jarvis-ai-framework 8.1.0 → 8.2.0

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

@@ -40,11 +40,11 @@ Além dele, o `start` pode criar apenas os arquivos de apoio da própria sessão
 
 O workflow **só é considerado completo** após:
 
-1. O `architecture.md` estar preenchido
+1. O `architecture.md` estar preenchido, com o passe crítico feito (Fase 4.4 do workflow: seção 2.5 "Premissas e Passe Crítico", com o lido separado do presumido e a premissa que derrubaria o documento)
 2. O usuário revisar o documento
-3. O usuário **aprovar explicitamente** para prosseguir — sem Advisor, pela pergunta de transição "Aprovar o architecture.md?" (`eng.transitions-rules.md`)
+3. O usuário **aprovar explicitamente** para prosseguir, pela pergunta de transição "Aprovar o architecture.md?" (`eng.transitions-rules.md`): sempre sem Advisor e, com Advisor, sempre que a aprovação for obrigatória (autonomia `média` ou `baixa`, ou questão nova do passe crítico)
 
-**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.
+**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, salvo se o passe crítico (Fase 4.4) abriu questão nova: nesse caso, a aprovação explícita da pessoa é obrigatória; com `média` ou `baixa`, a aprovação explícita continua obrigatória.
 
 ---
 
@@ -91,8 +91,8 @@ O workflow **só é considerado completo** após:
 
 7. **Aguardar aprovação**
    - Se aprovado → Informar próximos passos
-   - Se rejeitado → Iterar no documento
-   - 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
+   - Se rejeitado → Iterar no documento, somar 1 em "Ajustes antes da aprovação" no cabeçalho e refazer o passe crítico no que mudou
+   - 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, sem questão nova aberta pelo passe crítico
 
 ---
 
@@ -238,6 +238,8 @@ Antes de considerar o `start` completo:
 - [ ] Decisões têm justificativas
 - [ ] Riscos têm mitigações
 - [ ] Componentes impactados listados com caminhos reais
+- [ ] Passe crítico feito: seção 2.5 preenchida, presumidas que mudam o plano lidas ou viradas questão
+- [ ] "Ajustes antes da aprovação" atualizado no cabeçalho
 - [ ] Usuário revisou o documento
 - [ ] Usuário aprovou explicitamente
 - [ ] Nenhum código foi executado/criado

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

@@ -37,19 +37,20 @@ Lida pelos workflows `eng.start`, `eng.plan`, `eng.work`, `eng.pre-pr` e `eng.pr
 | 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.start` | Fim, **sem Advisor**, ou com Advisor quando a aprovação é obrigatória (autonomia `média`/`baixa`, ou questão nova do passe crítico) | "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.pre-pr` | Fim | Variante B do fechamento (sem 🔴 pendente nem 🟡 herdada com `🔧 Corrigir`; só ⚪ sem decisão, ou também 🟡 com o critério de parada atingido): "Restam {c} lacunas ⚪… Como seguir?" (substitui as perguntas 2 e 4 do fechamento; com 🟡 sem decisão, o rótulo da primeira opção varia conforme o gatilho: ver o "Fechamento" do `eng.pre-pr.md`) | Aceitar as ⚪ e seguir para o PR · Corrigir antes do PR · Só gerar o relatório (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; quem escolheu revisar também tem o `[Só gerar os arquivos]` na revisão da 4.2) |
 | `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.
+Nas perguntas "Depois do work", "O que fazer com o plano?" e na variante B do fechamento do `eng.pre-pr`, a opção "como hoje" não é a primeira (em "Depois do work" e na variante B fica por último), por escolha de produto: as primeiras opções são as ações que o usuário mais quer. Na variante B, a #191 pede "Aceitar as ⚪ e seguir para o PR" como primeira opção (a recomendada), para lacunas menores não gerarem mais uma rodada. 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.
+**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, salvo se o passe crítico (Fase 4.4 do `eng.start`) abriu questão nova: nesse caso, como com autonomia `média` ou `baixa`, a aprovação explícita é obrigatória e é pedida pela pergunta "Aprovar o architecture.md?" da tabela.
 
 ### Recomendado
 

package/skills/SKILLS-ROADMAP.md

@@ -114,8 +114,8 @@ Skills existentes e planejadas do framework Jarvis.
 - **Status**: `criado`
 
 ### `product-specs-update` ✅
-- **Trigger**: atualização de specs existentes
-- **Escopo**: revisão e evolução de requisitos
+- **Trigger**: PRD ou FRD criado ou modificado; pedido para sincronizar ou indexar specs
+- **Escopo**: sincroniza PRD/FRD em cascata e mantém o índice local de specs (`$PROD_DOCS/specs-index.md`)
 - **Status**: `criado`
 
 ### `product-roadmap-report` ✅

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, SPEC, 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`), depois do merge do PR. Os documentos de trabalho nunca são publicados lá.
+Quem escreve no Central docs é o **`/eng.spec-consolidate`** (agente `eng.docs-consolidator.agent`), 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-evolution-architect/references/exemplos.md

@@ -152,7 +152,7 @@ Consolidar skills **não é a resposta**. Problema é **organização e document
 **O Que Eu Mudaria:**
 1. Criar um **INDEX.md** principal que agrupa skills por contexto
 2. Adicionar tags em metadatas das skills
-3. Criar uma skill `/jarvis-find-skill` que busca
+3. Criar uma skill de busca de skills (hipotética; não existe no framework)
 4. Melhorar `metadata.area` e `metadata.tags`
 
 **O Que Eu Não Faria:**
@@ -263,7 +263,7 @@ Quando você invoca a skill:
 ```
 "Qual skill devo usar para X?"
 ```
-❌ Isso não é pergunta arquitetural. Use `/jarvis-find-skill` em vez disso.
+❌ Isso não é pergunta arquitetural. Consulte o mapeamento comando → skill em `skills/AGENTS.md` em vez disso.
 
 ### ✅ Fazer isso:
 ```
@@ -286,7 +286,7 @@ Quando você invoca a skill:
 | "Devo criar um novo agent?" | ✅ SIM |
 | "Essa feature deveria ser skill ou workflow?" | ✅ SIM |
 | "Acho que essa feature está complexa demais" | ✅ SIM |
-| "Qual skill usa para X?" | ❌ NÃO (use `/jarvis-find-skill`) |
+| "Qual skill usa para X?" | ❌ NÃO (consulte `skills/AGENTS.md`) |
 | "Como implement feature X?" | ❌ NÃO (use skill específica) |
 | "Devemos adotar X tendência?" | ✅ SIM |
 | "Qual a diferença entre SDD e CDD?" | ✅ SIM |

package/skills/jarvis-init/SKILL.md

@@ -82,6 +82,8 @@ Regras que **substituem** qualquer trecho legado deste skill ou dos assets:
 │        ↓                                                    │
 │  9. STACKS → Adicionar as stacks (opcional, pulável)        │
 │        ↓                                                    │
+│  9.5 VALIDAR ENV.md → Arquivo inteiro × template (sempre)   │
+│        ↓                                                    │
 │  10. CONFIRMAR → Com usuário                                │
 │                                                             │
 └─────────────────────────────────────────────────────────────┘
@@ -204,14 +206,15 @@ Identificar qual IDE o usuário está utilizando:
    ⚠️ O arquivo ENV.md já existe. O que deseja fazer?
    A: Sobrescrever completamente
    B: Atualizar apenas variáveis específicas
-   C: Upgrade — adicionar variáveis novas do template (não toca nos valores existentes)
+   C: Upgrade — adicionar variáveis novas do template (não troca valor existente sem a sua resposta)
    D: Cancelar
    ```
+   A (que segue o fluxo completo), B e C terminam pelo **passo 9.5 (validar o ENV.md)**; D não toca no arquivo.
 
 **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, salvo as exceções declaradas no item 9 (`CENTRAL_DOCS_LOCATION` e `TOKEN_TASK_MANAGER`, com confirmação; `JARVIS_PROJECT` vazio, automático).
+> **O upgrade só acrescenta chaves novas:** nenhuma chave já existente, preenchida ou não, é alterada, salvo as exceções declaradas no item 9 (`CENTRAL_DOCS_LOCATION` e `TOKEN_TASK_MANAGER`, com confirmação; `JARVIS_PROJECT` vazio, automático). Depois, a validação final (passo 9.5) pode reorganizar o arquivo, mover chaves para o assunto delas e corrigir valores fora das opções, sempre perguntando: nenhum valor muda sem a resposta da pessoa.
 > 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`
@@ -223,14 +226,14 @@ Identificar qual IDE o usuário está utilizando:
    ```
    ✅ ENV.md já está atualizado. Nenhuma variável nova encontrada.
    ```
-   Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar.
+   Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, rodar o **passo 9.5 (validar o ENV.md)** e então encerrar.
 7. Se houver diff, exibir prévia:
    ```
    🔍 Variáveis novas encontradas no template:
      + NOVA_VAR_1=
      + NOVA_VAR_2=valor-padrão
 
-   Serão adicionadas ao final do ENV.md sem alterar os valores existentes.
+   Serão adicionadas no assunto de cada uma, na posição do template, 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}`, `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, só se a raiz do workspace tiver `.git`, garanta `docs/jarvis/` no `.gitignore`.
@@ -246,18 +249,13 @@ Identificar qual IDE o usuário está utilizando:
 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.
     - **`.gitignore` numa raiz sem `.git` (ex.: `WORKSPACE_MODE=workspace`):** a raiz não é versionada, então esse arquivo não tem efeito. Não o apague; só avise: `ℹ️ O .gitignore da raiz do workspace não tem efeito (a raiz não é um repositório). Pode removê-lo se quiser.`
-11. Appender as novas variáveis ao final do `ENV.md` com comentário de data:
-   ```
-   # --- Upgrade YYYY-MM-DD ---
-   NOVA_VAR_1=
-   NOVA_VAR_2=valor-padrão
-   ```
+11. Acrescentar as novas variáveis no assunto de cada uma, na posição do template, junto das chaves do mesmo assunto (ex.: uma `DATA_*` nova vai para o bloco Data Engineering, ao lado das irmãs), com o comentário do template. Sem bloco datado no fim. O `jarvis init --upgrade` (terminal) acrescenta no fim, num bloco `# --- Upgrade ... ---`, por ser determinístico; o passo 9.5 põe essas chaves no lugar.
 12. Confirmar:
    ```
    ✅ ENV.md atualizado! N variável(is) nova(s) adicionada(s).
    ⚠️ Preencha os valores em branco antes de usar os novos recursos.
    ```
-13. Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar (não continuar para o fluxo de onboarding completo).
+13. Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, rodar o **passo 9.5 (validar o ENV.md)** e então encerrar (não continuar para o fluxo de onboarding completo).
 
 **⚠️ OBRIGATÓRIO - Criação do ENV.md**:
 
@@ -787,10 +785,12 @@ if (IDE === "claude") {
 }
 ```
 
-O arquivo `$IDE/ENV.md` deve seguir a **estrutura e ordem** de `templates/ENV-template.md` (não um dump reordenado). Blocos mínimos esperados após o init:
+O arquivo `$IDE/ENV.md` deve seguir a **estrutura e ordem** de `templates/ENV-template.md` (não um dump reordenado), com cada assunto na moldura de `# ====` do template; o passo 9.5 confere no fim. Blocos mínimos esperados após o init (os títulos são os do template; os comentários de cada bloco foram omitidos):
 
 ```markdown
-# --- Workspace e identidade ---
+# =============================================================================
+# Workspace e identidade
+# =============================================================================
 WORKSPACE=
 WORKSPACE_REPOS=
 WORKSPACE_MODE={workspace|project}
@@ -798,17 +798,17 @@ USER={resolvido}
 MAX_AI_EXECUTION_PERCENTAGE={60-100}
 ENABLE_CDD=true
 
-# --- Organização ---
+# =============================================================================
+# Organização (obrigatório — opções vêm do taxonomy.md)
+# =============================================================================
 SQUAD={valor}
 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 e pastas
+# =============================================================================
 IDE={valor}
 DOCS_FOLDER=docs
 FLOWS_FOLDER={commands|workflows}
@@ -824,16 +824,22 @@ PROD_TEMPLATES=...
 PROD_DOCS=...
 DISCOVERIES_FOLDER_NAME=discoveries
 DISCOVERIES_DOCS=...
+PROD_MODE={product-led|developer-guided}
+ARTIFACT_STYLE={ai-generated|human-generated}
 
-# --- Task manager (opcional; vazio = freelance) ---
+# =============================================================================
+# Task manager (opcional)
+# =============================================================================
 TASK_MANAGER=
 TASK_MANAGER_ACCESS=
 TASK_MANAGER_URL_BASE=
 
-# --- Controle de versão / chat / demais opcionais do template ---
+# =============================================================================
+# Controle de versão (opcional)
+# =============================================================================
 VERSION_CONTROL=
 VERSION_CONTROL_ACCESS=
-# ... restante do template (MESSAGE_*, DATABASE, JARVIS_PROJECT, CENTRAL_DOCS_*, etc.)
+# ... restante do template, cada assunto na sua moldura (MESSAGE_*, DATABASE, JARVIS_PROJECT, CENTRAL_DOCS_*, etc.)
 JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework
 ```
 
@@ -1159,6 +1165,47 @@ O tempo de ~10 minutos é referência, não limite. Nunca leia `.env*`, chaves o
 
 ---
 
+### 9.5 Validar o ENV.md (sempre, no fim)
+
+Roda no fim de todo caminho que grava o `ENV.md`: criação (opção A ou ENV.md novo), atualização de variáveis (B) e Upgrade (C, inclusive "já atualizado"), depois do passo 9. Não roda ao cancelar (D). Objetivo: o arquivo fica **100% correto** e **separado por assunto**, na estrutura e na ordem de `templates/ENV-template.md`, com cada assunto na moldura de `# ====`:
+
+```
+# =============================================================================
+# Workspace e identidade
+# =============================================================================
+```
+
+**Nunca mostre valor de variável**: nas perguntas e na saída vão só o nome da chave e se a linha tem algo depois do `=`.
+
+**1. Conferir o arquivo inteiro contra o template.** Cada item que falhar é um problema:
+
+| Verificação | Exemplo | Correção sugerida (primeira opção, "(Recomendada)") |
+|---|---|---|
+| Chave do template ausente | falta `WORKSPACE_MODE` | Acrescentar no assunto dela, com o padrão do template. Não conta como ausente uma `DATA_*` (exceto `DATA_SPECIALIZATIONS`) quando o HUB não exige o bloco DATA (regra do bloco DATA, abaixo) |
+| Chave fora do template (saiu dele ou é do projeto) | `QA_SIGNOFF_BRANCHES`, `MINHA_VAR` | Mover para o bloco final "Variáveis fora do template", com `# (descontinuada)` numa linha própria logo acima da chave e o valor intacto |
+| Chave duplicada | `HUB=` duas vezes | Manter a preenchida (ou a última) |
+| Valor fora das opções | `HUB=BACKEN`, `MAX_AI_EXECUTION_PERCENTAGE=40`, `TASK_MANAGER_ACCESS=api` | Perguntar o valor, com as opções do template ou do `taxonomy.md` (as mesmas perguntas do passo 3) |
+| Obrigatória vazia | `SQUAD=` | A mesma pergunta do passo 3 |
+| Lista de exemplo não escolhida | `TASK_MANAGER=[jira, github, gitlab]` | Escolher uma ou esvaziar |
+| Fora da ordem ou do assunto | blocos `# --- Upgrade ... ---` no fim; uma `DATA_*` longe das irmãs | Regravar na ordem do template |
+| Comentários ou separadores diferentes dos do template | comentário antigo; `# --- Assunto ---` | Trocar pelos do template (a pergunta avisa que comentários próprios se perdem) |
+| Bloco DATA fora da regra do HUB | `DATA_*` com `HUB=BACKEND` | Regra do bloco DATA (sempre exceto `DATA_SPECIALIZATIONS`, obrigatória em qualquer HUB): `HUB=DATA` exige o bloco (as que faltarem contam como ausentes); `HUB=FULLCYCLE` o deixa opcional (nem ausente, nem a remover), como a criação (passo 5) e o Upgrade (item 4) já fazem; outro HUB: sugerir remover o bloco |
+
+Não pergunte de novo o que as exceções 9 a 9.3 do Upgrade já resolveram nesta execução.
+
+**2. Perguntar cada problema** com `AskUserQuestion`: **uma pergunta por problema**, em chamadas de até 4 abas, agrupadas por tipo de verificação. Cada pergunta tem a correção sugerida como primeira opção, marcada "(Recomendada)", e uma opção que mantém o arquivo como está (ex.: "Manter como está"). Nada é corrigido sem resposta. Sem problema nenhum, não pergunte: avise `✅ ENV.md conferido: nada a corrigir.`
+
+**3. Regravar (só o que foi aceito).**
+- **Reorganização aceita:** use a estrutura do template (ordem, comentários e molduras), mas só com as chaves que o arquivo já tem mais as acrescentadas por resposta: chave que a pessoa recusou acrescentar não entra, e um bloco inteiro que o arquivo não tem (como o DATA, fora da regra do HUB) não volta. Ponha o valor atual de cada chave no lugar dela, cada uma no seu assunto e junto das irmãs, e desfaça os blocos datados. As chaves fora do template vão para o último bloco, "Variáveis fora do template", cada uma com `# (descontinuada)` logo acima. **Nenhuma chave é apagada**, salvo as que a pessoa mandou remover numa resposta (como o bloco DATA). O comentário fica numa linha própria: na mesma linha da chave, o CLI o leria como parte do valor.
+- **Reorganização recusada:** grave só as correções de conteúdo aceitas, no lugar em que cada chave está, sem mover o resto.
+- **Conferência antes de gravar:** o **conjunto de chaves** depois é o de antes, mais as acrescentadas e menos as removidas por resposta; e o mapa chave → valor das chaves mantidas é igual (só mudam as corrigidas por resposta). Se não for, não grave e avise: `⚠️ A regravação mudaria chaves ou valores que não foram respondidos: nada gravado.`
+
+**4. Rules do perfil.** Se uma correção mudou `HUB`, `POSITION`, `AREA`, `SQUAD`, `ARTIFACT_STYLE` ou `RTK_ENABLED`, rode o **passo 8** de novo: ele já rodou com os valores antigos, e as rules em `$IDE/rules/` seriam de outro perfil.
+
+**5. Resumo.** Liste o que foi corrigido e o que ficou pendente (respostas "Manter como está"), só com nomes de chave, e se o passo 8 rodou de novo.
+
+---
+
 ### 10. Confirmar Criação
 
 ```
@@ -1442,7 +1489,8 @@ Bem-vindo! 🎉
 - [ ] Detectou IDE corretamente
 - [ ] Verificou se ENV.md já existe
 - [ ] Se ENV.md existe: ofereceu opção de Upgrade (C) além de Sobrescrever/Atualizar/Cancelar
-- [ ] Se Upgrade: calculou diff template vs ENV.md e appendou apenas variáveis faltantes
+- [ ] Se Upgrade: calculou diff template vs ENV.md e acrescentou apenas as variáveis faltantes, no assunto de cada uma (sem bloco datado)
+- [ ] **Validou o ENV.md inteiro no passo 9.5**: uma pergunta por problema, regravação na ordem do template com as molduras de `# ====`, chaves fora do template no fim com `# (descontinuada)`, nenhum valor exibido nem trocado sem resposta
 - [ ] Coletou todas as variáveis obrigatórias
 - [ ] USER gravado no ENV.md a partir da identidade local
 - [ ] Validou MAX_AI_EXECUTION_PERCENTAGE (60-100) - para campos livres