jarvis-ai-framework 5.2.0 → 5.6.0

package/templates/ENV-template.md

@@ -11,20 +11,24 @@
 # Workspace = a pasta que contém $IDE/. Não é o nome de um repo.
 # Vazio: o CLI usa o nome dessa pasta. Preencha só se quiser outro slug.
 #
-#   meu-app/                    ← um git aqui
+#   meu-app/                    ← a raiz é um repositório (WORKSPACE_MODE=project)
 #   ├── .windsurf/ENV.md
 #   ├── .jarvis/sessions/
 #   └── .git/
 #
-#   workspace-squad/            ← vários gits nas subpastas
-#   ├── .windsurf/ENV.md
+#   workspace-squad/            ← a raiz NÃO é repositório; 1 ou mais subpastas com .git
+#   ├── .windsurf/ENV.md          (WORKSPACE_MODE=workspace)
 #   ├── .jarvis/sessions/
 #   ├── repo-api-1/
 #   └── repo-frontend/
 #
 # WORKSPACE_REPOS = allowlist opcional. Vazio = todas as subpastas com .git/.
+# WORKSPACE_MODE = workspace | project (detectado pelo /jarvis-init e pelo upgrade).
+#   workspace: a raiz não tem .git e há 1+ subpastas com .git/ (não depende do número de repos).
+#   project:   a raiz tem .git. O git já delimita o que é código.
 WORKSPACE=
 WORKSPACE_REPOS=
+WORKSPACE_MODE=
 USER=
 
 # Limite de autonomia da IA neste workspace (60–100). 80 = a IA executa até 80%.
@@ -71,12 +75,22 @@ PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$JARVIS_DOCS/$PROD_FOLDER_NAME
 
+# Discoveries (rascunhos de ideia, anteriores ao PRD) — fora de product/ (em geral não precisa mexer)
+DISCOVERIES_FOLDER_NAME=discoveries
+DISCOVERIES_DOCS=$JARVIS_DOCS/$DISCOVERIES_FOLDER_NAME
+
 # Modo de condução dos comandos de produto (prod.*) e do eng.create-ard.
 #   product-led      = para PMs: fluxo direto, sem explicações extras (padrão se vazio)
 #   developer-guided = para devs e futuros PMs: uma pergunta por vez, explica cada termo e etapa
 # Perguntado sempre pelo /jarvis-init. Para trocar, rode o /jarvis-init ou edite aqui.
 PROD_MODE=
 
+# Estilo dos artefatos gerados (commits, PRs, comentários e documentos).
+#   ai-generated    = como hoje: metadados, links de rastreabilidade e padrões da ferramenta (padrão)
+#   human-generated = nada publicado leva marca de IA; todo documento gerado oferece a versão {nome}.public.md
+# Perguntado pelo /jarvis-init. Trocou à mão? Rode /jarvis-init upgrade (copia ou remove a rule do estilo).
+ARTIFACT_STYLE=ai-generated
+
 
 # --- Especializações por área -------------------------------------------------
 # Skills especializados que o Jarvis carrega junto com o skill base de cada área.

package/templates/engineering/architecture-template.md

@@ -7,7 +7,8 @@
 > **Issue:** {JIRA_ISSUE_KEY}  
 > **Branch base:** {main | dev | outra — perguntada no eng.start; destino do PR no eng.pr}  
 > **Status:** 🔄 Em Revisão | ✅ Aprovado | ❌ Rejeitado  
-> **Advisor:** {modelo escolhido no início do eng.start} | não utilizado
+> **Advisor:** {modelo escolhido no início do eng.start} | não utilizado  
+> **Questões em aberto:** tratar no architecture.md (como hoje) | uma a uma, assim que surgirem (só sem Advisor)
 
 ---
 

package/templates/engineering/daily-template.md

@@ -9,7 +9,7 @@ task_key: {TASK-123}
 # URL do card no task manager (padrão da eng.integrations-rules.md). Vazio no modo freelance.
 card_url: {URL}
 
-# Pull/Merge Request aberto: número e URL. O daily.md só existe com PR aberto.
+# Pull/Merge Request aberto: número e URL. Vazio se o PR ainda não foi aberto (o daily.md é gerado mesmo assim).
 pr: {#n URL}
 
 # Branch de trabalho e branch base (Branch base: do architecture.md).

package/templates/engineering/plan-template.md

@@ -3,6 +3,8 @@
 > 📋 **Plano de Execução** | Jira: [{TASK_MANAGER_KEY}]({TASK_MANAGER_URL_BASE}/browse/{TASK_MANAGER_KEY})
 >
 > Se você está trabalhando nesta feature, **atualize este arquivo** conforme progride.
+>
+> **Execução:** {fase a fase | todas de uma vez} · **Commits:** {um por fase | um só ao final} · **Depois do work:** {sugerir /eng.pre-pr | rodar /eng.pre-pr | direto para /eng.pr | parar} _(preenchido pelo `eng.work`, Fase 1.3)_
 
 ---
 

package/templates/product/prod-epic-template.md

@@ -29,7 +29,7 @@ related_prd: {path PRD relacionado, exemplo /master-docs/product/prd-001.md}
 related_frd: {path FRD relacionado, exemplo /master-docs/product/frds/frd-001.md}
 
 # Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
-related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+related_discovery: {path do discovery de origem, exemplo $DISCOVERIES_DOCS/discovery-001-nome.md. Se não existir, ignore essa linha}
 
 # Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}

package/templates/product/prod-frd-template.md

@@ -29,7 +29,7 @@ updated_at: {YYYY-MM-DD}
 related_prd: {Lista de PRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
 
 # Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
-related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+related_discovery: {path do discovery de origem, exemplo $DISCOVERIES_DOCS/discovery-001-nome.md. Se não existir, ignore essa linha}
 
 # Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}

package/templates/product/prod-issue-template.md

@@ -24,7 +24,7 @@ related_epic: {nome do Epico relacionado, exemplo /master-docs/product/epics/epi
 related_frd: {path FRD relacionado, exemplo /master-docs/product/frds/frd-001.md}
 
 # Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
-related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+related_discovery: {path do discovery de origem, exemplo $DISCOVERIES_DOCS/discovery-001-nome.md. Se não existir, ignore essa linha}
 
 # Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}

package/templates/product/prod-prd-template.md

@@ -35,7 +35,7 @@ related_prd: {Lista de PRDs que são relacionadas a esse PRD, se forem vários,
 related_frd: {Lista de FRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
 
 # Discovery de origem (o rascunho da ideia, anterior ao PRD). Remova a linha se não houver.
-related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
+related_discovery: {path do discovery de origem, exemplo $DISCOVERIES_DOCS/discovery-001-nome.md. Se não existir, ignore essa linha}
 
 # Data de criação (YYYY-MM-DD).
 created_at: {YYYY-MM-DD}

package/workflows/engineering/eng.plan.md

@@ -14,6 +14,7 @@ model_justification: Planejamento detalhado requer decomposição de tarefas com
 Este workflow cria um **plano de execução detalhado e faseado** para implementar a feature de forma incremental.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.plan-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 ---
 
@@ -164,10 +165,10 @@ CONTEXT_PROFILE:
 
 ### Fase 4: Validação
 
-1. **Apresentar** o plano ao humano
+1. **Apresentar** o plano ao humano, com o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`: `context.md`, `architecture.md` e o `plan.md` novo)
 2. **Discutir** ajustes necessários
 3. **Atualizar** `architecture.md` se houver mudanças arquiteturais
-4. **Confirmar** antes de prosseguir
+4. **Confirmar** antes de prosseguir, com a pergunta de transição (`eng.transitions-rules.md`): **"O que fazer com o plano?"** (depois da mensagem em markdown com o consolidado de links) → **Aprovar e implementar agora** (chame o `/eng.work {TASK_MANAGER_KEY}`, ou mostre o comando) / **Aprovar e seguir manualmente (como hoje)** (o comando termina e o usuário chama o `/eng.work` quando quiser) / **Ajustar o plano** (o usuário diz o que mudar; atualize o `plan.md` e mostre de novo). As duas aprovações valem como a aprovação explícita do plano
 
 ---
 

package/workflows/engineering/eng.pr.md

@@ -15,6 +15,7 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/PR-template.md`
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 ## Skills recomendados
 
@@ -43,8 +44,8 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 | Fase 1 › 1.4 Executar Testes Automatizados (Opcional) | `/eng-qa` + `QA_SPECIALIZATIONS` | Passo opcional, recomendado em mudanças significativas |
 | Skills recomendados | `/eng-global-docs-write` | Se houver necessidade de atualizar documentação junto do PR |
 | Agentes recomendados (opcional) | `eng.qa.test-planner` (agente) | Se houver dúvidas sobre cobertura de testes ou mudanças significativas |
-| Fase 4 › 4.4 Criar MR/PR via adapter | `jarvis vcs create-merge` (CLI do Jarvis) | Só se o usuário responder **Sim** na Fase 4.3: abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
-| Fase 5 › 5.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado (só com o Sim da 4.3): um único comentário no card com o link do MR, seguindo o Passo 6 do skill `eng-global-pr` (freelance pula) |
+| Fase 4 › 4.4 Criar MR/PR via adapter | `jarvis vcs create-merge` (CLI do Jarvis) | Só se a escolha da Fase 0 for publicar (4.3): abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
+| Fase 5 › 5.2 Link do MR | `/eng-global-task-comment` | Depois de o MR ser criado (só ao publicar, 4.3): um único comentário no card com o link do MR, seguindo o Passo 6 do skill `eng-global-pr` (freelance pula) |
 
 ---
 
@@ -66,6 +67,13 @@ Ler `TASK_MANAGER` do `$IDE/ENV.md`. Seguir `$IDE/rules/engineering/eng.integrat
 
 ---
 
+## Fase 0: O que fazer com o PR (`eng.transitions-rules.md`)
+
+Pergunte com `AskUserQuestion`: **"O que fazer com o PR?"**
+- **Revisar o texto e publicar (como hoje):** gera o `pull-request.md`, você aprova ou ajusta (4.2) e, com a aprovação, faz o push e abre o PR (4.4). A aprovação do texto é a confirmação da publicação.
+- **Publicar sem revisar o texto:** gera o `pull-request.md` (4.1), faz o push e abre o PR (4.4) sem a revisão (4.2); você ajusta o texto direto no PR.
+- **Só gerar os arquivos:** gera o `pull-request.md` (4.1), mostra para revisão (4.2) e não faz push nem abre o PR; você abre à mão. A Fase 7 gera o `daily.md` mesmo assim.
+
 ## Fase 1: Validação Pré-PR
 
 ### 1.1 Executar Testes Unitários
@@ -156,7 +164,27 @@ Refs: {TASK_MANAGER_KEY}"
 
 ## Fase 3: Push
 
-> ⚠️ O push só acontece **depois do Sim** da Fase 4.3. Esta fase descreve o comando; ele roda dentro da publicação.
+> ⚠️ O push só acontece **depois da escolha de publicar** (Fase 0 e 4.3). Esta fase descreve o comando; ele roda dentro da publicação.
+
+### 3.0 Conferir marcas de IA (só com `ARTIFACT_STYLE=human-generated`)
+
+Antes do push, siga `$IDE/rules/artifact-style-rules.md`: nada publicado leva marca de IA ou da IDE.
+
+```bash
+TERMOS='co-authored-by|generated with|claude|anthropic|chatgpt|openai|copilot|\bIA\b|\bAI\b|sub-?agent|advisor'
+RANGE=$(git rev-parse --abbrev-ref @{u} >/dev/null 2>&1 && echo '@{u}..HEAD' || echo '{BRANCH_BASE}..HEAD')
+git log --format='%h %B' $RANGE | grep -inE "$TERMOS"
+grep -inE "$TERMOS" $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md
+```
+
+Revise cada ocorrência antes de remover: a busca é larga e pode achar texto legítimo (ex.: `ai-generated`, um link para o PR).
+
+- **Nada encontrado (ou só falsos positivos):** siga para o push.
+- **No `pull-request.md`:** remova os trechos (o texto aprovado na 4.2 muda só nisso).
+- **Nas mensagens de commit:** reescreva **só os commits de `$RANGE`** (ainda não enviados), sem modo interativo, por exemplo, com `{ref}` = o início de `$RANGE` (`@{u}` ou `{BRANCH_BASE}`), `git rebase {ref} --exec 'M=$(git rev-parse --git-dir)/MSG_LIMPA; git log -1 --format=%B | sed -E "/^Co-Authored-By:/Id" > "$M" && git commit -q --amend -F "$M"'`, ajustando o `sed` aos termos achados. Depois, rode a busca de novo.
+- **Commit já enviado com marca:** não reescreva; avise o usuário e pare.
+
+Informe no resumo o que foi removido. Com `ai-generated` (ou vazio), pule este passo.
 
 ### 3.1 Enviar para Remote
 
@@ -201,18 +229,18 @@ Preencher com a tarefa. Link do card:
 
 `{TASK_MANAGER_KEY}` = `{TASK_MANAGER_KEY}`.
 
-> ⚠️ Não mencione AI, Claude ou assistentes no MR/PR.
+> ⚠️ Não mencione AI, Claude ou assistentes no MR/PR. Com `ARTIFACT_STYLE=human-generated`, também sem "Generated with …" nem link da ferramenta (`rules/artifact-style-rules.md`).
 
 ### 4.2 Revisão do texto
 
-Mostre o `pull-request.md` (título e resumo das seções) e pergunte com `AskUserQuestion`: `[Aprovar]` / `[Ajustar]`. Ajuste até a aprovação.
+Mostre o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`, com o `pull-request.md` novo), o título e o resumo das seções e pergunte com `AskUserQuestion` (depois da mensagem com o consolidado de links): `[Aprovar]` / `[Ajustar]`. Ajuste até a aprovação. (Pulada com "Publicar sem revisar o texto" na Fase 0.)
 
-### 4.3 Publicar? (Sim / Não)
+### 4.3 Publicar ou não (sem pergunta nova)
 
-Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar o PR agora?"**
+A decisão já veio da Fase 0; não pergunte de novo. Aprovado o texto na 4.2, siga a escolha:
 
-- **Não:** nada é enviado. O `pull-request.md` fica na sessão para você publicar quando quiser (à mão ou rodando o `/eng.pr` de novo). Pule para a Fase 7 (sem `daily.md`, que só existe com PR aberto), com a mensagem "PR não publicado".
-- **Sim:** faça o push (Fase 3) e crie o MR/PR (4.4).
+- **Só gerar os arquivos:** nada é enviado. O `pull-request.md` fica na sessão para você publicar quando quiser (à mão ou rodando o `/eng.pr` de novo). Pule para a Fase 7, que gera o `daily.md` mesmo assim (para não passar batido quando você abrir o PR à mão), com a mensagem "PR não publicado".
+- **Revisar o texto e publicar** ou **Publicar sem revisar o texto:** faça o push (Fase 3) e crie o MR/PR (4.4).
 
 ### 4.4 Criar MR/PR via adapter
 
@@ -327,7 +355,7 @@ fi
 
 Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"); template em `$IDE/templates/engineering/daily-template.md`. Arquivo: `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/daily.md`, **só na sessão, nunca publicado**.
 
-1. **Há PR aberto?** Vale o criado na 4.4 ou o PR da branch que já existe e está aberto (CLI/adapter do vendor, ex.: `gh pr view --json state,number,url`). Sem PR aberto (Não na 4.3 e nenhum PR existente), **não gere** o `daily.md` e siga para a 7.3. Se não for possível confirmar, pergunte.
+1. **Gere sempre**, com ou sem PR publicado: quem abre o PR à mão ("Só gerar os arquivos" na Fase 0) também precisa do registro, e é aí que ele costuma passar batido. Se houver PR (o criado na 4.4 ou o PR já aberto da branch, via CLI/adapter do vendor, ex.: `gh pr view --json state,number,url`), preencha o campo `pr`; sem PR, deixe-o vazio e atualize quando o PR for aberto.
 2. **Data:** pergunte com `AskUserQuestion`: **"Registrar o esforço com qual data?"** → `Hoje ({AAAA-MM-DD})` | `Outra data` (o usuário digita `AAAA-MM-DD`).
 3. **Dias trabalhados** (só se o período entre a data do `.timestamp_start` e a data do registro tiver mais de um dia), uma pergunta por vez:
    - se o período tiver sábado ou domingo: **"Você trabalhou em {datas de sábado/domingo}?"** (Sim / Não; com várias datas, pode responder por data);
@@ -348,7 +376,7 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
    - **Descrição:** um parágrafo narrativo (contexto técnico, trabalho realizado, decisões), mais o *post mortem* quando couber (problema e causa raiz, investigação, solução/direcionamento), com detalhe suficiente para embasar questionamentos futuros.
    - **Timesheet:** **uma única linha** (`{TASK_KEY} — {resumo}`).
    - Sem e-mails, tokens nem valores de variáveis.
-7. **Revisão conjunta:** mostre a descrição e a linha de timesheet **juntas** e pergunte com `AskUserQuestion`: `[Aprovar]` / `[Ajustar]`. Com Ajustar, aplique os ajustes pontuais **nas duas** e mostre de novo, até aprovar.
+7. **Revisão conjunta:** mostre a descrição e a linha de timesheet **juntas** e pergunte com `AskUserQuestion` (depois da mensagem com o consolidado de links, com o `daily.md` novo): `[Aprovar]` / `[Ajustar]`. Com Ajustar, aplique os ajustes pontuais **nas duas** e mostre de novo, até aprovar.
 
 ### 7.3 Mensagem Final
 
@@ -367,13 +395,19 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 
 {LEAD_TIME_MSG}
 
-📝 Daily: $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/daily.md
+📄 Arquivos da sessão (consolidado acumulado, regra 5 de `eng.transitions-rules.md`; só os que existem):
+- [context.md]({caminho relativo}) ({nota de estado})
+- [architecture.md]({caminho relativo}) ({nota de estado})
+- [plan.md]({caminho relativo}) ({nota de estado})
+- [gate-checklist.md]({caminho relativo}) ({nota de estado})  ← se o `eng.pre-pr` rodou
+- [pull-request.md]({caminho relativo}) (novo; {publicado como PR #N | gerado, PR não publicado})
+- [daily.md]({caminho relativo}) (novo; {aprovado, com timesheet})
 🕒 Timesheet: {LINHA_DE_TIMESHEET_APROVADA}
 
 📌 Próximos passos:
-1. /eng.spec-consolidate {TASK_MANAGER_KEY} → registrar no Central docs o que esta entrega implementou
-2. Aguardar revisão do time e processar os comentários do code review
-3. Merge após aprovação
+1. Aguardar revisão do time e processar os comentários do code review
+2. Merge após aprovação
+3. /eng.spec-consolidate {TASK_MANAGER_KEY} depois do merge → registrar no Central docs o que esta entrega implementou
 
 🗂️ A sessão $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ não é apagada (o /eng.spec-consolidate precisa dela).
    Remova à mão quando quiser.
@@ -383,6 +417,16 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 - Jira: {TASK_MANAGER_URL_BASE}/browse/{TASK_MANAGER_KEY}
 ```
 
+### 7.4 Versões humanizadas (só com `ARTIFACT_STYLE=human-generated`)
+
+Pergunte uma vez, com `AskUserQuestion` de várias perguntas em abas (`rules/artifact-style-rules.md`, regra 2), uma aba por documento da sessão que existir: `architecture.md`, `plan.md`, `gate-checklist.md` e `daily.md` (o `pull-request.md` não entra: já é público). Cada aba: **"Gerar a versão humanizada de {documento}?"** → **Não (como hoje)** / **Sim**. Com Sim, grave `{nome}.public.md` ao lado do original, seguindo o checklist da regra, e mostre o link. Com outro `ARTIFACT_STYLE`, pule esta etapa.
+
+### 7.5 PR mergeado? (`eng.transitions-rules.md`)
+
+Pergunte com `AskUserQuestion`: **"O PR já foi aprovado e mergeado?"**
+- **Ainda não (como hoje):** encerre com a mensagem acima.
+- **Sim, rodar o `/eng.spec-consolidate`:** chame o `/eng.spec-consolidate {TASK_MANAGER_KEY}` (ou mostre o comando).
+
 ## Regras Importantes
 
 ### ⛔ NÃO FAÇA
@@ -401,7 +445,7 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 - ✅ Criar branch no padrão `{TASK_MANAGER_KEY}-{titulo}`
 - ✅ Preencher template do MR completamente
 - ✅ Mover card para "In Review"
-- ✅ Gerar o `pull-request.md` na sessão e só publicar com o **Sim** (Fase 4.3)
+- ✅ Gerar o `pull-request.md` na sessão e só publicar com a escolha de publicar da Fase 0 (4.3)
 - ✅ Com PR aberto, registrar o esforço no `daily.md` (7.2), com revisão conjunta da descrição e do timesheet
 - ✅ **Nunca apagar a sessão:** o `/eng.spec-consolidate` precisa dela
 

package/workflows/engineering/eng.pre-pr.md

@@ -15,6 +15,7 @@ Antes de abrir o PR/MR, este comando **revê a branch atrás de possíveis lacun
 > ⚠️ **Só revisa.** O `eng.pre-pr` não corrige código, não escreve testes, não atualiza documentação e não publica nada no Central docs. Ele aponta; quem decide e ajusta é você (ou o `eng.work`, se pedir).
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pre-pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 ## Skills recomendados
 
@@ -51,7 +52,7 @@ Antes de abrir o PR/MR, este comando **revê a branch atrás de possíveis lacun
 | Gates › item 8 | `eng.ux-designer.agent` (agente) | Se a branch introduzir nova feature de UI ou alterar fluxo de usuário |
 | Gates › item 9 | `eng.docs-writer` (agente) | Sempre — apontar documentação do projeto desatualizada (sem editar) |
 | Gates › item 10 | Nenhuma — checklist inline | Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos |
-| Publicação do relatório | `/eng-global-task-comment` | Só se o usuário responder **Sim** no fim: o `gate-checklist.md` com as decisões vira um comentário na issue/card (freelance pula) |
+| Publicação do relatório | `/eng-global-task-comment` | Só se o usuário escolher um dos **Sim** no fim: o resumo ou o `gate-checklist.md` completo, com as decisões, vira um comentário na issue/card (freelance pula, sem perguntar) |
 
 ## Regras de Execução
 
@@ -90,7 +91,7 @@ Grave em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/gate-checklist.md`:
 
 | # | Lacuna | Onde | Por que importa | Sugestão | Severidade | Decisão |
 |---|---|---|---|---|---|---|
-| 1 | {o que falta ou está errado} | `{arquivo:linha}` | {impacto, em linguagem simples} | {como resolver} | 🔴 Bloqueador / 🟡 Importante / ⚪ Menor | {Ajustar \| Não ajustar: motivo} |
+| 1 | {o que falta ou está errado} | `{arquivo:linha}` | {impacto, em linguagem simples} | {como resolver} | 🔴 Bloqueador / 🟡 Importante / ⚪ Menor | {Corrigir \| Aceitar: motivo} |
 
 (uma tabela por área; área sem lacuna: "Nenhuma lacuna encontrada.")
 
@@ -107,9 +108,21 @@ A coluna **Decisão** nasce vazia: quem preenche é o usuário.
 
 ## Fechamento
 
-1. Mostre o semáforo, o resumo e a lista de lacunas por severidade, com o caminho do `gate-checklist.md`.
-2. Peça as decisões: para cada lacuna 🔴 e 🟡, "Ajustar" ou "Não ajustar" (com o motivo). Use `AskUserQuestion` por lacuna quando houver poucas; com muitas, deixe a pessoa responder em texto ou editar o arquivo. Grave as decisões na coluna **Decisão**.
-3. Pergunte com `AskUserQuestion` (**Sim / Não**, sempre, nunca publicar sem a resposta): **"Publicar o gate-checklist.md (com as decisões) como comentário na issue/card?"**
-   - **Sim** (e `TASK_MANAGER` preenchido): `/eng-global-task-comment {TASK_MANAGER_KEY}` com o conteúdo do arquivo.
-   - **Não**, ou modo freelance: fica só na sessão.
-4. Próximo passo: ajustar o que foi marcado "Ajustar" (à mão ou com o `/eng.work`) e rodar o `/eng.pr`, que usa o PR Brief deste relatório.
+1. Mostre o semáforo, o resumo e a lista de lacunas por severidade, com o consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`: tudo o que já existe, com o `gate-checklist.md` novo).
+2. Peça as decisões com `AskUserQuestion`, depois da mensagem em markdown do passo 1 (com o link clicável): **"O que fazer com as {n} lacunas encontradas ({a} 🔴 bloqueadoras, {b} 🟡 importantes)? Relatório: gate-checklist.md."**
+   - **Corrigir todas antes do PR:** marca as {n} como "Corrigir"; você corrige à mão ou com o `/eng.work`.
+   - **Corrigir só as bloqueadoras 🔴:** marca as {a} 🔴 como "Corrigir"; as 🟡 ficam "Aceitar", com um motivo só, pedido uma vez.
+   - **Decidir uma a uma:** mostra cada lacuna 🔴 e 🟡 e você escolhe "Corrigir" ou "Aceitar" (com o motivo), com `AskUserQuestion` por lacuna.
+   - **Só gerar o relatório (vou analisar com calma):** não registra decisão agora; a coluna **Decisão** fica vazia, o `gate-checklist.md` fica na sessão para você analisar e o comando termina sem as perguntas 3 e 4. Rode o `/eng.pre-pr` de novo, ou preencha o arquivo à mão, quando decidir.
+
+   Grave as decisões na coluna **Decisão** como `Corrigir` ou `Aceitar: motivo`.
+3. **Modo freelance (`TASK_MANAGER` vazio):** não pergunte; o relatório fica só na sessão. **Com board**, pergunte com `AskUserQuestion` (nunca publique sem a resposta): **"Registrar o resultado do `/eng.pre-pr` como comentário no card {TASK_MANAGER_KEY}?"**
+   - **Não, manter só na sessão (como hoje):** nada é enviado ao card.
+   - **Sim, só o resumo:** `/eng-global-task-comment {TASK_MANAGER_KEY}` com o semáforo, o resumo e as lacunas 🔴 com a decisão de cada uma.
+   - **Sim, o relatório completo:** `/eng-global-task-comment {TASK_MANAGER_KEY}` com o conteúdo do `gate-checklist.md`.
+4. Próximo passo: corrigir o que foi marcado "Corrigir" (à mão ou com o `/eng.work`) e rodar o `/eng.pr`, que usa o PR Brief deste relatório. Antes, escreva uma mensagem em markdown com o consolidado de links da sessão (regra 5) e o resumo; depois pergunte com `AskUserQuestion` (`eng.transitions-rules.md`):
+   - **Com {n} lacunas marcadas "Corrigir"** — **"O `/eng.pre-pr` encontrou {n} lacunas a corrigir ({a} 🔴, {b} 🟡). Leia o gate-checklist.md com calma e responda quando decidir. Como seguir?"**
+     - **Corrigir as lacunas agora:** chame o `/eng.work {TASK_MANAGER_KEY}` para as {n} lacunas (ou mostre o comando).
+     - **Parar aqui para corrigir à mão (como hoje):** o comando termina.
+     - **Abrir o PR assim mesmo:** chame o `/eng.pr {TASK_MANAGER_KEY}`; as {n} pendências seguem registradas no PR Brief.
+   - **Sem lacunas a corrigir** — **"Relatório sem lacunas a corrigir (gate-checklist.md). Como seguir?"**: **Abrir o PR agora** (chame o `/eng.pr {TASK_MANAGER_KEY}`) / **Parar aqui (como hoje)**.

package/workflows/engineering/eng.spec-consolidate.md

@@ -10,7 +10,9 @@ model_justification: Consolidar exige ler e cruzar muitas fontes (documentos, de
 
 # Consolidar no Central docs
 
-Este comando registra no **Central docs** o que a entrega **de fato implementou**. Ele roda **logo depois do PR aberto** (`/eng.pr`) e gera dois documentos completos e autossuficientes:
+> 🔀 **Consolidado de links**: na mensagem final (Passo 7), siga a regra 5 de `$IDE/rules-on-demand/engineering/eng.transitions-rules.md`: liste, como links clicáveis, todos os arquivos da sessão que já existem.
+
+Este comando registra no **Central docs** o que a entrega **de fato implementou**. Ele roda **depois do merge do PR** (o `/eng.pr` pergunta no fim se o PR já foi mergeado e oferece chamá-lo) e gera dois documentos completos e autossuficientes:
 - o **documento da funcionalidade** (`feature-{slug}.md`), com o estado atual, novo ou atualizado;
 - o **registro da entrega** (`delivery-{AAAA-MM-DD}-{task_key}.md`), com o PR, os commits e os autores.
 
@@ -110,11 +112,15 @@ Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar no Central docs?"**
   (no `--inicial`, só os `feature-*`). Com o Central docs num repositório git, cada publicação abre um PR no repositório de documentação: informe as URLs.
 - **Não:** os arquivos ficam na sessão. Para publicar depois, use os mesmos comandos.
 
+Com `ARTIFACT_STYLE=human-generated`, a versão humanizada (`{nome}.public.md`) fica ao lado da consolidação, na sessão, e **não** é publicada.
+
 ## Passo 7: Mensagem final
 
 ```
 ✅ Consolidação {publicada | salva na sessão}
 
+📄 Arquivos da sessão (consolidado acumulado, regra 5 de `eng.transitions-rules.md`): links de `context.md`, `architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md` e dos arquivos de `consolidation/` (novos), só os que existem
+
 📄 Funcionalidade: {SQUAD}/product/{produto}/feature-{slug}.md
 🧾 Entrega:        {SQUAD}/engineering/{produto}/delivery-{AAAA-MM-DD}-{task_key}.md
 🔗 PR/MR: {URL} · Card: {URL ou número}

package/workflows/engineering/eng.start.md

@@ -15,6 +15,7 @@ Este comando inicia o **planejamento** de uma nova feature.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.start-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/architecture-template.md`
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 > ⚠️ **IMPORTANTE**: Este workflow é APENAS para planejamento e documentação.
 > **NÃO execute código, NÃO crie arquivos de código, NÃO faça commits.**
@@ -129,7 +130,11 @@ Se `$SESSIONS_DIR/warm-ups/` tiver aquecimentos, leia `$IDE/rules-on-demand/warm
 
 ## Fase 0.5: Advisor (opcional)
 
-Logo depois de obter o `TASK_MANAGER_KEY`, pergunte com `AskUserQuestion` (sem a ferramenta, use a tabela de `prod-rules.md`): **"Usar o Advisor nas questões em aberto desta tarefa?"** (**Não**, padrão / **Sim**). Com **Não**, siga como sempre e não mencione mais o Advisor.
+Logo depois de obter o `TASK_MANAGER_KEY`, pergunte com `AskUserQuestion` (sem a ferramenta, use a tabela de `prod-rules.md`): **"Usar o Advisor nas questões em aberto desta tarefa?"** (**Não**, padrão / **Sim**). Com **Não**, siga como sempre e não mencione mais o Advisor. Em seguida (só sem Advisor), pergunte **"Como tratar as questões em aberto que surgirem?"**:
+- **Tratar no architecture.md (como hoje):** as questões vão para a seção 8 e você as responde ao revisar o documento.
+- **Uma a uma, assim que surgirem:** cada questão encontrada nas Fases 2 e 3 é perguntada na hora com `AskUserQuestion` (contexto em uma frase, opções e a sugestão marcada "(Recomendada)"), e entra na seção 8 já respondida.
+
+Registre a escolha no cabeçalho do `architecture.md` (`Questões em aberto:`).
 
 Com **Sim**, pergunte **"Qual modelo para o Advisor?"** com os itens de `ADVISOR_MODELS` do `ENV.md` (até 4 opções; o resto em "Outro"). Lista vazia ou ausente: use `Sonnet 5.5` sem perguntar; lista de um item: use-o sem perguntar. Traduza o nome pela família (primeira palavra em minúsculas: `sonnet`, `opus`, `fable`, `haiku`); se o modelo não for aceito pela IDE, use `sonnet` e avise em uma linha. Se a IDE não permitir escolher o modelo do subagente, avise e não faça a segunda pergunta.
 
@@ -283,6 +288,8 @@ Use ferramentas de busca para entender o código existente:
 - **Grep**: Buscar padrões e implementações similares
 - **Read**: Analisar arquivos críticos que serão impactados
 
+Com `WORKSPACE_MODE=workspace`, busque só nos repositórios do workspace e siga a regra "Buscas de código em modo workspace" de `eng-rules.md` (ignora `$IDE/`, `.jarvis/`, `.vscode/`, `node_modules/` e o `CDD-MIND-MAP.md`; `docs/jarvis/` é lida como documento de trabalho).
+
 ### 3.2 Documentação Existente
 
 Verifique:
@@ -394,7 +401,7 @@ Levante na seção 8 **tudo** que for diferente do código ou ambíguo no card,
 3. Preencha "Sugestão do Sub-Agent (Advisor)", **"Decisão adotada" (a sugestão do Advisor, que prevalece; não a substitua nem a conteste)**, "Divergência" e "Impacto da decisão". Confira no código os fatos em que a sugestão se apoia antes de registrar.
 4. Poste **um** comentário de auditoria na issue com `/eng-global-task-comment`, no modelo do template (freelance pula).
 
-**Sem Advisor:** apresente as questões ao usuário, como sempre.
+**Sem Advisor:** com "Tratar no architecture.md (como hoje)", apresente as questões ao usuário, como sempre; com "Uma a uma", elas já foram respondidas ao surgir (registre as respostas e escreva só as que surgirem na escrita do documento).
 
 ---
 
@@ -407,7 +414,7 @@ Apresente:
 1. Resumo do que foi documentado
 2. Principais decisões arquiteturais
 3. Riscos identificados
-4. Link para o arquivo criado
+4. Consolidado de links da sessão (regra 5 de `eng.transitions-rules.md`): `context.md` (novo; tipo e autonomia) e `architecture.md` (novo; quantas questões em aberto) e o aquecimento consumido, se houver, cada um com a nota de estado, mais os links do card/issue
 
 ### 5.2 Iteração
 
@@ -417,6 +424,7 @@ Se o usuário tiver feedback:
 - Apresente novamente
 - Continue até aprovação explícita
 
+**Sem Advisor**, a aprovação é a pergunta de transição (`eng.transitions-rules.md`): **"Aprovar o architecture.md?"** (depois da mensagem em markdown com o link clicável do arquivo) → **Aprovar e parar aqui (como hoje)** / **Aprovar e seguir para o `/eng.plan`** / **Ajustar o documento**. Com "seguir", chame o `/eng.plan {TASK_MANAGER_KEY}` (ou mostre o comando).
 **Com Advisor**, o gate segue a autonomia do `context.md` (CDD): `alta` → apresente o resumo e siga para o `eng.plan` sem aguardar; `média` ou `baixa` → aguarde a aprovação explícita. Sem `context.md`, use a tabela "Autonomia por POSITION" de `eng-rules.md`. Sem Advisor, nada muda.
 
 ### 5.3 Atualizar Board

package/workflows/engineering/eng.work.md

@@ -15,6 +15,7 @@ Este comando executa a **implementação de código** seguindo o plano de execu
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.work-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/work-progress-template.md`
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 > ⚠️ **IMPORTANTE**: Este workflow é para codificação com commits incrementais por fase.
 > **NÃO crie PRs, NÃO faça push**, mas **FAZ commit ao final de cada fase validada.**
@@ -169,6 +170,20 @@ Procure no `plan.md`:
 - Fase marcada como `[Em Progresso ⏰]`
 - Se nenhuma, identifique a primeira `[Não Iniciada ⏳]`
 
+### 1.3 Escolhas do início (`eng.transitions-rules.md`)
+
+Pergunte com `AskUserQuestion`, uma pergunta por decisão (padrão primeiro):
+
+| Pergunta | Opções |
+|---|---|
+| **Execução das fases** | **Fase a fase, com aprovação (como hoje)** / **Todas de uma vez** (mostre "N de M tarefas", com N pelo limite `MAX_AI_EXECUTION_PERCENTAGE` abaixo) |
+| **Commits** | **Um por fase (como hoje)** / **Um commit só ao final** |
+| **Depois do work** | **Rodar o `/eng.pre-pr`** / **Rodar o `/eng.pr`** (sem o `/eng.pre-pr`) / **Fluxo normal (como hoje)** (só a mensagem final; o usuário segue os próximos comandos manualmente) |
+
+- Grave as escolhas no cabeçalho do `plan.md` (`Execução:`, `Commits:`, `Depois do work:`). Retomada com escolhas já gravadas: uma pergunta só, **"Manter as escolhas ({resumo})?"** (Manter / Mudar).
+- **Em qualquer escolha**, o limite de execução, um teste falhando e uma questão nova em aberto **param** a execução e voltam a perguntar.
+- Com **Todas de uma vez**, a escolha é a aprovação das fases: as pausas da Fase 2.2 e da 6.1 não acontecem.
+
 ---
 
 ## Fase 2: Planejamento da Implementação
@@ -202,7 +217,7 @@ Apresente ao usuário:
 
 ### 2.2 Aguardar Aprovação
 
-**PARE e aguarde confirmação do usuário antes de implementar.**
+**PARE e aguarde confirmação do usuário antes de implementar** (com "Fase a fase"; com "Todas de uma vez", siga direto).
 
 Se o usuário tiver sugestões, ajuste o plano.
 
@@ -441,7 +456,7 @@ Refs: {TASK_MANAGER_KEY}"
 
 **Regras de commit:**
 - Sempre referenciar o `TASK_MANAGER_KEY` no início e no `Refs:`
-- Uma fase = um commit (agrupar todas as mudanças da fase)
+- Uma fase = um commit (agrupar todas as mudanças da fase), com "Um por fase"; com "Um commit só ao final", um commit depois da última fase, com todos os testes passando
 - Tipo: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`
 - **NUNCA** usar `git add .` — adicionar arquivos individualmente
 
@@ -480,7 +495,7 @@ Refs: TASK-123"
 ❓ Deseja iniciar a Fase {N+1}?
 ```
 
-**AGUARDE confirmação antes de iniciar.**
+**AGUARDE confirmação antes de iniciar** (com "Fase a fase"; com "Todas de uma vez", siga para a próxima fase).
 
 ### 6.2 Se Todas as Fases Foram Concluídas
 
@@ -488,7 +503,7 @@ Refs: TASK-123"
 🎉 TODAS AS FASES CONCLUÍDAS!
 
 📁 Sessão: $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/
-📄 Plan atualizado: plan.md ✅
+📄 Arquivos da sessão (consolidado acumulado, regra 5 de `eng.transitions-rules.md`): links de `context.md`, `architecture.md` e `plan.md` (atualizado, com comentários por fase; quantas fases concluídas), cada um com a nota de estado, mais os links do card/issue
 🌿 Branch: {TASK_MANAGER_KEY}-{titulo} — {N} commits realizados
 
 📊 Resumo:
@@ -506,6 +521,8 @@ Refs: TASK-123"
 ⚠️ LEMBRETE: push e PR são responsabilidade do `eng.pr`.
 ```
 
+Depois da mensagem, siga a escolha **Depois do work**: chamar o `/eng.pre-pr {TASK_MANAGER_KEY}`, chamar o `/eng.pr {TASK_MANAGER_KEY}`, fazer o que o usuário descreveu em texto livre (o "Outros" automático) ou, no **Fluxo normal (como hoje)**, só encerrar com a mensagem (chamar = pelo Skill tool, ou mostrar o comando pronto na IDE que não permite).
+
 ## Regras Importantes
 
 ### ⛔ NÃO FAÇA
@@ -513,10 +530,10 @@ Refs: TASK-123"
 - ❌ NÃO crie Pull Requests
 - ❌ NÃO faça push (`git push`) — push é responsabilidade do `eng.pr`
 - ❌ NÃO use `git add .` — adicionar arquivos individualmente
-- ❌ NÃO commite sem aprovação explícita do usuário na fase
+- ❌ NÃO commite sem aprovação explícita do usuário na fase (a escolha "Todas de uma vez" da 1.3 é essa aprovação)
 - ❌ NÃO commite com testes falhando
 - ❌ NÃO mova cards no Jira
-- ❌ NÃO sugira "vamos fazer o PR agora"
+- ❌ NÃO sugira "vamos fazer o PR agora" (salvo a escolha "Rodar o `/eng.pr`" da 1.3)
 
 ### ✅ FAÇA SEMPRE
 

package/workflows/product/prod.spec.discovery.md

@@ -16,7 +16,7 @@ model_justification: Discovery exige separar fatos de suposições, escolher as
 
 > 🔥 **Warm-up**: se `$SESSIONS_DIR/warm-ups/` tiver aquecimentos, leia `$IDE/rules-on-demand/warm-up-consume-rules.md` e siga-o antes de começar (grava em `$SESSIONS_DIR/prod/{id do documento}/context.md`).
 
-Investiga uma ideia crua com **poucas perguntas certas** e grava um **rascunho** em `$PROD_DOCS/discoveries/discovery-{id}-{nome}.md`, pelo template `$PROD_TEMPLATES/prod-discovery-template.md`. Postura: agente `$IDE/agents/product/prod.discovery-interviewer.md`. Guia humano: `docs/produto/prod.spec.discovery.md`. Siga `$PROD_RULES` (ENV, idioma, `AskUserQuestion` uma pergunta por vez).
+Investiga uma ideia crua com **poucas perguntas certas** e grava um **rascunho** em `$DISCOVERIES_DOCS/discovery-{id}-{nome}.md`, pelo template `$PROD_TEMPLATES/prod-discovery-template.md`. Postura: agente `$IDE/agents/product/prod.discovery-interviewer.md`. Guia humano: `docs/produto/prod.spec.discovery.md`. Siga `$PROD_RULES` (ENV, idioma, `AskUserQuestion` uma pergunta por vez).
 
 <requirement>
 #$ARGUMENTS
@@ -39,7 +39,7 @@ Sem ideia: pergunte qual é, antes de tudo. Caminho, nome ou id de um discovery
 
 ## Passo 1 — Ler em silêncio
 
-Antes de perguntar qualquer coisa, leia: o `$ARGUMENTS`; em `$PROD_DOCS`, os PRD/FRD que já cobrem a ideia e os discoveries parecidos (só título e Entendimento/Ideia); o código e os commits, se ajudarem a viabilidade; o Central docs, se configurado. Não repita perguntas cuja resposta já está em algum desses.
+Antes de perguntar qualquer coisa, leia: o `$ARGUMENTS`; em `$PROD_DOCS`, os PRD/FRD que já cobrem a ideia; em `$DISCOVERIES_DOCS`, os discoveries parecidos (só título e Entendimento/Ideia); o código e os commits, se ajudarem a viabilidade; o Central docs, se configurado. Não repita perguntas cuja resposta já está em algum desses.
 
 ## Passo 2 — Entendimento (uma confirmação)
 

package/workflows/warm-up.md

@@ -28,7 +28,7 @@ As rules já estão no contexto da sessão: **não as releia**. Perfil de comuni
 ## Passo 1 — Perfil (silencioso)
 
 ```bash
-grep -E "^(POSITION|AREA|HUB|SQUAD|WORKSPACE|WORKSPACE_REPOS|PROD_MODE|ENABLE_CDD|CENTRAL_DOCS_STORAGE|[A-Z]+_SPECIALIZATIONS)=" $IDE/ENV.md
+grep -E "^(POSITION|AREA|HUB|SQUAD|WORKSPACE|WORKSPACE_REPOS|WORKSPACE_MODE|PROD_MODE|ENABLE_CDD|CENTRAL_DOCS_STORAGE|[A-Z]+_SPECIALIZATIONS)=" $IDE/ENV.md
 ```
 
 `$IDE/ENV.md` pode estar num ancestral do cwd. `WORKSPACE` vazio = nome da pasta que contém `$IDE/`. Não invente valores ausentes; não pergunte o que está no ENV.
@@ -37,7 +37,7 @@ grep -E "^(POSITION|AREA|HUB|SQUAD|WORKSPACE|WORKSPACE_REPOS|PROD_MODE|ENABLE_CD
 
 O mapa é o **contexto de workspace**: stack e papel de cada repositório. Fica na raiz do workspace (ao lado do `AGENTS.md`), fora do versionamento. Formato e instruções de preenchimento: `$IDE/templates/cdd-mind-map-template.md`.
 
-1. **Repositórios do workspace:** os de `WORKSPACE_REPOS` ou, se vazia, as subpastas com `.git/`; só a raiz com `.git` = projeto único (uma linha).
+1. **Repositórios do workspace:** use o `WORKSPACE_MODE` do ENV. `workspace`: os de `WORKSPACE_REPOS` ou, se vazia, as subpastas com `.git/` (a raiz não é repositório, mesmo com uma subpasta só). `project`: a raiz, uma linha. Reconfira pelo critério (raiz com `.git` = `project`; raiz sem `.git` e 1+ subpastas com `.git/` = `workspace`) e, se o valor gravado divergir do detectado ou estiver ausente, avise e sugira `jarvis init --upgrade`, sem alterar o ENV. Nas buscas de código vale a regra "Buscas de código em modo workspace" de `eng-rules.md`.
 2. **Mapa não existe:** infira cada repositório pela tabela `$IDE/skills/jarvis-init/assets/sinais-de-stack.md` e pela estrutura (papel), mostre a tabela e pergunte com `AskUserQuestion`: **Confirmar** | **Corrigir** | **Incluir informação**. Repita até confirmar. Então:
    - grave `CDD-MIND-MAP.md` na raiz do workspace;
    - garanta a linha no `.gitignore`: `grep -qxF 'CDD-MIND-MAP.md' .gitignore 2>/dev/null || echo 'CDD-MIND-MAP.md' >> .gitignore`;