@polymorphism-tech/morph-spec 8.46.0 → 9.0.0

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

@@ -1,161 +0,0 @@
----
-name: morph-brainstorming
-description: Entende o negócio, os usuários e a arquitetura antes de qualquer planejamento técnico. Varre o ambiente primeiro, monta a árvore de decisões abertas e abre com a escolha de modo de descoberta (entrevista uma-pergunta-por-vez ou automático). Para projetos existentes, detecta desvios de stack e propõe plano de compliance.
-version: core
-when-to-invoke: ao receber um novo request de feature, antes de morph-plan
-user-invokable: true
-cliVersion: "8.46.0"
----
-
-# morph-brainstorming
-
-## Objetivo
-Garantir que o planejamento técnico parta de entendimento real do negócio e do contexto técnico existente — não de suposições. Output é o `proposal.md` aprovado pelo Gate 1.
-
-## Quando invocar
-Ao iniciar uma nova feature — antes de qualquer especificação técnica ou planejamento.
-
-## Stack padrão (baked in)
-
-O harness conhece o stack por padrão (backend .NET 10 + VSA + EF Core/Neon, IA via MAF, frontend Next.js/Tailwind/Shadcn) e a lista de padrões proibidos (`Guid.NewGuid()`, classes não-sealed, Service/Manager layer, repository genérico, SQL cru). **Não pergunte sobre tecnologia a menos que haja ambiguidade real** — stack nunca entra na árvore de decisões. Regra canônica: `MORPH.md` § "Stack baked-in".
-
-## Modo bug-lean (`workType: bug`)
-
-Quando a feature tem `workType: bug` (roteada pela `morph-proposal` — ver MORPH.md §2.1 "Roteamento por tipo de trabalho"), o brainstorming é enxuto. A varredura (Parte 0) continua rodando normalmente — o diagnóstico precisa do contexto técnico —, mas a árvore da Parte 1 é de **repro, diagnóstico e comportamento do sistema**, não de negócio; em modo automático (Parte 3) isso significa no máximo 1 pergunta de repro, e só se o pedido original não deixar claro. O `proposal.md` (Parte 4) foca em **Repro / Diagnóstico / Root cause provável / Escopo do fix / Conflitos com o acervo**, sem as seções de negócio completas.
-
-Para `workType: feature` (ou features sem `workType` — compat, ver MORPH.md §2.1), o fluxo completo abaixo permanece integral.
-
-## O que fazer
-
-### Parte 0 — Varredura (antes de qualquer pergunta)
-
-Fato não se pergunta. Antes de levar a primeira pergunta ao usuário, levante o que o ambiente já responde:
-
-1. Invoque `Skill(morph-stack-scan)`. A skill:
-   - Curto-circuita em projetos greenfield (sem source files) — retorna relatório vazio.
-   - Em brownfield, varre stack atual (.csproj, package.json, migrations), padrões (Guid.NewGuid vs Guid.CreateVersion7, sealed, result pattern), features existentes.
-   - Produz `.morph/features/{feature}/0-proposal/stack-scan.md`.
-
-2. Leia o contexto que já existe no projeto: `.morph/context/` (se existir), `.morph/config/config.json` (stack, integrations, trust), as features ativas em `.morph/features/`, o **acervo de use cases** em `.morph/specs/usecases/` e o **índice de ADRs ativos** em `.morph/specs/adrs/` (um arquivo por ADR, se existir). O comportamento já implementado é o contexto mais barato que existe — e é ele que evita perguntar o que o sistema já responde.
-
-   O acervo tem ciclo de vida: UC com `status: superseded` **não é o comportamento vigente** — o vigente é o `superseded_by`, e `scope` (quando existe) diz onde o antigo ainda vale. Decisão vigente é a do índice; os `decisions.md` de `.morph/archive/` são **história, não instrução** — abra um só para entender por que algo é como é, nunca para decidir.
-
-3. **Conflitos com o acervo — avise, não entreviste.** Para cada UC vigente, ADR do índice ou documento de `.morph/context/` que o pedido novo **contradiz**:
-   - **Avise o usuário** — uma linha por conflito no resumo que abre a Parte 2 (fonte, o que ela diz, o que o pedido muda). Aviso, não pergunta.
-   - **Pedido explícito sobre o ponto → vale o mais novo.** Registre a escolha na coluna **Decisão** da seção de conflitos (o que muda, o que o antigo ainda cobre) e siga. Só entra na árvore (Parte 1) o conflito que o pedido deixa **ambíguo** — "o admin passa a Geist" não diz nada sobre a vitrine, então a vitrine é decisão; o admin não é.
-   - Todo conflito vai para a seção **Conflitos com o acervo** do `proposal.md` (Parte 4). A `2-plan/` só abre depois do Gate 1, então é a `morph-plan` que transforma cada decisão pelo novo em ADR no `decisions.md` e em linha de revogação no `spec.md` (§3) — é essa linha que o `finish` aplica ao acervo.
-
-4. Reconciliação de design-system (se aplicável): comparar `.morph/context/design-system.md` (se existir) com o que foi detectado no stack-scan e com bundles/mocks recentes do usuário. Se houver **divergência** (tokens diferentes, framework version mismatch, fonte aprovada distinta), marque `signals.designSystemDivergence = true` — a escolha da fonte vira uma **decisão da árvore** (Parte 1), não uma pergunta solta. Resolvida, **reescreva o corpo** de `.morph/context/design-system.md` com a fonte escolhida — a seção que descrevia a antiga passa a descrever a nova, e o valor que ainda vale num escopo diz o escopo. O changelog guarda **só data e motivo**, nunca o valor novo: quem lê só o corpo precisa receber a resposta de hoje.
-
-5. Desvio de stack detectado (`stack-scan.md`, seção Desvios): "a migração entra nesta feature ou vira feature separada?" — pergunta feita pelo `morph-stack-scan` ao fim da varredura — também é decisão da árvore; a resposta vai para a seção "Compliance de stack" do `proposal.md` (Parte 4).
-
-### Parte 1 — Árvore de decisões abertas
-
-Enumere **só o que a varredura não respondeu**. Uma decisão entra na árvore quando (a) muda o escopo, o comportamento ou a arquitetura da feature, e (b) o ambiente não a resolve.
-
-Ordene por dependência: decisão que **poda** outras vem primeiro. "O fluxo é síncrono ou assíncrono?" antecede "qual é a política de retry" — a primeira resposta pode eliminar a segunda inteira.
-
-Publique a **árvore de decisões** ao usuário antes de perguntar qualquer coisa. Ela é o sinal de progresso da entrevista e a base da recomendação de modo na Parte 2.
-
-### Parte 2 — Pergunta de abertura (modo de descoberta)
-
-Aplica-se a `workType: feature` e `bug`. **`chore` e `hotfix` não passam por aqui** — nascem com os Gates 1 e 2 carimbados `policy:{tipo}` e começam direto em `implement`.
-
-Faça **uma** `AskUserQuestion` apresentando a árvore e recomendando um modo. A recomendação sai do tamanho e do acoplamento da árvore: muitas decisões abertas, ou decisões que dependem umas das outras → recomende **entrevista**; árvore rasa ou já respondida pela varredura → recomende **automático**. A opção recomendada vai em primeiro lugar, com o sufixo `(Recomendado)` no label.
-
-```
-question: "Antes de começar {feature}: entrevista ou automático? Encontrei {n} decisões abertas: {resumo da árvore}"
-header: "Descoberta"
-options:
-  - { label: "{modo recomendado} (Recomendado)", description: "{por que a árvore recomenda este modo}" }
-  - { label: "{o outro modo}", description: "{o que muda na prática}" }
-```
-
-### Parte 3 — Entendimento
-
-**Modo entrevista.** Percorra a árvore, **uma pergunta por chamada** de `AskUserQuestion` — perguntas em lote desorientam e impedem que uma resposta pode ramos. Regras:
-
-- Toda pergunta traz **resposta recomendada**, como primeira opção, marcada `(Recomendado)`.
-- Cada resposta risca, poda ou abre ramos; mostre a árvore atualizada quando ela mudar de forma.
-- Fato descoberto no ambiente nunca vira pergunta. As **decisões** são do usuário; os **fatos** são seus.
-- Termina quando a árvore zera. Então apresente o **entendimento compartilhado** (problema, escopo com exclusões, usuários e fluxos, riscos) — a confirmação dele é o Gate 1, que **pausa sempre** neste modo.
-- O usuário pode encerrar a entrevista a qualquer momento; o que ficou aberto vira exclusão explícita de escopo no `proposal.md`.
-
-**Modo automático.** Até 4 perguntas via `AskUserQuestion` cobrindo o que a árvore deixou aberto:
-   - Qual problema de negócio esta feature resolve?
-   - Quem são os usuários afetados e quais são os fluxos críticos deles?
-   - Qual é o critério de sucesso — como saberemos que a feature está pronta?
-   - Há integrações externas, dependências de outras features ou restrições de prazo?
-
-   Árvore vazia → nenhuma pergunta. O Gate 1 segue trust-aware (regras do MORPH.md §5).
-
-**Em `workType: bug`**, a árvore é de **repro, diagnóstico e comportamento do sistema** — não de negócio. Em modo automático vale o bug-lean: no máximo 1 pergunta de repro, e só se o pedido original não deixar claro.
-
-### Parte 4 — Produção do proposal.md
-
-1. Produza `proposal.md` em `.morph/features/{feature}/0-proposal/` com:
-   - **Problema:** o que está sendo resolvido e para quem (máx. 2 parágrafos)
-   - **Escopo:** o que está incluído e o que está explicitamente excluído — registre se a mudança cria ou altera superfície de UI (componente, página, tela, estilo, fluxo de navegação): é o fato que decide o roteamento para o ramo uiux na `morph-proposal` (critério objetivo em `MORPH.md` §2.1)
-   - **Usuários e fluxos críticos:** quem usa e qual é o caminho principal
-   - **Stack:** confirme o stack padrão ou documente desvios aprovados
-   - **Riscos e dependências:** o que pode dar errado, o que esta feature depende
-   - **Compliance de stack:** "Em compliance" ou lista de desvios detectados e plano de resolução
-   - **Conflitos com o acervo:** os conflitos da Parte 0 (passo 3), numa tabela `Fonte | O que diz hoje | O que o pedido muda | Decisão` — ou `Nenhum conflito encontrado.`. A seção existe sempre, também no bug-lean: ausente, ela diz que a checagem não rodou (o `validate-feature` avisa)
-
-   **Não escreva critérios de aceite aqui.** O comportamento verificável mora nos **use cases**, destilados pela `morph-plan` na fase seguinte (`2-plan/usecases/UC-{nn}-{slug}.md`), onde cada pós-condição precisa ser observável em teste e chega literal ao `doneCriteria` das tasks. O `proposal.md` responde **o quê e por quê**; os use cases respondem **como o sistema se comporta**. Duplicar aqui produz duas fontes que divergem no primeiro ajuste.
-
-   **Se `workType: bug`** (modo bug-lean, ver nota no início da skill), substitua a lista acima pela estrutura enxuta: **Repro** (passos para reproduzir), **Diagnóstico** (o que foi observado/investigado), **Root cause provável**, **Escopo do fix** (o que muda, o que fica de fora) e **Conflitos com o acervo** — sem as seções de negócio completas do fluxo `feature`. A condição verificável de que o bug foi corrigido vira a **pós-condição** que faltava no use case do acervo (`.morph/specs/usecases/`), corrigida ou acrescentada na fase plan.
-
-   Um bom proposal.md tem no máximo 2 páginas. Se está crescendo além disso, o escopo precisa ser cortado.
-
-2. Apresente o Gate 1 segundo o modo de descoberta e o trust mode.
-
-   **Modo entrevista** (Parte 2) é a única exceção genuína: pausa sempre, e `shouldPauseGate` não tem esse conceito — `discoveryMode` não está entre as chaves que `gate-check --signals` aceita sobrescrever. Registre direto, sem `gate-check`:
-   ```
-   morph-spec gate-decision {feature} proposal --pause true --reason "modo entrevista — entendimento compartilhado confirmado pelo usuário" --signals '{"discoveryMode":"interview"}'
-   ```
-
-   **Fora do modo entrevista** (o caminho comum), rode `morph-spec gate-check {feature} proposal [--json]` — lê `trust` de `.morph/config/config.json`, decide via `shouldPauseGate` e persiste `gateDecisions.proposal` com timestamp server-side, imprimindo `pause`/`reason`/`signals`. Se a Parte 0 detectou divergência de design-system (leitura semântica — o `gate-check` não a vê sozinho no disco), repasse-a: `designSystemDivergence` é uma das poucas chaves que `--signals` aceita sobrescrever aqui:
-   ```
-   morph-spec gate-check {feature} proposal --signals '{"designSystemDivergence":true}'
-   ```
-
-   **Nunca edite `feature.json` à mão** (o Edit manual colide com o hook state-sync — erro "file modified since read"). Os dois comandos gravam `gateDecisions.proposal = { pause, reason, signals, trust, decidedAt }` no mesmo lugar (shape canônico em `.morph/framework/schemas/feature.schema.json`); o hook `gate-guard.js` confere depois se a ação (pausar vs auto-aprovar) bateu com a decisão persistida.
-
-   **Se `pause === true`** (manual mode OU risco detectado em auto), use `AskUserQuestion`:
-
-   ```
-   question: "Gate 1 — Proposta de {nome} aprovada?{ reason ? ' Sinal de risco: ' + reason : '' }"
-   header: "Gate 1"
-   options:
-     - { label: "aprovado, prosseguir", description: "Aceitar a proposta e avançar para o planejamento" }
-     - { label: "preciso ajustar", description: "Apontar mudanças necessárias antes de prosseguir" }
-     - { label: "cancelar feature", description: "Abortar — feature não vai avançar" }
-   ```
-
-   Aguardar resposta. Se "preciso ajustar", aplique e reapresente.
-
-   **Se `pause === false`** (auto-aprovação), exibir summary curto e prosseguir sem aguardar:
-
-   ```
-   ## Gate 1 (auto-aprovado)
-
-   **Feature:** {nome}
-   **Problema:** {1 frase}
-   **Escopo:** {incluído} | Excluído: {exclusões}
-   **Stack:** {compliance}
-   **Riscos:** {principal} (sinais detectados: nenhum)
-   ```
-
-   No caminho manual, o hook state-sync.js detecta a aprovação automaticamente (grava o gate no `feature.json` autoritativo, `approvedBy: "manual"`) — **atribuindo pela feature nomeada na pergunta**; sem o nome, e com mais de uma feature na árvore, ele recusa a gravar e avisa (aprove então por `morph-spec approve {feature} proposal`). Em modo auto sem AskUserQuestion, aprove via `morph-spec approve {feature} proposal --mode auto` (ou `morph-spec advance {feature}` para já criar a pasta 2-plan/) — nunca via Edit à mão de state.json.
-
-## Output esperado
-- `.morph/features/{feature}/0-proposal/proposal.md` — proposta aprovada, com desvios de stack (se houver) resolvidos na seção "Compliance de stack" e os conflitos com o acervo listados em "Conflitos com o acervo"
-- Gate 1 apresentado e aprovado
-
-## 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`)
-- `.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)
-- `.morph/specs/usecases/` e `.morph/specs/adrs/` — o acervo vigente (UC `superseded` e `decisions.md` arquivado não são instrução); lidos na Parte 0

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

@@ -1,194 +0,0 @@
----
-name: morph-implement
-description: Guia a execução de cada tarefa de implementação com standard e persona adequados
-version: core
-when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
-user-invokable: false
-cliVersion: "8.46.0"
----
-
-# morph-implement
-
-## Objetivo
-Executar uma task com o standard e a persona certos, até o `doneCriteria` valer e o
-`verify` da task ficar verde, e registrar o resultado no recap.
-
-## Quando invocar
-Ao iniciar cada task de `tasks.json`, antes de escrever código. Normalmente chamada pela
-`morph-apply`, que passa a task atual.
-
-## O que fazer
-
-1. **Contexto, uma vez por sessão.** Na primeira task da sessão (ou depois de um `/compact`), Read
-   em `2-plan/spec.md`, nos use cases que a task referencia (`2-plan/usecases/UC-*.md`) e em
-   `2-plan/decisions.md`. Nas tasks seguintes, **não releia por padrão**: o contrato do plano está
-   congelado desde o Gate 2. Releia só o trecho que falta para a task corrente.
-
-   **Correção** (a `morph-apply` devolveu a task com o `feedback` do verify vermelho ou com critério
-   não atendido): corrija esses pontos no código existente — não reimplemente.
-
-2. **Standard.** `morph-spec standards --find "<domínio da task>"` devolve `id · path · digest`.
-   O digest decide; Read só no `.md` escolhido. Task MAF: os `standards/ai-agents/*.md` relevantes
-   valem mesmo com docs externas consultadas. Nenhum standard cobre: registre em `decisions.md` e
-   siga o critério mais conservador.
-
-3. **Persona.** `task.agent` e `task.standards` (carimbados pelo `morph-plan`). Plano legado sem
-   `agent`: Read em `.morph/framework/agents.json` e escolha por `domains`. O `**Persona:**` do recap
-   registra o mecanismo real: `morph-{id}`, `general-purpose (fallback: {id})` ou `inline ({id})`.
-
-4. **Despachar ou não.** Despache (`subagent_type: "morph-{id}"`) quando a task muda de domínio,
-   tem effort L/XL, já falhou 3 correções no mesmo ponto, exige ler arquivo > 500 linhas, ou repete
-   um padrão > 3 vezes. Inline só para S/M no domínio já carregado. O DAG da `morph-apply` decide
-   quantas tasks rodam ao mesmo tempo; este passo decide quem executa cada uma.
-
-   Tipo `morph-{id}` não registrado: `general-purpose` com o campo `persona` colado no prompt, e
-   `dispatch-fallback: general-purpose ({id} não registrado)` nas `notes` da task.
-   Template do prompt para `subagent_type: "morph-{id}"` — cole literal, só os campos entre colchetes mudam:
-   ```
-   Implementar [ID]: [title da task]
-
-   Spec: [description completa do tasks.json]
-   Standards: [por standard: `id` + o digest do `standards --find` + as 3-8 regras
-     do .md que ESTA task aplica, coladas. O path vai junto só para consulta
-     pontual — o sub-agente não relê standards inteiros]
-   Arquivos relevantes: [os `target` de task.reuse + o que o scout/grafo apontou
-     — é por aqui que o código existente chega ao sub-agente, que trabalha em
-     contexto fresco. O que você já leu entra como `arquivo:linhas` + o trecho]
-   Reuso: [task.reuse — `CONCEITO: VEREDITO → alvo`, uma linha por conceito]
-   Done quando: [doneCriteria do tasks.json]
-
-   Antes de criar tipo, componente, hook ou serviço NOVO, verifique se já
-   existe: `morph-spec graph explain <nome>` e `graph affected <conceito>
-   --uses-only`. Sem grafo (`no-graph`), caia para `grep -rn "<nome>"` e siga —
-   a ausência de grafo nunca bloqueia. Se algo cobre o caso, reuse ou estenda;
-   se criar mesmo assim, diga por que em uma linha no relatório.
-
-   Leitura e turnos: cada turno custa ~10 s antes de a tool rodar, e o teto de
-   turnos corta sem aviso. Chamadas que não dependem uma da outra vão no MESMO
-   turno: leia de uma vez todos os arquivos que este prompt lista, dispare os
-   Grep juntos. Use Read/Grep/Glob — nunca `grep`, `sed -n`, `cat`, `find`,
-   `ls` via Bash. Não releia o que este prompt já traz. Em arquivo grande, `Grep`
-   acha a linha e `Read` com `offset`/`limit` lê só o trecho; log de build/teste
-   se lê pelo `Grep` do erro, não inteiro.
-
-   Ferramentas: antes de supor a API de uma biblioteca (MAF, EF Core, Next,
-   shadcn, SDK de provedor), consulte o MCP `context7` (`resolve-library-id` →
-   `query-docs`). Impacto e vizinhança de símbolo vêm do grafo
-   (`morph-spec graph`). Tool `mcp__…` não carregada se carrega com `ToolSearch`
-   (`select:<nome>`); MCP ausente nunca bloqueia — siga com o fallback.
-
-   Comentário: o padrão é nenhum. Nome, tipo e teste explicam o código; sem
-   `///`/JSDoc em membro de aplicação, cabeçalho, banner de seção ou história
-   da task. Só o porquê que o código não mostra, em uma linha
-   (`architecture-code-comments`). O elo com a pós-condição vai no nome do
-   teste. O hook `comment-guard` bloqueia a edição que adiciona história,
-   banner ou bloco longo.
-
-   Contrato do relatório final:
-   1. GRAVE `.morph/features/{feature}/3-implement/reports/[ID].md` ANTES de
-      encerrar — é o retorno autoritativo, não a sua mensagem final. NÃO chame
-      SendMessage.
-   2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
-      — todo estado é gravado exclusivamente pelo orquestrador.
-   3. TESTE — a prova é do orquestrador (`morph-spec verify {feature} {task}`,
-      logo depois do seu retorno), não sua. Escreva os testes pelo orçamento:
-      um por pós-condição, um de regressão por bug, variantes numa tabela
-      (`[Theory]`/`it.each`). NÃO rode teste a cada marco nem faça ciclo
-      red→green: escreva código e testes, compile, e rode SÓ o filtro dos seus
-      testes UMA vez, em primeiro plano, antes do relatório; se falhar, corrija e rode só os que falharam. Grave a
-      saída em arquivo (`… > .morph/logs/test-last.log 2>&1`, sem nada depois)
-      e leia o arquivo — um pipe troca o exit do teste pelo do último comando.
-      Em batch paralelo SEM isolamento, só compile. Com `isolation: "worktree"`,
-      o mesmo vale no seu worktree, e o último ato é o commit na branch dele.
-   4. ESCOPO: no máximo 3 tasks e ~4 arquivos por dispatch. Escopo maior falha e
-      volta — fatie antes, não depois.
-   5. SOBREVIVÊNCIA: o limite de turnos (`maxTurns`, no seu system prompt)
-      corta sem aviso: commite `wip({taskId})` a cada marco (um arquivo ou
-      uma fatia coerente escrita), não só ao fim da task — e só os seus arquivos
-      (`git add <paths>`, nunca `-A`). Sem commit, a retomada recomeça do zero.
-      A ~70% do limite, grave o relatório parcial no arquivo canônico: `PARCIAL`
-      na 1ª linha, o feito e o que falta, sem critério dado como atendido. Depois
-      siga ou pare, por decisão sua; o relatório final substitui o parcial.
-   6. PROCESSOS: NUNCA `taskkill /IM node.exe` (derruba os MCPs de todas as
-      sessões). Encerre dev server pelo PID que você mesmo subiu. Build e
-      suíte pesados rodam por `morph-spec heavy run -- <comando>`, em primeiro
-      plano. Exit 3 é fila cheia depois da espera da própria fila: não repita
-      nem espere em laço — diga no relatório o que não rodou.
-   7. RETORNO: o relatório no arquivo canônico é o retorno. `SendMessage` não é
-      substituto do relatório e não deve ser chamado.
-   8. MUTAÇÃO: nunca altere, reverta, mova ou apague código de produção para ver
-      um teste falhar (`sed`, `mv`, `git show HEAD:… >`, `git stash`, `git
-      checkout --`). A prova de que o teste morde é do avaliador no Gate 3.
-
-   Formato do relatório:
-     (1) o que foi feito, em 2-3 frases;
-     **Arquivos:** um item `- \`path\`` por arquivo criado ou modificado;
-     **Critérios:** cada doneCriteria — atendido (o teste ou `arquivo:linha` que o
-       prova) ou não atendido (por quê);
-     (4) problemas encontrados e como foram resolvidos.
-   ```
-   **Passo pós-dispatch (seu, ao retomar o controle):** `morph-spec report-check {feature} {taskId} --json`. O veredito do
-   relatório e o bloco `tree` (`dirty`, `diffstat`, `commits`, `markers`) mostram o disco que o agente
-   deixou. Árvore suja sem explicação ou `markers` não vazio: registre no recap. Com
-   `isolation: "worktree"`, depois de ler o relatório rode `morph-spec worktree reap --json`.
-
-   **Leia `3-implement/reports/[ID].md`** — a mensagem de texto do agente é atalho, nunca a fonte.
-   Arquivo ausente é falha de protocolo: registre e complete a partir do que ficou no disco.
-
-   **`PARCIAL` na 1ª linha = a task não está pronta** — o `report-check` o acusa como `report-incomplete`.
-   Retome o MESMO agente por `SendMessage`,
-   colando `tree.dirty`, `tree.commits` e o que falta; ou re-despache só o que falta a partir do
-   último `wip`. Nunca marque `done` sobre um parcial.
-
-5. **Implementação inline.** Siga o standard e a persona. Ambiguidade não coberta pelo plano:
-   registre em `decisions.md` e resolva pelo lado conservador, sem pausar. Testes: as cláusulas 3 e 8
-   do template valem para você também.
-
-   **Task com `3-implement/evidencias/{ID}.md` em `outputs`** (critério sobre saída de LLM): rode o
-   eval antes do `done`, e só ele. Com nó `runner: "evals"`:
-   `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist` — escopo de
-   feature porque no de task o nó `evals` é pulado; `--skip-e2e` porque o stack subiria;
-   `--no-persist` porque esta execução é sonda, não prova de gate. Sem nó `evals`, rode o eval direto
-   e registre "nenhum nó — execução manual". O arquivo traz: o critério (literal), o nó e o cenário,
-   o modelo efetivo, a versão ou o hash do prompt (nunca o prompt cru), entrada e saída sem dado
-   pessoal, e o veredito com a razão. Não é o `reports/{ID}.md`: aquele diz o que o agente fez; este
-   prova, rodando, que a saída atende ao critério.
-
-6. **Recap.** Append em `3-implement/recap.md`:
-   ```markdown
-   ## T{N} — {title}
-
-   **Standard:** {standard-id} (`.morph/framework/standards/{path}.md`)
-   **Persona:** {`morph-{id}` | `general-purpose (fallback: {id})` | `inline ({id})`}
-   **Files:**
-   - `{path}`
-
-   {2-3 frases}
-   ```
-   Sem standard que cubra: `Standard: ad-hoc (see decisions.md ADR-{N})`. O `validate-completion`
-   cobra o bloco.
-
-7. **Audite antes do `done`:** `morph-spec report-check {feature} {taskId} --json`. `report-stale` =
-   relatório completo e velho (a task seguiu escrevendo depois dele): **não re-despache** — leia
-   `observed` (escritas reais, do `events.jsonl`) e atualize o relatório. Demais vereditos:
-   `MORPH.md` §6.
-
-8. Atualizar `tasks.json` marcando a task como `done` (Edit, só campos mutáveis):
-   - `status`: `pending` | `in_progress` | `done` | `skipped` | `blocked`.
-   - `outputs` DEVE listar TODO arquivo criado ou modificado pela task, inclusive artefato auxiliar
-     fora do plano (factory, seed, config gerada). Arquivo em produção sem dono em `outputs` é falha de
-     protocolo que o Gate 3 aponta. Deleções vão em `notes` (string única), nunca em `outputs`.
-   - Divergiu do planejado: o porquê em `notes` na mesma edição — o hook exige.
-
-9. Quando invocada por `morph-apply`, devolva o controle a ela e não rode a suíte do projeto: o `verify {feature} {task}` é do orquestrador. **Única exceção:** a execução de evidência do passo 5, filtrada ao nó `evals`, com `--skip-e2e` e `--no-persist`. No loop por task o recorte é automático (o `group` escolhe as suítes, os testes de `outputs` estreitam o comando; `--filter` só força a escolha de suítes, `--full` desliga o recorte); a suíte inteira roda no Gate 3 e no CI, sem filtro. Invocada manualmente: siga para a próxima task ready.
-
-## Output esperado
-- Código conforme o standard; `3-implement/reports/{taskId}.md` quando despachada
-- `3-implement/evidencias/{taskId}.md` na task que o lista em `outputs`
-- `recap.md` com o bloco da task; `tasks.json` com a task `done`
-- `decisions.md` quando houve decisão não trivial
-
-## Referências
-- `morph-spec standards --find` — passo 2
-- `.morph/framework/MORPH.md` §6 — dispatch e contrato do relatório
-- `.morph/framework/CLI.md`, seção "Suítes de teste" — recorte por task

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

@@ -1,152 +0,0 @@
----
-name: morph-proposal
-description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encadeia morph-brainstorming (Gate 1) e morph-plan (Gate 2). Em trust:auto pula gates sem sinais de risco.
-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.46.0"
----
-
-# morph-proposal
-
-## Objetivo
-
-Conduzir uma feature do request inicial até o plano aprovado (Gate 2), sem intervenção do usuário entre os gates quando `trust: "auto"` e sem sinais de risco.
-
-## Quando invocar
-
-- Usuário pede "use /morph-proposal {feature}" ou "vamos planejar {feature}".
-- Início de qualquer feature nova num projeto morph-spec.
-- Em sessões retomadas, antes de continuar uma feature em progresso, verificar via `.morph/features/{feature-name}/feature.json` (estado autoritativo da feature) se ela já passou pelos Gates.
-
-## Argumentos
-
-- `{feature-name}` — nome em kebab-case da feature. Se ausente, perguntar via `AskUserQuestion`.
-
-## Pré-condições
-
-- `.morph/config/config.json` existe (rode `morph-spec init` antes).
-- Stack está definido (padrão: VSA + .NET 10 + MAF + Next.js + Neon).
-
-## Fluxo
-
-### 0. Roteamento por tipo de trabalho
-
-Antes de qualquer trabalho de negócio, classifique o pedido. Se `{feature-name}` ainda não foi determinado, pergunte via `AskUserQuestion` antes desta chamada (ver Argumentos):
-
-```
-morph-spec create {feature-name} --request "<pedido do usuário>"
-```
-
-(ou `--type <tipo> --description "<o quê/porquê>"` diretamente quando o tipo é óbvio pelo pedido — ex.: o usuário já diz "isso é um hotfix"). O `--request` **serve de semente da descrição**: toda feature nasce com `name` (o slug) e `description` (obrigatória) carimbados. Sem `--request` nem `--description`, o `create` recusa — nada de scaffolds anônimos.
-
-- **Classificação `high` confidence** — a feature nasce com o `workType` decidido pelo detector determinístico (keywords: `hotfix` — "produção caiu/urgente/incident/p0"; `bug` — "bug/corrigir/exception/regressão"; `chore` — "typo/rename/bump/config/docs/cleanup"). Prossiga para o branch correspondente abaixo.
-- **Exit 2** (empate `tie` ou nenhum sinal `none`) — o comando sai sem criar a feature e imprime `{ needsDecision, candidates, matched }`. **Você é o roteador**: decida o tipo entre os candidatos e re-rode com `morph-spec create {feature-name} --type <tipo> --request "<pedido do usuário>"` (o `--request` re-passado carimba a descrição). Só use `AskUserQuestion` para o usuário quando o pedido for genuinamente indeterminado — a maioria dos empates o roteador resolve sozinho pelo contexto da conversa.
-
-**Branches por tipo** (dimensionamento completo em `MORPH.md` §2.1):
-
-- **`hotfix`** → invoque `Skill(morph-hotfix)` passando `{feature-name}` e **ENCERRE** — não siga o restante deste fluxo. A skill cuida de scout, brief, fix cirúrgico, test loop e Gate 3 (sempre humano).
-- **`chore`** → fast-track: os Gates 1 e 2 já nasceram carimbados `policy:chore` no `create`. Escreva um `2-plan/tasks.json` mínimo (1-3 tasks) e invoque `Skill(morph-apply)` diretamente — **exceção documentada** à regra do passo 7 ("não despachar `morph-apply` automaticamente"): não pausar numa mudança óbvia é exatamente o valor do fast-track.
-- **`bug`** → siga para `Skill(morph-brainstorming)` em modo **bug-lean**: produz um `proposal.md` enxuto (repro / diagnóstico / root cause / escopo do fix — não a proposta completa de uma feature nova; **sem critérios de aceite**, que moram na pós-condição do use case) e depois um plano enxuto via `Skill(morph-plan)`. Gates 1 e 2 continuam trust-aware (passos 3 e 6) — só o conteúdo dos artefatos é mais curto.
-- **`feature`** (default — inclui features criadas antes do v8 sem `workType`) → siga o fluxo completo abaixo (passos 1-7): brainstorming → Gate 1 → plan → Gate 2.
-
-### 1. Determinar feature name e estado
-
-- Se argumento ausente: perguntar via `AskUserQuestion` (1 pergunta, header "Feature").
-- Verificar `.morph/features/{feature-name}/`:
-  - Se `0-proposal/proposal.md` existe e tem conteúdo: pular para passo 3.
-  - Caso contrário: rode `morph-spec create {feature-name} --description "<resumo do pedido do usuário>"` — cria `.morph/features/{feature-name}/0-proposal/` e o `feature.json` canônico (shape em `.morph/framework/schemas/feature.schema.json`) num passo só, server-side, com `name`+`description` carimbados. A `--description` é **obrigatória** no nascimento (ou `--request`, que a semeia). Não crie a estrutura à mão nem dependa do nascimento implícito via hook no primeiro Write. Depois siga o passo 2.
-
-### 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 `.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`.
-
-### 3. Gate 1 (trust-aware)
-
-A decisão de pausa já foi tomada e persistida pela `morph-brainstorming` (Parte 4): `morph-spec gate-check {feature} proposal` no caminho comum (`shouldPauseGate`; divergência de design-system detectada entra via `--signals`), ou `gate-decision` manual quando `discoveryMode: "interview"` — o único sinal que `shouldPauseGate` não representa. Leia `gateDecisions.proposal` em `feature.json` (ou o output do comando) para `pause`/`reason`.
-
-**Se `pause === true`**, apresentar via `AskUserQuestion`:
-
-```
-question: "Gate 1 — Proposta de {feature} aprovada? Sinal de risco: {reason}"
-options:
-  - { label: "aprovado, prosseguir", description: "Aceitar a proposta e avançar para o planejamento" }
-  - { label: "preciso ajustar", description: "Apontar mudanças necessárias na proposta" }
-  - { label: "cancelar feature", description: "Abortar — feature não vai avançar" }
-header: "Gate 1"
-```
-
-Aguardar resposta. Se "preciso ajustar", aplicar ajustes e reapresentar o gate.
-
-**Se `pause === false`**, exibir summary curto e prosseguir:
-
-```
-## Gate 1 (auto-aprovado)
-Feature: {nome}
-Problema: {1 frase}
-Escopo: {incluído} | Excluído: {exclusões}
-Stack: {compliance}
-```
-
-No caminho manual, o hook `state-sync.js` registra a aprovação automaticamente via PostToolUse quando a `AskUserQuestion` é respondida com "aprovado" (grava o gate no `feature.json` autoritativo, `approvedBy: "manual"`) — **atribuindo pela feature nomeada na pergunta**; sem o nome, e com mais de uma feature na árvore, ele recusa a gravar e avisa (aprove então por `morph-spec approve {feature} <gate>`). Em `trust: auto` (sem AskUserQuestion), **aprove via CLI — nunca via Edit à mão de state.json**:
-
-```
-morph-spec approve {feature} proposal --mode auto
-# ou, para já aprovar o Gate 1 e criar a pasta 2-plan/ num passo só:
-morph-spec advance {feature}
-```
-
-### 3a. Roteamento uiux (após o Gate 1)
-
-Critério objetivo em `MORPH.md` §2.1: a mudança cria ou altera superfície de UI (componente, página, tela, estilo, fluxo de navegação)?
-
-- **Sim** → em vez do `advance {feature}` do passo 3, rode `morph-spec advance {feature} --design` (cria `1-design/`) e invoque `Skill(morph-uiux)`. Ela conduz a fase de design e, com o Gate uiux aprovado, devolve o controle aqui — siga para o passo 4.
-- **Não** → nenhuma ação extra; o `advance {feature}` do passo 3 já criou `2-plan/` direto.
-
-### 4. Verificar retomada antes de morph-plan
-
-- Se `.morph/features/{feature}/2-plan/spec.md` já existe: pular para passo 6 (Gate 2).
-
-### 5. Invocar `Skill(morph-plan)`
-
-A skill lê `proposal.md` e produz:
-- `usecases/UC-*.md` — o comportamento, com pós-condições testáveis
-- `spec.md` — especificação técnica, com a seção `## Contrato de implementação`
-- `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)
-
-Mesma mecânica do passo 3: a decisão já foi tomada e persistida pela `morph-plan` (passo 6) — `morph-spec gate-check {feature} plan` no caminho comum (`shouldPauseGate` sobre `taskCount` do disco; `designSystemDivergence`/`standardsViolations` via `--signals` quando aplicável — não são herdados automaticamente entre gates), ou `gate-decision` manual para risco que nenhuma dessas chaves representa. Leia `gateDecisions.plan` para `pause`/`reason` e apresente com o mesmo template (AskUserQuestion ou auto-aprovação) do passo 3.
-
-### 7. Conclusão
-
-- Sinalizar ao usuário: "Plano aprovado. Rode `/morph-apply {feature}` (ou peça 'implementar {feature}') para iniciar a execução."
-- Não dispachar `morph-apply` automaticamente — usuário decide quando começar.
-
-## Anti-padrões
-
-- Não pular o Gate 1 mesmo em trust:auto se houver divergência detectada.
-- Não escrever código nesta fase — apenas artefatos de planejamento.
-- Não perguntar sobre stack — o stack padrão está em MORPH.md.
-- Não rodar o pipeline completo de 5 fases num `chore` ou `bug` óbvio — o Passo 0 existe para dimensionar o trabalho pelo `workType`, não para ser pulado "para simplificar".
-
-## Output esperado
-
-- `.morph/features/{feature}/0-proposal/proposal.md`
-- `.morph/features/{feature}/1-design/` (se o ramo uiux — passo 3a — foi tomado)
-- `.morph/features/{feature}/2-plan/spec.md`
-- `.morph/features/{feature}/2-plan/tasks.json`
-- Gates 1 e 2 registrados aprovados em `.morph/features/{feature}/feature.json` (autoritativo) — via `morph-spec approve`/`morph-spec advance` em auto, ou via hook state-sync no caminho manual.
-
-## Referências
-
-- `.morph/framework/MORPH.md` — charter NLH completo
-- `.morph/framework/MORPH.md` §2.1 — roteamento por tipo de trabalho (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)