# Memory - Roadmap de maturidade do sdd-layer

## Rastreabilidade
- Orquestração: `roadmap-de-maturidade-do-sdd-layer-gate-unico-de-release-corrigir-jest-do-bot-modul-960734c3de8d`
- Stage: memory
- Estado: recorded.
- Fontes: `01-idea.md`, `02-prd.md`, `03-techspec.md`, `04-tasks.md`, `05-refinement.md`, `06-execution.md`, `06-adr.md`, `07-review.md`.

## Estado final
O projeto agora tem um gate único de release em `sdd ci --strict-release` e uma visão rápida por área em `sdd maintenance report`. O CI principal usa `target/release/sdd ci --strict-release --name <slug-da-entrega>` depois de instalar dependências de bot e docs.

## Funcionalidades implementadas
- `sdd ci --strict-release`: agrega fmt, clippy all-targets/all-features, tests locked/all-features, `sdd health --strict`, workflow, clients, capabilities, skills, bot build/test, docs generate/links/build e advisory checks.
- `sdd ci --strict-release --json --dry-run`: contrato estável para testar/plugar automação sem executar comandos caros.
- `sdd health --strict`: transforma `warn` em falha.
- `sdd ci --strict-release --name <slug>`: filtra sinais da orquestração alvo e inclui validações contextuais como diagram doctor.
- `sdd maintenance report`: Markdown/JSON por área.
- `block_gate`: timeout HTTP de 10s, retry seguro para GET em timeout/conexão/429/5xx, classificação de status e redaction de tokens GitHub.
- Bot Jira/GitHub: helper HTTP comum com timeout, classificação, retry seguro para leituras e redaction; webhook GitHub retorna `413 payload_too_large`.
- Supply chain do bot: `npm audit --audit-level=high` limpo após remover dependências locais não usadas e aplicar fix transitive.

## Arquitetura atual
- O gate e o maintenance report ainda estão em `src/main.rs`.
- A decisão registrada em `06-adr.md` recomenda extrair `commands/release` ou `commands/maintenance` em uma próxima fatia.
- Advisory checks são não bloqueantes por desenho.
- `maintenance report` é rápido e marca checks caros não executados como `skipped`.

## Decisões
- Estender `sdd ci` antes de criar `sdd release gate`.
- Usar `maintenance report` como leitura derivada, não como nova fonte de verdade.
- Gate strict/release sempre roda health estrito; release por orquestração adiciona escopo e diagram doctor com `--name`.
- Advisory checks aparecem como `warn/skipped`, não como falha obrigatória.

## Padrões úteis
- Para comandos novos de release, manter dry-run JSON testável.
- Para checks caros, capturar saída e resumir sem despejar log integral.
- Para HTTP externo, usar timeout curto, retry apenas em leitura e redaction antes de propagar body.

## Testes e comandos
```bash
sdd ci --strict-release
sdd ci --strict-release --json --dry-run
sdd ci --strict-release --name "<slug>"
sdd maintenance report --json
target/release/sdd ci --strict-release
```

## Variáveis de ambiente
- `GITHUB_TOKEN` ou `GH_TOKEN`: token GitHub para `block_gate`.
- Config GitHub App continua em `github.auth.app_id`, `installation_id`, `private_key_env` ou `private_key_path`.
- `GITHUB_WEBHOOK_SECRET`: segredo do webhook do bot.

## Testes
- Focados novos: `health_strict_fails_on_warning_status`, `ci_strict_release_dry_run_json_reports_gate_matrix`, `maintenance_report_json_covers_expected_areas`.
- `block_gate` cobre parsing GitHub, link pagination, classificação de status, retry por status e redaction.
- Bot HTTP cobre sucesso, 401/404, 429/5xx, timeout e body com segredo via mock server.
- Gate real executado: `target/release/sdd ci --strict-release`, com obrigatórios `pass` e advisory `warn` apenas por ferramentas opcionais ausentes.

## Pendências
- Instalar/rodar `cargo-audit`, `cargo-deny` e `gitleaks` em CI advisory.
- Modularizar `src/main.rs` por comandos.
- Expandir golden/property tests de artefatos SDD e rastreabilidade.

## Próximos passos
1. Extrair gate/report para módulo dedicado mantendo formatos JSON/Markdown.
2. Criar corpus golden mínimo de PRD, Tech Spec, Tasks e traceability map.
3. Instalar ou rodar `cargo-audit`, `cargo-deny` e `gitleaks` em ambiente advisory.
4. Planejar a separação fina do TUI em estado, adapters, rendering, execução, persistência e telemetria.

## Contexto para o próximo agente
A execução entregou a camada de release/readiness que faltava para a nova base. O projeto saiu de uma validação espalhada para um contrato único, com visibilidade por área, advisory checks explícitos e bot GitHub mais resiliente. A maturidade subiu, mas o próximo ganho estrutural depende de modularização e corpus de precisão.
