@polymorphism-tech/morph-spec 8.46.0 → 8.47.0

package/CLAUDE.md

@@ -48,7 +48,7 @@ No build step — pure ESM JavaScript, runs directly via Node.js 18+.
   - `templates/` — Handlebars template registry and renderer
   - `workflows/` — Workflow type detector
 - **`src/lib/`** — Libraries and subsystems:
-  - `validators/` — Data-driven validators (architecture, css, design-system, nextjs)
+  - `validators/` — Validators run by the `verify` validators node (code-budget, contracts, nextjs, packages, reuse)
   - `generators/` — Code generation (recap, context, handoff)
   - `stack-filter.js` — Stack-aware asset filtering via YAML frontmatter `stacks:` tags
   - `installers/` — Agents, skills, hooks installers
@@ -117,7 +117,7 @@ When modifying framework components, verify the full scope of related files.
 | When you modify...              | Also verify...                                                                            |
 |----------------------------------|-------------------------------------------------------------------------------------------|
 | `framework/agents.json`          | agents-installer.js (test/utils/agents-installer.test.js), doctor.js (REQUIRED_AGENTS). **`maxTurns` (ADR-004):** UMA régua de validade, `maxTurnsError` em `agents-installer.js`, com QUATRO leitores — `installAgents` (recusa antes de escrever), `checkAgentsDrift` (`invalid`), `validateAgentsJson` do `doctor` (error) e o Check 6 do `validate-framework.js` (`test/framework/validate-framework-agents.test.js`); uma segunda noção de "valor válido" faz o mesmo arquivo passar num e ser recusado no outro. Sem o campo, o frontmatter sai byte a byte igual ao de antes (canário COMPAT). O corpo gerado anuncia o teto ao sub-agent, e a cláusula 5 dos templates de dispatch depende disso. O drift lê o registry MCP do PACOTE (`mcpRegistryDir`): a cópia instalada não tem `mcp/`, e ler dela dava toda persona com `mcp` como stale numa instalação limpa. O marcador `PARCIAL` (1ª linha) que a cláusula 5 e o corpo da persona mandam gravar é lido por `report-check.js` (`PARTIAL_MARKER` → `report-incomplete`, ação `resume`): mudar a grafia num lado só devolve o parcial lido como `ok`. **`effort`:** mesma régua única em quatro leitores (`effortError`); ausente, o frontmatter não ganha linha e o sub-agent herda o effort da sessão (COMPAT intacto). Implementadores e `scout` `medium`, `evaluator` sem o campo — o Gate 3 não é barateado. **`surfaces` (ADR-005):** mesma régua única em quatro leitores (`surfacesError`), e `personaStandardIds` é a leitura única de "todo standard da persona" para o Check 1, o drift e os scanners do dashboard (`agents-scanner.js`, `standards-scanner.js`) — iterar só `standards` deixa id de superfície sem validar e a aresta do grafo sumida. Sem o campo, o `.md` sai byte a byte o de antes: `test/fixtures/agents/ui-designer-5.3.0.{json,md}` é a persona do 5.3.0 e o render do installer de main, comparados com `strictEqual` — nunca regere a fixture para fazer o teste passar. A chave da superfície é a que o checklist de tela do `morph-uiux` escreve em `Superfície` e que o `morph-plan` §5a usa para somar a lista em `tasks[].standards` |
-| `framework/standards/**`         | STANDARDS.json entry exists (o **digest** e o que `standards --find` devolve — corrigir a prosa e esquecer o digest e o caso mais comum), agents reference standard, .md file exists. **Bloco de codigo `csharp` num standard e afirmacao verificavel:** extraia com `node scripts/extract-doc-csharp.mjs <std.md> "## Secao" out.cs` e compile numa sonda com o pin + `TreatWarningsAsErrors` (sem ele `MEAI001` vira aviso e o build fica verde sobre codigo que o consumidor nao compila). Medido: um exemplo carimbado sem compilar tinha 3 erros independentes |
+| `framework/standards/**`         | STANDARDS.json entry exists (o **digest** e o que `standards --find` devolve — corrigir a prosa e esquecer o digest e o caso mais comum), e o bullet do standard na rule `framework/rules/*-standards.md` que o roteia (resumo inline; `@`-import em rule resolve relativo ao arquivo da rule e, quando resolve, carrega em TODA sessão ignorando `paths:` — medido; canário `test/framework/rules-no-imports.test.js`), agents reference standard, .md file exists. **Bloco de codigo `csharp` num standard e afirmacao verificavel:** extraia com `node scripts/extract-doc-csharp.mjs <std.md> "## Secao" out.cs` e compile numa sonda com o pin + `TreatWarningsAsErrors` (sem ele `MEAI001` vira aviso e o build fica verde sobre codigo que o consumidor nao compila). Medido: um exemplo carimbado sem compilar tinha 3 erros independentes |
 | `isImplementer` (Check 6 de `scripts/validate-framework.js`) | toda persona com Write/Edit no escopo efetivo de tools tem de alcançar, pelos `standards`, as âncoras `comment-policy` e `test-budget` do STANDARDS.json (`IMPLEMENTER_ANCHORS`). Renomear a chave da âncora no registry derruba o `validate`, e persona implementadora nova sem os dois standards também. Installer e `doctor` não cobram isso de propósito: um `agents.json` instalado antigo continua valendo |
 | `scripts/generate-standards-registry.js` | `framework/standards/STANDARDS.json` (REGENERE, nunca patch textual — tres features escrevem no mesmo arquivo), `src/lib/standards/verified-against.js` (`parseVerifiedAgainst`/`deriveProvedBy`: `verifiedAgainst` e `provedBy` sao DERIVADOS a cada run e NAO entram em `PRESERVE_FIELDS`), `test/framework/standards-registry.test.js`. **Renomear um standard e uma PARADA, nao um exit 0**: path sumido + path novo faz o gerador recusar nomeando os dois conjuntos e prescrevendo a edicao do campo `path` da entrada antiga — ele nao adivinha o par. `MORPH_STANDARDS_BASE` e o unico seam de teste do script e nada em producao o define |
 | `framework/hooks/claude-code/**` | hooks-installer.js MORPH_HOOKS array, hook follows fail-open pattern. O `timeout` de cada entrada é em SEGUNDOS, a unidade que o Claude Code lê — em milissegundos ele passa do default de 600 e prende a sessão por horas (canário em `test/hooks/hooks-installer.test.js`); binding `async: true` não tem timeout aplicado |
@@ -162,8 +162,8 @@ When modifying framework components, verify the full scope of related files.
 | `framework/hooks/shared/graph-freshness.js` (a regra única de "grafo em dia") | os três lados que perguntam: `graph-refresh.js` (decide se roda e se o disparo solta processo), `graph-loader.js` `getFreshness` (`graph status\|explain\|affected` e o `doctor`) e `graph build\|refresh` (gravam a rodada em `<git-common-dir>/morph-spec/graph-refresh-state.json`). O registro da rodada existe porque o `graphify update` 0.9.50 não recarimba `built_at_commit` quando a topologia não muda: sem ele, o grafo parecia velho para sempre e cada disparo rodava o graphify de novo (~80 s no MORPH_GHLBrain). As regras do `.graphifyignore` entram por CONTEÚDO (hash sem comentário, BOM e CRLF), nunca pelo relógio, e `ignoreTextOf` é a ÚNICA leitura de "as regras desta árvore": numa worktree sem arquivo próprio, as da raiz — as mesmas que o `graph refresh` põe ali durante a rodada (`prepareIgnore` em `build.js`). O arquivo temporário leva `TEMP_IGNORE_MARKER` na 1ª linha; nas duas triagens de sujeira (`finish` e `worktree remove`) `withoutLeftoverIgnore` o tira da conta ANTES das recusas e `dropLeftoverIgnore` o apaga só DEPOIS delas — apagar antes é mutação atrás de uma precondição. Mudar a grafia do marcador num lado só devolve o `worktree-dirty` de uma rodada morta no meio. Mora em `hooks/shared` porque hook não importa `src/` |
 | `framework/hooks/shared/graph-refresh.js` (o refresh em background) | os dois disparos (`graph-refresh-kick`, depois de Bash/PowerShell com `git`/`gh`/`morph-spec`, e o SessionStart de `worktree-context.js`), `graph build\|refresh` (o MESMO lock por repositório) e `worktree.js` (`seedGraphFromRoot`: a worktree nasce com o grafo da raiz e o registro dela — em dia no HEAD só se a raiz estava). **Só a raiz**: o worker destacado nasce com `cwd` no git common dir e nunca recebe o caminho de uma worktree — no win32 um diretório em uso não se apaga, e o `finish` de uma worktree com refresh correndo falhava no meio. A worktree anda por `morph-spec graph refresh`, em primeiro plano. `runGraphify` roda o graphify com `cwd` no git common dir, nunca na árvore (ele lê o alvo, o ignore e o git pelo argumento — medido no 0.9.50). O disparo lê o HEAD pelo disco (`readPrimaryHead`, `git-paths.js`) e não solta processo quando o grafo não pede refresh: ele roda a cada comando git do agente. O step 18b de `setup-infra.js` não instala o hook git do graphify: ele não roda em worktree, não tem `post-merge` e carimba como em dia um grafo sem os arquivos do merge |
 | `framework/hooks/shared/git-exclude.js` | ÚNICO escritor dos blocos do morph-spec no `info/exclude` do COMMON dir — o `.git/worktrees/<id>/info/exclude` o git não lê para worktree vinculada. Leitores que passam o seu marcador: `worktree.js`, `handoff-generator.js` e `graph-refresh.js`. Resolve o common dir pelo disco, sem subprocesso: um `git` gerado por um processo destacado abria janela de console no win32 |
-| `src/lib/validators/reuse/**`     | `validation-runner.js` (case + push universal), `framework/rubrics/*.json` (o id `reuse` mapeado numa categoria, senão o achado não pesa no score), `test/fixtures/graph/prospectpro-reuse.graph.json` (recorte do grafo real — regerar com `build-reuse-fixture.mjs`, nunca editar à mão) |
-| `src/lib/validators/code-budget/**` | `validation-runner.js` (case + push universal fora do `light`), `framework/rubrics/*.json` (o id `code-budget` em `code_quality` nas TRÊS, senão o aviso não pesa), `framework/docs/CLI.md` (o que conta como teste e os limites 1,5×/40 linhas) e `test/integration/code-budget-verify.test.js`. Lê `addedLinesAgainst` (`default-branch.js`), `isTestFile` (`symbol-scanner.js`, a mesma régua de teste do `reuse`), `isProjectSource`/`isGenerated` (`hooks/shared/source-files.js`) e `commentLines`/`citesProcess` (`hooks/shared/comment-scanner.js`, sobre `stripComments` com `js`). Sempre `warning`. Não conseguir medir é skip `unavailable` com razão, e o `validation-runner` não põe validador pulado em `results`: pulado não conta como verde |
+| `src/lib/validators/reuse/**`     | `validation-runner.js` (case + push universal), `test/fixtures/graph/prospectpro-reuse.graph.json` (recorte do grafo real — regerar com `build-reuse-fixture.mjs`, nunca editar à mão) |
+| `src/lib/validators/code-budget/**` | `validation-runner.js` (case + push universal fora do `light`), `framework/docs/CLI.md` (o que conta como teste e os limites 1,5×/40 linhas) e `test/integration/code-budget-verify.test.js`. Lê `addedLinesAgainst` (`default-branch.js`), `isTestFile` (`symbol-scanner.js`, a mesma régua de teste do `reuse`), `isProjectSource`/`isGenerated` (`hooks/shared/source-files.js`) e `commentLines`/`citesProcess` (`hooks/shared/comment-scanner.js`, sobre `stripComments` com `js`). Sempre `warning`. Não conseguir medir é skip `unavailable` com razão, e o `validation-runner` não põe validador pulado em `results`: pulado não conta como verde |
 | `framework/hooks/shared/comment-rules.js` / `comment-scanner.js` / `source-files.js` (o hook `comment-guard`) | Os dois leitores do MESMO comentário: o hook `comment-guard` (PostToolUse `Write\|Edit`, bloqueia na hora da edição) e o `code-budget` (avisa no `verify`). Moram em `hooks/shared` porque hook não importa `src/`; o `src/` importa daqui, nunca uma cópia. O hook julga só o comentário ADICIONADO (`tool_response.originalFile`, medido: `null` no Write que cria) e só FORMA — processo, banner/`#region`, bloco > 3 linhas, doc-comment fora de pacote publicado —, nunca "repete o código". É o ÚLTIMO elo da chain `Write\|Edit` (um block encerra a chain; canário em `test/hooks/hooks-installer.test.js`). Marcador que template precisa manter (`READS STANDARD(S):`, `VERIFY:`) entra em `ALLOWED`; o canário de template em `test/hooks/comment-rules.test.js` reprova template que dispararia o hook no scaffold |
 | o ciclo de reuso (`tasks[].reuse`) | `framework/schemas/tasks.schema.json` + `tasks-json-parser.js` (campo `reuse`, com `why` no CRIAR — o parser só checa tipo, para não travar a escrita de status de plano antigo), `morph-plan` §1c/§5b, template de dispatch de `morph-implement`/`morph-apply`, personas de `agents.json`, o validador `reuse` (`src/lib/validators/reuse/`) e `test/framework/graph-fallback.test.js` |
 | `framework/mcp/registry.json`    | mcp-installer.js, claude-config-detector.js, agents-installer.js (personas' `mcp` field), `scripts/validate-framework.js` Check 8, `test/framework/mcp-registry.test.js` |
@@ -180,7 +180,7 @@ When modifying framework components, verify the full scope of related files.
 | `src/lib/tasks/test-nodes.js` | os DOIS leitores de `validateTestNodes` — `verify-runner.js` (fail-closed: nó inválido avermelha o gate) e `doctor.js` (`doctor --full`, camada 3 do contrato do spec §2.2: WARN, e **pula sem imprimir nada** sem `config.json` ou sem `project.tests`, senão quebra `test/commands/doctor.test.js:46`). Uma segunda noção de "nó válido" faz o mesmo config passar num lugar e falhar no outro. `morphConfigPath` deriva de `CONFIG_FILE_NAME` (`core/state/state-manager.js`), a mesma constante de `readMorphConfig` — o JSDoc promete "one spelling" e agora é literal. O campo `groups` (#87): `TASK_GROUPS` é o MESMO enum do `group` de `tasks.schema.json` e de `config.schema.json` (canário em `test/lib/tasks/test-nodes.test.js`), `RUNNER_DEFAULT_GROUPS` dá o default por runner e `effectiveGroups` é o que `test-scope.js` lê — `null` é nó sem grupo, nunca palpite. `discoverFrontendPackages` (a união do fallback de `resolveTestNodes` e o WARN do `doctor --full`) varre as pastas de `PACKAGE_LOCATIONS`, de `src/lib/detectors/index.js` — uma segunda lista de pastas é como dois detectores começam a discordar |
 | `src/lib/worktree/docker-audit.js` | `worktree-audit.js` (`auditWorktrees` concatena os achados e é quem PASSA as features conhecidas — um segundo scan aqui discordaria sobre o que é órfão), `doctor.js` (a classificação `info`/`warn` = não-falha em `doctorWorktreesCommand`; e `samePathCase`, a regra de caixa de path que o WARN de frontend do `doctor --full` e o `spelled` de `test-scope.js` reusam — uma segunda cópia dela foi removida), `env-allocator.js` (`allocatedFeatures` é read-only de propósito: `allocateEnvBlock` ESCREVE, e uma auditoria que aloca inventa o estado que reporta), `test/lib/worktree/docker-audit.test.js`. Nunca no `doctor --full` (D10): `test/commands/doctor.test.js:46` exige zero `✗` neste repo |
 | `src/lib/risk-detector.js` | os DOIS lados da mesma decisão de gate: `gate-check.js` (`collectSignals` COLETA do disco; nenhum sinal que descreva um FATO pode entrar em `OVERRIDABLE_SIGNAL_KEYS` — `gate`/`workType`/`e2e*` são o precedente), `src/commands/validation/verify.js` (o stamp `verification` é a ÚNICA coisa que o gate lê: campo novo aqui só vira sinal se o stamp o gravar), `framework/schemas/feature.schema.json` (`verification` é `additionalProperties: false`), `framework/MORPH.md` §5 (tabela de sinais — ela se declara fonte única) e `framework/docs/CLI.md`. Política escrita no coletor cria duas fontes para o mesmo fato — foi assim que `gate-check` e `approve` divergiram uma vez sobre o Gate 3. O veredito do avaliador é lido por UM leitor (`evaluatorReportState`, `src/lib/evaluator-report.js`) e decidido por UMA regra (`verdictPause`): `approve` exige `status: ok`, `gate-check` pausa em `FIX`, bloqueador aberto ou sem tipo. **`verificationScope` é sinal, não auditoria**: a dispensa de e2e (`project`/`scope`) só conta vinda de um stamp de escopo `feature` — um `verify {f} {task}` de task `group: docs` carimba a razão de dispensa e compraria o Gate 3 da feature inteira. **E o escopo de task pausa o ship por si só** (#87): no `review`, `verificationScope` string ≠ `'feature'` pausa ANTES do bloco de e2e, mesmo com todos os nós verdes — o recorte automático faz TODO `verify {f} {task}` rodar menos que a suíte; `null` (stamp legado) não pausa por esta regra. O par mora em `verify.js`: `--filter` de escopo de feature não persiste o stamp (`reason: 'filtered'`), nem `--skip-tests`/`--skip-build` (`'skip-tests'`/`'skip-build'`, #113 — nó pulado não reprova o rollup e nenhuma regra do gate lê `tests`/`build` pulados; a lista é `PARTIAL_RUN_FLAGS`) |
-| `src/lib/installers/effects.js` | os NOVE pontos de emissão que atravessam o caminho de `update`: `update.js` (clean, payloads, spawn de `generate-refs.js`, `gitIndex`), `skills-installer.js`, `agents-installer.js`, `setup-infra.js` (`installRulesForStack`, `updateClaudeMdAgentsBlock`), `hooks-installer.js` (`installClaudeHooks`, `installGlobalStatusline`), `file-copier.js` (`updateGitignore`, `ensureGitattributes`), `claude-md-injector.js`, `version-checker.js` (`saveProjectMorphVersion`) e `templates-reconcile.js`. **O caminho real também emite** — o resumo de uma execução real sai de `list()`, e é por isso que um ponto de emissão esquecido some das DUAS saídas ao mesmo tempo. Canários: `test/lib/installers/effects.test.js` (igualdade dry × real do MESMO roteiro) e `test/commands/update-dry-run.test.js` — que tem DOIS canários e precisa dos dois: **igualdade** prova que os dois lados percorrem o mesmo caminho, **diferencial** (mudar `--templates` muda a previsão) prova que o caminho lê a flag. Só igualdade aprova uma previsão e uma execução que ignoram a MESMA flag — foi medido nesta feature, por mutação. Um laço de limpeza de órfão novo tem de nascer calado em `fx.dryRun` (D6): o clean o subsome. E a lista de `frameworkDirsToClean` é pinada **à mão** no teste (`DIRETORIOS_APAGADOS_POR_INTEIRO`, dez caminhos, `deepEqual` ordenado): derivar a expectativa chamando a própria função deixou a suíte inteira cega — medido, dava para remover 2 das 10 entradas sem matar nenhum dos 207 arquivos de teste |
+| `src/lib/installers/effects.js` | os NOVE pontos de emissão que atravessam o caminho de `update`: `update.js` (clean, payloads, spawn de `generate-refs.js`, `gitIndex`), `skills-installer.js`, `agents-installer.js`, `setup-infra.js` (`installRulesForStack`, `installCommandsForStack`, `updateClaudeMdAgentsBlock`), `hooks-installer.js` (`installClaudeHooks`, `installGlobalStatusline`), `file-copier.js` (`updateGitignore`, `ensureGitattributes`), `claude-md-injector.js`, `version-checker.js` (`saveProjectMorphVersion`) e `templates-reconcile.js`. **O caminho real também emite** — o resumo de uma execução real sai de `list()`, e é por isso que um ponto de emissão esquecido some das DUAS saídas ao mesmo tempo. Canários: `test/lib/installers/effects.test.js` (igualdade dry × real do MESMO roteiro) e `test/commands/update-dry-run.test.js` — que tem DOIS canários e precisa dos dois: **igualdade** prova que os dois lados percorrem o mesmo caminho, **diferencial** (mudar `--templates` muda a previsão) prova que o caminho lê a flag. Só igualdade aprova uma previsão e uma execução que ignoram a MESMA flag — foi medido nesta feature, por mutação. Um laço de limpeza de órfão novo tem de nascer calado em `fx.dryRun` (D6): o clean o subsome. E a lista de `frameworkDirsToClean` é pinada **à mão** no teste (`DIRETORIOS_APAGADOS_POR_INTEIRO`, dez caminhos, `deepEqual` ordenado): derivar a expectativa chamando a própria função deixou a suíte inteira cega — medido, dava para remover 2 das 10 entradas sem matar nenhum dos 207 arquivos de teste |
 | `src/lib/ai/**` (`doctor --ai`) | `src/commands/project/doctor.js` (`doctorAiCommand` + a guarda de uso indevido), `bin/morph-spec.js` (`--ai`), `framework/docs/CLI.md`. **`--ai` NUNCA entra no `doctor --full` nem no default** — o renderer do `--full` manda tudo que não é `ok`/`warn` para `✗` e `test/commands/doctor.test.js` exige zero `✗` neste repositório. **Nada alcançável por `--ai` pode escrever**: `test/commands/doctor-ai.test.js` varre o grafo de imports E o corpo de `doctorAiCommand` (com os imports dinâmicos fixados nos dois permitidos), reprovando `writeFileSync`/`spawn`/`fs-extra` em CÓDIGO — comentários apagados antes, porque os módulos EXPLICAM por escrito que não fazem isso e medir a menção seria medir uma cópia do objeto. `null` é DESCONHECIDO e vira `skip` **com razão obrigatória**; `[]` é "perguntei e não achei" e vira `ok` |
 | `src/lib/ai/registry-audit.js` | o leitor de PRODUÇÃO do mesmo documento: `framework/templates/dotnet/ai-kit/src/Morph.AiKit/Providers/ModelRegistry.cs` (`CommentHandling = Skip`, `AllowTrailingCommas`, `AllowedAliasProperties` com `pricing`/`pricingWaiver`) e o exemplar `model-registry.v2.json` que o framework manda COPIAR. A auditoria tem de enxergar a **mesma forma** que o leitor de produção enxerga: com `JSON.parse` estrito, duas das cinco checagens saíam `skip` sobre o exemplar canônico — e `skip` não muda exit code, então o silêncio era total. A tolerância a JSONC vive em `framework/hooks/shared/comment-stripper.js`, ÚNICA (o `code-audit.js` usa o mesmo varredor, e o `code-budget` também, o único com a opção `js` — template e regex literal de TS/JS; sem ela o varredor é o de antes) — e a paridade é nos DOIS sentidos: `jsoncToJson` **lança** no comentário de bloco não fechado, porque o `JsonCommentHandling.Skip` do .NET lança, e ser mais frouxo que o kit é aprovar documento que a app recusa carregar. Ao mascarar strings, **as aspas delimitadoras ficam**: apagá-las junto faz um elemento-string virar espaço puro e o detector de vírgula sobrando comer um SEPARADOR real (`{"tags":["a","b"]}` saía inválido). Canário obrigatório: array terminado em **string**, com e sem vírgula sobrando — uma suíte só com arrays de número passa dos dois lados dessa inversão. A **REGRA DURA** do exemplar — *todo alias declara `pricing` OU `pricingWaiver`, nunca os dois, nunca nenhum* — é do alias, não de um mapa no topo: ler só o mapa dava 6 falsos positivos sobre um documento correto. O canário **copia o exemplar do disco**, nunca uma paráfrase dele |
 | `src/lib/worktree/dirs.js` | ÚNICA fonte do nome do container (`worktrees/`, sem ponto — Jest esconde diretório com ponto e reporta 0 testes sem erro). `worktree.js` re-exporta; `graphifyignore.js`, `file-copier.js`, `architecture-scanner.js`, `test-runner.js`, `worktree-audit.js`, os scanners do dashboard (`features-scanner.js`, `project-api.js`), `tasks/linux-runner.js` (exclusões do `tar` do `--linux`) importam. `test/lib/worktree/dirs.test.js` cobra cada leitor |

package/README.md

@@ -3,7 +3,7 @@
 > Spec-driven development framework for multi-stack projects. Turns feature requests into implementation-ready code through structured, AI-orchestrated phases.
 
 **Package:** `@polymorphism-tech/morph-spec`
-**Version:** 8.46.0  
+**Version:** 8.47.0  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -379,4 +379,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v8.46.0 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v8.47.0 by [Polymorphism Tech](https://polymorphism.tech)*

package/bin/morph-spec.js

@@ -366,17 +366,15 @@ graphCommand
 // ─── Validation ───────────────────────────────────────────────────────────
 program
   .command('validate [validator]')
-  .description('Run project validations (all | packages | architecture | contrast)')
+  .description('Run project validations (all | packages | next-components | spec-tasks)')
   .option('-v, --verbose', 'Show detailed output')
   .option('--auto-fix, --fix', 'Auto-fix issues where possible')
   .option('--no-fail', 'Don\'t exit with error code')
-  .option('--wcag-aaa', 'Use WCAG AAA standard (stricter)')
   .action((validator, options) => {
     const args = validator ? [validator] : ['all'];
     if (options.verbose) args.push('--verbose');
     if (options.autoFix) args.push('--auto-fix');
     if (options.noFail) args.push('--no-fail');
-    if (options.wcagAaa) args.push('--wcag-aaa');
     validateCommand(args);
   });
 
@@ -393,7 +391,6 @@ program
   .command('verify <feature> [task]')
   .description('Run the deterministic verification chain (build + tests + validators + e2e) — code before the LLM judge')
   .option('--json', 'Output as JSON')
-  .option('--rubric <id>', 'Force a rubric (default: by task group → config → default)')
   .option('--timeout <ms>', 'Timeout in ms for the build AND tests nodes (build default 120000; tests default 120000 per test project, or project.testTimeoutMs)', (v) => parseInt(v, 10))
   .option('--filter <ids>', 'Run only the test nodes whose id matches (comma-separated; exact or substring). Unmatched nodes are reported as skip; matching nothing is a usage error (exit 2)')
   .option('--linux', 'Run the test nodes inside a Linux container, on a COPY of the tree (the host tree is mounted read-only and copied in — a bind mount is case-insensitive and cannot reproduce case defects). No Docker = usage error, never a skip')

package/bin/validate.js

@@ -5,7 +5,7 @@
  *
  * Runs validators for the current project stack (detected from .morph/config/config.json).
  *
- * .NET/Blazor stacks: packages, architecture, contrast, spec-tasks
+ * .NET stacks:       packages, spec-tasks
  * Next.js stack:      next-components, spec-tasks
  * Other stacks:       spec-tasks
  *
@@ -23,7 +23,7 @@ import { getStackProfile } from '../src/lib/stack/stack-profile.js';
 
 /**
  * Build the VALIDATORS registry for the current stack.
- * .NET stacks  → packages, architecture, contrast, spec-tasks
+ * .NET stacks  → packages, spec-tasks
  * nextjs stack → next-components, spec-tasks
  * other stacks → spec-tasks only
  */
@@ -35,24 +35,12 @@ async function buildValidators(stack) {
 
   if (isDotnet) {
     const { validatePackages } = await import('../src/lib/validators/packages/package-validator.js');
-    const { validateArchitecture } = await import('../src/lib/validators/architecture/architecture-validator.js');
-    const { validateContrast } = await import('../src/lib/validators/ui/ui-contrast-validator.js');
 
     validators.packages = {
       name: 'Package Compatibility',
       description: 'Validates NuGet package versions against .NET compatibility matrix',
       run: validatePackages
     };
-    validators.architecture = {
-      name: 'Architecture Patterns',
-      description: 'Detects DI anti-patterns, middleware issues, and configuration problems in .NET',
-      run: validateArchitecture
-    };
-    validators.contrast = {
-      name: 'UI Contrast (WCAG)',
-      description: 'Validates color contrast ratios for accessibility',
-      run: validateContrast
-    };
   }
 
   if (isNextjs) {
@@ -273,8 +261,7 @@ async function runValidator(VALIDATORS, name, options) {
   try {
     const result = await validator.run('.', {
       verbose: true, // Always verbose for single validator
-      autoFix: options.autoFix,
-      wcagLevel: options.wcagLevel
+      autoFix: options.autoFix
     });
 
     if (result.status === 'ok') {
@@ -302,8 +289,7 @@ function parseOptions(args) {
   const options = {
     verbose: false,
     autoFix: false,
-    noFail: false,
-    wcagLevel: 'AA'
+    noFail: false
   };
 
   for (const arg of args) {
@@ -313,8 +299,6 @@ function parseOptions(args) {
       options.autoFix = true;
     } else if (arg === '--no-fail') {
       options.noFail = true;
-    } else if (arg === '--wcag-aaa') {
-      options.wcagLevel = 'AAA';
     }
   }
 
@@ -334,20 +318,15 @@ ${chalk.bold('USAGE')}
 ${chalk.bold('VALIDATORS')}
   all             Run all validators (default)
   packages        Validate NuGet package compatibility (.NET 10)
-  architecture    Validate architecture patterns (DI, lifecycle)
-  contrast        Validate UI contrast ratios (WCAG 2.1)
 
 ${chalk.bold('OPTIONS')}
   --verbose, -v        Show detailed output
   --auto-fix, --fix    Auto-fix issues where possible
   --no-fail            Don't exit with error code
-  --wcag-aaa           Use WCAG AAA standard (stricter)
 
 ${chalk.bold('EXAMPLES')}
   morph-spec validate                    # Run all validators
   morph-spec validate packages --fix     # Validate packages and auto-fix
-  morph-spec validate architecture -v    # Verbose architecture validation
-  morph-spec validate contrast --wcag-aaa # Stricter contrast validation
   morph-spec validate all                # Run all validators
 
 ${chalk.bold('EXIT CODES')}

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "8.46.0",
+  "version": "8.47.0",
   "displayName": "MORPH-SPEC Framework",
   "description": "Spec-driven development with 38 agents and 8-phase workflow for .NET/Blazor/Next.js/Azure",
   "publisher": "polymorphism-tech",

package/docs/CHEATSHEET.md

@@ -94,7 +94,7 @@ Never hand-edit `gateDecisions`/`approvalGates` in `feature.json` — always go
 ## CLI — validation
 
 ```bash
-morph-spec validate [architecture|packages|contrast] [--wcag-aaa]
+morph-spec validate [packages|next-components|spec-tasks]
 morph-spec validate-feature {feature} [--phase {phase}] [--json]   # alias: vf
 morph-spec verify {feature} [task] [--json] [--skip-tests] [--skip-build]   # deterministic build+test+validator chain, before the LLM judge
 ```
@@ -185,4 +185,4 @@ Never edited directly — go through CLI commands or `morph-spec update` instead
 
 ---
 
-*morph-spec v8.46.0 by Polymorphism Tech*
+*morph-spec v8.47.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -249,4 +249,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v8.46.0 by Polymorphism Tech*
+*morph-spec v8.47.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -32,7 +32,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Fechar cada task só com `verify {f} {T}` verde e cada `doneCriteria` com a evidência que o prova; vermelho ou critério sem prova dispara o loop de correção autônomo, sem escalar ao humano entre tarefas. No Gate 3, o veredito (`SHIP`/`FIX`) vem do **avaliador independente** despachado pela `morph-review` — nunca de quem implementou.
 - Em `hotfix`, o Gate 3 pausa **sempre** para um humano, mesmo em `trust: auto` — `approve ... review --mode auto` é recusado; aprove com `--approver`.
 - Confirmar antes de `finish`/`archive`/`delete` se o SessionStart avisar que outra sessão tem claim vivo na mesma feature.
-- **Contrato do relatório final** em todo dispatch de sub-agent: (1) grava o relatório em arquivo canônico ANTES de encerrar — `.morph/features/{f}/3-implement/reports/{taskId}.md` (avaliador: `4-review/evaluator-report.md`) — com o quê / **Arquivos:** / **Critérios:** (cada doneCriteria com evidência) / problemas; é o retorno autoritativo, nunca chamar `SendMessage`; (2) não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; (3) testes pelo orçamento, só o próprio filtro uma vez, sem red→green (a prova é o `verify` do orquestrador); (8) nunca mutar produção. Racional completo: `MORPH.md` §6. Templates: `morph-implement` §4, `morph-apply` §3b. **O orquestrador lê o arquivo ao retomar controle** — nunca confia só na mensagem de retorno da tool.
+- **Ao retomar o controle depois de um dispatch, o orquestrador lê o arquivo de relatório, não a mensagem final** — a mensagem pode não chegar ou vir resumida. As cláusulas do prompt vivem só nos templates (`morph-implement` §4, `morph-apply` §3b).
 
 ## Slash commands
 

package/framework/MORPH.md

@@ -21,7 +21,7 @@ Entre gates, você opera com autonomia total. O dev valida. Você executa.
 | Task implementada (código escrito) | `morph-spec verify <feature> <task>` e cada `doneCriteria` com a evidência que o prova |
 | Verify verde e critérios atendidos | Task `done`, próxima tarefa, sem anúncio |
 | Verify vermelho ou critério sem evidência | Loop de correção autônomo com o feedback, até 3 tentativas, sem pausa humana |
-| 3 tentativas sem fechar | Escalar ao usuário (aceitar/continuar/pular) — único ponto de pausa do loop |
+| 3 tentativas sem fechar | `AskUserQuestion` (aceitar/continuar/pular) — único ponto de pausa do loop; nunca uma 4ª tentativa por conta própria nem re-dispatch: sem informação nova, repete o erro |
 | `verify` exit 3 (fila pesada cheia) | A fila já esperou: no máximo uma chamada nova, depois avise — nunca laço de espera |
 
 **Regra de ouro:** dúvida que não bloqueia → resolver e registrar; dúvida que bloqueia → uma pergunta, máximo. Vale **entre gates** (plan/implement/review) — **não** vale na abertura da feature: a fase proposal pode rodar em **modo entrevista** (escolhido na pergunta de abertura, `morph-brainstorming` Parte 2), onde perguntar até fechar o entendimento é o comportamento desejado.
@@ -64,7 +64,7 @@ O morph-spec opera com três papéis que você assume conforme o contexto:
 
 **Orchestrator** — ativo na abertura de uma feature e nas transições de fase. Lê o mandato, entende o escopo, propõe o plano de ataque, identifica dependências entre tarefas, garante que gates sejam respeitados antes de avançar. Anti-padrão: não escreve código — se percebe que começou a implementar, pare, você transitou de papel sem intenção.
 
-**Specialist** — ativo durante a implementação. Executa tarefas do tasks.json em ordem, consulta standards antes de cada uma, registra decisões/desvios no decisions.md, mantém o recap.md atualizado ao final de cada tarefa. Anti-padrão: não cria novas tarefas — descoberta de escopo vai para decisions.md com flag "escopo expandido", o Orchestrator avalia se o tasks.json precisa mudar.
+**Specialist** — ativo durante a implementação. Executa tarefas do tasks.json em ordem, consulta standards antes de cada uma, registra decisões/desvios no decisions.md, mantém o recap.md atualizado ao final de cada tarefa. Anti-padrão: não cria novas tarefas — escopo descoberto: adição pequena → `notes` da task; erro de fato do spec → `## Errata` (§3); o escopo mudou → `morph-spec unapprove {f} plan` e re-aprovar, porque o contrato do Gate 2 é congelado.
 
 **Evaluator** — ativo no Gate 3, sempre um sub-agent independente com contexto fresco (`morph-evaluator`), nunca quem implementou (enforcement: relatório obrigatório, `--self-assessed`, exceção `hotfix` — **§5**). Segue `.morph/framework/evals/review-checklist.md`: veredito `SHIP`/`FIX` e bloqueador só com evidência (uc, teste, regressão, segurança); o resto é nota. Não roda a suíte (a prova é o verify do orquestrador) e não reescreve código.
 
@@ -188,11 +188,11 @@ Cada fase produz um trace JSON em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.js
 **Fluxo de consulta:**
 
 1. Antes de iniciar uma tarefa, identifique 1-3 standards relevantes — rode `morph-spec standards --find "<domínio/tecnologia da task>"` (devolve o top 3 como `id · path · digest`) em vez de filtrar `id`/`tags` à mão no JSON.
-2. Leia apenas o arquivo `.md` daquele standard (campo `path`).
+2. O `digest` (resumo de ~700 chars) costuma bastar; abra o `.md` (campo `path`) só quando não bastar — exemplo completo, seção que o resumo não cobre.
 3. Aplique durante a implementação. Se precisar de mais contexto, leia mais um standard.
 4. Registre no recap.md qual standard foi consultado e como foi aplicado.
 
-**Como identificar o standard certo:** filtre por `category` primeiro (ex: "architecture", "contracts", "testing"), depois por `tags` (ex: "dotnet", "nextjs", "blazor"). Dois standards relevantes em conflito → adote o mais específico ao stack do projeto e registre o conflito no decisions.md.
+**Como identificar o standard certo:** filtre por `category` primeiro (ex: "architecture", "backend", "frontend", "ai-agents"), depois por `tags` (ex: "dotnet", "nextjs", "maf"). Dois standards relevantes em conflito → adote o mais específico ao stack do projeto e registre o conflito no decisions.md.
 
 O agente responsável por um domínio está em `.morph/framework/agents.json` (fonte única — os subagents `morph-{id}` são gerados dele). O campo `persona` define o ponto de vista e o nível de rigor a adotar ao aplicar os standards daquele domínio trabalhando inline (um agente de arquitetura é mais rígido que um de suporte mensal).
 
@@ -218,6 +218,7 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), auto-pas
 | `standardsViolations` | array.length > 0 | Plano ou código viola padrões proibidos |
 | `evaluatorVerdict` | ≠ SHIP, bloqueador, ou ausente | Veredito do `evaluator-report`: `FIX`, bloqueador aberto, bloqueador sem tipo, ou relatório sem `**Verdict:**`. Só no **ship** |
 | `verificationStatus` | === 'fail' | `verify` vermelho — build, testes, validadores **ou e2e**. Vale em **qualquer** gate |
+| `verificationStatus` | ausente, no `review` | nenhum `verify` carimbado: ship sem prova; `approve` auto aplica a mesma régua |
 | `verificationStale` | true | Stamp do `verify` com sha != HEAD: o verde é de outro código. Só no **ship** |
 | `e2eSkipClass` (derivada) | environment/requested/unknown | e2e pulou sem dispensa legítima (só `project`/`scope`). Só no **ship** |
 | `verificationScope` | !== `feature` (presente) | Stamp do `verify` é de escopo parcial (`task:{id}`) — não cobre a feature inteira. Só no **ship** |
@@ -241,9 +242,9 @@ Modo: `.morph/config/config.json → trust` (`"auto"`, o default, ou `"manual"`)
 
 **Comportamento padrão fora de gate:** autonomia total — só pausa nestes três pontos. Ambiguidade de escopo fora do plano: registre em decisions.md, resolva conservadoramente, sinalize na entrega da task.
 
-**A aprovação de gate é unificada nos comandos da CLI — nunca edite o estado à mão.** Em `trust: "auto"` (sem `AskUserQuestion`): `morph-spec approve <feature> <gate> --mode auto`; `morph-spec advance <feature>` aprova o gate corrente **e** cria a pasta da próxima fase (`--design` = ramo opcional de uiux). **O hook state-sync.js** cobre o caminho manual: `AskUserQuestion` respondida com label "aprovado" → registra o gate no `feature.json` autoritativo com `approvedBy: "manual"`. **A feature é identificada pelo nome que a pergunta cita** — grava na árvore dona dela, nunca na "feature ativa" da sessão. Pergunta sem nome numa árvore com mais de uma feature: o hook **recusa gravar** e avisa — aprove por `morph-spec approve`.
+**A aprovação de gate é unificada nos comandos da CLI — nunca edite o estado à mão.** Em `trust: "auto"` (sem `AskUserQuestion`): `morph-spec approve <feature> <gate> --mode auto`; `morph-spec advance <feature>` aprova o gate corrente **e** cria a pasta da próxima fase (`--design` = ramo opcional de uiux). **O hook state-sync.js** cobre o caminho manual: `AskUserQuestion` respondida com frase de aprovação (abaixo) → registra o gate no `feature.json` autoritativo com `approvedBy: "manual"`. **A feature é identificada pelo nome que a pergunta cita** — grava na árvore dona dela, nunca na "feature ativa" da sessão. Pergunta sem nome numa árvore com mais de uma feature: o hook **recusa gravar** e avisa — aprove por `morph-spec approve`.
 
-**Registre quem aprovou (`approvedBy`):** objeto `{ approved, timestamp, approvedBy }`. `"auto"` — política `trust: auto` sem decisão humana. `"manual"` — humano aprovou (via `AskUserQuestion` ou, em headless, texto iniciado em "aprovado"); em `trust: manual` todo gate é `"manual"` — nunca `"auto"` num gate humano.
+**Registre quem aprovou (`approvedBy`):** objeto `{ approved, timestamp, approvedBy }`. `"auto"` — política `trust: auto` sem decisão humana. `"manual"` — humano aprovou — via `AskUserQuestion` ou, em headless, texto; o hook só reconhece resposta que começa com "aprovado" ou contém "pode avançar", "pode implementar" ou "pode prosseguir" (outra frase, ex. "lgtm", não grava: aprove por `morph-spec approve`); em `trust: manual` todo gate é `"manual"` — nunca `"auto"` num gate humano.
 
 **O hook gate-guard.js** confere, sem bloquear, se a ação num gate (pausar vs auto-aprovar) bateu com a decisão persistida. **Default:** `gate-check <feature> <gate> [--signals <json>] [--json]` decide via `shouldPauseGate`; `--signals` sobrescreve só o que o disco não expõe (`designSystemDivergence`, `standardsViolations`). **Escape manual** (sinal que `shouldPauseGate` não representa): `gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`. Ambos gravam `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` server-side (`.morph/framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão** — colide com state-sync. Divergência → o guard avisa no contexto.
 
@@ -257,7 +258,6 @@ A thread principal é o **Orchestrator**. Trabalho pesado ou fora do domínio co
 
 - **Domínio diferente do contexto corrente** (ver `agents.json → domains`) — ex: backend agora, próxima task é frontend/UI/dados. Gatilho mais importante: cada domínio tem sua persona e standards, e o sub-agent escopado os carrega sem inchar seu contexto.
 - **Esforço L ou XL** (> 5 minutos).
-- Mais de 3 tentativas de correção falharam no mesmo problema.
 - Análise de arquivo com mais de 500 linhas.
 - Tarefa repetitiva com mais de 3 instâncias do mesmo padrão.
 - Risco de "contaminar" o contexto principal com detalhes de baixo nível irrelevantes.
@@ -314,7 +314,7 @@ aceito em silêncio. Segunda ausência sem trabalho entregue é falha real: esca
 - **Critérios:** cada `doneCriteria`, atendido (com o teste ou `arquivo:linha`) ou não (por quê)
 - Problemas encontrados e como foram resolvidos
 
-**Contrato do relatório final:** as oito cláusulas que todo prompt de dispatch inclui vivem nos DOIS templates — `morph-implement` §4 e `morph-apply` §3b — e não são repetidas aqui: duas cópias da mesma regra divergem, e quem manda é a que o sub-agent recebe. **4-8** (escopo, sobrevivência, processos, retorno, mutação) são idênticas **palavra por palavra**, e um canário as compara; **1-3** (relatório, estado, teste) dizem o mesmo na redação de cada template.
+**Contrato do relatório final:** as oito cláusulas que todo prompt de dispatch de implementador inclui vivem nos DOIS templates — `morph-implement` §4 e `morph-apply` §3b — e não são repetidas aqui: duas cópias da mesma regra divergem, e quem manda é a que o sub-agent recebe. **4-8** (escopo, sobrevivência, processos, retorno, mutação) são idênticas **palavra por palavra**, e um canário as compara; **1-3** (relatório, estado, teste) dizem o mesmo na redação de cada template.
 
 **Teto de turnos:** `maxTurns` por persona no `agents.json` (sem o campo, 20; implementadores 120), anunciado ao sub-agent no corpo da persona. O corte é cego: a cláusula 5 manda `wip` por marco e, a ~70% do teto, relatório `PARCIAL` sem critério dado como atendido (`report-incomplete`): retome o agente, não carimbe DEGRADADO.
 

package/framework/commands/create-umbraco-lp.md

@@ -2,6 +2,8 @@
 description: Cria uma nova landing page ponta-a-ponta a partir do template MORPH Umbraco genérico: coleta decisões, scaffolda com new-lp, sobe e valida, customiza branding e módulos.
 argument-hint: [nome-do-projeto]
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill
+stacks:
+  - umbraco
 ---
 
 # /create-umbraco-lp — Nova LP Umbraco

package/framework/commands/migrate-lp-to-umbraco.md

@@ -2,6 +2,8 @@
 description: Migra uma LP existente (React/Vite, Next.js estático ou HTML) para o template Umbraco-headless MORPH entregando a LP EXATAMENTE igual à origem (mesmo CSS, imagens, fontes e comportamento) + Umbraco — obtenção automática do template, lift-and-rewire verbatim de cada seção para módulo editável, conexão do formulário ao backend de leads e gate de paridade determinístico. Repo-agnóstica.
 argument-hint: <projeto>
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion, Skill
+stacks:
+  - umbraco
 ---
 
 # /migrate-lp-to-umbraco — Migração de LP para Umbraco Headless

package/framework/commands/morph-archive.md

@@ -1,5 +1,5 @@
 ---
-description: Archive a completed MORPH-SPEC feature after Gate 3 approval
+description: Archive a feature WITHOUT integrating — reserved for legacy features (no morph/{f} branch) and cleanup; the normal close is morph-spec finish
 argument-hint: <feature-name>
 allowed-tools: Read, Bash
 ---

package/framework/commands/morph-hotfix.md

@@ -22,7 +22,7 @@ Resolve uma queda ou bug crítico de produção com prioridade máxima em veloci
 4. **Fix cirúrgico:** implementa a mudança mínima que resolve o sintoma — sem refatoração, sem hardening fora de escopo.
 5. **Test loop:** `morph-spec verify {feature-name} {task} --json` focado no blast radius até verde; evidência real capturada no `recap.md`.
 6. **Gate 3 sempre humano:** `morph-spec gate-check {feature-name} review` (força a pausa via `workType: hotfix`, lido do disco) → `4-review/review-report.md` → `AskUserQuestion` sempre. **Nunca** `morph-spec approve {feature-name} review --mode auto` — o CLI recusa essa combinação num hotfix.
-7. **Pós-gate:** `morph-spec verify {feature-name}` (suíte completa da feature) e sinaliza commit/archive — não arquiva automaticamente.
+7. **Pós-gate:** `morph-spec verify {feature-name}` (suíte completa da feature), depois `morph-spec finish {feature-name} --pr|--merge` — o encerramento único (arquiva, integra, desmonta). O usuário decide o modo, porque `finish` toca a default ou o remoto; `--pr` **não integra** (`awaiting: "merge"`), então o incidente só está resolvido depois do merge.
 
 ## Anti-padrões
 

package/framework/commands/morph-infra.md

@@ -1,215 +1,29 @@
 ---
-description: Manage Azure infrastructure with Bicep templates — provision, update, and monitor cloud resources
-argument-hint: [up|down|plan|status]
-allowed-tools: Read, Write, Edit, Bash, Glob, AskUserQuestion
+description: Infra do projeto — Docker Compose local e deploy no Coolify (API via SSH), com política de custo
+argument-hint: [compose|deploy|status]
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Agent
 ---
 
-# /morph-infra - Infrastructure Management
+# /morph-infra — Infraestrutura
 
-Manage Azure infrastructure using Bicep templates.
+Antes de agir, leia os standards: `morph-spec standards --find infra` (deploy no Coolify e isolamento do compose local). Trabalho de infra vai para a persona `morph-infra-engineer` quando ela está instalada; sem ela, siga os standards direto.
 
-## Usage
+## Local — Docker Compose
 
-```
-/morph-infra [action] [options]
-```
+Cada worktree sobe o próprio stack: portas do bloco do worktree (`${VAR:-default}`), nunca `container_name`, healthcheck em todo serviço. Subir e provar: `morph-spec e2e up {feature}` e o nó e2e do `morph-spec verify {feature}`.
 
-### Actions
+## Deploy — Coolify
 
-| Action | Description |
-|--------|-------------|
-| `init` | Initialize IaC structure in the project |
-| `validate` | Validate Bicep templates |
-| `plan` | Show what-if of changes |
-| `deploy` | Execute resource deployment |
-| `destroy` | Remove all resources |
+Não existe MCP nem CLI do Coolify: o acesso é por SSH ao servidor (alias configurado pelo usuário) e `curl` na API em `localhost`, com o token lido do lado do servidor e nunca impresso. Variáveis de ambiente ficam no Coolify, nunca no Dockerfile. Repositório e PRs pelo `gh`.
 
----
-
-## Workflow
-
-### 1. INIT - Initialize IaC
-
-When the user requests `/morph-infra init`:
-
-1. Create the `infra/` structure in the project:
-   ```
-   infra/
-   ├── main.bicep
-   ├── parameters.dev.json
-   ├── parameters.prod.json
-   └── modules/
-       ├── container-app.bicep
-       ├── container-app-env.bicep
-       ├── sql-database.bicep
-       ├── storage.bicep
-       ├── key-vault.bicep
-       └── app-insights.bicep
-   ```
-
-2. Copy templates from `.morph/framework/templates/infrastructure/...`
-
-3. Replace placeholders:
-   - `{{APP_NAME}}` → project name
-   - `{{SUBSCRIPTION_ID}}` → request from user
-   - `{{RESOURCE_GROUP}}` → suggest default `rg-{app}-{env}`
-
-4. Document the created structure in `decisions.md`
-
----
-
-### 2. VALIDATE - Validate Templates
-
-When the user requests `/morph-infra validate`:
-
-1. Run Bicep validation:
-   ```bash
-   az bicep build --file infra/main.bicep
-   ```
-
-2. Check required parameters
-
-3. Report errors or success
-
----
-
-### 3. PLAN - Preview Changes
-
-When the user requests `/morph-infra plan [env]`:
-
-1. Check if Azure CLI is authenticated:
-   ```bash
-   az account show
-   ```
-
-2. Run what-if:
-   ```bash
-   az deployment group what-if \
-     --resource-group rg-{app}-{env} \
-     --template-file infra/main.bicep \
-     --parameters @infra/parameters.{env}.json
-   ```
-
-3. Present change summary:
-   - Resources to create
-   - Resources to modify
-   - Resources to delete
-   - Estimated costs
-
-4. **STOP and wait for approval** before deploy
-
----
-
-### 4. DEPLOY - Execute Deploy
-
-When the user requests `/morph-infra deploy [env]`:
-
-1. Verify plan was approved
-
-2. Create resource group if it doesn't exist:
-   ```bash
-   az group create --name rg-{app}-{env} --location brazilsouth
-   ```
-
-3. Execute deploy:
-   ```bash
-   az deployment group create \
-     --resource-group rg-{app}-{env} \
-     --template-file infra/main.bicep \
-     --parameters @infra/parameters.{env}.json
-   ```
+## Custo
 
-4. Capture outputs:
-   - Container App URL
-   - SQL Connection String
-   - Key Vault URI
+| Custo mensal | Ação |
+|---|---|
+| grátis | segue |
+| até US$ 10 | confirme com o usuário |
+| acima de US$ 10 | ADR em `decisions.md` antes de criar |
 
-5. Update documentation with deploy information
-
----
-
-### 5. DESTROY - Remove Resources
-
-When the user requests `/morph-infra destroy [env]`:
-
-1. **WARN** that this action is irreversible
-
-2. List resources that will be deleted
-
-3. **STOP and wait for explicit confirmation** ("yes, delete")
-
-4. Execute:
-   ```bash
-   az group delete --name rg-{app}-{env} --yes --no-wait
-   ```
-
----
-
-## Security Rules
-
-### NEVER:
-- Expose secrets in logs
-- Commit files with secrets
-- Delete production resources without explicit confirmation
-- Create resources outside Bicep (zero portal)
-
-### ALWAYS:
-- Use Key Vault for secrets
-- Validate Bicep before deploy
-- Run what-if before deploy
-- Document estimated costs
-- Keep parameters.json separated by environment
-
----
-
-## Cost Guardian Integration
-
-Before any deploy, check with Cost Guardian:
-
-1. Estimate monthly resource costs
-2. Verify it's within approved limits:
-   - Free tier: no approval needed
-   - Up to $10/month: requires confirmation
-   - Above $10: requires ADR
-
----
-
-## Usage Example
-
-```
-User: /morph-infra init
-Claude: Creating IaC structure...
-        - infra/main.bicep
-        - infra/parameters.dev.json
-        - infra/modules/*.bicep
-        Done! Run /morph-infra validate to verify.
-
-User: /morph-infra plan dev
-Claude: Analyzing changes for dev environment...
-
-        CREATE:
-        + Container App Environment
-        + Container App
-        + SQL Server (Free)
-        + Storage Account (LRS)
-        + Key Vault
-        + Application Insights
-
-        ESTIMATED COST: ~$0/month (Free tier)
-
-        Approve deploy? (yes/no)
-
-User: yes
-Claude: Executing deploy...
-        ✓ Resource Group created
-        ✓ Deploy completed in 3m 45s
-
-        OUTPUTS:
-        - URL: https://myapp-dev.azurecontainerapps.io
-        - SQL: tcp:myapp-dev-sql.database.windows.net
-        - Key Vault: https://myapp-dev-kv.vault.azure.net
-```
-
----
+Nunca apague recurso de produção sem confirmação explícita.
 
-*MORPH-SPEC by Polymorphism Tech*
+**Input:** $ARGUMENTS

package/framework/commands/morph-media.md

@@ -2,6 +2,9 @@
 description: Conduz a autoria de mídia gerada por IA — escolher o modelo pelo trabalho, montar o prompt como spec versionada, encadear a partir de um herói aprovado, subir a escada de custo e conduzir o gate humano de escolha entre N candidatas.
 argument-hint: [o que gerar]
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill
+stacks:
+  - dotnet
+  - nextjs
 ---
 
 # /morph-media — Autoria de mídia gerada