atlas-workflow 0.9.1 → 0.9.3

package/hosts/pi/.pi/agents/atlas-slice-review.md

@@ -82,7 +82,7 @@ Base the review on three inputs:
 
 ### 1. Build the slice boundary first
 Before reviewing code, identify:
-* diff physical boundary (`git diff --name-only main...HEAD`).
+* boundary físico do diff a partir do state/task ids; use a base configurada ou upstream e inclua mudanças não commitadas pertencentes à slice.
 * Section 2 - Invariants of Execution (contract).
 * Section 6 - Technical Contracts (signatures and shapes).
 * Section 8 - Validation and Checklist (QA criteria).
@@ -109,10 +109,43 @@ Ask what the implementation forgot:
 * **View & rendering:** inputs empty, null, partial, out of order, UI permission conditional.
 * **Contracts:** shape drift, enums, mappers, RLS server-side, i18n parity.
 
+Aplique estes probes determinísticos a cada símbolo ou hunk alterado relevante:
+* **Linha a linha:** leia cada hunk alterado e a função completa que o contém; construa entradas, estados, timings ou plataformas concretas capazes de provocar falha.
+* **Comportamento removido:** para cada guard, validação, cleanup, error path ou teste removido/substituído, identifique o invariante protegido e prove onde o novo código o restabelece.
+* **Rastreamento cross-file:** inspecione callers e callees quando assinaturas, shapes de retorno, erros, timing, ordem ou pré-condições mudarem.
+* **Altitude:** confirme que a mudança corrige o componente proprietário do invariante, sem empilhar um caso especial local sobre um defeito compartilhado.
+* **Regras aplicáveis:** inspecione arquivos de instruções do repo que governam os arquivos alterados. Reporte apenas violações exatas, com path da regra, texto da regra, linha violadora e impacto concreto.
+
+Reuse, simplificação e eficiência só viram findings quando o diff atual cria custo comportamental, operacional ou de manutenção concreto. Não reporte preferências de estilo.
+
 ### 4. Distinguish current-diff findings from pre-existing issues
 Prefer findings attributable to the executed slice. Mark pre-existing issues as observations or separate notes to keep signals clean and actionable.
 
-### 5. Output Expectations
+### 5. Verifique candidatos antes de reportar
+
+Elimine duplicatas que descrevam o mesmo defeito no mesmo local. Classifique cada candidato restante como:
+* `CONFIRMED` — evidência e cenário de falha alcançável sustentam o defeito.
+* `REFUTED` — código, tipo, invariante ou guard prova que o candidato é falso ou já está tratado.
+* `NEEDS_EVIDENCE` — o cenário é relevante, mas a evidência disponível não estabelece o defeito.
+
+Apenas `CONFIRMED` vira finding. Descarte `REFUTED`. Mova `NEEDS_EVIDENCE` para `Perguntas Abertas ou Suposições`, sem apresentá-lo como defeito. Nunca mantenha um candidato apenas por ser plausível.
+
+Antes de renderizar a saída, materialize os findings confirmados como JSON e execute o gate canônico Node `node scripts/classify_findings.mjs <findings.json>`. Cada item deve conter `severity`, `task_id`, `title`, `file`, `line`, `failure_mode`, `evidence`, `recommendation` e `fix_validation`. Saída não-zero bloqueia o relatório até o payload ser corrigido; é proibido ignorar o gate ou substituir campos ausentes por texto vazio. Array vazio é válido quando não há findings confirmados.
+
+Node é o único requisito runtime deste gate e funciona em Linux/macOS/Windows. `scripts/classify_findings.py` permanece por uma release somente como wrapper compatível que delega ao Node; não é fonte canônica nem torna Python obrigatório.
+
+### 6. Recomende uma correção de causa raiz
+
+Todo finding deve incluir exatamente uma recomendação principal de correção e uma validação que comprove a correção. A recomendação deve:
+* atacar a causa raiz no componente proprietário do invariante violado;
+* ser cirúrgica e permanecer no boundary revisado, salvo quando a evidência provar que o proprietário está fora dele;
+* preservar contratos do plano, arquitetura e comportamento existente não implicado pelo finding;
+* nomear concretamente componente, condição e comportamento esperado;
+* ser a melhor correção sustentada pela evidência disponível, nunca uma alegação sem suporte de superioridade absoluta.
+
+Não ofereça alternativas A/B. Não forneça patch completo nem altere código. Se a evidência for insuficiente para recomendar uma correção com segurança, classifique o candidato como `NEEDS_EVIDENCE` em vez de emitir finding.
+
+### 7. Output Expectations
 
 Return exactly this structure:
 
@@ -125,6 +158,8 @@ Return exactly this structure:
 - **Arquivo:** `relative/path.ext:line`
 - **Modo de falha:** [o que quebra e como]
 - **Evidência:** [o que suporta o finding]
+- **Correção recomendada:** [uma correção cirúrgica na causa raiz]
+- **Validação da correção:** [teste/check específico que comprova a resolução]
 
 ### P1 - <short title>
 [same shape]

package/hosts/pi/.pi/agents/atlas-task-validator.md

@@ -27,9 +27,14 @@ Leia o JSON em `.atlas/state/<run_id>/<slice>.json` usando o schema em `packages
 2. **Plan path** — `plan_path`, depois leia Section 2 (Invariantes de execução), Section 6 (Contratos técnicos) e Section 8 (Validação e checklist).
 3. **Executed task ids** — `tasks`.
 4. **Boundary refs** — `boundary_refs`.
+5. **Deterministic boundary** — `base_sha`, `head_sha`, `contract_kind` e arrays de evidence/probes.
+6. **Working-tree delta** — confronte `worktree_baseline`, `worktree_final` e árvore atual; dirty preexistente intacto fica fora, mutação posterior entra.
+7. **Repair correlation** — no attempt 2, correlacione findings por ID com `repair_evidence` no mesmo state path.
 
 Não aceite contrato inline, diff colado ou listas de tasks coladas como boundary de validação. Se `state_path` estiver ausente, ilegível, ou faltar qualquer campo obrigatório, retorne JSON com `verdict: "fail"` e um finding P1 `Input insuficiente: <missing item>`.
 
+Compatibilidade: state legado mínimo sem `contract_kind` só é aceito para `atlas-plan-execute`. `atlas-direct-execute` exige extensão completa e `obligations` não vazio. Compare `base_sha...head_sha`, `HEAD` atual e arquivos evidenciados no working tree com `files_changed`; nunca infira base pelo nome da branch. Divergência gera boundary violation + P1.
+
 ## State persistence
 
 Use `atlas_run_state` como fonte primária de metadados da run e estado de gate. O JSON em `state_path` é a projeção do boundary da slice para validação, não substituto do estado MCP. Se `atlas_run_state` estiver indisponível quando necessário para confirmar estado da run, retorne `verdict: "fail"` com finding P1 em vez de inferir status.
@@ -88,7 +93,17 @@ Retorne JSON estrito como output final. Não envolva em Markdown e não anteceda
   "challenge_response": "string (sha256 hex do challenge.file; null se sem challenge)",
   "verdict": "pass | fail | pass_with_observations",
   "findings": [
-    { "severity": "P0|P1|P2|P3", "file": "string", "line": 0, "msg": "string" }
+    {
+      "id": "F-001",
+      "severity": "P0|P1|P2|P3",
+      "file": "string",
+      "line": 1,
+      "failure_mode": "string",
+      "evidence": "string",
+      "recommendation": "string",
+      "fix_validation": "string",
+      "msg": "string (deprecated; derivado por uma release)"
+    }
   ],
   "observations": [
     { "file": "string", "line": 0, "msg": "string" }
@@ -101,6 +116,8 @@ Retorne JSON estrito como output final. Não envolva em Markdown e não anteceda
 
 `dispatch_token` deve ser exatamente `validator_recovery.expected_dispatch_token`. `findings`, `observations` e `boundary_violations` são sempre arrays. Use arrays vazios quando não houver itens.
 
+IDs são únicos, obrigatórios no formato `F-NNN` e estáveis nos dois ciclos; severity é estritamente `P0|P1|P2|P3`. No segundo, devolva `repaired_finding_ids` e confirme que cada ID alvo possui `repair_evidence` com arquivos, checks e `status: resolved`. O MCP rejeita shape incompleto e `pass`/`pass_with_observations` com P0/P1.
+
 ## Severity Model
 
 Escala alinhada com `atlas-slice-review` (`P0/P1/P2/P3`).

package/hosts/pi/atlas/VERSION

@@ -1 +1 @@
-0.9.1
+0.9.3

package/hosts/pi/atlas/orchestrator/README.md

@@ -117,7 +117,7 @@ Status:
    ↓
 2. Validate PRD + Interview (condicional)
    ↓
-3. Execute
+3. Execute (`atlas-direct-execute`, mantendo `phase: plan_execute`)
    ↓
 4. Review (se --review)
    ↓
@@ -127,9 +127,11 @@ Status:
 ### Interview-Only Mode
 
 ```
-1. Entrevista direta (sem PRD anterior)
+1. Cria draft mínimo pelo `PRD_TEMPLATE.md` quando a entrada é brainstorm
    ↓
-2. Output (PRD esboço + decisões)
+2. Entrevista `atlas-prd-interview` com `prd_path` válido
+   ↓
+3. Output (PRD esboço + decisões)
 ```
 
 ## Sequências canônicas
@@ -140,7 +142,7 @@ Atlas é família única. Cliente (Claude Code, Cursor, Codex App) é apenas o h
 |------|-----------|
 | `full` | `atlas-sprint-prd-generator` → `atlas-prd-interview` quando necessário → `atlas-plan-handoff` → `atlas-plan-execute` → `atlas-task-validator` → `atlas-findings-repair` (no `fail`) → `atlas-slice-review` somente com `--review` |
 | `direct` | PRD/spec existente → `atlas-direct-execute` → `atlas-task-validator` → `atlas-findings-repair` (no `fail`) → `atlas-slice-review` somente com `--review` |
-| `interview-only` | `atlas-prd-interview` |
+| `interview-only` | draft PRD mínimo (se brainstorm) → `atlas-prd-interview` |
 
 ## Validação automática
 
@@ -220,7 +222,7 @@ Veja este README, `packages/mcp-server/README.md` e os SKILL.md `atlas-*` para o
 
 ---
 
-**Plugin version:** 0.9.1
+**Plugin version:** 0.9.3
 **Author:** Paulo Borini
 **Last updated:** 2026-06-16
 

package/hosts/pi/atlas/orchestrator/commands/workflow.md

@@ -34,4 +34,4 @@ Exemplos:
 
 Não improvise comportamento fora do `SKILL.md`. **Pipeline é fire-and-continue**: uma vez iniciado, avança fase a fase sem pedir permissão entre gates; só para em gate duro `blocked` ou blockage de ambiente real (ver "Princípio de continuação automática"). Nunca invente "Modo Discussão" ou peça "quer que eu gere/continue?". Decisão em aberto não para — dispara entrevista, propaga e segue. Em caso de erro real, siga "Error handling".
 
-**Gates duros (v0.3):** o pipeline é orientado a artefato e MCP. Antes de iniciar, rode a **Fase 0 (Pré-flight)** com `atlas_ping` e `atlas_preflight`; use ids `atlas-*`; garanta que cada sub-agent carregue o `SKILL.md` real antes de agir. Se MCP não responder, resultado exigido estiver ausente ou status for bloqueante, **aborte; nunca use fallback narrativo**. Respeite os Gates G1–G11 + TC da SKILL: `atlas_verify_artifact` antes de avançar (G1); em `full`, nenhum código antes de `PLAN_*.md` validado (G2); skills invocadas de verdade (G3); validador frio como sub-agent separado (G4); `atlas_scan_prd` determinístico e logado (G5); status verificado contra disco e MCP (G6); plano/execução/review como sub-agents reais com `atlas_lock_dispatch` (G7/G8); orquestrador de mãos atadas e dispatch blocking (G9); família única atlas-* via `atlas_preflight` (G10); em `full`, `atlas_assert_after_plan` exige `plan_execute` após plano (G11); PRD/PLAN exigem `atlas_verify_template_conformance` passed com `pending_count: 0` (TC).
+**Gates duros (v0.3):** o pipeline é orientado a artefato e MCP. Antes de iniciar, rode a **Fase 0 (Pré-flight)** com `atlas_ping` e `atlas_preflight`; use ids `atlas-*`; garanta que cada sub-agent carregue o `SKILL.md` real antes de agir. Se MCP não responder, resultado exigido estiver ausente ou status for bloqueante, **aborte; nunca use fallback narrativo**. Respeite os Gates G1–G11 + TC da SKILL: `atlas_verify_artifact` antes de avançar (G1); em `full`, nenhum código antes de `PLAN_*.md` validado (G2); skills invocadas de verdade (G3); validador frio como sub-agent separado (G4); `atlas_scan_prd` determinístico e logado (G5); status verificado contra disco e MCP (G6); execução/review como sub-agents reais com `atlas_lock_dispatch`, enquanto PRD/entrevista/plano são autoria documental no pai (G7/G8); orquestrador de mãos atadas e dispatch blocking (G9); família única atlas-* via `atlas_preflight` (G10); em `full`, `atlas_assert_after_plan` exige `atlas-plan-execute` após plano (G11); `direct` usa `atlas-direct-execute`; ambos mantêm `phase: plan_execute`; PRD/PLAN exigem `atlas_verify_template_conformance` passed com `pending_count: 0` (TC). Em `interview-only brainstorm`, crie draft mínimo pelo template antes de invocar `atlas-prd-interview` com `prd_path` válido.

package/hosts/pi/atlas/orchestrator/references/host-adapters.md

@@ -11,7 +11,7 @@ Tools nativas do cliente (`Agent()`, `TodoWrite`, `tasks`, `$skill`) vivem no ho
 1. **Runtime:** `atlas_capabilities` (MCP) — detecta host por env e retorna o descritor. Preferir sempre.
 2. **Estático:** esta tabela — fallback de leitura/documentação quando o MCP não está disponível.
 
-Os dois devem permanecer consistentes. O descritor em código vive em `packages/mcp-server/server.js` (`HOST_ADAPTERS`).
+Os dois devem permanecer consistentes. O descritor em código vive em `packages/mcp-server/server.js` (`HOST_ADAPTERS`). ZCode usa o mesmo formato de agentes que Claude (`.md` com frontmatter) por ser Claude Agent SDK compat.
 
 ## Detecção de host
 
@@ -21,6 +21,7 @@ Os dois devem permanecer consistentes. O descritor em código vive em `packages/
 | env `ATLAS_HOST` | o valor da env |
 | env `CLAUDE_PLUGIN_ROOT` presente | `claude` |
 | env `CODEX_HOME` / `CODEX_PLUGIN_ROOT` | `codex` |
+| env `ZCODE_PLUGIN_ROOT` (injetado pelo `.zcode-plugin` do host) | `zcode` |
 | env `ATLAS_HOST=opencode` (injetado por `opencode.json`) | `opencode` |
 | env `ATLAS_HOST=pi` (injetado pela config do `pi-mcp-adapter`) | `pi` |
 | env `ATLAS_HOST=antigravity` (injetado por `mcp_config.json`) | `antigravity` |
@@ -28,15 +29,15 @@ Os dois devem permanecer consistentes. O descritor em código vive em `packages/
 
 ## Matriz de adapters
 
-| Concern | `claude` (Claude Code) | `codex` (Codex App) | `opencode` | `pi` (pi cli) | `antigravity` (Gemini) | `generic` |
-|---------|------------------------|---------------------|------------|---------------|------------------------|-----------|
-| Disparo de subagente | `Agent(subagent_type: "<name>", prompt: "<state_path>")` | `spawn_agent(agent_type: "<name>", items: [{ type: "text", text: "<state_path>" }])` | `@<name>` (ou auto) com `<state_path>` | tool `subagent({ agent: "<name>", task: "<state_path>", context: "fresh" })` (pi-subagents) | `define_subagent` + `invoke_subagent` com `<state_path>` | subagente nativo do host, passando só `<state_path>` |
-| Registro do subagente | `agents/<name>.md` na raiz do plugin | `CODEX_HOME/agents/<name>.toml` via `init codex` (`.codex/agents/` no bundle é fonte gerada; custom agent nativo; `developer_instructions` carrega o `SKILL.md`; `atlas-task-validator` pinado em `model="gpt-5.4"` + `model_reasoning_effort="high"`) | `.opencode/agents/<name>.md` (`mode: subagent`) | `.pi/agents/<name>.md` (pi-subagents; frontmatter `name`+`description`+`tools`; **`SKILL.md` canônico embutido no corpo** porque o pi não tem skill loader no sub-agente — fonte única segue `packages/skills/<name>/SKILL.md`, agente é cópia gerada por `build/gen-host-agent.mjs`) | dinâmico via `define_subagent` da skill do orquestrador | mecanismo nativo equivalente |
-| Topologia do validador frio (G4) | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** |
-| Join síncrono (gate JOIN) | `self_evident` (`Agent()` bloqueante) | `self_evident` (confirmado em produção) | `self_evident` (`@<name>` bloqueante) | `must_report` (depende de `pi-subagents`; hard-fail sem report) | `self_evident` (`invoke_subagent` bloqueante) | `must_report` (indeterminado; hard-fail sem report) |
-| Todo nativo | `TodoWrite` | `tasks` | `todowrite` | nenhum (segue sem mirror) | nenhum (segue sem mirror) | nenhum (segue sem mirror) |
-| Config MCP | `plugin.json` `mcpServers` | `.mcp.json` | `opencode.json` `mcp.<name>` (`type:"local"`, `environment.ATLAS_HOST=opencode`) | `.mcp.json` no root (`pi-mcp-adapter`; `env.ATLAS_HOST=pi`); tools chegam proxiadas/prefixadas `atlas_workflow_<tool>` | `mcp_config.json` (`env.ATLAS_HOST=antigravity`) | host MCP-capaz |
-| Deps externas obrigatórias | — | — | — | **`pi-mcp-adapter` + `pi-subagents`** (DEC-005) | — | — |
+| Concern | `claude` (Claude Code) | `codex` (Codex App) | `opencode` | `pi` (pi cli) | `antigravity` (Gemini) | `zcode` (ZCode) | `generic` |
+|---------|------------------------|---------------------|------------|---------------|------------------------|-----------|-----------|
+| Disparo de subagente | `Agent(subagent_type: "<name>", prompt: "<state_path>")` | `spawn_agent(agent_type: "<name>", items: [{ type: "text", text: "<state_path>" }])` | `@<name>` (ou auto) com `<state_path>` | tool `subagent({ agent: "<name>", task: "<state_path>", context: "fresh" })` (pi-subagents) | `define_subagent` + `invoke_subagent` com `<state_path>` | `Agent(subagent_type: "<name>", prompt: "<state_path>")` | subagente nativo do host, passando só `<state_path>` |
+| Registro do subagente | `agents/<name>.md` na raiz do plugin | `CODEX_HOME/agents/<name>.toml` via `init codex` (`.codex/agents/` no bundle é fonte gerada; custom agent nativo; `developer_instructions` carrega o `SKILL.md`; `atlas-task-validator` pinado em `model="gpt-5.4"` + `model_reasoning_effort="high"`) | `.opencode/agents/<name>.md` (`mode: subagent`) | `.pi/agents/<name>.md` (pi-subagents; frontmatter `name`+`description`+`tools`; **`SKILL.md` canônico embutido no corpo** porque o pi não tem skill loader no sub-agente — fonte única segue `packages/skills/<name>/SKILL.md`, agente é cópia gerada por `build/gen-host-agent.mjs`) | dinâmico via `define_subagent` da skill do orquestrador | `agents/<name>.md` na raiz do plugin (.zcode-plugin) — mesmo formato claude (Claude Agent SDK) | mecanismo nativo equivalente |
+| Topologia do validador frio (G4) | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** | **`sibling`** |
+| Join síncrono (gate JOIN) | `self_evident` (`Agent()` bloqueante) | `self_evident` (confirmado em produção) | `self_evident` (`@<name>` bloqueante) | `must_report` (depende de `pi-subagents`; hard-fail sem report) | `self_evident` (`invoke_subagent` bloqueante) | `self_evident` (`Agent()` bloqueante; Claude Agent SDK) | `must_report` (indeterminado; hard-fail sem report) |
+| Todo nativo | `TodoWrite` | `tasks` | `todowrite` | nenhum (segue sem mirror) | nenhum (segue sem mirror) | `TodoWrite` | nenhum (segue sem mirror) |
+| Config MCP | `plugin.json` `mcpServers` | `.mcp.json` | `opencode.json` `mcp.<name>` (`type:"local"`, `environment.ATLAS_HOST=opencode`) | `.mcp.json` no root (`pi-mcp-adapter`; `env.ATLAS_HOST=pi`; tools chegam proxiadas/prefixadas `atlas_workflow_<tool>`) | `mcp_config.json` (`env.ATLAS_HOST=antigravity`) | `.zcode-plugin/plugin.json` `mcpServers` (stdio; `ZCODE_PLUGIN_ROOT` injetado pelo host) | host MCP-capaz |
+| Deps externas obrigatórias | — | — | — | **`pi-mcp-adapter` + `pi-subagents`** (DEC-005) | — | — | — |
 | Estado de run | `atlas_run_state` (MCP) | `atlas_run_state` (MCP) | `atlas_run_state` (MCP) | `atlas_run_state` (MCP) | `atlas_run_state` (MCP) | `atlas_run_state` (MCP) |
 | Escrita de plano | `.atlas/plans/` | `.atlas/plans/` | `.atlas/plans/` | `.atlas/plans/` | `.atlas/plans/` | `.atlas/plans/` |
 | Leitura de plano (ordem) | `.atlas/plans/` → `.cursor/plans/` → `.codex/plans/` | idem | idem | idem | idem | idem |
@@ -92,7 +93,7 @@ Campos retornados (DEC-007):
 1. Adicionar entrada em `HOST_ADAPTERS` (`packages/mcp-server/server.js`).
 2. Adicionar regra de detecção em `detectHost` se houver env próprio.
 3. Adicionar linha na matriz de adapters.
-4. Registrar o subagente no formato nativo do host (ex.: `agents/<name>.md` ou equivalente).
+4. Registrar o subagente no formato nativo do host (ex.: `agents/<name>.md` ou equivalente). ZCode reusa o formato Claude (`agents/<name>.md`) — mesmo formato, sem geração extra.
 
 Sem tocar nas skills — elas já consomem o descritor.
 
@@ -102,4 +103,4 @@ Sem tocar nas skills — elas já consomem o descritor.
 
 ## Status multi-host
 
-Todos os hosts-alvo do survey S01 estão implementados na matriz acima: `claude`, `codex`, `cursor` (carona no manifest claude), `opencode` (S06), `pi` (S07) e `generic`. Nenhum exige HTTP/SSE → stdio único (DEC-006/S05). Survey completo + fontes: `PRD_S01_host_survey.md`.
+Todos os hosts-alvo do survey S01 estão implementados na matriz acima: `claude`, `codex`, `cursor` (carona no manifest claude), `opencode` (S06), `pi` (S07), `zcode` (Claude Agent SDK compat) e `generic`. Nenhum exige HTTP/SSE → stdio único (DEC-006/S05). Survey completo + fontes: `PRD_S01_host_survey.md`.

package/hosts/pi/atlas/orchestrator/skills/atlas-workflow-orchestrator/SKILL.md

@@ -21,7 +21,7 @@ Orquestra pipelines de desenvolvimento de features no projeto Atlas, automatizan
 Três modos **canônicos de execução** — `full`, `direct`, `execute` (PRD §5 D1) — mais o modo `interview-only`, que permanece **separado** (entrevista sem execução; PRD D2, não é colapsado em `full`).
 
 - **`full`** — pipeline completo: PRD → validação → entrevista (se necessário) → **plano (artefato obrigatório)** → executor → review (opcional)
-- **`direct`** — pipeline enxuto: PRD → validação → entrevista (se necessário) → executor → review (opcional). **Não produz plano de handoff** — a diferença real para `full` é exatamente essa.
+- **`direct`** — pipeline enxuto: PRD → validação → entrevista (se necessário) → `atlas-direct-execute` → review (opcional). **Não produz plano de handoff** — a diferença real para `full` é exatamente essa.
 - **`execute`** — recebe um **`PLAN_*.md` pronto** e o executa **sem gerar plano** (PRD D1). Entrada = caminho de plano; reverifica o artefato + conformidade de template e despacha `plan_execute` direto. Não regera nem replaneja: ajustes de plano pedem `full`. `atlas_assert_after_plan` (gate pós-plano do `full`) **não se aplica** em `execute` — o plano já é o input; o equivalente é a reverificação na entrada (PRD D13). **Não há alias `plan`**: usar `plan` como modo é ambíguo com planejamento documental e deve ser rejeitado como modo inválido.
 - **`interview-only`** — entrevista direta (ex: brainstorm, resolução de decisões). Entrevista **sem execução**: não usa `guarantee_level` no fluxo (não há execução de código a garantir). Permanece modo separado (PRD D2).
 
@@ -51,7 +51,7 @@ Três modos **canônicos de execução** — `full`, `direct`, `execute` (PRD §
 → Gera PRD de indicação, força entrevista, plano, executor
 
 /workflow interview-only brainstorm "que tal dark mode?"
-→ Entrevista direto, sem PRD prévio
+→ Cria draft mínimo pelo template canônico, valida o path e entrevista esse PRD; sem execução
 
 /workflow execute plan "/path/to/PLAN_S05_login.md"
 → Reverifica o plano (artifact + TC), executa direto via plan_execute + validador frio. Não gera plano.
@@ -102,7 +102,7 @@ Executar **antes** de iniciar o pipeline. Se qualquer item falhar, **parar e rep
       Ação: instalar/ativar o plugin ou corrigir o pacote atlas-* disponível no host
    ```
    **PROIBIDO o fallback "implementação direta" / "contratos equivalentes inline".** Não existe caminho onde o orquestrador faz plano ou código no próprio fio. Emulação inline e fallback direto são a falha-raiz que esta skill proíbe — se não há sub-agent, **para**. (Gate G7.)
-8. **Rejeitar conflito de modo:** se o pedido tiver `full`/`direct` junto com "sem patch", "sem editar código", "planejamento apenas", "handoff only" ou equivalente, **pare antes de gerar artefatos**. `full`/`direct` executam `plan_execute`; não existe interpretação plan-only implícita.
+8. **Rejeitar conflito de modo:** se o pedido tiver `full`/`direct` junto com "sem patch", "sem editar código", "planejamento apenas", "handoff only" ou equivalente, **pare antes de gerar artefatos**. `full` executa `atlas-plan-execute`; `direct` executa `atlas-direct-execute`; não existe interpretação plan-only implícita.
 9. **Declarar o plano de execução** (1 bloco curto): `run_id`, modo, **ids exatos de cada sub-agent**, sequência de fases, artefatos esperados e tools MCP que sustentarão cada gate. Só então iniciar a Fase 1.
 
 ---
@@ -120,7 +120,8 @@ O pipeline é **fire-and-continue**: uma vez iniciado, o orquestrador avança fa
 
 **Após entrevista**: reexecuta os gates afetados (`atlas_verify_artifact`/`atlas_scan_prd`/TC) e **retoma o pipeline (plano→execução) automaticamente**, sem nova confirmação.
 
-A única interação legítima com o usuário é **dentro de uma fase** — o `AskUserQuestion` da entrevista para resolver ambiguidade de produto. Resolver ambiguidade ≠ pedir permissão pra avançar. Terminada a fase, o pipeline segue sozinho até o próximo gate duro ou o output final.
+A única interação legítima com o usuário é **dentro de uma fase** — o mecanismo estruturado `question_prompt` devolvido por `atlas_capabilities`, usado pela entrevista para resolver ambiguidade de produto. Resolver ambiguidade ≠ pedir permissão pra avançar. Terminada a fase, respostas são persistidas no PRD, gates são reexecutados e o pipeline segue sozinho.
+
 
 ## Papel do orquestrador (fronteira de determinismo pela mutação de código)
 
@@ -129,7 +130,7 @@ O orquestrador **coordena a execução**, não implementa código — maestro qu
 - **ANTES do plano validado — autoria documental livre no fio principal.** Pode autorar PRD, entrevistar e escrever `PLAN_*.md` direto; fases documentais não exigem sub-agent (documento não muta o produto). **Ao finalizar um PRD inline, estampar `| Status | Aprovado para implementação |`** — é o `required_status` do gate TC; sem isso o PRD sai `Draft` e trava o TC em rodadas de correção.
 - **DEPOIS do plano validado (`atlas_verify_artifact` + TC `passed`) — mãos atadas fortes.** Não edita mais PRD/plano/código nem roda comando mutante; só coordena (despachar sub-agent, ler artefato pra verificar gate, ecoar banner, montar output).
 
-Execução de código é **sempre** sub-agent `plan_execute` (blocking, um por vez) + validador frio `task_validator` (Gate G9/G7 — detalhe na tabela de gates). Dispatch blocking: despacha → espera retorno → verifica gate → próxima fase. Nunca dois sub-agents simultâneos.
+Execução de código é **sempre** sub-agent executor do modo (`atlas-plan-execute` em `full`/`execute`; `atlas-direct-execute` em `direct`), mantendo `phase: plan_execute`, + validador frio `task_validator` (Gate G9/G7). Dispatch blocking: despacha → espera retorno → verifica gate → próxima fase. Nunca dois sub-agents simultâneos.
 
 ### Verbo de dispatch é host-agnóstico (não assuma "Agent tool")
 
@@ -143,6 +144,7 @@ O **mecanismo** varia por host — leia `subagent_dispatch.mechanism`, `.example
 
 > Ausência de "Agent tool" (host ≠ Claude) **não** é licença pra executar inline — é sinal pra usar o verbo daquele host (Gate G9, qualquer host). Host sem mecanismo de sub-agent já abortou em PREREQ; você nunca chega aqui sem isolamento.
 
+
 ## Protocolo de banner (única comunicação de progresso)
 
 O orquestrador comunica progresso **apenas** por **banner de fase de linha única** no formato `▸ atlas: <fase> · <ação> [· <detalhe>]` (PRD D7/D8). Regras:
@@ -180,9 +182,9 @@ Regras inegociáveis. Violação = parar, não contornar.
 
 ## Fluxo de execução
 
-### [EXEC] — passo comum de execução + validação (idêntico em `full`/`direct`/`execute`)
+### [EXEC] — passo comum de execução + validação
 
-`atlas_lock_dispatch(action=start, phase=plan_execute)`; despachar `plan_execute` como sub-agent blocking (lê `PLAN_*.md` em `full`/`execute`, PRD em `direct`). O executor emite checkpoints G12; sem retorno/progresso, chamar `atlas_lock_dispatch(action=status, phase=plan_execute)` e tratar `executor_bootstrap_timeout`/`executor_progress_timeout` como `stalled`/retry — nunca como execução em andamento. O executor retorna `validator_handoff_required` com `state_path`; o MCP só abre o slot após o checkpoint `state_path_created` para esse mesmo `state_path`. Validação sempre **sibling**: `atlas_lock_validator(action=start)`, despachar **um** `task_validator`, exigir no output o `dispatch_token` do slot e fechar com `validator_run_id` + `dispatch_token`. Em `fail`: `repair_start`, despachar `atlas-findings-repair` com `{state_path, findings, validator_attempt, repair_run_id, repair_budget: 1}`, exigir atualização do mesmo `state_path`, fechar com `repair_run_id` e rodar o **2º e último** validator. `passed`/`passed_with_observations` são terminais aprovados; status diferente bloqueia review e output completed.
+`atlas_lock_dispatch(action=start, phase=plan_execute)` em todos os modos; despachar como sub-agent blocking o `routing.executor_skill` devolvido pelo preflight: `atlas-plan-execute` em `full`/`execute`, `atlas-direct-execute` em `direct`. O executor emite checkpoints G12; sem retorno/progresso, chamar `atlas_lock_dispatch(action=status, phase=plan_execute)` e tratar `executor_bootstrap_timeout`/`executor_progress_timeout` como `stalled`/retry — nunca como execução em andamento. O executor retorna `validator_handoff_required` com `state_path`; o MCP só abre o slot após o checkpoint `state_path_created` para esse mesmo `state_path`. Validação sempre **sibling**: `atlas_lock_validator(action=start)`, despachar **um** `task_validator`, exigir no output o `dispatch_token` do slot e fechar com `validator_run_id` + `dispatch_token`. Em `fail`: `repair_start`, despachar `atlas-findings-repair` com `{state_path, findings, validator_attempt, repair_run_id, repair_budget: 1}`, exigir atualização do mesmo `state_path`, fechar com `repair_run_id` e rodar o **2º e último** validator. `passed`/`passed_with_observations` são terminais aprovados; status diferente bloqueia review e output completed.
 
 ### Full mode
 
@@ -225,8 +227,9 @@ Entrada: um **`PLAN_*.md` pronto**. Artefatos esperados: (plano já existe) →
 
 ### Interview-only mode
 
-1. Entrevista direta (sem PRD anterior) — invoca o id resolvido para `prd_interview`.
-2. Gera PRD esboço (opcional).
+1. Se a entrada já for PRD válido, usar seu path. Se for `brainstorm`, criar primeiro um draft mínimo em disco com `packages/templates/PRD_TEMPLATE.md`, preservando as 6 seções canônicas e registrando o brainstorm em contexto/objetivo.
+2. Verificar o draft com `atlas_verify_artifact` e `atlas_verify_template_conformance(artifact_type=prd)`; path ausente/inválido bloqueia.
+3. Invocar `prd_interview` no fio principal com `prd_path` válido; persistir respostas no mesmo artefato e reverificar.
 
 > `interview-only` é entrevista **sem execução**: não há fase `plan_execute` nem `guarantee_level` no fluxo (nada de código a garantir). A autoria do esboço é documental e livre.
 
@@ -245,9 +248,10 @@ O scan é **determinístico** e roda **dentro do MCP** (`atlas_scan_prd`): a lis
 Detalhe do caminho que a "Princípio de continuação automática" exige para decisão pendente de **qualquer fonte** (scan/entrevista/validação de plano/`PERGUNTAS_EM_ABERTO.md`/`DISCUSSAO_*.md`/backlog — a fonte não muda o tratamento):
 
 1. **Garantir o PRD primeiro.** Em `full`/`direct`, se o PRD não existe, **gerar o PRD draft** com as decisões marcadas. A entrevista é **PRD-scoped**: roda **sobre** o PRD, nunca antes. Detectar decisão não antecipa nem pula a geração do PRD.
-2. **Disparar `atlas-prd-interview`** sobre o PRD — resolve via `AskUserQuestion` (interação dentro da fase, não pedido de permissão).
-3. **Propagar** ao PRD/plano/DEC/registro de origem.
-4. **Reexecutar** os gates afetados (`atlas_verify_artifact`/`atlas_scan_prd`/TC) e **continuar** automaticamente.
+2. **Disparar `atlas-prd-interview`** sobre o PRD — resolve via `atlas_capabilities.question_prompt`, sem hardcode de host.
+3. **Persistir após cada rodada** no mesmo PRD, reindexar §3–§6 e não repetir D* fechada.
+4. **Propagar** ao PRD/plano/DEC/registro de origem.
+5. **Reexecutar** os gates afetados (`atlas_verify_artifact`/`atlas_scan_prd`/TC) e **continuar** automaticamente.
 
 Marcar TBD e adiar só se o usuário pedir **explicitamente** — nunca por iniciativa do orquestrador.
 
@@ -326,13 +330,16 @@ Se `full` gerou `PLAN_*.md` mas não despachou `plan_execute`, o cabeçalho deve
 
 ## Skills envolvidas
 
+`atlas-backlog-generator` aparece apenas para descoberta do catálogo: é **explicit-only** e nunca integra `full`/`direct`/`execute`/`interview-only`. A cadeia automática começa em PRD/input já fornecido.
+
 | Skill | Entrada | Saída (artefato) |
 |-------|---------|------------------|
-| `atlas-backlog-generator` | ideia/prompt/conversa/briefing | `BACKLOG_MESTRE_*.md` |
+| `atlas-backlog-generator` (**explicit-only**) | pedido explícito de backlog | `BACKLOG_MESTRE_*.md` |
 | `atlas-sprint-prd-generator` | sprint_id/indicação | `PRD_*.md`, decisions_found |
 | `atlas-prd-interview` | prd_path, ambiguities | `PRD_*.md` atualizado, decisions |
 | `atlas-plan-handoff` | prd_path | `PLAN_*.md` |
-| `atlas-plan-execute` | plan_path (full / **execute**) ou prd_path (direct) | diff de código, evidência |
+| `atlas-plan-execute` | plan_path (`full` / `execute`) | diff de código, evidência, `state_path` |
+| `atlas-direct-execute` | prd_path/spec/task (`direct`) | diff de código, evidência, `state_path` |
 | `atlas-slice-review` | diff/output | review_feedback |
 
 **Sub-agent frio (Gate G4):** `atlas-task-validator` é verificado no pré-flight pelo orquestrador e sempre roda isolado como **sub-agent irmão (sibling)**, em todos os hosts: despachado pelo orquestrador a partir do `state_path` retornado pelo executor. A topologia é sempre sibling — o executor nunca despacha o validador.
@@ -356,11 +363,11 @@ Se o MCP não responder ou reportar drift, o pacote está inválido: abortar no
 ```
 orquestrador
  ├─ MCP ping + preflight                         → atlas_ping + atlas_preflight (G10)
- ├─ PRD        → sub-agent                       → atlas_verify_artifact (G1)
+ ├─ PRD        → autoria documental no pai       → atlas_verify_artifact (G1)
  ├─ scan       → atlas_scan_prd (G5) + TC        → entrevista se bloqueado ou --interview
- ├─ PLANO      → lock_dispatch + sub-agent       → atlas_verify_artifact + atlas_verify_template_conformance
+ ├─ PLANO      → autoria documental no pai       → atlas_verify_artifact + atlas_verify_template_conformance
  ├─ G11        → atlas_assert_after_plan         → próxima ação obrigatória = plan_execute
- ├─ EXECUÇÃO   → atlas_lock_dispatch + sub-agent plan_execute
+ ├─ EXECUÇÃO   → atlas_lock_dispatch + sub-agent atlas-plan-execute
  ├─ VALIDAÇÃO  → lock_validator + task-validator irmão
  │                └─ fail → findings-repair (budget 1, mesmo state_path) → validator final
  └─ REVIEW     → atlas_lock_dispatch + sub-agent slice_review (se --review)

package/hosts/pi/atlas/packages/mcp-server/README.md

@@ -1,6 +1,6 @@
 # Atlas Workflow MCP Server
 
-Servidor MCP do plugin Atlas Workflow v0.9.1.
+Servidor MCP do plugin Atlas Workflow v0.9.3.
 
 ## Tools
 

package/hosts/pi/atlas/packages/mcp-server/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@atlas-workflow/mcp-server",
-  "version": "0.9.1",
+  "version": "0.9.3",
   "private": true,
   "type": "module",
   "bin": {