oxe-cc 0.3.8 → 0.5.0

package/oxe/workflows/obs.md

@@ -0,0 +1,95 @@
+# OXE — Workflow: obs
+
+<objective>
+Registrar uma **observação contextual** em **`.oxe/OBSERVATIONS.md`** durante ou fora de uma execução. A observação é incorporada automaticamente nos próximos `/oxe-spec`, `/oxe-plan`, `/oxe-discuss` ou `/oxe-execute` sem necessidade de re-explicar.
+
+**Princípio:** *observation-without-re-explaining* — registre em 1 request, receba o benefício em todos os workflows seguintes sem custo extra de requisição.
+
+Entrada: texto livre com a observação (restrição, descoberta técnica, preferência, risco, decisão).
+</objective>
+
+<context>
+- Pode ser chamado **a qualquer momento**: antes, durante ou após qualquer passo da trilha OXE.
+- Não interrompe o fluxo em curso — a observação é armazenada e incorporada na próxima oportunidade.
+- Se chamado **durante execute** (fase `executing` no STATE) com impacto `execute` ou `all`: oferecer opção de aplicar agora (pausar onda atual) ou continuar e aplicar na próxima rodada.
+- Ler **`.oxe/STATE.md`** para capturar o contexto automático (fase atual, tarefa ativa, workstream ativo).
+- Usar `oxe/templates/OBSERVATIONS.template.md` para criar o arquivo se ainda não existir.
+</context>
+
+<format_observations_md>
+Arquivo: **`.oxe/OBSERVATIONS.md`**
+
+```markdown
+# Observações OXE
+
+| ID | Data | Contexto | Impacto | Status |
+|----|------|----------|---------|--------|
+| OBS-001 | 2026-04-04 | execute/T3 | spec, plan | pendente |
+| OBS-002 | 2026-04-04 | pós-spec | execute | incorporada → execute (2026-04-04) |
+
+---
+
+### OBS-001 — 2026-04-04 | execute/T3
+**Impacto:** spec, plan
+**Status:** pendente
+
+JWT expiration deve ser configurável via `JWT_EXPIRES_IN` env var, não hardcoded 7d.
+
+---
+
+### OBS-002 — 2026-04-04 | pós-spec
+**Impacto:** execute
+**Status:** incorporada → execute (2026-04-04)
+
+API deve retornar mensagens de erro em português do Brasil.
+```
+
+**IDs:** sequenciais `OBS-001`, `OBS-002`, … (continuar do último ID existente no arquivo).
+
+**Impacto:** classificar automaticamente com base no conteúdo:
+- `spec` — afeta requisitos, critérios de aceite ou escopo
+- `plan` — afeta tarefas, ondas, dependências ou verificação
+- `execute` — afeta a implementação da tarefa atual ou próxima
+- `all` — afeta múltiplas camadas
+
+**Status lifecycle:** `pendente` → `incorporada → <workflow> (YYYY-MM-DD)`
+</format_observations_md>
+
+<process>
+1. Ler **`.oxe/STATE.md`**: capturar `phase`, `last_task` ou tarefa ativa na onda, `active_workstream`.
+2. Determinar o **próximo ID** (OBS-NNN): contar entradas existentes em `.oxe/OBSERVATIONS.md` ou começar em OBS-001.
+3. Classificar o **impacto** automaticamente com base no texto; se ambíguo, usar `all`.
+4. Criar ou atualizar **`.oxe/OBSERVATIONS.md`**:
+   - Adicionar linha na tabela de índice.
+   - Adicionar seção `### OBS-NNN` com contexto, impacto, status e texto.
+5. Avaliar **urgência**:
+   - Se `phase` ∈ `{ executing, quick_active }` **e** impacto ∈ `{ execute, all }`:
+     - Apresentar ao usuário: "Observação registrada. Deseja aplicar agora (pausar onda atual) ou continuar e incorporar na próxima rodada?"
+     - Se pausar: sugerir revisão do bloco `**Verificar:**` da tarefa ativa e ajuste inline.
+     - Se continuar: confirmar que será incorporado no início da próxima onda.
+   - Em qualquer outro caso: confirmar registro e mencionar quando será incorporado.
+6. Atualizar **`.oxe/STATE.md`**: adicionar ou atualizar campo `obs_pendentes: true` (remover ou marcar `false` quando todos os OBS estiverem `incorporada`).
+7. Responder no chat com: ID atribuído (OBS-NNN), impacto classificado, próximo passo sugerido (qual workflow incorporará a observação).
+</process>
+
+<auto_incorporation_rule>
+Qualquer workflow que leia `.oxe/OBSERVATIONS.md` deve:
+1. Verificar se há entradas com `Status: pendente` relevantes ao seu escopo de impacto.
+2. Incorporar o conteúdo na lógica do workflow (enriquecer requisitos, ajustar tarefas, modificar implementação).
+3. Após incorporar: atualizar a linha no índice e na seção `### OBS-NNN` para `incorporada → <workflow> (data)`.
+4. Se `STATE.md` tiver `obs_pendentes: true` e todas as observações relevantes foram incorporadas: atualizar para `obs_pendentes: false`.
+
+**Workflows que incorporam observações:**
+- `/oxe-spec` (Fase 3 — Requisitos): impacto `spec` ou `all`
+- `/oxe-plan`: impacto `plan` ou `all`
+- `/oxe-discuss`: impacto `spec`, `plan` ou `all` (como contexto adicional)
+- `/oxe-execute`: impacto `execute` ou `all` — incorporar no início da onda atual
+</auto_incorporation_rule>
+
+<success_criteria>
+- [ ] `.oxe/OBSERVATIONS.md` existe com entrada OBS-NNN na tabela e seção de detalhe.
+- [ ] Impacto classificado corretamente (spec | plan | execute | all).
+- [ ] `STATE.md` tem `obs_pendentes: true`.
+- [ ] Se urgência execute: usuário foi consultado sobre pausar ou continuar.
+- [ ] Resposta no chat inclui ID, impacto e próximo passo de incorporação.
+</success_criteria>

package/oxe/workflows/plan-agent.md

@@ -10,7 +10,7 @@ O plano **não** é só uma lista de tarefas: cada agente é um **pacote de cont
 
 **Exclusividade:** os papéis definidos no JSON são **efémeros** e **exclusivos** da trilha PLAN + **`/oxe-execute`** com este `runId`. **`/oxe-quick`** ou trabalho fora do `PLAN.md` **não** reutilizam estes agentes (ver **`quick.md`**, **`execute.md`**, referência **`references/plan-agent-chat-protocol.md`**).
 
-Se o utilizador pedir **`--replan`**: aplicar a mesma lógica de replanejamento descrita em **`plan.md`** (VERIFY, SUMMARY, secção Replanejamento) e **atualizar ou recriar** `plan-agents.json` em coerência com o novo `PLAN.md`; gerar **novo** `runId` e repor `lifecycle.status` → `pending_execute` (e limpar ou arquivar `.oxe/plan-agent-messages/` se o utilizador quiser histórico limpo — documentar no chat).
+Se o utilizador pedir **`--replan`**: aplicar a mesma lógica de replanejamento descrita em **`plan.md`** (VERIFY, SUMMARY, secção Replanejamento) e **atualizar ou recriar** `plan-agents.json` em coerência com o novo `PLAN.md`; gerar **novo** `runId` e repor `lifecycle.status` → `pending_execute`. Se ainda existir pasta **`.oxe/plan-agent-messages/`** cheia do **run** anterior e o utilizador não precisar dela na raiz, **arquivar** primeiro em **`.oxe/archive/plan-agent-runs/<runId-antigo>/`** (ver **`references/plan-agent-chat-protocol.md`**) ou pedir confirmação antes de sobrescrever; depois recriar **`.oxe/plan-agent-messages/README.md`** para o novo `runId`.
 </objective>
 
 <context>
@@ -26,6 +26,31 @@ Se o utilizador pedir **`--replan`**: aplicar a mesma lógica de replanejamento
 - Modelo JSON: ver **`oxe/templates/plan-agents.template.json`** e **`oxe/schemas/plan-agents.schema.json`**.
 </context>
 
+<agent_isolation_rule>
+## Regra de Isolamento de Agentes (Plan-Driven Dynamic Agents)
+
+**Cada `/oxe-plan-agent` cria agentes NOVOS para ESTE plano específico.**
+
+| Regra | Descrição |
+|-------|-----------|
+| **`runId` único** | Gerar `runId` NOVO a cada execução — nunca reutilizar `runId` de `plan-agents.json` anterior |
+| **`role` específico** | Descrever o papel no domínio desta demanda: "Especialista em autenticação JWT para este plano", não "Backend Developer" genérico |
+| **Não há reuso** | Agentes de planos ou demandas anteriores são inválidos para este plano. `lifecycle.status: invalidated` em qualquer blueprint anterior com `invalidatedBy: "new_plan"` |
+| **Lifecycle exclusivo** | Agentes vivem somente enquanto `lifecycle.status ∈ { pending_execute, executing }` e `runId` alinhado ao STATE.md |
+| **Gate de unicidade** | No quality gate: verificar que o `runId` gerado não existe em nenhum `plan-agents.json` anterior no repositório |
+
+**Invalidação de blueprint anterior:**
+Se já existir `.oxe/plan-agents.json` com status não-terminal (`pending_execute` ou `executing`), invalidá-lo antes de criar o novo:
+```json
+"lifecycle": {
+  "status": "invalidated",
+  "since": "<ISO agora>",
+  "invalidatedBy": "new_plan",
+  "invalidatedReason": "Novo /oxe-plan-agent iniciado para nova demanda"
+}
+```
+</agent_isolation_rule>
+
 <format_plan_md>
 Seguir **integralmente** o bloco **`<format_plan>`** e **`<plan_quality_gate>`** do ficheiro **`oxe/workflows/plan.md`** ao escrever `.oxe/PLAN.md` (incluindo gate antes de fechar).
 </format_plan_md>
@@ -49,12 +74,15 @@ Cada **agente**:
 |-------|-------------|-------------|
 | `id` | sim | Slug único estável (`agent-db`, `agent-backend-auth`). |
 | `role` | sim | Nome legível do papel. |
+| `persona` | não | ID de persona em `oxe/personas/` (ex.: `executor`, `architect`). O workflow `/oxe-execute` carrega a persona para instruir o LLM. Ver `oxe/personas/README.md`. |
 | `scope` | sim | Lista de strings (o que este agente faz, em bullets curtos). |
 | `taskIds` | sim | Lista de IDs **`T1`…`Tn`** que este agente implementa (subconjunto do `PLAN.md`). |
 | `dependencies` | não | Lista de **`id`** de outros agentes que devem concluir antes (grafo entre agentes). |
 | `inputs` | não | Caminhos ou nomes de artefactos a carregar no contexto (ex.: `.oxe/STATE.md`, `.oxe/SPEC.md`). |
 | `outputs` | não | Paths ou padrões de ficheiros esperados (orientação; o código real vem do PLAN). |
 
+**Personas disponíveis:** `executor`, `planner`, `verifier`, `researcher`, `debugger`, `architect`, `ui-specialist`, `db-specialist`. Ver `oxe/personas/README.md` para descrição de cada uma. Personas customizadas do projeto ficam em `.oxe/personas/`.
+
 **Regras de desenho:** preferir **um agente por domínio** (DB, API, UI) e **várias `Tn`** no mesmo agente quando partilham contexto; usar **agentes separados** quando o contexto mínimo diverge forte (evita fugas de foco).
 </format_plan_agents_json>
 
@@ -69,6 +97,8 @@ Antes de finalizar, validar **em conjunto** `PLAN.md` + `plan-agents.json`:
 6. **Alinhamento SPEC:** cada `scope` relevante deve ser rastreável a critérios **A*** via `taskIds` → **Aceite vinculado** no PLAN.
 7. **Artefactos de mensagens:** pasta **`.oxe/plan-agent-messages/`** existe e contém **`README.md`** (conteúdo baseado em **`oxe/templates/plan-agent-messages-README.template.md`**).
 
+8. **Isolamento:** `runId` gerado é novo e único; se havia blueprint anterior com status não-terminal, foi invalidado com `invalidatedBy: "new_plan"` antes de criar o novo (ver `<agent_isolation_rule>`).
+
 Resumo obrigatório no chat: `Gate plan-agent: OK` ou `Gate plan-agent: corrigido (N problemas)`.
 </plan_agent_quality_gate>
 

package/oxe/workflows/plan.md

@@ -12,10 +12,11 @@ Se o usuário pedir **--replan** (ou replanejamento implícito após `verify_fai
 </objective>
 
 <context>
+- Se existir **`.oxe/OBSERVATIONS.md`** com entradas `pendente` de impacto `plan` ou `all`, incorporar nas tarefas relevantes antes de finalizar o plano (ajustar implementação, verificação ou escopo de Tn) e marcar essas entradas como `incorporada → plan (data)`.
 - Não inventar APIs inexistentes: cruzar com **STRUCTURE.md**, **INTEGRATIONS.md** e arquivos reais; respeitar **CONCERNS.md** (evitar agravar dívida conhecida sem tarefa explícita).
 - Se existir **`.oxe/NOTES.md`**, rever entradas em aberto: incorporar em tarefas (com **Aceite vinculado** quando aplicável) ou registar na secção **Replanejamento** / nota explícita *fora de âmbito desta trilha*.
 - Se existir **`.oxe/UI-SPEC.md`**, as tarefas de UI devem referenciar secções do UI-SPEC no texto de **Implementação** ou **Verificar**.
-- Se existir **`.oxe/DISCUSS.md`**, alinhar tarefas às decisões registradas.
+- Se existir **`.oxe/DISCUSS.md`**, alinhar tarefas às decisões registradas. Referenciar IDs **D-NN** no campo **Decisão vinculada:** de cada tarefa impactada — se nenhuma decisão impactar a tarefa, omitir o campo. A rastreabilidade D-NN → Tn → verify é usada pela seção **Fidelidade de decisões** do verify.
 - Se existir **`.oxe/RESEARCH.md`** e notas em **`.oxe/research/*.md`**, ler o índice e as notas cujo **Tema** cruza o âmbito do plano (ou as mais recentes relevantes). Se o índice marcar **Estado** pendente em tópico bloqueante, pedir nova sessão **research** ou **discuss**, ou registar **suposição explícita** no PLAN antes de ondas que dependam dessa decisão.
 - Se existir **`.oxe/plan-agents.json`** (gerado por **`/oxe-plan-agent`**), um **--replan** ou renumerar tarefas deve **atualizar o JSON em conjunto** com o `PLAN.md` (cobertura `taskIds`, ondas e dependências entre agentes) — ver **`oxe/workflows/plan-agent.md`**. Preferir **`/oxe-plan-agent --replan`** para regerar **`runId`**, **`lifecycle`** (`pending_execute`) e alinhar **STATE.md**; se só **`/oxe-plan`** for usado, ou o JSON fica manualmente sincronizado, ou marcar no JSON `lifecycle.invalidatedBy: new_plan` até novo plan-agent.
 - Se existirem **`.oxe/CODEBASE-DELTA.md`** e/ou **`.oxe/RESUME.md`** (tipicamente após **`/oxe-compact`**), ler **antes** de detalhar tarefas: o delta resume o que mudou nos mapas face ao código; o RESUME ancora fase e trilha OXE — **não** substituem SPEC nem os sete ficheiros em `codebase/`.
@@ -38,6 +39,8 @@ Cada tarefa em PLAN.md deve seguir:
   - Comando: `...` (ex.: npm test, pytest, mvn test)
   - Manual: (opcional) passos breves
 - **Aceite vinculado:** A1, A2 (IDs exatos da tabela de critérios da SPEC)
+- **Decisão vinculada:** D-01, D-02 (IDs de `.oxe/DISCUSS.md` — omitir se não houver DISCUSS)
+<!-- oxe-task: {"id":"Tn","wave":1,"type":"feature","files":[],"done":false} -->
 ```
 
 **Projetos sem suíte de testes única (legado):** o bloco **Verificar** pode usar `Comando: —` e **Manual** com Grep, leitura de paths ou checklist — ver exemplos em **`oxe/workflows/references/legacy-brownfield.md`**. Todo critério **A*** da SPEC deve aparecer em **Aceite vinculado** de alguma tarefa ou como gap explícito.
@@ -54,6 +57,7 @@ Antes de finalizar a resposta ao utilizador, o agente **deve** percorrer este ga
 4. **Ondas:** cada número de **Onda:** usado tem pelo menos uma tarefa; sem ondas vazias.
 5. **`plan_max_tasks_per_wave`:** se `.oxe/config.json` tiver valor **> 0**, contar tarefas por **Onda**; nenhuma onda excede o limite.
 6. **UI-SPEC:** se existir `.oxe/UI-SPEC.md`, toda tarefa cuja **Implementação** ou **Verificar** toque UI (paths como `*.tsx`, `components/`, ou palavras-chave front, ou pedido explícito do utilizador) deve citar **secção § do UI-SPEC** ou path explícito.
+7. **Fidelidade de decisões:** se existir `.oxe/DISCUSS.md` com IDs **D-NN**, cada decisão com impacto técnico deve aparecer em **Decisão vinculada:** de alguma tarefa, ou ter nota explícita de gap (fora do escopo desta entrega). Sem cobertura para D-NN técnico = falha do gate.
 
 Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.
 

package/oxe/workflows/quick.md

@@ -3,15 +3,114 @@
 <objective>
 Registrar trabalho **rápido a médio** sem SPEC/PLAN completos: objetivo claro, passos curtos e uma verificação. Saída principal: **`.oxe/QUICK.md`** + atualização de **`.oxe/STATE.md`**.
 
-Usar quando: correção pontual, refactor local, uma feature pequena, ou protótipo que **não** justifica critérios de aceite longos.
+Quando o trabalho envolve **2 ou mais domínios distintos** (ex.: backend + frontend, DB + API, CLI + UI), aplicar também o conceito de **Plan-Driven Dynamic Agents — lean**: agentes focados derivados dos passos do QUICK.md, criados para esta demanda específica, sem reutilização entre demandas. O modo com agentes cria também **`.oxe/quick-agents.json`**.
+
+Usar quando: correção pontual, refactor local, feature pequena ou protótipo que **não** justifica critérios de aceite completos.
 </objective>
 
 <context>
 - Ler `.oxe/STATE.md` e, se existirem, `OVERVIEW.md` e `STACK.md` em `.oxe/codebase/` para não contradizer o repo.
 - Não apagar `SPEC.md` / `PLAN.md` se existirem; este fluxo é paralelo ou temporário.
-- **Blueprint plan-agent:** este fluxo **não** reutiliza papéis (`role` / `scope`) de **`.oxe/plan-agents.json`**. Se existir `plan-agents.json` com **`oxePlanAgentsSchema: 2`** e `lifecycle.status` **não** for já `invalidated`, **invalidar** o blueprint após criar/substituir **`QUICK.md`**: `lifecycle: { "status": "invalidated", "since": "<ISO>", "invalidatedBy": "quick", "invalidatedReason": "oxe-quick substitui trilha focada do blueprint" }`. Actualizar **`.oxe/STATE.md`** — secção **Blueprint de agentes (sessão)**: **lifecycle_status** → `invalidated`, nota “invalidado por quick”. Não escrever novas mensagens em **`.oxe/plan-agent-messages/`** para o `runId` invalidado.
+- **Blueprint plan-agent:** este fluxo **não** reutiliza papéis (`role` / `scope`) de **`.oxe/plan-agents.json`**. Se existir `plan-agents.json` com **`oxePlanAgentsSchema: 2`** e `lifecycle.status` **não** for já `invalidated`, **invalidar** o blueprint após criar/substituir **`QUICK.md`**: `lifecycle: { "status": "invalidated", "since": "<ISO>", "invalidatedBy": "quick", "invalidatedReason": "oxe-quick substitui trilha focada do blueprint" }`. Actualizar **`.oxe/STATE.md`** — secção **Blueprint de agentes (sessão)**: **lifecycle_status** → `invalidated`, nota "invalidado por quick". Não escrever novas mensagens em **`.oxe/plan-agent-messages/`** para o `runId` invalidado.
+- **Quick-agents anterior:** se existir **`.oxe/quick-agents.json`** com `status` diferente de `done` ou `invalidated`, invalidá-lo antes de criar o novo (`status: "invalidated", "since": "<ISO>", "reason": "novo quick iniciado"`).
 </context>
 
+<plan_driven_dynamic_agents_lean>
+## Plan-Driven Dynamic Agents — lean (integrado ao Quick)
+
+### Os três princípios que guiam este modo
+
+**1. Spec-Driven Design**
+O campo `## Objetivo` de **`QUICK.md`** é a **minispec**: define o que pode ser construído, os limites do escopo e o critério de "pronto" (bloco `## Verificar`). Nenhum agente pode adicionar escopo além desse objetivo. A minispec precede e restringe os agentes.
+
+**2. Spec-Driven Development**
+Os `## Passos` de **`QUICK.md`** são o **mini-plano**: cada passo é acionável, sequenciado e rastreável ao bloco `## Verificar`. Os agentes são **derivados dos passos** — os passos definem o trabalho; os agentes organizam quem faz o quê. Nunca o contrário.
+
+**3. Plan-Driven Dynamic Agents**
+Os agentes são criados **a partir dos passos**, **para esta demanda específica**, e são **invalidados** quando o quick termina ou é superado por um plano completo. Não há reuso de agentes entre demandas distintas. Cada new quick = novos agentes, se aplicável.
+
+### Quando ativar PDDA no Quick
+
+Ativar quando **qualquer** condição for verdadeira:
+- Os passos tocam **2 ou mais domínios distintos** (ex.: API e UI, DB e cache, backend e CLI)
+- O usuário pede explicitamente com `--agents`
+- Há **5 ou mais passos** que se agrupam naturalmente em responsabilidades diferentes
+
+**Não** ativar quando: todos os passos ficam no mesmo módulo ou camada, há ≤ 3 passos, ou o trabalho é puramente de conteúdo (docs, config).
+
+**Se precisar de mais de 3 agentes:** o trabalho não é mais "quick" → promover para **`/oxe-plan-agent`**.
+
+### Formato dos agentes no QUICK.md
+
+Cada passo recebe uma anotação de agente (`<!-- agente: id -->`). Uma seção `## Agentes dinâmicos` é adicionada:
+
+```markdown
+## Agentes dinâmicos (lean PDDA)
+> Derivados dos passos deste QUICK.md — spec-driven (objetivo restringe escopo) e plan-driven (passos definem tarefas).
+> Criados para **esta demanda**. Invalidados ao promover para spec/plan ou ao iniciar novo quick.
+
+| ID | Papel nesta demanda | Passos | Persona |
+|----|---------------------|--------|---------|
+| auth-backend | Especialista em JWT e middleware Express para este quick | 1–3 | executor |
+| login-ui | Especialista em integração do formulário de login React | 4–5 | ui-specialist |
+```
+
+**Regras de desenho:**
+- **`role`** deve ser específico ao domínio da demanda: não "Backend Developer" genérico, mas "Especialista em JWT para autenticação neste quick"
+- **`persona`** usa as personas disponíveis: `executor`, `planner`, `verifier`, `researcher`, `debugger`, `architect`, `ui-specialist`, `db-specialist`
+- Cada agente cobre steps **contíguos ou logicamente agrupados** (não intercalar responsabilidades)
+- Máximo **3 agentes** por quick
+
+### Arquivo `.oxe/quick-agents.json`
+
+Criar junto ao QUICK.md quando PDDA estiver ativo (usar como base `oxe/templates/quick-agents.template.json`):
+
+```json
+{
+  "oxeQuickAgentsSchema": 1,
+  "quickId": "quick-<YYYY-MM-DD>-<6hex>",
+  "quickRef": ".oxe/QUICK.md",
+  "status": "active",
+  "since": "<ISO agora>",
+  "agents": [
+    {
+      "id": "auth-backend",
+      "role": "Especialista em JWT e middleware Express para este quick",
+      "persona": "executor",
+      "steps": [1, 2, 3],
+      "focus": "Implementar signing/verification de JWT e middleware de auth"
+    },
+    {
+      "id": "login-ui",
+      "role": "Especialista em integração do formulário de login React",
+      "persona": "ui-specialist",
+      "steps": [4, 5],
+      "focus": "Integrar token JWT no componente Login e feedback de erro"
+    }
+  ]
+}
+```
+
+**Lifecycle de `status`:** `active` → `done` (verify concluído com sucesso) | `invalidated` (novo quick/plan/plan-agent iniciado)
+
+### Como `/oxe-execute` usa quick-agents
+
+Quando **`quick-agents.json`** tiver `status: active` e QUICK.md existir:
+- `/oxe-execute` adota o `role` e `persona` de cada agente para os steps atribuídos
+- Cada agente trabalha **somente** nos steps listados em `steps[]`
+- Não há protocolo de handoff entre agentes (lean: sem `.oxe/plan-agent-messages/`)
+- Ao concluir todos os steps: sugerir `/oxe-verify` e marcar `quick-agents.json` → `status: done`
+
+### Invalidação de quick-agents
+
+| Evento | Ação sobre `quick-agents.json` |
+|--------|-------------------------------|
+| Novo `/oxe-quick` iniciado | `status: "invalidated"`, `reason: "novo quick"` |
+| `/oxe-plan` ou `/oxe-plan-agent` chamado | `status: "invalidated"`, `reason: "promovido a plano"` |
+| `/oxe-verify` confirma sucesso total | `status: "done"` |
+| Invalidação manual pelo usuário | `status: "invalidated"`, `reason: "manual"` |
+</plan_driven_dynamic_agents_lean>
+
 ## Perfil fast (modo trivial)
 
 Uso **sem** novo slash: é o mesmo `/oxe-quick` com redação mínima.
@@ -19,6 +118,7 @@ Uso **sem** novo slash: é o mesmo `/oxe-quick` com redação mínima.
 - **Objetivo** — uma frase no `.oxe/QUICK.md`.
 - **Passos** — lista numerada, **máximo 10**; cada passo acionável numa linha.
 - **Verificar** — um comando de terminal **ou** checklist manual explícito.
+- **Agentes dinâmicos** — seção opcional quando PDDA estiver ativo (ver acima).
 - **Promover para spec/plan?** — preencher sempre; se qualquer gatilho abaixo for verdadeiro, resposta **sim** e parar de acumular trabalho no QUICK — passar a **`/oxe-spec`** (e depois discuss/plan conforme config).
 
 O perfil fast **não** é uma segunda trilha: continua sujeito à mesma promoção obrigatória quando o trabalho deixa de ser trivial.
@@ -31,6 +131,7 @@ Promova **nesta sessão ou na próxima** se **qualquer** condição for verdadei
 - Mudança de **contrato público** (API HTTP, schema de dados exposto, eventos, SDK).
 - **Segurança**, **dados pessoais**, **auth** ou **conformidade** envolvidos.
 - O próprio quick ficar com **mais de 10 passos** — dividir ou passar a SPEC.
+- PDDA lean precisaria de **mais de 3 agentes** — promover para **`/oxe-plan-agent`**.
 
 No final de **`.oxe/QUICK.md`**, mantenha a linha:
 
@@ -40,20 +141,29 @@ Se **sim**, o próximo passo recomendado no chat é **`/oxe-spec`** (depois disc
 
 <process>
 1. Garantir `.oxe/` (usar template de STATE só se `STATE.md` não existir).
-2. Criar ou substituir **`.oxe/QUICK.md`** com:
-   - **Objetivo** — uma frase.
+2. Avaliar se PDDA lean se aplica (ver `<plan_driven_dynamic_agents_lean>` — domínios distintos, 5+ passos, ou flag `--agents`).
+3. Criar ou substituir **`.oxe/QUICK.md`** com:
+   - **Objetivo** — uma frase. *(Esta é a minispec: restringe o escopo de todos os agentes e passos.)*
    - **Contexto** — 2–5 bullets (arquivos/pastas já vistos).
-   - **Passos** — lista numerada, **máximo 10** passos acionáveis.
-   - **Verificar** — pelo menos um: comando de terminal (ex.: `npm test`) **ou** checklist manual explícito.
+   - **Passos** — lista numerada, **máximo 10** passos acionáveis; se PDDA ativo, anotar `<!-- agente: id -->` em cada passo.
+   - **Agentes dinâmicos** *(somente se PDDA ativo)* — tabela com ID, papel, steps, persona.
+   - **Verificar** — pelo menos um: comando de terminal (ex.: `npm test`) **ou** checklist manual explícito. *(Este é o critério de aceite da minispec.)*
    - **Promover para spec/plan?** — conforme seção acima.
-3. Se existir **`.oxe/plan-agents.json`** com schema 2 e lifecycle ainda não `invalidated`, aplicar a invalidação descrita em **context** (actualizar JSON + **STATE.md** — blueprint de agentes).
-4. Atualizar **`.oxe/STATE.md`**: fase `quick_active`, próximo passo `oxe:execute` ou implementação manual + `oxe:verify`.
-5. Responder no chat com resumo em ≤8 linhas e o comando de verificação escolhido; se promover = sim, destacar **`/oxe-spec`** como próximo passo lógico; se o blueprint foi invalidado, mencionar **`/oxe-plan-agent`** para novo roteiro com agentes.
+4. Se PDDA ativo, criar **`.oxe/quick-agents.json`** usando `oxe/templates/quick-agents.template.json`:
+   - Gerar `quickId` novo (`quick-<YYYY-MM-DD>-<6hex>`).
+   - `status: "active"`, `since: "<ISO agora>"`.
+   - Preencher `agents[]` derivando de cada grupo de passos do QUICK.md.
+5. Se existir **`.oxe/plan-agents.json`** com schema 2 e lifecycle ainda não `invalidated`, aplicar a invalidação descrita em **context** (actualizar JSON + **STATE.md** — blueprint de agentes).
+6. Se existir **`.oxe/quick-agents.json`** anterior com `status` não-terminal, invalidá-lo (ver **context**).
+7. Atualizar **`.oxe/STATE.md`**: fase `quick_active`, próximo passo `oxe:execute` ou implementação manual + `oxe:verify`; se PDDA ativo, registrar `quick_agents_status: active` e `quick_id: <quickId>`.
+8. Responder no chat com resumo em ≤10 linhas: objetivo, passos, agentes (se PDDA ativo), verificação; se promover = sim, destacar **`/oxe-spec`** como próximo passo lógico; se blueprint plan-agent foi invalidado, mencionar **`/oxe-plan-agent`** para novo roteiro.
 </process>
 
 <success_criteria>
-- [ ] `.oxe/QUICK.md` existe com passos e bloco **Verificar**.
+- [ ] `.oxe/QUICK.md` existe com objetivo (minispec), passos (mini-plano) e bloco **Verificar** (critério de aceite).
 - [ ] `STATE.md` reflete fase `quick_active` e próximo passo coerente.
 - [ ] Fica explícito quando **promover** para spec/plan (regra acima + campo no arquivo).
 - [ ] Se havia blueprint schema 2 activo, `plan-agents.json` e `STATE.md` reflectem **`invalidated`** por quick.
+- [ ] Se PDDA ativo: `quick-agents.json` existe com `status: active`, `quickId` único, agentes com `role` específico à demanda, `steps` alinhados aos passos do QUICK.md; seção `## Agentes dinâmicos` presente no QUICK.md.
+- [ ] Se PDDA ativo: máximo 3 agentes; se mais necessário, QUICK.md declara `Promover para spec/plan?: sim` com razão "necessita > 3 agentes".
 </success_criteria>

package/oxe/workflows/references/plan-agent-chat-protocol.md

@@ -78,6 +78,20 @@ Opcional: **`taskIds`** — subset das tarefas que esta mensagem cobre.
 - **`/oxe-quick`** invalida o blueprint (`invalidatedBy: quick`); não reutilizar papéis do JSON no fluxo quick.
 - Trabalho **fora** do conjunto de `Tn` do `PLAN.md`: não assumir persona do blueprint; opcionalmente pedir confirmação para invalidar (`invalidatedBy: out_of_scope`).
 
+## Artefactos no repositório após fecho (recomendação OXE)
+
+Durante a trilha ativa, **`plan-agents.json`** e **`.oxe/plan-agent-messages/`** na raiz de `.oxe/` são práticos (caminhos estáveis para **`/oxe-execute`**). Depois de **`lifecycle.closed`** (tipicamente após **`/oxe-verify`** com sucesso), estes ficheiros **deixam de ser necessários** para o dia a dia e **poluem** o explorador e o `git status` se ficarem sempre na raiz.
+
+**Recomendação (equilíbrio entre limpeza e auditoria):**
+
+1. **Arquivar por sessão (`runId`), não apagar** — Move-se o histórico para **`.oxe/archive/plan-agent-runs/<runId>/`**:
+   - **`messages/`** — todo o conteúdo actual de **`.oxe/plan-agent-messages/`** excepto um `README.md` de índice opcional (ou mover também o README antigo para dentro do arquivo).
+   - **`plan-agents.json`** — cópia final do blueprint **no momento do fecho** (o JSON na raiz `.oxe/` pode ser **removido** após cópia, ou substituído por um stub mínimo só se outra ferramenta exigir o path; o normal é remover da raiz após arquivo).
+2. **Não commitar ruído sem querer** — Quem preferir **não** versionar handoffs: adicionar **`.oxe/archive/plan-agent-runs/`** ou **`.oxe/plan-agent-messages/`** ao **`.gitignore`** do projeto (trade-off: perde-se histórico no Git).
+3. **Pastas por sessão desde o primeiro dia** (alternativa maior) — **`.oxe/plan-agent-runs/<runId>/messages/`** + **`plan-agents.json`** dentro da mesma pasta, com um **`plan-agents.active`** ou entrada em **STATE** a apontar o `runId` corrente. Exige alterar todos os workflows e o mental model dos agentes; reserve-se para uma evolução do pacote se a raiz `.oxe/` tiver de ficar sempre mínima.
+
+**Resumo:** para o fluxo OXE actual, **arquivar em `.oxe/archive/plan-agent-runs/<runId>/` após verify OK** é a forma mais simples de “não precisarem mais existir na raiz” sem perder rastreabilidade. Apagar em massa só com **confirmação explícita** do utilizador.
+
 ## Ver também
 
 - [`oxe/workflows/plan-agent.md`](../plan-agent.md)

package/oxe/workflows/scan.md

@@ -32,7 +32,15 @@ Se **`.oxe/config.json`** tiver `scan_focus_globs` ou `scan_ignore_globs`, **pri
    - **CONVENTIONS.md** — estilo de código (naming, formatação, imports), padrões de erros/logging, organização de módulos; **prescreve** o que seguir em novas alterações (com paths em backticks).
    - **CONCERNS.md** — dívida técnica, áreas frágeis, riscos de segurança/desempenho, dependências sensíveis; cada item com impacto breve e **arquivos** referenciados.
 4. Atualizar **`.oxe/STATE.md`**: **Data** do scan (ISO), fase sugerida `scan_complete`, próximo passo `oxe:spec` ou `oxe:plan` se já houver SPEC.
-5. Resumir em 5–10 linhas no chat: o que foi escrito e o próximo passo sugerido.
+5. **Scale-adaptive** (se `scale_adaptive: true` em `.oxe/config.json` ou não configurado — ativo por padrão):
+   - Contar arquivos de código (excluindo `node_modules`, `dist`, `build`).
+   - Contar dependências diretas (se houver `package.json`, `pom.xml`, `go.mod`, etc.).
+   - Sugerir profile adequado no chat:
+     - **< 50 arquivos, < 10 dependências** → sugerir `profile: "fast"` no config.
+     - **50–500 arquivos** → sugerir `profile: "balanced"` (padrão).
+     - **> 500 arquivos ou sistema legado** → sugerir `profile: "strict"`.
+   - Se já houver `profile` no `.oxe/config.json`, não sugerir mudança — apenas confirmar.
+6. Resumir em 5–10 linhas no chat: o que foi escrito, o próximo passo sugerido, e (se scale-adaptive ativo) o profile recomendado.
 </process>
 
 <success_criteria>

package/oxe/workflows/spec.md

@@ -1,42 +1,191 @@
 # OXE — Workflow: spec
 
 <objective>
-Registrar a intenção do usuário em **`.oxe/SPEC.md`**: escopo, **critérios de aceite com IDs estáveis (A1, A2, …)** e coluna **Como verificar**, não objetivos e suposições. A spec é o contrato antes do plano.
+Conduzir as **5 fases** do processo de especificação e produzir dois artefatos:
 
-Para trabalho **muito pequeno**, o usuário pode preferir **`oxe:quick`** (`.oxe/QUICK.md`) em vez deste fluxo — não bloqueie: se pedirem explicitamente quick, redirecione.
+1. **`.oxe/SPEC.md`** — contrato formal com critérios de aceite estáveis (A1, A2, …) e coluna **Como verificar**.
+2. **`.oxe/ROADMAP.md`** — fases de entrega mapeadas a requisitos (R-ID) e critérios (A*).
 
-Se **`.oxe/config.json`** tiver `discuss_before_plan: true`, mencionar no fim que o próximo passo recomendado é **`oxe:discuss`** antes do plano.
+**Foco em redução de requisições:** as fases são estruturadas para extrair o máximo de informação por rodada — nunca uma pergunta por vez, sempre blocos coesos.
 
-Entrada: texto livre na mensagem ou caminho `@arquivo.md` / anexo para incorporar PRD/notas.
+Para trabalho **muito pequeno** que não justifica spec completa: redirecionar para **`oxe:quick`**.
+
+Se **`.oxe/config.json`** tiver `discuss_before_plan: true`: mencionar no final da Fase 5 que o próximo passo é **`oxe:discuss`** antes do plano.
 </objective>
 
 <context>
-**Pré-requisito:** preferencialmente **scan** já executado. Se não existir scan, mencionar na spec que o mapa está pendente.
-
-Leia `.oxe/STATE.md` e, se existirem, trechos relevantes de `.oxe/codebase/OVERVIEW.md` e `STACK.md` para não contradizer o projeto real.
+**Pré-requisito preferível:** scan executado. Se não existir, mencionar na spec que o mapa está pendente.
 
-Use o template **`oxe/templates/SPEC.template.md`**: tabela **Critérios de aceite** com colunas **ID | Critério | Como verificar**.
+Ler no início:
+- `.oxe/STATE.md` — fase atual, decisões, workstream ativo
+- `.oxe/codebase/OVERVIEW.md` e `STACK.md` se existirem — não contradizer o repo
+- **`.oxe/OBSERVATIONS.md`** — se houver entradas `pendente` com impacto `spec` ou `all`, incorporá-las na Fase 3 (Requisitos) e marcá-las `incorporada → spec (data)` após uso
 
-**Brownfield (COBOL, JCL, copybooks, VB6, SP):** quando o objetivo for documentar ou planear migração, ver **`oxe/workflows/references/legacy-brownfield.md`** — epicos por **trilha** (batch, online, desktop↔SQL), critérios **A*** verificáveis por Grep/leitura/checklist, e secções opcionais alinháveis a `spec_required_sections` em `.oxe/config.json` (ver `oxe/templates/CONFIG.md`).
+**Brownfield (COBOL, JCL, copybooks, VB6, SP):** quando o objetivo for documentar ou planear migração, ver **`oxe/workflows/references/legacy-brownfield.md`** — épicos por trilha, critérios A* verificáveis por Grep/leitura/checklist.
 
-**Exploratório / sistema grande / reversa / modernização:** quando a tecnologia ou o âmbito for incerto, houver necessidade de **mapear** o sistema, **engenharia reversa** ou **hipóteses de modernização** antes de tarefas executáveis, recomendar **`oxe:research`** (notas datadas em `.oxe/research/` + índice `.oxe/RESEARCH.md`) **antes** de `oxe:plan` — sugestão, não bloqueio obrigatório para specs mínimas.
+Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.template.md`**.
 </context>
 
+<fase_1_perguntas>
+## Fase 1 — Perguntas
+
+**Objetivo:** entender completamente a ideia antes de qualquer escrita de artefato.
+
+**Regra de ouro:** nunca uma pergunta por vez — sempre um **bloco coeso** de 3-5 perguntas por rodada. Máximo **3 rodadas**; sinalize quando achar que tem entendimento completo e peça confirmação antes de avançar.
+
+**Blocos de perguntas (adaptar ao contexto):**
+
+*Bloco A — Objetivo e motivação:*
+- Qual o problema central que isso resolve? Quem se beneficia?
+- Há uma solução atual (mesmo que ruim)? O que falha nela?
+- Como o sucesso será medido — qual o indicador mais importante?
+
+*Bloco B — Restrições e tecnologia:*
+- Quais tecnologias ou frameworks são obrigatórios ou proibidos?
+- Há restrições de prazo, orçamento, tamanho do time ou infraestrutura?
+- Quais integrações existentes precisam ser mantidas?
+
+*Bloco C — Casos extremos e escopo:*
+- Quais cenários de erro ou casos extremos são críticos de tratar na v1?
+- O que definitivamente está **fora** do escopo desta entrega?
+- Há comportamento esperado que você sabe que não é óbvio?
+
+**Estratégia de rodadas:**
+- Rodada 1: blocos A + B (entendimento geral)
+- Rodada 2: bloco C + clarificações específicas (se necessário)
+- Rodada 3 (máx): apenas se ainda houver ambiguidade crítica
+- Após rodada 3: avançar para Fase 2 mesmo com suposições explícitas
+
+**Ao final:** "Acho que entendi completamente. Confirma antes de avançarmos para pesquisa/requisitos? [resumo em 3-5 bullets]"
+</fase_1_perguntas>
+
+<fase_2_pesquisa>
+## Fase 2 — Pesquisa (opcional, recomendada)
+
+**Objetivo:** investigar domínios incertos antes de escrever requisitos.
+
+**Proposta ao usuário:** com base na Fase 1, listar 2-4 áreas de investigação sugeridas e perguntar quais investigar. Exemplos:
+- "Há 3 áreas com incerteza técnica: autenticação JWT, integração com Stripe, e deploy em edge. Quer investigar alguma antes de avançar para requisitos?"
+
+**Se aprovado:**
+- Criar notas de pesquisa datadas em `.oxe/research/YYYY-MM-DD-<slug>.md` (usar fluxo de `research.md`)
+- Atualizar `.oxe/RESEARCH.md` com índice
+- Consolidar descobertas relevantes antes de avançar para Fase 3
+
+**Se pulado:** registrar em `SPEC.md` as áreas de incerteza como suposições explícitas.
+
+**Explorações grandes / sistemas legado:** ver **`oxe/workflows/references/legacy-brownfield.md`** — progressive disclosure por área, multiple sessions, epicos por trilha.
+</fase_2_pesquisa>
+
+<fase_3_requisitos>
+## Fase 3 — Requisitos
+
+**Objetivo:** extrair uma tabela clara de requisitos com versionamento (v1/v2/fora).
+
+**Incorporar primeiro:** verificar `.oxe/OBSERVATIONS.md` por entradas `pendente` com impacto `spec` ou `all` — incorporar aqui antes de finalizar a tabela.
+
+**Formato da tabela:**
+
+| R-ID | Requisito | Versão | Critério de aceite |
+|------|-----------|--------|--------------------|
+| R1 | [o que o sistema deve fazer] | v1 | A1 — [como verificar] |
+| R2 | [outro requisito] | v1 | A2 — [como verificar] |
+| R3 | [requisito futuro] | v2 | A3 — [quando implementado] |
+| R4 | [fora do escopo] | fora | — |
+
+**Definições:**
+- **v1** = MVP essencial; entra no próximo `/oxe-plan`
+- **v2** = evolução futura; entra em ciclos seguintes
+- **fora** = explicitamente descartado desta entrega
+
+**Apresentar ao usuário para validação** antes de avançar para Fase 4. Se ajustar: atualizar tabela e repetir até aprovação.
+</fase_3_requisitos>
+
+<fase_4_roteiro>
+## Fase 4 — Roteiro
+
+**Objetivo:** criar fases de entrega mapeadas aos requisitos v1 e escrever `.oxe/ROADMAP.md`.
+
+**Lógica de agrupamento:**
+- Agrupar requisitos v1 em fases por **dependência técnica** e **valor entregável**
+- Cada fase deve ter resultado demonstrável (não apenas código interno)
+- Fase 1 = o que `/oxe-plan` implementará no próximo ciclo
+- Fases 2+ = ciclos futuros de spec→plan→execute→verify
+
+**Escrever `.oxe/ROADMAP.md`** usando `oxe/templates/ROADMAP.template.md`:
+
+```markdown
+---
+oxe_doc: roadmap
+status: draft
+updated: <data>
+spec_ref: .oxe/SPEC.md
+---
+
+## Fase 1 — [Nome]
+**Requisitos:** R1, R3
+**Critérios de aceite:** A1, A2, A3
+**Escopo:** ...
+
+## Fase 2 — [Nome]
+**Requisitos:** R2, R5
+**Critérios de aceite:** A4, A5
+**Escopo:** ...
+
+## Fora do escopo (v2+)
+- R4: [descrição] — motivo
+```
+</fase_4_roteiro>
+
+<fase_5_aprovacao>
+## Fase 5 — Aprovação e próximo passo
+
+**Objetivo:** confirmar o roteiro com o usuário e redirecionar para o plano.
+
+**Apresentar resumo:**
+- Objetivo em 1 frase
+- Requisitos v1 (N itens), v2 (M itens), fora (K itens)
+- Roteiro: Fase 1 → N critérios; Fase 2 → M critérios
+- Critérios de aceite da Fase 1: A1, A2, …
+
+**Perguntar ao usuário:**
+> "Roteiro aprovado? Quer gerar o plano agora ou ajustar algo antes?"
+
+**Se aprovado — oferecer os próximos passos:**
+
+| Opção | Quando usar | Próximo passo |
+|-------|-------------|---------------|
+| Plano simples | Tarefa clara, sem orquestração multi-agente | `/oxe-plan` |
+| Plano com agentes | Time distribuído, domínios distintos, ondas paralelas | `/oxe-plan-agent` |
+| Discutir antes | `discuss_before_plan: true` em config, ou risco técnico | `/oxe-discuss` → `/oxe-plan` |
+
+**Se ajustar:** voltar à fase indicada (Requisitos, Roteiro ou Perguntas) e repetir.
+
+**Ao finalizar:**
+- Marcar `ROADMAP.md` → `status: approved`
+- Atualizar `STATE.md`: `phase: spec_ready`, próximo passo conforme escolha
+</fase_5_aprovacao>
+
 <process>
-1. Resolver entrada: se começar com `@`, ler arquivo; senão usar o texto da conversa.
-2. Criar ou atualizar **`.oxe/SPEC.md`** usando `oxe/templates/SPEC.template.md` como esqueleto. Se o ficheiro já existir com YAML inicial (`---` … `---` antes do primeiro `#`), **preservar** chaves existentes; **atualizar** `updated:` com a data ISO do dia; ajustar `status` (ex. para `ready`) se o utilizador declarar a spec fechada. Se não houver frontmatter, pode adicioná-lo na primeira edição substancial.
-3. Garantir seções:
-   - **Objetivo** — uma frase clara.
-   - **Escopo** — bullets dentro / fora.
-   - **Critérios de aceite** — tabela com IDs **A1**, **A2**, … (testáveis).
-   - **Suposições e riscos**.
-   - **Referências** — paths se conhecidos.
-4. Atualizar **`.oxe/STATE.md`**: fase `spec_ready`, próximo passo `oxe:discuss` ou `oxe:plan` conforme `discuss_before_plan`.
-5. Responder com resumo da spec e no máximo 3 perguntas objetivas se algo crítico estiver ambíguo.
+1. Ler `.oxe/STATE.md`, `OVERVIEW.md`, `STACK.md` e `.oxe/OBSERVATIONS.md` (verificar pendentes).
+2. **Fase 1 — Perguntas:** enviar bloco coeso de 3-5 perguntas; máx 3 rodadas; confirmar entendimento.
+3. **Fase 2 — Pesquisa:** propor áreas de investigação; aguardar aprovação; executar se aprovado.
+4. **Fase 3 — Requisitos:** extrair tabela R-ID com v1/v2/fora e critérios A*; incorporar OBS pendentes; apresentar para validação.
+5. **Fase 4 — Roteiro:** agrupar requisitos v1 em fases; escrever `.oxe/ROADMAP.md`.
+6. Escrever **`.oxe/SPEC.md`** usando `oxe/templates/SPEC.template.md`:
+   - Frontmatter YAML (`oxe_doc: spec`, `status`, `updated`, `inputs`)
+   - Objetivo, Escopo (dentro/fora), Critérios de aceite (tabela A*), Suposições e riscos, Referências
+   - Preservar chaves existentes se SPEC.md já existir; atualizar `updated:`
+7. **Fase 5 — Aprovação:** apresentar resumo, aguardar aprovação do roteiro, redirecionar.
+8. Atualizar **`.oxe/STATE.md`**: `phase: spec_ready`, próximo passo.
+9. Marcar OBS incorporadas em `.oxe/OBSERVATIONS.md` se houver pendentes de impacto `spec`.
 </process>
 
 <success_criteria>
-- [ ] `.oxe/SPEC.md` existe e cada critério tem ID **A*** e forma de verificar.
-- [ ] `STATE.md` atualizado.
-- [ ] Ambiguidades críticas foram perguntas ou registradas como suposição explícita.
+- [ ] `.oxe/SPEC.md` existe com critérios A* e coluna Como verificar; `STATE.md` atualizado.
+- [ ] `.oxe/ROADMAP.md` existe com fases mapeadas a R-IDs e A*, status `approved` (ou `draft` se usuário não confirmou).
+- [ ] Tabela de requisitos R-ID foi apresentada e validada (v1/v2/fora) antes do roteiro.
+- [ ] Usuário foi consultado no gate da Fase 5 e escolheu o próximo passo.
+- [ ] OBS pendentes com impacto `spec` foram incorporadas e marcadas `incorporada`.
+- [ ] Máximo 3 rodadas de perguntas utilizadas — não mais.
 </success_criteria>