Lujker/road-map-journal

Roadmap y diario de trabajo

Mantener un plan actual útil y un registro trazable de decisiones sin imponer una nueva estructura. Seguir las instrucciones del usuario y las convenciones del proyecto. Preservar nombres, identificadores, idioma, enlaces, cambios sin confirmar y contenido no relacionado existentes. Para un plan nuevo, usar el idioma que el usuario especifique o indique razonablemente; preguntar si no está claro. No imponer un idioma.

Cuándo usarlo

Usar para solicitudes sobre un roadmap, plan de desarrollo, cola, diario de trabajo, estado de elementos o continuación de trabajo planificado. Ejemplos incluyen "¿qué sigue en el roadmap?", "continúa el elemento acordado", «dorožnaya karta», «plan razrabotki», «dnevnik razrabotki», «shto dal'she po planu?» y «prodolźi razrabotku po planu». Determinar el alcance solicitado según el contexto; una pregunta de estado es de solo lectura.

Descubrir primero

Identificar la raíz del proyecto y leer sus instrucciones. Localizar roadmaps, colas, notas de elementos y documentos de traspaso existentes; los nombres y ubicaciones varían. Leer el elemento relevante, sus criterios de aceptación, la cola actual y las notas vinculadas. Verificar la implementación relevante, el estado del control de versiones si está disponible, y la evidencia cuando la solicitud necesite una evaluación del estado actual. No asumir Git, un diseño de directorios específico o un vocabulario de estado particular. Para múltiples repositorios, seguir los enlaces existentes; preguntar por una ubicación autorizada inaccesible en lugar de inventar un reemplazo.

Seleccionar el modo implícito en la solicitud:

• Solo lectura: Responder a partir de los documentos y la evidencia relevantes. Distinguir afirmaciones registradas de hechos verificados de forma independiente; no hacer ediciones.
• Inicialización: Si no existe un plan, discutir la forma de trabajo deseada por el propietario y proponer una estructura, ubicación, alcance, elementos iniciales y orden adecuados; incluir tracks, roles de agente y tarjetas iniciales cuando sea relevante. Para exploración más profunda, usar grill-me si está disponible y es apropiado; si no, ofrecer instalarlo, pero no instalar sin permiso ni bloquear el flujo de trabajo. De lo contrario, facilitar una discusión estructurada y concisa tú mismo, con recomendaciones para las opciones no resueltas. Obtener el consentimiento informado del usuario antes de crear archivos; no inventar prioridades ni compromisos.
• Adopción: Si ya existe material de planificación, usarlo en su lugar. Cuando el propietario solicite una revisión sustancial, usar la misma discusión estructurada opcional que para la inicialización, adaptada a lo que esté sin resolver. Explicar cualquier nuevo archivo, migración o reescritura sustancial propuestos y obtener el consentimiento informado primero. No crear silenciosamente una fuente de verdad paralela.
• Reanudación: Leer la última directiva, la cola activa, las notas de los elementos y el estado actual relevante. Resolver instrucciones contradictorias o desactualizadas según la evidencia actual y la última decisión del usuario; preguntar si persiste un conflicto relevante. Si el elemento no está ya seleccionado o delegado, acordar uno antes de la implementación. Un plan guardado o la aprobación para documentar no es autorización para comenzar a trabajar.
• Actualización: Realizar los cambios solicitados y con alcance definido en los registros existentes. Mantener consistentes el estado del elemento, el trabajo restante y las entradas de cola afectadas; preservar el historial y el orden no relacionado. Para un archivo nuevo o una reescritura sustancial, explicar el cambio propuesto y obtener el consentimiento informado primero. Una solicitud limitada a un elemento no autoriza a implementar o reescribir el resto del plan.

Registrar y conciliar

Usar la disposición establecida del proyecto. Típicamente, un roadmap resume los elementos y su orden actual; un diario contiene decisiones, hallazgos, evidencia e historial. Vincular en lugar de duplicar detalles largos. Mantener estables los identificadores. No eliminar silenciosamente decisiones o trabajo cancelado: marcarlos como reemplazados o cancelados con la razón cuando sea relevante.

Cuando una decisión, pausa u orden cambie, actualizar los resúmenes actuales afectados y las instrucciones de siguientes pasos dentro del alcance autorizado; etiquetar las instrucciones anteriores como históricas. Un plan pausado o aplazado no debe parecer una instrucción activa para continuar. No re-priorizar trabajo no relacionado solo porque se añadió una nota. Si una corrección necesaria queda fuera del alcance autorizado, señalarla al usuario en lugar de ampliar la edición.

A menos que el propietario haya autorizado un alcance más amplio, trabajar en un elemento a la vez y no comenzar automáticamente el siguiente. Una subetapa completada no completa el elemento padre; registrar el resto. Mantener el modo de trabajo separado de los permisos y presupuestos: la autorización para continuar no es un permiso general para acciones de producción o escrituras externas. Mantener distintas la finalización registrada, la aceptación pendiente del usuario y el trabajo completamente aceptado. Mantener puntos de control concisos en traspasos, decisiones, resultados verificados y bloqueadores, incluyendo qué queda y cómo reanudar; verificar acciones inciertas en curso antes de repetirlas. Antes de una actualización multiarchivo en un checkout compartido, verificar el estado del control de versiones y las rutas sucias inmediatamente antes de escribir, aplicar ediciones precisas sobre contenido recién leído, preservar el trabajo no relacionado y verificar los cambios con alcance definido sin confirmar ni publicar a menos que esté autorizado.

Para trabajo que abarca varios elementos, agentes o sesiones, tiene un presupuesto, o donde el propietario autoriza un track o modo continuo, leer primero Trabajo de larga duración.

Estado y evidencia

Usar el vocabulario de estado del proyecto. Si no existe, sugerir ABIERTO, EN PROGRESO, BLOQUEADO, PARCIAL y HECHO, con significados acordados para el proyecto. Registrar el estado según los criterios de aceptación y la evidencia real, no según la intención o una afirmación no respaldada de un delegado. Para PARCIAL, nombrar qué queda y cualquier bloqueador. Mantener coherentes las referencias de estado afectadas.

Registrar las comprobaciones realmente realizadas, sus resultados y alcance, y quién las realizó cuando sea relevante. La evidencia puede ser histórica o de otro ejecutor; etiquetar su fuente y aplicabilidad, y no implicar que se volvió a ejecutar. Si cambios posteriores invalidan una comprobación, identificar o realizar la verificación adecuada. Nunca inventar comandos, resultados, conteos de pruebas, aprobaciones o aceptación del usuario. Las pruebas automatizadas, el código lanzado y la operación en vivo son afirmaciones diferentes: nunca inferir aceptación en vivo a partir de la implementación o las pruebas. Si no se ha producido la aceptación requerida, retener PARCIAL o el equivalente del proyecto y declarar el entorno o la aprobación faltantes.

Después de una edición autorizada, comprobar el estado afectado, la cola, los enlaces y la coherencia con la evidencia y el alcance. Informar cambios, comprobaciones realmente realizadas y elementos no resueltos. No reclamar verificación que no se realizó.

Referencias

• Plantillas genéricas — puntos de partida opcionales, adaptados al proyecto.
• Escenarios — ejemplos concisos de elecciones de modo y alcance.
• Trabajo de larga duración — tracks, puntos de control, pausa y parada, aceptación, presupuestos, checkouts compartidos.
• Conciliación multirepositorio — preservar el trabajo y distinguir entre estado registrado, Git y en vivo a través de checkouts.