| name | diligence/repair |
| description | Execute corrections identified by Flag — update OBCs, create missing Work Items, close orphaned ones. Never touches product code or creates implementation PRs. |
DILIGENCE ASYNC → REPAIR
Execute only the Repair step of the Diligence Async flow.
Responsabilidade: executar as correções identificadas pelo Flag, restaurando a consistência entre artefatos canônicos e ferramentas externas. Repair nunca modifica código de produto e nunca cria Pull Requests de implementação.
Ação
1. Ler a lista de itens pendentes do Flag
Obter os itens classificados como reparáveis pela Diligence. Ignorar itens com status BLOQUEADO — esses pertencem a outras jornadas.
2. Executar reparos em ordem de severidade
Para cada item, aplicar a ação corretora correspondente:
Work Item ausente: executar step Attach para o OBC afetado.
→ prodops/skills/diligence/diligence-sync/steps/attach/SKILL.md
Issue com labels canônicas fora do projeto gerenciado:
gh project item-add <project-number> \
--owner <owner> \
--url https://github.com/<owner>/<repo>/issues/<issue-number>
Verificar membership após adição:
gh project item-list <project-number> --owner <owner> --format json \
| jq '.items[] | select(.content.number == <issue-number>) | .id'
Se o projeto gerenciado não existir: registrar bloqueio — escalar para Workspace
Reconciliation antes de continuar.
Work Item aberto com OBC Operational: executar step Close para o OBC afetado.
→ prodops/skills/diligence/diligence-sync/steps/close/SKILL.md
OBC absent do Iteration Plan com pré-requisitos satisfeitos: executar step Promote para o OBC afetado.
→ prodops/skills/diligence/diligence-sync/steps/promote/SKILL.md
Artefato de gestão desatualizado (Iteration Plan, Roadmap, Product Backlog): atualizar o artefato diretamente, registrando a data e a decisão que originou a mudança.
OBC sem estado canônico correto: executar step Capture para o OBC afetado.
→ prodops/skills/diligence/diligence-sync/steps/capture/SKILL.md
3. Parar em itens que exigem decisão de produto
Quando um reparo não pode ser executado sem uma decisão de produto:
- Registrar o bloqueio com o OBC afetado, o gap e a jornada responsável
- Não inventar a decisão
- Escalar para Assessment ou Discovery conforme o tipo de gap
4. Commit por grupo de reparos
git add prodops/artifacts/obcs/
git add prodops/artifacts/plans/
git commit -m "docs(diligence): repair divergences from async scan"
5. Registrar resultado
Para cada item reparado: OBC afetado, ação executada, data.
Para cada item não reparado: motivo e jornada responsável.
Post-conditions
Concluído quando:
- Todos os itens reparáveis foram corrigidos ou tiveram o bloqueio explicitamente registrado
- Nenhum código de produto foi modificado
- Nenhum Pull Request de implementação foi criado
Guardrails
- Nunca modificar código de produto — escopo é exclusivamente artefatos ProdOps e backlogs.
- Nunca criar Pull Requests de implementação.
- Parar e escalar itens que exigem decisão de produto antes de reparar.
- Não silenciar falhas de reparo — registrar explicitamente o que não pôde ser corrigido e por quê.
Out of scope
repair não implementa funcionalidades — nunca.repair não resolve divergências que exigem decisão de Assessment ou Discovery.repair não substitui a execução de Downstream readiness para itens bloqueados por artefatos ausentes de Delivery.
