govern-architecture

name	govern-architecture
description	Orquestra o ciclo completo de governança no Architecture Graph, coordenando descoberta, Tech Radar, ADR, Guidelines, Guardrails e Fitness Functions. Use quando o usuário pedir para analisar um repositório, completar lacunas do grafo ou medir aptidão arquitetural sem contornar checkpoints humanos.

Govern Architecture

Conduzir o fluxo integrado sem fundir responsabilidades das skills especializadas. Ler references/checkpoints.md antes de iniciar.

Fluxo

1. Localizar o repositório central por architecture.yaml.
2. Se não existir, usar initialize-architecture, confirmar o destino e validar.
3. Depois da inicialização, informar o próximo passo e aguardar confirmação explícita antes de analisar qualquer repositório.
4. Usar tech-radar para atualizar fatos e preparar recomendações para todos os blips ativos sem preencher anéis oficiais.
5. Apresentar o conjunto completo de recomendações, com confiança, evidências e lacunas, e aguardar o usuário escolher o que deseja revisar. Não sugerir, priorizar ou iniciar silenciosamente nenhum blip.
6. Para o blip escolhido pelo usuário, obter a decisão humana antes de criar ADR ou aplicar postura no Radar.
7. Usar suggest-guidelines para investigar código, Radar e ADRs existentes.
8. Para cada candidato, avaliar prontidão e apresentar lacunas ao usuário.
9. Se faltar blip, retornar a tech-radar; não inventar referência.
10. Se faltar decisão, usar write-adr e obter ratificação humana.
11. Registrar aprovação, rejeição ou pedido de complementação do candidato.
12. Usar write-guardrail para provar o check determinístico.
13. Somente após aprovação e check verde, usar write-guideline para promover o bundle.
14. Quando houver objetivo mensurável, usar write-fitness-function para definir métrica, threshold e executor determinístico com aprovação humana.
15. Executar medições, projetar tendência e regenerar o grafo.

Regras de coordenação

• Nunca tomar decisão arquitetural em nome do usuário.
• Parar em cada checkpoint descrito na referência.
• Reaproveitar blips e ADRs existentes quando semanticamente adequados.
• Não criar artefatos apenas para eliminar alertas.
• Preservar descoberta pendente quando o lastro ainda não existe.
• Não expor comandos internos ao participante do bootcamp.
• Não escolher silenciosamente o local da fonte central na primeira execução.
• Não tratar permissões técnicas do host como aprovação de uma etapa do bootcamp.
• Não apresentar recomendações parciais como se fossem o resultado da análise.
• Depois da visão completa do Radar, aguardar a escolha do usuário sem sugerir um blip.
• Manter resultados no repositório de arquitetura indicado pelo usuário; para ensaios e avaliações, usar diretório temporário fora do plugin.

Resultado

Apresentar a cadeia concluída como referências navegáveis:

repository → blip → ADR → guideline-candidate → guideline → guardrail

Quando houver medição: ADR → architecture-objective ← fitness-function → repository.

Separar decisões concluídas, hipóteses pendentes e próximos checkpoints.