@polymorphism-tech/morph-spec 8.47.0 → 9.1.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_use: Use quando for iniciar cada task de implementação listada em tasks.json
-user-invocable: false
-cliVersion: "8.47.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_use: Use quando o usuário pedir "use /morph-proposal" ou ao iniciar uma nova feature
-user-invocable: true
-cliVersion: "8.47.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)

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

@@ -1,145 +0,0 @@
----
-name: morph-stack-scan
-description: Varre o codebase existente, detecta stack atual, compara com o stack padrão e registra desvios em stack-scan.md
-version: core
-when_to_use: Use quando uma feature começar em projeto brownfield (codebase já existente)
-user-invocable: true
-cliVersion: "8.47.0"
----
-
-# morph-stack-scan
-
-## Objetivo
-Identificar o estado real do codebase antes de planejar qualquer feature — garantindo que a implementação não adicione inconsistência a um projeto já existente.
-
-## Quando invocar
-Quando o projeto já tem código existente e você precisa entender o estado atual antes de propor uma feature. Normalmente invocado pelo morph-brainstorming, mas pode ser invocado diretamente.
-
-## Stack padrão de referência
-
-O "Esperado" da comparação do passo 2 é o stack baked-in (runtime .NET 10 + VSA, EF Core/Neon, `Guid.CreateVersion7()`, `sealed`, result pattern, MAF, Next.js/Tailwind/Shadcn, Hangfire) e a lista de padrões proibidos (`Guid.NewGuid()`, classes não-sealed, Service/Manager layer, repository genérico, SQL cru sem justificativa) — regra canônica em `MORPH.md` § "Stack baked-in". Os templates de `stack-scan.md` abaixo (greenfield e brownfield) escrevem essa lista por extenso no artefato da feature, para que quem ler o `stack-scan.md` depois não precise reabrir o `MORPH.md`.
-
-## Greenfield short-circuit
-
-Antes de despachar Explore, verifique se o projeto é greenfield:
-
-1. Use `Glob` para detectar presença de qualquer um destes:
-   - `**/*.csproj`
-   - `**/*.sln`
-   - `package.json` (na raiz)
-   - `src/**/*.cs` ou `src/**/*.ts` ou `src/**/*.tsx`
-   - `migrations/**/*`
-
-2. Se **nenhum** for encontrado, o projeto é greenfield. Produza este `stack-scan.md` em `.morph/features/{feature}/0-proposal/` e retorne sem chamar Explore:
-
-   ```markdown
-   # Stack Scan — {feature}
-
-   **Status:** GREENFIELD (sem código source detectado)
-
-   ## Stack
-   Project empty. Aplicar stack padrão de MORPH.md:
-   - Backend: .NET 10 + VSA + EF Core + Neon
-   - Frontend: Next.js App Router + Tailwind + Shadcn + Framer Motion
-   - IA: MAF (quando aplicável à feature)
-   - Jobs: Hangfire (apenas se necessário)
-
-   ## Padrões obrigatórios
-   - IDs: `Guid.CreateVersion7()`
-   - Classes: `sealed` por padrão
-   - Erros: Result pattern (`result.Match()`)
-
-   ## Padrões proibidos
-   `Guid.NewGuid()`, 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. Acesso a dados em VSA: `ApplicationDbContext` direto no slice (`DbSet<T>` já é repository, `DbContext` já é unit of work); para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
-
-   ## Recomendação
-   Compliance trivial (greenfield). Prosseguir para morph-brainstorming.
-   ```
-
-3. Se algum dos arquivos foi encontrado, o projeto é brownfield — siga para o passo seguinte.
-
-## O que fazer (brownfield)
-
-0. **Se houver grafo, ele responde a pergunta do repository genérico melhor que o grep.**
-
-   ```bash
-   morph-spec graph status --json                        # available:false? pule este passo
-   morph-spec graph affected IRepository --uses-only --json
-   morph-spec graph explain IRepository --json           # o registro no DI aparece aqui
-   ```
-
-   A pergunta do passo 1 é *"quantos CONSUMIDORES REAIS"*, e é exatamente aí que o grep erra: no ProspectPRO ele aponta **23 arquivos**, mas 20 são interfaces filhas **herdando** o contrato e só **2** são uso real. Quem lê 23 conclui "está em uso, não é código morto" — e a conclusão certa é a oposta. `--uses-only` exclui `inherits`/`implements`/`extends` e devolve os 2. O `explain` do mesmo símbolo entrega de brinde a outra metade da pergunta: onde ele está registrado no DI.
-
-   **Fallback:** grafo ausente (`no-graph`), símbolo não encontrado ou ambíguo — siga com o `Explore` e o grep do passo 1, e **registre no `stack-scan.md` que a contagem veio do grep**, que superestima consumidores por não separar herança de uso.
-
-1. Despache um `Explore` subagent para varrer o codebase:
-
-   ```
-   Varredura de stack compliance — morph-stack-scan.
-
-   Leia os seguintes arquivos/pastas e reporte o que encontrar:
-
-   BACKEND:
-   - Todos os .csproj: qual TargetFramework? Quais PackageReferences relevantes?
-   - Procure por: Guid.NewGuid() vs Guid.CreateVersion7(), sealed classes, result pattern vs exceptions
-   - Estrutura de src/: segue feature-folder (VSA)? Tem Controllers? Tem repository genérico (IRepository<T>/IUnitOfWork)? Se tiver, reporte como código morto: liste onde está registrado no DI e quantos consumidores reais existem em src/ e tests/
-   - Migrations/: qual ORM? Neon/Postgres ou outro banco?
-   - Microsoft.Agents.* ou Microsoft.Extensions.AI nos PackageReferences?
-
-   FRONTEND:
-   - package.json: Next.js? Tailwind? Framer Motion? Shadcn/ui?
-   - Estrutura de app/ ou pages/: App Router ou Pages Router?
-
-   JOBS:
-   - Hangfire nos PackageReferences?
-
-   Para cada item acima, responda: presente/ausente, e se presente qual versão ou padrão.
-   Não faça sugestões — apenas reporte o que existe.
-   ```
-
-2. Com os resultados da varredura, compare com o stack padrão item por item e classifique cada desvio:
-
-   | Severidade | Critério |
-   |------------|---------|
-   | **Bloqueante** | Runtime diferente (.NET 8 ou anterior), ORM diferente (Dapper puro sem EF Core), banco diferente (MySQL, SQL Server) |
-   | **Alto** | `Guid.NewGuid()` generalizado, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`) presente — código morto: migração é deletar a pasta `Repository/` + as 2 linhas de DI, SQL cru generalizado, exceptions como fluxo de controle |
-   | **Médio** | Classes não-sealed, Pages Router em vez de App Router, biblioteca de UI diferente |
-   | **Baixo** | Versões de pacotes desatualizadas mas compatíveis |
-
-3. Produza `stack-scan.md` em `.morph/features/{feature}/0-proposal/`:
-
-   ```markdown
-   # Stack Scan — {feature}
-
-   ## Resultado
-   {Em compliance / Desvios detectados}
-
-   ## Stack detectado
-   | Camada | Detectado | Esperado | Status |
-   |--------|-----------|----------|--------|
-   | Runtime | .NET X | .NET 10 | ✓ / ✗ |
-   ...
-
-   ## Desvios (ordenados por severidade)
-   ### Bloqueantes
-   - {desvio}: {onde foi encontrado} — impacto: {o que quebra se não migrar} — esforço: {estimativa}
-
-   ### Não bloqueantes
-   - {desvio}: {onde foi encontrado} — migração: {como resolver} — esforço: {estimativa}
-
-   ## Recomendação
-   {Em compliance — prosseguir para morph-brainstorming}
-   {ou: Migração necessária antes de prosseguir — ver Desvios acima}
-   ```
-
-4. Se houver desvios bloqueantes ou altos, pergunte via `AskUserQuestion`: "Esta migração deve ser incluída na feature atual ou tratada numa feature separada?" A resposta é decisão humana — registre-a na seção "Compliance de stack" do `proposal.md` (produzido pela `morph-brainstorming`), não num artefato novo: a lista de desvios com impacto/esforço já vive no `stack-scan.md` acima.
-
-5. Se não houver desvios (ou apenas baixos): informe "codebase em compliance com o stack padrão" e prossiga para morph-brainstorming ou morph-plan conforme o contexto.
-
-## Output esperado
-- `.morph/features/{feature}/0-proposal/stack-scan.md` — resultado da varredura, com desvios ordenados por severidade e esforço estimado
-- Decisão documentada: incluir migração nesta feature ou separar (registrada no proposal.md pela morph-brainstorming)
-
-## Referências
-- `.morph/framework/MORPH.md` — seção 4 (Standards), seção 2 (Fases)
-- `.claude/skills/morph-brainstorming/SKILL.md` — fluxo greenfield/brownfield