jarvis-ai-framework 5.2.0 → 5.5.0

package/bin/lib/core/profile-filter.js

@@ -7,7 +7,9 @@
  * `rules/AGENTS.md`: ao mudar uma, mude as três.
  *
  * Regras:
- * - Os quatro eixos (HUB, POSITION, AREA, SQUAD) são combinados com AND.
+ * - Os eixos (HUB, POSITION, AREA, SQUAD e o opcional ARTIFACT_STYLE) são combinados com AND.
+ * - ARTIFACT_STYLE (5º campo, opcional): ausente no bloco = `all`; perfil sem valor =
+ *   `ai-generated`. Sem coringa: FULLCYCLE e GENERALIST não o satisfazem (é escolha da pessoa).
  * - `all` casa qualquer valor; listas são separadas por vírgula.
  * - FULLCYCLE (HUB) satisfaz qualquer HUB.
  * - GENERALIST (POSITION) satisfaz qualquer POSITION e qualquer AREA.
@@ -20,8 +22,11 @@
 import { existsSync, readdirSync, readFileSync, statSync } from "node:fs";
 import { join, relative, sep } from "node:path";
 
+// SQUAD para no próximo `|`: o 5º campo (ARTIFACT_STYLE) é opcional.
 const APPLIES_TO_RE =
-  /> \*\*Applies to:\*\* HUB: ([^|]+)\| POSITION: ([^|]+)\| AREA: ([^|]+)\| SQUAD: (.+)/;
+  /> \*\*Applies to:\*\* HUB: ([^|]+)\| POSITION: ([^|]+)\| AREA: ([^|]+)\| SQUAD: ([^|\n]+)(?:\| ARTIFACT_STYLE: ([^|\n]+))?/;
+
+const DEFAULT_ARTIFACT_STYLE = "ai-generated";
 
 /**
  * @typedef {Object} AppliesTo
@@ -29,6 +34,7 @@ const APPLIES_TO_RE =
  * @property {string} POSITION
  * @property {string} AREA
  * @property {string} SQUAD
+ * @property {string} ARTIFACT_STYLE - `all` quando o bloco não traz o campo
  */
 
 /**
@@ -37,6 +43,7 @@ const APPLIES_TO_RE =
  * @property {string} POSITION
  * @property {string} AREA
  * @property {string} SQUAD
+ * @property {string} [ARTIFACT_STYLE] - vazio = `ai-generated`
  */
 
 /**
@@ -52,6 +59,7 @@ export function parseAppliesTo(content) {
     POSITION: match[2].trim(),
     AREA: match[3].trim(),
     SQUAD: match[4].trim(),
+    ARTIFACT_STYLE: (match[5] || "all").trim(),
   };
 }
 
@@ -76,7 +84,11 @@ export function matchesProfile(appliesTo, profile) {
   const position = generalist || axisMatches(appliesTo.POSITION, profile.POSITION);
   const area = generalist || axisMatches(appliesTo.AREA, profile.AREA);
   const squad = axisMatches(appliesTo.SQUAD, profile.SQUAD);
-  return hub && position && area && squad;
+  const style = axisMatches(
+    appliesTo.ARTIFACT_STYLE || "all",
+    profile.ARTIFACT_STYLE || DEFAULT_ARTIFACT_STYLE
+  );
+  return hub && position && area && squad && style;
 }
 
 function walkMarkdown(dir) {

package/bin/lib/core/sync-engine.js

@@ -149,7 +149,7 @@ export function syncAssets(targetDir, ide, opts = {}) {
 
   // RTK: detectar e reconciliar RTK_ENABLED + rtk-rules.md
   if (!opts.dryRun) {
-    const rtkResult = reconcileRtk(ideDir, targetDir, ide);
+    const rtkResult = reconcileRtk(ideDir, targetDir, ide, { keepEnvValues: opts.keepEnvValues });
     if (rtkResult) result.copied.push(rtkResult);
   }
 
@@ -191,9 +191,11 @@ export function syncAssets(targetDir, ide, opts = {}) {
  * Detecta RTK no PATH e reconcilia RTK_ENABLED no ENV.md + rtk-rules.md na IDE.
  * - RTK encontrado → RTK_ENABLED=true no ENV.md, mantém rule
  * - RTK não encontrado → remove rtk-rules.md da IDE, mantém RTK_ENABLED=false
+ * - `keepEnvValues` (jarvis init --upgrade): não troca RTK_ENABLED=false por true, porque o
+ *   upgrade só acrescenta chaves novas; acrescentar RTK_ENABLED quando ela não existe continua valendo
  * @returns {string|null} mensagem de log ou null se nenhuma ação
  */
-function reconcileRtk(ideDir, targetDir, ide) {
+function reconcileRtk(ideDir, targetDir, ide, { keepEnvValues = false } = {}) {
   const rtkRulePath = join(ideDir, "rules", "rtk-rules.md");
   const envPath = join(ideDir, "ENV.md");
   const hasRtk = (() => {
@@ -209,7 +211,7 @@ function reconcileRtk(ideDir, targetDir, ide) {
     // Ativar RTK_ENABLED no ENV.md se existir e estiver false
     if (existsSync(envPath)) {
       let env = readFileSync(envPath, "utf-8");
-      if (env.includes("RTK_ENABLED=false")) {
+      if (env.includes("RTK_ENABLED=false") && !keepEnvValues) {
         env = env.replace("RTK_ENABLED=false", "RTK_ENABLED=true");
         writeFileSync(envPath, env, "utf-8");
         return "(rtk) detectado — RTK_ENABLED=true no ENV.md";

package/bin/lib/core/token-report.js

@@ -91,6 +91,7 @@ export function buildReport(root, profile, opts = {}) {
       POSITION: profile.POSITION,
       AREA: profile.AREA,
       SQUAD: profile.SQUAD,
+      ARTIFACT_STYLE: profile.ARTIFACT_STYLE || "ai-generated",
     },
     rtkEnabled,
     estimate: `tokens = bytes ÷ ${BYTES_PER_TOKEN} (estimativa)`,

package/bin/lib/docs/storage/build-index.js

@@ -53,7 +53,8 @@ export function renderIndex(root, squad) {
     const areaDir = join(root, squad, area);
     const files = walkFiles(areaDir).filter((f) => {
       const name = f.split(sep).pop();
-      return name.startsWith(prefix) && name.endsWith(".md");
+      // {nome}.public.md (versão humanizada, ARTIFACT_STYLE=human-generated) não entra no índice
+      return name.startsWith(prefix) && name.endsWith(".md") && !name.endsWith(".public.md");
     });
     out.push(`## ${area}`, "", `> ${title}`, "");
     if (files.length === 0) {

package/bin/lib/vcs/api.js

@@ -108,6 +108,14 @@ export async function createMergeRequest(repoUrl, opts) {
   };
 }
 
+// Tipos de issue do Bitbucket (campo `kind`; ele não tem labels livres).
+const BITBUCKET_KINDS = ["bug", "enhancement", "proposal", "task"];
+
+/**
+ * @param {string} repoUrl
+ * @param {{ title: string, body: string, labels?: string[] }} opts - `labels` padrão: ["bug"].
+ *   No Bitbucket, a primeira label vira o `kind` quando é um tipo válido; senão, `bug`.
+ */
 export async function createIssue(repoUrl, opts) {
   const { title, body, labels = ["bug"] } = opts;
   const repo = parseRepoUrl(repoUrl);
@@ -149,7 +157,11 @@ export async function createIssue(repoUrl, opts) {
     {
       method: "POST",
       headers,
-      body: { title, content: { raw: body } },
+      body: {
+        title,
+        content: { raw: body },
+        kind: BITBUCKET_KINDS.includes(labels[0]) ? labels[0] : "bug",
+      },
     }
   );
   if (!ok || !json?.links?.html?.href) {

package/bin/lib/vcs/create-issue.js

@@ -9,11 +9,25 @@ import { createIssue, parseRepoUrl } from "./api.js";
  * @param {string} options.repo - URL ou `org/repo` do repositório
  * @param {string} options.title - Título da issue
  * @param {string} options.bodyFile - Path de um arquivo com o corpo em markdown
+ * @param {string} [options.labels] - Labels separadas por vírgula (padrão: bug)
  */
-export async function runCreateIssue({ repo, title, bodyFile }) {
+/**
+ * "enhancement, documentation" → ["enhancement", "documentation"]; vazio → undefined (padrão: bug).
+ * @param {string} [raw]
+ * @returns {string[] | undefined}
+ */
+export function parseLabels(raw) {
+  const list = String(raw || "")
+    .split(",")
+    .map((l) => l.trim())
+    .filter(Boolean);
+  return list.length ? list : undefined;
+}
+
+export async function runCreateIssue({ repo, title, bodyFile, labels }) {
   if (!title || !bodyFile || !repo) {
     console.error(
-      "Uso: jarvis vcs create-issue --repo <url-ou-path> --title <titulo> --body-file <path>"
+      "Uso: jarvis vcs create-issue --repo <url-ou-path> --title <titulo> --body-file <path> [--label <labels>]"
     );
     process.exit(1);
   }
@@ -33,7 +47,7 @@ export async function runCreateIssue({ repo, title, bodyFile }) {
   const body = existsSync(bodyFile) ? readFileSync(bodyFile, "utf-8") : "";
 
   try {
-    const result = await createIssue(repoUrl, { title, body });
+    const result = await createIssue(repoUrl, { title, body, labels: parseLabels(labels) });
     parseRepoUrl(repoUrl);
     console.log(`✅ Issue aberto: ${result.url}`);
     console.log(JSON.stringify(result));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jarvis-ai-framework",
-  "version": "5.2.0",
+  "version": "5.5.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: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",
     "lint": "eslint bin/ test/",
     "lint:fix": "eslint bin/ test/ --fix",
     "format": "prettier --write bin/ test/",

package/rules/AGENTS.md

@@ -75,6 +75,8 @@ Cada arquivo de rule declara para quais perfis se aplica via bloco `applies_to`,
 > **Applies to:** HUB: {valor ou all} | POSITION: {valor ou all} | AREA: {valor ou all} | SQUAD: {valor ou all}
 ```
 
+Campo opcional no fim: `| ARTIFACT_STYLE: {ai-generated, human-generated ou all}` (ausente = `all`).
+
 **Eixos de filtragem:**
 
 | Eixo | Exemplos de valor | `all` significa |
@@ -83,13 +85,14 @@ Cada arquivo de rule declara para quais perfis se aplica via bloco `applies_to`,
 | POSITION | TECH LEAD, PM, QA-ENGINEER, SENIOR, GENERALIST | qualquer cargo |
 | AREA | ENGINEERING, PRODUCT | qualquer área |
 | SQUAD | CORE | qualquer squad |
+| ARTIFACT_STYLE (opcional) | ai-generated, human-generated | qualquer estilo (ENV vazio = `ai-generated`; sem coringa) |
 
 **Regras:**
 - Uma rule é aplicada se **todos** os eixos forem satisfeitos (AND, não OR)
 - Arquivos sem bloco `applies_to` são considerados **universais** — copiados para qualquer perfil
 - `rules/AGENTS.md` nunca é filtrado — sempre copiado
 
-**Quem faz a filtragem:** o skill `/jarvis-init` (Passo 9 — Profile-Aware Rules Sync). Ao criar, atualizar ou fazer upgrade do ENV.md, copia para `$IDE/rules/` apenas as rules que batem com o perfil (HUB + POSITION + AREA + SQUAD) e deleta as que não batem mais.
+**Quem faz a filtragem:** o skill `/jarvis-init` (Passo 8 — Profile-Aware Rules Sync). Ao criar, atualizar ou fazer upgrade do ENV.md, copia para `$IDE/rules/` apenas as rules que batem com o perfil (HUB + POSITION + AREA + SQUAD + ARTIFACT_STYLE) e deleta as que não batem mais.
 
 **Ao criar uma nova rule**, definir o bloco `applies_to` é obrigatório. Sem ele, a rule é tratada como universal — o que pode ser indesejado para rules domain-specific.
 

package/rules/artifact-style-rules.md

@@ -0,0 +1,53 @@
+> **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all | ARTIFACT_STYLE: human-generated
+
+# Artifact Style Rules (human-generated)
+
+## Objetivo
+
+Com `ARTIFACT_STYLE=human-generated` no `ENV.md`, nada do que o Jarvis publica leva marca de IA, e todo documento gerado oferece uma versão humanizada para repassar a clientes ou stakeholders.
+
+## Escopo
+
+Esta rule só é copiada para `$IDE/rules/` quando o perfil tem `ARTIFACT_STYLE=human-generated` (eixo do `Applies to`, Passo 8 do `/jarvis-init`). Vale para todo comando e para pedidos fora de workflow.
+
+## Regras
+
+### Obrigatório
+
+1. **Publicado pelo Jarvis: sempre sem marcas, sem perguntar.**
+   - Vale para: mensagem de commit, título e descrição do PR/MR, comentário no card, issue aberta (ex.: `jarvis-report-issue`).
+   - 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**).
+   - 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:
+   - `Co-Authored-By` de ferramenta, "Generated with …" ou links para a ferramenta;
+   - menções a IA, Claude ou outros modelos, assistente, agente, sub-agente ou Advisor;
+   - `recommended_model` nem comentários de frontmatter dirigidos à IA;
+   - "Reportado por: IA" ou qualquer autoria atribuída à ferramenta.
+4. **Estilo da versão humanizada:** texto corrido de pessoa para pessoa. Parágrafos onde cabe parágrafo; lista só quando há itens; sem emojis de status em excesso; sem fórmulas como "Em resumo", "Vale ressaltar". Mantenha o conteúdo, as decisões e os links úteis ao leitor (issue, PR, card).
+
+### Proibido
+
+- Alterar o documento original para gerar a versão humanizada.
+- Publicar commit, PR, comentário ou issue com qualquer item do checklist.
+- Reescrever commits já enviados ao remoto.
+- Contar `{nome}.public.md` na sequência de IDs (`prd-{id}`, `discovery-{id}`…) ou incluí-lo em índices.
+
+### Recomendado
+
+- Com vários documentos gerados no mesmo comando, uma pergunta só, listando os documentos.
+
+## Exceções
+
+- Com `ARTIFACT_STYLE=ai-generated` (ou vazio), esta rule não existe na sessão e nada muda.
+
+## Referências
+
+- `templates/ENV-template.md` (`ARTIFACT_STYLE`)
+- `skills/jarvis-init/SKILL.md` (Pergunta 9 e Passo 8)
+- `workflows/engineering/eng.pr.md` (conferência antes do push)
+- `rules/AGENTS.md` (eixo `ARTIFACT_STYLE` do `Applies to`)

package/rules/product/prod-rules.md

@@ -40,12 +40,14 @@ PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
 PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$DOCS_FOLDER/jarvis/$PROD_FOLDER_NAME
+DISCOVERIES_DOCS=$DOCS_FOLDER/jarvis/discoveries
 ```
 
 Abaixo, segue uma descrição de algumas das variáveis mais importantes para as rotinas de produto:
 
 - $DOCS_FOLDER é o nome da pasta principal de documentações do projeto. Ela fica localizada na raiz do projeto.
-- $PROD_DOCS é a pasta dos documentos de produto gerados pelos comandos (PRD, FRD, épicos, histórias, discovery): `$JARVIS_DOCS/product` (`docs/jarvis/product`), nos dois modos de trabalho e fora do versionamento do código. Os de engenharia ficam em `$ENG_DOCS` (`docs/jarvis/engineering`).
+- $PROD_DOCS é a pasta dos documentos de produto gerados pelos comandos (PRD, FRD, épicos, histórias): `$JARVIS_DOCS/product` (`docs/jarvis/product`), nos dois modos de trabalho e fora do versionamento do código. Os de engenharia ficam em `$ENG_DOCS` (`docs/jarvis/engineering`).
+- $DISCOVERIES_DOCS é a pasta dos discoveries: `$JARVIS_DOCS/discoveries` (`docs/jarvis/discoveries`), fora de `product/`. ENV sem a variável: use `$PROD_DOCS/discoveries` se essa pasta existir, senão `$JARVIS_DOCS/discoveries`, e avise para rodar `jarvis init --upgrade`.
 - $PROD_FOLDER_NAME é o nome padrão da pasta de produto que será usada em diversos contextos do projeto.
 - $TEMPLATES_FOLDER é o nome da pasta principal de templates do projeto.
 - $PROD_TEMPLATES é o caminho completo para os templates de produto.
@@ -126,7 +128,7 @@ Dentro das pastas do projeto, os caminhos de pastas e o nome dos arquivos finais
 - Documento de Requisitos Funcionais: `$PROD_DOCS/prd-{id}-{nome-do-pai}/frd-{id}-{nome}.md`
 - Épico: `$PROD_DOCS/prd-{id}-{nome-do-pai}/issues/epic-{id}-{nome}.md`
 - História / tarefa: `$PROD_DOCS/prd-{id}-{nome-do-pai}/issues/{story|task}-{id}-{nome}.md`
-- Discovery (rascunho de uma ideia, anterior ao PRD): `$PROD_DOCS/discoveries/discovery-{id}-{nome}.md`. Usa `status` (`in_review` enquanto o rascunho existe; `cancelled` se o veredito for não seguir) e `verdict` (vazio durante a entrevista, `proceed`, `investigate_more` ou `do_not_proceed`). O veredito é uma recomendação; um PRD, FRD, épico ou issue criado depois prevalece como fonte da verdade.
+- Discovery (rascunho de uma ideia, anterior ao PRD): `$DISCOVERIES_DOCS/discovery-{id}-{nome}.md`. Usa `status` (`in_review` enquanto o rascunho existe; `cancelled` se o veredito for não seguir) e `verdict` (vazio durante a entrevista, `proceed`, `investigate_more` ou `do_not_proceed`). O veredito é uma recomendação; um PRD, FRD, épico ou issue criado depois prevalece como fonte da verdade.
 
 O ID deve ser iterado nos novos arquivos seguindo a sequência existente.
 

package/rules/product/prod.spec-rules.md

@@ -147,14 +147,14 @@ A terminologia inconsistente cria confusão. "Cliente" vs "Usuário" vs "Cliente
 
 ### Princípio: Discovery como insumo
 
-**Princípio**: O discovery (`$PROD_DOCS/discoveries/discovery-{id}-{nome}.md`) é um rascunho de suposições. Ele pode servir de contexto para um PRD, FRD, épico ou issue, mas nunca é obrigatório e nunca é tratado como verdade.
+**Princípio**: O discovery (`$DISCOVERIES_DOCS/discovery-{id}-{nome}.md`) é um rascunho de suposições. Ele pode servir de contexto para um PRD, FRD, épico ou issue, mas nunca é obrigatório e nunca é tratado como verdade.
 
 **O discovery é opcional**:
 - Sem discovery apontado, siga o fluxo do comando normalmente, sem procurar na pasta `discoveries/` e sem perguntar nada sobre discovery. Ter arquivos nessa pasta não tem relação com o comando.
 - Exemplos: `/prod.spec.prd já sei o que quero` segue o fluxo de sempre; `/prod.spec.prd discovery-002` carrega o discovery.
 
 **Como apontar e achar o discovery**:
-- O usuário aponta por caminho, nome ou id (como `discovery-002`); procure em `$PROD_DOCS/discoveries/`.
+- O usuário aponta por caminho, nome ou id (como `discovery-002`); procure em `$DISCOVERIES_DOCS/`.
 - Se o arquivo não existir: informe, liste os discoveries da pasta e pergunte qual usar, ou se o usuário prefere seguir sem discovery.
 - Se a pasta `discoveries/` não existir: siga sem discovery e não crie a pasta.
 - Se mais de um arquivo casar com o que o usuário apontou: pergunte qual usar, sem escolher sozinho.

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
+- ✅ Validar o plano com o humano antes de prosseguir (pergunta "Aprovar o plan.md?" de `eng.transitions-rules.md`)
 - ✅ Escrever tudo em português (pt-BR)
 
 ---

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

@@ -271,6 +271,7 @@ O MR deve seguir o template em `$IDE/templates/engineering/PR-template.md`:
 - ❌ Commitar arquivos de configuração local
 - ❌ Commitar credenciais ou tokens
 - ❌ Mencionar AI/Claude no PR
+- ❌ Com `ARTIFACT_STYLE=human-generated`: push de commit ou PR com marca de IA ou da IDE (`Co-Authored-By` de ferramenta, "Generated with …") — conferir antes (Fase 3.0 do `eng.pr`)
 - ❌ [!IMPORTANT] PUSH DIRETO PARA `main`/`dev`
 
 ### ✅ SEMPRE FAÇA
@@ -322,7 +323,7 @@ Antes de considerar o PR completo:
 - [ ] Card do Jira movido para "In Review"
 - [ ] Comentários de code review processados
 - [ ] `pull-request.md` aprovado na sessão (e publicado, se o usuário respondeu Sim)
-- [ ] Lembrete do `/eng.spec-consolidate` na mensagem final
+- [ ] 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
 
 ---
@@ -330,8 +331,8 @@ Antes de considerar o PR completo:
 ## 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?". Com Não, o arquivo fica na sessão e nada é enviado.
-- **A sessão nunca é apagada por este comando:** o `/eng.spec-consolidate`, que roda em seguida, precisa do `architecture.md`, do `plan.md`, do `gate-checklist.md` e do `pull-request.md`. A pessoa apaga à mão quando quiser.
+- **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.
+- **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)
 

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,58 @@
+> **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.
+
+## 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`.
+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.
+
+### 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 | "Aprovar o plan.md?" | Aprovar e parar aqui (como hoje) · Aprovar e seguir para o `/eng.work` · 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.pr` | Fim | "O PR já foi aprovado e mergeado?" | Ainda não (como hoje) · Sim, rodar o `/eng.spec-consolidate` |
+
+**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 "Ir direto para 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-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);