# Tasks - 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: tasks
- Estado atual: recorded, gerado após aprovação humana da Tech Spec.
- Artefato anterior aprovado: `03-techspec.md`.
- Artefatos de base: `00-project-discovery.md`, `00-risk-classification.md`, `01-idea.md`, `02-prd.md`.
- Context Pack: `.sdd/intelligence/context-packs/roadmap-de-maturidade-do-sdd-layer-gate-unico-de-release-corrigir-jest-do-bot-modul-960734c3de8d/tasks.md`.
- Risco calibrado: `medium`; Refinement obrigatório antes de Execution.

## Backlog

### Épico E-01 - Estabilização da base atual

#### História H-01 - Baseline reproduzível da nova base
Como mantenedor do `sdd-layer`, quero saber quais checks da nova base estão realmente verdes ou vermelhos para executar o roadmap a partir de evidência atual, não de memória.

##### T-01 - Rodar baseline e corrigir falhas bloqueantes pequenas
- Objetivo: executar o bundle mínimo de validação da nova base e corrigir apenas falhas diretamente relacionadas ao roadmap que tenham baixo risco e correção local.
- Escopo: `cargo fmt`, clippy all-features, testes Rust, bot build/test, docs build/checks e doctors SDD.
- Fora do escopo: refatorar arquitetura, criar comandos novos, resolver falhas não relacionadas sem evidência.
- Arquivos prováveis: `src/domain/orchestrator/block_gate.rs`, `src/main.rs`, `src/tui/runner.rs`, `tests/cli.rs`, `bot/src/**`, `docs-site/**`, `.github/workflows/**`, `docs/IMPLEMENTACOES-RECENTES.md`.
- Validação: bundle descrito em `03-techspec.md`, registrando comandos executados e falhas restantes.

### Épico E-02 - Gate único de release

#### História H-02 - Gate obrigatório reproduzível
Como reviewer, quero um comando ou modo único que represente o release gate para reduzir divergência entre validação local, CI e docs.

##### T-02 - Implementar gate strict/release em cima de checks existentes
- Objetivo: expor uma entrada única para executar o gate obrigatório, preferencialmente estendendo `sdd ci` antes de criar subcomando novo.
- Escopo: Rust fmt, clippy, testes all-features, `sdd health --strict --json`, workflow/clients/capabilities/skills doctors, bot build/test, docs generate/links/build.
- Fora do escopo: checks advisory como bloqueantes por padrão.
- Arquivos prováveis: `src/main.rs`, possível `src/domain/maintenance.rs`, `.github/workflows/**`, `docs/QUALITY-OBSERVABILITY.md`, `docs/USAGE.md`, `tests/cli.rs`.
- Validação: teste CLI cobrindo sucesso/falha agregada e CI chamando o mesmo contrato documentado.

##### T-03 - Tornar checks advisory visíveis sem bloquear contributor local
- Objetivo: integrar `cargo audit`, `cargo deny`, `gitleaks`, `npm audit` e SBOM como advisory com status `pass`, `warn` ou `skipped`.
- Escopo: detecção de ferramenta ausente, saída estruturada, ação recomendada e documentação.
- Fora do escopo: exigir instalação local dessas ferramentas para o CLI básico.
- Arquivos prováveis: `src/main.rs`, `docs/QUALITY-OBSERVABILITY.md`, `docs/USAGE.md`, `.github/workflows/**`, `tests/cli.rs`.
- Validação: testes de ferramenta ausente retornando `skipped` e não `fail` no modo advisory.

### Épico E-03 - Bot GitHub e integrações externas

#### História H-03 - Bot GitHub estável em build, teste e webhook
Como operador do bot, quero GitHub Issues/Projects/PRs/Webhooks funcionando com testes determinísticos para não depender de ambiente real em CI.

##### T-04 - Hardening do GitHub provider e Jest do bot
- Objetivo: garantir `npm run build` e `npm test` verdes no bot com GitHub provider, webhook e config.
- Escopo: estabilizar mock de `execa`, decidir se `GitShell` é necessário, cobrir branch/PR, issue/comment, token/env/GitHub App e errors.
- Fora do escopo: chamada real à API GitHub no teste unitário.
- Arquivos prováveis: `bot/src/providers/github.ts`, `bot/src/providers/contracts.ts`, `bot/src/__tests__/githubProvider.test.ts`, `bot/src/config.ts`, `bot/package.json`, `bot/jest.config.*`.
- Validação: `cd bot && npm run build && npm test`.

##### T-05 - Validar webhook receiver e migration do provider GitHub
- Objetivo: fechar o contrato multi-superfície do webhook e da persistência/configuração GitHub.
- Escopo: assinatura HMAC, payload máximo, JSON inválido, dispatch de eventos, config example, migration `002_github_provider.sql`, docs do bot.
- Fora do escopo: servidor público, deploy, tunnel ou integração live com GitHub.
- Arquivos prováveis: `bot/src/providers/githubWebhook.ts`, `bot/src/providers/githubWebhookReceiver.ts`, `bot/src/__tests__/githubWebhook.test.ts`, `bot/src/db/migrations/002_github_provider.sql`, `bot/README.md`, `bot/sdd-bot.config.example.yaml`.
- Validação: testes unitários de webhook/migration/config e build do bot.

#### História H-04 - Block gate resiliente para Jira/GitHub
Como usuário da orquestração, quero que `/bloqueado` funcione em Jira e GitHub sem travar indefinidamente nem vazar segredo.

##### T-06 - Criar política HTTP comum e aplicar no `block_gate`
- Objetivo: adicionar timeout, retry seguro, rate-limit, classificação de erro e redaction para chamadas Jira/GitHub.
- Escopo: helper Rust compartilhado ou trait fake testável, timeout default de 10s, retry apenas leitura em timeout/5xx/429, sem retry em 401/403/404.
- Fora do escopo: reescrever todos os providers do bot em Rust.
- Arquivos prováveis: `src/runtime/http.rs`, `src/domain/orchestrator/block_gate.rs`, `Cargo.toml`, `tests/cli.rs`.
- Validação: testes cobrindo 401/403/404/429/5xx/timeout, body redigido e paginação `rel=last`.

### Épico E-04 - Observabilidade de maturidade

#### História H-05 - Maintenance report por área
Como mantenedor, quero um relatório rápido por área para enxergar drift e próximos comandos sem rodar sempre o gate completo.

##### T-07 - Implementar `sdd maintenance report`
- Objetivo: criar relatório Markdown/JSON por área reaproveitando `health_report`.
- Escopo: áreas `core Rust`, `docs`, `clients`, `bot`, `providers`, `intelligence`, `workflows`, `release`, `diagrams`; status `pass/warn/fail/skipped`; duração quando disponível; ação recomendada.
- Fora do escopo: executar builds caros por padrão.
- Arquivos prováveis: `src/main.rs`, `src/domain/maintenance.rs`, `tests/cli.rs`, `docs/QUALITY-OBSERVABILITY.md`, `docs/USAGE.md`.
- Validação: teste JSON estável, snapshot estrutural leve e execução manual do comando.

##### T-08 - Integrar rastreabilidade externa e diagramas ao report/gate
- Objetivo: validar `sdd artifact link` e `sdd diagram doctor` como parte da saúde de orquestrações quando aplicável.
- Escopo: links externos controlados, mutação segura de `traceability-map.yaml`, diagram doctor por slug, drift de comandos espelhados de clients.
- Fora do escopo: tornar companion visual obrigatório para toda orquestração.
- Arquivos prováveis: `src/main.rs`, `tests/cli.rs`, `clients/**`, `.claude/commands/diagram.md`, `.cursor/commands/diagram.md`, `.opencode/commands/diagram.md`, `.devin/workflows/diagram.md`, `.trae/commands/diagram.md`, `plugins/orchestration/commands/diagram.md`.
- Validação: testes CLI de `artifact link`, `diagram doctor` e doctors de clients/skills quando o contrato mudar.

### Épico E-05 - TUI e modularização incremental

#### História H-06 - Execução multi-provider segura no TUI
Como operador do TUI, quero saber quando um provider pode escrever no workspace e receber erro claro quando não pode.

##### T-09 - Endurecer readiness e trace de workspace execution no TUI
- Objetivo: validar e documentar o contrato de `DirectAdapter` para Codex, Claude, opencode, Cursor, Devin, Trae e Antigravity.
- Escopo: readiness por binário/configuração mínima, mensagens de login, trace/provenance/uso estimado, falha antes de mutar workspace para provider desconhecido.
- Fora do escopo: automatizar merge/deploy ou remover gates humanos.
- Arquivos prováveis: `src/tui/runner.rs`, possível `src/tui/adapters.rs`, `src/tui/persist.rs`, `tests/cli.rs`.
- Validação: testes unitários de command builder, capabilities, unsupported provider e gravação de relatório.

#### História H-07 - Modularização sem reescrita ampla
Como contribuidor, quero módulos menores no CLI/TUI sem perder comportamento público.

##### T-10 - Extrair primeira fatia de `src/main.rs`
- Objetivo: mover uma fatia real e testável de `src/main.rs` para módulo dedicado, priorizando `commands/artifacts` ou `commands/diagram`.
- Escopo: mover implementação, tipos auxiliares e testes relacionados; preservar assinatura pública CLI e outputs existentes.
- Fora do escopo: reorganizar todo `main.rs` em uma única PR.
- Arquivos prováveis: `src/main.rs`, `src/commands/artifacts.rs`, `src/commands/diagram.rs`, `tests/cli.rs`.
- Validação: `cargo fmt --check`, `cargo test --locked --all-features`, testes CLI específicos de artifact/diagram.

##### T-11 - Extrair primeira fatia do TUI
- Objetivo: separar readiness/adapters ou execution state do TUI sem alterar render/navegação.
- Escopo: mover structs/funções coesas, manter testes existentes, adicionar cobertura para a fatia extraída.
- Fora do escopo: redesenhar UI, trocar Ratatui ou reescrever `App`.
- Arquivos prováveis: `src/tui/runner.rs`, `src/tui/adapters.rs`, `src/tui/execution.rs`, `src/tui/state.rs`.
- Validação: testes unitários do TUI e `cargo test --locked --all-features`.

### Épico E-06 - Precisão de contratos SDD

#### História H-08 - Corpus determinístico de artefatos
Como mantenedor do SDD, quero detectar regressões de PRD, Tech Spec, Tasks e traceability antes que cheguem aos clients.

##### T-12 - Adicionar golden/property tests de artefatos e rastreabilidade
- Objetivo: criar corpus mínimo e testes determinísticos para artefatos SDD, external links, slug/stage/path e reports.
- Escopo: fixtures bons/ruins, golden estrutural, property tests leves sem dependência de provider.
- Fora do escopo: snapshot integral de copy longa ou avaliação semântica via LLM.
- Arquivos prováveis: `tests/cli.rs`, `tests/fixtures/golden/**`, `schemas/artifact-sections.json`, `src/domain/evaluation.rs`, `src/main.rs`.
- Validação: testes unitários/integração verdes e golden focado em estrutura.

## Dependências
- T-01 deve acontecer antes de qualquer task de implementação profunda.
- T-02 depende de T-01 para conhecer o estado real da base.
- T-03 depende de T-02 ou pode rodar em paralelo se o modelo de status do gate já estiver claro.
- T-04 e T-05 podem rodar em paralelo depois de T-01, mas ambas precisam fechar antes de declarar bot/GitHub maduro.
- T-06 depende de T-01 e deve considerar resultados de T-04/T-05 para manter semântica Jira/GitHub alinhada.
- T-07 depende de T-02 para reutilizar o modelo de status do gate.
- T-08 depende de `artifact link` e `diagram doctor` existentes na base e deve rodar antes de fechar release gate completo.
- T-09 depende de T-01 e deve preceder qualquer execution task real via TUI multi-provider.
- T-10 e T-11 dependem de T-01 e devem esperar estabilização do gate mínimo para reduzir risco de refactor.
- T-12 pode começar após T-02/T-08, quando os contratos de report, link e diagramas estiverem estáveis.

## Critérios de aceite
```gherkin
Funcionalidade: Baseline da nova base

  Cenário: Baseline registra o estado real dos checks
    Dado que o worktree contém mudanças em Rust, bot, docs, clients e TUI
    Quando a task T-01 executa o bundle mínimo de validação
    Então cada comando executado é registrado com status e evidência
    E falhas bloqueantes pequenas relacionadas ao roadmap são corrigidas ou explicitamente isoladas

Funcionalidade: Gate único de release

  Cenário: Falha obrigatória bloqueia release
    Dado que um check obrigatório como `cargo clippy` ou `bot npm test` falha
    Quando o gate strict/release é executado
    Então o comando retorna exit code diferente de zero
    E a saída identifica área, comando e próxima ação

  Cenário: Check advisory ausente não bloqueia contributor
    Dado que `cargo audit` ou `gitleaks` não está instalado
    Quando os checks advisory rodam
    Então o status da ferramenta é `skipped`
    E o gate obrigatório não falha apenas por essa ausência

Funcionalidade: GitHub provider e webhook do bot

  Cenário: Jest executa GitHub provider sem erro de ESM
    Dado que `execa` é mockado ou isolado atrás de adapter testável
    Quando `npm test` roda no diretório `bot/`
    Então os testes do GitHub provider passam
    E não ocorre erro `Cannot use import statement outside a module`

  Cenário: Webhook rejeita assinatura inválida
    Dado que um payload chega sem assinatura HMAC SHA-256 válida
    Quando o receiver recebe o POST
    Então responde 401
    E não despacha ação de domínio

Funcionalidade: Block gate Jira/GitHub resiliente

  Cenário: Rate-limit externo é classificado e redigido
    Dado que GitHub ou Jira retorna 429 com body sensível
    Quando o block gate consulta o último comentário
    Então o erro é classificado como `rate_limited`
    E o body exibido ou persistido está truncado e redigido

Funcionalidade: Maintenance report

  Cenário: Relatório mostra saúde por área
    Dado que existem checks obrigatórios, advisory e doctors SDD
    Quando `sdd maintenance report --json` é executado
    Então o JSON contém áreas de core Rust, docs, clients, bot, providers, intelligence, workflows, release e diagrams
    E cada área possui status, evidência e ação recomendada

Funcionalidade: TUI multi-provider

  Cenário: Provider desconhecido não edita workspace
    Dado que o provider selecionado não possui adapter direto
    Quando uma task de execution é disparada no TUI
    Então o TUI falha antes de iniciar shell de escrita
    E registra trace/provenance da falha

Funcionalidade: Modularização incremental

  Cenário: Extração preserva comportamento público
    Dado que uma fatia de CLI ou TUI foi movida para novo módulo
    Quando os testes all-features e doctors relevantes rodam
    Então comandos públicos e formatos JSON/Markdown permanecem compatíveis

Funcionalidade: Precisão de contratos

  Cenário: Golden test detecta regressão estrutural
    Dado que uma fixture de artefato SDD perde seção obrigatória
    Quando a suíte de golden/property tests roda
    Então a regressão falha com mensagem ligada ao contrato do artifact schema
```

## Definition of Done
- Tech Spec aprovada está registrada como `approved` no artifact store.
- Cada task executada tem relatório próprio com comandos, arquivos alterados, decisões e pendências.
- Nenhuma task reverte mudanças locais não relacionadas.
- O gate obrigatório documentado roda localmente e no CI com o mesmo contrato.
- Bot build/test, docs build/checks e Rust all-features entram no caminho de release.
- Checks advisory aparecem como `warn` ou `skipped` sem bloquear o contributor local no primeiro ciclo.
- Segurança de tokens, private keys e payloads externos é validada por testes ou revisão explícita.
- Refinement foi executado antes de Execution por risco `medium`.

## Estratégia de testes
- Começar cada task com teste/diagnóstico reproduzível que falhe ou capture o comportamento atual.
- Preferir testes de contrato em `tests/cli.rs` para comandos SDD e formatos JSON/Markdown.
- No bot, usar mocks de `axios`, `execa` ou adapter de shell; não chamar GitHub real em teste unitário.
- Para HTTP externo Rust, usar trait fake ou mock server local com cenários 401/403/404/429/5xx/timeout.
- Para TUI, testar command builders, capabilities, readiness e persistência sem depender de terminal real.
- Para golden/property tests, validar estrutura e campos críticos em vez de copy longa.
- Bundle mínimo esperado após fatias relevantes:

```bash
cargo fmt --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --locked --all-features
sdd health --strict --json
sdd workflow validate agentic-sdd-loop --json
sdd clients doctor --strict --json
sdd capabilities doctor --targets all --json
sdd skills doctor --strict --json
cd bot && npm run build && npm test
cd docs-site && npm run docs:generate -- --check && npm run docs:links && npm run build
```

## Ordem sugerida
1. T-01 - Rodar baseline e corrigir falhas bloqueantes pequenas.
2. T-04 - Hardening do GitHub provider e Jest do bot.
3. T-05 - Validar webhook receiver e migration do provider GitHub.
4. T-02 - Implementar gate strict/release em cima de checks existentes.
5. T-03 - Tornar checks advisory visíveis sem bloquear contributor local.
6. T-06 - Criar política HTTP comum e aplicar no `block_gate`.
7. T-08 - Integrar rastreabilidade externa e diagramas ao report/gate.
8. T-07 - Implementar `sdd maintenance report`.
9. T-09 - Endurecer readiness e trace de workspace execution no TUI.
10. T-10 - Extrair primeira fatia de `src/main.rs`.
11. T-11 - Extrair primeira fatia do TUI.
12. T-12 - Adicionar golden/property tests de artefatos e rastreabilidade.

## Prompts Agent

### Prompt T-01 - Rodar baseline e corrigir falhas bloqueantes pequenas
Task ID: T-01. Origem: `02-prd.md`, `03-techspec.md`, este `04-tasks.md` e diagramas da Tech Spec. Objetivo verificável: produzir baseline atual da nova base e corrigir apenas falhas pequenas diretamente ligadas ao roadmap. In scope: executar `cargo fmt --check`, `cargo clippy --all-targets --all-features -- -D warnings`, `cargo test --locked --all-features`, `sdd health --strict --json`, doctors SDD, bot build/test e docs checks; corrigir formatação, clippy simples, Jest/config ou docs drift quando a causa for local e clara. Out of scope: refactor amplo, comandos novos, reverter mudanças não relacionadas. Arquivos prováveis: `src/domain/orchestrator/block_gate.rs`, `src/main.rs`, `src/tui/runner.rs`, `tests/cli.rs`, `bot/src/**`, `docs-site/**`, docs de qualidade. Passos: mapear status do worktree, rodar comandos, corrigir falhas pequenas, rerodar comando afetado, registrar pendências. Validação: todos os comandos possíveis executados ou justificativa objetiva para os não executados. Definition of Done: relatório com status por comando, diffs limitados e próximos riscos.

### Prompt T-02 - Implementar gate strict/release em cima de checks existentes
Task ID: T-02. Origem: PRD RF-01, Tech Spec `Release gate`, Tasks E-02. Objetivo verificável: disponibilizar um gate único local/CI para checks obrigatórios. In scope: estender `sdd ci` com modo strict/release ou criar comando separado apenas se necessário; agregar Rust, SDD doctors, bot e docs; retornar exit code correto. Out of scope: checks advisory como bloqueantes. Arquivos prováveis: `src/main.rs`, `src/domain/maintenance.rs`, `.github/workflows/**`, `tests/cli.rs`, `docs/QUALITY-OBSERVABILITY.md`, `docs/USAGE.md`. Passos: identificar `run_ci`, desenhar estrutura de status, implementar comando, adicionar testes CLI, alinhar docs/CI. Validação: teste de sucesso/falha agregada e execução manual do comando. Definition of Done: gate reproduzível, documentado e chamável por CI.

### Prompt T-03 - Tornar checks advisory visíveis sem bloquear contributor local
Task ID: T-03. Origem: PRD RF-07, Tech Spec `Segurança`, Tasks E-02. Objetivo verificável: checks opcionais aparecem como advisory com `pass/warn/skipped`. In scope: detecção de `cargo audit`, `cargo deny`, `gitleaks`, `npm audit` e SBOM; saída estruturada; docs. Out of scope: exigir instalação local ou falhar release por ausência no primeiro ciclo. Arquivos prováveis: `src/main.rs`, `src/domain/maintenance.rs`, `tests/cli.rs`, docs de qualidade/uso. Passos: definir shape advisory, implementar execução segura, simular ferramenta ausente em teste, documentar. Validação: teste de `skipped` quando ferramenta não existe e `warn` quando comando retorna risco advisory. Definition of Done: advisory visível e não bloqueante por padrão.

### Prompt T-04 - Hardening do GitHub provider e Jest do bot
Task ID: T-04. Origem: PRD RF-02, Tech Spec `Bot GitHub`, Tasks H-03. Objetivo verificável: `cd bot && npm run build && npm test` verde com GitHub provider. In scope: estabilizar mock/adapter de `execa`, cobrir GitHub issue/comment/project/branch/PR e auth token/env/App sem rede real. Out of scope: integração live com GitHub. Arquivos prováveis: `bot/src/providers/github.ts`, `bot/src/providers/contracts.ts`, `bot/src/__tests__/githubProvider.test.ts`, `bot/package.json`, config Jest/TS. Passos: rodar build/test, diagnosticar ESM/Jest, escolher mock ou `GitShell`, adicionar testes faltantes, rerodar. Validação: build e Jest verdes. Definition of Done: provider GitHub testável e sem falha ESM.

### Prompt T-05 - Validar webhook receiver e migration do provider GitHub
Task ID: T-05. Origem: Tech Spec `Bot GitHub`, Tasks H-03. Objetivo verificável: webhook receiver e migration GitHub têm cobertura de contrato. In scope: HMAC, payload máximo, JSON inválido, dispatch de eventos, config example, migration SQLite. Out of scope: deploy do receiver. Arquivos prováveis: `bot/src/providers/githubWebhook.ts`, `bot/src/providers/githubWebhookReceiver.ts`, `bot/src/__tests__/githubWebhook.test.ts`, `bot/src/db/migrations/002_github_provider.sql`, `bot/README.md`, `bot/sdd-bot.config.example.yaml`. Passos: revisar contratos, adicionar testes de negativos, validar migration/config, atualizar docs. Validação: `npm test` e `npm run build` no bot. Definition of Done: webhook rejeita entradas inválidas e documenta operação local.

### Prompt T-06 - Criar política HTTP comum e aplicar no `block_gate`
Task ID: T-06. Origem: PRD RF-05, Tech Spec `HTTP externo`, Tasks H-04. Objetivo verificável: Jira/GitHub no `block_gate` têm timeout, retry seguro, rate-limit e redaction testados. In scope: helper Rust ou trait fake, timeout 10s, retry para leitura em timeout/5xx/429, sem retry em 401/403/404, erro classificado. Out of scope: reescrever bot TS. Arquivos prováveis: `src/runtime/http.rs`, `src/domain/orchestrator/block_gate.rs`, `Cargo.toml`, `tests/cli.rs`. Passos: extrair política, aplicar no Jira/GitHub, adicionar testes de status e redaction, rodar Rust all-features. Validação: testes negativos e `cargo test --locked --all-features`. Definition of Done: falhas externas previsíveis e seguras.

### Prompt T-07 - Implementar `sdd maintenance report`
Task ID: T-07. Origem: PRD RF-08, Tech Spec `Maintenance report`, Tasks E-04. Objetivo verificável: `sdd maintenance report` gera Markdown e JSON por área. In scope: reutilizar `health_report`, adicionar áreas bot/docs/release/diagrams/advisory, status `pass/warn/fail/skipped`. Out of scope: rodar builds caros no modo rápido padrão. Arquivos prováveis: `src/main.rs`, `src/domain/maintenance.rs`, `tests/cli.rs`, `docs/QUALITY-OBSERVABILITY.md`. Passos: modelar área/status, implementar coletores rápidos, adicionar JSON, documentar. Validação: teste CLI do JSON e execução manual. Definition of Done: relatório útil sem duplicar fonte de verdade.

### Prompt T-08 - Integrar rastreabilidade externa e diagramas ao report/gate
Task ID: T-08. Origem: Tech Spec `Artifact link` e `Diagramas`, Tasks E-04. Objetivo verificável: `artifact link` e `diagram doctor` são cobertos por testes e entram no report/gate quando aplicável. In scope: links externos controlados, preservação de YAML válida, diagram doctor por slug, drift de comandos espelhados. Out of scope: exigir companion visual em toda feature. Arquivos prováveis: `src/main.rs`, `tests/cli.rs`, `clients/**`, `.claude/commands/diagram.md`, `.cursor/commands/diagram.md`, `.opencode/commands/diagram.md`, `.devin/workflows/diagram.md`, `.trae/commands/diagram.md`, `plugins/orchestration/commands/diagram.md`. Passos: adicionar testes de link/diagram, integrar ao report/gate, rodar doctors de clients/skills. Validação: testes CLI e doctors strict quando contrato mudar. Definition of Done: rastreabilidade externa e diagramas auditáveis.

### Prompt T-09 - Endurecer readiness e trace de workspace execution no TUI
Task ID: T-09. Origem: Tech Spec `TUI workspace execution`, Tasks H-06. Objetivo verificável: adapters diretos do TUI têm readiness e trace seguros. In scope: Codex, Claude, opencode, Cursor, Devin, Trae, Antigravity; login command; provider desconhecido; provenance; relatório da task. Out of scope: merge/deploy automático. Arquivos prováveis: `src/tui/runner.rs`, `src/tui/adapters.rs`, `src/tui/persist.rs`, testes Rust. Passos: revisar `DirectAdapter`, adicionar readiness testável, melhorar mensagens de falha, cobrir command builders. Validação: testes unitários e `cargo test --locked --all-features`. Definition of Done: provider sem adapter não escreve workspace e falhas ficam rastreáveis.

### Prompt T-10 - Extrair primeira fatia de `src/main.rs`
Task ID: T-10. Origem: PRD RF-03, Tech Spec `Boundaries propostos`, Tasks H-07. Objetivo verificável: uma fatia real de `src/main.rs` sai para módulo dedicado sem mudar comportamento público. In scope: escolher `commands/artifacts` ou `commands/diagram`, mover implementação e testes próximos. Out of scope: reorganizar todo o CLI. Arquivos prováveis: `src/main.rs`, `src/commands/artifacts.rs`, `src/commands/diagram.rs`, `tests/cli.rs`. Passos: mapear funções/tipos, mover uma fatia, ajustar imports, rodar testes. Validação: `cargo fmt --check` e `cargo test --locked --all-features`. Definition of Done: diff pequeno, comportamento preservado e main menor.

### Prompt T-11 - Extrair primeira fatia do TUI
Task ID: T-11. Origem: PRD RF-04, Tech Spec `Boundaries propostos`, Tasks H-07. Objetivo verificável: readiness/adapters ou execution state do TUI ficam em módulo próprio com testes. In scope: mover structs/funções coesas, manter render e navegação, adicionar cobertura. Out of scope: redesenhar UI ou trocar Ratatui. Arquivos prováveis: `src/tui/runner.rs`, `src/tui/adapters.rs`, `src/tui/execution.rs`, `src/tui/state.rs`. Passos: escolher menor fatia, mover, manter API interna, rodar testes. Validação: testes TUI e Rust all-features. Definition of Done: menor acoplamento sem regressão visível.

### Prompt T-12 - Adicionar golden/property tests de artefatos e rastreabilidade
Task ID: T-12. Origem: PRD RF-06, Tech Spec `Precisão de contratos`, Tasks E-06. Objetivo verificável: corpus mínimo detecta regressões estruturais de artefatos SDD e rastreabilidade. In scope: fixtures bons/ruins para PRD, Tech Spec, Tasks, traceability map, maintenance report e diagramas; property tests leves para slug/stage/path/external links. Out of scope: avaliação via LLM ou snapshots longos de copy. Arquivos prováveis: `tests/fixtures/golden/**`, `tests/cli.rs`, `schemas/artifact-sections.json`, `src/domain/evaluation.rs`, `src/main.rs`. Passos: criar fixtures mínimas, adicionar testes estruturais, rodar suíte. Validação: `cargo test --locked --all-features`. Definition of Done: regressões de contrato falham de forma determinística.
