Communitygithub.com

Gentleman-Programming/gentle-ai-rdd-defect-workflow

Desencadenante: RDD, desarrollo impulsado por recibos, autoridad de revisión, recibo/linaje, corrección/recuperación, compuerta de entrega/interruptor de cancelación, defectos de revisión acotados. Guía el trabajo.

¿Qué es gentle-ai-rdd-defect-workflow?

Esta habilidad define un flujo de trabajo riguroso para la corrección de defectos guiado por principios de Desarrollo Impulsado por Recibos (RDD, por sus siglas en inglés). Está diseñada para entornos que requieren una autoridad de revisión clara y mantienen una separación estricta entre la evidencia de revisión y la autoridad de entrega. La habilidad exige que todos los cambios estén vinculados a un problema aprobado, una reproducción limpia en la rama `main` y un análisis de impacto basado en CodeGraph. Impone reglas estrictas como el agrupamiento de cambios por invariante causal, la validación de flujos de operador mediante pruebas de banco reales o pruebas E2E, y un límite de 400 líneas modificadas por candidato. Su objetivo es mantener una base de código limpia, una comunicación basada en evidencia y una distinción clara entre las funciones de contribuyente y mantenedor.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Gentleman-Programming/gentle-shell/tree/main/skills/rdd-defect-workflow

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Contrato de Activación

Cargar cuando los términos de activación en el frontmatter se apliquen a un flujo de trabajo de defectos.

Esta habilidad guía la colaboración pública. No otorga autoridad para aprobar issues, etiquetar, revisar, hacer excepciones ni fusionar.

Reglas Estrictas

  • La evidencia de Revisión y Día del Juicio es solo para revisión. Pi nunca acuña autoridad de entrega: los commits, pushes, PRs y releases ordinarios siempre siguen la política del repositorio, independientemente del modo RDD.
  • Requerir un issue aprobado (status:approved) y una reproducción limpia en main actual antes de la implementación. Auditar los PRs existentes para detectar sustitución o conflicto; detener o reducir reclamaciones obsoletas.
  • Agrupar por invariante de autoridad causal. Usar un issue y un PR o cadena explícita por invariante independiente y límite de reversión. Separar causas independientes; nunca fusionar una línea de autoridad sustituida o en conflicto.
  • Inventariar cada flujo de operador reclamado por el issue o PR, incluyendo entrada, modo, entorno, expectativa y controles negativos. Requerir un recorrido de banco de pruebas de caja negra veraz por flujo CLI o de ciclo de vida, o una prueba E2E real de tiempo de ejecución cuando el banco central no pueda representarlo. La cobertura sintética mediante proxies nunca prueba otro tiempo de ejecución.
  • Usar mapeo de impacto basado en CodeGraph primero, un worktree dedicado y pruebas basadas en comportamiento. Ejecutar normalización que modifique la fuente antes de congelar el candidato.
  • Pronosticar los cambios a realizar antes de las ediciones. El límite estricto es 400 adiciones más eliminaciones; por encima de eso, DETENERSE para una cadena o una excepción explícita aprobada por el mantenedor.
  • Cuando RDD esté habilitado, vincular los recibos de revisión, el linaje, la corrección y la evidencia de recuperación al candidato exacto. Mantener los defectos de revisión acotados en una sola transacción de corrección; nunca tratar esa evidencia como autoridad de entrega.
  • Requerir validación independiente de solo lectura del candidato antes de la publicación. La validación no puede editar la fuente ni la autoridad; los hallazgos requieren un nuevo candidato.
  • Mantener la comunicación humana y basada en evidencia. Las etiquetas del repositorio y los metadatos del flujo de trabajo son propiedad del mantenedor, nunca evidencia de culpa del contribuyente.

Compuertas de Decisión

CondiciónAcción
Cualquier modo RDDLa evidencia de revisión sigue siendo solo para revisión; los commits, pushes, PRs y releases ordinarios siguen la política del repositorio sin autoridad de entrega de Pi.
La compuerta del issue o la reproducción fallaEsperar, detener o reducir con evidencia.
El invariante o la reversión son independientesSeparar el issue y la línea de PR con autoridad.
El banco central encaja / no encajaRecorrido de banco / E2E real de tiempo de ejecución; nunca proxy.
El pronóstico supera las 400 líneasCadena o excepción aprobada antes de las ediciones.

Pasos de Ejecución

  1. Verificar modo, aprobación, conflictos de PR y reproducción en main actual.
  2. Nombrar invariante y reversión; aislar el worktree; mapear con CodeGraph código, pruebas, evidencia, documentación, distribución y registro.
  3. Inventariar flujos y controles; agregar pruebas fallidas y la corrección más pequeña.
  4. Normalizar, cumplir con el presupuesto, ejecutar pruebas y registrar el candidato exacto, comando, escenario y resultado de cada flujo.
  5. Congelar, validar en modo solo lectura y dar el veredicto, la evidencia y una próxima acción humana.

Contrato de Salida

Devolver rdd_mode, issue_pr, causal_invariant, operator_flows, journey_runtime_evidence, changed_line_budget, tests, rollback y unresolved_authority_decisions.

Identificar líneas de autoridad aprobadas y sustituidas/en conflicto; cada flujo, control negativo y prueba vinculada al candidato; adiciones más eliminaciones y cadena/excepción; resultados de pruebas; reversión independiente; y decisiones de mantenedor no resueltas.

Referencias

No hay archivos de soporte. La política actual del repositorio sigue siendo autoritativa.

Individual skills in this repo

This repo contains 7 individual skills — each has its own dedicated page.

Skills relacionados