@polymorphism-tech/morph-spec 8.47.0 → 9.1.0

package/framework/rules/morph-workflow.md

@@ -1,244 +0,0 @@
----
-stacks:
-  - "*"
----
-
-# MORPH-SPEC Workflow Rules
-
-> Always-active rules for all MORPH-SPEC managed projects.
-
----
-
-## Spec-First Mandate
-
-**NEVER skip to code without a specification.** Every feature must progress through phases:
-
-1. **Proposal** — Problem statement + scope + risks (`0-proposal/proposal.md`). No acceptance criteria: verifiable behaviour lives in the use cases.
-2. **UI/UX Design** (optional, UI-heavy) — Design system + mockups + flows. The phase id is `uiux` (that is the gate name); the folder is `1-design/`
-3. **Plan** — Use cases first, then technical spec + tasks (`2-plan/usecases/UC-{nn}-{slug}.md`, `spec.md`, `tasks.json`). Each use case post-condition must be observable in a test and reaches the task's `doneCriteria` verbatim.
-4. **Implement** — Code + recap (`3-implement/recap.md`)
-5. **Review** — Review report + Gate 3 (`4-review/review-report.md`)
-
----
-
-## Phase Sequence
-
-```
-proposal → [uiux] → plan → implement → review
-```
-
-Use `morph-spec status {feature}` to see current phase and pending approval gates.
-
----
-
-## Phase Commands
-
-| Command | Purpose |
-|---------|---------|
-| `/morph-proposal {feature}` | Business understanding + plan — pauses at Gate 1 and Gate 2 |
-| `/morph-apply {feature}` | Autonomous execution + review — pauses at Gate 3 |
-| `/morph-status` | Feature dashboard |
-
-The full slash-command and CLI surface lives in the resident `.claude/CLAUDE.md` and in
-`.morph/framework/CLI.md` — this table only carries the three phase entry points.
-
----
-
-## State & Outputs
-
-| Path | Notes |
-|------|-------|
-| `.morph/features/{feature}/feature.json` | **Authoritative + committed** feature state. Write it through the CLI (`create`, `gate-decision`, `gate-check`, `approve`) — a hand Edit collides with the `state-sync` hook |
-| `.morph/state.json` | **READ-ONLY** — thin, gitignored index rebuilt from `feature.json` on load; kept in sync by the `state-sync` hook |
-| `.morph/features/{feature}/{phase}/` | Feature outputs organized by phase |
-| `.morph/framework/` | **READ-ONLY** — framework files managed by morph-spec |
-| `.morph/config/config.json` | Project configuration (editable) |
-
-### output types
-
-The canonical filename and phase folder of every output type are fixed by
-morph-spec itself — the concrete paths are in the table below. State sync is
-handled automatically by the `state-sync.js` PostToolUse hook: write the file
-at the right path and it is recorded; the agent does not call any CLI to
-register an output.
-
----
-
-## Output Paths
-
-All outputs go in `.morph/features/{feature}/`:
-
-| Phase | Path |
-|-------|------|
-| Proposal | `0-proposal/proposal.md`, `stack-scan.md` |
-| Design (optional) | `1-design/design-system.md`, `mockups.md`, `components.md`, `flows.md` |
-| Plan | `2-plan/usecases/`, `spec.md`, `tasks.json`, `decisions.md` |
-| Implement | `3-implement/recap.md` + source code; `3-implement/evidencias/{taskId}.md` (condicional — task cujo `doneCriteria` julga saída de LLM) |
-| Review | `4-review/review-report.md` |
-
----
-
-## Formato obrigatório do `3-implement/recap.md`
-
-> Esta exigência é **cobrada por hook** (`validate-completion`, no Stop). Ela está aqui, na regra
-> sempre-ativa, e não só na skill `morph-implement`: descobrir o formato quando o hook dispara
-> significa reescrever o recap depois de a fase já estar dada por encerrada.
-
-**Para CADA task com `status: "done"` em `tasks.json`**, o recap precisa de um bloco próprio:
-
-1. um heading `## T{N}` (o hook casa `^## T\d+` — uma linha de tabela `| T1 | … | done |` conta
-   como menção, **não** como bloco);
-2. uma linha `**Standard:** {standard-id}` **dentro de 12 linhas** do heading. Sem standard que
-   cubra o caso, registre a decisão em `decisions.md` e cite
-   `**Standard:** ad-hoc (see decisions.md ADR-{N})`.
-
-```markdown
-## T{N} — {title}
-
-**Standard:** {standard-id} (`.morph/framework/standards/{path}.md`)
-**Persona:** {mecanismo real usado}
-**Files:**
-- `{path}`
-
-{2-3 frases sobre o que foi feito}
-
-**Issues encontrados:** {breve descrição ou "nenhum"}
-```
-
-O `validate-completion` também acusa **drift**: uma task que aparece como concluída no recap mas
-ainda está `pending`/`in_progress` no `tasks.json`. Template completo e regras de exceção em
-`morph-implement` §6.
-
----
-
-## Checkpoints
-
-Run a checkpoint every 3 completed tasks:
-- Validate architecture compliance
-- Check package versions
-- Scan for security issues
-- Verify design system adherence (UI features)
-
----
-
-## Approval Gates
-
-Before completing any phase, verify pending approval gates:
-- `morph-spec approval-status <feature>` — check which gates are pending
-- `morph-spec approve <feature> <gate>` — approve a gate (`proposal`, `plan`, `review`; `uiux` if applicable)
-- `morph-spec advance <feature>` — approve the current gate AND scaffold the next phase folder in one step
-- Gates must be approved before advancing to the next phase
-
----
-
-## Protected Files
-
-**NEVER directly edit:**
-- `.morph/state.json` — Managed by CLI only
-- `.morph/framework/**` — Read-only framework content
-
----
-
-## Test File Policy
-
-When a test fails, always follow this order:
-
-1. **Analyze first** — determine if the IMPLEMENTATION is wrong or the TEST SPEC is wrong
-2. **Fix implementation first** — the test is the spec; trust it by default
-3. **Only modify a test file if the test expectation itself is incorrect** — wrong expected value, wrong behavior modeled
-4. **Before modifying any test file, explain WHY the test spec is wrong** — what the correct behavior is and why the test doesn't model it
-
-Do not modify test files to make a failing test pass when the implementation is the actual problem.
-
----
-
-## Context Maintenance
-
-After making structural changes (new packages, dependencies, project config changes), update the project context:
-- Edit `.morph/context/README.md` — update Tech Stack, Architecture, Key Integrations sections
-- Any `.morph/context/*.md`: **rewrite the body, never stack** — the section that described the old fact now describes the new one (a value that still holds somewhere says where); a changelog keeps only date and reason
-- Update `.morph/config/config.json` — update stack, architecture, integrations, paths
-- Structural changes include: package.json, .csproj, next.config.*, tsconfig.json, docker-compose.yml
-
----
-
-## Spec-Driven Task Execution (implement phase)
-
-BEFORE implementing ANY task during the implement phase:
-
-1. **Read tasks.json** → identify the current task object (`id`, `description`, `doneCriteria`, `dependencies`)
-2. **Read spec.md** → the FR sections that the task `description` references
-3. **Read the contracts** → the DTOs/interfaces are defined inside `spec.md` (v5 keeps contracts in the spec, not separate files)
-4. Only then begin implementation
-
-This is **NON-NEGOTIABLE**. The spec is the source of truth. Code that doesn't match the spec is a bug.
-
-Every task in `tasks.json` MUST reference its FR(s) in the `description` field so the link to the spec is explicit:
-```json
-{
-  "id": "T1",
-  "title": "Create user endpoint",
-  "description": "Implement user CRUD (FR001) and input validation (FR003). Contracts: CreateUserRequest, CreateUserResponse, UserErrors.",
-  "dependencies": [],
-  "effort": "M",
-  "doneCriteria": "POST /users creates a user and rejects invalid input",
-  "status": "pending",
-  "outputs": ["Features/UserFeature/Create/Handler.cs", "Validator.cs", "Endpoint.cs"],
-  "group": "backend"
-}
-```
-
----
-
-## Debugging
-
-When a bug or unexpected behavior shows up mid-task, find the **root cause before proposing a
-fix** — never a patch on the symptom. This is MANDATORY:
-
-1. Reproduce it and read the full error, not the first line.
-2. For a known .NET/Next.js error, run `/morph-troubleshoot <keywords>` first.
-3. One hypothesis at a time, each tested by the smallest check that could refute it.
-4. After three failed fixes, never try a fourth on your own: escalate via `AskUserQuestion` (accept / keep trying / skip), bringing the design question the failures raise — a fourth attempt with no new information repeats the error (same rule as MORPH.md §0).
-5. Confirm the fix with the same check that reproduced the bug; add a test only when no existing one covers that behavior.
-
-Everything else that a rule like this might list is owned by the flow itself, and duplicating it
-here would put a second, staler copy in permanent context:
-
-| Concern | Where it actually lives |
-|---------|-------------------------|
-| How many tests to write | The test budget in `morph-plan` §5: one test per postcondition, same-behavior cases in one table, no test that only pins text |
-| Verifying a task before `status: "done"` | `morph-spec verify {feature} [task]` (build + tests + validators + e2e) green, and each `doneCriteria` with the test or `file:line` that proves it |
-| Parallel dispatch | `morph-spec dag {feature}` decides sequential vs parallel; execution and isolation rules are in `morph-apply` §2/§3b |
-| Closing the phase / opening the PR | `morph-review` for Gate 3, then `morph-spec finish {feature} --pr\|--merge` |
-
----
-
-## Scope Escalation
-
-The plan contract frozen at Gate 2 — `spec.md` and the immutable `tasks.json`
-fields listed in `morph-task-tracking.md` — is enforced by the `protect-spec-files` hook. When a
-task turns out to be bigger than estimated, three different situations resolve three different ways:
-
-| Situation | Path |
-|-----------|------|
-| **Small addition**, still inside the task's scope | Record it in the task's `notes` (a mutable field) — no gate to revoke, no contract to amend |
-| **Error of fact**: the spec asserts something about the code that the code contradicts, with no scope change | Append an `## Errata` block at the END of the file. Body untouched, append-only, accepted by `protect-spec-files` **without revoking the gate** — freezing the CONTRACT is not freezing an ERROR OF FACT (MORPH.md §3) |
-| **The scope itself changed**: the contract no longer describes the work | `morph-spec unapprove {feature} plan --reason "..."`, amend the plan, then re-approve. There is no shortcut around the gate for this one |
-
-Scope ambiguity the plan does not cover is **not** an escalation: record it in
-`decisions.md`, resolve it the conservative way, and keep going — only pause if it is genuinely
-blocking (`morph-implement` §5).
-
-**Never** implement extra functionality within a task without registering it — `notes` for small
-additions, gate revocation for anything that changes the plan contract.
-
----
-
-## Context Window Tip
-
-When using 3+ MCPs, add `"experimental": { "mcpCliMode": true }` to `.claude/settings.json`.
-MCP tools load on-demand instead of all at startup — keeps context clean for actual work.
-
----
-
-*MORPH-SPEC by Polymorphism Tech*

package/framework/schemas/tasks.schema.json

@@ -1,79 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "MORPH-SPEC tasks.json",
-  "description": "Structured task list for a morph-spec feature. Replaces tasks.md.",
-  "type": "object",
-  "required": ["version", "feature", "tasks"],
-  "properties": {
-    "version": { "type": "string", "const": "1.0" },
-    "feature": { "type": "string", "minLength": 1 },
-    "tasks": {
-      "type": "array",
-      "items": {
-        "type": "object",
-        "required": ["id", "title", "description", "dependencies", "effort", "doneCriteria", "status"],
-        "properties": {
-          "id": { "type": "string", "pattern": "^T\\d+$" },
-          "title": { "type": "string", "minLength": 1 },
-          "description": { "type": "string", "minLength": 1 },
-          "dependencies": {
-            "type": "array",
-            "items": { "type": "string", "pattern": "^T\\d+$" }
-          },
-          "effort": { "type": "string", "enum": ["S", "M", "L", "XL"] },
-          "doneCriteria": { "type": "string", "minLength": 1 },
-          "status": { "type": "string", "enum": ["pending", "in_progress", "done", "skipped", "blocked"] },
-          "outputs": { "type": "array", "items": { "type": "string" } },
-          "notes": { "type": "string" },
-          "group": { "type": "string", "enum": ["backend", "frontend", "tests", "infra", "docs"] },
-          "usecase": {
-            "type": "string",
-            "pattern": "^UC-\\d+$",
-            "description": "ID of the use case this task realizes (2-plan/usecases/UC-{nn}-{slug}.md). Optional: technical tasks with no observable behaviour have none."
-          },
-          "agent": {
-            "type": "string",
-            "minLength": 1,
-            "description": "Persona id assigned by morph-plan for this task — the bare framework/agents.json id, no 'morph-' prefix (e.g. \"dotnet-senior\"). Optional. Part of the plan contract: frozen after Gate 2."
-          },
-          "reuse": {
-            "type": "array",
-            "description": "Veredito de reuso por conceito que ESTA task introduz, carimbado por morph-plan. Optional. Part of the plan contract: frozen after Gate 2.",
-            "items": {
-              "type": "object",
-              "required": ["concept", "verdict"],
-              "properties": {
-                "concept": {
-                  "type": "string",
-                  "minLength": 1,
-                  "description": "Nome do conceito/símbolo, como ele aparecerá no código (ex.: \"SimpleBuilding\")."
-                },
-                "verdict": {
-                  "type": "string",
-                  "enum": ["REUSAR", "ESTENDER", "CRIAR"],
-                  "description": "REUSAR: usar o que existe. ESTENDER: partir do que existe. CRIAR: nada cobre o caso — exige `why`."
-                },
-                "target": {
-                  "type": "string",
-                  "description": "Path (ou path:símbolo) do que será reusado/estendido. Vazio ou ausente em CRIAR."
-                },
-                "why": {
-                  "type": "string",
-                  "description": "Uma linha: por que nada existente cobre o caso. Exigido em CRIAR."
-                }
-              },
-              "additionalProperties": false
-            }
-          },
-          "standards": {
-            "type": "array",
-            "items": { "type": "string", "minLength": 1 },
-            "description": "Standards pinned by morph-plan for this task, as PATHS relative to the framework root (e.g. \"standards/backend/dotnet/vsa-handler-patterns.md\"). Optional. Part of the plan contract: frozen after Gate 2. NOT the same vocabulary as agents.json's top-level `standards` field, which lists IDs (e.g. \"backend-dotnet-vsa-handler-patterns\", no slashes/extension) — same field name, different shape; do not treat one as the other."
-          }
-        },
-        "additionalProperties": false
-      }
-    }
-  },
-  "additionalProperties": false
-}

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_use: Use quando chegar um novo request de feature, antes de morph-plan
-user-invocable: true
-cliVersion: "8.47.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