jarvis-ai-framework 5.5.0 → 5.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jarvis-ai-framework",
-  "version": "5.5.0",
+  "version": "5.7.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 test/session-scan.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 de transição** (todas as da tabela "Transições", inclusive as do início, como "O que fazer com o PR?", e mesmo quando a pergunta é repetida), 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 de transição**, escreva primeiro essa mensagem em markdown, com o resumo, e só então abra o `AskUserQuestion`. Isso vale também para as perguntas que não dependem de um arquivo: a lista é o mapa de onde a tarefa está no ponto de decisão. Na pergunta que depende de um arquivo (`architecture.md`, `plan.md`, `gate-checklist.md`, `pull-request.md`, `daily.md`), o resumo é o desse arquivo. 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/architecture-template.md

@@ -251,10 +251,11 @@ graph TD
 > Tudo que for **diferente do código ou ambíguo no card** vira uma questão aqui, detalhada a ponto de outro agente entendê-la sem reconstruir a análise. No mínimo 3 opções, mais a **4 — Outra**.
 > **Com Advisor** (cabeçalho), a sugestão do Advisor prevalece e é a decisão adotada; o agente principal não a substitui nem contesta. **Sem Advisor**, "Sugestão do Sub-Agent (Advisor)" e "Divergência" ficam "N/A (Advisor não utilizado)", a regra em destaque é omitida e a decisão é a do usuário ao revisar o documento.
 > Questão levantada depois do `eng.start` (consulta por exceção) entra aqui, numerada em sequência, marcada "levantada no `eng.plan`" ou "no `eng.work`". Sem questão em aberto, escreva "Nenhuma" e o motivo em uma frase.
+> **Marcação para leitura rápida:** decidida a questão, a opção escolhida ganha ✅ e "(escolhida)" no título, e as demais ganham ❌, inclusive a **4 — Outra**. A coluna "Opção escolhida" da tabela repete a escolha (`✅ {n} — {nome curto}`). Enquanto a questão estiver 🔄 Aberta, as opções ficam sem marcação e a coluna fica "—".
 
-| ID | Questão                      | Responsável                 | Deadline | Status                     |
-| -- | ---------------------------- | --------------------------- | -------- | -------------------------- |
-| Q1 | {resumo objetivo da questão} | {Advisor \| nome do usuário} | {— \| data} | {✅ Decidida \| 🔄 Aberta} |
+| ID | Questão                      | Opção escolhida                     | Responsável                 | Deadline | Status                     |
+| -- | ---------------------------- | ----------------------------------- | --------------------------- | -------- | -------------------------- |
+| Q1 | {resumo objetivo da questão} | {✅ {n} — {nome curto} \| —}        | {Advisor \| nome do usuário} | {— \| data} | {✅ Decidida \| 🔄 Aberta} |
 
 ### Q1 — {Título da questão}
 
@@ -269,17 +270,17 @@ graph TD
 
 **Opções:**
 
-**1. {Opção 1}**
+**✅ 1. {Opção 1} (escolhida)**
 * Como funciona: {descrição}
 * Vantagens: {vantagens}
 * Desvantagens: {desvantagens}
 * Impacto: {impacto}
 
-**2. {Opção 2}** (mesmo formato)
+**❌ 2. {Opção 2}** (mesmo formato)
 
-**3. {Opção 3}** (mesmo formato)
+**❌ 3. {Opção 3}** (mesmo formato)
 
-**4. Outra**
+**❌ 4. Outra**
 * Alternativa adicional identificada pelo Sub-Agent/Advisor, detalhada caso ele entenda que nenhuma das opções anteriores é a melhor abordagem.
 
 **Sugestão do Agente Principal (Architect):**
@@ -289,7 +290,7 @@ graph TD
 {recomendação independente do Advisor + justificativa técnica}
 
 **Decisão adotada:**
-**{recomendação do Sub-Agent/Advisor}**
+✅ **{n} — {recomendação do Sub-Agent/Advisor}**
 
 > **Regra:** a recomendação do Advisor sempre prevalece e deve ser adotada na implementação, independentemente de ser igual ou diferente da recomendação do Agente Principal.
 

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).
@@ -30,7 +30,7 @@ updated_at: {YYYY-MM-DD}
 
 # Daily — {TASK_KEY}
 
-> Registro pessoal do esforço: narrativa auditável e linha pronta para o timesheet. Fica só na sessão, nunca é publicado. Uma seção por data (`## AAAA-MM-DD`), no formato abaixo, para um comando futuro juntar os registros de um dia.
+> Registro pessoal do esforço: narrativa auditável e linha pronta para o timesheet. Fica só na sessão, nunca é publicado. Uma seção por data (`## AAAA-MM-DD`), no formato abaixo, para o `/eng.daily-report` juntar os registros por dia.
 
 ## {AAAA-MM-DD}
 

package/workflows/engineering/eng.daily-report.md

@@ -0,0 +1,131 @@
+---
+description: Junta os daily.md das sessões em um relatório por dia (mapa mental), com alertas das sessões sem daily.md
+auto_execution_mode: 3
+recommended_model: sonnet
+model_tier: medium
+model_justification: Leitura de poucos arquivos e síntese curta; a janela, as datas e os alertas já vêm prontos do CLI
+---
+
+# Relatório dos daily.md
+
+Este comando junta o que foi feito nos últimos `N` dias, lendo os `daily.md` que o `/eng.pr` grava em cada sessão. O resultado é um relatório em markdown, do dia mais recente para o mais antigo, em lista aninhada (tarefa > frentes de trabalho > detalhes), com a linha de timesheet de cada tarefa e um bloco de **alertas** das sessões que deveriam ter `daily.md` e não têm.
+
+> 🔒 **Privado**: o relatório reaproveita a narrativa e o timesheet pessoais do `daily.md`. Ele fica em `$ENG_DOCS/daily-reports/` (dentro de `docs/jarvis/`, fora do versionamento) e **nunca** é publicado: nem no Central docs, nem no card.
+
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |
+
+---
+
+## Argumento
+
+<arguments>
+$ARGUMENTS
+</arguments>
+
+`{N}` é a janela em dias: **1, 3, 7, 15, 30 ou 60** (padrão **7**). A janela é do calendário local e inclui hoje: `1` = só hoje; `7` = hoje e os 6 dias anteriores.
+
+---
+
+## Passo 1: Ler as sessões
+
+Rode o helper do CLI (ele lê o `ENV.md` do workspace, mesmo se você estiver dentro de um repositório filho):
+
+```bash
+jarvis daily-report --days {N} --json
+```
+
+- **Saída com erro** (código 1, por exemplo `N` inválido): mostre a mensagem, que já lista os valores aceitos, e **pare**. Não crie arquivo.
+- **Saída JSON**: use os campos abaixo e não refaça as contas (janela, fuso, ordem e alertas já estão certos).
+
+| Campo | O que é |
+|---|---|
+| `days`, `window.from`, `window.to`, `today` | Janela pedida, no calendário local |
+| `sessionsScanned`, `sessionsInWindow` | Sessões lidas em `$SESSIONS_DIR/eng/` e quantas entram na janela |
+| `byDate[]` | Um item por dia com registro, do mais recente para o mais antigo; em cada um, `tasks[]` com `key`, `taskKey`, `cardUrl`, `pr`, `description` e `timesheet` (seção `## AAAA-MM-DD` do `daily.md`) |
+| `alerts[]` | Sessões sem `daily.md` que deveriam ter (chegaram ao `eng.pr` ou começaram a partir de 2026-10-15), com `date`, `dateSource`, `activity`, `issueKey`, `prNumber` |
+| `warnings[]` | Avisos (por exemplo, data tirada da modificação da pasta) |
+| `reportPath`, `reportPathAbs` | Onde escrever o relatório |
+
+Os textos já vêm sem e-mails.
+
+---
+
+## Passo 2: Completar os alertas pelo vendor
+
+Para cada item de `alerts` com `prNumber` ou `issueKey`, consulte o vendor de `VERSION_CONTROL`/`TASK_MANAGER` (no GitHub: `gh pr view {n} --json title,createdAt` e `gh issue view {n} --json title`):
+
+- **Título:** use o do vendor quando `activity` vier vazia.
+- **Data:** se houver PR, a data de criação dele (em fuso local) vale mais que a data local do helper. Se ela cair fora da janela, tire o alerta.
+- Sem vendor, sem acesso ou com falha: siga com o que veio do helper, sem perguntar.
+- Sem nenhuma fonte de atividade: escreva "não identificada", só com o ID da sessão.
+
+---
+
+## Passo 3: Escrever o relatório
+
+Crie a pasta de `reportPathAbs`, se não existir, e escreva o arquivo. Se já existir um relatório com a mesma janela no mesmo dia, ele é **sobrescrito**. Janelas diferentes no mesmo dia convivem.
+
+```markdown
+# Daily report — {window.from} a {window.to} ({N} dias)
+
+> Gerado em {AAAA-MM-DD HH:MM} · {sessionsScanned} sessões lidas · {sessionsInWindow} na janela · privado, não publicar
+
+## ⚠️ Alertas: sessões sem daily.md
+
+| Data | ID da sessão | Atividade | Status |
+|---|---|---|---|
+| {date} | {key} | {activity} ({issueKey}, PR {prNumber}) | sem daily.md{; data pela modificação da pasta, se dateSource = mtime} |
+
+## {AAAA-MM-DD} ({dia da semana})
+
+- **{taskKey} — {título curto}** ([card]({cardUrl}), [PR {n}]({url do PR}))
+  - {frente de trabalho 1}
+    - {detalhe}
+  - {frente de trabalho 2}
+    - {detalhe}
+  - 🕒 `{timesheet}`
+```
+
+- **Alertas** vêm antes dos dias. Sem alertas, troque a tabela por "✅ Todas as sessões da janela têm `daily.md`."
+- **Um bloco `##` por data de `byDate`, na mesma ordem** (decrescente). Dia sem registro não aparece.
+- **Síntese por tarefa:** de 3 a 5 frentes de trabalho, cada uma com detalhes curtos, tirados **só** da `description` (contexto, o que foi feito, decisões; *post mortem* quando houver). Não acrescente fatos. O título curto vem da linha de timesheet ou do card.
+- **Timesheet literal:** a linha `timesheet` entra sem alteração, para copiar.
+- Links: `cardUrl` e o PR de `pr` (o campo traz `#n` e a URL). Faltando, omita o link.
+
+---
+
+## Passo 4: Mostrar o resultado
+
+Mostre, em markdown:
+
+```
+✅ Relatório gerado: [{nome do arquivo}]({reportPath})
+
+🗓️ Janela: {window.from} a {window.to} ({N} dias)
+📚 Sessões: {sessionsScanned} lidas · {sessionsInWindow} na janela · {dias com registro} dias com registro
+⚠️ Alertas: {quantidade} ({IDs}) — rode o /eng.pr nessas sessões (Fase 7.2) para gerar o daily.md
+```
+
+O link usa o caminho relativo ao workspace (`reportPath`).
+
+---
+
+## Regras
+
+### ✅ Faça
+
+- Use o JSON do `jarvis daily-report` como fonte da janela, das datas, da ordem e dos alertas
+- Mantenha a linha de timesheet literal
+- Sobrescreva o relatório da mesma janela no mesmo dia
+
+### ⛔ Não faça
+
+- Não publique o relatório (Central docs, card, PR) nem o copie para fora de `docs/jarvis/`
+- Não inclua e-mails, tokens nem valores de variáveis do `ENV.md`
+- Não acrescente fatos além do `daily.md` e do vendor
+- Não altere os `daily.md` nem outros arquivos das sessões
+- Não gere arquivo quando a janela for inválida

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