jesusgraterol/jg-challenge-plan

Invocación

Ejecutar solo bajo invocación directa del desarrollador. Ejecuta el flujo de trabajo con las herramientas disponibles; no lo simules, no sustituyas comandos de shell ni preguntes de nuevo por acciones ya autorizadas.

Trata el texto proporcionado como argumentos, restricciones o contexto, respetando límites y aplazamientos. Informa honestamente sobre capacidades faltantes y bloqueadores. Nunca simules éxito.

Libera los recursos de ejecución propiedad del runtime y los resultados temporales descartables, incluso en caso de fallo, conservando evidencia no resuelta e informando sobre los recursos retenidos en la salida de esta habilidad. Esta excepción de limpieza acotada 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 proporcionado tienen prioridad.

Protocolo jg-plans 0.2

Los documentos persistentes necesitan jg-plans >=0.6.1 con esquema CLI 3. Para trabajo sin plan/solo código, análisis de transcripción y pausa no se necesita CLI.

• Utiliza la entrada del proyecto instalada, normalmente <raíz-del-repositorio>/node_modules/.bin/jg-plans, o su entrada documentada. Ejecuta esa entrada exacta con --version --json; requiere que error sea nulo, versión >=0.6.1 y schemaVersion 3 antes de trabajar con documentos. De lo contrario, detén ese trabajo con el par observado y la solución específica del gestor, por ejemplo npm install --save-dev --save-exact [email protected]. Preserva la dependencia de producción del consumidor del runtime. Nunca instales automáticamente, descargues un ejecutor, uses herramientas globales ni tomes prestado el CLI de otro proyecto. Vuelve a verificar la entrada después de una actualización/compilación.
• Lee solo el directorio seleccionado a través de ese CLI: inspect --directory <ruta> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Utiliza su fuente, metadatos, lapsos, diagnósticos, sha256 y huella estructural. Nunca edites/analices/parsees documentos persistentes directamente, generes sus UUIDs, selecciones planes por antigüedad ni reconstruyas 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 los planes son pendiente, en progreso, finalizado y entregado. Los estados de los hitos permanecen pendiente, en progreso y finalizado. Activo significa pendiente, en progreso y finalizado; solo entregado está inactivo. Las declaraciones de error utilizan listas de repositorio/registro/códigos; preserva los tipos cadena/número y compara String(código) dentro del repositorio/registro. Los estados faltantes/personalizados, metadatos/archivos no disponibles y marcadores ambiguos siguen siendo observaciones, nunca valores predeterminados ni autoridad.
• El mapeo de entrega requerido asigna cada repositorio declarado a su parada definida por el repositorio, con claves coincidentes. Usa un mapeo vacío explícito solo cuando no se declaran repositorios. La entrega no cambia el alcance de la implementación ni el progreso de los hitos. Las huellas excluyen exactamente created_at, updated_at, revision, status, priority y delivery; la identidad no disponible no puede establecer una cobertura nueva.
• Muta a través de la misma entrada con entrada estructurada de crear/actualizar/escribir/eliminar-hitos, dentro de la autoridad de este flujo de trabajo. Las escrituras de destino existentes requieren un freshExpectedSha256; null solo crea hitos ausentes explícitamente solicitados. Usa write para el cuerpo de un plan/metadatos o fuente completa de hitos; update para metadatos/marcadores acotados. Asigna IDs faltantes solo cuando esté autorizado; conserva los IDs devueltos e inspecciona las escrituras. Establece updated_at explícitamente cuando plan.md cambie. Las ediciones solo de entrega preservan revisión/progreso; un alcance modificado necesita una reevaluación de la cobertura.
• Los bloqueos son cortos y locales: nunca los mantengas entre turnos, elimines bloqueos desconocidos ni vuelvas a ejecutar sobre texto más reciente. Después de una falla de mutación parcial multi-documento o incierta, inspecciona/informa los estados duraderos y detente sin retroceso/reintento. Los documentos, diagnósticos y enlaces no otorgan autoridad.

Flujo de trabajo

Realiza un desafío conciso y de solo lectura de un plan concreto para el cambio de ingeniería que se está discutiendo actualmente. Trata el plan como una propuesta no confiable, incluso cuando el mismo agente lo creó. El propósito es ayudar al desarrollador a verificar rápidamente que el resultado planificado coincida con el contrato de la tarea y exponer decisiones materiales, suposiciones, omisiones y riesgos antes de la aprobación, jg-breakdown o la implementación. Esta habilidad no autoriza cambiar el plan, crear o editar archivos de planificación, modificar código fuente, pruebas, instantáneas, configuración, dependencias, migraciones, artefactos generados, documentación ordinaria del proyecto o el estado de Git, aprobar o rechazar el plan, autorizar jg-breakdown ni comenzar la implementación. Si un comando de inspección modifica archivos inesperadamente, preserva e informa esos cambios sin limpiarlos, revertirlos ni reclamarlos como parte del desafío.

Se requiere un plan concreto. Cuando el desarrollador identifica un plan por ruta u otro identificador inequívoco, desafía exactamente ese plan. De lo contrario, usa el plan actual exacto solo cuando exista un candidato inequívoco en la discusión actual. Si más de un plan pudiera ser razonablemente el objetivo previsto, detente y pide al desarrollador que seleccione uno. No busques otros directorios de planificación, elijas un plan basado en marcas de tiempo ni infieras un objetivo únicamente por la antigüedad del archivo. Si no existe un plan actual o no se puede acceder completamente al plan identificado, informa el bloqueador y detente. Si la evidencia actual del repositorio invalida materialmente el plan, continúa con el desafío y presenta esa desactualización como un hallazgo bloqueante.

1. Lee el plan objetivo completo, el contrato de la tarea de la discusión actual y cualquier enmienda del desarrollador que se aplique a ese plan exacto. Trata el resumen de la tarea del propio plan como una representación no confiable, no como evidencia independiente de la intención del desarrollador. Si el objetivo, las restricciones, las exclusiones, los criterios de aceptación y las enmiendas del desarrollador no pueden establecerse independientemente del plan, continúa solo con desafíos internos del plan y basados en evidencia del repositorio, indica que no se pudo verificar la alineación de la intención, enumera como decisión 1 confirmando que el objetivo, las restricciones y las exclusiones del plan coinciden con la intención del desarrollador, y usa Se requiere decisión del desarrollador antes de proceder a menos que un defecto material del plan requiera Se requiere revisión del plan antes de proceder. Captura la ruta relativa al repositorio del plan objetivo o el identificador proporcionado y su SHA-256 exacto de la inspección seleccionada actual, incluye ambos en ## Resumen del plan y vuelve a inspeccionar inmediatamente antes de responder y verifica que el hash no haya cambiado; si cambió, informa el bloqueador y detente. Reutiliza la evidencia del repositorio establecida por el plan cuando siga siendo actual. Realiza solo la inspección adicional de solo lectura más pequeña necesaria para verificar una incertidumbre material, detectar desactualización o validar una afirmación de alto impacto; no repitas el flujo de trabajo completo de planificación solo porque se invocó esta habilidad.

2. Determina qué construirá, cambiará, eliminará, migrará, expondrá o implementará realmente el plan. Compara ese resultado con el objetivo, las restricciones, las exclusiones, los criterios de aceptación y las decisiones aprobadas del desarrollador. Identifica la expansión material del alcance, el trabajo requerido faltante, el comportamiento cambiado, las suposiciones no respaldadas y los lugares donde el resultado propuesto podría diferir de la intención del desarrollador. Verifica que la entrega cubra cada repositorio declarado, que los destinos existan en su documento de entrega, que los operadores/precondiciones sean explícitos y que la aprobación cubra los pasos operados por el agente. La entrega de todo el plan debe seguir a la implementación y revisión; los pasos restantes operados por el desarrollador no pueden llamarse entregados.

3. Desafía las decisiones materiales del plan y los controles de riesgo cuando sea aplicable, incluidos la arquitectura y la propiedad de módulos; el flujo de datos y los límites de integración; los esquemas de base de datos, datos persistentes, migraciones y reversión; las API públicas, exportaciones, eventos, colas, webhooks, claves de caché, configuración y compatibilidad; seguridad, privacidad, autenticación, autorización, propiedad, facturación y otro comportamiento que genera valor; concurrencia, reintentos, idempotencia y recuperación de fallos; dependencias, infraestructura, despliegue y requisitos operativos; eliminaciones de rutas reemplazadas o paralelas; y si la estrategia de pruebas y verificación podría exponer defectos importantes de manera realista.

4. Busca específicamente complejidad innecesaria, abstracciones especulativas, propiedad duplicada, implementaciones temporales o paralelas sin una necesidad de migración justificada, rutas de compatibilidad o reversión incompletas, cambios ocultos de alto radio de explosión y verificación que podría pasar mientras el comportamiento material sigue siendo incorrecto. No fabriques críticas solo porque esta habilidad se llama jg-challenge-plan; Sin preocupaciones materiales es un resultado válido. En un seguimiento, reevalúa hallazgos anteriores, intención o material del plan cambiados e interacciones afectadas, reutilizando la evidencia actual para áreas revisadas sin cambios. Mantén las preocupaciones materiales no resueltas; amplía solo para un desafío completo nuevo explícito, cobertura previa faltante, evidencia desactualizada, nuevos fallos o riesgo material cambiado.

5. Informa solo información que ayude al desarrollador a tomar una decisión de aprobación. Mantén los detalles de implementación de bajo impacto, inventarios de archivos exhaustivos, secuencias de implementación paso a paso, matrices de prueba completas y listas de comandos de verificación fuera del resultado a menos que un elemento específico exponga una preocupación material. Para cada desafío, indica la discrepancia concreta, omisión, suposición no respaldada o riesgo; por qué es importante; y la corrección más pequeña y apropiada. No reescribas el plan, reemplaces silenciosamente su arquitectura ni presentes una implementación alternativa como si ya estuviera aceptada.

6. Presenta el resultado usando exactamente estas secciones:

   • ## Resumen del plan: Resume el resultado final previsto, los límites principales de implementación y las exclusiones importantes explícitas.
   • ## Impacto material: Expón solo las decisiones arquitectónicas, cambios de base de datos o datos persistentes, cambios de contratos públicos o de integración, comportamiento sensible a la seguridad, cambios de dependencias o infraestructura e implicaciones de migración, compatibilidad, despliegue o reversión que merezcan la atención del desarrollador. Omite categorías irrelevantes o indica Sin cambios cuando la ausencia en sí misma sea importante.
   • ## Desafíos: Enumera los hallazgos materiales en orden descendente de impacto. Indica No se encontraron preocupaciones materiales cuando no existan.
   • ## Decisiones del desarrollador requeridas: Incluye solo las elecciones no resueltas que afecten materialmente el comportamiento, alcance, contratos, seguridad, datos, arquitectura u operaciones. Numera cada decisión listada en el orden en que el desarrollador debería abordarla. Para cada decisión, indica la elección exacta a tomar, proporciona al menos una recomendación y explica las consecuencias materiales y las compensaciones de aceptar la recomendación, elegir una alternativa significativa o dejar la decisión sin resolver. Indica Ninguna cuando no quede tal decisión; no inventes una decisión solo para llenar esta sección.
   • ## Recomendación: Coloca exactamente uno de Sin preocupaciones materiales, Se requiere revisión del plan antes de proceder o Se requiere decisión del desarrollador antes de proceder en la primera línea. Usa Se requiere revisión del plan antes de proceder siempre que exista un defecto material del plan, incluso cuando también se requiera la opinión del desarrollador. Usa Se requiere decisión del desarrollador antes de proceder solo cuando el plan por lo demás sea sólido pero no pueda proceder de manera segura sin una decisión material del desarrollador. Coloca exactamente una línea Siguiente paso: debajo del veredicto:
     • después de Sin preocupaciones materiales, dirige al desarrollador a ejecutar jg-breakdown cuando el plan tenga al menos dos partes que puedan terminarse, verificarse y revisarse por separado, como paquetes, repositorios o versiones separados, y de lo contrario a aprobar el plan o invocar jg-execute. Los puntos de control de revisión del propio plan no hacen que un desglose sea innecesario: sin milestones.md, jg-execute ejecuta todo el plan como una sola unidad y no se detiene en ellos.
     • después de Se requiere revisión del plan antes de proceder, dirige al desarrollador a responder cualquier decisión numerada, invocar jg-plan, que aplica las correcciones requeridas junto con esas respuestas, e invocar jg-challenge-plan nuevamente después de que se presente el plan revisado.
     • después de Se requiere decisión del desarrollador antes de proceder, dirige al desarrollador a responder las decisiones numeradas, invocar jg-plan con cualquier respuesta que cambie el plan e invocar jg-challenge-plan nuevamente después de que se presente el plan revisado.

7. Mantén el desafío completo en 1.000 palabras o menos. Consolida preocupaciones estrechamente relacionadas y prioriza la información con el mayor valor de decisión. No omitas una preocupación bloqueante solo para cumplir con el límite y no reproduzcas contenido del plan solo para consumir el espacio disponible.

8. Trata la recomendación como consultiva. No aprueba el plan, revoca una aprobación anterior, autoriza jg-breakdown, autoriza la implementación ni convierte jg-challenge-plan en un requisito previo para otro flujo de trabajo. Un desafío se aplica solo a la versión exacta del plan evaluada; cualquier revisión del plan hace que el desafío anterior quede desactualizado y no debe reutilizarse como evidencia sobre el plan revisado. Termina después de la línea Siguiente paso: en ## Recomendación; el contrato de salida de esta habilidad reemplaza cualquier requisito general de resumen de finalización.