jarvis-ai-framework 5.2.0 → 5.6.0

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.start-rules.md

@@ -42,7 +42,7 @@ O workflow **só é considerado completo** após:
 
 1. O `architecture.md` estar preenchido
 2. O usuário revisar o documento
-3. O usuário **aprovar explicitamente** para prosseguir
+3. O usuário **aprovar explicitamente** para prosseguir — sem Advisor, pela pergunta de transição "Aprovar o architecture.md?" (`eng.transitions-rules.md`)
 
 **Exceção (Advisor):** se o usuário escolheu usar o Advisor no início do `eng.start`, as questões em aberto são decididas pela sugestão dele e o gate segue a autonomia do `context.md`: com `autonomia: alta` o `start` apresenta o resumo e segue para o `eng.plan` sem aguardar; com `média` ou `baixa`, a aprovação explícita continua obrigatória.
 
@@ -92,7 +92,7 @@ O workflow **só é considerado completo** após:
 7. **Aguardar aprovação**
    - Se aprovado → Informar próximos passos
    - Se rejeitado → Iterar no documento
-   - NUNCA prosseguir automaticamente
+   - NUNCA prosseguir sem a resposta: "Aprovar e seguir para o `/eng.plan`" (pergunta de transição, `eng.transitions-rules.md`) é a aprovação para seguir; a exceção do Advisor continua valendo
 
 ---
 

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

@@ -0,0 +1,67 @@
+> **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+# Regras das transições do ciclo de engenharia
+
+## Objetivo
+
+Dar fluidez ao ciclo `eng.start → eng.plan → eng.work → eng.pre-pr → eng.pr → eng.spec-consolidate` com perguntas nos pontos de início e de transição, sem mudar nada para quem prefere o fluxo de sempre.
+
+## 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. 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. **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. **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
+
+- Pergunta nova sem a opção que mantém o fluxo atual.
+- Avançar para o próximo comando sem a resposta do usuário.
+- Usar a escolha de um comando para contornar o `MAX_AI_EXECUTION_PERCENTAGE`.
+
+### Transições
+
+| Comando | Quando | Pergunta | Opções (padrão primeiro) |
+|---|---|---|---|
+| `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 | "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 | 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
+
+- Mostre, na própria opção, o que muda na prática (ex.: "Todas de uma vez (6 de 6 tarefas)").
+- No `eng.work`, grave as escolhas no cabeçalho do `plan.md`; numa retomada, pergunte uma vez se mantém.
+
+## Exceções
+
+- O usuário pode dar as escolhas em texto livre ("faça todas as fases, um commit, direto ao PR"); valem como as respostas das perguntas correspondentes. É o "Escape Hatch" de `eng-rules.md` ("o usuário pode sempre fazer override de qualquer regra contextual com instrução explícita").
+
+## Referências
+
+- `workflows/engineering/eng.{start,plan,work,pre-pr,pr}.md`
+- `rules/engineering/eng-rules.md` (`MAX_AI_EXECUTION_PERCENTAGE`)
+- `rules/product/prod-rules.md` (formato sem `AskUserQuestion`)

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

@@ -73,7 +73,7 @@ O `work` é **estritamente proibido** de:
 | Fazer `git push`                                   | Escrever código                                           |
 | Criar Pull Requests                                | Criar/modificar arquivos de código                        |
 | Usar `git add .`                                   | `git add` de arquivos específicos da fase                 |
-| Commitar sem aprovação do usuário na fase          | Commitar ao final da fase validada, com testes passando   |
+| Commitar sem aprovação do usuário na fase          | Commitar ao final da fase validada (ou ao final, com "Um commit só"), com testes passando |
 | Commitar com testes falhando                       | Executar testes locais                                    |
 | Mover cards no Jira                                | Ler arquivos da sessão                                    |
 | Fazer merge de branches                            | Atualizar `plan.md` com progresso                         |
@@ -81,6 +81,8 @@ 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 "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
 
 O `work` atua **exclusivamente** em:
@@ -222,12 +224,14 @@ Ao concluir uma fase, adicione na seção `### Comentários:`:
 
 ### Pontos de Pausa Obrigatórios
 
-O workflow **DEVE pausar e aguardar confirmação**:
+Com **"Fase a fase, com aprovação (como hoje)"**, o workflow **DEVE pausar e aguardar confirmação**:
 
 1. ✋ **Antes de iniciar qualquer fase**
 2. ✋ **Após completar implementação** (antes de atualizar plan.md)
 3. ✋ **Antes de iniciar próxima fase**
 
+Com **"Todas de uma vez"**, essas pausas não acontecem. **Em qualquer escolha**, o workflow para no limite do `MAX_AI_EXECUTION_PERCENTAGE`, com um teste falhando e diante de uma questão nova em aberto.
+
 ### Comunicação
 
 - Seja claro sobre o que foi feito
@@ -291,10 +295,12 @@ Ao finalizar **TODAS as fases** do `plan.md`, informe:
 2. Execute os testes completos
 3. Quando estiver pronto, use `eng.pr` para criar o Pull Request
 
-⚠️ Este workflow commita por fase, mas NÃO faz push nem PR.
+⚠️ Este workflow commita (por fase ou ao final), mas NÃO faz push nem PR.
    Use `eng.pr` quando estiver pronto para submeter.
 ```
 
+Depois, siga a escolha **Depois do work** da Fase 1.3 (sugerir o `/eng.pre-pr`, chamá-lo, chamar o `/eng.pr` ou parar).
+
 ---
 
 ## Checklist de Conclusão de Fase

package/skills/eng-global-pr/SKILL.md

@@ -152,6 +152,8 @@ git add {arquivo1} {arquivo2} ...
 Refs: {TASK_MANAGER_KEY}
 ```
 
+Com `ARTIFACT_STYLE=human-generated`: sem `Co-Authored-By` de ferramenta nem "Generated with …", mesmo que a IDE peça (`rules/artifact-style-rules.md`).
+
 **Tipos permitidos:**
 
 | Tipo | Uso |
@@ -207,7 +209,7 @@ Usar template oficial em `$IDE/templates/engineering/PR-template.md`.
 - **Branch origem**: `{NOME_DA_BRANCH}`
 - **Branch destino**: Conforme solicitado (ex: `develop`)
 
-> ⚠️ **IMPORTANTE**: Não mencione AI, Claude ou assistentes no MR.
+> ⚠️ **IMPORTANTE**: Não mencione AI, Claude ou assistentes no MR. Com `ARTIFACT_STYLE=human-generated`, também sem "Generated with …" nem link da ferramenta.
 
 ### 6. Atualizar o card (`TASK_MANAGER`)
 

package/skills/eng-global-task-comment/SKILL.md

@@ -28,6 +28,8 @@ Ler `TASK_MANAGER`, `TASK_MANAGER_URL_BASE`, `TOKEN_TASK_MANAGER` e `USER` do `$
 
 Se `TASK_MANAGER` estiver vazio, ausente ou ainda for a lista `[jira, linear, github, asana]` → **encerrar em silêncio** (freelance, sem board). Não pedir token. Não falhar o workflow.
 
+Com `ARTIFACT_STYLE=human-generated`, o comentário sai sem marcas de IA (`rules/artifact-style-rules.md`).
+
 ### 1. MCP (só Jira)
 
 Se `TASK_MANAGER=jira` e o MCP Atlassian estiver disponível:

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-docs-central/SKILL.md

@@ -24,7 +24,7 @@ Integrar os comandos do framework com o **Central docs**: o registro do que **de
 | Documentos de trabalho | PRD, FRD, épicos, histórias, ARD, RFC, QA, swagger, robôs, C4: o que se pretende e se discute | `docs/jarvis/` (`$PROD_DOCS`, `$ENG_DOCS`), fora do versionamento |
 | **Central docs** | O que foi implementado: um documento **completo e autossuficiente** por funcionalidade (estado atual) e um **registro por entrega** (PR, commits, autores) | Pasta do Central docs (adaptador) |
 
-Quem escreve no Central docs é o **`/eng.spec-consolidate`** (agente `eng.docs-consolidator`), logo depois do PR. Os documentos de trabalho nunca são publicados lá.
+Quem escreve no Central docs é o **`/eng.spec-consolidate`** (agente `eng.docs-consolidator`), depois do merge do PR. Os documentos de trabalho nunca são publicados lá.
 
 **Modos deste skill:**
 - buscar o que já foi implementado (Modo 1);

package/skills/jarvis-init/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: jarvis-init
 description: Inicializa o framework JARVIS e guia novos membros no processo de onboarding. Use quando precisar configurar o ambiente, criar ENV.md, validar MCPs ou orientar um novo desenvolvedor.
-argument-hint: "[nome-do-membro-opcional]"
+argument-hint: "[upgrade | nome-do-membro-opcional]"
 disable-model-invocation: false
 allowed-tools: Read Write Edit Grep Glob Bash MCP
 license: AGPL-3.0
@@ -39,7 +39,7 @@ Regras que **substituem** qualquer trecho legado deste skill ou dos assets:
 
 ## Entrada
 
-- `$ARGUMENTS` - (Opcional) Nome do novo membro para personalizar o onboarding
+- `$ARGUMENTS` - (Opcional) `upgrade` (sem diferenciar maiúsculas): com `$IDE/ENV.md` existente, vai direto ao **Upgrade (C)** do passo "2. Verificar Existência do ENV.md", sem o menu A/B/C/D; sem `ENV.md`, avisa e segue a criação normal. Qualquer outro valor é o nome do novo membro, para personalizar o onboarding.
 
 ## Recursos
 
@@ -179,7 +179,7 @@ Identificar qual IDE o usuário está utilizando:
 **CRÍTICO**: O `ENV.md` é a fonte de verdade do projeto.
 
 1. Verificar se `$IDE/ENV.md` já existe
-2. Se existir, perguntar ao usuário:
+2. Se existir e `$ARGUMENTS` for `upgrade`, siga direto para a opção C, sem perguntar. Se existir e não vier `upgrade`, perguntar ao usuário:
    ```
    ⚠️ O arquivo ENV.md já existe. O que deseja fazer?
    A: Sobrescrever completamente
@@ -190,10 +190,14 @@ Identificar qual IDE o usuário está utilizando:
 
 **Se opção C (Upgrade):**
 
+> No terminal, rode antes `jarvis init --upgrade --ide {ide}`: ele atualiza os arquivos do framework, acrescenta as variáveis novas e move os documentos para as pastas novas (itens 1–8, 10 a 12). Aqui ficam o Central docs antigo (item 9), as pendências que ele listar e o passo das stacks.
+> **O upgrade só acrescenta chaves novas:** nenhuma chave já existente, preenchida ou não, é alterada.
+> Trocou o `ARTIFACT_STYLE` (ou HUB, POSITION, AREA, SQUAD) à mão? O Passo 8 copia ou remove as rules desse perfil.
+
 1. Ler todas as chaves do `templates/ENV-template.md`
 2. Ler todas as chaves do `$IDE/ENV.md` existente
 3. Ler `HUB` do ENV.md existente
-4. Se `HUB≠DATA`: excluir do diff todas as chaves `DATA_*` — não propor adicioná-las
+4. Se `HUB≠DATA`: excluir do diff todas as chaves `DATA_*` (exceto `DATA_SPECIALIZATIONS`, que é obrigatória em qualquer HUB) — não propor adicioná-las
 5. Calcular diff: chaves no template que **não existem** no ENV.md atual (respeitando exclusão de DATA_* para não-DATA)
 6. Se não houver diff:
    ```
@@ -208,12 +212,15 @@ Identificar qual IDE o usuário está utilizando:
 
    Serão adicionadas ao final do ENV.md sem alterar os valores existentes.
    ```
-8. **Exceção — documentos nos caminhos antigos:** procure documentos de trabalho em `$DOCS_FOLDER/product`, `$DOCS_FOLDER/engineering/{ARD,RFC,qa,swagger,openapi,robots,c4}` e `docs/engineering/{robots,swagger,openapi,c4}`.
-   - Se houver, liste o que encontrou e pergunte com `AskUserQuestion` se move para `docs/jarvis/…` (`$PROD_DOCS` e `$ENG_DOCS/…`). Use `git mv` quando o arquivo for versionado e `mv` quando não for, e garanta `docs/jarvis/` no `.gitignore`.
-   - **Sem confirmação, não mova nada:** grave `PROD_DOCS`/`ENG_DOCS` apontando para os caminhos antigos.
+8. **Exceção — documentos nos caminhos antigos:** procure documentos de trabalho em `$DOCS_FOLDER/product`, `$DOCS_FOLDER/engineering/{ARD,RFC,qa,swagger,openapi,robots,c4}`, `docs/engineering/{robots,swagger,openapi,c4}` e os discoveries em `$PROD_DOCS/discoveries/`.
+   - Se houver, liste o que encontrou e pergunte com `AskUserQuestion` (uma pergunta para todos) se move para `docs/jarvis/…` (`$PROD_DOCS`, `$ENG_DOCS/…` e, para os discoveries, `$DISCOVERIES_DOCS`). Use `git mv` quando o arquivo for versionado e `mv` quando não for, e garanta `docs/jarvis/` no `.gitignore`.
+   - **Conflito** (arquivo com o mesmo nome no destino): não sobrescreva; liste e pule esse arquivo. A pasta antiga só é removida se ficar vazia.
+   - **`related_discovery`:** depois de mover discoveries, nos `.md` de `$PROD_DOCS`, troque todo `related_discovery:` cujo **nome de arquivo** seja o de um discovery movido pelo caminho novo (relativo ao workspace). Isso também conserta valores que já estavam quebrados.
+   - **Sem confirmação, não mova nada:** as chaves **novas** recebem o caminho antigo (`DISCOVERIES_DOCS=$PROD_DOCS/discoveries`; `PROD_DOCS`/`ENG_DOCS` só se também forem novas). Chave que já existe não muda: avise que os documentos ficaram no caminho antigo.
    - 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, faça a mesma pergunta do Passo 3 (Pergunta 8 — modo de condução) e grave a resposta no lugar do valor vazio. As demais chaves continuam sem pergunta.
+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 ---
@@ -268,6 +275,7 @@ Fluxo correto:
 - **SQUAD** (do taxonomy) → mostrar em texto numerado
 - **POSITION** (do taxonomy) → mostrar em texto numerado
 - **PROD_MODE** (2 opções: product-led, developer-guided) → AskUserQuestion, sempre perguntado e sem opção sugerida
+- **ARTIFACT_STYLE** (2 opções: ai-generated, human-generated) → AskUserQuestion, `ai-generated` primeiro
 
 ```
 // Exemplo 1: HUB (5 opções) - MOSTRAR EM TEXTO
@@ -343,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]
@@ -417,6 +426,15 @@ Como você quer que os comandos de produto (prod.*) e o eng.create-ard conduzam
 
 *[Perguntar **sempre**, para qualquer `AREA` e qualquer `POSITION` (inclusive `GENERALIST` e PM). **Não** marcar nenhuma opção como recomendada nem sugerir padrão por área ou cargo. Gravar `PROD_MODE=product-led` ou `PROD_MODE=developer-guided`.]*
 
+```
+Pergunta 9 (opções fixas - 2 opções - usar AskUserQuestion) — ARTIFACT_STYLE:
+Qual o estilo dos artefatos que o Jarvis gera (commits, PRs, comentários e documentos)?
+- AI-Generated (padrão): como hoje, com metadados, links de rastreabilidade e padrões da ferramenta.
+- Human-Generated: nada do que é publicado (commit, PR, comentário no card, issue) leva marca de IA; e todo documento gerado oferece, no fim, uma versão humanizada ({nome}.public.md) para repassar a clientes ou stakeholders.
+```
+
+*[`ai-generated` como primeira opção. Gravar `ARTIFACT_STYLE=ai-generated` ou `ARTIFACT_STYLE=human-generated`. A escolha muda as rules copiadas no Passo 8: com `human-generated`, entra `rules/artifact-style-rules.md`.]*
+
 **Regras de Implementação:**
 - **Opções fixas com ≤4 opções** → usar AskUserQuestion
 - **Opções fixas com >4 opções** (HUB com DATA, IDE, SQUAD, POSITION) → mostrar em texto numerado
@@ -433,6 +451,7 @@ Como você quer que os comandos de produto (prod.*) e o eng.create-ard conduzam
 |----------|-----------|-----------|
 | `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**) |
@@ -441,6 +460,7 @@ Como você quer que os comandos de produto (prod.*) e o eng.create-ard conduzam
 | `USER` | Identidade do usuário (email ou nome) | ENV.md → git `user.email` → usuário do SO. Sem login |
 | `POSITION` | Cargo do usuário | Deve estar em `taxonomy.md` → Positions. Autonomia ponta a ponta em qualquer cargo |
 | `PROD_MODE` | Modo de condução dos comandos de produto e do `eng.create-ard` | `product-led` ou `developer-guided`. Sempre perguntado, sem opção sugerida (Pergunta 8) |
+| `ARTIFACT_STYLE` | Estilo dos artefatos gerados | `ai-generated` (padrão) ou `human-generated` (Pergunta 9). No Upgrade (C), entra com `ai-generated` |
 
 > **💡 Nota**:
 > - As opções para SQUAD, HUB, AREA e POSITION são definidas em `taxonomy.md` e podem ser customizadas por organização.
@@ -606,6 +626,7 @@ Nunca grave TOKEN_VERSION_CONTROL (chave removida do template).
 | `JARVIS_PROJECT` | `https://github.com/phelipperibeiro/jarvis-framework` | Repo do framework (`/jarvis-report-issue`) |
 | `CENTRAL_DOCS_STORAGE` / `_LOCATION` | `filesystem` / pasta padrão do modo de trabalho | Central docs (o que foi implementado), configurado no Passo 5.2; vazio = desligado |
 | `JARVIS_DOCS` / `ENG_DOCS` | `$DOCS_FOLDER/jarvis` / `$JARVIS_DOCS/engineering` | Documentos de trabalho (não perguntar; `docs/jarvis/` no `.gitignore`) |
+| `DISCOVERIES_FOLDER_NAME` / `DISCOVERIES_DOCS` | `discoveries` / `$JARVIS_DOCS/$DISCOVERIES_FOLDER_NAME` | Discoveries, fora de `product/` (não perguntar) |
 | `CENTRAL_DOCS_REF` / `_TARGET_BRANCH` / `_REVIEWERS` | `main` / `main` / *(vazio)* | Só quando a pasta do Central docs tem `.git` |
 | `SESSIONS_DIR` | `.jarvis/sessions` | Não perguntar — gravar fixo |
 | `RTK_ENABLED` | `false` (ou true se detectar `rtk`) | Token Killer |
@@ -699,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`.
@@ -744,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
@@ -754,6 +776,10 @@ HUB={valor}
 AREA={valor}
 POSITION={valor}
 
+# --- Condução e estilo ---
+PROD_MODE={product-led|developer-guided}
+ARTIFACT_STYLE={ai-generated|human-generated}
+
 # --- IDE e pastas ---
 IDE={valor}
 DOCS_FOLDER=docs
@@ -768,6 +794,8 @@ PROD_RULES=...
 PROD_FLOWS=...
 PROD_TEMPLATES=...
 PROD_DOCS=...
+DISCOVERIES_FOLDER_NAME=discoveries
+DISCOVERIES_DOCS=...
 
 # --- Task manager (opcional; vazio = freelance) ---
 TASK_MANAGER=
@@ -797,6 +825,8 @@ PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
 PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$JARVIS_DOCS/$PROD_FOLDER_NAME
+DISCOVERIES_FOLDER_NAME=discoveries
+DISCOVERIES_DOCS=$JARVIS_DOCS/$DISCOVERIES_FOLDER_NAME
 ```
 
 **⚠️ IMPORTANTE - FLOWS_FOLDER por IDE:**
@@ -987,7 +1017,7 @@ Objetivo: garantir que `$IDE/rules/` e `$IDE/rules-on-demand/` contenham apenas
 **Passos:**
 
 ```
-1. Ler HUB, POSITION, AREA, SQUAD do ENV.md recém-gravado
+1. Ler HUB, POSITION, AREA, SQUAD e ARTIFACT_STYLE (vazio = `ai-generated`) do ENV.md recém-gravado
 2. Para cada uma das duas pastas (rules/ e rules-on-demand/), listar todos os arquivos .md (recursivo, exceto AGENTS.md)
 3. Para cada arquivo:
    a. Ler o bloco `> **Applies to:**` (primeira ocorrência no arquivo)
@@ -1018,11 +1048,16 @@ function matchesProfile(appliesTo, profile) {
   const positionMatches = profile.POSITION === 'GENERALIST' || matches(appliesTo.POSITION, profile.POSITION)
   const areaMatches = profile.POSITION === 'GENERALIST' || matches(appliesTo.AREA, profile.AREA)
 
+  // ARTIFACT_STYLE (5º campo opcional): ausente no bloco = 'all'; perfil vazio = 'ai-generated'.
+  // Sem coringa: FULLCYCLE e GENERALIST não o satisfazem (é escolha da pessoa, não papel).
+  const styleMatches = matches(appliesTo.ARTIFACT_STYLE || 'all', profile.ARTIFACT_STYLE || 'ai-generated')
+
   return (
     hubMatches &&
     positionMatches &&
     areaMatches &&
-    matches(appliesTo.SQUAD, profile.SQUAD)
+    matches(appliesTo.SQUAD, profile.SQUAD) &&
+    styleMatches
   )
 }
 ```
@@ -1031,16 +1066,18 @@ function matchesProfile(appliesTo, profile) {
 
 ```javascript
 // Exemplo de bloco: > **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
+// 5º campo opcional:  ... | SQUAD: all | ARTIFACT_STYLE: human-generated
 function parseAppliesTo(fileContent) {
   const match = fileContent.match(
-    /> \*\*Applies to:\*\* HUB: ([^|]+)\| POSITION: ([^|]+)\| AREA: ([^|]+)\| SQUAD: (.+)/
+    /> \*\*Applies to:\*\* HUB: ([^|]+)\| POSITION: ([^|]+)\| AREA: ([^|]+)\| SQUAD: ([^|\n]+)(?:\| ARTIFACT_STYLE: ([^|\n]+))?/
   )
   if (!match) return null // sem bloco = universal
   return {
-    HUB:      match[1].trim(),
-    POSITION: match[2].trim(),
-    AREA:     match[3].trim(),
-    SQUAD:    match[4].trim(),
+    HUB:            match[1].trim(),
+    POSITION:       match[2].trim(),
+    AREA:           match[3].trim(),
+    SQUAD:          match[4].trim(),
+    ARTIFACT_STYLE: (match[5] || 'all').trim(),
   }
 }
 ```
@@ -1058,7 +1095,7 @@ cp "$pasta/$relPath" "$IDE/$pasta/$relPath"   # $pasta = rules ou rules-on-deman
 **Saída para o usuário:**
 
 ```
-🔍 Sincronizando rules para o perfil: HUB={HUB} | POSITION={POSITION} | AREA={AREA} | SQUAD={SQUAD}
+🔍 Sincronizando rules para o perfil: HUB={HUB} | POSITION={POSITION} | AREA={AREA} | SQUAD={SQUAD} | ARTIFACT_STYLE={ARTIFACT_STYLE}
 
 ✅ Rules sincronizadas:
    Copiadas : N arquivos (rules/: N | rules-on-demand/: N)
@@ -1312,7 +1349,10 @@ Pergunta 7: Qual seu cargo?
 Pergunta 8: Modo dos comandos de produto?
 [AskUserQuestion: Product-Led | Developer-Guided, sem opção sugerida]
 
-Pergunta 9 (opcional): Usa task manager? jira/linear/github/asana ou Nenhum (freelance)
+Pergunta 9: Estilo dos artefatos?
+[AskUserQuestion: AI-Generated (padrão) | Human-Generated]
+
+Pergunta 10 (opcional): Usa task manager? jira/linear/github/asana ou Nenhum (freelance)
 ```
 
 **Agente**: *(cria ENV.md + `.jarvis/sessions/{eng,prod,qa}`, valida Context7, cria AGENTS.md e confirma)*
@@ -1360,6 +1400,7 @@ Bem-vindo! 🎉
 - [ ] **Usou AskUserQuestion só para ≤4 opções** (AREA se aplicável — HUB com DATA vai em texto)
 - [ ] **Mostrou em texto numerado para >4 opções** (HUB, IDE, SQUAD, POSITION)
 - [ ] **Perguntou o `PROD_MODE`** (Product-Led ou Developer-Guided), sem opção sugerida, qualquer que seja a área ou o cargo
+- [ ] **Perguntou o `ARTIFACT_STYLE`** (AI-Generated primeiro ou Human-Generated)
 - [ ] **Mostrou TODAS as opções disponíveis** (HUB inclui DATA; nunca omitiu)
 - [ ] **Incluiu descrição útil em cada opção** (seja AskUserQuestion ou texto)
 - [ ] **Validou respostas em texto contra lista de opções válidas**
@@ -1400,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/skills/jarvis-report-issue/SKILL.md

@@ -1,25 +1,38 @@
 ---
 name: jarvis-report-issue
-description: Reporta um bug no próprio framework Jarvis. A IA reflete sobre qual artefato (skill/workflow/rule) causou o erro, monta o report e abre um issue no repo do Jarvis (GitLab, GitHub ou Bitbucket, conforme VERSION_CONTROL).
-argument-hint: "[descrição opcional do problema]"
+description: Reporta um bug ou propõe uma melhoria no próprio framework Jarvis. Classifica o report (bug ou melhoria), monta o issue no formato do tipo e o abre no repo do Jarvis (GitLab, GitHub ou Bitbucket, conforme VERSION_CONTROL), com a label certa.
+argument-hint: "[descrição opcional do problema ou da melhoria]"
 disable-model-invocation: false
 allowed-tools: Read Bash Grep Glob
 license: AGPL-3.0
 metadata:
   author: jarvis-team
-  version: "1.0"
+  version: "1.1"
   area: global
 ---
 
-# jarvis-report-issue — Auto-report de bug no Framework Jarvis
+# jarvis-report-issue — Bug ou melhoria no Framework Jarvis
 
-Você é a IA que acabou de cometer ou identificar um erro causado por uma instrução do Jarvis.
-Sua tarefa é: **refletir sobre o que falhou no framework, montar o report e abrir o issue no repositório do Jarvis**.
+Você abre um issue no repositório do Jarvis: um **bug** (uma instrução do Jarvis induziu um erro) ou uma **melhoria** (funcionalidade nova ou mudança de comportamento pedida pelo usuário).
 
 O usuário não precisa preencher nada — você é o autor do report.
 
 ---
 
+## Fase 0 — Classificar (obrigatória)
+
+| Tipo | Quando | Título | Label |
+|---|---|---|---|
+| **Bug** | Um skill, workflow ou rule do Jarvis induziu um erro (algo saiu diferente do que o framework promete) | `[BUG] {artefato}: {descrição curta}` | `bug` |
+| **Melhoria** | Funcionalidade nova, mudança de comportamento ou proposta de evolução | `[MELHORIA] {artefato}: {descrição curta}` | `enhancement` |
+
+Na dúvida, pergunte com `AskUserQuestion`: **"É um bug (algo do Jarvis induziu um erro) ou uma melhoria?"**, com a sua sugestão primeiro, marcada "(Recomendada)".
+
+- **Bug:** siga as Fases 1 e 2 como estão.
+- **Melhoria:** pule a Fase 1 (reflexão sobre o erro) e use o formato da Fase 2-M.
+
+---
+
 ## Fase 1 — Reflexão (obrigatória antes de qualquer ação)
 
 Responda internamente às perguntas abaixo. Use o contexto da conversa atual:
@@ -82,6 +95,47 @@ Com as respostas da Fase 1, monte o issue no formato abaixo.
 - **Reportado por:** IA (auto-report)
 ```
 
+Com `ARTIFACT_STYLE=human-generated`, troque a linha por `- **Reportado por:** {USER do ENV, só o nome antes do @}` e não cite IA no corpo (`rules/artifact-style-rules.md`).
+
+---
+
+## Fase 2-M — Montar a melhoria
+
+**Título:** `[MELHORIA] {artefato}: {descrição curta em até 80 chars}`
+
+**Corpo** (issue autossuficiente, executável sem reconstruir a conversa):
+
+```markdown
+## Contexto
+{por que a mudança importa; situação atual, com arquivos e linhas medidos}
+
+## Problema
+{o que falta ou atrapalha hoje}
+
+## Objetivo
+{o resultado esperado, em itens verificáveis}
+
+## Escopo
+**Alterar:** {arquivos e o que muda em cada um}
+**Não alterar:** {o que fica de fora}
+
+## Decisões
+{as escolhas já feitas com o usuário; o que ficou em aberto vai para "Questões em aberto", com a sugestão}
+
+## Critérios de aceite
+{comandos ou buscas verificáveis}
+
+## Entrega
+{branch base, destino do PR, `Closes #N`, idioma}
+
+## Contexto de execução
+- **Artefatos:** {caminhos}
+- **Versão do Jarvis:** {package.json → version}
+- **Reportado por:** IA, a partir do pedido do usuário
+```
+
+Antes de abrir, se o pedido tiver pontos em conflito com as regras atuais ou ambíguos, pergunte ao usuário (uma pergunta por ponto) e registre as respostas em "Decisões".
+
 ---
 
 ## Fase 3 — Credenciais e repo
@@ -117,7 +171,8 @@ REPO=$(grep -E '^(JARVIS_PROJECT|JARVIS_GITLAB_PROJECT)=' $IDE/ENV.md | tail -1
 jarvis vcs create-issue \
   --repo "$REPO" \
   --title "$ISSUE_TITLE" \
-  --body-file "$BODY_FILE"
+  --body-file "$BODY_FILE" \
+  --label "$LABEL"   # bug (Bug) ou enhancement (Melhoria), pela Fase 0
 
 rm -f "$BODY_FILE"
 ```
@@ -157,7 +212,7 @@ Verifique token (GitLab .npmrc / gh auth / BITBUCKET_TOKEN) e JARVIS_PROJECT.
 ## Regras
 
 - **Nunca** pedir ao usuário que preencha o report — a IA preenche tudo
-- **Nunca** abrir issue sem completar a Fase 1 (reflexão obrigatória)
+- **Nunca** abrir issue sem a Fase 0 (classificação); num bug, sem a Fase 1 (reflexão)
 - **Nunca** hardcodar o repo ou token — sempre ler `JARVIS_PROJECT` do ENV.md; o adapter resolve o vendor
-- **Sempre** usar label `bug` — sem exceções
+- **Sempre** usar a label do tipo: `bug` para bug, `enhancement` para melhoria (no Bitbucket, o adapter grava como `kind`)
 - **Sempre** limpar arquivos temporários após o curl