@polymorphism-tech/morph-spec 8.25.0 → 8.27.0

package/framework/rules/morph-task-tracking.md

@@ -5,49 +5,22 @@ stacks:
 
 # MORPH-SPEC Task Tracking
 
-> Session tasks are MANDATORY in every MORPH-SPEC phase. They track real progress and must be
-> created BEFORE any phase work begins.
-
-## Rules
-
-1. **Every phase skill MUST create session tasks** using `TaskCreate` before reading files or generating outputs
-2. **Tasks are dynamic** — analyze the phase workflow and create tasks that reflect YOUR actual planned actions for this session
-3. **Every task MUST be updated**: `in_progress` before starting, `completed` after finishing
-4. **Pipeline orchestrators** (`/morph-proposal`, `/morph-apply`) MUST create master tasks for each phase
-5. **Never skip task creation** — even if resuming mid-phase, create tasks for remaining steps
-6. **Granularity**: minimum 2, typically 3-7 tasks per phase — adjust to complexity
-7. **For iterative work** (clarification rounds, quality loops): update task `subject` with round/score progress
-
-## Task Update Pattern
-
-```
-TaskUpdate(taskId, status="in_progress")   // before starting the step
-// ... do the work ...
-TaskUpdate(taskId, status="completed")     // after step finishes
-```
-
-For iterative tasks:
-```
-TaskUpdate(taskId, subject="Round 3 — score 82/100")
-```
+> Progress lives in `tasks.json` — nowhere else. There is no CLI command to mark a task done and
+> no session-level checklist to keep in sync: this file IS the record of what happened.
 
 ## Persisting Progress to `tasks.json`
 
-> **Dois sistemas, dois vocabulários.** Tudo acima desta linha é sobre as *session
-> tasks* nativas do Claude Code (`TaskCreate`/`TaskUpdate`), cujo status terminal é
-> `completed`. Tudo abaixo é sobre o `tasks.json` do morph-spec, governado por
-> `.morph/framework/schemas/tasks.schema.json`, cujo status terminal é `done` —
-> **`completed` não existe nesse enum** e o hook `protect-spec-files` rejeita a
-> gravação. Não misture os dois.
-
-Native session tasks (`TaskCreate`/`TaskUpdate`) track your live work. To persist
-task progress for the feature, write `.morph/features/{feature}/2-plan/tasks.json`,
+To record task progress for the feature, write `.morph/features/{feature}/2-plan/tasks.json`,
 touching ONLY the mutable fields:
 
 - `status` — `pending` → `in_progress` → `done` (também: `skipped`, `blocked`)
 - `outputs` — the files the task produced
 - `notes` — free-text record (deviations, context, resolved blockers)
 
+> **O status terminal é `done`.** `completed` **não existe** no enum de
+> `.morph/framework/schemas/tasks.schema.json` — é vocabulário de outro sistema, e o hook
+> `protect-spec-files` rejeita a gravação.
+
 The plan contract — `title`, `description`, `dependencies`, `effort`, `doneCriteria`,
 `group`, `agent`, `standards` — is frozen after Gate 2. Any attempt to change it is
 blocked by the `protect-spec-files` hook. `agent` (persona id, no `morph-` prefix)
@@ -59,6 +32,10 @@ as long as it touches only `status`, `outputs`, and `notes`. State is then synce
 automatically by the `state-sync` PostToolUse hook; you do not call a CLI to mark
 output.
 
+Update each task as you go — `in_progress` when you pick it up, `done` when it is finished —
+rather than batching every write to the end of the phase. `morph-spec status`, `dag`, `verify`
+and the dashboard all read this file, so a stale `tasks.json` is a blind orchestrator.
+
 ## Deviation Tracking
 
 When completing a task differently than originally planned, record the reason in the

package/framework/rules/morph-workflow.md

@@ -14,7 +14,7 @@ stacks:
 **NEVER skip to code without a specification.** Every feature must progress through phases:
 
 1. **Proposal** — Problem statement + scope + risks (`0-proposal/proposal.md`). No acceptance criteria: verifiable behaviour lives in the use cases.
-2. **Design** (optional, UI-heavy) — Design system + mockups + flows (`1-design/`)
+2. **UI/UX Design** (optional, UI-heavy) — Design system + mockups + flows. The phase id is `uiux` (that is the gate name); the folder is `1-design/`
 3. **Plan** — Use cases first, then technical spec + mandate + tasks (`2-plan/usecases/UC-{nn}-{slug}.md`, `spec.md`, `mandate.md`, `tasks.json`). Each use case post-condition must be observable in a test and reaches the task's `doneCriteria` verbatim.
 4. **Implement** — Code + recap (`3-implement/recap.md`)
 5. **Review** — Review report + Gate 3 (`4-review/review-report.md`)
@@ -24,7 +24,7 @@ stacks:
 ## Phase Sequence
 
 ```
-proposal → [design] → plan → implement → review
+proposal → [uiux] → plan → implement → review
 ```
 
 Use `morph-spec status {feature}` to see current phase and pending approval gates.
@@ -35,26 +35,32 @@ Use `morph-spec status {feature}` to see current phase and pending approval gate
 
 | Command | Purpose |
 |---------|---------|
-| `/morph-proposal {feature}` | Full spec pipeline (phases 1-4, pauses for approval) |
-| `/morph-apply {feature}` | Implement feature (phase 5) |
+| `/morph-proposal {feature}` | Business understanding + plan — pauses at Gate 1 and Gate 2 |
+| `/morph-apply {feature}` | Autonomous execution + review — pauses at Gate 3 |
 | `/morph-status` | Feature dashboard |
 
+The full slash-command and CLI surface lives in the resident `.claude/CLAUDE.md` and in
+`.morph/framework/CLI.md` — this table only carries the three phase entry points.
+
 ---
 
 ## State & Outputs
 
 | Path | Notes |
 |------|-------|
-| `.morph/state.json` | **READ-ONLY** — updated automatically by the `state-sync` hook |
+| `.morph/features/{feature}/feature.json` | **Authoritative + committed** feature state. Write it through the CLI (`create`, `score`, `gate-check`, `approve`) — a hand Edit collides with the `state-sync` hook |
+| `.morph/state.json` | **READ-ONLY** — thin, gitignored index rebuilt from `feature.json` on load; kept in sync by the `state-sync` hook |
 | `.morph/features/{feature}/{phase}/` | Feature outputs organized by phase |
 | `.morph/framework/` | **READ-ONLY** — framework files managed by morph-spec |
 | `.morph/config/config.json` | Project configuration (editable) |
 
 ### output types
 
-Output types are defined in `src/core/paths/output-schema.js`. State sync is
-handled automatically by the `state-sync.js` PostToolUse hook — the agent
-does not need to record outputs through any CLI call.
+The canonical filename and phase folder of every output type are fixed by
+morph-spec itself — the concrete paths are in the table below. State sync is
+handled automatically by the `state-sync.js` PostToolUse hook: write the file
+at the right path and it is recorded; the agent does not call any CLI to
+register an output.
 
 ---
 
@@ -183,35 +189,42 @@ Every task in `tasks.json` MUST reference its FR(s) in the `description` field s
 
 ---
 
-## Mandatory Skills per Phase
-
-During implementation, these skills MUST be invoked at the specified triggers:
+## Debugging
 
-### Implement Phase
-| Trigger | Skill | When |
-|---------|-------|------|
-| Before each task | `superpowers:test-driven-development` | Invoke BEFORE writing any code for a task |
-| Before marking a task complete | `morph-verification-before-completion` | Invoke BEFORE setting a task's `status` to `done` in `tasks.json` |
-| On bug/unexpected | `superpowers:systematic-debugging` | Invoke IF a bug or unexpected behavior is encountered |
-| After all tasks | `morph-post-implementation` | Invoke AFTER all tasks completed |
-| Before PR | `morph-checklist` | Invoke BEFORE creating pull request |
+When a bug or unexpected behavior shows up mid-task, invoke `superpowers:systematic-debugging`
+with the `Skill()` tool **before proposing a fix** — root cause first, never a patch on the
+symptom. This is MANDATORY; do NOT skip it.
 
-### Tasks Phase
-| Trigger | Skill | When |
-|---------|-------|------|
-| On parallel tasks | `superpowers:dispatching-parallel-agents` | When parallel task groups are identified |
-| Before completion | `morph-verification-before-completion` | Before completing the tasks phase |
+Everything else that a rule like this might list is owned by the flow itself, and duplicating it
+here would put a second, staler copy in permanent context:
 
-These are MANDATORY. Use the `Skill()` tool. Do NOT skip.
+| Concern | Where it actually lives |
+|---------|-------------------------|
+| TDD before writing code | The feature's `mandate.md` (TDD is built in) — the resident `.claude/CLAUDE.md` says to prefer `morph-*` over the generic `superpowers:*` equivalents |
+| Verifying a task before `status: "done"` | `morph-spec verify {feature} [task]` (build + tests + validators + e2e), then the `morph-eval` skill for the 0-10 score |
+| Parallel dispatch | `morph-spec dag {feature}` decides sequential vs parallel; execution and isolation rules are in `morph-apply` §2/§3b |
+| Closing the phase / opening the PR | `morph-review` for Gate 3, then `morph-spec finish {feature} --pr\|--merge` |
 
 ---
 
 ## Scope Escalation
 
-If during implementation a task reveals significantly more complexity than estimated:
-- **Low impact:** record the added scope in the task's `notes` field (in `tasks.json`) and track the sub-steps with native `TaskCreate`/`TaskUpdate` for the current session
-- **Medium/High impact:** `/morph-scope-escalation <feature>` — re-opens the plan so the frozen contract (`title`/`description`/`dependencies`/`doneCriteria`) can be amended through the gate
-- **Never** implement extra functionality within a task without registering it — in `notes` for small additions, or via scope escalation for anything that changes the plan contract
+The plan contract frozen at Gate 2 — `spec.md`, `mandate.md`, and the immutable `tasks.json`
+fields listed in `morph-task-tracking.md` — is enforced by the `protect-spec-files` hook. When a
+task turns out to be bigger than estimated, three different situations resolve three different ways:
+
+| Situation | Path |
+|-----------|------|
+| **Small addition**, still inside the task's scope | Record it in the task's `notes` (a mutable field) — no gate to revoke, no contract to amend |
+| **Error of fact**: the spec asserts something about the code that the code contradicts, with no scope change | Append an `## Errata` block at the END of the file. Body untouched, append-only, accepted by `protect-spec-files` **without revoking the gate** — freezing the CONTRACT is not freezing an ERROR OF FACT (MORPH.md §3) |
+| **The scope itself changed**: the contract no longer describes the work | `morph-spec unapprove {feature} plan --reason "..."`, amend the plan, then re-approve. There is no shortcut around the gate for this one |
+
+Scope ambiguity the `mandate.md` does not cover is **not** an escalation: record it in
+`decisions.md`, resolve it the conservative way, and keep going — only pause if it is genuinely
+blocking (`morph-implement` §5).
+
+**Never** implement extra functionality within a task without registering it — `notes` for small
+additions, gate revocation for anything that changes the plan contract.
 
 ---
 

package/framework/skills/core/create-umbraco-lp/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a criação de uma landing page nova ponta-a-ponta a partir do
 version: core
 when-to-invoke: ao iniciar um novo projeto de LP com o template Umbraco genérico
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 stacks:
   - umbraco
 ---

package/framework/skills/core/migrate-lp-to-umbraco/SKILL.md

@@ -4,7 +4,7 @@ description: Migra uma landing page existente (React/Vite, Next.js estático ou
 version: core
 when-to-invoke: ao receber instrução "use /migrate-lp-to-umbraco {projeto}" do usuário, ou quando o usuário descrever necessidade de migrar uma LP para Umbraco
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 stacks:
   - umbraco
 ---

package/framework/skills/core/morph-apply/SKILL.md

@@ -4,7 +4,7 @@ description: Orquestra a execução autônoma de tasks de uma feature morph-spec
 version: core
 when-to-invoke: após Gate 2 aprovado, ao receber instrução "use /morph-apply" ou "implementar feature"
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-apply
@@ -158,8 +158,8 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
        (que é cortesia best-effort e pode não chegar inteira). NÃO chame
        SendMessage.
     2. NÃO toque em tasks.json, feature.json, state.json nem no board de
-       sessão (TaskCreate/TaskUpdate) — todo estado (status de task, scores,
-       gates) é gravado exclusivamente pelo orquestrador.
+       sessão — todo estado (status de task, scores, gates) é gravado
+       exclusivamente pelo orquestrador.
     3. Verificação condicional ao isolamento:
        - Batch SEM isolamento (working tree compartilhada): NÃO rode build/test da
          suíte compartilhada — edições concorrentes quebram o build umas das outras;
@@ -179,7 +179,7 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
 
 > **Alternativa quando os fluxos tocam os mesmos projetos/arquivos** (ex.: o mesmo csproj de testes compartilhado): siga a §3b-w abaixo em vez desta seção — despache com `isolation: "worktree"`, cada agente trabalha numa working tree própria e o orquestrador integra ao final.
 
-Aguardar todos os agentes terminarem, depois **ler primeiro** `.morph/features/{feature}/3-implement/reports/{taskId}.md` de cada task — é o valor de retorno autoritativo; a mensagem de texto do dispatch, se chegou inteira, é só um atalho que economiza essa leitura. Se um arquivo vier ausente, oco, ou sem os itens da cláusula 1, registre a falha de protocolo no recap. Depois, sequencialmente:
+Aguardar todos os agentes terminarem, depois **auditar os relatórios contra o trabalho** com `morph-spec report-check {feature} --json` — determinístico e independente da palavra dos agentes; é o passo que pega tanto o relatório ausente quanto o `report-stale` (completo, porém gravado antes do fim do trabalho: o agente relatou cedo e continuou escrevendo). Em `report-stale`, **não re-despache** — leia o campo `observed` (writes reais do `events.jsonl`) e atualize o relatório a partir dele. Vereditos e ações: `MORPH.md` §6. Em seguida **ler** `.morph/features/{feature}/3-implement/reports/{taskId}.md` de cada task — é o valor de retorno autoritativo; a mensagem de texto do dispatch, se chegou inteira, é só um atalho que economiza essa leitura. Depois, sequencialmente:
 - **Rodar `morph-spec verify {feature} --json` uma única vez, pós-batch** (escopo feature) — os agentes não a rodaram (cláusula 3). Vermelho: use `verify.feedback` para corrigir/redespachar ANTES de qualquer morph-eval. (Com isolamento por worktree, cada agente já rodou o verify dentro do seu worktree; o orquestrador roda o verify compartilhado UMA vez após o merge — ver §3b-w.)
 - Para cada relatório retornado:
   - Aplicar `Skill(morph-eval)`.
@@ -241,10 +241,10 @@ re-apresente o gate**: siga direto para o encerramento (§6) conforme a decisão
 ## Referências
 
 - `.morph/framework/MORPH.md` — charter NLH; §6 tem o racional completo do contrato do relatório final (aqui e no `morph-implement` §4 estão só as versões curtas coladas no dispatch)
-- `framework/skills/core/morph-implement/SKILL.md` — §4 tem o template sequencial paritário a este §3b
-- `framework/skills/core/morph-eval/SKILL.md`
-- `framework/skills/core/morph-review/SKILL.md`
-- `framework/skills/core/morph-plan/SKILL.md` §5a — resolve e carimba `task.agent`/`task.standards` no plano; fonte primária deste §3b
+- `.claude/skills/morph-implement/SKILL.md` — §4 tem o template sequencial paritário a este §3b
+- `.claude/skills/morph-eval/SKILL.md`
+- `.claude/skills/morph-review/SKILL.md`
+- `.claude/skills/morph-plan/SKILL.md` §5a — resolve e carimba `task.agent`/`task.standards` no plano; fonte primária deste §3b
 - `morph-spec dag {feature}` — análise de DAG e decisão sequencial vs paralelo (ponderada por effort), incluindo recomendação de isolamento (`isolation.recommended: "worktree"`)
 - `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores+e2e (código antes do juiz)
 - `morph-spec score {feature} {task} {score} [--dims a,c,q,t]` — grava taskScores no feature.json com timestamp server-side

package/framework/skills/core/morph-brainstorming/SKILL.md

@@ -4,7 +4,7 @@ description: Entende o negócio, os usuários e a arquitetura antes de qualquer
 version: core
 when-to-invoke: ao receber um novo request de feature, antes de morph-plan
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-brainstorming
@@ -148,5 +148,5 @@ options:
 ## Referências
 - `.morph/framework/MORPH.md` — seções 1 (Papéis), 2 (Fases), 5 (Gates), Trust Mode
 - `morph-spec standards --find "<query>"` — para referência de standards relevantes à stack (ver `morph-standards`)
-- `framework/skills/core/morph-stack-scan/SKILL.md` — invocada na Parte 0 (varredura), antes de qualquer pergunta
+- `.claude/skills/morph-stack-scan/SKILL.md` — invocada na Parte 0 (varredura), antes de qualquer pergunta
 - `.morph/framework/MORPH.md` §5 — regras de pausa do Gate 1 (trust mode)

package/framework/skills/core/morph-eval/SKILL.md

@@ -4,7 +4,7 @@ description: Avalia a qualidade de uma tarefa ou fase com rubricas graduadas 0-1
 version: core
 when-to-invoke: ao completar uma tarefa ou ao finalizar uma fase de implementação
 user-invokable: false
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-eval

package/framework/skills/core/morph-hotfix/SKILL.md

@@ -4,7 +4,7 @@ description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de prod
 version: core
 when-to-invoke: ao receber "/morph-hotfix {feature}", quando a morph-proposal classifica o pedido como workType hotfix (Passo 0), ou o usuário diz "produção caiu / hotfix / urgente"
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-hotfix
@@ -56,7 +56,7 @@ Escreva o brief curto (~20 linhas) reutilizando o nome canônico `proposal.md`:
 
 ### 4. Plano mínimo (`2-plan/tasks.json`)
 
-Escreva um `tasks.json` mínimo validado contra `framework/schemas/tasks.schema.json`:
+Escreva um `tasks.json` mínimo validado contra `.morph/framework/schemas/tasks.schema.json`:
 
 - `T1` — o fix.
 - `T2` — verify/regressão do blast radius.
@@ -81,7 +81,7 @@ Use `--skip-tests`/`--skip-build` quando fizer sentido para velocidade (ex.: ite
 
 ### 7. Gate 3 — SEMPRE humano
 
-O hotfix tem `forcedPauseGates: ['review']` (`src/core/work-types.js`) — o Gate 3 pausa **sempre**, mesmo em `trust: auto`. `gate-check` já sabe disso: lê `workType` do disco e `shouldPauseGate` força a pausa antes de checar qualquer outro sinal — rode direto, sem `--signals`:
+O hotfix nasce com o Gate 3 em `forcedPauseGates` — o Gate 3 pausa **sempre**, mesmo em `trust: auto`. `gate-check` já sabe disso: lê `workType` do disco e `shouldPauseGate` força a pausa antes de checar qualquer outro sinal — rode direto, sem `--signals`:
 
 ```
 morph-spec gate-check {feature} review [--json]
@@ -98,7 +98,7 @@ options:
   - { label: "rollback", description: "Desfazer o fix — voltar ao estado anterior" }
 ```
 
-**NUNCA `morph-spec approve {feature} review --mode auto`** — o CLI recusa explicitamente essa combinação (`src/commands/state/approve.js`: `gateName === 'review' && feature.workType === 'hotfix' && approvedBy === 'auto'` é bloqueado) porque `forcedPauseGates` sobrepõe qualquer trust mode. Em contexto headless (sem `AskUserQuestion` disponível), **o `state-sync` NÃO cobre este caso**: ele é um hook `PostToolUse` com matcher `Write|Edit|AskUserQuestion`, e uma resposta em texto puro do usuário não é tool call — não gera evento e não grava gate nenhum. Esperar por ele deixa o Gate 3 por aprovar em silêncio. O caminho é registrar a aprovação humana explicitamente:
+**NUNCA `morph-spec approve {feature} review --mode auto`** — o CLI recusa explicitamente essa combinação (gate `review` + `workType: hotfix` + aprovador `auto`) porque `forcedPauseGates` sobrepõe qualquer trust mode. Em contexto headless (sem `AskUserQuestion` disponível), **o `state-sync` NÃO cobre este caso**: ele é um hook `PostToolUse` com matcher `Write|Edit|AskUserQuestion`, e uma resposta em texto puro do usuário não é tool call — não gera evento e não grava gate nenhum. Esperar por ele deixa o Gate 3 por aprovar em silêncio. O caminho é registrar a aprovação humana explicitamente:
 
 ```
 morph-spec approve {feature} review --approver "<nome de quem aprovou>"
@@ -132,9 +132,9 @@ morph-spec approve {feature} review --approver "<nome de quem aprovou>"
 - `.morph/framework/MORPH.md` §2.1 — roteamento por tipo de trabalho
 - `.morph/framework/MORPH.md` §5 — Gates de aprovação, gate humano forçado no hotfix
 - `.morph/framework/MORPH.md` §6 — Sub-agents, persona de estágio scout, protocolo obrigatório
-- `framework/skills/core/morph-proposal/SKILL.md` — Passo 0, roteamento que invoca esta skill
-- `framework/skills/core/morph-implement/SKILL.md` §4 — template de dispatch e protocolo
-- `src/core/work-types.js` — `scaffold`/`skippedGates`/`forcedPauseGates` do tipo `hotfix`
+- `.claude/skills/morph-proposal/SKILL.md` — Passo 0, roteamento que invoca esta skill
+- `.claude/skills/morph-implement/SKILL.md` §4 — template de dispatch e protocolo
+- `morph-spec create {feature} --type hotfix --json` — mostra a política do tipo (`scaffold`, `skippedGates`, `forcedPauseGates`) como o CLI a aplicou
 - `morph-spec create {feature} --type hotfix` — nascimento com política de gates
 - `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores
 - `morph-spec gate-check {feature} review [--json]` — persiste a decisão de pausa (forçada por `workType: hotfix`) antes do Gate 3

package/framework/skills/core/morph-implement/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-implement
@@ -31,9 +31,9 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    **Se a `morph-apply` passou `feedback` de uma tentativa anterior** (loop de correção — a task foi implementada mas o `morph-eval` deu score < 9): isto NÃO é uma implementação do zero. Leia o feedback priorizado, identifique os pontos bloqueantes listados, e **corrija especificamente esses pontos** no código já existente. Não reescreva o que já passou; foque no que o eval apontou. Registre no recap qual feedback foi endereçado em qual tentativa.
 
 2. Identifique o standard mais relevante para a tarefa atual:
-   - Rode `morph-spec standards --find "<domínio/tecnologia da task>"` (filtros opcionais `--category`, `--tags`, `--json`) — o comando busca em `framework/standards/STANDARDS.json` e devolve o top 3 candidatos como `id · path · digest`, sem você abrir o index inteiro.
+   - Rode `morph-spec standards --find "<domínio/tecnologia da task>"` (filtros opcionais `--category`, `--tags`, `--json`) — o comando busca em `.morph/framework/standards/STANDARDS.json` e devolve o top 3 candidatos como `id · path · digest`, sem você abrir o index inteiro.
    - **O digest decide a escolha.** Escolha 1-3 standards pelo `digest` retornado. Depois, **use a tool Read APENAS no(s) arquivo(s) `.md` escolhido(s)** (campo `path` do resultado) — o digest te diz qual candidato é o certo; o arquivo escolhido se lê inteiro, porque é onde vivem as convenções aplicáveis.
-   - **Tarefas de agente de IA (MAF):** Read os `framework/standards/ai-agents/*.md` relevantes para a task. Mesmo que você consulte docs externas (context7) para a superfície da API do `Microsoft.Agents.AI`, as **convenções de projeto** (single-agent por padrão, provider/caching/observability, A2A, middleware) vêm desses standards. Uma fonte externa não as conhece.
+   - **Tarefas de agente de IA (MAF):** Read os `.morph/framework/standards/ai-agents/*.md` relevantes para a task. Mesmo que você consulte docs externas (context7) para a superfície da API do `Microsoft.Agents.AI`, as **convenções de projeto** (single-agent por padrão, provider/caching/observability, A2A, middleware) vêm desses standards. Uma fonte externa não as conhece.
    - Se nenhum standard cobrir o caso, registre no decisions.md e adote o critério mais conservador.
 
 3. Identifique a persona de agente adequada para a tarefa:
@@ -115,13 +115,28 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 
    Regras:
    - **Standard é obrigatório** — sempre referenciar pelo menos um standard de
-     `framework/standards/STANDARDS.json` que justificou as escolhas de implementação.
+     `.morph/framework/standards/STANDARDS.json` que justificou as escolhas de implementação.
      Se nenhum standard existente cobre, registre a decisão em `decisions.md` E cite
      `Standard: ad-hoc (see decisions.md ADR-{N})` no recap.
    - Sem standard ⇒ a task falha no validador de Gate 3 (`validate-completion`)
      e o reviewer não consegue auditar de onde veio a decisão técnica.
 
-7. Atualizar `tasks.json` marcando a task como `done` — **direto com a tool `Edit` (ou `Write`)**, sem scripts:
+7. **Antes de marcar a task como `done`, audite o relatório contra o trabalho:**
+
+   ```
+   morph-spec report-check {feature} {taskId} --json
+   ```
+
+   Não é burocracia — é a única checagem que não depende da palavra do agente. Veredito
+   `report-stale` significa **relatório completo e VELHO**: a task seguiu escrevendo arquivos depois
+   que ele foi gravado, então o texto descreve um estado já ultrapassado. Aconteceu de verdade: o
+   sub-agent gravou o esqueleto dizendo "teste ainda não escrito — em andamento", escreveu os 9
+   testes, e foi cortado antes de atualizar. Quem leu o relatório quase marcou a task como
+   incompleta e re-despachou trabalho pronto. **Nesse caso não re-despache**: leia `observed`
+   (arquivos realmente escritos, do `events.jsonl`, não auto-declarados) e atualize o relatório a
+   partir dessa evidência. Demais vereditos: tabela em `MORPH.md` §6.
+
+8. Atualizar `tasks.json` marcando a task como `done` — **direto com a tool `Edit` (ou `Write`)**, sem scripts:
 
    - Mude apenas os campos mutáveis da task: `status` (enum válido: `pending`,
      `in_progress`, `done`, `skipped`, `blocked` — nunca invente valores como
@@ -154,7 +169,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    > tasks.json + recap.md + `taskScores` do feature.json. **NÃO escreva o trace
    > manualmente** — a escrita manual foi removida da cerimônia por task.
 
-8. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
+9. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
 
 ## Output esperado
 - Código implementado conforme o standard consultado (direto ou via sub-agent)

package/framework/skills/core/morph-plan/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a produção dos artefatos de planejamento de uma feature (use
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-plan
@@ -89,7 +89,7 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    - Standards obrigatórios: descubra-os com `morph-spec standards --find "<domínio/tecnologia>"` (top 3 `id · path · digest` — o digest decide) por domínio tocado; liste os IDs escolhidos.
    - Patterns proibidos — **copie por extenso no mandate.md** a lista canônica de `MORPH.md` § "Stack baked-in" (`Guid.NewGuid()`→`Guid.CreateVersion7()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, repository genérico `IRepository<T>`/`IUnitOfWork`, SQL cru sem justificativa) mais qualquer proibição específica da feature. Copie o texto completo — o mandate.md é lido por implementadores em contexto fresco, sem `MORPH.md` carregado, então um ponteiro sozinho não basta aqui.
    - Política de acesso a dados (registre no mandate): `ApplicationDbContext` injetado direto no slice — para CRUD e para queries específicas (joins, projeção, paginação). Para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
-   - **Features com agentes de IA (MAF):** se a feature envolve um agente (Microsoft Agent Framework), **use a tool Read** nos standards relevantes de `framework/standards/ai-agents/*.md` (ex.: `setup`, `agent-session`, `middleware-patterns`, `mcp-server`, `mcp-tools`, `multi-agent-patterns`, `production`) — filtre pelo que a feature exige via `morph-spec standards --find "<tema>" --category ai-agents`. Esses standards carregam as **convenções de projeto** (single-agent por padrão — Workflows só para fan-in/out real; provider, caching, observability, A2A) que uma fonte externa de docs (ex.: context7) não conhece. Padrão de divisão: **superfície da API** pode vir de docs ao vivo/context7 (mais frescas para um SDK em evolução), mas **as convenções vêm dos standards** — registre ambas no mandate. Não pule os `ai-agents/*.md` só porque o STANDARDS.json index lista que eles existem.
+   - **Features com agentes de IA (MAF):** se a feature envolve um agente (Microsoft Agent Framework), **use a tool Read** nos standards relevantes de `.morph/framework/standards/ai-agents/*.md` (ex.: `setup`, `agent-session`, `middleware-patterns`, `mcp-server`, `mcp-tools`, `multi-agent-patterns`, `production`) — filtre pelo que a feature exige via `morph-spec standards --find "<tema>" --category ai-agents`. Esses standards carregam as **convenções de projeto** (single-agent por padrão — Workflows só para fan-in/out real; provider, caching, observability, A2A) que uma fonte externa de docs (ex.: context7) não conhece. Padrão de divisão: **superfície da API** pode vir de docs ao vivo/context7 (mais frescas para um SDK em evolução), mas **as convenções vêm dos standards** — registre ambas no mandate. Não pule os `ai-agents/*.md` só porque o STANDARDS.json index lista que eles existem.
    - **Verificação de runtime** — como se PROVA que a feature funciona rodando, não só compilando.
      Compilar não é subir: um serviço injetado sem registro em `Program.cs` passa no build e derruba
      a aplicação no startup. Registre no mandate:
@@ -112,6 +112,18 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
        verificação de runtime vira teatro. É gap de Gate 2, não dispensa de Gate 3.
      - **Quando não se aplica** (biblioteca pura, chore sem runtime), registre a dispensa e o porquê.
    - Checklist de done com critérios verificáveis por tarefa.
+   - **Baseline é um COMANDO, nunca um número.** O mandate congela no Gate 2 e é lido por
+     implementadores durante dias — todo número cravado nele (`Suíte: 2366 passando`, cobertura,
+     contagem de arquivos) está errado a partir da primeira task, e um agente que confia nele
+     "conserta" um baseline que nunca esteve quebrado. Registre **como medir** (`npm test`,
+     `dotnet test`) e mande comparar com o resultado do momento, não com um valor histórico.
+     Aconteceu de verdade: mandate afirmando 2366 quando já eram 2375, e um ADR escrito só para
+     desmentir o próprio mandate.
+   - **Pré-requisito é um PREDICADO, nunca um SHA literal.** "`git merge-base --is-ancestor
+     origin/main HEAD` sai 0" ou "a branch da feature X está integrada" — não "confirme que
+     origin/master contém `49dfba2`". SHA cravado envelhece na primeira rebase/squash: o merge sai
+     com outro hash e o sub-agent mandado verificá-lo ou queima turnos procurando o que não existe,
+     ou declara que verificou sem ter verificado.
 
 5. Produza `tasks.json` em `.morph/features/{feature}/2-plan/` seguindo o schema em `.morph/framework/schemas/tasks.schema.json`.
 
@@ -149,7 +161,7 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    - `outputs` (opcional): array de paths que serão criados/modificados.
    - `usecase` (opcional): o **ID** do use case que a task realiza — `UC-07`, nunca o nome do arquivo. Task puramente técnica (build, config, migração) não tem.
    - `agent` (opcional): o `id` da persona de `agents.json` responsável pelo domínio da task — **sem** o prefixo `morph-` (ex.: `"dotnet-senior"`, não `"morph-dotnet-senior"`). Carimbado no passo 5a abaixo; ausente numa task sem domínio de agente claro (config/docs) ou num plano legado.
-   - `standards` (opcional): array de paths relativos de `framework/standards/` (ex.: `["standards/backend/dotnet/vsa-handler-patterns.md"]`) — os standards da persona resolvida em `agent`, mais qualquer standard específico que a task exija.
+   - `standards` (opcional): array de paths relativos de `.morph/framework/standards/` (ex.: `["standards/backend/dotnet/vsa-handler-patterns.md"]`) — os standards da persona resolvida em `agent`, mais qualquer standard específico que a task exija.
 
    **5a. Carimbe `agent` e `standards` — uma leitura de `agents.json`, N tasks.** Antes de fechar o array `tasks`, **use a tool Read UMA VEZ** em `.morph/framework/agents.json` (não releia por task — é essa releitura repetida por task, hoje feita em `morph-implement`/`morph-apply` a cada dispatch, que este passo existe para eliminar). Para cada task do plano, resolva:
    - `agent`: o `id` da persona (chave do objeto `agents`, sem prefixo `morph-`) cujo `domains` cobre o `group`/domínio da task — o mesmo casamento que `morph-implement` §3 e `morph-apply` §3b fariam manualmente a cada dispatch; aqui você faz uma vez, no plano.

package/framework/skills/core/morph-proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-proposal
@@ -59,7 +59,7 @@ morph-spec create {feature-name} --request "<pedido do usuário>"
 
 ### 2. Invocar `Skill(morph-brainstorming)`
 
-Passa o nome da feature. A skill é a **dona da fase de entendimento** — não re-descreva o comportamento dela aqui. Em resumo: varre o ambiente antes de perguntar qualquer coisa (`Skill(morph-stack-scan)` + contexto do projeto + acervo de use cases), monta a **árvore de decisões abertas**, abre com a escolha de **modo de descoberta** (entrevista ou automático — só `feature` e `bug`), detecta divergência entre fontes de design-system (`signals.designSystemDivergence`) e produz `proposal.md` em `.morph/features/{feature}/0-proposal/`. Detalhes em `framework/skills/core/morph-brainstorming/SKILL.md`.
+Passa o nome da feature. A skill é a **dona da fase de entendimento** — não re-descreva o comportamento dela aqui. Em resumo: varre o ambiente antes de perguntar qualquer coisa (`Skill(morph-stack-scan)` + contexto do projeto + acervo de use cases), monta a **árvore de decisões abertas**, abre com a escolha de **modo de descoberta** (entrevista ou automático — só `feature` e `bug`), detecta divergência entre fontes de design-system (`signals.designSystemDivergence`) e produz `proposal.md` em `.morph/features/{feature}/0-proposal/`. Detalhes em `.claude/skills/morph-brainstorming/SKILL.md`.
 
 No **modo entrevista** o Gate 1 pausa sempre — a confirmação do entendimento compartilhado é o gate. O modo escolhido chega ao passo 3 em `gateDecisions.proposal.signals.discoveryMode`.
 
@@ -114,7 +114,7 @@ Critério objetivo em `MORPH.md` §2.1: a mudança cria ou altera superfície de
 A skill lê `proposal.md` e produz:
 - `spec.md` — especificação técnica detalhada
 - `mandate.md` — contrato de implementação (stack defaults + padrões proibidos)
-- `tasks.json` — task breakdown estruturado validado contra `framework/schemas/tasks.schema.json`
+- `tasks.json` — task breakdown estruturado validado contra `.morph/framework/schemas/tasks.schema.json`
 - `decisions.md` — apenas se houver decisões não triviais
 
 ### 6. Gate 2 (trust-aware)
@@ -146,8 +146,8 @@ Mesma mecânica do passo 3: a decisão já foi tomada e persistida pela `morph-p
 
 - `.morph/framework/MORPH.md` — charter NLH completo
 - `.morph/framework/MORPH.md` §2.1 — roteamento por tipo de trabalho (Passo 0)
-- `framework/skills/core/morph-brainstorming/SKILL.md`
-- `framework/skills/core/morph-uiux/SKILL.md` — invocada no passo 3a quando a feature toma o ramo uiux
-- `framework/skills/core/morph-plan/SKILL.md`
-- `framework/skills/core/morph-hotfix/SKILL.md` — pipeline invocado pelo branch `hotfix` do Passo 0
+- `.claude/skills/morph-brainstorming/SKILL.md`
+- `.claude/skills/morph-uiux/SKILL.md` — invocada no passo 3a quando a feature toma o ramo uiux
+- `.claude/skills/morph-plan/SKILL.md`
+- `.claude/skills/morph-hotfix/SKILL.md` — pipeline invocado pelo branch `hotfix` do Passo 0
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

package/framework/skills/core/morph-review/SKILL.md

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-review
@@ -34,7 +34,7 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
    - Se parcialmente atendido: registre como "pendência" com o que falta.
 
    **Verificações mecânicas sempre-rodar** (independente do mandate mencionar ou não — cobrem bugs
-   reais já vistos em produção, ver `framework/evals/rubrics/architecture.md` → "Verificações
+   reais já vistos em produção, ver `.morph/framework/evals/rubrics/architecture.md` → "Verificações
    mecânicas obrigatórias"), quando o diff tocar endpoints minimal API ou fetch cross-camada:
    - Todo serviço injetado numa lambda de endpoint tem `AddScoped`/`AddSingleton`/`AddTransient`
      correspondente em `Program.cs`. Falha aqui é bloqueante — a app não sobe.
@@ -104,6 +104,13 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
          reportar, não defeito de implementação a pontuar.
          NÃO reescreva código. NÃO toque em tasks.json, feature.json nem no board
          de sessão — Bash é só para verificação, nunca para mudar estado.
+         Se o que você avalia é uma CORREÇÃO (rodada do loop, fix de achado
+         anterior), responda no relatório: O QUE ESTA CORREÇÃO ABRIU? Que
+         comportamento antes correto pode ter regredido, e há teste que
+         pegaria? Um fix que fecha um defeito e abre outro pontua alto em toda
+         dimensão e ainda assim piorou o produto — e essa pergunta é a única
+         que o score não faz sozinho. Não aceite "agora tem teste" como
+         fechamento: RE-EXECUTE os probes da rodada anterior.
          Contrato do relatório final: GRAVE seu relatório em
          `.morph/features/{feature}/4-review/evaluator-report.md` ANTES de
          encerrar — esse arquivo é o valor de retorno autoritativo desta
@@ -202,7 +209,7 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
 - `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores+e2e anexada ao prompt do avaliador (passo 4)
 - `.morph/framework/MORPH.md` — seção 5 (Gate 3 + regras de pausa), seção 1 (papel Evaluator), Trust Mode
 - `.claude/agents/morph-evaluator.md` — subagent do avaliador (gerado de `.morph/framework/agents.json`), despachado no passo 4
-- `framework/skills/core/morph-eval/SKILL.md` — rubricas e bandas que o avaliador aplica
+- `.claude/skills/morph-eval/SKILL.md` — rubricas e bandas que o avaliador aplica
 - `.morph/framework/evals/trace-schema.md` — formato canônico do trace
 - `.morph/features/{feature}/2-plan/mandate.md` — critérios de done da feature
 - `.morph/features/{feature}/2-plan/spec.md` — arquitetura e contratos

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-stack-scan
@@ -129,5 +129,5 @@ Antes de despachar Explore, verifique se o projeto é greenfield:
 - Decisão documentada: incluir migração nesta feature ou separar (registrada no proposal.md pela morph-brainstorming)
 
 ## Referências
-- `framework/MORPH.md` — seção 4 (Standards), seção 2 (Fases)
-- `framework/skills/core/morph-brainstorming/SKILL.md` — fluxo greenfield/brownfield
+- `.morph/framework/MORPH.md` — seção 4 (Standards), seção 2 (Fases)
+- `.claude/skills/morph-brainstorming/SKILL.md` — fluxo greenfield/brownfield

package/framework/skills/core/morph-standards/SKILL.md

@@ -4,7 +4,7 @@ description: Localiza um standard específico via busca server-side (morph-spec
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-standards
@@ -45,7 +45,7 @@ pra categoria X?", sem um termo de busca claro), nesta ordem:
 
 1. `morph-spec standards` sem `--find` — lista categorias + contagem, custo mínimo, o suficiente
    pra decidir qual `--category` usar num `--find` em seguida.
-2. Só se isso não bastar, abra `framework/standards/STANDARDS.json` inteiro — último recurso,
+2. Só se isso não bastar, abra `.morph/framework/standards/STANDARDS.json` inteiro — último recurso,
    nunca o primeiro passo.
 
 ## Quando não há standard adequado
@@ -60,5 +60,5 @@ Não invente um standard — padrões não documentados são dívida técnica.
 
 ## Referências
 - `morph-spec standards --find "<query>" [--category] [--tags] [--json]` — busca server-side, top 3 `id · path · digest`
-- `framework/standards/STANDARDS.json` — índice completo; abrir só como fallback exploratório (ver acima)
-- `framework/MORPH.md` — seção 4 (Como consultar Standards)
+- `.morph/framework/standards/STANDARDS.json` — índice completo; abrir só como fallback exploratório (ver acima)
+- `.morph/framework/MORPH.md` — seção 4 (Como consultar Standards)

package/framework/skills/core/morph-uiux/SKILL.md

@@ -4,7 +4,7 @@ description: Conduz a fase opcional de UI/UX — design system, mockups, compone
 version: core
 when-to-invoke: ao tomar o ramo uiux (morph-spec advance --design), depois do Gate 1 e antes do morph-plan
 user-invokable: true
-cliVersion: "8.25.0"
+cliVersion: "8.27.0"
 ---
 
 # morph-uiux
@@ -131,5 +131,5 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)
 - `.morph/framework/agents.json` — persona `ui-designer` (tools, MCPs, standards)
 - `.morph/framework/templates/context/design-system.md` — forma de partida quando o projeto não tem design system vivo
-- `framework/skills/core/morph-brainstorming/SKILL.md` — protocolo de reconciliação/changelog do design-system vivo (Parte 0), reaplicado no passo 4
-- `framework/skills/core/morph-plan/SKILL.md` — consome os artefatos desta fase por path
+- `.claude/skills/morph-brainstorming/SKILL.md` — protocolo de reconciliação/changelog do design-system vivo (Parte 0), reaplicado no passo 4
+- `.claude/skills/morph-plan/SKILL.md` — consome os artefatos desta fase por path