jpantsjoha/ai-native-developer-experience

Sitrep

Los informes de situación son para la persona que no estaba en la sala. Escribe para ella.

Un sitrep no es un diario de actividades. Es una imagen comprimida y accionable del estado actual. Tres preguntas: qué está hecho, qué está bloqueado, qué sigue. Cualquier cosa que no responda a una de esas tres preguntas no pertenece al sitrep.

Cuándo usarlo

• Síntesis del daily standup a partir de registros de trabajo, commits o estado de tickets
• Resumen de fin de sprint para interesados
• Informe de situación durante o después de un incidente activo
• Resumen de traspaso al cambiar de contexto o entregar trabajo a otro agente o persona
• Cuando un interesado pregunta "¿dónde estamos?" y la respuesta honesta es "es complicado"

Procedimiento

1. Recopila el estado actual del trabajo — lee de las fuentes disponibles:

   • Issues / tickets abiertos y cerrados recientemente
   • Commits recientes (últimas 24-48 horas para un standup; último sprint para un resumen de sprint)
   • Documentos de estado del proyecto y roadmap (p. ej. docs/operating-model/PROJECT-OPERATING-PROFILE.md, docs/ROADMAP.md, o equivalente según la estructura del proyecto)
   • Cualquier bandera de bloqueo, entradas del registro de riesgos o notas de escalamiento

2. Clasifica los elementos en tres cubos:

   • Hecho — completado y verificablemente cerrado (pruebas pasando, ticket cerrado, desplegado)
   • Bloqueado — trabajo que no puede avanzar sin una dependencia específica no resuelta (nombra el bloqueador con precisión)
   • Siguiente — los elementos de mayor prioridad que se trabajarán a continuación (ordenados por prioridad)

3. Escribe el sitrep — estructura:

   ## Sitrep — <fecha> [<alcance: sprint / incidente / traspaso>]
   
   **Hecho**
   - <elemento> — <una frase sobre lo que se entregó y su evidencia>
   
   **Bloqueado**
   - <elemento> — bloqueado por <dependencia específica / propietario / ETA si se conoce>
   
   **Siguiente**
   - <elemento> — <orden de prioridad, más importante primero>
   
   **Riesgos / banderas** (opcional — solo si es relevante)
   - <riesgo> — <impacto si no se resuelve> — <propietario>
   

4. Aplica la prueba de compresión — por cada línea: si eliminarla no cambia nada que el lector necesite para actuar, elimínala.

5. Nombra los bloqueadores con precisión — "bloqueado por backend" no es una entrada de bloqueador. "Bloqueado por el contrato de API para /v2/orders — esperando a @owner, ETA desconocida" sí lo es.

6. No editorialices el progreso — "se ha avanzado bien" es ruido. "Se entregó X, lo que desbloquea Y" es señal.

Salidas

• Un sitrep en el formato anterior
• Opcional: un resumen ejecutivo de un párrafo para los interesados que necesitan aún menos

Guardarraíles

• Sin informes de actividad. "Trabajé en el módulo de autenticación" no es una entrada de sitrep. "Módulo de autenticación: validación JWT completa, renovación de token falla bajo carga — investigando" sí lo es.
• Bloqueado significa bloqueado. Si algo avanza lentamente pero no está realmente bloqueado, pertenece a "Siguiente" con una nota, no a "Bloqueado".
• Hecho significa hecho. "95% hecho" no está hecho. Si no está verificablemente completo, es "Siguiente".
• La longitud no es calidad. Un sitrep de cinco líneas que responde las tres preguntas es mejor que uno de veinte líneas que no lo hace.