@brunosps00/dev-workflow 1.5.0 → 1.6.0

package/scaffold/en/templates/idea-onepager.md

@@ -1,11 +1,19 @@
 ---
 type: idea-onepager
-schema_version: "1.0"
-status: draft
+schema_version: "1.1"
+status: draft | paused | aligned
 date: YYYY-MM-DD
 classification: improves | consolidates | new
+alignment:
+  confirmed_by_user: false   # set true ONLY when the user explicitly confirms shared understanding
+  confirmed_on: null         # ISO date of that confirmation
 ---
 
+> **Schema 1.1.** The `## Grill Alignment` block below is populated by a `/dw-brainstorm` grill session. Without a
+> Grill, leave that block empty and keep `status: draft`. `status: aligned` is allowed ONLY when every dependency
+> branch is resolved, glossary/code contradictions are closed, no blocking decision remains, and the user has
+> explicitly confirmed shared understanding — otherwise use `draft` or `paused`.
+
 # Idea: [Short, imperative title]
 
 ## Problem Statement
@@ -81,6 +89,40 @@ Ideally 2-4 stories. If it's more than 5, it's probably not MVP.]
 - [Question 1 affecting scope]
 - [Question 2 affecting priority]
 
+## Grill Alignment
+
+_(schema 1.1 — filled by a `/dw-brainstorm` grill session; consumed by `/dw-plan`, which does NOT re-ask resolved decisions. Leave empty for a non-grilled one-pager.)_
+
+### Resolved Decisions
+
+| Decision | Recommended | Chosen | Alternative rejected | Evidence |
+|----------|-------------|--------|----------------------|----------|
+| [the decision] | [what Grill recommended] | [what the user chose] | [the rejected option + its trade-off] | [one-pager/repo source] |
+
+### Evidence
+
+[Facts discovered during Grill from the repo/rules/intel/docs — each with its source (`path:line`, doc, or intel query) — that were used instead of asking the user.]
+
+- **[fact]** — source: `[path:line or doc]`
+
+### Canonical Vocabulary
+
+[Links into `.dw/domain/**` for the terms this idea depends on. Do not restate definitions here — point to the glossary.]
+
+- **[Term]** → `.dw/domain/glossary.md#term` (or `.dw/domain/contexts/<slug>.md#term` for a multi-context project)
+
+### Remaining Decisions
+
+[Non-blocking decisions still open after alignment, with their owner. A blocking decision means the one-pager is NOT `aligned`.]
+
+- **[open decision]** — owner: [who] — blocking? [no]
+
+### Alignment State
+
+- **State:** `draft` | `paused` | `aligned`
+- **Shared understanding confirmed by user:** [yes/no — `aligned` requires an explicit yes]
+- **Why not aligned (if draft/paused):** [the blocking node or unclosed contradiction that stopped alignment]
+
 ## Next Step
 
 Pick ONE:

package/scaffold/pt-br/commands/dw-adr.md

@@ -1,36 +1,71 @@
 <system_instructions>
-Você é um registrador de decisões arquiteturais. Sua função é criar um **Architecture Decision Record (ADR)** que documente uma decisão técnica importante feita durante a fase atual do PRD.
+Você é um registrador de decisões arquiteturais. Sua função é criar um **Architecture Decision Record (ADR)** que documente uma decisão técnica importante — repo-wide (`--scope=repo`, válido mesmo antes de qualquer PRD existir) ou vinculada a um PRD ativo (`--scope=prd`).
 
 ## Quando Usar
 - Use quando uma decisão arquitetural ou de design foi tomada e precisa ser registrada para referência futura (escolha de biblioteca, padrão de comunicação, tradeoff de performance, restrição imposta por compliance, etc.)
 - Use durante `/dw-plan techspec` ou `/dw-run` quando a justificativa da decisão não cabe no techspec nem no task file
+- Use **antes de qualquer PRD existir** para registrar uma decisão repo-wide — passe `--scope=repo` (escreve em `.dw/adrs/`).
 - NÃO use para decisões triviais ou reversíveis sem custo (escolha de nome de variável, ordem de import)
 - NÃO use para registrar bugs ou incidents (use `/dw-bugfix` ou notas operacionais)
 
+<critical>Ofereça ou crie um ADR SOMENTE quando os três critérios valem: (1) **difícil de reverter**, (2) **surpreendente sem contexto**, e (3) um **trade-off real** (uma alternativa real foi considerada e descartada). Se qualquer um falta, pule o ADR — não vire ruído no log de ADRs. A criação SEMPRE exige aprovação explícita do usuário, mesmo quando os três valem.</critical>
+
 ## Posição no Pipeline
-**Antecessor:** qualquer ponto do pipeline após `/dw-plan prd` | **Sucessor:** continua o fluxo anterior (techspec, task, review)
+**Antecessor:** qualquer ponto (ADRs com scope repo funcionam mesmo antes de `/dw-plan prd`) | **Sucessor:** continua o fluxo anterior (techspec, task, review)
 
 O ADR é **aditivo**: ele não substitui nenhuma etapa do pipeline. Qualquer command existente pode invocar `/dw-adr` quando uma decisão não-trivial precisar de registro permanente.
 
+## Scope (`--scope=repo|prd`)
+
+| Scope | Diretório | Quando |
+|-------|-----------|--------|
+| `repo` | `.dw/adrs/adr-NNN.md` | Decisão repo-wide, e qualquer decisão tomada **antes de um PRD existir**. |
+| `prd` | `{{PRD_PATH}}/adrs/adr-NNN.md` | Decisão vinculada a um PRD ativo específico. |
+
+**Resolução default** quando `--scope` não é passado (`--scope=` é sempre autoritativo e sobrepõe isto):
+
+1. Determine os **candidatos a PRD ativo** (ver "PRD ativo" abaixo) — diretórios de PRD em `.dw/spec/prd-*/` que NÃO são terminais/históricos.
+2. Exatamente um candidato → default `prd` (esse PRD).
+3. Zero candidatos (nenhum PRD existe, ou todo PRD é terminal) → default `repo`.
+4. Dois ou mais candidatos sem sinal desambiguador → **pergunte** qual PRD (ou `repo`); nunca adivinhe.
+
+### PRD ativo (definição operacional)
+
+Distinga um PRD **ativo** de um **histórico/terminal** de forma determinística e conservadora, usando evidência já presente no repo — nesta precedência:
+
+1. **Alvo explícito** — um PRD nomeado no pedido ou passado como `{{PRD_PATH}}`. Vence direto.
+2. **Sessão ativa** — o PRD referenciado por `.dw/STATE.md` (o spec de trabalho atual), quando presente.
+3. **Branch atual** — um checkout `feat/prd-<slug>` aponta para `prd-<slug>`.
+
+Um diretório de PRD é **terminal/histórico** (excluído dos candidatos) quando o frontmatter/status do seu `prd.md` o marca como shipped, merged, delivered, done, archived, superseded ou cancelled. Quando nenhum dos sinais 1–3 desambigua e resta mais de um PRD não-terminal, **pergunte** — não adivinhe. Isto lê apenas o que o repo já registra; nunca inventa estado, campo de status, nem migração.
+
+A numeração (`NNN`) é sequencial **dentro do diretório de ADR do scope escolhido** — ADRs de repo e ADRs por PRD têm contadores independentes.
+
 ## Variáveis de Entrada
 
 | Variável | Descrição | Exemplo |
 |----------|-----------|---------|
-| `{{PRD_PATH}}` | Caminho da pasta do PRD ativo | `.dw/spec/prd-minha-feature` |
+| `{{SCOPE}}` | `repo` ou `prd` (opcional; resolvido pelas regras default acima) | `repo` |
+| `{{PRD_PATH}}` | Caminho da pasta do PRD ativo (só para `scope=prd`) | `.dw/spec/prd-minha-feature` |
 | `{{TITLE}}` | Título curto da decisão (imperativo) | "Usar PostgreSQL ao invés de MongoDB" |
 
-Se `{{PRD_PATH}}` não for fornecido, pergunte ao usuário qual PRD está ativo (leia `.dw/spec/` e liste). Se `{{TITLE}}` não for fornecido, pergunte.
+Se `{{SCOPE}}` não for fornecido, resolva pela seção Scope (PRD único → `prd`; nenhum PRD → `repo`; múltiplos PRDs → pergunte). Para `scope=prd`, se `{{PRD_PATH}}` não for fornecido, pergunte ao usuário qual PRD está ativo (leia `.dw/spec/` e liste). Se `{{TITLE}}` não for fornecido, pergunte.
 
 ## Localização dos Arquivos
 
-- Diretório de ADRs: `{{PRD_PATH}}/adrs/`
-- Arquivo novo: `{{PRD_PATH}}/adrs/adr-NNN.md` (NNN zero-padded para 3 dígitos)
+- **`scope=repo`** → diretório `.dw/adrs/`, arquivo novo `.dw/adrs/adr-NNN.md`.
+- **`scope=prd`** → diretório `{{PRD_PATH}}/adrs/`, arquivo novo `{{PRD_PATH}}/adrs/adr-NNN.md`.
+- NNN zero-padded para 3 dígitos, sequencial dentro do diretório do scope escolhido.
 - Template: `.dw/templates/adr-template.md`
 
 ## Fluxo de Trabalho
 
+### 0. Resolver o scope
+- Determine o `scope` a partir de `--scope=` ou da resolução default (PRD ativo único → `prd`; nenhum PRD → `repo`; múltiplos PRDs ambíguos → pergunte). Defina o diretório-alvo de ADR de acordo (`.dw/adrs/` para repo, `{{PRD_PATH}}/adrs/` para prd).
+- Confirme que o gate de três critérios vale (difícil de reverter + surpreendente + trade-off real) e obtenha aprovação explícita do usuário antes de escrever.
+
 ### 1. Descobrir o próximo número
-- Liste os arquivos em `{{PRD_PATH}}/adrs/` (crie o diretório se não existir)
+- Liste os arquivos no diretório-alvo de ADR (crie o diretório se não existir)
 - O próximo número é `max(existentes) + 1`, ou `1` se vazio
 
 ### 2. Coletar contexto (perguntas mínimas)
@@ -52,8 +87,9 @@ id: NNN
 status: Proposed | Accepted | Deprecated | Superseded
 title: [título do ADR]
 date: YYYY-MM-DD
-prd: [slug do PRD]
-schema_version: "1.0"
+scope: repo | prd
+prd: [slug do PRD para scope=prd, ou "n/a" para scope=repo]
+schema_version: "1.1"
 ---
 
 # ADR-NNN: [Título]
@@ -86,11 +122,13 @@ schema_version: "1.0"
 
 ### 4. Atualizar referências cruzadas
 
-Se o ADR for criado **durante** a execução de um PRD, adicionar uma linha na seção "Related ADRs" dos artefatos relacionados:
+Se o ADR for criado com **`scope=prd`** (durante a execução de um PRD), adicionar uma linha na seção "Related ADRs" dos artefatos relacionados:
 - `prd.md`, `techspec.md`, ou `[N]_task.md`, conforme o escopo da decisão
 
 Se a seção "Related ADRs" não existir no arquivo, adicioná-la ao final.
 
+Para ADRs com **`scope=repo`** não há PRD dono — defina `prd: n/a` no frontmatter e linke artefatos relacionados só quando genuinamente aplicáveis (ex. `.dw/constitution.md`, `.dw/rules/`). ADRs de repo são o lar natural de decisões tomadas durante uma sessão de Grill greenfield antes de qualquer PRD existir.
+
 ### 5. Reportar
 
 Apresente ao usuário:
@@ -110,7 +148,7 @@ Este command é inspirado no padrão de ADRs de `/tmp/compozy/.agents/skills/cy-
 
 - Paths são `.dw/spec/<prd>/adrs/` ao invés de `.compozy/tasks/<name>/adrs/`
 - 4 perguntas mínimas em vez do fluxo interativo mais longo (alinhado com o estilo conciso de outros commands dw-*)
-- Integração explícita com `schema_version` dos templates v1.0
+- Integração explícita com `schema_version` v1.1 dos templates (adiciona `scope`; o link de PRD é condicional para ADRs de escopo repo serem coerentes)
 
 Credit: Compozy project.
 

package/scaffold/pt-br/commands/dw-analyze-project.md

@@ -32,6 +32,7 @@ As rules geradas por este comando são consumidas por:
 <critical>NUNCA modifique código fonte, apenas leia e documente</critical>
 <critical>Gere os arquivos de rules em .dw/rules/ na raiz do workspace</critical>
 <critical>Inclua exemplos de código do próprio projeto nas rules geradas</critical>
+<critical>PRESERVE os artefatos de domínio do fluxo de Grill. `.dw/domain/**` (glossary / context-map / arquivos por contexto) é vocabulário canônico curado à mão, dono do `/dw-brainstorm` grill — este comando NUNCA pode regenerar, mesclar ou sobrescrevê-lo. Quando `.dw/domain/**` existe, LEIA e LINKE a partir de `.dw/rules/index.md`; não copie seus termos para os arquivos auto-gerados de `.dw/rules/`. Este comando é dono de `.dw/rules/**`; o fluxo de Grill é dono de `.dw/domain/**`.</critical>
 
 ## Objetivo
 
@@ -454,8 +455,11 @@ workspace-root/
 ## Referência Rápida
 - Ver [{módulo}]({módulo}.md) para rules detalhadas por módulo
 - Ver [integrations.md](integrations.md) para comunicação entre projetos (se monorepo)
+- Ver [glossário de domínio](../domain/glossary.md) — ou [context map](../domain/context-map.md) — para vocabulário canônico (só quando `.dw/domain/` existe; dono do Grill, read-only aqui, nunca regenerado)
 ```
 
+> Quando `.dw/domain/**` existe, adicione o(s) link(s) de Domain Vocabulary acima ao `index.md` gerado e deixe os arquivos de domínio intocados. Quando não existe, omita o link — este comando nunca cria `.dw/domain/**` (só o `/dw-brainstorm` grill cria, após autorização explícita).
+
 #### 7.2 `.dw/rules/integrations.md` (apenas para monorepo / multi-projeto)
 
 Gerar este arquivo quando 2+ projetos forem detectados.
@@ -824,6 +828,7 @@ Este passo é aditivo e reversível; nunca edita código de componente, só docu
 - [ ] Step 9 (mapa de concerns) apresentou candidatos, aguardou aprovação, escreveu `.dw/rules/concerns.md` (ou anotou que não há sinais)
 - [ ] Passo 10 (autoridade de design) rodou para projetos frontend: autoridade existente respeitada, ou `DESIGN.md` gerado a partir de tokens reais, ou bootstrap via curated-defaults recomendado
 - [ ] Blocos com marker preserved em concerns.md mantidos verbatim no refresh
+- [ ] `.dw/domain/**` (glossary / context-map) preservado verbatim e linkado do index.md quando presente — nunca regenerado ou sobrescrito
 
 ## Exemplo de Uso
 

package/scaffold/pt-br/commands/dw-brainstorm.md

@@ -20,8 +20,8 @@ Modos internos (o dispatcher seleciona 1+):
 
 | Modo | Dispara automaticamente quando |
 |------|--------------------------------|
-| **option-matrix** (default sempre ativo) | Surface padrão: 3-7 opções (conservadora / equilibrada / ousada) com tags `[IMPROVES] / [CONSOLIDATES] / [NEW]`. Sempre roda salvo override explícito. |
-| **grill** | Vocabulário está instável — termos do usuário divergem de `.dw/rules/` / `.dw/constitution.md`, ou dois sinônimos competem na mesma conversa, ou alguém propõe um nome que conflita com o glossário. |
+| **option-matrix** (surface padrão) | 3-7 opções (conservadora / equilibrada / ousada) com tags `[IMPROVES] / [CONSOLIDATES] / [NEW]`. Roda por padrão **exceto quando Grill é a fase ativa** — `grill` e `option-matrix` são mutuamente exclusivos num turn (um override explícito ou um Grill autorizado também a pula). |
+| **grill** (nativo, com estado — exige autorização explícita) | O plan/PRD ou o vocabulário está instável. O Signal Reading pode **recomendar** Grill, mas é uma sessão de alinhamento com estado que escreve em `.dw/domain/**` e no one-pager; começa só com **intenção explícita** — `--mode=grill`, uma frase direta como "me questione" / "grill me", ou um **sim** à oferta única. Mutuamente exclusivo com `option-matrix`. |
 | **prototype** | Usuário pergunta "esse modelo de estado faz sentido?" / "como isso deveria parecer?" sem resposta clara; ou o próximo passo razoável é RODAR código, não escrever palavras. |
 | **council** | Duas ou mais abordagens competem sem vencedor óbvio; ou o consenso se forma rápido demais (sinal de false-consensus). |
 | **research** | A pergunta depende de state-of-the-art externo ("qual é a best practice atual para X", comparações multi-fonte, landscape regulatório ou de framework). |
@@ -68,6 +68,8 @@ Quando disponíveis no projeto em `./.agents/skills/`, use para enriquecer a ide
 - `dw-ui-discipline`: use quando o brainstorm envolver frontend ou direção de UI — o hard-gate (scene sentence, surface job) é forcing function generativa durante ideação, não só check de review. Também usado pelo branch UI do modo **prototype**.
 - `vercel-react-best-practices`: use quando explorar arquitetura React/Next.js ou trade-offs de performance.
 - `security-review`: use quando o brainstorm tocar auth, manipulação de dados ou features sensíveis à segurança.
+- `dw-grilling`: o motor de entrevista do modo **grill** — árvore de decisão ordenada por dependência, exatamente uma decisão por turn, cada uma com resposta recomendada. Interna, lida por path; nunca exportada.
+- `dw-domain-modeling`: o motor de vocabulário do modo **grill** — glossário canônico em `.dw/domain/**`, desafio de termos vagos/sobrecarregados, cross-check com o código, e a política de ADR raro. Interna, lida por path; nunca exportada.
 
 ## Referência do Template
 
@@ -92,9 +94,9 @@ Antes de produzir qualquer output, **leia a situação**:
 1. Inspecione `.dw/spec/prd-*/`, `.dw/rules/`, `.dw/constitution.md`, `.dw/intel/` se existirem. Anote vocabulário atual e PRDs recentes.
 2. Inspecione git recente (`git log --oneline -20`) pra detectar trabalho em andamento.
 3. Releia o pedido do usuário contra a tabela de Auto-Dispatch no topo desse arquivo. Casa sinais com modos.
-4. Decida o dispatch: **option-matrix** sempre roda salvo override que pule. Outros modos (grill, prototype, council, research, refactor-audit, onepager) disparam **aditivamente** quando seus sinais estão presentes.
-5. Diga ao usuário em uma linha curta qual o dispatch decidido: ex. "Dispatch: option-matrix + onepager (PRD está um passo à frente)" ou "Dispatch: grill (vocabulário instável no PRD atual)". Não esconda — surface antes de rodar.
-6. Depois, execute os modos nessa ordem (quando encadeados): grill → research → option-matrix → council → refactor-audit → prototype → onepager. Pule modos fora do dispatch.
+4. Decida o dispatch: **option-matrix** roda por padrão salvo override que pule OU Grill ser a fase ativa (os dois são mutuamente exclusivos). **grill** nunca é auto-iniciado — se os sinais aparecem, **recomende**-o e peça uma autorização explícita antes de iniciar a sessão com estado ou escrever qualquer arquivo (um brainstorm normal não pode escrever artefatos de Grill só porque o vocabulário parece instável). Os outros modos (prototype, council, research, refactor-audit, onepager) disparam **aditivamente** quando seus sinais estão presentes.
+5. Diga ao usuário em uma linha curta qual o dispatch decidido: ex. "Dispatch: option-matrix + onepager (PRD está um passo à frente)" ou, para grill, uma recomendação que precisa de consentimento: "Recomendando: grill (vocabulário instável) — autoriza iniciar a sessão com estado?". Não esconda — surface antes de rodar.
+6. Depois, execute os modos nessa ordem (quando encadeados): grill (só se autorizado) → research → option-matrix → council → refactor-audit → prototype → onepager. Como grill e option-matrix são mutuamente exclusivos, um Grill autorizado roda até o alinhamento primeiro e só **oferece** option-matrix como fase posterior separada e explicitamente anunciada. Pule modos fora do dispatch.
 
 ### Fluxo padrão (modo option-matrix)
 
@@ -181,7 +183,7 @@ Ao final, sempre deixe o usuario em uma destas situacoes:
 - com o one-pager em `.dw/spec/ideas/<slug>.md` (se modo **onepager** disparou)
 - com o relatório de research em `~/Documents/<Tópico>_Research_<data>/` (se modo **research** disparou)
 - com o plano de refactor em `<target>/refactor-plan.md` (se modo **refactor-audit** disparou)
-- com entradas de glossário sharpened em `.dw/rules/` (se modo **grill** disparou)
+- com entradas de glossário canônico em `.dw/domain/**` e um one-pager de ideia alinhado (se **grill** rodou com autorização)
 - com um protótipo throwaway rodável + template de verdict (se modo **prototype** disparou)
 
 ## Modo: research (research multi-fonte)
@@ -331,57 +333,116 @@ Salvo em `<target>/refactor-plan.md`:
 - Propor refactors sem teste ou não-testáveis → alto risco, não shippa.
 - Ignorar decisões arquiteturais documentadas em `.dw/rules/` → flagar design intencional como smell.
 
-## Modo: grill (domain-grilling)
+## Modo: grill (alinhamento nativo com estado)
 
-Dispara quando o vocabulário está instável — termos do usuário divergem de `.dw/rules/` / `.dw/constitution.md`, dois sinônimos competem, ou alguém propõe um nome que conflita com o glossário. Override: `--mode=grill`. Substitui o option-matrix por um **stress-test estilo entrevista** do plan/PRD contra o vocabulário do projeto. Cada rodada sharpens um pedaço. Atualiza `.dw/rules/` (ou `.dw/constitution.md`) inline conforme termos cristalizam — nunca adia pra "depois da conversa".
+Grill é uma **sessão de alinhamento com estado** que entrevista o plan/PRD até *shared understanding* e persiste
+vocabulário canônico em `.dw/domain/**`. **Não** é um turn normal de brainstorm: mantém uma árvore de decisão
+entre turns e escreve arquivos. Por ser stateful e mutante, começa **só com intenção explícita**.
 
-<critical>Pergunte UMA pergunta de cada vez. Espere a resposta. Não despeje 5 perguntas e torça pelo melhor.</critical>
+<critical>Intenção explícita de Grill = `--mode=grill`, uma frase direta como "me questione" / "grill me" / "grilla esse plano", OU um **sim** à oferta única abaixo. O Signal Reading automático pode **recomendar** Grill, mas DEVE pedir uma autorização explícita antes de iniciar a sessão ou escrever QUALQUER arquivo. Um brainstorm normal nunca escreve artefatos de Grill só porque o vocabulário parece instável.</critical>
 
-### Quando usar grill mode
+<critical>`grill` e `option-matrix` são **mutuamente exclusivos** num turn. Grill converge decisões; NÃO gera matriz de opções nem um veredito final de option-matrix — mas **cada pergunta da entrevista ainda carrega uma resposta recomendada** (com rationale e uma alternativa/trade-off). "Sem recomendação" se refere só ao veredito de option-matrix, nunca à recomendação por pergunta. Após o alinhamento, Grill pode **oferecer** option-matrix como fase posterior separada e explicitamente anunciada.</critical>
 
-- Antes de `/dw-plan prd` quando o domínio parece instável ou o time usa termos competindo.
+<critical>Pergunte exatamente UMA decisão não-resolvida por interação, e espere. Nunca despeje uma lista de perguntas.</critical>
+
+Grill é movido por duas skills internas (lidas por path em `./.agents/skills/`, nunca exportadas):
+- **`dw-grilling`** — o motor de entrevista em árvore de decisão (ordenação por dependência, uma decisão por
+  turn, uma resposta recomendada para cada pergunta, fatos descobertos em vez de perguntados, o gate de
+  shared-understanding).
+- **`dw-domain-modeling`** — o motor de vocabulário (termos canônicos, desafio de termos vagos/sobrecarregados,
+  cross-check com o código, e persistência lazy e segura em `.dw/domain/**`).
+
+### Quando Grill é o movimento certo
+
+- Antes de `/dw-plan prd` quando o domínio ou o plano parece instável ou o time usa termos competindo.
 - Depois de `/dw-plan prd` quando reviewers flagam linguagem ambígua no PRD.
-- Durante discussão de arquitetura quando "módulo", "serviço", "componente" são usados de forma intercambiável e precisa fixar o termo canônico.
-- Quando alguém propõe um nome que não combina com o glossário existente do projeto.
+- Quando "módulo", "serviço", "componente" (ou dois sinônimos) são usados de forma intercambiável e o termo canônico precisa ser fixado.
+- Quando um nome proposto conflita com o glossário existente, ou um plano esconde decisões não-resolvidas.
+
+Quando esses sinais aparecem no auto-dispatch, **recomende** Grill em uma linha e ofereça iniciá-lo — ex.
+*"O plano deixa 4 decisões de produto abertas e `Account` está sobrecarregado. Iniciar uma sessão de Grill
+(stateful, escreve em `.dw/domain/**` e no one-pager)? [sim/não]"*. Comece só com um sim explícito.
+
+### A sessão (após autorização)
 
-### Disciplinas durante a sessão
+1. **Construa a árvore de decisão primeiro.** Antes da primeira pergunta, inspecione os fatos do projeto —
+   PRDs/TechSpecs atuais, `.dw/rules/`, `.dw/intel/` (via `/dw-intel`), `.dw/constitution.md`, `.dw/domain/**` e
+   git recente — e monte uma árvore de decisão **ordenada por dependências** (nunca pergunte uma decisão
+   downstream antes do seu bloqueador).
+2. **Pergunte exatamente uma decisão não-resolvida por interação e espere.** Cada pergunta inclui: evidência
+   quando disponível (com fonte), a resposta recomendada, uma rationale curta, e uma alternativa/trade-off
+   significativa. Siga `dw-grilling` (`references/interview-loop.md`, `references/decision-tree.md`).
+3. **Fatos são descobertos, decisões são perguntadas.** Busque fatos no repo/rules/intel/docs; leve só decisões
+   genuínas ao usuário, e deixe a escolha com o usuário.
+4. **Sharpen o vocabulário com `dw-domain-modeling`.** Desafie termos vagos/sobrecarregados, stress-test com
+   cenários concretos de edge case, e cross-check cada termo contra o código (surface contradições `file:line`).
+5. **Uma resposta resolvida autoriza a atualização correspondente.** Resolvida a decisão, você pode persistir a
+   mudança de glossário/alinhamento correspondente (ver allowlist). Criação de ADR ainda exige **aprovação
+   explícita separada** — nunca crie um automaticamente.
 
-1. **Desafie contra o glossário.** Leia `.dw/rules/index.md` + `.dw/rules/<modulo>.md` + `.dw/constitution.md`. Flague conflitos de terminologia no instante em que o usuário usa um termo que diverge do que já está documentado.
+### Escritas com estado permitidas (só após autorização + a decisão relevante resolvida)
 
-2. **Sharpen linguagem vaga.** Quando o usuário disser "a coisa do user" ou "aquele lance de pedidos", proponha um termo canônico preciso. Não finja que entendeu — empurre de volta.
+- `.dw/domain/**` — o glossário canônico / context-map (via `dw-domain-modeling`).
+- O one-pager ativo `.dw/spec/ideas/<slug>.md` (estendido para schema `1.1`, abaixo).
+- Um PRD/TechSpec **explicitamente ativo** — só **depois de mostrar a mudança proposta** e obter concordância.
+- Paths de ADR roteados via `/dw-adr --scope=repo|prd` (após aprovação separada de ADR).
 
-3. **Discuta cenários concretos.** Force precisão com edge cases específicos: "O que acontece com a Order no estado X quando o evento Y chega durante o retry Z?" Respostas vagas voltam como mais perguntas.
+**Nunca edite código-fonte durante o Grill.** Se a autorização falta, continue entrevistando e reporte o que
+você *persistiria*.
 
-4. **Cross-reference o código.** Quando o usuário afirmar um comportamento, olhe rápido no codebase pra confirmar. Surface contradições: "Você disse que a API retorna `OrderId` mas `src/api/orders.ts:42` retorna `{ order_id, status }`." Não argumente em generalidades.
+### Artefatos de domínio nativos (não `.dw/rules/`, não `CONTEXT.md` na raiz)
 
-5. **Atualize `.dw/rules/` inline.** Quando um termo cristaliza, escreva no arquivo de rules apropriado no mesmo turn da conversa. Lazy file creation: se o arquivo não existir, crie. Formato segue a disciplina de glossário do projeto (ver `.dw/rules/index.md`).
+Vocabulário canônico vive em `.dw/domain/**`, criado **lazy** só depois que um termo é resolvido e existe
+autorização de escrita:
 
-6. **Pule detalhe de implementação no glossário.** `.dw/rules/` e `.dw/constitution.md` descrevem vocabulário e princípios — não implementação. "Order: pedido de um cliente para comprar itens, em um destes estados: pending, paid, shipped, delivered, refunded" é bom. "Order: uma classe TypeScript em `src/orders/`" é vazamento de implementação.
+- Contexto único → `.dw/domain/glossary.md`.
+- Múltiplos contextos → `.dw/domain/context-map.md` + `.dw/domain/contexts/<slug>.md`.
+
+Uma definição de glossário é uma ou duas frases que dizem o que o termo de domínio **é**, lista sinônimos
+desencorajados (`_Avoid:_`), e exclui detalhes de implementação, requisitos, notas de rascunho e conceitos gerais
+de programação. **Não** guarde vocabulário curado nos arquivos auto-gerados de `.dw/rules/`. `/dw-analyze-project`
+lê e linka `.dw/domain/**` e deve preservá-lo, nunca regenerá-lo.
+
+### Handoff alinhado — o one-pager de ideia (schema `1.1`)
+
+Grill estende `.dw/spec/ideas/<slug>.md` para o schema `1.1`, adicionando: **Resolved Decisions** (cada uma com a
+resposta recomendada, a escolha do usuário e a alternativa rejeitada), **Evidence** (fatos descobertos com fontes),
+**Canonical Vocabulary** (links para `.dw/domain/**`), **Remaining Decisions** e **Alignment State**.
+
+Defina `status: aligned` **só quando todas** valem: cada branch de dependência resolvida, contradições
+glossário/código fechadas, nenhuma decisão bloqueante aberta, E o usuário **confirma explicitamente** o shared
+understanding. Senão persista um estado `draft`/`paused` (com a árvore de decisão e os nós abertos) e **pare**.
+`/dw-plan` consome um handoff alinhado sem re-perguntar as decisões de produto já resolvidas.
 
 ### Disciplina de criação de ADR
 
-Só proponha um ADR via `/dw-adr` quando **todos os três** valem:
+Só ofereça um ADR (via `/dw-adr --scope=repo|prd`) quando **todos os três** valem — e a criação sempre exige
+aprovação explícita separada do usuário (`dw-domain-modeling/references/adr-policy.md`):
 
 | Critério | Teste |
 |----------|-------|
-| **Difícil de reverter** | Se mudarmos em 6 meses, custa >1 semana de trabalho? |
+| **Difícil de reverter** | Se mudarmos em 6 meses, custa significativamente mais que um dia? |
 | **Surpreendente sem contexto** | Um novo contribuinte chegaria razoavelmente a uma decisão diferente? |
 | **Trade-off real** | Havia uma alternativa real considerada e descartada? |
 
-Se algum falta, pule o ADR. Não ADR toda decisão casual — vira ruído na pasta de ADRs.
+Roteamento de scope: `repo` → `.dw/adrs/adr-NNN.md` (funciona antes de qualquer PRD); `prd` →
+`.dw/spec/<prd>/adrs/adr-NNN.md`. Se algum critério falta, pule o ADR — não vire ruído no log de ADRs.
 
 ### Output
 
 O modo grill produz:
-- **`.dw/rules/<modulo>.md` ou `.dw/constitution.md` atualizado** com termos cristalizados.
-- **PRD / TechSpec atualizado** se grill rodou no meio do planejamento (termos alinhados com o glossário).
-- **`.dw/spec/<prd>/adrs/adr-NNN.md` opcional** se os critérios acima valem.
-- **NÃO** produz option matrix ou recomendação (esse é o option-matrix; grill é só sharpening). Se o dispatcher encadeou grill+option-matrix, o option matrix roda em fase separada.
+- **Vocabulário canônico em `.dw/domain/**`** (glossary, ou context-map + arquivos por contexto) para termos resolvidos.
+- **Um one-pager estendido** em `.dw/spec/ideas/<slug>.md` (schema `1.1`) — `aligned` só após confirmação explícita, senão `draft`/`paused`.
+- **PRD / TechSpec atualizado** só se explicitamente ativo e a mudança foi mostrada antes.
+- **ADR roteado opcional** via `/dw-adr --scope=…` se os três critérios valem e o usuário aprova.
+- **NÃO** produz option matrix nem um veredito final de option-matrix — mas cada pergunta da entrevista ainda carrega uma resposta recomendada (option-matrix é fase posterior separada se oferecida e aceita).
 
 ### Quando a disciplina dobra
 
-- **Projeto greenfield sem `.dw/rules/`**: grille mesmo assim; a conversa produz as PRIMEIRAS entradas em `.dw/rules/index.md`. Isso é o valor.
-- **Discordância cosmética de terminologia** ("usamos `userId` ou `user_id`?"): pule grill mode; use ADR de convenção de código ou seção Naming em `.dw/rules/index.md`.
+- **Projeto greenfield sem `.dw/domain/`**: grille mesmo assim (uma vez autorizado); a sessão produz as PRIMEIRAS
+  entradas em `.dw/domain/glossary.md`. Isso é o valor. ADRs antes de qualquer PRD roteiam para `--scope=repo`.
+- **Discordância cosmética de terminologia** ("usamos `userId` ou `user_id`?"): pule grill; use uma nota de
+  convenção de código na seção Naming de `.dw/rules/index.md` — estilo de nome não é termo de domínio.
 
 ## Modo: prototype (protótipo descartável)
 
@@ -445,8 +506,20 @@ O padrão de codebase-grounded idea refinement é inspirado em [`addyosmani/agen
 - Output em `.dw/spec/ideas/<slug>.md` (irmão de `prd-<slug>/`) em vez de `docs/ideas/` — mantém a convenção de paths do dev-workflow.
 - Integração com o pipeline existente: `/dw-plan prd` aceita o one-pager como input, reduzindo perguntas de clarificação.
 
-Os modos **grill** e **prototype** são adaptados de [`mattpocock/skills/grill-with-docs`](https://github.com/mattpocock/skills/tree/main/grill-with-docs) e [`mattpocock/skills/prototype`](https://github.com/mattpocock/skills/tree/main/prototype) (Matt Pocock, MIT). Adaptação dev-workflow: integrados como modos INTERNOS auto-dispatchados em vez de skills separadas, paths rebaseados em `.dw/rules/` + `.dw/spec/<prd>/`, criação de ADR gated no teste 3-critérios (difícil de reverter + surpreendente + trade-off real).
-
-Crédito: Addy Osmani (idea-refine) e Matt Pocock (grill-with-docs, prototype).
+O modo **grill** é uma reimplementação nativa da disciplina de grilling do Matt Pocock (MIT), baseada em três
+skills upstream: [`skills/engineering/grill-with-docs`](https://github.com/mattpocock/skills/blob/main/skills/engineering/grill-with-docs/SKILL.md)
+(entrevista que produz docs conforme avança), [`skills/productivity/grilling`](https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md)
+(entrevista uma-decisão-por-vez com resposta recomendada, fatos buscados e não perguntados, gate de
+shared-understanding), e [`skills/engineering/domain-modeling`](https://github.com/mattpocock/skills/blob/main/skills/engineering/domain-modeling/SKILL.md)
+(glossário canônico, desafio de termos vagos, ADRs raros). Adaptações dev-workflow: comportamento reimplementado
+na voz deste repo (sem copiar prosa upstream) e extraído em duas skills **internas e não-exportadas** —
+`dw-grilling` e `dw-domain-modeling` — invocadas por este modo; o glossário vive em **`.dw/domain/**`** (não no
+`CONTEXT.md` da raiz do upstream nem no nosso `.dw/rules/` auto-gerado); Grill é uma **sessão com estado que exige
+uma autorização explícita** antes de escrever; o alinhamento produz um one-pager de ideia no schema `1.1`
+consumido pelo `/dw-plan`; e a criação de ADR é gated no teste 3-critérios e roteada via `/dw-adr --scope=repo|prd`.
+O modo **prototype** é adaptado de [`mattpocock/skills/prototype`](https://github.com/mattpocock/skills) (MIT) como
+modo interno auto-dispatchado.
+
+Crédito: Addy Osmani (idea-refine) e Matt Pocock (grill-with-docs, grilling, domain-modeling, prototype).
 
 </system_instructions>

package/scaffold/pt-br/commands/dw-claude-run.md

@@ -11,18 +11,19 @@ para implementar um prompt/spec ja preparado, captura a execucao inteira num log
 
 | Slot | Valor Claude |
 |---|---|
-| `DISPATCH` | `UUID=$(cat /proc/sys/kernel/random/uuid); cd <WORKTREE> && claude -p --session-id "$UUID" --model <MODEL> --output-format stream-json --include-partial-messages --verbose --dangerously-skip-permissions "$(cat <PROMPT>)" </dev/null > <AUDIT>/<slug>.log 2>&1` |
+| `DISPATCH` | `UUID=$(cat /proc/sys/kernel/random/uuid); cd <WORKTREE> && claude -p --session-id "$UUID" --model <MODEL> --effort <EFFORT> --output-format stream-json --include-partial-messages --verbose --dangerously-skip-permissions "$(cat <PROMPT>)" </dev/null > <AUDIT>/<slug>.log 2>&1` |
 | `STREAM` | `--output-format stream-json --include-partial-messages --verbose` (`--verbose` e **obrigatorio** com `stream-json` no modo `-p`) |
 | `AUTO` | `--dangerously-skip-permissions` (auto-aprovacao headless; justificavel porque a worktree e isolada). Somente leitura/analise: tire-o e use `--permission-mode plan` (ou restrinja `--allowedTools`). |
-| `RESUME <id>` | `cd <WORKTREE> && claude --resume "$UUID" -p --output-format stream-json --include-partial-messages --verbose --dangerously-skip-permissions "$(cat <FOLLOWUP_PROMPT>)" </dev/null >> <AUDIT>/<slug>.log 2>&1` |
+| `RESUME <id>` | `cd <WORKTREE> && claude --resume "$UUID" -p --effort <EFFORT> --output-format stream-json --include-partial-messages --verbose --dangerously-skip-permissions "$(cat <FOLLOWUP_PROMPT>)" </dev/null >> <AUDIT>/<slug>.log 2>&1` |
 | `RESUME_LAST` | `claude -c -p …` (continua a conversa mais recente nesta cwd) |
 | `SESSION_ID` | **FIXADO por voce** — voce passa `--session-id "$UUID"` na 1a run, entao o id e conhecido de antemao. Gere-o (`cat /proc/sys/kernel/random/uuid` ou `uuidgen`) e grave em `<AUDIT>/<slug>.session` ANTES/no dispatch. Sem scraping do stream — o Claude e o caso facil. |
 | `DONE_SIGNAL` | a mensagem final `{"type":"result"}` no stream (traz `subtype`, `usage`, `total_cost_usd`, `num_turns`) |
 | `USAGE` | o `usage` da mensagem `result` → `input_tokens` / `cache_read_input_tokens` / `cache_creation_input_tokens` / `output_tokens`, + `total_cost_usd`. Extrair: `grep -oE '"usage":\{[^}]*\}' <AUDIT>/<slug>.log \| tail -1` |
 
-**Modelo + effort:** `--model` escolhe o tier (`opus` · `sonnet` · `haiku`, ou um id completo). O Claude nao tem
-flag numerica de effort; mapeie "escalonamento" para o tier do modelo (e, quando precisar, peca extended thinking
-no prompt). Comece um tier abaixo do teto; escale conforme a `dw-cli-run`.
+**Modelo + effort:** `--model` escolhe o tier (`opus` · `sonnet` · `haiku`, ou um id completo). `--effort` escolhe
+o budget de raciocinio: `low` · `medium` · `high` · `xhigh` · `max` (suportado pelo Claude CLI ≥ 2.1.206). Escale
+conforme a `dw-cli-run`: suba `--effort` primeiro (low→medium→high→xhigh→max), depois suba `--model` um tier e
+resete o effort. Comece um notch abaixo do teto.
 
 ## Resume de sessao (o coracao)
 Como voce passa `--session-id "$UUID"`, o id e **fixo e conhecido** no dispatch — grave-o em
@@ -38,6 +39,8 @@ o Claude recarrega a mesma conversa (raciocinio + arquivos ja tocados). Fallback
 | `<PROMPT>` | caminho do prompt/spec preparado | `.dw/spec/prd-billing-integrador/codex-prompt.md` |
 | `<slug>` | chave da tarefa p/ arquivos de audit/sessao | `prd-billing-integrador` |
 | `<AUDIT>` | dir de auditoria duravel FORA da worktree | `~/code/vizzita/.dw/cli-run` |
+| `<MODEL>` | tier do Claude ou id completo do modelo | `opus` / `sonnet` / `haiku` |
+| `<EFFORT>` | budget de raciocinio (Claude CLI ≥ 2.1.206) | `low` / `medium` / `high` / `xhigh` / `max` |
 
 Retorne pelo **Structured Return** da `dw-cli-run` (Status/Score/Scope/Evidence/Artifacts/Decisions/Risks/
 Telemetria/Next Step), incluindo o `session-id` fixo (UUID), o caminho do sidecar, e o comando `RESUME` exato pra

package/scaffold/pt-br/commands/dw-plan.md

@@ -55,7 +55,36 @@ Claude Code e OpenCode podem usar agentes nativos. Codex e Copilot usam `.agents
 
 <critical>Quando uma ferramenta estruturada de entrevista/input do usuario estiver disponivel, `/dw-plan` DEVE usa-la para as perguntas de clarificacao de PRD e TechSpec. Nao rebaixe para chat comum por conveniencia. Se nenhuma ferramenta desse tipo existir no runtime, faca as mesmas perguntas no chat e registre explicitamente: `Ferramenta de entrevista estruturada indisponivel; usando fallback em chat.`</critical>
 
-A ferramenta e obrigatoria no planejamento porque preserva escolhas explicitas do usuario e impede o agent de responder as proprias perguntas. Cada estagio mantem sua propria cota: PRD exige 7+ perguntas de produto; TechSpec exige 7+ perguntas tecnicas.
+A ferramenta e obrigatoria no planejamento porque preserva escolhas explicitas do usuario e impede o agent de responder as proprias perguntas.
+
+## Entrevista dirigida por cobertura (sem cotas fixas de perguntas)
+
+<critical>`/dw-plan` NÃO faz um número fixo de perguntas. Cada estágio monta uma **coverage matrix** sobre suas dimensões obrigatórias, descobre fatos do repo/rules/intel/artefatos de domínio, **credita evidência já resolvida num handoff de Grill alinhado**, e então pergunta — uma decisão por vez — SOMENTE as dimensões que continuam descobertas. Nunca re-pergunte uma decisão de produto que o usuário já resolveu no Grill.</critical>
+
+### Handoff alinhado (do grill do `/dw-brainstorm`)
+
+Antes do Stage 1, verifique se há um one-pager de ideia em `.dw/spec/ideas/<slug>.md` e o vocabulário canônico em `.dw/domain/**`.
+
+<critical>Valide o handoff e FALHE FECHADO. Credite um handoff alinhado — i.e. suprima as perguntas de produto que suas decisões cobrem — SOMENTE quando TODAS valem:
+- `schema_version: "1.1"`;
+- `status: aligned`;
+- `alignment.confirmed_by_user: true`;
+- toda branch de dependência resolvida (nenhum nó de decisão aberto);
+- contradições glossário/código fechadas;
+- nenhuma entrada **bloqueante** resta em Remaining Decisions.
+Se QUALQUER check falha — ou o arquivo está malformado, internamente inconsistente, `draft` ou `paused` — o one-pager é **input, não handoff confiável**: leia para contexto, mas trate todas as suas decisões como **descobertas** e pergunte normalmente. Nunca suprima uma pergunta de produto só pela força do `status: aligned`; `alignment.confirmed_by_user: true` e uma árvore resolvida, não-bloqueante e sem contradições também são exigidos.</critical>
+
+Quando (e só quando) o handoff é totalmente válido:
+- Carregue suas **Resolved Decisions**, **Evidence** e links de **Canonical Vocabulary**.
+- Marque toda dimensão de PRD que essas decisões cobrem como **já coberta** (cite o one-pager como evidência) — NÃO re-pergunte.
+- Só dimensões descobertas viram perguntas, uma por vez.
+
+### Coverage matrices
+
+- **Dimensões do PRD:** objetivos, usuários-alvo, limites de escopo, métricas de sucesso, estratégia de rollout, pontos de integração, edge cases.
+- **Dimensões do TechSpec:** domain placement, data flow, dependências, core interfaces, estratégia de testes, reuse-vs-build, integração multi-projeto (quando aplicável).
+
+Para cada estágio: monte a matriz, marque cada dimensão `coberta` (fato descoberto ou evidência alinhada creditada) ou `descoberta`, e pergunte só as `descobertas` — uma decisão por turn, cada uma com resposta recomendada. **Decisões técnicas que um Grill de produto não cobriu ainda podem ser perguntadas durante o TechSpec** — Grill alinha vocabulário e decisões de produto, não o design técnico completo.
 
 ## Constitution Gate
 
@@ -78,11 +107,11 @@ Roda em modo padrão OU `plan prd`.
 
 ### Pré-requisitos
 - Ideia ou tópico do usuário.
-- (Opcional) one-pager de brainstorm em `.dw/spec/ideas/<slug>.md` via `/dw-brainstorm --onepager`.
+- (Opcional) um one-pager de ideia do `/dw-brainstorm` em `.dw/spec/ideas/<slug>.md`. Se estiver `status: aligned` (schema `1.1`, de uma sessão de Grill), consuma como handoff — suas Resolved Decisions são creditadas, não re-perguntadas (ver Entrevista dirigida por cobertura).
 
 ### Comportamento obrigatório
 
-1. **Perguntas de clarificação (MÍNIMO 7).** Antes de escrever qualquer coisa, use a ferramenta de entrevista estruturada quando disponivel para fazer 7+ perguntas cobrindo: objetivos, usuários-alvo, limites de escopo, métricas de sucesso, estratégia de rollout, pontos de integração, edge cases. Se a ferramenta estiver indisponivel, use fallback em chat e registre o fallback.
+1. **Coverage matrix sobre as dimensões do PRD** (objetivos, usuários-alvo, limites de escopo, métricas de sucesso, estratégia de rollout, pontos de integração, edge cases). Monte a matriz, credite evidência de handoff alinhado e fatos descobertos do repo, e pergunte SOMENTE as dimensões descobertas — uma decisão por vez, cada uma com resposta recomendada — usando a ferramenta de entrevista estruturada quando disponível (registre o fallback em chat caso contrário). Sem contagem fixa de perguntas; nunca re-pergunte uma decisão resolvida num one-pager alinhado.
 2. **Web search MÍNIMO 3 queries** para padrões de mercado, contexto regulatório, abordagens de competidores quando relevante.
 3. **Constitution alignment.** Cada requisito funcional (FR-N.M) inclui linha `Constitution Alignment: respects P-NNN, P-MMM` OU `no applicable principle: <motivo>`.
 4. **Awareness multi-projeto.** Se feature cruza projetos do workspace, consulte `.dw/rules/integrations.md` e documente escopo na seção "Projetos Impactados".
@@ -106,7 +135,7 @@ Roda em modo padrão (após aprovação do PRD) OU `plan techspec` OU `plan --fr
 ### Comportamento obrigatório
 
 1. **Hard gate: open questions do PRD.** Se `.dw/spec/prd-<feature>/prd.md` tem seção "Open Questions" com itens não resolvidos, PARE e peça pra usuário resolver primeiro.
-2. **Perguntas de clarificação (MÍNIMO 7).** Use a ferramenta de entrevista estruturada quando disponivel para fazer perguntas tecnicas cobrindo: domain placement, data flow, dependências, core interfaces, estratégia de testes, reuse-vs-build, integração multi-projeto se aplicável. Se a ferramenta estiver indisponivel, use fallback em chat e registre o fallback.
+2. **Coverage matrix sobre as dimensões do TechSpec** (domain placement, data flow, dependências, core interfaces, estratégia de testes, reuse-vs-build, integração multi-projeto quando aplicável). Credite evidência de handoff alinhado e fatos descobertos, e pergunte SOMENTE as dimensões descobertas — uma decisão por vez — usando a ferramenta de entrevista estruturada quando disponível (registre o fallback em chat caso contrário). Decisões técnicas não cobertas por um Grill de produto ainda podem ser perguntadas aqui. Sem contagem fixa de perguntas.
 3. **Web search MÍNIMO 3 queries** + Context7 MCP para framework/library specifics.
 4. **Source grounding (`dw-source-grounding`).** Toda decisão de framework/library carrega `[source: <url>, version: X.Y, retrieved: YYYY-MM-DD]`.
 5. **Constitution gate.** Cada decisão arquitetural lista `Respects: P-NNN` ou `Deviates: P-NNN — justification: <slug ADR ou racional>`. Desvios de princípios `severity: high/critical` sem ADR → PARE.
@@ -187,7 +216,7 @@ Após plan completo, o diretório do PRD contém:
 
 ## Diretrizes finais
 
-- Cada estágio tem sua própria cota de perguntas de clarificação — não recicle. Estágios diferentes precisam de framing diferente. Use a ferramenta de entrevista estruturada sempre que disponivel.
+- Cada estágio roda uma coverage matrix sobre suas próprias dimensões — sem cota fixa de perguntas. Credite evidência de handoff alinhado e fatos descobertos; pergunte só decisões descobertas, uma por vez. Estágios diferentes precisam de framing diferente. Use a ferramenta de entrevista estruturada sempre que disponivel.
 - Web search é obrigatório; Context7 MCP para libraries. Sem pular pra "acho que sei a versão mais recente."
 - Constitution gate roda na entrada de cada estágio; defaults são auto-instalados quando ausente (nunca bloqueia).
 - Os três estágios produzem Markdown commitado — esses são os artefatos canônicos de planejamento. Eles evoluem com a feature.

package/scaffold/pt-br/templates/adr-template.md

@@ -3,8 +3,9 @@ id: NNN
 status: Proposed
 title: [Título imperativo curto da decisão]
 date: YYYY-MM-DD
-prd: [slug do PRD, ex: prd-user-auth]
-schema_version: "1.0"
+scope: repo | prd
+prd: [slug do PRD para scope=prd, ex: prd-user-auth; "n/a" para scope=repo]
+schema_version: "1.1"
 supersedes: null
 superseded_by: null
 ---
@@ -46,8 +47,11 @@ Proposed | Accepted | Deprecated | Superseded by ADR-XXX
 
 ## Related
 
-- PRD: `.dw/spec/[prd-slug]/prd.md`
-- TechSpec: `.dw/spec/[prd-slug]/techspec.md` (se aplicável)
+<!-- scope=prd: linke o PRD/TechSpec dono. scope=repo: sem PRD dono — omita as linhas de PRD/TechSpec
+     (ou escreva "n/a") e linke `.dw/constitution.md` / `.dw/rules/` só quando genuinamente aplicáveis. -->
+
+- PRD: `.dw/spec/[prd-slug]/prd.md` (só scope=prd; "n/a" para scope=repo)
+- TechSpec: `.dw/spec/[prd-slug]/techspec.md` (se aplicável; só scope=prd)
 - Tasks afetadas: [lista de tasks, se aplicável]
 - ADRs relacionadas: [lista, se aplicável]