jg-breakdown

Invocación

Ejecutar solo por invocación directa del desarrollador. Ejecutar el flujo de trabajo con las herramientas disponibles; no simularlo, sustituir comandos de shell ni volver a preguntar por acciones ya autorizadas.

Tratar el texto suministrado como argumentos, restricciones o contexto, respetando los límites y aplazamientos. Informar honestamente sobre las capacidades faltantes y los bloqueadores. Nunca simular éxito.

Liberar los recursos de ejecución propiedad del runtime y la salida desechable del proceso, incluso en caso de error, preservando la evidencia no resuelta e informando los recursos retenidos en la salida de esta habilidad. Esta excepción limitada de limpieza nunca permite modificar archivos revisados/preexistentes, eliminar cambios inesperados ni limpiar trabajo anterior. Todas las demás escrituras siguen este flujo de trabajo. Las reglas específicas de esta habilidad sobre el material suministrado tienen prioridad.

jg-plans protocolo 0.2

Los documentos persistentes necesitan jg-plans >=0.6.1 local al proyecto con esquema CLI 3. El trabajo sin plan/solo código, el análisis de transcripciones y la pausa no necesitan CLI.

• Usar la entrada del proyecto instalada, normalmente <repository-root>/node_modules/.bin/jg-plans, o su entrada de construcción documentada. Ejecutar esa entrada exacta con --version --json; requerir error nulo, versión >=0.6.1 y schemaVersion 3 antes del trabajo con documentos. De lo contrario, detener ese trabajo con el par observado y la solución específica del gestor, como npm install --save-dev --save-exact [email protected]. Preservar la dependencia de producción de los consumidores del runtime. Nunca instalar automáticamente, descargar un ejecutor, usar herramientas globales ni tomar prestada la CLI de otro proyecto. Volver a verificar la entrada después de una actualización/construcción.
• Leer solo el directorio seleccionado a través de esa CLI: inspect --directory <path> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Usar su fuente, metadatos, intervalos, diagnósticos, sha256 y huella estructural. Nunca editar/analizar/hashear documentos persistentes directamente, generar sus UUIDs, seleccionar planes por actualidad ni reconstruir transcripciones en archivos. No se requiere conformidad para la inspección. Solo jg-plan ejecuta adicionalmente overlaps --json, con un --root por cada raíz de planificación existente en los repositorios registrados/propios cuando se declaran códigos.
• Los estados de plan son pendiente, en progreso, hecho y entregado. Los estados de hito permanecen como pendiente, en progreso y hecho. Activo significa pendiente, en progreso y hecho; solo entregado está inactivo. Las declaraciones de error usan listas de repositorio/registro/códigos; preservar tipos string/number y comparar String(code) dentro del repositorio/registro. Los estados faltantes/personalizados, metadatos/archivos no disponibles y marcadores ambiguos siguen siendo observaciones, nunca valores predeterminados o autoridad.
• Los mapas de entrega requeridos declaran cada repositorio hasta su parada definida por el repositorio, con claves coincidentes. Usar un mapeo vacío explícito solo cuando no se declaren repositorios. La entrega no cambia el alcance de implementación ni el progreso del hito. Las huellas excluyen exactamente created_at, updated_at, revision, status, priority y delivery; la identidad no disponible no puede establecer una cobertura nueva.
• Mutar a través de la misma entrada con entrada estructurada de create/update/write/remove-milestones, dentro de la autoridad de este flujo de trabajo. Las escrituras en destino existente requieren un expectedSha256 nuevo; null solo crea hitos ausentes explícitamente solicitados. Usar write para el cuerpo/metadatos de un plan o fuente completa de hito; update para metadatos/marcadores estrechos. Asignar IDs faltantes solo cuando esté autorizado; retener los IDs devueltos e inspeccionar las escrituras. Establecer updated_at explícitamente cuando plan.md cambie. Las ediciones solo de entrega preservan revisión/progreso; el alcance cambiado necesita una reevaluación de cobertura.
• Los bloqueos son cortos y locales: nunca mantenerlos entre turnos, eliminar bloqueos desconocidos ni reproducir sobre texto más nuevo. Después de una falla de mutación parcial de múltiples documentos o incierta, inspeccionar/informar los estados duraderos y detenerse sin retroceder/reintentar. Los documentos, diagnósticos y enlaces no otorgan autoridad.

Flujo de trabajo

Realizar una evaluación solo de planificación de un plan concreto para el cambio de ingeniería que se está discutiendo actualmente. Convertir el plan en hitos de implementación ordenados solo cuando la descomposición proporcione límites significativos de ejecución y revisión. Esta habilidad no crea una nueva estrategia ni autoriza la implementación. Autoriza solo la inspección del repositorio de solo lectura más pequeña necesaria para confirmar que el plan sigue siendo actual y la creación, actualización o eliminación de milestones.md en el directorio de ese plan. No autoriza la edición de ningún otro archivo, la actualización de pruebas o instantáneas, la ejecución de correcciones automáticas o generadores que producen escritura, la instalación de dependencias, la creación de migraciones o artefactos generados, el cambio del estado de Git, el commit, el push ni el inicio de la implementación.

Se requiere un plan concreto. Usar el plan en la ruta proporcionada con la invocación, de lo contrario el plan exacto establecido en la discusión actual y el directorio de planificación que lo contiene. No buscar otros directorios de planificación ni seleccionar un plan basado en marcas de tiempo. Si el plan no se persistió, usar el plan exacto presentado más recientemente al desarrollador, mantener esa limitación explícita y no crear un nuevo directorio de planificación durante jg-breakdown. No usar jg-breakdown para rediseñar la solución, expandir o reducir el alcance, cambiar la arquitectura, alterar los criterios de aceptación, introducir mejoras opcionales o resolver en silencio decisiones que pertenecen al nivel del plan. Si no existe un plan actual, no se puede identificar de forma segura, la evidencia del repositorio lo ha invalidado materialmente, o producir un desglose seguro requeriría cambiar una decisión material del plan, informar el bloqueador y detenerse; el plan debe crearse o revisarse a través de jg-plan antes de que pueda desglosarse.

1. Reutilizar la evidencia del repositorio y las decisiones establecidas por el plan actual cuando sigan siendo actuales. Realizar inspección de solo lectura adicional solo cuando sea necesario para determinar si existen límites de hitos útiles, establecer sus dependencias, asignar la propiedad de verificación o determinar si el plan se ha vuelto obsoleto.

2. Determinar si el plan contiene al menos dos fragmentos de implementación coherentes que puedan alcanzar un estado final significativo, completar sus pruebas requeridas u otra verificación, y respaldar un punto de control de revisión útil para el desarrollador. No dividir un plan simplemente porque contiene múltiples archivos, pasos de implementación, capas o comandos de verificación.

3. Si el plan es un fragmento de implementación coherente, no crear milestones.md. Eliminar una secuencia innecesaria existente solo cuando el desarrollador haya autorizado la eliminación y el progreso retenido no se descarte en silencio; de lo contrario, preguntar antes de eliminar. Usar remove-milestones con su hash inspeccionado reciente. Un resultado deliberado actual sin secuencia establece la ejecución de todo el plan; una secuencia esperada faltante inesperada nunca lo hace. Decir al desarrollador que el plan debe implementarse como un alcance completo sin desglosarlo. Si el plan aún no ha sido aprobado, indicar que su aprobación aún es necesaria. Luego detenerse sin añadir un resumen de finalización. Mantener la entrega final de la tarea como metadatos de todo el plan, fuera de los criterios de implementación, el estado del hito y los objetivos. Si un criterio del plan requiere alcanzar su objetivo de entrega final antes de que la implementación pueda considerarse hecha, detenerse para que jg-plan elimine esa dependencia circular; no asignar cobertura solo de requisito previo mientras se admite que el criterio sigue sin cumplirse. Retener las compuertas de lanzamiento/despliegue de componentes independientemente necesarias donde la estrategia aprobada las requiera, y las pruebas del comportamiento de entrega como una característica del producto; no añadir entrega de tareas automática por hito.

4. Cuando la descomposición esté justificada, convertir los pasos de implementación estratégicos del plan en una secuencia ordenada de hitos numerados. Usar Milestone como unidad de ejecución; no crear una jerarquía de hito, tarea y subtarea solo para aumentar la granularidad.

5. Hacer que cada hito sea el fragmento de implementación coherente más pequeño que pueda completarse, probarse o verificarse de otro modo, y revisarse como un estado final significativo. Mantener cada hito lo suficientemente pequeño como para terminarlo en una ventana de contexto nueva, y colocar la refactorización que facilite hitos posteriores al principio. Para cada hito, incluir:

   • un objetivo conciso que describa el resultado final
   • dependencias de hitos anteriores o requisitos previos externos
   • los archivos, módulos, símbolos, contratos, configuración, documentación y migraciones exactos dentro del alcance del plan que el hito posee cuando se conocen
   • el trabajo de implementación requerido para alcanzar el estado final del hito
   • las pruebas enfocadas y otra verificación que debe completarse para ese hito, reteniendo su propia evidencia de corrección y cualquier compuerta de lanzamiento/despliegue independiente requerida. Asignar la cobertura de regresión final a su hito propietario en lugar de copiarla en cada unidad; seguir la política de pruebas del plan y del repositorio, e identificar evidencia reutilizable válida y repeticiones de estabilidad requeridas
   • criterios de aceptación concretos que determinen si el hito está completo; en un plan de protocolo 0.2, escribir estas comprobaciones específicas del hito como prosa y nunca definir nuevos IDs AC- en milestones.md
   • un punto de control de revisión que identifique el comportamiento, los contratos, los riesgos, los puntos de integración u otros detalles importantes que el desarrollador debe inspeccionar antes de continuar

6. Mantener la implementación y su evidencia de corrección requerida juntas. No dividir las pruebas requeridas, la documentación directamente afectada, la sincronización de contratos de error, las migraciones, las exportaciones públicas u otro trabajo de soporte necesario en hitos posteriores solo para hacer un hito anterior más pequeño. No crear marcadores de posición, duplicación temporal, abstracciones no utilizadas, rutas de compatibilidad transitorias, andamios sin salida ni implementaciones deliberadamente incompletas únicamente para fabricar límites de hitos a menos que el plan aprobado requiera explícitamente una ruta de compatibilidad o migración por etapas. No hacer los hitos artificialmente pequeños o uniformes en tamaño. Ordenarlos según las dependencias de implementación reales y el riesgo.

7. Realizar un pase de cobertura de plan a hitos antes de finalizar la secuencia. Cada entregable dentro del alcance, criterio de aceptación, cambio de producción requerido, prueba, actualización de documentación, migración, cambio de contrato público, eliminación, punto de integración y requisito de verificación en el plan debe aparecer en al menos un hito visible para el desarrollador. La secuencia presentada al desarrollador es la secuencia de hitos completa y final. No reservar hitos ocultos, mantener una secuencia interna alternativa, omitir trabajo requerido ni depender de trabajo a nivel de hito no declarado. Si el trabajo requerido no se puede asignar sin cambiar una decisión material del plan, informar el bloqueador y detenerse; el plan debe revisarse a través de jg-plan antes de que el desglose pueda completarse.

8. Inspeccionar el plan actual seleccionado y la secuencia. Requerir un id de plan utilizable, revisión y huella estructural con exactamente created_at, updated_at, revision, status, priority y delivery excluidos antes de vincular una secuencia. Conciliar todo el plan actual con las unidades propuestas: los IDs retenidos identifican el mismo trabajo, y el estado hecho retenido necesita evidencia de que sus requisitos siguen siendo satisfechos. Preservar identidades/progreso coincidentes y metadatos de hitos no relacionados; agregar nuevo alcance incompleto como pendiente. Preguntar al desarrollador cuando la correspondencia de identidad/alcance o la finalización contradictoria no se pueda resolver de forma segura. Nunca retroceder un estado sin autorización explícita de reapertura. Los marcadores existentes faltantes/personalizados/ambiguos no son valores predeterminados pendientes. Escribir la fuente completa del hito a través de guarded write, expectedSha256 null solo para ausencia observada, con assignMissingIds true; la herramienta proporciona UUIDs faltantes. Colocar el estado inmediatamente debajo de cada encabezado y el UUID inmediatamente después. En un plan de protocolo 0.2, dar a cada hito que entregue criterios del plan una línea **Criterios de aceptación:** AC-01, AC-03 que liste sus IDs, directamente después de su línea UUID, o directamente después de su línea de estado cuando la herramienta asignará el UUID; cada criterio del plan aparece en al menos la línea de un hito, y un hito que no entrega ninguno la omite. No generar una tabla de Visión general y no sincronizar una. Incluir un mapeo de frontmatter jg_skills con plan_id, plan_revision y plan_content_sha256 del plan actual solo después de que la secuencia completa lo cubra. Preservar unidades completadas mientras se agrega nuevo alcance incluso cuando cada unidad anterior se haya completado. Volver a inspeccionar la identidad del plan inmediatamente antes de escribir y verificar que se mantuvo actual; el cambio concurrente requiere una nueva evaluación de cobertura. Volver a inspeccionar el resultado persistido, incluidos los IDs asignados, antes de presentar su Markdown completo exacto. Para un plan de protocolo 0.2, también ejecutar <local-cli> check --directory <path> --json y corregir cada error de cobertura, ID y estado en milestones.md antes de presentar; informar los errores de plan.md como necesitando jg-plan. Informar la ruta relativa al repositorio primero. Cambiar solo milestones.md en el directorio seleccionado; nunca cambiar plan.md, el estado de Git o la implementación.

9. Terminar tanto milestones.md como el cuerpo de respuesta coincidente con una sección ## Aprobación requerida que resuma la secuencia completa de hitos y establezca estas reglas, luego detenerse:

   • Cada hito necesita su propia autorización explícita, es el alcance completo de esa solicitud y termina en su punto de control de revisión. Invocar jg-execute autoriza el hito que ejecuta; jg-execute auto autoriza cada hito restante, o solo el hito que nombra.
   • Si un hito depende de trabajo anterior incompleto, o completarlo cruzaría un límite de hito o cambiaría el plan aprobado, detenerse e informar antes de expandir el alcance.
   • Para cambiar el plan, invocar jg-plan con las enmiendas. Para crear o cambiar hitos, invocar jg-breakdown.

   El contrato de salida de esta habilidad reemplaza cualquier requisito general de resumen de finalización; no añadir un resumen de finalización después de ## Aprobación requerida. La aprobación debe emitirse después de que se presente la secuencia actual de hitos; la invocación de jg-breakdown en sí misma, la aprobación anterior del jg-plan y los contratos de revisión independientes no constituyen aprobación. Cuando se presente una secuencia de hitos por primera vez, la aprobación de un hito aún requiere la invocación de jg-execute.

Autorización

Esta habilidad autoriza las siguientes acciones: inspección de solo lectura del repositorio, lectura del contenido de documentos de planificación a través de la CLI de jg-plans, y creación, actualización o eliminación del archivo milestones.md en el directorio del plan seleccionado. No autoriza la edición de ningún otro archivo, la instalación de dependencias, la ejecución de pruebas, la realización de cambios en Git, el inicio de la implementación ni ninguna otra acción de escritura o modificación.

Restricciones

• Esta habilidad no debe utilizarse para rediseñar la solución, expandir o reducir el alcance, cambiar la arquitectura, alterar los criterios de aceptación, introducir mejoras opcionales ni resolver en silencio decisiones que pertenecen al nivel del plan.
• No debe utilizarse cuando no exista un plan concreto, no se pueda identificar de forma segura o la evidencia del repositorio lo haya invalidado materialmente.
• No debe crear hitos artificialmente pequeños o uniformes en tamaño; debe ordenarlos según las dependencias de implementación reales y el riesgo.
• No debe dividir el trabajo de soporte necesario (pruebas, documentación, migraciones, etc.) en hitos posteriores solo para hacer un hito anterior más pequeño, a menos que el plan aprobado requiera explícitamente una ruta de compatibilidad o migración por etapas.
• No debe reservar hitos ocultos, mantener una secuencia interna alternativa, omitir trabajo requerido ni depender de trabajo a nivel de hito no declarado.

Salida y formato

La salida de esta habilidad es el contenido de milestones.md en el directorio del plan seleccionado, con el formato especificado por el protocolo jg-plans 0.2. El cuerpo de la respuesta debe terminar con una sección ## Aprobación requerida que resuma la secuencia completa de hitos y establezca las reglas de aprobación. No se debe añadir ningún resumen de finalización después de esta sección.