atlas-workflow 0.9.0 → 0.9.2

package/plugins/atlas-workflow-orchestrator/skills/atlas-backlog-generator/SKILL.md

@@ -33,8 +33,10 @@ Se faltar informação não bloqueante, gere o backlog com premissas marcadas e
 6. **Decompor em sprints:** transforme o objetivo em fatias verticais pequenas, cada uma com objetivo único, dependências e PRD futuro (`PRD_S<NN>_<slug>.md`).
 7. **Priorizar:** para cada sprint, preencha MoSCoW, ganho, esforço e prioridade usando a regra da seção 8.3 do template.
 8. **Selecionar próxima sprint:** escolha a primeira sprint executável respeitando dependências, DoR, MoSCoW, esforço x ganho e risco. Registre a justificativa na seção 20.
-9. **Salvar artefato:** grave o backlog no path pedido ou, se não houver path, crie o diretório `.atlas/backlog/` no projeto consumidor e use `.atlas/backlog/BACKLOG_MESTRE_<slug>.md`.
-10. **Validar antes de finalizar:** releia o arquivo salvo e confirme que não restaram placeholders acidentais, exceto campos conscientemente pendentes e marcados.
+9. **Atualização não destrutiva:** se o arquivo já existe, compare antes/depois com `validateBacklogUpdate(before, after, { authorizedIds })` de `../_shared/scripts/document_quality.mjs`. `authorizedIds` contém somente IDs cuja mudança foi explicitamente decidida pelo usuário. Preserve demais IDs, linhas `done`, decisões `decidido|fechado|aprovado`, itens/sprints e ordem histórica.
+10. **Registrar alterações:** toda atualização acrescenta `## Registro de alterações` (data, IDs afetados, motivo e fonte). Não reescreva histórico anterior.
+11. **Salvar artefato:** grave o backlog no path pedido ou, se não houver path, crie o diretório `.atlas/backlog/` no projeto consumidor e use `.atlas/backlog/BACKLOG_MESTRE_<slug>.md`.
+12. **Validar antes de finalizar:** bloqueie se `validateBacklogUpdate` apontar sprint/decisão removida, sprint `done` alterada, enum inválido, ciclo de dependência, placeholder acidental ou falta de registro. Confirme também que dependências referenciam IDs existentes.
 
 ---
 
@@ -76,6 +78,7 @@ O backlog final deve:
 - Ter catálogo de fases preservado e adaptado apenas quando necessário.
 - Ter riscos, decisões e próxima sprint executável preenchidos.
 - Ser específico o bastante para gerar PRDs de sprint depois com `atlas-sprint-prd-generator`.
+- Preservar histórico/IDs em update e passar validação de ciclos/enums/placeholders.
 
 ---
 
@@ -86,3 +89,5 @@ O backlog final deve:
 - Não inventar endpoints, tabelas, schemas, fornecedores, métricas ou responsabilidades como fatos. Quando forem hipóteses, marcar como premissa.
 - Não transformar o backlog em plano técnico de implementação. Código, classes e comandos entram no plano/PRD quando apropriado, não no backlog mestre.
 - Não deixar `[...]` ou placeholders óbvios no arquivo final, salvo quando o campo estiver deliberadamente pendente e explicado.
+- Não renumerar IDs, reabrir/editar sprint `done`, alterar decisão fechada ou remover item não relacionado por conveniência editorial.
+- Não ser acionada pelo orquestrador: permanece **explicit-only**, fora de qualquer cadeia automática.

package/plugins/atlas-workflow-orchestrator/skills/atlas-direct-execute/SKILL.md

@@ -149,6 +149,8 @@ For each task, keep a tiny task contract:
 
 Do not widen scope for opportunistic cleanup.
 
+**Minimalism rung (per task, before writing):** prefer the minimal viable implementation that satisfies the obligation — reuse existing repo code/symbol before introducing a new abstraction; use a stdlib/native platform feature before a new dependency; avoid indirection, factory, wrapper, extra layer, config option, or extra file not required by an obligation or invariant. This rung constrains only new abstraction/indirection/file/dependency. It never reduces trust-boundary validation, error handling, data-loss handling, invariants, scenario/test coverage, or negative paths. When minimal and safe conflict, choose safe.
+
 Before the first concrete task, emit `task_started`. After the first workspace mutation, emit `first_write`.
 
 ### 4. Gate each task
@@ -175,6 +177,8 @@ After tasks and local gates pass, write `.atlas/state/<run_id>/<slice>.json` fol
 
 For direct execution, the state file is still the only validator input. Use the user-provided PRD/spec path as `plan_path` when no handoff plan exists, and include direct-contract anchors in `boundary_refs` such as `direct.O1`, `direct.invariant.permissions`, or `direct.risk.partial_failure`.
 
+Persist the full direct contract using the additive state extension: `base_sha`, `head_sha`, `contract_kind: direct`, non-empty `obligations`, `invariants`, `scenario_probes`, `risk_probes`, `validation_map`, `task_evidence`, empty `repair_evidence`, `worktree_baseline` and `worktree_final`. Capture baseline before the first mutation and final immediately before handoff; `files_changed`/evidence must equal `base_sha...head_sha` + snapshot delta. Capture base from an explicit task/spec anchor or execution-start `HEAD`; never infer it from branch name. Recompute `head_sha` and `diff_stat` immediately before handoff. A direct state without obligations is invalid and must block.
+
 The state file is the only validator input. Validation is always **sibling**, on every host: this executor **never** dispatches `atlas-task-validator` itself and never validates its own work in the same context. After tasks and local gates pass and the state file is written, this executor **stops mutation** and returns `validator_handoff_required` with the `state_path`. The orchestrator then dispatches `atlas-task-validator` as the next isolated sibling phase, locks it via `atlas_lock_validator`, and — if the verdict is `fail` — dispatches `atlas-findings-repair` (not this executor) before the **2nd and last** validator.
 
 After writing the state file and before returning, emit `state_path_created` with the same `state_path`.
@@ -190,7 +194,7 @@ The verdict is consumed by the **orchestrator**, not by this executor:
 
 This executor only re-engages if the orchestrator explicitly re-dispatches it for a new slice. It must not "fix" observations and reopen a closed slice; real follow-up from an observation goes to the final report or backlog, not into an extra in-slice change.
 
-If isolated subagents are unavailable in the current environment, do not pretend the slice is validator-closed. Run a local self-check against the same contract, report `validator not run`, and mark residual risk explicitly.
+If isolated subagents or MCP are unavailable, return `blocked` with the missing prerequisite and next safe action. Never replace cold validation with a local self-check or report `validator not run` as an accepted pipeline outcome.
 
 ## Stop Conditions
 
@@ -211,7 +215,7 @@ Keep final report short:
 - changed scope
 - files touched
 - validations run
-- validator verdict/cycles
+- `validator_handoff_required` + `state_path`
 - blockers or residual risks
 
 Do not include the full internal contract unless the user asks.

package/plugins/atlas-workflow-orchestrator/skills/atlas-findings-repair/SKILL.md

@@ -49,6 +49,7 @@ Leia `atlas_run_state` como fonte primária do estado da run. O `state_path` con
 5. **Não despachar validator, review ou qualquer subagente.** O orquestrador faz isso.
 6. **Não iniciar terceiro ciclo.** Esta skill existe só entre validator 1 e validator 2.
 7. **Não trocar o `state_path`.** Atualize o arquivo original em lugar; redirecionar o boundary invalida a correlação do repair.
+8. **Não inventar correlação.** IDs devem existir no packet recebido, sem duplicatas; todo arquivo tocado pertence a pelo menos um `repair_evidence` recebido e nenhum arquivo extra é permitido.
 
 ## Fluxo
 
@@ -67,6 +68,8 @@ Leia do plano apenas o mínimo necessário:
 - Section 6 — contratos técnicos
 - Section 8 — checklist
 
+Capture também `base_sha`, `head_sha`, `task_evidence`, `repair_evidence`, `worktree_baseline` e `worktree_final` do state.
+
 ### 2. Ler os findings recebidos
 
 Trabalhe somente com findings de severidade:
@@ -75,6 +78,8 @@ Trabalhe somente com findings de severidade:
 - `P1`
 - `P2`
 
+Cada finding novo deve ter `id`, `failure_mode`, `evidence`, `recommendation` e `fix_validation`. `msg` é compatibilidade deprecated e não substitui esses campos.
+
 Se o pacote vier vazio, inconsistente ou sem finding reparável, pare em `blocked`.
 
 ### 3. Montar contrato mínimo de reparo
@@ -115,7 +120,11 @@ Se o finding persistir por falta de decisão de produto, dependência externa ou
 
 Ao terminar:
 
-- atualize o conteúdo do `state_path` original se a evidência do boundary mudou
+- atualize `files_changed` com todo arquivo tocado, inclusive novo/adjacente
+- recompute `head_sha` (`git rev-parse HEAD`) e `diff_stat`; preserve `base_sha`
+- preserve `worktree_baseline` e recapture `worktree_final` após o repair; derive o boundary completo do delta entre snapshots
+- acrescente `repair_evidence[]` no shape `{finding_id, files_touched, checks_run, status}`
+- garanta que cada `repair_evidence.files_touched` esteja em `files_changed`
 - mantenha a mesma slice
 - não invente novo run state paralelo
 
@@ -128,6 +137,7 @@ Retorne saída curta e estruturada com:
 - `state_path`
 - `files_touched`
 - `checks_run`
+- `repairs`: array `{finding_id, files_touched, checks_run, status: resolved|blocked}`
 - `residual_risk` (se houver)
 
 O orquestrador chamará `atlas_lock_validator(action=repair_complete, repair_run_id=..., state_path=<mesmo path original>)` e só então poderá despachar o validator final.

package/plugins/atlas-workflow-orchestrator/skills/atlas-plan-execute/SKILL.md

@@ -130,16 +130,30 @@ Create `.atlas/state/<run_id>/<slice>.json` following `packages/templates/STATE_
 {
   "run_id": "<run_id>",
   "slice": "<slice id>",
+  "base_sha": "<base commit explícito do plano/handoff>",
+  "head_sha": "<git rev-parse HEAD ao fechar a execução>",
+  "contract_kind": "plan",
   "tasks": ["T01"],
   "files_changed": ["relative/path.ext"],
   "diff_stat": "N files, +X -Y",
   "plan_path": ".atlas/plans/<id>.plan.md",
   "boundary_refs": ["§2.I1", "§6.1", "§8"],
+  "obligations": [],
+  "invariants": [{"id": "I1", "requirement": "<invariante>", "expected_evidence": ["<path/check>"]}],
+  "scenario_probes": [{"id": "S1", "scenario": "<cenário>", "expected": "<resultado>"}],
+  "risk_probes": [{"id": "R1", "risk": "<risco>", "probe": "<pergunta verificável>"}],
+  "validation_map": [{"obligation_ids": [], "checks": ["<comando>"], "status": "passed"}],
+  "task_evidence": [{"task": "T01", "files": ["relative/path.ext"], "checks": ["<comando>"], "result": "passed"}],
+  "repair_evidence": [],
+  "worktree_baseline": [{"path": "relative/preexisting.ext", "status": "M", "sha256": "<64 hex>"}],
+  "worktree_final": [{"path": "relative/preexisting.ext", "status": "M", "sha256": "<64 hex>"}],
   "executed_at": "ISO8601",
   "executor_skill": "atlas-plan-execute"
 }
 ```
 
+Capture `base_sha` da referência explícita do plano/handoff; nunca infira pelo nome da branch. Antes da primeira mutação, capture `worktree_baseline`; imediatamente antes do handoff, capture `worktree_final`. `files_changed` e `task_evidence` representam exatamente `base_sha...head_sha` + delta entre snapshots. Dirty preexistente byte/status-idêntico fica fora; qualquer alteração posterior entra.
+
 Validation is always **sibling**, on every host. The validator is registered as a real subagent on every host, but this executor **never** dispatches it and never validates its own work. After tasks and local gates pass and the state file is written, this executor **stops mutation** and returns `validator_handoff_required` with the `state_path`. The orchestrator dispatches `atlas-task-validator` as the next isolated sibling phase, locks it via `atlas_lock_validator`, and — if the verdict is `fail` — dispatches `atlas-findings-repair` (not this executor) before the **2nd and last** validator.
 
 After writing the state file and before returning, emit `state_path_created` with the same `state_path`.
@@ -157,5 +171,5 @@ This executor does not parse the validator output — the **orchestrator** does,
 
 Never decide by substring matching prose. Once the slice is closed, do not edit code, tests, or boundary files just to satisfy an observation; that reopens the slice and forces an avoidable re-validation. Real follow-up from an observation goes to the final report or a backlog item, not into an extra in-slice change.
 
-### 10. Report final outcome
-At the end of execution, report completed tasks, validations run, validator outcome, and any residual gaps.
+### 10. Report executor handoff
+Report only completed tasks, local validations, files changed, and `validator_handoff_required` with `state_path`. Validator verdict/cycles and final residuals belong exclusively to the orchestrator's final report.

package/plugins/atlas-workflow-orchestrator/skills/atlas-plan-handoff/SKILL.md

@@ -47,8 +47,8 @@ No workflow `full`, `atlas-plan-handoff` é autoria documental do agente princip
 
 ## Fluxo obrigatório
 
-1. **Classificação da tarefa:** feature, ui, contract, navigation, shared, security, diagnostic, refactoring, testing. Leia `project-rules/index/<tipo>.md` e regras em `project-rules/rules/` (ou equivalente do repo ativo).
-2. **Grounding no código:** confirme padrões, contratos e comandos locais (`flutter analyze` / `flutter test` com path do package) antes de inferir.
+1. **Classificação da tarefa:** feature, ui, contract, navigation, shared, security, diagnostic, refactoring, testing. Leia instruções reais aplicáveis do repo; `project-rules/` é apenas um formato possível, nunca requisito universal.
+2. **Grounding no código:** confirme padrões, contratos, manifests e comandos reais antes de inferir. Resolva baseline/perfis via `../_shared/references/stack-profiles.md` + `detectStackProfiles(project_root, declared_commands, boundary_paths)`; não presuma Flutter nem aplique perfil fora do package correspondente.
 3. **Decisões estáveis:** sanar bloqueios com perguntas ao usuário; registrar no plano (não recopiar tabela D* do PRD — referenciar `PRD §3`).
 4. **Escrita:** artefato markdown no path canônico `.atlas/plans/`. Teto orientativo ~250–350 linhas (até ~450 com slices).
 
@@ -112,7 +112,9 @@ Tarefas `#### T01.` … `#### TNN.` com schema de `BOUNDARY_PRD_PLAN.md` canôni
 - **Quality gates** (opcional em tasks críticas)
 - **Casos mínimos** (somente em tasks de teste)
 
-Última task típica: **Validação final** (`flutter analyze`, `flutter test`, passos manuais alinhados a **PRD §4–6**).
+**Regra de minimalismo estrutural (autoria de task):** ao redigir `Mudança esperada`, prefira a forma mínima viável que cumpre o `Critério de done` — reusar módulo/símbolo já existente no repo antes de introduzir nova abstração; usar stdlib/feature nativa antes de dependência nova; evitar indireção, factory, wrapper, camada ou opção de config não exigida por PRD/invariante. A regra recai **somente** sobre abstração/indireção/arquivo/dependência nova. **Nunca** reduz: validação de trust-boundary, error-handling, data-loss, invariantes §2, cobertura de cenário/teste e negative paths. Em dúvida entre enxuto e seguro, escolha seguro.
+
+Última task típica: **Validação final** (checks reais da stack ativa e passos manuais alinhados a **PRD §4–6**). Flutter usa `flutter analyze/test`; Node e Python usam somente scripts/ferramentas declarados no repo/plano.
 
 ### 6. Contratos técnicos (só ambiguidade PRD → código)
 
@@ -126,7 +128,7 @@ Tarefas `#### T01.` … `#### TNN.` com schema de `BOUNDARY_PRD_PLAN.md` canôni
 
 - Critérios derivados de **PRD §6** + invariantes **§2** deste plano.
 - Título recomendado: `## 8. Validação e checklist (validator)`.
-- Comandos globais de analyze/test do package.
+- Comandos globais aplicáveis ao package, derivados de manifests/scripts reais; nunca inventar `flutter`, `npm` ou `pytest`.
 
 ---
 

package/plugins/atlas-workflow-orchestrator/skills/atlas-prd-interview/SKILL.md

@@ -41,8 +41,11 @@ Ataque principalmente as seguintes seções do template de PRD:
 * **§5 Contrato funcional e invariantes:** `❌` se campos críticos não possuírem regras de formato (ex: decimais) ou se a regra de negócio for ambígua/impossível de verificar na codebase.
 * **§6 Critérios de aceite (negócio):** `❌` se o critério for subjetivo, não observável ou não testável.
 
-3. **Perguntas por Rodada (AskUserQuestion):** Formule rodadas de no máximo 4 perguntas concisas via ferramenta nativa `AskUserQuestion`, com exatamente 3 opções e indicando a recomendada. **Pare o turno e aguarde a resposta.**
-4. **Veredito Final:** Só emita o veredito de `Pronto para planejamento` quando zerar todos os `❌`.
+3. **Resolver mecanismo estruturado:** chame `atlas_capabilities`, leia `question_prompt` e use seu `mechanism`/shape. Nunca hardcode nome de ferramenta de host. Se o descriptor estiver ausente ou indisponível, bloqueie a rodada; não degrade para pergunta livre sem correlação.
+4. **Perguntas por rodada:** formule no máximo 4 perguntas concisas, exatamente 3 opções, recomendada explícita e `decision_id` D* estável. Antes de perguntar, use `pendingInterviewQuestions` de `../_shared/scripts/document_quality.mjs` para excluir decisões já fechadas.
+5. **Persistência imediata:** ao receber respostas, grave-as no mesmo PRD antes de qualquer nova pergunta, preservando IDs/anchors e acrescentando histórico. Use `persistInterviewRound(prd_path, answers)`, que escreve via arquivo temporário + rename e valida readback; falha bloqueia. Nunca acumule respostas apenas no chat.
+6. **Reindexação:** releia o PRD salvo, reexecute o índice §3–§6 e recalcule perguntas pendentes. Decisão fechada não pode reaparecer em rodada posterior.
+7. **Veredito Final:** só emita `Pronto para planejamento` quando zerar todos os `❌`; no workflow, devolva controle ao orquestrador para reexecutar artifact/scan/TC.
 
 ---
 
@@ -55,6 +58,8 @@ Ataque principalmente as seguintes seções do template de PRD:
 §6 Aceite:        ✅/⚠️/❌
 ```
 
+O índice é materializado novamente após cada persistência; não reutilize índice anterior à resposta.
+
 ---
 
 ## Uso standalone vs protocolo interno no workflow (PRD D10/D11)

package/plugins/atlas-workflow-orchestrator/skills/atlas-slice-review/SKILL.md

@@ -54,7 +54,7 @@ Base the review on three inputs:
 
 ### 1. Build the slice boundary first
 Before reviewing code, identify:
-* diff physical boundary (`git diff --name-only main...HEAD`).
+* boundary físico do diff a partir do state/task ids; use a base configurada ou upstream e inclua mudanças não commitadas pertencentes à slice.
 * Section 2 - Invariants of Execution (contract).
 * Section 6 - Technical Contracts (signatures and shapes).
 * Section 8 - Validation and Checklist (QA criteria).
@@ -81,10 +81,43 @@ Ask what the implementation forgot:
 * **View & rendering:** inputs empty, null, partial, out of order, UI permission conditional.
 * **Contracts:** shape drift, enums, mappers, RLS server-side, i18n parity.
 
+Aplique estes probes determinísticos a cada símbolo ou hunk alterado relevante:
+* **Linha a linha:** leia cada hunk alterado e a função completa que o contém; construa entradas, estados, timings ou plataformas concretas capazes de provocar falha.
+* **Comportamento removido:** para cada guard, validação, cleanup, error path ou teste removido/substituído, identifique o invariante protegido e prove onde o novo código o restabelece.
+* **Rastreamento cross-file:** inspecione callers e callees quando assinaturas, shapes de retorno, erros, timing, ordem ou pré-condições mudarem.
+* **Altitude:** confirme que a mudança corrige o componente proprietário do invariante, sem empilhar um caso especial local sobre um defeito compartilhado.
+* **Regras aplicáveis:** inspecione arquivos de instruções do repo que governam os arquivos alterados. Reporte apenas violações exatas, com path da regra, texto da regra, linha violadora e impacto concreto.
+
+Reuse, simplificação e eficiência só viram findings quando o diff atual cria custo comportamental, operacional ou de manutenção concreto. Não reporte preferências de estilo.
+
 ### 4. Distinguish current-diff findings from pre-existing issues
 Prefer findings attributable to the executed slice. Mark pre-existing issues as observations or separate notes to keep signals clean and actionable.
 
-### 5. Output Expectations
+### 5. Verifique candidatos antes de reportar
+
+Elimine duplicatas que descrevam o mesmo defeito no mesmo local. Classifique cada candidato restante como:
+* `CONFIRMED` — evidência e cenário de falha alcançável sustentam o defeito.
+* `REFUTED` — código, tipo, invariante ou guard prova que o candidato é falso ou já está tratado.
+* `NEEDS_EVIDENCE` — o cenário é relevante, mas a evidência disponível não estabelece o defeito.
+
+Apenas `CONFIRMED` vira finding. Descarte `REFUTED`. Mova `NEEDS_EVIDENCE` para `Perguntas Abertas ou Suposições`, sem apresentá-lo como defeito. Nunca mantenha um candidato apenas por ser plausível.
+
+Antes de renderizar a saída, materialize os findings confirmados como JSON e execute o gate canônico Node `node scripts/classify_findings.mjs <findings.json>`. Cada item deve conter `severity`, `task_id`, `title`, `file`, `line`, `failure_mode`, `evidence`, `recommendation` e `fix_validation`. Saída não-zero bloqueia o relatório até o payload ser corrigido; é proibido ignorar o gate ou substituir campos ausentes por texto vazio. Array vazio é válido quando não há findings confirmados.
+
+Node é o único requisito runtime deste gate e funciona em Linux/macOS/Windows. `scripts/classify_findings.py` permanece por uma release somente como wrapper compatível que delega ao Node; não é fonte canônica nem torna Python obrigatório.
+
+### 6. Recomende uma correção de causa raiz
+
+Todo finding deve incluir exatamente uma recomendação principal de correção e uma validação que comprove a correção. A recomendação deve:
+* atacar a causa raiz no componente proprietário do invariante violado;
+* ser cirúrgica e permanecer no boundary revisado, salvo quando a evidência provar que o proprietário está fora dele;
+* preservar contratos do plano, arquitetura e comportamento existente não implicado pelo finding;
+* nomear concretamente componente, condição e comportamento esperado;
+* ser a melhor correção sustentada pela evidência disponível, nunca uma alegação sem suporte de superioridade absoluta.
+
+Não ofereça alternativas A/B. Não forneça patch completo nem altere código. Se a evidência for insuficiente para recomendar uma correção com segurança, classifique o candidato como `NEEDS_EVIDENCE` em vez de emitir finding.
+
+### 7. Output Expectations
 
 Return exactly this structure:
 
@@ -97,6 +130,8 @@ Return exactly this structure:
 - **Arquivo:** `relative/path.ext:line`
 - **Modo de falha:** [o que quebra e como]
 - **Evidência:** [o que suporta o finding]
+- **Correção recomendada:** [uma correção cirúrgica na causa raiz]
+- **Validação da correção:** [teste/check específico que comprova a resolução]
 
 ### P1 - <short title>
 [same shape]

package/plugins/atlas-workflow-orchestrator/skills/atlas-slice-review/references/scenario-lenses.md

@@ -34,6 +34,14 @@ Use these lenses to find hidden bugs in the executed slice. Apply only the relev
 - Is retry or re-entry behavior still coherent after this slice?
 - Did generated files, localization keys, imports, routes, RPC signatures, or schemas match the verified repo convention?
 
+## Mecânica da mudança
+
+- Qual invariante cada guard, validação, cleanup, error path ou teste removido/substituído protegia, e onde ele foi restabelecido?
+- Callers e callees alterados ainda concordam sobre pré-condições, shapes de retorno, erros, timing e ordem?
+- A mudança corrige o componente proprietário do invariante ou adiciona um caso especial local frágil?
+- Algum novo problema de reuse, simplificação ou eficiência tem custo comportamental, operacional ou de manutenção concreto?
+- As instruções aplicáveis do repo expõem uma violação exata, atribuível a uma linha e com impacto concreto?
+
 ## Security and safety
 
 - Did the slice weaken permission, ownership, or visibility checks?

package/plugins/atlas-workflow-orchestrator/skills/atlas-slice-review/scripts/classify_findings.mjs

@@ -0,0 +1,60 @@
+#!/usr/bin/env node
+import fs from 'node:fs';
+import { pathToFileURL } from 'node:url';
+
+export const SEVERITY_ORDER = Object.freeze({ P0: 0, P1: 1, P2: 2, P3: 3 });
+export const REQUIRED_TEXT_FIELDS = Object.freeze([
+  'task_id', 'title', 'file', 'failure_mode', 'evidence', 'recommendation', 'fix_validation',
+]);
+
+export function normalizeFinding(finding, index) {
+  if (!finding || typeof finding !== 'object' || Array.isArray(finding)) {
+    throw new Error(`Finding ${index} must be a JSON object`);
+  }
+  if (!(finding.severity in SEVERITY_ORDER)) {
+    throw new Error(`Finding ${index} has invalid severity: ${JSON.stringify(finding.severity)}`);
+  }
+  const missing = REQUIRED_TEXT_FIELDS.filter(
+    (field) => typeof finding[field] !== 'string' || !finding[field].trim(),
+  );
+  if (missing.length) throw new Error(`Finding ${index} missing required fields: ${missing.join(', ')}`);
+  if (!Number.isInteger(finding.line) || finding.line < 1) {
+    throw new Error(`Finding ${index} has invalid line: ${JSON.stringify(finding.line)}`);
+  }
+  return {
+    severity: finding.severity,
+    task_id: finding.task_id,
+    title: finding.title,
+    file: finding.file,
+    line: finding.line,
+    summary: typeof finding.summary === 'string' ? finding.summary : '',
+    failure_mode: finding.failure_mode,
+    evidence: finding.evidence,
+    recommendation: finding.recommendation,
+    fix_validation: finding.fix_validation,
+    diff_attributed: finding.diff_attributed !== false,
+  };
+}
+
+export function classifyFindings(payload) {
+  if (!Array.isArray(payload)) throw new Error('Findings input must be a JSON array');
+  return payload.map(normalizeFinding).sort((a, b) => (
+    SEVERITY_ORDER[a.severity] - SEVERITY_ORDER[b.severity]
+      || a.task_id.localeCompare(b.task_id)
+      || a.file.localeCompare(b.file)
+      || a.line - b.line
+  ));
+}
+
+export function run(argv = process.argv.slice(2)) {
+  if (argv.length !== 1) throw new Error('Usage: node classify_findings.mjs <findings.json>');
+  const payload = JSON.parse(fs.readFileSync(argv[0], 'utf8'));
+  process.stdout.write(`${JSON.stringify(classifyFindings(payload), null, 2)}\n`);
+}
+
+if (import.meta.url === pathToFileURL(process.argv[1] ?? '').href) {
+  try { run(); } catch (error) {
+    process.stderr.write(`${error.message}\n`);
+    process.exitCode = 1;
+  }
+}

package/plugins/atlas-workflow-orchestrator/skills/atlas-slice-review/scripts/classify_findings.py

@@ -1,56 +1,24 @@
 #!/usr/bin/env python3
-"""Normalize raw findings into a severity-oriented review structure."""
+"""Wrapper legado: delega ao gate Node canônico por uma release."""
 
 from __future__ import annotations
 
-import argparse
-import json
 import pathlib
+import subprocess
 import sys
-from typing import Any
-
-SEVERITY_ORDER = {"P0": 0, "P1": 1, "P2": 2, "P3": 3}
-
-
-def load_findings(path: pathlib.Path) -> list[dict[str, Any]]:
-    payload = json.loads(path.read_text(encoding="utf-8"))
-    if not isinstance(payload, list):
-        raise ValueError("Findings input must be a JSON array")
-    return payload
-
-
-def normalize_finding(finding: dict[str, Any]) -> dict[str, Any]:
-    severity = finding.get("severity", "P2")
-    if severity not in SEVERITY_ORDER:
-        severity = "P2"
-    return {
-        "severity": severity,
-        "task_id": finding.get("task_id", ""),
-        "title": finding.get("title", ""),
-        "file": finding.get("file", ""),
-        "line": finding.get("line"),
-        "summary": finding.get("summary", ""),
-        "evidence": finding.get("evidence", ""),
-        "diff_attributed": bool(finding.get("diff_attributed", True)),
-    }
 
 
 def main() -> int:
-    parser = argparse.ArgumentParser(description=__doc__)
-    parser.add_argument("findings_json", help="Path to a JSON array of findings")
-    args = parser.parse_args()
-
+    if len(sys.argv) != 2:
+        sys.stderr.write("Usage: python classify_findings.py <findings.json>\n")
+        return 1
+    script = pathlib.Path(__file__).with_name("classify_findings.mjs")
     try:
-        normalized = [normalize_finding(item) for item in load_findings(pathlib.Path(args.findings_json))]
-    except (FileNotFoundError, ValueError, json.JSONDecodeError) as exc:
-        sys.stderr.write(f"{exc}\n")
+        return subprocess.run(["node", str(script), sys.argv[1]], check=False).returncode
+    except FileNotFoundError:
+        sys.stderr.write("Node.js ausente: requisito runtime do Atlas\n")
         return 1
 
-    normalized.sort(key=lambda item: (SEVERITY_ORDER[item["severity"]], item["task_id"], item["file"], item["line"] or 0))
-    json.dump(normalized, sys.stdout, indent=2)
-    sys.stdout.write("\n")
-    return 0
-
 
 if __name__ == "__main__":
     raise SystemExit(main())

package/plugins/atlas-workflow-orchestrator/skills/atlas-sprint-prd-generator/SKILL.md

@@ -16,6 +16,7 @@ Todo PRD gerado por esta skill deve declarar explicitamente a cadeia de execuç
 * Sprint ID: `S<NN>` (`S01`, `S02`, etc.).
 * Opcional: app/projeto alvo quando houver mais de uma fonte de backlog/roadmap.
 * Opcional: path de saída.
+* Opcional: path explícito do backlog autoritativo. Quando fornecido, vence qualquer descoberta.
 
 *Se faltar o Sprint ID, peça antes de gerar.*
 
@@ -23,10 +24,11 @@ Todo PRD gerado por esta skill deve declarar explicitamente a cadeia de execuç
 
 ## Workflow Obrigatório
 
-1. **Localizar Insumos:** Descubra a raiz do repo com `git rev-parse --show-toplevel`. Localize o template canônico em `<raiz-do-plugin>/packages/templates/PRD_TEMPLATE.md`. Localize backlog/roadmap no repo ativo (`**/BACKLOG_MESTRE*.md`).
-2. **Extração da Sprint:** Leia a fonte de backlog/roadmap. Localize a sprint, extraindo fase-fonte, objetivo, dependências e filename do PRD.
-3. **Inspecionar Código:** Busque no codebase por classes, tabelas, RPCs, mappers e rotas existentes que influenciam a feature.
-4. **Redação do PRD:** Siga estritamente o layout enxuto e focado do `PRD_TEMPLATE.md` (teto orientativo de ~180-220 linhas), separando dores e regras de negócio de implementações de código.
+1. **Localizar Insumos:** Descubra a raiz do repo com `git rev-parse --show-toplevel`. Localize o template canônico em `<raiz-do-plugin>/packages/templates/PRD_TEMPLATE.md`. Localize backlogs candidatos (`**/BACKLOG_MESTRE*.md`) sem escolher por heurística silenciosa.
+2. **Fechar autoridade:** use `../_shared/scripts/document_quality.mjs#resolveSprintAuthority` com precedência fixa: path explícito → backlog canônico referenciado pelo artefato/input → único candidato contendo o Sprint ID. Zero match bloqueia. Múltiplos matches sem autoridade, mesmo com conteúdo parecido, bloqueiam com paths conflitantes e `next_action` para informar o path.
+3. **Extração da Sprint:** leia somente a fonte autoritativa. Extraia fase-fonte, objetivo, dependências e filename do PRD; registre no PRD o path + anchor exato da linha/seção do backlog.
+4. **Inspecionar Código:** Busque no codebase por contratos reais que influenciam a feature e registre anchors estáveis (`path:símbolo` ou `path:linha`) nas referências; não copie implementação para o PRD.
+5. **Redação/atualização:** siga `PRD_TEMPLATE.md`. Ao atualizar, preserve IDs `D*`, decisões fechadas, anchors e histórico; novos IDs são append-only. Mudança deliberada em D* exige decisão explícita e registro histórico.
 
 ### Resolução Canônica de Templates
 
@@ -57,6 +59,7 @@ Todo PRD criado ou atualizado por esta skill deve incluir, perto do topo e sem s
 
 * **Status final:** `Aprovado para implementação`. Setar **automaticamente** ao finalizar a geração — é o status que o gate TC do orquestrador exige (`required_status=Aprovado para implementação`) para o PRD avançar no pipeline. Não deixar `Draft` (trava o gate e força correção manual). O sinal de determinismo que sustenta o avanço é o `atlas_scan_prd` (varredura de ambiguidade) + entrevista quando houver padrões bloqueantes — não o campo Status, que é marcador documental.
 * **Data:** ISO `YYYY-MM-DD` (hoje).
+* **Autoridade:** `Relacionado`/`Referências` inclui backlog autoritativo + anchor da sprint e anchors de código/contrato usados.
 * **Escopo:** Lista fechada de capacidades funcionais.
 * **UX:** Cobrir caminhos de `loading`, `empty`, `error`, `success` e `permission` sob a perspectiva do usuário.
 * **Critérios de Aceite:** Binários e observáveis, divididos conforme `PRD_TEMPLATE.md` em: **Produto**, **UX**, **Dados** e **Regressão de produto**.

package/plugins/atlas-workflow-orchestrator/skills/atlas-task-validator/SKILL.md

@@ -34,9 +34,16 @@ Read the JSON file at `.atlas/state/<run_id>/<slice>.json` using the schema in `
 3. **Executed task ids** — `tasks`.
 4. **Boundary refs** — `boundary_refs`.
 5. **Explicit cold-review note** — you did not observe implementation; read current code only.
+6. **Deterministic boundary** — `base_sha`, `head_sha`, `contract_kind`, and all evidence/probe arrays.
+7. **Working-tree delta** — compare `worktree_baseline`/`worktree_final` and current tree; unchanged preexisting dirt stays outside, later mutations must be evidenced.
+8. **Repair correlation** — on attempt 2, correlate every target finding id with `repair_evidence` in the same state path.
 
 Do not accept inline contract, copied diff, or pasted task lists as the validation boundary. If `state_path` is missing, unreadable, or lacks any required field, return JSON with `verdict: "fail"` and one P1 finding for `Input insuficiente: <missing item>`.
 
+Compatibilidade: state legado mínimo sem `contract_kind` só é aceito quando `executor_skill=atlas-plan-execute`; nesse caso o plano continua autoritativo. State de `atlas-direct-execute` exige extensão completa e `obligations` não vazio.
+
+Antes de validar código, compare `base_sha...head_sha`, `HEAD`, snapshot final atual e delta `worktree_baseline→worktree_final` com `files_changed`/evidências. Não infira base pelo nome da branch. Divergência gera `boundary_violations` e finding P1 estruturado.
+
 ---
 
 ## Resolução Canônica de Templates
@@ -79,23 +86,24 @@ Do not accept inline contract, copied diff, or pasted task lists as the validati
 3. **For each relevant Section 6 Contract:** verify signature, behavior, and returned shape where applicable.
 4. **For each relevant Section 8 checklist item:** mark it pass or fail with evidence.
 5. **Perform cross-task checks** for shared state, missing required args, route order, partial failure handling, and UI/backend permission mismatch.
-6. **Apply universal baseline checks** below. Do not invent new mandatory criteria outside the plan and baseline.
+6. **Aplique baseline + perfis ativos** abaixo. Resolva os perfis por manifests/comandos reais conforme `../_shared/references/stack-profiles.md`; não invente critérios fora do plano, baseline e perfis ativos.
 7. **Do not patch files or propose diffs.** Suggested fix must fit in 1-2 lines of text.
 
 ---
 
-## Universal Baseline
+## Baseline universal + perfis
+
+Fonte compartilhada: `../_shared/references/stack-profiles.md`. Execute `detectStackProfiles(project_root, declared_commands, boundary_paths)` de `../_shared/scripts/document_quality.mjs`; aplique cada entrada de `boundaries` somente aos arquivos daquele package.
+
+Sempre aplique baseline universal: segurança/permissões, boundary/contratos, erros/falhas parciais, concorrência/reentrada, cleanup/estado stale, integridade de dados/input e checks realmente declarados.
+
+Ative regras específicas somente quando o perfil retornar `true`:
 
-Always apply these checks:
-* **Naming cross-layer:** New read methods use `get*` prefix. Mutation uses explicit verbs (`create`, `update`, `delete`, `add`, `remove`). Concepts keep consistent root names across layers.
-* **State lifecycle:** Shared stores or controllers reused across modes or routes must reset previous mode state in `init()` or transition.
-* **Navigation args:** Argument resolvers validate required fields; navigation passes all required ids (no empty placeholder `''`).
-* **Partial failure paths:** Multi-step mutations surface partial persistence clearly if a later step fails.
-* **Backend and UI gate match:** Sensitive mutations require server-side enforcement. UI gating alone is insufficient (Page reads `canManage` from Store).
-* **Route registration:** Literal routes are registered before parameterized routes (`/:id`, `/:id/edit`) under the same prefix.
-* **Localization:** New localization keys must exist in every required locale file; generated l10n is clean.
-* **Analyzer:** `flutter analyze` (or stack equivalent) returns zero issues for touched files in boundary.
-* **Casts and nullability:** Remote payload casts use safe defensive patterns; nulos in collections treated with `?? []`.
+- `flutter_dart`: lifecycle Flutter, rotas/args, null-safety/casts, l10n, analyze/test; GetX somente se dependência/import/regra real confirmar GetX.
+- `node_typescript`: handles/promises, validação runtime, ESM/CJS/exports/tipos e scripts Node reais.
+- `python`: context managers/cleanup, exceções/async, typing/parsing e ferramentas Python declaradas.
+
+Monorepo pode ativar múltiplos perfis, sempre restritos ao boundary correspondente. Fixture Node sem sinal Flutter não recebe regra Flutter/GetX.
 
 ---
 
@@ -110,10 +118,15 @@ Return strict JSON as the final output. Do not wrap it in Markdown and do not pr
   "verdict": "pass | fail | pass_with_observations",
   "findings": [
     {
+      "id": "F-001",
       "severity": "P0|P1|P2|P3",
       "file": "string",
-      "line": 0,
-      "msg": "string"
+      "line": 1,
+      "failure_mode": "string",
+      "evidence": "string",
+      "recommendation": "string",
+      "fix_validation": "string",
+      "msg": "string (deprecated; derivado por uma release)"
     }
   ],
   "observations": [
@@ -134,6 +147,8 @@ Return strict JSON as the final output. Do not wrap it in Markdown and do not pr
 
 `dispatch_token` must equal `validator_recovery.expected_dispatch_token`. `findings`, `observations`, and `boundary_violations` must always be arrays. Use empty arrays when there are no items.
 
+IDs são únicos, obrigatórios no formato `F-NNN` e estáveis nos dois ciclos. Severity é estritamente `P0|P1|P2|P3`. No segundo ciclo, confirme por ID que `repair_evidence` registra arquivos, checks e `status: resolved`; finding não correlacionado permanece P1. O MCP rejeita shape incompleto e `pass`/`pass_with_observations` quando há P0/P1.
+
 **Proof-of-work (`challenge_response`).** If `validator_recovery.challenge` is not `null`, it carries `{ file, algo: "sha256" }` — a boundary file you must have read access to. Compute the sha256 of that file's raw bytes (`shasum -a 256 "<challenge.file>"`) and return the hex (first token) in `challenge_response`. If `challenge` is `null`, return `null`. Never fabricate the hash: the orchestrator recomputes it from disk and blocks the slice (`challenge_failed`) on mismatch. This is a *mechanical* attestation that the verdict touched real boundary bytes — it closes the laziest bypass (claiming `pass` with no read at all); it does **not** by itself prove you read and understood the code (hashing a file does not require loading its content). Reading the boundary remains your obligation. It is not a non-forgeable isolation proof either (the MCP shares one stdio caller). Challenge failures are bounded per attempt: past the cap the slot closes terminally (`challenge_exhausted`), which usually signals path resolution diverging from the consumer root.
 
 ---