jarvis-ai-framework 5.5.0 → 5.6.0

package/AGENTS.md

@@ -194,7 +194,7 @@ Comandos disponíveis:
 jarvis whoami   [--logout]                          # Exibir identidade (ENV.md / git / SO)
 jarvis logout                                       # Remover auth.json legado (opcional)
 jarvis init                                         # Bootstrap do framework no projeto
-jarvis init --upgrade [--ide X] [--yes]             # Atualizar projeto existente: assets + variáveis novas do ENV + documentos nas pastas novas
+jarvis init --upgrade [--ide X] [--yes] [--remove-stale]   # Atualizar projeto existente: assets + variáveis novas do ENV (inclui WORKSPACE_MODE) + documentos nas pastas novas + lista/remove skills antigos
 jarvis list                                         # Listar agents, skills e workflows
 jarvis install-rtk                                  # Instalar RTK (token killer — economia 60-90% em tokens de shell)
 jarvis tokens    [--hub X --position Y --area Z --squad W] [--rtk] [--json]   # Estimar o que carrega no início da sessão (perfil do ENV.md se sem flags)

package/README.md

@@ -119,7 +119,7 @@ npm install -g jarvis-ai-framework@latest
 jarvis init --upgrade --ide {ide}   # assets + variáveis novas do ENV.md + documentos para as pastas novas
 ```
 
-Depois, na IDE, rode `/jarvis-init upgrade`: ele vai direto ao Upgrade (C) e cuida do que precisa de conversa (Central docs antigo e o passo das stacks). O `--upgrade` só **acrescenta** chaves ao `ENV.md`: nenhuma chave existente muda. Ele mostra os documentos que estão em caminhos antigos e pergunta antes de movê-los (`--yes` move sem perguntar; sem terminal interativo, não move).
+Depois, na IDE, rode `/jarvis-init upgrade`: ele vai direto ao Upgrade (C) e cuida do que precisa de conversa (Central docs antigo e o passo das stacks). O `--upgrade` só **acrescenta** chaves ao `ENV.md`: nenhuma chave existente muda. Ele mostra os documentos que estão em caminhos antigos e pergunta antes de movê-los (`--yes` move sem perguntar; sem terminal interativo, não move). Também lista os skills instalados que saíram do framework e pergunta antes de removê-los (`--remove-stale` remove sem perguntar só os listados; skills registrados em `*_SPECIALIZATIONS` nunca são listados).
 
 **Instalou via clone local** (fluxo de [Desenvolvendo o Jarvis localmente](#desenvolvendo-o-jarvis-localmente)) — quando o repo no GitHub ganhar commits novos, sincronize assim:
 

package/bin/commands/init.js

@@ -16,6 +16,11 @@ import { getPackageInfo, getFrameworkRoot } from "../lib/utils/paths.js";
 import { logger, configureFromFlags } from "../lib/utils/logger.js";
 import { resolveEnvPath } from "../lib/env-loader.js";
 import { LOCK_FILE } from "../lib/config/constants.js";
+import {
+  findStaleSkills,
+  registeredSpecializations,
+  removeStaleSkills,
+} from "../lib/core/stale-skills.js";
 import { parseEnvEntries, planEnvUpgrade, applyEnvUpgrade } from "../lib/core/env-upgrade.js";
 import {
   expandEnv,
@@ -283,7 +288,7 @@ async function runUpgrade(cwd, flags) {
     join(getFrameworkRoot(), "templates", "ENV-template.md"),
     "utf-8"
   );
-  const envPlan = planEnvUpgrade(envText, templateText);
+  const envPlan = planEnvUpgrade(envText, templateText, { workspaceDir });
   const addedKeys = envPlan.added.map((a) => a.key);
 
   // 3. Documentos: o plano usa o ENV como ficará depois do upgrade (com as chaves novas)
@@ -313,6 +318,34 @@ async function runUpgrade(cwd, flags) {
   const today = new Date().toISOString().slice(0, 10);
   applyEnvUpgrade(envPath, envPlan, today, overrides);
 
+  // 3.1 Skills instalados que saíram do framework: só lista; remove com confirmação ou --remove-stale
+  const ideSkillsDir = join(workspaceDir, `.${getIDEFolder(ide)}`, "skills");
+  const stale = findStaleSkills({
+    ideSkillsDir,
+    frameworkSkillsDir: join(getFrameworkRoot(), "skills"),
+    registered: registeredSpecializations(parseEnvEntries(envText)),
+  });
+  let staleRemoved = [];
+  let staleErrors = [];
+  if (stale.length > 0) {
+    logger.info(`${YELLOW}🧹 Skills instalados que saíram do framework:${NC}`);
+    for (const name of stale) logger.info(`  .${getIDEFolder(ide)}/skills/${name}/`);
+    let confirmed = Boolean(flags.removeStale);
+    if (!confirmed && !flags.yes && process.stdin.isTTY) {
+      const rl = createInterface({ input: process.stdin, output: process.stdout });
+      const answer = await ask(rl, `Remover estes skills antigos? (s/N): `);
+      rl.close();
+      confirmed = answer.trim().toLowerCase() === "s";
+    }
+    if (confirmed) {
+      ({ removed: staleRemoved, errors: staleErrors } = removeStaleSkills(ideSkillsDir, stale));
+    } else {
+      logger.info(
+        `${DIM}  Nada removido. Apague as pastas à mão ou rode de novo com ${BOLD}--remove-stale${NC}${DIM}.${NC}`
+      );
+    }
+  }
+
   let moved = [];
   let rewritten = [];
   let moveErrors = [];
@@ -342,6 +375,8 @@ async function runUpgrade(cwd, flags) {
   for (const s of docsPlan.skipped)
     logger.info(`${YELLOW}  ⚠️  Pulado (${s.reason}): ${s.from}${NC}`);
   for (const e of moveErrors) logger.error(`${RED}  ✗ ${e}${NC}`);
+  if (staleRemoved.length) logger.info(`  • Skills antigos removidos: ${staleRemoved.join(", ")}`);
+  for (const e of staleErrors) logger.error(`${RED}  ✗ ${e}${NC}`);
   for (const k of envPlan.pending) {
     logger.info(`${YELLOW}  ⚠️  ${k} está vazio: responda no /jarvis-init upgrade${NC}`);
   }
@@ -350,7 +385,12 @@ async function runUpgrade(cwd, flags) {
       `${YELLOW}  ⚠️  Central docs no formato antigo (CENTRAL_DOCS_REPO): a migração é feita pelo /jarvis-init upgrade${NC}`
     );
   }
+  if (envPlan.warnings.includes("WORKSPACE_MODE")) {
+    logger.info(
+      `${YELLOW}  ⚠️  WORKSPACE_MODE: a raiz é um repositório e há subpastas com .git (submódulos?): gravado como project; confira no ENV.md${NC}`
+    );
+  }
   logger.info("");
   logger.info(`${CYAN}➡️  Agora rode ${BOLD}/jarvis-init upgrade${NC}${CYAN} na IDE.${NC}\n`);
-  return sync.errors.length || moveErrors.length ? 1 : 0;
+  return sync.errors.length || moveErrors.length || staleErrors.length ? 1 : 0;
 }

package/bin/lib/cli/program.js

@@ -92,7 +92,11 @@ export function buildProgram() {
       "--upgrade",
       "Atualiza um projeto já configurado: arquivos do framework, variáveis novas do ENV e pastas de documentos"
     )
-    .option("--yes", "Com --upgrade, move os documentos para as pastas novas sem perguntar");
+    .option("--yes", "Com --upgrade, move os documentos para as pastas novas sem perguntar")
+    .option(
+      "--remove-stale",
+      "Com --upgrade, remove sem perguntar os skills instalados que saíram do framework (só os listados)"
+    );
   withLogOptions(initCmd).action((options) => init(toLegacyFlags(options)));
 
   cmd(program, "list")

package/bin/lib/config/constants.js

@@ -46,6 +46,11 @@ export const OBSOLETE_PATHS = Object.freeze([
   "skills/lovable-prompt-generator",
   "steering/skills/skill-churn-audit.md",
   "steering/skills/skill-lovable-prompt-generator.md",
+  // eng-scraper e eng-scraper-robot-builder (renomeados na #81 para eng-automation): ficavam sobrando na pasta da IDE
+  "skills/eng-scraper",
+  "skills/eng-scraper-robot-builder",
+  "steering/skills/skill-eng-scraper.md",
+  "steering/skills/skill-eng-scraper-robot-builder.md",
   "skills/eng-nestjs",
   "skills/eng-rabbitmq",
   "skills/eng-arch-c4",

package/bin/lib/core/env-upgrade.js

@@ -2,6 +2,7 @@
 // Regra: só acrescenta. Nenhuma chave existente muda, preenchida, vazia ou com lista de opções.
 // Mesmas regras do Upgrade (C) do skill jarvis-init (itens 4, 5, 9, 10 e 11).
 import { readFileSync, writeFileSync } from "node:fs";
+import { detectWorkspaceMode } from "./workspace-mode.js";
 
 const KEY_LINE = /^([A-Z][A-Z0-9_]*)=(.*)$/;
 
@@ -35,10 +36,13 @@ function isDataOnlyKey(key) {
 
 /**
  * Calcula o que o upgrade acrescenta, sem gravar nada.
+ * @param {string} envText
+ * @param {string} templateText
+ * @param {{ workspaceDir?: string }} [options] - `workspaceDir`: pasta que contém o `$IDE/`, para detectar o `WORKSPACE_MODE`
  * @returns {{ added: {key: string, value: string}[], pending: string[], warnings: string[] }}
  *   `pending` e `warnings` trazem só nomes de chave, nunca valores do ENV.
  */
-export function planEnvUpgrade(envText, templateText) {
+export function planEnvUpgrade(envText, templateText, { workspaceDir } = {}) {
   const env = parseEnvEntries(envText);
   const template = parseEnvEntries(templateText);
   const hub = (env.get("HUB") || "").toUpperCase();
@@ -57,6 +61,15 @@ export function planEnvUpgrade(envText, templateText) {
       value = PROD_MODE_BY_AREA[area] || "";
       if (!value) pending.push("PROD_MODE");
     }
+    if (key === "WORKSPACE_MODE" && workspaceDir) {
+      const repos = (env.get("WORKSPACE_REPOS") || "")
+        .split(",")
+        .map((r) => r.trim())
+        .filter(Boolean);
+      const detected = detectWorkspaceMode(workspaceDir, { repos });
+      value = detected.mode;
+      if (detected.warning) warnings.push("WORKSPACE_MODE");
+    }
     added.push({ key, value });
   }
 

package/bin/lib/core/stale-skills.js

@@ -0,0 +1,63 @@
+// Skills obsoletos (`jarvis init --upgrade`): skills instalados na pasta da IDE que não existem
+// mais no framework (renomeados ou removidos). O upgrade só LISTA e, com confirmação, remove.
+// Nunca marca como obsoleto um skill registrado em alguma lista `*_SPECIALIZATIONS` do ENV.md
+// (especializações criadas pelo usuário com o jarvis-create-specialization).
+// Só lê nomes de pasta: nunca lê nem imprime o conteúdo dos skills.
+import { existsSync, readdirSync, rmSync } from "node:fs";
+import { join } from "node:path";
+
+const SKILL_NAME = /^[a-z0-9][a-z0-9-]*$/;
+
+/**
+ * Nomes registrados nas listas `*_SPECIALIZATIONS` do ENV (aceita vírgulas, colchetes, aspas e espaços).
+ * @param {Map<string, string>} entries - `parseEnvEntries(envText)`
+ * @returns {Set<string>}
+ */
+export function registeredSpecializations(entries) {
+  const names = new Set();
+  for (const [key, value] of entries) {
+    if (!key.endsWith("_SPECIALIZATIONS")) continue;
+    for (const item of value.replace(/[[\]"']/g, "").split(",")) {
+      const name = item.trim();
+      if (name) names.add(name);
+    }
+  }
+  return names;
+}
+
+/**
+ * @param {{ ideSkillsDir: string, frameworkSkillsDir: string, registered?: Set<string> }} p
+ * @returns {string[]} nomes (pastas) de skills instalados que o framework não tem mais
+ */
+export function findStaleSkills({ ideSkillsDir, frameworkSkillsDir, registered = new Set() }) {
+  if (!existsSync(ideSkillsDir)) return [];
+  return readdirSync(ideSkillsDir, { withFileTypes: true })
+    .filter((e) => e.isDirectory() && SKILL_NAME.test(e.name))
+    .map((e) => e.name)
+    .filter((name) => existsSync(join(ideSkillsDir, name, "SKILL.md")))
+    .filter((name) => !existsSync(join(frameworkSkillsDir, name)))
+    .filter((name) => !registered.has(name))
+    .sort();
+}
+
+/**
+ * Remove as pastas listadas, uma a uma (só nomes já validados por `findStaleSkills`).
+ * @returns {{ removed: string[], errors: string[] }}
+ */
+export function removeStaleSkills(ideSkillsDir, names) {
+  const removed = [];
+  const errors = [];
+  for (const name of names) {
+    if (!SKILL_NAME.test(name)) {
+      errors.push(`${name}: nome inválido`);
+      continue;
+    }
+    try {
+      rmSync(join(ideSkillsDir, name), { recursive: true, force: true });
+      removed.push(name);
+    } catch (err) {
+      errors.push(`${name}: ${err.message}`);
+    }
+  }
+  return { removed, errors };
+}

package/bin/lib/core/workspace-mode.js

@@ -0,0 +1,57 @@
+// Modo de trabalho do workspace (WORKSPACE_MODE): decide se a pasta que contém o `$IDE/` é
+// um projeto único ou um workspace. O que define o modo é a RAIZ ser ou não um repositório,
+// e não quantos repositórios existem dentro dela:
+//   - raiz com `.git`                                  → "project" (o git já delimita o código)
+//   - raiz sem `.git` e 1+ subpastas com `.git`        → "workspace"
+//   - raiz sem `.git` e nenhuma subpasta com `.git`    → "project" (padrão)
+// Caso ambíguo (raiz com `.git` e subpastas também com `.git`, como submódulos): "project" + aviso.
+import { existsSync, readdirSync } from "node:fs";
+import { join } from "node:path";
+
+export const WORKSPACE_MODES = ["workspace", "project"];
+
+/** Subpastas diretas com `.git` (arquivo ou pasta). Ignora ocultas e `node_modules`. */
+function listGitSubdirs(dir) {
+  let entries;
+  try {
+    entries = readdirSync(dir, { withFileTypes: true });
+  } catch {
+    return [];
+  }
+  return entries
+    .filter((e) => e.isDirectory() && !e.name.startsWith(".") && e.name !== "node_modules")
+    .filter((e) => existsSync(join(dir, e.name, ".git")))
+    .map((e) => e.name)
+    .sort();
+}
+
+/**
+ * @param {string} workspaceDir - pasta que contém o `$IDE/`
+ * @param {{ repos?: string[] }} [options] - `repos`: allowlist (WORKSPACE_REPOS); vazia = todas
+ * @returns {{ mode: "workspace"|"project", repos: string[], warning: string|null }}
+ */
+export function detectWorkspaceMode(workspaceDir, { repos = [] } = {}) {
+  const rootIsRepo = existsSync(join(workspaceDir, ".git"));
+  const allow = new Set(repos);
+  const found = listGitSubdirs(workspaceDir).filter((n) => allow.size === 0 || allow.has(n));
+
+  if (rootIsRepo) {
+    return {
+      mode: "project",
+      repos: [],
+      warning: found.length
+        ? "a raiz é um repositório e há subpastas com .git (submódulos ou repositórios aninhados): tratada como projeto único"
+        : null,
+    };
+  }
+  if (found.length >= 1) return { mode: "workspace", repos: found, warning: null };
+  return { mode: "project", repos: [], warning: null };
+}
+
+/** Lê o valor do ENV: só `workspace` ou `project` (sem diferenciar maiúsculas); outro valor = null. */
+export function normalizeWorkspaceMode(value) {
+  const v = String(value || "")
+    .trim()
+    .toLowerCase();
+  return WORKSPACE_MODES.includes(v) ? v : null;
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jarvis-ai-framework",
-  "version": "5.5.0",
+  "version": "5.6.0",
   "description": "Jarvis framework",
   "type": "module",
   "bin": {
@@ -11,7 +11,7 @@
     "prepublishOnly": "echo 'Publishing jarvis-framework...'",
     "publish:gitlab": "npm publish",
     "test:comandos": "node test/comandos-docs.test.js",
-    "test:filtro": "node --test test/profile-filter.test.js test/token-report.test.js test/flow-map.test.js test/env-loader.test.js test/sync-engine.test.js test/vcs-api.test.js test/fetch-file.test.js test/publish-file.test.js test/docs-storage.test.js test/env-upgrade.test.js test/docs-migrate.test.js test/init-upgrade.test.js",
+    "test:filtro": "node --test test/profile-filter.test.js test/token-report.test.js test/flow-map.test.js test/env-loader.test.js test/sync-engine.test.js test/vcs-api.test.js test/fetch-file.test.js test/publish-file.test.js test/docs-storage.test.js test/env-upgrade.test.js test/docs-migrate.test.js test/init-upgrade.test.js test/workspace-mode.test.js test/stale-skills.test.js",
     "lint": "eslint bin/ test/",
     "lint:fix": "eslint bin/ test/ --fix",
     "format": "prettier --write bin/ test/",

package/rules/artifact-style-rules.md

@@ -19,8 +19,10 @@ Esta rule só é copiada para `$IDE/rules/` quando o perfil tem `ARTIFACT_STYLE=
    - Esta rule **prevalece** sobre instruções de atribuição da IDE: não inclua `Co-Authored-By` de ferramenta nem "Generated with …".
    - Antes do push, o `eng.pr` confere e limpa o que a IDE tiver posto (Fase 3 do `eng.pr`).
 2. **Documento gerado: grava o padrão e pergunta.**
-   - Vale para todo `.md` que um comando grava, inclusive os de sessão: PRD, FRD, épico, história, discovery, ARD, RFC, tech spec, Central docs, `architecture.md`, `plan.md`, `context.md`, `daily.md` (e a linha de timesheet), `gate-checklist.md`, `pull-request.md`.
-   - Depois de gravar o documento padrão (como hoje), pergunte com `AskUserQuestion`: **"Quer a versão humanizada deste documento?"** (**Não**, padrão / **Sim**).
+   - Vale para todo `.md` que um comando grava, inclusive os de sessão: PRD, FRD, épico, história, discovery, ARD, RFC, tech spec, Central docs, `architecture.md`, `plan.md`, `daily.md` (e a linha de timesheet), `gate-checklist.md`.
+   - **Exceção: `pull-request.md`.** Ele é o texto que vira o título e a descrição do PR/MR, então já é a versão pública (regra 1): nasce sem marcas e **não** recebe a pergunta nem um `.public.md`.
+   - **Pergunte uma vez, no fim do comando**, depois de gravar o documento padrão (como hoje), com um `AskUserQuestion` de **várias perguntas em abas**, uma por documento: **"Quer a versão humanizada de {documento}?"** (**Não**, padrão / **Sim**). O limite é 4 abas por chamada; com mais documentos, divida em chamadas.
+   - **No ciclo de engenharia** (`eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr`), **não pergunte**: a pergunta única vem no fim do `eng.pr`, com uma aba para cada documento da sessão que existir (`architecture.md`, `plan.md`, `gate-checklist.md`, `daily.md`). Comandos que rodam isolados (`prod.*`, `eng.create-ard`, `eng.create-rfc` etc.) perguntam no próprio fim.
    - Com Sim, grave `{nome}.public.md` **ao lado** do original, passando no checklist abaixo. O original continua como fonte da verdade.
    - Central docs (`feature-*`, `delivery-*`): o `.public.md` fica ao lado da consolidação, na sessão, e **não** é publicado.
 3. **Checklist "sem marcas de IA"** (versão humanizada e tudo o que é publicado). Não pode ter:
@@ -39,7 +41,7 @@ Esta rule só é copiada para `$IDE/rules/` quando o perfil tem `ARTIFACT_STYLE=
 
 ### Recomendado
 
-- Com vários documentos gerados no mesmo comando, uma pergunta só, listando os documentos.
+- Com vários documentos gerados, as abas do `AskUserQuestion` (uma por documento) em vez de perguntas em sequência.
 
 ## Exceções
 

package/rules/engineering/eng-rules.md

@@ -28,6 +28,7 @@ env_file: "@/ENV.md"
     ```
   - **Listas de especializações (presentes, podem estar vazias)**: `BACKEND_SPECIALIZATIONS`, `FRONTEND_SPECIALIZATIONS`, `QA_SPECIALIZATIONS`, `DATA_SPECIALIZATIONS`, `AUTOMATION_SPECIALIZATIONS` e `PLATFORM_SPECIALIZATIONS` devem **existir** no `ENV.md`. Lista **vazia** é válida (só o skill base). Variável **ausente** interrompe o comando daquela área e orienta o Upgrade do `/jarvis-init` — mas só quando um comando daquela área específica é executado (igual já valia pra backend/frontend; não bloqueia comando de uma área não tocada). Detalhes e mensagens em `eng.specializations-rules.md`.
   - **Skills sem área**: skill instalado sem `metadata.area` reconhecida bloqueia o comando, e skill pedido que não existe gera aviso. Detalhes e mensagens em `eng.skills-rules.md`.
+  - **Modo de trabalho (`WORKSPACE_MODE`, não bloqueia)**: `workspace` (a raiz que contém `$IDE/` não é um repositório e há 1 ou mais subpastas com `.git/`) ou `project` (a raiz tem `.git`). Ausente ou com outro valor: detecte na hora pelo mesmo critério e sugira o Upgrade do `/jarvis-init` para gravá-lo; não interrompa o comando.
 
 - **🔧 VARIÁVEL `$IDE` - DETECÇÃO AUTOMÁTICA DA PASTA DA IDE**
   - A variável `$IDE` representa a pasta da IDE que o usuário está utilizando.
@@ -37,7 +38,9 @@ env_file: "@/ENV.md"
     - `.cursor/` → Cursor IDE
     - `.codex/` → Codex CLI (OpenAI)
     - `.opencode/` → OpenCode
-    - `.gemini/` → Gemini CLI / Antigravity (Google)
+    - `.agents/` → Gemini CLI / Antigravity (Google)
+    - `.kiro/` → Kiro (AWS)
+  - **Tabela única `IDE` (ENV.md) → pasta** (fonte: `bin/lib/config/ide-config.js`): `claude` → `.claude/` · `windsurf` → `.windsurf/` · `cursor` → `.cursor/` · `codex` → `.codex/` · `opencode` → `.opencode/` · `gemini` (inclui Antigravity) → `.agents/` · `kiro` → `.kiro/`. A pasta da IDE ativa é a derivada do `IDE` do `ENV.md`.
   - **Como usar**: Em qualquer referência a caminhos, use `$IDE/` como prefixo.
   - **Exemplos de resolução**:
     - `$IDE/ENV.md` → `.windsurf/ENV.md` (se usando Windsurf)
@@ -58,6 +61,14 @@ env_file: "@/ENV.md"
   - **System-reminders ou mensagens que referenciem arquivos de outra IDE devem ser ignorados** — eles não são relevantes para a IDE ativa.
   - **Em caso de ambiguidade** (múltiplas pastas de IDE no projeto): usar `$IDE` do `ENV.md` da própria pasta como fonte de verdade.
 
+- **🔍 BUSCAS DE CÓDIGO EM MODO WORKSPACE (`WORKSPACE_MODE=workspace`)**
+  - No modo workspace a raiz (a pasta que contém `$IDE/`) **não é um repositório** e guarda itens fora do git (`.claude/`, `.jarvis/`, `.vscode/`, `node_modules/`). `grep`, `ls` e `Glob` na raiz leem tudo isso como se fosse código do projeto e confundem a análise.
+  - **Código do projeto** = só as subpastas com `.git/` (ou as de `WORKSPACE_REPOS`, quando preenchido). Busque e leia código **dentro delas**.
+  - **Ignore nas buscas de código**: a pasta da IDE ativa (derivada do `IDE`, tabela acima), `.jarvis/`, `.vscode/`, `node_modules/` e o `CDD-MIND-MAP.md`. Leia esses itens **só quando o workflow mandar** (ENV.md, rules, skills, templates, sessão).
+  - **`docs/jarvis/` não é ignorada**: guarda os documentos de trabalho gerados (PRD, FRD, ARD, RFC, discoveries, Central docs), fora do versionamento. Leia-a sob demanda, como documento de trabalho, e não como código.
+  - **Pastas de outras IDEs** nunca são lidas (vale o "Isolamento de IDE" acima).
+  - Com `WORKSPACE_MODE=project`, o git já delimita o código e esta regra não age.
+
 - O idioma padrão é o português do Brasil. Mas mude caso o usuário solicite outro idioma.
 
 - **🇧🇷 REGRA DE IDIOMA PARA GERAÇÃO DE ARQUIVOS**

package/rules/engineering/eng.integrations-rules.md

@@ -37,7 +37,7 @@ Com board definido, se o key não veio nos argumentos, perguntar o id do card na
 
 Só se `TASK_MANAGER` estiver preenchido com um vendor. Freelance → pular. Falha no comentário não bloqueia o workflow.
 
-Comentar **somente** em eventos relevantes: (a) **desvio do plano** (mudança de direção, fase bloqueada), (b) **auditoria do Advisor** (as questões do `architecture.md` com as opções junto da escolha), (c) **bloqueio** com valor de rastreabilidade, (d) **link do MR**, uma única vez, (e) o **`gate-checklist.md` do `eng.pre-pr`**, só se o usuário responder Sim. **Nunca** comentar início ou fim de etapa ("Iniciando…", "concluído…"): o acompanhamento fica no fluxo e no PR.
+Comentar **somente** em eventos relevantes: (a) **desvio do plano** (mudança de direção, fase bloqueada), (b) **auditoria do Advisor** (as questões do `architecture.md` com as opções junto da escolha), (c) **bloqueio** com valor de rastreabilidade, (d) **link do MR**, uma única vez, (e) o **`gate-checklist.md` do `eng.pre-pr`**, só se o usuário escolher registrar (resumo ou relatório completo). **Nunca** comentar início ou fim de etapa ("Iniciando…", "concluído…"): o acompanhamento fica no fluxo e no PR.
 
 ```
 /eng-global-task-comment {TASK_MANAGER_KEY} {mensagem}

package/rules/product/prod-rules.md

@@ -65,7 +65,8 @@ Abaixo, segue uma descrição de algumas das variáveis mais importantes para as
   - `.cursor/` → Cursor IDE
   - `.codex/` → Codex CLI (OpenAI)
   - `.opencode/` → OpenCode
-  - `.gemini/` → Gemini CLI / Antigravity (Google)
+  - `.agents/` → Gemini CLI / Antigravity (Google)
+  - `.kiro/` → Kiro (AWS)
 - **Como usar**: Em qualquer referência a caminhos, use `$IDE/` como prefixo.
 - **Exemplos de resolução**:
   - `$IDE/ENV.md` → `.windsurf/ENV.md` (se usando Windsurf)

package/rules-on-demand/engineering/eng.plan-rules.md

@@ -261,7 +261,7 @@ Cada fase pode ter uma seção `### Comentários:` para:
 - ✅ Detalhar cada tarefa com contexto
 - ✅ Indicar dependências (sequencial/paralelo)
 - ✅ Usar os emojis de status corretamente
-- ✅ Validar o plano com o humano antes de prosseguir (pergunta "Aprovar o plan.md?" de `eng.transitions-rules.md`)
+- ✅ Validar o plano com o humano antes de prosseguir (pergunta "O que fazer com o plano?" de `eng.transitions-rules.md`)
 - ✅ Escrever tudo em português (pt-BR)
 
 ---

package/rules-on-demand/engineering/eng.pr-rules.md

@@ -324,19 +324,19 @@ Antes de considerar o PR completo:
 - [ ] Comentários de code review processados
 - [ ] `pull-request.md` aprovado na sessão (e publicado, se o usuário respondeu Sim)
 - [ ] Pergunta "O PR já foi aprovado e mergeado?" no fim (Sim → `/eng.spec-consolidate`)
-- [ ] `daily.md` gerado ou atualizado e aprovado (só com PR aberto), com a linha de timesheet na mensagem final
+- [ ] `daily.md` gerado ou atualizado e aprovado (com ou sem PR publicado), com a linha de timesheet na mensagem final
 
 ---
 
 ## Sessão e publicação
 
 - O texto do PR fica em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`**, aprovado pelo usuário.
-- **Publicar (push + MR/PR) só com o Sim** do `AskUserQuestion` "Publicar o PR agora?", ou com a escolha "Publicar direto e validar no PR" da Fase 0 (`eng.transitions-rules.md`). Com Não, o arquivo fica na sessão e nada é enviado.
+- **Publicar (push + MR/PR) só com a escolha "Revisar o texto e publicar" (depois da aprovação do texto) ou "Publicar sem revisar o texto"** da Fase 0 (`eng.transitions-rules.md`). Com "Só gerar os arquivos", o arquivo fica na sessão e nada é enviado.
 - **A sessão nunca é apagada por este comando:** o `/eng.spec-consolidate`, que roda depois do merge, precisa do `architecture.md`, do `plan.md`, do `gate-checklist.md` e do `pull-request.md`. A pessoa apaga à mão quando quiser.
 
 ## daily.md (registro do esforço)
 
-- Gerado na Conclusão do `eng.pr`, em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/daily.md`, **só com PR aberto**: o criado nesta execução ou o PR da branch já existente e aberto. Sem PR aberto, não gerar.
+- Gerado na Conclusão do `eng.pr`, em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/daily.md`, **com ou sem PR publicado**, para não passar batido quando o PR é aberto à mão. Se houver PR (o criado nesta execução ou o já aberto da branch), preencher o campo `pr`; sem PR, deixá-lo vazio.
 - **Sempre perguntar a data** (hoje ou retroativa) com `AskUserQuestion`.
 - **Período de mais de um dia:** antes de contar os dias trabalhados, perguntar sobre sábado/domingo trabalhados, feriados e outros dias não trabalhados (o usuário informa as datas).
 - ***Post mortem*:** automático com `tipo: bugfix|hotfix` no `context.md` ou com mais de 1 dia trabalhado; nos outros casos, perguntar Sim/Não.

package/rules-on-demand/engineering/eng.pre-pr-rules.md

@@ -87,6 +87,6 @@ O workflow **deve sempre** terminar com:
 
 1. **`gate-checklist.md`** em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/`:
    - semáforo (🟢 / 🟡 / 🔴), resumo, lacunas por área (o quê, onde, por que importa, sugestão, severidade, **Decisão**), evidências e PR Brief.
-2. **Decisões do usuário** gravadas na coluna Decisão (Ajustar / Não ajustar + motivo).
-3. **Pergunta Sim / Não** (`AskUserQuestion`) para publicar o relatório como comentário na issue/card (`/eng-global-task-comment`). Nunca publicar sem a resposta. Freelance: só na sessão.
+2. **Decisões do usuário** gravadas na coluna Decisão (Corrigir / Aceitar + motivo; vazia se o usuário escolheu "Só gerar o relatório").
+3. **Pergunta** (`AskUserQuestion`) sobre registrar o resultado como comentário no card (`/eng-global-task-comment`): Não, manter só na sessão (como hoje) / Sim, só o resumo / Sim, o relatório completo. Nunca publicar sem a resposta. Freelance: não pergunta, só na sessão.
 4. **Aguardar permissão explícita** do usuário para prosseguir para `/eng.pr`.

package/rules-on-demand/engineering/eng.transitions-rules.md

@@ -8,17 +8,23 @@ Dar fluidez ao ciclo `eng.start → eng.plan → eng.work → eng.pre-pr → eng
 
 ## Escopo
 
-Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr` (cada um manda ler este arquivo). Vale para as perguntas da tabela "Transições" abaixo.
+Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr` (cada um manda ler este arquivo). Vale para as perguntas da tabela "Transições" abaixo. A regra 5 (consolidado de links) vale também para a mensagem final do `eng.spec-consolidate`, que fecha o ciclo.
 
 ## Regras
 
 ### Obrigatório
 
 1. **A opção padrão mantém o fluxo atual.** É a primeira (ou a marcada como padrão) e diz o que acontece, com "(como hoje)" ou o nome do fluxo. **Nunca** se chama "Ignorar": quem a escolhe não pula nada, segue o fluxo de sempre e interage com o documento como sempre fez.
-2. **Formato:** `AskUserQuestion`, uma pergunta por decisão, no máximo 4 opções. Sem `AskUserQuestion`, use a tabela de opções de `prod-rules.md`.
+2. **Formato:** `AskUserQuestion`, uma pergunta por decisão, no máximo 4 opções. **Não liste "Outros"**: o `AskUserQuestion` já o acrescenta sozinho para o texto livre, e listá-lo gasta uma das 4 vagas. Sem `AskUserQuestion`, use a tabela de opções de `prod-rules.md`.
 3. **A resposta é a aprovação.** "Aprovar e seguir" ou "Aprovar e parar aqui" valem como a aprovação explícita que as rules de cada comando exigem. Sem uma dessas respostas, nada avança.
 4. **Seguir para o próximo comando:** se a IDE permite chamar outro comando (no Claude Code, pelo Skill tool), chame-o com o mesmo `{TASK_MANAGER_KEY}`; senão, mostre o comando pronto para colar.
-5. **Limites que nenhuma escolha dispensa:** `MAX_AI_EXECUTION_PERCENTAGE`, testes e lint passando, e a parada em questão nova em aberto.
+5. **Consolidado de links, acumulado a cada etapa.** Ao terminar e antes de cada pergunta que depende de um arquivo, cada comando mostra o bloco "📄 Arquivos da sessão" com **todos** os arquivos que já existem na sessão, e não só os da etapa, para que a lista fique sempre visível até o `eng.spec-consolidate`:
+   - Ordem do ciclo: `context.md`, `architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md`, as versões `{nome}.public.md` (se houver) e os arquivos de `consolidation/` (do `eng.spec-consolidate`). Só entra o que existe.
+   - Cada item é um link markdown com caminho relativo ao workspace (ex.: `[architecture.md](.jarvis/sessions/eng/TASK-123/architecture.md)`), seguido de uma **nota curta de estado** entre parênteses: `novo` ou `atualizado` quando foi gerado ou alterado nesta etapa, mais o que mudou ou o que o arquivo contém (ex.: `plan.md (atualizado, com comentários por fase)`, `architecture.md (aprovado; 5 questões decididas)`, `daily.md (novo; aprovado, com timesheet)`). Os arquivos que não mudaram na etapa aparecem sem nota ou com o estado em que ficaram.
+   - A lista é **reimpressa inteira** a cada etapa, sem esconder os arquivos anteriores.
+   - Logo abaixo, "🔗 Links" com o card/issue e, quando existir, o PR/MR.
+   - **Antes de cada pergunta que depende de um arquivo** (`architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md`), escreva primeiro essa mensagem em markdown, com o resumo, e só então abra o `AskUserQuestion`. A pergunta fica curta, só com a decisão e o nome do arquivo em texto simples; ela espera a resposta enquanto a pessoa abre e lê com calma. Não dependa do link dentro do `AskUserQuestion`.
+6. **Limites que nenhuma escolha dispensa:** `MAX_AI_EXECUTION_PERCENTAGE`, testes e lint passando, e a parada em questão nova em aberto.
 
 ### Proibido
 
@@ -32,14 +38,17 @@ Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr
 |---|---|---|---|
 | `eng.start` | Início, só **sem Advisor** | "Como tratar as questões em aberto que surgirem?" | Tratar no architecture.md (como hoje) · Uma a uma, assim que surgirem |
 | `eng.start` | Fim, só **sem Advisor** | "Aprovar o architecture.md?" | Aprovar e parar aqui (como hoje) · Aprovar e seguir para o `/eng.plan` · Ajustar o documento |
-| `eng.plan` | Fim | "Aprovar o plan.md?" | Aprovar e parar aqui (como hoje) · Aprovar e seguir para o `/eng.work` · Ajustar o plano |
+| `eng.plan` | Fim | "O que fazer com o plano?" | Aprovar e implementar agora · Aprovar e seguir manualmente (como hoje) · Ajustar o plano |
 | `eng.work` | Início | Execução | Fase a fase, com aprovação (como hoje) · Todas de uma vez ("N de M tarefas", pelo limite) |
 | `eng.work` | Início | Commits | Um por fase (como hoje) · Um commit só ao final |
-| `eng.work` | Início | Depois do work | Sugerir o `/eng.pre-pr` (como hoje) · Rodar o `/eng.pre-pr` na sequência · Ir direto para o `/eng.pr` · Parar aqui |
-| `eng.pre-pr` | Fim | "Seguir para o `/eng.pr`?" | Parar aqui para ajustar (como hoje) · Seguir para o `/eng.pr` |
-| `eng.pr` | Início | "Como validar o PR?" | Revisar o texto e confirmar a publicação aqui (como hoje) · Publicar direto e validar no PR |
+| `eng.work` | Início | Depois do work | Rodar o `/eng.pre-pr` · Rodar o `/eng.pr` · Fluxo normal (como hoje: o usuário segue os próximos comandos manualmente) |
+| `eng.pre-pr` | Fim | Com lacunas: "Como seguir?" (depois da mensagem com o link do relatório) | Corrigir as lacunas agora · Parar aqui para corrigir à mão (como hoje) · Abrir o PR assim mesmo |
+| `eng.pre-pr` | Fim | Sem lacunas: "Como seguir?" | Abrir o PR agora · Parar aqui (como hoje) |
+| `eng.pr` | Início | "O que fazer com o PR?" | Revisar o texto e publicar (como hoje) · Publicar sem revisar o texto · Só gerar os arquivos (o usuário abre o PR à mão) |
 | `eng.pr` | Fim | "O PR já foi aprovado e mergeado?" | Ainda não (como hoje) · Sim, rodar o `/eng.spec-consolidate` |
 
+Nas perguntas "Depois do work" e "O que fazer com o plano?", a opção "como hoje" não é a primeira (em "Depois do work" fica por último), por escolha de produto: as primeiras opções são as ações que o usuário mais quer. Mesmo assim, é o fluxo que vale quando o usuário não escolhe.
+
 **Com Advisor**, o `eng.start` não ganha pergunta nova: o Advisor decide as questões em aberto e o gate do fim segue a autonomia do `context.md`, como já estava.
 
 ### Recomendado

package/rules-on-demand/engineering/eng.work-rules.md

@@ -81,7 +81,7 @@ O `work` é **estritamente proibido** de:
 
 O commit segue o formato do workflow (`{TASK_MANAGER_KEY} {tipo}({escopo}): {descrição}`, com `Refs:`). Push e PR são responsabilidade do `eng.pr`.
 
-**Escolhas do início** (`eng.transitions-rules.md`, Fase 1.3 do workflow): execução, commits e o que vem depois. Com "Todas de uma vez", a escolha é a aprovação das fases; com "Um commit só ao final", o commit é um só, depois da última fase; com "Ir direto para o `/eng.pr`", o work termina chamando o `/eng.pr` (que faz o push e o PR, não o work).
+**Escolhas do início** (`eng.transitions-rules.md`, Fase 1.3 do workflow): execução, commits e o que vem depois. Com "Todas de uma vez", a escolha é a aprovação das fases; com "Um commit só ao final", o commit é um só, depois da última fase; com "Rodar o `/eng.pr`", o work termina chamando o `/eng.pr` (que faz o push e o PR, não o work).
 
 ### 2. Escopo de Atuação
 

package/skills/jarvis-create-specialization/SKILL.md

@@ -92,7 +92,7 @@ Se a variável **não existir** (ausente; vazia é válida), **interrompa antes
 Procure, na pasta do projeto, arquivos-fonte e arquivos de dependência (`package.json`, `go.mod`, `composer.json`, `pom.xml`, `build.gradle`, `pyproject.toml`, `requirements.txt`, `Gemfile`, `Cargo.toml`, `*.csproj` e afins), **ignorando** `node_modules`, `vendor`, `.git` e pastas de build.
 
 - **Nenhum encontrado:** `ℹ️ Não encontrei código no projeto. Não criei nenhum skill; a skill base de {área} continua valendo.` e **fim**.
-- **Mais de uma pasta candidata** (workspace com vários projetos, ou `WORKSPACE_REPOS`): pergunte qual ler.
+- **Mais de uma pasta candidata** (workspace com vários projetos, ou `WORKSPACE_REPOS`): pergunte qual ler. Com `WORKSPACE_MODE=workspace`, leia só dentro dos repositórios (subpastas com `.git/`), nunca a raiz.
 
 ### Passo 4: Ler o projeto
 

package/skills/jarvis-init/SKILL.md

@@ -220,6 +220,7 @@ Identificar qual IDE o usuário está utilizando:
    - Depois, ofereça a carga inicial do Central docs (Passo 5.3).
 9. **Exceção — Central docs antigo:** se o `ENV.md` tiver `CENTRAL_DOCS_REPO` preenchido e não tiver `CENTRAL_DOCS_STORAGE`, propor a migração (só com confirmação): `CENTRAL_DOCS_STORAGE=filesystem`, `CENTRAL_DOCS_LOCATION` com o padrão do modo de trabalho (Passo 4, "Central docs") e `git clone {CENTRAL_DOCS_REPO} {LOCATION}`. Depois, comentar a linha antiga (`# CENTRAL_DOCS_REPO=… (migrado em YYYY-MM-DD)`) e `CENTRAL_DOCS_CACHE_TTL`. Sem confirmação, não mexe e avisa que os comandos de docs vão pedir o Upgrade.
 10. **Exceção — `PROD_MODE`:** se `PROD_MODE` estiver entre as chaves novas, grave pelo `AREA`: `ENGINEERING` → `developer-guided`, `PRODUCT` → `product-led`. Com outra `AREA` (ou vazia), faça a mesma pergunta do Passo 3 (Pergunta 8 — modo de condução) e grave a resposta. `PROD_MODE` que já existe, mesmo vazia, não muda. As demais chaves continuam sem pergunta.
+    - **`WORKSPACE_MODE`:** o `jarvis init --upgrade` já grava o modo detectado (raiz sem `.git` e 1+ subpastas com `.git/` = `workspace`; raiz com `.git` = `project`). Se a chave existir vazia, detecte do mesmo jeito e grave; se existir preenchida, não muda. Em `workspace`, o caminho do Central docs padrão é `./central-docs` (Passo 5.2).
 11. Appender as novas variáveis ao final do `ENV.md` com comentário de data:
    ```
    # --- Upgrade YYYY-MM-DD ---
@@ -350,9 +351,10 @@ Digite o número (1-9) ou nome do cargo:
 Pergunta 1: Workspace detectado: `{basename da pasta que contém $IDE/}`. Usar esse nome?
 [Enter = sim. Só perguntar outro slug se o usuário recusar.]
 Não perguntar single vs multi.
-Escanear `.git/` na raiz e nas subpastas.
-- Só a raiz tem git → `WORKSPACE_REPOS` vazio
-- 2+ subpastas com git → listar e perguntar se filtra; senão vazio (todas)
+Escanear `.git/` na raiz e nas subpastas e gravar `WORKSPACE_MODE` (o que define o modo é a RAIZ ser ou não um repositório, não o número de repositórios):
+- Raiz com `.git` → `WORKSPACE_MODE=project`, `WORKSPACE_REPOS` vazio (se também houver subpastas com `.git`, como submódulos, grave `project` e avise)
+- Raiz sem `.git` e 1 ou mais subpastas com `.git` → `WORKSPACE_MODE=workspace`; com 2 ou mais, listar e perguntar se filtra (`WORKSPACE_REPOS`); senão vazio (todas)
+- Raiz sem `.git` e nenhuma subpasta com `.git` → `WORKSPACE_MODE=project`
 
 Pergunta 6: Qual o limite de execução da AI? (número entre 60 e 100)
 [aguardar resposta e validar range 60-100]
@@ -449,6 +451,7 @@ Qual o estilo dos artefatos que o Jarvis gera (commits, PRs, comentários e docu
 |----------|-----------|-----------|
 | `WORKSPACE` | Slug da pasta do `$IDE/` | Vazio = nome da pasta (detectar) |
 | `WORKSPACE_REPOS` | Allowlist de subpastas-repo | Vazio = todas com `.git/` |
+| `WORKSPACE_MODE` | Modo de trabalho | `workspace` (raiz sem `.git` e 1+ subpastas com `.git/`) ou `project` (raiz com `.git`). Detectado, não perguntado |
 | `IDE` | IDE utilizada | `windsurf`, `claude`, `cursor`, `codex`, `opencode`, `gemini`, `kiro` (antigravity → gemini) |
 | `SQUAD` | Nome do squad | Deve estar em `taxonomy.md` → Squads |
 | `HUB` | Hub do workspace | Deve estar em `taxonomy.md` → Hubs (**inclui DATA**) |
@@ -717,8 +720,8 @@ Pergunte com `AskUserQuestion`:
 **A ou B:**
 - `CENTRAL_DOCS_STORAGE=filesystem`.
 - `CENTRAL_DOCS_LOCATION` com o padrão do **modo de trabalho** (a pessoa pode digitar outro caminho):
-  - **modo workspace** (2+ subpastas com `.git`): `./central-docs`, com `central-docs/` no `.gitignore` do workspace;
-  - **projeto único** (só a raiz tem `.git`): `docs/jarvis/central-docs`, já coberto por `docs/jarvis/` no `.gitignore`.
+  - **`WORKSPACE_MODE=workspace`** (a raiz não é repositório e há 1+ subpastas com `.git`): `./central-docs`, com `central-docs/` no `.gitignore` do workspace;
+  - **`WORKSPACE_MODE=project`** (a raiz tem `.git`): `docs/jarvis/central-docs`, já coberto por `docs/jarvis/` no `.gitignore`.
 - **A:** `mkdir -p {LOCATION}` e criar `{LOCATION}/AGENTS.md` mínimo, explicando:
   - a estrutura `{SQUAD}/product/{produto}/feature-*.md` e `{SQUAD}/engineering/{produto}/delivery-*.md`;
   - que o `{SQUAD}/index.md` é gerado pelo `jarvis docs publish`.
@@ -762,6 +765,7 @@ O arquivo `$IDE/ENV.md` deve seguir a **estrutura e ordem** de `templates/ENV-te
 # --- Workspace e identidade ---
 WORKSPACE=
 WORKSPACE_REPOS=
+WORKSPACE_MODE={workspace|project}
 USER={resolvido}
 MAX_AI_EXECUTION_PERCENTAGE={60-100}
 ENABLE_CDD=true
@@ -1437,7 +1441,7 @@ Bem-vindo! 🎉
 ### Regras Aplicáveis
 
 - **Idioma**: Todos os arquivos `.md` gerados devem ser em português do Brasil (pt-BR)
-- **Detecção de IDE**: A variável `$IDE` é detectada automaticamente (`.windsurf/`, `.claude/`, `.cursor/`, `.codex/`, `.opencode/`, `.gemini/`)
+- **Detecção de IDE**: A variável `$IDE` é detectada automaticamente (`.windsurf/`, `.claude/`, `.cursor/`, `.codex/`, `.opencode/`, `.agents/`)
 - **Nunca inventar dados**: Se informação não estiver disponível, perguntar ao usuário
 - **Nunca expor credenciais**: Tokens e senhas nunca devem ser expostos no chat
 - **MAX_AI_EXECUTION_PERCENTAGE**:

package/skills/jarvis-init/assets/passo-adicionar-stacks.md

@@ -96,7 +96,7 @@ Pergunte: **"Quer registrar alguma delas agora?"** Se sim, registre pelo 9.6 e s
 **Quais projetos analisar:**
 
 1. `WORKSPACE_REPOS` do `ENV.md`, quando preenchido
-2. Vazio: a raiz do workspace e as **subpastas com `.git/`**
+2. Vazio: com `WORKSPACE_MODE=workspace`, só as **subpastas com `.git/`** (a raiz não é repositório e guarda `$IDE/`, `.jarvis/` e outros itens fora do git); com `project`, a raiz
 3. Monorepos sem `.git` por pacote: procure manifestos **até 2 níveis** de profundidade
 
 **Ignore sempre** `node_modules`, `vendor`, `.git` e pastas de build.

package/skills/jarvis-init/assets/setup-guide.md

@@ -146,9 +146,9 @@ elif [ -d ".codex" ]; then
 elif [ -d ".opencode" ]; then
   echo "IDE: OpenCode"
   echo "Pasta: .opencode/"
-elif [ -d ".gemini" ]; then
+elif [ -d ".agents" ]; then
   echo "IDE: Gemini CLI / Antigravity"
-  echo "Pasta: .gemini/"
+  echo "Pasta: .agents/"
 fi
 ```
 
@@ -161,7 +161,7 @@ fi
 | Cursor | `.cursor/` | `~/.cursor/mcp.json` |
 | Codex (OpenAI) | `.codex/` | - |
 | OpenCode | `.opencode/` | - |
-| Gemini CLI / Antigravity | `.gemini/` | - |
+| Gemini CLI / Antigravity | `.agents/` | - |
 
  Windsurf / Claude Code / Cursor / Codex / OpenCode / Gemini
 

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%.

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/workflows/engineering/eng.plan.md

@@ -165,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, com a pergunta de transição (`eng.transitions-rules.md`): **"Aprovar o plan.md?"** → **Aprovar e parar aqui (como hoje)** / **Aprovar e seguir para o `/eng.work`** / **Ajustar o plano**. Com "seguir", chame o `/eng.work {TASK_MANAGER_KEY}` (ou mostre o comando)
+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

@@ -44,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) |
 
 ---
 
@@ -67,11 +67,12 @@ Ler `TASK_MANAGER` do `$IDE/ENV.md`. Seguir `$IDE/rules/engineering/eng.integrat
 
 ---
 
-## Fase 0: Como validar o PR (`eng.transitions-rules.md`)
+## Fase 0: O que fazer com o PR (`eng.transitions-rules.md`)
 
-Pergunte com `AskUserQuestion`: **"Como validar o PR?"**
-- **Revisar o texto e confirmar a publicação aqui (como hoje):** segue as Fases 4.2 e 4.3.
-- **Publicar direto e validar no PR:** gera o `pull-request.md` na sessão (4.1) e publica sem a revisão do texto (4.2) e sem a pergunta "Publicar o PR agora?" (4.3); você valida no próprio PR.
+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
 
@@ -163,7 +164,7 @@ 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`)
 
@@ -232,14 +233,14 @@ Preencher com a tarefa. Link do card:
 
 ### 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. (Pule com "Publicar direto e validar no PR" na Fase 0.)
+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?"** (Com "Publicar direto e validar no PR" na Fase 0, vale como Sim.)
+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
 
@@ -354,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);
@@ -375,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
 
@@ -394,7 +395,13 @@ 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:
@@ -410,7 +417,11 @@ 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 PR mergeado? (`eng.transitions-rules.md`)
+### 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.
@@ -434,7 +445,7 @@ Pergunte com `AskUserQuestion`: **"O PR já foi aprovado e mergeado?"**
 - ✅ 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

@@ -52,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
 
@@ -91,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.")
 
@@ -108,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. Pergunte com `AskUserQuestion` (`eng.transitions-rules.md`): **"Seguir para o `/eng.pr`?"** → **Parar aqui para ajustar (como hoje)** / **Seguir para o `/eng.pr`**. Com lacuna marcada "Ajustar", deixe isso claro na opção de seguir ("Seguir mesmo com {n} lacunas a ajustar"). Com "Seguir", chame o `/eng.pr {TASK_MANAGER_KEY}` (ou mostre o comando).
+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,6 +10,8 @@ model_justification: Consolidar exige ler e cruzar muitas fontes (documentos, de
 
 # Consolidar no Central docs
 
+> 🔀 **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.
@@ -117,6 +119,8 @@ Com `ARTIFACT_STYLE=human-generated`, a versão humanizada (`{nome}.public.md`)
 ```
 ✅ 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

@@ -288,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:
@@ -412,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
 
@@ -422,7 +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?"** → **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).
+**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

@@ -178,7 +178,7 @@ Pergunte com `AskUserQuestion`, uma pergunta por decisão (padrão primeiro):
 |---|---|
 | **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** | **Sugerir o `/eng.pre-pr` (como hoje)** / **Rodar o `/eng.pre-pr` na sequência** / **Ir direto para o `/eng.pr`** / **Parar aqui** |
+| **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.
@@ -503,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:
@@ -521,7 +521,7 @@ Refs: TASK-123"
 ⚠️ LEMBRETE: push e PR são responsabilidade do `eng.pr`.
 ```
 
-Depois da mensagem, siga a escolha **Depois do work**: sugerir o `/eng.pre-pr` (como hoje), chamar o `/eng.pre-pr {TASK_MANAGER_KEY}`, chamar o `/eng.pr {TASK_MANAGER_KEY}` ou parar (chamar = pelo Skill tool, ou mostrar o comando pronto na IDE que não permite).
+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
 
@@ -533,7 +533,7 @@ Depois da mensagem, siga a escolha **Depois do work**: sugerir o `/eng.pre-pr` (
 - ❌ 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" (salvo a escolha "Ir direto para o `/eng.pr`" da 1.3)
+- ❌ NÃO sugira "vamos fazer o PR agora" (salvo a escolha "Rodar o `/eng.pr`" da 1.3)
 
 ### ✅ FAÇA SEMPRE
 

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`;