# Classificação de Risco — SDDL-2: SDD Bot do Slack

- **Orquestração:** SDDL-2
- **Data:** 2026-06-24
- **Classificado por:** risk-classifier (subagent)
- **Origem:** Descrição do card Jira SDDL-2 + `sdd.config.yaml` + `bot/sdd-bot.config.example.yaml`

---

## Classificação de Risco

### Nível: ALTO

---

### Fatores de Risco

| Dimensão | Evidência | Peso |
|---|---|---|
| **Segredos e tokens sensíveis** | Bot token (`xoxb-...`) e App token (`xapp-...`) do Slack, API token do Jira e API key de LLM gerenciados em arquivo de config; risco de vazamento via git se `.gitignore` falhar | Critico |
| **Dependências externas múltiplas** | Slack API (Socket Mode + OAuth), Jira REST API, Bitbucket API, provider LLM — quatro sistemas externos com contratos independentes e potencial de breaking change | Alto |
| **Webhooks/Socket públicos** | Socket Mode do Slack expõe endpoint de eventos; qualquer falha de validação de payload abre superfície para injeção de comandos arbitrários no orquestrador SDD | Alto |
| **Mudança estrutural no SDD** | Remoção de amarrações do bot nos comandos existentes (`sdd install`, `sdd orchestrator`) afeta o fluxo principal; risco de regressão no caminho crítico do produto | Alto |
| **Banco de dados local (SQLite)** | Novo contrato de dados persistido (`cards`, `status`, `contexto`) sem schema versionado nem estratégia de migração documentada | Médio |
| **Execução autônoma do orquestrador** | `/bot create` dispara `/orchestrator <CARD-ID>` sem intervenção humana até o PRD; mecanismo `/bloqueado` como gate operacional, mas implementado via comentário de texto — frágil e auditável com dificuldade | Alto |
| **Novo componente separado (brownfield)** | O projeto já tem infraestrutura Rust estabelecida; adicionar um daemon de bot (provavelmente async/tokio) em paralelo exige decisões de arquitetura não triviais sobre isolamento, processo e ciclo de vida | Médio |
| **Contexto brownfield** | `sdd.config.yaml` declara `lifecycle: brownfield`; o impacto de remover amarrações antigas do bot nos comandos existentes é incerto sem análise de chamadores | Alto |

**Gatilhos automáticos do `risk_policy` (sdd.config.yaml):**
- `external_dependency` — Slack, Jira, Bitbucket, LLM provider → exige Refinement
- `data_sensitive` — tokens/secrets e dados de cards → exige Refinement
- `security_sensitive` — webhook/socket público, injeção via Slack → exige Agent Team
- `cross_layer` — bot interage com CLI, orquestrador, artifact store e APIs externas → exige Agent Team
- `brownfield_unknowns` — remoção de amarrações existentes → exige Agent Team

---

### Refinement: OBRIGATÓRIO

A feature dispara quatro critérios do `require_refinement_for` definidos no `sdd.config.yaml` (`external_dependency`, `data_sensitive`). Adicionalmente, a incerteza brownfield relevante na remoção de código existente eleva o risco em um nível. O Refinement deve:

1. Auditar todos os pontos de código onde o bot está amarrado nos comandos atuais do SDD (`sdd install`, `sdd orchestrator`) e levantar o risco de regressão.
2. Definir estratégia de armazenamento seguro dos tokens (env vars, secret store ou arquivo fora do repositório com instrução clara no instalador).
3. Especificar schema SQLite versionado com estratégia de migração.
4. Validar o mecanismo `/bloqueado` — definir se é suficiente ou se requer campo de status estruturado no banco.
5. Revisar o contrato de comandos do Slack (parse, validação de payload, tratamento de erros) antes de implementação.

---

### Agent Teams

| Equipe | Responsabilidade |
|---|---|
| `security-reviewer` | Auditoria do fluxo de tokens/secrets, validação de payload Slack, superfície de injeção via texto livre no `/bot create` |
| `architecture-reviewer` | Decisão sobre processo/daemon do bot, isolamento do componente, ciclo de vida em relação ao CLI Rust existente, estratégia de SQLite |
| `data-contract-reviewer` | Schema do banco SQLite, contrato de mensagens Slack → SDD, contrato de comentários Jira como gate de estado |
| `test-reviewer` | Estratégia de testes para componente com dependências externas (mocks de Slack, Jira), cobertura do caminho de execução autônoma |

---

### Reviewers Humanos

- Aprovação obrigatória após PRD (ponto de definição de escopo e contratos externos)
- Aprovação obrigatória após Tech Spec (arquitetura do daemon, decisões de segurança)
- Aprovação obrigatória após Refinement (grooming de tasks, validação dos gates)
- Aprovação obrigatória antes de merge/deploy (`require_deploy_checkpoint_for: production`)

---

### Checkpoints Obrigatórios

| # | Ponto | Critério de avanço |
|---|---|---|
| CP-1 | Após PRD aprovado | Escopo definido, contratos externos listados, estratégia de secrets aprovada pelo humano |
| CP-2 | Após Tech Spec aprovada | Arquitetura do bot, schema SQLite, fluxo de autenticação e isolamento do componente revisados pelo `architecture-reviewer` e `security-reviewer` |
| CP-3 | Após Refinement aprovado | Tasks decompostas, mecanismo `/bloqueado` validado, riscos de regressão mapeados |
| CP-4 | Antes do merge | Review sem achados Críticos; testes de integração com mocks passando; `cargo audit` sem CVEs críticas; `gitleaks` sem secrets expostos |
| CP-5 | Antes do deploy | Verificação manual de `.gitignore` cobrindo `sdd-bot.config.yaml`; variáveis de ambiente documentadas; runbook de rollback definido |

---

### Evidências Mínimas

- [ ] PRD com lista explícita de todos os escopos OAuth do Slack e permissões Jira necessários
- [ ] Tech Spec com diagrama de sequência do fluxo `/bot create` (Slack → bot → Jira → orquestrador → Jira comentário)
- [ ] Schema SQLite versionado (migration 001) incluído na Tech Spec ou ADR
- [ ] Decisão documentada sobre armazenamento de secrets (ADR ou seção dedicada na Tech Spec)
- [ ] Estratégia de testes: mocks de Slack e Jira definidos antes da execução
- [ ] `cargo audit` e `gitleaks` executados e sem achados críticos antes do merge
- [ ] Checklist de regressão para os comandos SDD afetados pela remoção das amarrações antigas
- [ ] Runbook de rollback documentado para o componente bot

---

### Estimativa Inicial de Prazo

| Fase | Dias úteis |
|---|---|
| Ideia + PRD | 1–2 |
| Tech Spec + Agent Team reviews | 2–3 |
| Refinement (grooming) | 1 |
| Execução (implementação) | 5–8 |
| Review + ajustes | 2–3 |
| Memória + fechamento | 0,5 |
| **Total estimado** | **11–17 dias úteis** |

> A amplitude reflete a incerteza brownfield na remoção das amarrações existentes e na decisão de arquitetura do daemon. O limite inferior assume que as decisões de arquitetura e segurança são tomadas sem iterações adicionais nos checkpoints.

---

## Rastreabilidade

- **Origem:** Card Jira SDDL-2 (descrição da feature fornecida diretamente)
- **Configuração consultada:** `C:/alisson/sdd-layer/.worktree/SDDL-2/sdd.config.yaml`
- **Config do bot consultada:** `C:/alisson/sdd-layer/.worktree/SDDL-2/bot/sdd-bot.config.example.yaml`
- **Artefato salvo em:** `docs/sddl-2/00-risk-classification.md`
- **Próxima etapa:** `/idea` — aguarda aprovação deste artefato antes de prosseguir
