# ADR - Gate de release e maintenance report

## Rastreabilidade
- Orquestração: `roadmap-de-maturidade-do-sdd-layer-gate-unico-de-release-corrigir-jest-do-bot-modul-960734c3de8d`
- Stage: adr
- Estado: recorded.
- Origem: `06-execution.md`.
- Decisão registrada em: `2026-07-04`.

## Status
Aceita.

## Contexto
A base nova já continha mudanças amplas em bot GitHub, diagramas, artifact links, TUI e `block_gate`, mas ainda faltava um contrato único que representasse readiness de release. Antes desta execução, `sdd ci` validava smoke checks locais, mas não cobria bot, docs, clippy all-features, health, skills/capabilities e advisory checks em uma única matriz.

## Problema
Sem um gate único, a validação local, o CI e a documentação podiam divergir. Além disso, o projeto não tinha uma leitura rápida por área para entender drift sem rodar todos os builds caros.

## Decisão
Estender `sdd ci` com `--strict-release` em vez de criar um comando separado de release neste ciclo. Criar `sdd maintenance report` como comando derivado e rápido, reutilizando `health_report` e adicionando áreas operacionais.

Também foi decidido:
- `sdd health --strict` falha em `warn`.
- `sdd ci --strict-release` sempre usa `sdd health --strict --json`.
- `sdd ci --strict-release --name <slug>` adiciona escopo da orquestração e validações contextuais, como diagram doctor.
- Advisory checks aparecem na matriz como `warn` ou `skipped`, mas não bloqueiam o gate obrigatório.

## Alternativas consideradas
- Criar `sdd release gate`: adiado para evitar nova superfície antes de estabilizar `sdd ci`.
- Manter documentação com lista manual de comandos: rejeitado porque manteria divergência local/CI.
- Tornar advisory bloqueante: rejeitado neste ciclo por dependências e ferramentas ainda ausentes.

## Consequências
- CI e validação local passam a compartilhar o mesmo contrato principal.
- `main.rs` cresceu mais; a próxima onda deve modularizar comandos de release/maintenance.
- Warnings de supply chain ficam visíveis sem impedir contribuição local.
- Releases por orquestração conseguem adicionar checks contextuais sem enfraquecer o health estrito global.

## Impactos e riscos
- `target/release/sdd ci --strict-release` é mais caro que o `sdd ci` legado.
- O output do gate captura stdout/stderr e trunca o resumo; falhas profundas ainda podem exigir rerodar o comando individual.
- Checks advisory podem continuar `skipped` quando ferramentas opcionais não estiverem instaladas.

## Plano de adoção
- Usar `target/release/sdd ci --strict-release` no workflow principal.
- Usar `sdd ci --strict-release --name <slug>` antes de fechar uma orquestração específica.
- Usar `sdd maintenance report --json` para dashboards, bots ou revisão rápida.

## Plano de reversão
- Remover `--strict-release` do workflow e voltar para `target/release/sdd ci`.
- Manter `sdd maintenance report` como leitura opcional mesmo se o gate for revertido.
- Como os comandos novos são aditivos, a reversão não exige migração de artefatos.

## Evidências
- `cargo test --locked --all-features ci_strict_release_dry_run_json_reports_gate_matrix` passou.
- `cargo test --locked --all-features maintenance_report_json_covers_expected_areas` passou.
- `target/release/sdd ci --strict-release` retornou exit code 0 com status agregado `warn` apenas em advisory por ferramentas opcionais ausentes.
- `npm audit --audit-level=high` no bot foi limpo após remoção de dependências locais não usadas e `npm audit fix`.

## Histórico de revisão
- 2026-07-04: decisão criada após Execution.
