discutir-fase

Como funciona:

1. Carregar contexto anterior (PROJECT.md, REQUIREMENTS.md, STATE.md, arquivos CONTEXT.md anteriores)
2. Explorar base de código em busca de recursos e padrões reutilizáveis
3. Analisar a fase — pular áreas cinzentas já decididas em fases anteriores
4. Apresentar áreas cinzentas restantes — usuário seleciona quais discutir
5. Aprofundar cada área selecionada até satisfação
6. Criar CONTEXT.md com decisões que guiam pesquisa e planejamento

Saída: {phase_num}-CONTEXT.md — decisões claras o suficiente para que agentes subsequentes possam agir sem perguntar ao usuário novamente

<execution_context> @./.claude/framework/workflows/discuss-phase.md @./.claude/framework/workflows/discuss-phase-assumptions.md @./.claude/framework/templates/context.md </execution_context>

Arquivos de contexto são resolvidos no workflow usando init phase-op e chamadas de ferramentas de roadmap/estado.

Se DISCUSS_MODE for "assumptions": Ler e executar @./.claude/framework/workflows/discuss-phase-assumptions.md do início ao fim.

Se DISCUSS_MODE for "discuss" (ou não definido, ou qualquer outro valor): Ler e executar @./.claude/framework/workflows/discuss-phase.md do início ao fim.

OBRIGATÓRIO: Os arquivos execution_context listados acima SÃO as instruções. Ler o arquivo de workflow ANTES de tomar qualquer ação. As seções de objective e success_criteria neste arquivo de comando são resumos — o arquivo de workflow contém o processo completo passo a passo com todos os comportamentos obrigatórios, verificações de configuração e padrões de interação. Não improvisar a partir do resumo.

<success_criteria>

• Contexto anterior carregado e aplicado (sem re-perguntar questões já decididas)
• Áreas cinzentas identificadas através de análise inteligente
• Usuário escolheu quais áreas discutir
• Cada área selecionada explorada até satisfação
• Expansão de escopo redirecionada para ideias adiadas
• CONTEXT.md captura decisões, não visão vaga
• Usuário conhece os próximos passos </success_criteria>

<observability_integration> Integração com Observability-Driven Development (v1.9):

Quando o workflow.observability_phase_questions = true (default), o workflow inclui pergunta canônica de ODD na sessão de discussão:

"Quais SLIs essa fase impacta? O que precisa ser instrumentado para responder às 4 perguntas pré-PR?"

A pergunta é resolvida consultando a skill observability-driven-development e o resultado é registrado na seção <observability> do CONTEXT.md gerado:

<observability>
## SLIs impactados
- [SLI ou "nenhum — fase puramente interna"]

## Instrumentação necessária
- Spans novos: [lista]
- Atributos canônicos: [user.id, tenant_id, ...]
- error.type enum esperado: [validation, timeout, ...]
</observability>

O plan-checker invocado pelo /planejar-fase (Phase 33 — INT-FW-02) lê esta seção e bloqueia o plano se ODD ausente para fases voltadas ao usuário (skip silenciosamente para fases de infraestrutura — ver detecção em discuss-phase.md).

REQ: INT-FW-01. </observability_integration>

<legacy_refactor_integration> Integração com Suíte Legacy Code (Feathers):

Quando o workflow detecta intent de refactor (palavras-chave em descrição da fase: "refator", "refactor", "extrair", "limpar", "reorganizar", "split", "quebrar classe/módulo"), inclui pergunta canônica:

"Esta fase envolve refactor de arquivo existente? Se sim, qual é o arquivo alvo?"

Para cada arquivo identificado:

1. Coleta line count + checa se path matches contrato externo (supabase/functions, src/api, webhooks, pages/api)
2. Invoca refactor-safety-auditor em modo dry-run para coletar evidências sem bloquear
3. Resultado registrado em CONTEXT.md em seção <refactor_safety>: