Contrato de Ativação
Carregar quando os termos de gatilho do frontmatter se aplicam a um fluxo de trabalho de defeito.
Esta skill orienta a colaboração pública. Ela não concede aprovação de issue, etiqueta, revisão, exceção ou autoridade de merge.
Regras rígidas
- Evidências de Revisão e Dia do Julgamento são apenas para revisão. Pi nunca cunha autoridade de entrega: commit, push, PR e release comuns sempre seguem a política do repositório, independentemente do modo RDD.
- Exigir uma issue aprovada (
status:approved) e uma reprodução limpa namainatual antes da implementação. Auditar PRs existentes para substituição ou conflito; parar ou restringir alegações obsoletas. - Agrupar por invariante de autoridade causal. Usar uma issue e um PR ou cadeia explícita por invariante independente e limite de rollback. Separar causas independentes; nunca mesclar uma linha de autoridade substituída ou conflitante.
- Inventariar cada fluxo de operador reivindicado pela issue ou PR, incluindo entrada, modo, ambiente, expectativa e controles negativos. Exigir uma jornada de bench black-box verdadeira por fluxo CLI ou de ciclo de vida, ou prova E2E de runtime real quando o bench principal não puder representá-la. Cobertura de proxy sintético nunca prova outro runtime.
- Usar mapeamento de impacto CodeGraph-first, uma worktree dedicada e testes behavior-first. Executar normalização que modifica a fonte antes do congelamento do candidato.
- Prever mudanças autoradas antes das edições. O limite rígido é 400 adições mais deleções; acima disso, PARAR para uma cadeia ou exceção explícita aprovada pelo mantenedor.
- Quando RDD está habilitado, vincular recibos de revisão, linhagem, correção e evidências de recuperação ao candidato exato. Manter defeitos de revisão limitados em uma única transação de correção; nunca tratar essa evidência como autoridade de entrega.
- Exigir validação de candidato independente somente leitura antes da publicação. Validação não pode editar fonte ou autoridade; descobertas exigem um novo candidato.
- Manter a comunicação humana e baseada em evidências. Etiquetas de repositório e metadados de workflow são de propriedade do mantenedor, nunca evidência de culpa do colaborador.
Portões de Decisão
| Condição | Ação |
|---|---|
| Qualquer modo RDD | Evidências de revisão permanecem apenas para revisão; commit, push, PR e release comuns seguem a política do repositório sem autoridade de entrega Pi. |
| Portão de issue ou reprodução falha | Aguardar, parar ou restringir com evidências. |
| Invariante ou rollback é independente | Linha separada de issue e PR autoritativa. |
| Bench principal se encaixa / não se encaixa | Jornada de bench / E2E de runtime real; nunca proxy. |
| Previsão excede 400 linhas | Cadeia ou exceção aprovada antes das edições. |
Etapas de Execução
- Verificar modo, aprovação, conflitos de PR e reprodução na main atual.
- Nomear invariante e rollback; isolar a worktree; mapear código, testes, evidências, documentação, distribuição e registro com CodeGraph.
- Inventariar fluxos e controles; adicionar testes com falha e a menor correção.
- Normalizar, aplicar orçamento, executar testes e registrar o candidato exato, comando, cenário e resultado de cada fluxo.
- Congelar, validar somente leitura e fornecer o veredito, evidências e uma próxima ação humana.
Contrato de Saída
Retornar rdd_mode, issue_pr, causal_invariant, operator_flows, journey_runtime_evidence, changed_line_budget, tests, rollback e unresolved_authority_decisions.
Identificar linhas de autoridade aprovadas e substituídas/conflitantes; cada fluxo, controle negativo e prova vinculada ao candidato; adições mais deleções e cadeia/exceção; resultados de teste; rollback independente; e decisões não resolvidas do mantenedor.
Referências
Nenhum arquivo de suporte. A política atual do repositório permanece autoritativa.