jarvis-ai-framework 5.2.0 → 5.5.0

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,14 @@ 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.
 11. Appender as novas variáveis ao final do `ENV.md` com comentário de data:
    ```
    # --- Upgrade YYYY-MM-DD ---
@@ -268,6 +274,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
@@ -417,6 +424,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
@@ -441,6 +457,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 +623,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 |
@@ -754,6 +772,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 +790,8 @@ PROD_RULES=...
 PROD_FLOWS=...
 PROD_TEMPLATES=...
 PROD_DOCS=...
+DISCOVERIES_FOLDER_NAME=discoveries
+DISCOVERIES_DOCS=...
 
 # --- Task manager (opcional; vazio = freelance) ---
 TASK_MANAGER=
@@ -797,6 +821,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 +1013,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 +1044,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 +1062,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 +1091,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 +1345,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 +1396,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**

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

package/templates/ENV-template.md

@@ -71,12 +71,22 @@ PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$JARVIS_DOCS/$PROD_FOLDER_NAME
 
+# Discoveries (rascunhos de ideia, anteriores ao PRD) — fora de product/ (em geral não precisa mexer)
+DISCOVERIES_FOLDER_NAME=discoveries
+DISCOVERIES_DOCS=$JARVIS_DOCS/$DISCOVERIES_FOLDER_NAME
+
 # Modo de condução dos comandos de produto (prod.*) e do eng.create-ard.
 #   product-led      = para PMs: fluxo direto, sem explicações extras (padrão se vazio)
 #   developer-guided = para devs e futuros PMs: uma pergunta por vez, explica cada termo e etapa
 # Perguntado sempre pelo /jarvis-init. Para trocar, rode o /jarvis-init ou edite aqui.
 PROD_MODE=
 
+# Estilo dos artefatos gerados (commits, PRs, comentários e documentos).
+#   ai-generated    = como hoje: metadados, links de rastreabilidade e padrões da ferramenta (padrão)
+#   human-generated = nada publicado leva marca de IA; todo documento gerado oferece a versão {nome}.public.md
+# Perguntado pelo /jarvis-init. Trocou à mão? Rode /jarvis-init upgrade (copia ou remove a rule do estilo).
+ARTIFACT_STYLE=ai-generated
+
 
 # --- Especializações por área -------------------------------------------------
 # Skills especializados que o Jarvis carrega junto com o skill base de cada área.

package/templates/engineering/architecture-template.md

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

package/templates/engineering/plan-template.md

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

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

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

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

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

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

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

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

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

package/workflows/engineering/eng.plan.md

@@ -14,6 +14,7 @@ model_justification: Planejamento detalhado requer decomposição de tarefas com
 Este workflow cria um **plano de execução detalhado e faseado** para implementar a feature de forma incremental.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.plan-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 ---
 
@@ -167,7 +168,7 @@ CONTEXT_PROFILE:
 1. **Apresentar** o plano ao humano
 2. **Discutir** ajustes necessários
 3. **Atualizar** `architecture.md` se houver mudanças arquiteturais
-4. **Confirmar** antes de prosseguir
+4. **Confirmar** antes de prosseguir, com a pergunta de transição (`eng.transitions-rules.md`): **"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)
 
 ---
 

package/workflows/engineering/eng.pr.md

@@ -15,6 +15,7 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/PR-template.md`
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 ## Skills recomendados
 
@@ -66,6 +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`)
+
+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.
+
 ## Fase 1: Validação Pré-PR
 
 ### 1.1 Executar Testes Unitários
@@ -158,6 +165,26 @@ Refs: {TASK_MANAGER_KEY}"
 
 > ⚠️ O push só acontece **depois do Sim** da Fase 4.3. Esta fase descreve o comando; ele roda dentro da publicação.
 
+### 3.0 Conferir marcas de IA (só com `ARTIFACT_STYLE=human-generated`)
+
+Antes do push, siga `$IDE/rules/artifact-style-rules.md`: nada publicado leva marca de IA ou da IDE.
+
+```bash
+TERMOS='co-authored-by|generated with|claude|anthropic|chatgpt|openai|copilot|\bIA\b|\bAI\b|sub-?agent|advisor'
+RANGE=$(git rev-parse --abbrev-ref @{u} >/dev/null 2>&1 && echo '@{u}..HEAD' || echo '{BRANCH_BASE}..HEAD')
+git log --format='%h %B' $RANGE | grep -inE "$TERMOS"
+grep -inE "$TERMOS" $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md
+```
+
+Revise cada ocorrência antes de remover: a busca é larga e pode achar texto legítimo (ex.: `ai-generated`, um link para o PR).
+
+- **Nada encontrado (ou só falsos positivos):** siga para o push.
+- **No `pull-request.md`:** remova os trechos (o texto aprovado na 4.2 muda só nisso).
+- **Nas mensagens de commit:** reescreva **só os commits de `$RANGE`** (ainda não enviados), sem modo interativo, por exemplo, com `{ref}` = o início de `$RANGE` (`@{u}` ou `{BRANCH_BASE}`), `git rebase {ref} --exec 'M=$(git rev-parse --git-dir)/MSG_LIMPA; git log -1 --format=%B | sed -E "/^Co-Authored-By:/Id" > "$M" && git commit -q --amend -F "$M"'`, ajustando o `sed` aos termos achados. Depois, rode a busca de novo.
+- **Commit já enviado com marca:** não reescreva; avise o usuário e pare.
+
+Informe no resumo o que foi removido. Com `ai-generated` (ou vazio), pule este passo.
+
 ### 3.1 Enviar para Remote
 
 ```bash
@@ -201,15 +228,15 @@ Preencher com a tarefa. Link do card:
 
 `{TASK_MANAGER_KEY}` = `{TASK_MANAGER_KEY}`.
 
-> ⚠️ Não mencione AI, Claude ou assistentes no MR/PR.
+> ⚠️ Não mencione AI, Claude ou assistentes no MR/PR. Com `ARTIFACT_STYLE=human-generated`, também sem "Generated with …" nem link da ferramenta (`rules/artifact-style-rules.md`).
 
 ### 4.2 Revisão do texto
 
-Mostre o `pull-request.md` (título e resumo das seções) e pergunte com `AskUserQuestion`: `[Aprovar]` / `[Ajustar]`. Ajuste até a aprovação.
+Mostre o `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.)
 
 ### 4.3 Publicar? (Sim / Não)
 
-Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar o PR agora?"**
+Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar o PR agora?"** (Com "Publicar direto e validar no PR" na Fase 0, vale como Sim.)
 
 - **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).
@@ -371,9 +398,9 @@ Regras em `$IDE/rules-on-demand/engineering/eng.pr-rules.md` (seção "daily.md"
 🕒 Timesheet: {LINHA_DE_TIMESHEET_APROVADA}
 
 📌 Próximos passos:
-1. /eng.spec-consolidate {TASK_MANAGER_KEY} → registrar no Central docs o que esta entrega implementou
-2. Aguardar revisão do time e processar os comentários do code review
-3. Merge após aprovação
+1. Aguardar revisão do time e processar os comentários do code review
+2. Merge após aprovação
+3. /eng.spec-consolidate {TASK_MANAGER_KEY} depois do merge → registrar no Central docs o que esta entrega implementou
 
 🗂️ A sessão $SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/ não é apagada (o /eng.spec-consolidate precisa dela).
    Remova à mão quando quiser.
@@ -383,6 +410,12 @@ 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`)
+
+Pergunte com `AskUserQuestion`: **"O PR já foi aprovado e mergeado?"**
+- **Ainda não (como hoje):** encerre com a mensagem acima.
+- **Sim, rodar o `/eng.spec-consolidate`:** chame o `/eng.spec-consolidate {TASK_MANAGER_KEY}` (ou mostre o comando).
+
 ## Regras Importantes
 
 ### ⛔ NÃO FAÇA

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

@@ -15,6 +15,7 @@ Antes de abrir o PR/MR, este comando **revê a branch atrás de possíveis lacun
 > ⚠️ **Só revisa.** O `eng.pre-pr` não corrige código, não escreve testes, não atualiza documentação e não publica nada no Central docs. Ele aponta; quem decide e ajusta é você (ou o `eng.work`, se pedir).
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pre-pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 ## Skills recomendados
 
@@ -112,4 +113,4 @@ A coluna **Decisão** nasce vazia: quem preenche é o usuário.
 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.
+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).

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

@@ -10,7 +10,7 @@ model_justification: Consolidar exige ler e cruzar muitas fontes (documentos, de
 
 # Consolidar no Central docs
 
-Este comando registra no **Central docs** o que a entrega **de fato implementou**. Ele roda **logo depois do PR aberto** (`/eng.pr`) e gera dois documentos completos e autossuficientes:
+Este comando registra no **Central docs** o que a entrega **de fato implementou**. Ele roda **depois do merge do PR** (o `/eng.pr` pergunta no fim se o PR já foi mergeado e oferece chamá-lo) e gera dois documentos completos e autossuficientes:
 - o **documento da funcionalidade** (`feature-{slug}.md`), com o estado atual, novo ou atualizado;
 - o **registro da entrega** (`delivery-{AAAA-MM-DD}-{task_key}.md`), com o PR, os commits e os autores.
 
@@ -110,6 +110,8 @@ Pergunte com `AskUserQuestion` (**Sim / Não**): **"Publicar no Central docs?"**
   (no `--inicial`, só os `feature-*`). Com o Central docs num repositório git, cada publicação abre um PR no repositório de documentação: informe as URLs.
 - **Não:** os arquivos ficam na sessão. Para publicar depois, use os mesmos comandos.
 
+Com `ARTIFACT_STYLE=human-generated`, a versão humanizada (`{nome}.public.md`) fica ao lado da consolidação, na sessão, e **não** é publicada.
+
 ## Passo 7: Mensagem final
 
 ```

package/workflows/engineering/eng.start.md

@@ -15,6 +15,7 @@ Este comando inicia o **planejamento** de uma nova feature.
 
 > 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.start-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/architecture-template.md`
+> 🔀 **Transições**: `$IDE/rules-on-demand/engineering/eng.transitions-rules.md` — perguntas de início e de fim deste comando (a opção padrão mantém o fluxo de sempre).
 
 > ⚠️ **IMPORTANTE**: Este workflow é APENAS para planejamento e documentação.
 > **NÃO execute código, NÃO crie arquivos de código, NÃO faça commits.**
@@ -129,7 +130,11 @@ Se `$SESSIONS_DIR/warm-ups/` tiver aquecimentos, leia `$IDE/rules-on-demand/warm
 
 ## Fase 0.5: Advisor (opcional)
 
-Logo depois de obter o `TASK_MANAGER_KEY`, pergunte com `AskUserQuestion` (sem a ferramenta, use a tabela de `prod-rules.md`): **"Usar o Advisor nas questões em aberto desta tarefa?"** (**Não**, padrão / **Sim**). Com **Não**, siga como sempre e não mencione mais o Advisor.
+Logo depois de obter o `TASK_MANAGER_KEY`, pergunte com `AskUserQuestion` (sem a ferramenta, use a tabela de `prod-rules.md`): **"Usar o Advisor nas questões em aberto desta tarefa?"** (**Não**, padrão / **Sim**). Com **Não**, siga como sempre e não mencione mais o Advisor. Em seguida (só sem Advisor), pergunte **"Como tratar as questões em aberto que surgirem?"**:
+- **Tratar no architecture.md (como hoje):** as questões vão para a seção 8 e você as responde ao revisar o documento.
+- **Uma a uma, assim que surgirem:** cada questão encontrada nas Fases 2 e 3 é perguntada na hora com `AskUserQuestion` (contexto em uma frase, opções e a sugestão marcada "(Recomendada)"), e entra na seção 8 já respondida.
+
+Registre a escolha no cabeçalho do `architecture.md` (`Questões em aberto:`).
 
 Com **Sim**, pergunte **"Qual modelo para o Advisor?"** com os itens de `ADVISOR_MODELS` do `ENV.md` (até 4 opções; o resto em "Outro"). Lista vazia ou ausente: use `Sonnet 5.5` sem perguntar; lista de um item: use-o sem perguntar. Traduza o nome pela família (primeira palavra em minúsculas: `sonnet`, `opus`, `fable`, `haiku`); se o modelo não for aceito pela IDE, use `sonnet` e avise em uma linha. Se a IDE não permitir escolher o modelo do subagente, avise e não faça a segunda pergunta.
 
@@ -394,7 +399,7 @@ Levante na seção 8 **tudo** que for diferente do código ou ambíguo no card,
 3. Preencha "Sugestão do Sub-Agent (Advisor)", **"Decisão adotada" (a sugestão do Advisor, que prevalece; não a substitua nem a conteste)**, "Divergência" e "Impacto da decisão". Confira no código os fatos em que a sugestão se apoia antes de registrar.
 4. Poste **um** comentário de auditoria na issue com `/eng-global-task-comment`, no modelo do template (freelance pula).
 
-**Sem Advisor:** apresente as questões ao usuário, como sempre.
+**Sem Advisor:** com "Tratar no architecture.md (como hoje)", apresente as questões ao usuário, como sempre; com "Uma a uma", elas já foram respondidas ao surgir (registre as respostas e escreva só as que surgirem na escrita do documento).
 
 ---
 
@@ -417,6 +422,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).
 **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