@polymorphism-tech/morph-spec 8.3.0 → 8.4.0

package/README.md

@@ -3,7 +3,7 @@
 > Spec-driven development framework for multi-stack projects. Turns feature requests into implementation-ready code through structured, AI-orchestrated phases.
 
 **Package:** `@polymorphism-tech/morph-spec`
-**Version:** 8.3.0  
+**Version:** 8.4.0  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -184,8 +184,8 @@ morph-spec verify {feature} [task]     # Deterministic build+tests+validators ch
 ### Work-type routing
 
 ```bash
-morph-spec create {feature} --type feature|bug|chore|hotfix   # Explicit birth: type dimensions the pipeline
-morph-spec create {feature} --request "<free text>"           # Deterministic detector classifies the type
+morph-spec create {feature} --type feature|bug|chore|hotfix --description "<what/why>"   # Explicit birth: type dimensions the pipeline, description is required
+morph-spec create {feature} --request "<free text>"           # Detector classifies the type AND seeds the description
 morph-spec retype {feature} {newType}                          # Change work type mid-flight (blocked after Gate 3)
 morph-spec dag {feature} [--mermaid]                            # DAG dispatch decision; --mermaid emits a flowchart
 ```
@@ -193,7 +193,7 @@ morph-spec dag {feature} [--mermaid]                            # DAG dispatch d
 ### Worktrees (parallel development)
 
 ```bash
-morph-spec create {feature} --worktree   # Birth the feature already isolated in its own worktree
+morph-spec create {feature} --description "<what/why>" --worktree   # Birth the feature already isolated in its own worktree
 morph-spec worktree setup {feature}      # Create .worktrees/{feature}/ on branch morph/{feature}
 morph-spec worktree link [--all]         # Relink shared infra (node_modules, .claude, .morph/framework)
 morph-spec worktree finish {feature}     # Merge --no-ff back to the primary root, clean up (requires Gate 3)
@@ -365,4 +365,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v8.3.0 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v8.4.0 by [Polymorphism Tech](https://polymorphism.tech)*

package/bin/morph-spec.js

@@ -35,6 +35,8 @@ import { gateDecisionCommand } from '../src/commands/state/gate-decision.js';
 import { createCommand } from '../src/commands/state/create.js';
 import { retypeCommand } from '../src/commands/state/retype.js';
 import { handoffCommand } from '../src/commands/state/handoff.js';
+import { listCommand } from '../src/commands/state/list.js';
+import { deleteCommand } from '../src/commands/state/delete.js';
 
 // === Tasks ===
 import { dagCommand } from '../src/commands/tasks/dag.js';
@@ -126,13 +128,22 @@ program
   .option('-v, --verbose', 'Show detailed output')
   .action(statusCommand);
 
+program
+  .command('list')
+  .description('List every feature × status × gates (G1/G2/G3) × workType — the audit board')
+  .option('--all', 'Include archived features (.morph/archive)')
+  .option('--archived', 'Include archived features (alias of --all)')
+  .option('--json', 'Output as JSON')
+  .action((options) => listCommand(options));
+
 // ─── Approval gates (dev-only) ────────────────────────────────────────────
 program
   .command('approve <feature> <gate>')
-  .description('Approve a phase gate (proposal, plan, review)')
+  .description('Approve a phase gate (proposal, plan, review). Enforces gate order (N requires N-1)')
   .option('--approver <name>', 'Name of approver (default: current user when interactive, "auto" otherwise)')
   .option('--mode <mode>', 'Approval mode: "user" or "auto" (default: detected from TTY)')
   .option('--notes <notes>', 'Approval notes')
+  .option('--force', 'Approve out of order (bypass the gate-monotonicity check)')
   .action((feature, gate, options) => approveCommand(feature, gate, options));
 
 program
@@ -142,6 +153,7 @@ program
   .option('--mode <mode>', 'Approval mode: "user" or "auto" (default: detected from TTY)')
   .option('--design', 'From proposal, advance into the optional design (uiux) phase instead of plan')
   .option('--notes <notes>', 'Approval notes')
+  .option('--force', 'Advance even if a prerequisite gate is unapproved (out-of-order recovery)')
   .action((feature, options) => advanceCommand(feature, options));
 
 program
@@ -151,6 +163,15 @@ program
   .option('--force', 'Archive even if Gate 3 (review) is not approved')
   .action((feature, options) => archiveCommand(feature, options));
 
+program
+  .command('delete <feature>')
+  .description('Delete a feature (hard by default; --archive marks it abandoned). Refuses if a gate is approved unless --force')
+  .option('--archive', 'Soft delete: move to .morph/archive with status "abandoned" instead of removing')
+  .option('--force', 'Delete even when a gate is approved')
+  .option('--no-git', 'Skip git staging of the removal')
+  .option('--json', 'Output as JSON')
+  .action((feature, options) => deleteCommand(feature, options));
+
 program
   .command('approval-status <feature>')
   .description('Show approval status for all gates')
@@ -178,6 +199,8 @@ program
 program
   .command('create <feature>')
   .description('Classify work type (--type/--request), scaffold + stamp policy gates, and create the canonical feature.json (explicit birth — see framework/schemas/feature.schema.json)')
+  .option('--name <name>', 'Human-readable feature name (default: the slug)')
+  .option('--description <text>', 'What/why of the feature — required at birth unless --request is given (it seeds the description)')
   .option('--status <status>', 'Initial feature status (default: in_progress)')
   .option('--type <type>', 'Work type: feature|bug|chore|hotfix (default: feature) — see src/core/work-types.js')
   .option('--request <text>', 'Free-text request classified by the deterministic detector; tie/none exits 2 with candidates for an LLM/user decision (feature NOT created)')

package/claude-plugin.json

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

package/docs/CHEATSHEET.md

@@ -68,9 +68,11 @@ morph-spec archive {feature} [--force] [--no-git]
 
 Every feature is born with a **work type** that dimensions its pipeline: `feature` (full proposal → [uiux] → plan → implement → review), `bug` (lean), `chore` (fast-track straight to implement), `hotfix` (scout → surgical fix → human Gate 3 always, even under `trust: auto`).
 
+Every feature is also born with an **identity**: `--description` is required (`create` refuses a nameless scaffold without it), `name` defaults to the slug.
+
 ```bash
-morph-spec create {feature} --type feature|bug|chore|hotfix
-morph-spec create {feature} --request "<free text>"      # deterministic detector classifies the type
+morph-spec create {feature} --type feature|bug|chore|hotfix --description "<what/why>"
+morph-spec create {feature} --request "<free text>"       # detector classifies the type AND seeds the description
 morph-spec retype {feature} {newType}                     # change type mid-flight (blocked after Gate 3)
 ```
 
@@ -111,7 +113,7 @@ morph-spec dag {feature} --mermaid         # emit the tasks.json DAG as a Mermai
 One feature = one git worktree = one Claude Code instance. Each worktree gets its own deterministic port block (`.morph/worktree.env`) and a regenerable handoff document.
 
 ```bash
-morph-spec create {feature} --worktree     # birth the feature already isolated in its own worktree
+morph-spec create {feature} --description "<what/why>" --worktree   # birth the feature already isolated in its own worktree
 morph-spec worktree setup {feature}        # create .worktrees/{feature}/ on branch morph/{feature}
 morph-spec worktree link [--all]           # relink shared infra (node_modules[, .claude, .morph/framework])
 morph-spec worktree finish {feature}       # merge --no-ff back to the primary root, clean up + release ports (requires Gate 3)
@@ -180,4 +182,4 @@ Never edited directly — go through CLI commands or `morph-spec update` instead
 
 ---
 
-*morph-spec v8.3.0 by Polymorphism Tech*
+*morph-spec v8.4.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -129,14 +129,20 @@ morph-spec verify my-feature T001      # scoped to one task
 
 Not every change needs the full pipeline walked above. Every feature is born with a **work type** that dimensions its pipeline:
 
+Every feature is also born with an **identity** — a `--description` (the one field a human must supply; `create` refuses a nameless scaffold without it) and a `name` (defaults to the slug):
+
 ```bash
-morph-spec create my-feature --type feature   # default: full proposal → [uiux] → plan → implement → review
-morph-spec create my-fix --type bug           # lean proposal/plan
-morph-spec create my-chore --type chore       # skips straight to implement (Gates 1/2 stamped by policy)
-morph-spec create my-hotfix --type hotfix     # scout → surgical fix → test loop; Gate 3 always pauses for a human
+# full: proposal → [uiux] → plan → implement → review
+morph-spec create my-feature --type feature --description "what & why"
+# bug: lean proposal/plan
+morph-spec create my-fix --type bug --description "what broke"
+# chore: skips straight to implement (Gates 1/2 stamped by policy)
+morph-spec create my-chore --type chore --description "the tidy-up"
+# hotfix: scout → surgical fix → test loop; Gate 3 always pauses for a human
+morph-spec create my-hotfix --type hotfix --description "the incident"
 ```
 
-You can also let the deterministic detector classify a free-text request instead of picking a type by hand:
+You can also let the deterministic detector classify a free-text request instead of picking a type by hand (`--request` doubles as the description):
 
 ```bash
 morph-spec create my-feature --request "produção caiu, corrigir urgente"
@@ -157,7 +163,7 @@ Production incidents run through the dedicated `/morph-hotfix my-feature` slash
 Independent features can be developed in parallel, each isolated in its own git worktree — one feature, one worktree, one Claude Code instance:
 
 ```bash
-morph-spec create my-feature --worktree      # birth the feature already isolated
+morph-spec create my-feature --description "what & why" --worktree   # birth the feature already isolated
 # or, for an existing feature:
 morph-spec worktree setup my-feature         # creates .worktrees/my-feature/ on branch morph/my-feature
 ```
@@ -240,4 +246,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v8.3.0 by Polymorphism Tech*
+*morph-spec v8.4.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -47,7 +47,9 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - `morph-spec dag <feature>` — análise do DAG de tasks.json com decisão sequencial vs paralelo **ponderada por effort** (raízes S vão inline, nunca ganham agente próprio).
 - `morph-spec score <feature> <task> <score> [--dims a,c,q,t]` — grava `taskScores` no feature.json com timestamp server-side; **nunca edite taskScores à mão**. Em PowerShell, cite o valor de `--dims` entre aspas (`--dims "9.5,9,9,9"`) — sem aspas, a lista pode chegar como tokens separados; o parser aceita ambas as formas, mas citar evita qualquer ambiguidade.
 - `morph-spec gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]` — grava `gateDecisions` no feature.json com timestamp server-side (shape em `framework/schemas/feature.schema.json`); **nunca edite gateDecisions à mão** — o Edit manual colide com o hook state-sync.
-- `morph-spec create <feature> --type <feature|bug|chore|hotfix> [--request "<txt>"] [--worktree]` — cria a estrutura da feature + `feature.json` canônico explicitamente (nascimento explícito no início da proposal; o hook state-sync continua cobrindo o caminho implícito como fallback). `--type` classifica direto; `--request "<pedido>"` roda o detector determinístico (empate/sem sinal sai com exit 2 e candidatos — a LLM decide e re-roda com `--type`); `--worktree` já nasce a feature no seu worktree próprio.
+- `morph-spec create <feature> --description "<o quê/porquê>" --type <feature|bug|chore|hotfix> [--request "<txt>"] [--name "<nome>"] [--worktree]` — cria a estrutura da feature + `feature.json` canônico explicitamente (nascimento explícito no início da proposal; o hook state-sync continua cobrindo o caminho implícito como fallback). **Identidade no nascimento:** `name` (default = slug) e `description` são carimbados; a `--description` é **obrigatória** numa feature nova (ou `--request`, que a semeia) — sem nenhuma das duas o `create` recusa (fim dos scaffolds anônimos). `--type` classifica direto; `--request "<pedido>"` roda o detector determinístico (empate/sem sinal sai com exit 2 e candidatos — a LLM decide e re-roda com `--type` + `--request`/`--description`); `--worktree` já nasce a feature no seu worktree próprio.
+- `morph-spec list [--all] [--json]` — o quadro de auditoria: uma linha por feature × workType × status × fase × gates G1/G2/G3 × descrição, com `⚠` para inconsistências (sem descrição, ordem de gate). `--all` inclui as arquivadas; `--json` para scripting. É o complemento do `delete` (enxergar o que está morto antes de remover).
+- `morph-spec delete <feature> [--archive] [--force]` — remove uma feature. Hard por padrão (pasta apagada, git-aware, + entrada podada do índice raiz para não ressuscitar); `--archive` move para `.morph/archive` com status `abandoned` em vez de apagar. Recusa se algum gate estiver aprovado, a menos que `--force`. Use para faxina de scaffolds mortos e drafts abandonados (`archive` é para trabalho concluído; `delete` é para trabalho morto).
 - `morph-spec retype <feature> <newType>` — muda o tipo de trabalho mid-flight; desfaz só os gates carimbados por política, preserva aprovações humanas; bloqueado após o Gate 3.
 - `morph-spec verify <feature> [task] [--json]` — cadeia determinística build+testes+validadores (código antes do juiz LLM); escopo de task quando informado, senão a feature inteira.
 - `morph-spec worktree setup|link|finish|list` — gerencia o ciclo do worktree por feature (`setup` cria `.worktrees/{f}/` na branch `morph/{f}`, aloca o bloco de portas e escreve `.morph/worktree.env`; `link` religa infra compartilhada; `finish` faz merge `--no-ff`, limpa e libera o bloco; `list` mostra fase/gate de cada worktree ativo).
@@ -70,9 +72,9 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 
 ## Roteamento por tipo de trabalho
 
-Toda feature nasce com um `workType` (`morph-spec create <f> --type <tipo>` ou classificado de `--request "<pedido>"`) que dimensiona o pipeline: `feature` roda o fluxo completo (proposal → [uiux] → plan → implement → review); `bug` roda uma versão enxuta (proposal/plan lean); `chore` pula direto para implement (Gates 1/2 carimbados por política no nascimento); `hotfix` roda scout → fix cirúrgico → test loop → ship. O Gate 3 do `hotfix` **pausa sempre para um humano**, mesmo em `trust: auto` — o CLI recusa `morph-spec approve <f> review --mode auto` nesse tipo. Detalhes em `.morph/framework/MORPH.md` §2.1 e §5.
+Toda feature nasce com um `workType` (`morph-spec create <f> --description "<o quê/porquê>" --type <tipo>` ou classificado de `--request "<pedido>"`, que também semeia a descrição obrigatória) que dimensiona o pipeline: `feature` roda o fluxo completo (proposal → [uiux] → plan → implement → review); `bug` roda uma versão enxuta (proposal/plan lean); `chore` pula direto para implement (Gates 1/2 carimbados por política no nascimento); `hotfix` roda scout → fix cirúrgico → test loop → ship. O Gate 3 do `hotfix` **pausa sempre para um humano**, mesmo em `trust: auto` — o CLI recusa `morph-spec approve <f> review --mode auto` nesse tipo. Detalhes em `.morph/framework/MORPH.md` §2.1 e §5.
 
-Features independentes podem rodar em paralelo, cada uma isolada num git worktree (`morph-spec create <f> --worktree` ou `morph-spec worktree setup <f>`) — uma feature por worktree, uma instância de Claude Code por worktree. Cada worktree tem seu **bloco de portas** próprio (`.morph/worktree.env` — suba dev servers SEMPRE nelas, nunca nas portas padrão) e seu **handoff.md** de retomada. `feature.json` viaja commitado na branch `morph/{f}`; ao fechar, aprove o Gate 3 dentro do worktree e rode `morph-spec worktree finish <f>` seguido de `morph-spec archive <f>` na raiz. Visão agregada: `morph-spec fleet`. Detalhes em `.morph/framework/MORPH.md` §2.2.
+Features independentes podem rodar em paralelo, cada uma isolada num git worktree (`morph-spec create <f> --description "<o quê/porquê>" --worktree` ou `morph-spec worktree setup <f>`) — uma feature por worktree, uma instância de Claude Code por worktree. Cada worktree tem seu **bloco de portas** próprio (`.morph/worktree.env` — suba dev servers SEMPRE nelas, nunca nas portas padrão) e seu **handoff.md** de retomada. `feature.json` viaja commitado na branch `morph/{f}`; ao fechar, aprove o Gate 3 dentro do worktree e rode `morph-spec worktree finish <f>` seguido de `morph-spec archive <f>` na raiz. Visão agregada: `morph-spec fleet`. Detalhes em `.morph/framework/MORPH.md` §2.2.
 
 ## Personas (em `.claude/agents/`)
 

package/framework/MORPH.md

@@ -97,7 +97,7 @@ Não avance de fase sem o gate correspondente ter sido confirmado.
 
 ### 2.1 Roteamento por tipo de trabalho
 
-Nem todo trabalho merece o pipeline completo. Cada feature nasce com um **workType** (`morph-spec create <f> --type <tipo>` ou classificado de `--request "<pedido>"`), e o tipo dimensiona o pipeline:
+Nem todo trabalho merece o pipeline completo. Cada feature nasce com **identidade** (`name` = slug por padrão + `description` obrigatória) e um **workType** (`morph-spec create <f> --description "<o quê/porquê>" --type <tipo>`, ou classificado de `--request "<pedido>"` — que também semeia a descrição), e o tipo dimensiona o pipeline:
 
 | Tipo | Pipeline | Gates |
 |------|----------|-------|
@@ -114,7 +114,7 @@ Nem todo trabalho merece o pipeline completo. Cada feature nasce com um **workTy
 
 ### 2.2 Desenvolvimento paralelo por worktree (frota)
 
-Features independentes podem ser desenvolvidas **em paralelo, cada uma no seu git worktree**, com uma instância de Claude Code por worktree. `morph-spec create <f> --worktree` (ou `morph-spec worktree setup <f>`) cria `.worktrees/{f}/` na branch `morph/{f}`. Contrato:
+Features independentes podem ser desenvolvidas **em paralelo, cada uma no seu git worktree**, com uma instância de Claude Code por worktree. `morph-spec create <f> --description "<o quê/porquê>" --worktree` (ou `morph-spec worktree setup <f>`) cria `.worktrees/{f}/` na branch `morph/{f}`. Contrato:
 
 - **Uma feature = um worktree = uma instância.** Nunca abra duas instâncias na mesma feature (o setup recusa com exit 3).
 - O estado autoritativo (`feature.json`) viaja **commitado na branch** `morph/{f}`. O `state.json` local do worktree é um índice derivável — materializado por self-heal, nunca sincronizado à mão.

package/framework/commands/morph-hotfix.md

@@ -16,7 +16,7 @@ Resolve uma queda ou bug crítico de produção com prioridade máxima em veloci
 
 ## Fluxo
 
-1. **Nascimento:** `morph-spec create {feature-name} --type hotfix` — carimba os gates `proposal`/`plan` por política e cria `0-proposal/`, `2-plan/`, `3-implement/` num passo só.
+1. **Nascimento:** `morph-spec create {feature-name} --type hotfix --description "<incidente>"` — carimba `name`+`description` (obrigatória) e os gates `proposal`/`plan` por política e cria `0-proposal/`, `2-plan/`, `3-implement/` num passo só.
 2. **Scout obrigatório:** despacha `subagent_type: "morph-scout"` (fallback `general-purpose` + persona colada) para localizar root cause e blast radius antes de qualquer fix.
 3. **Hotfix brief:** escreve `0-proposal/proposal.md` curto (sintoma/root cause/blast radius/plano do fix) e `2-plan/tasks.json` mínimo (T1 fix, T2 verify/regressão).
 4. **Fix cirúrgico:** implementa a mudança mínima que resolve o sintoma — sem refatoração, sem hardening fora de escopo.

package/framework/hooks/claude-code/core/state-sync.js

@@ -66,8 +66,9 @@ function registerFeatureIfMissing(state, featureName) {
   if (!state.features) state.features = {};
   if (state.features[featureName]) return false;
 
-  // Canonical object-form gates (incl. optional uiux) — no boolean drift.
-  state.features[featureName] = createDefaultFeature();
+  // Canonical object-form gates (incl. optional uiux) + stamped identity
+  // (name=slug, workType, createdAt) — no anonymous shell, no boolean drift.
+  state.features[featureName] = createDefaultFeature(featureName);
   return true;
 }
 
@@ -114,6 +115,15 @@ function gateFromQuestion(question) {
   return null;
 }
 
+// Gate monotonicity — mirror of src/core/state/gate-order.js (hooks are
+// installed standalone and cannot import from src/). Keep in sync:
+// proposal → plan → review; uiux requires proposal.
+const GATE_PREREQ = { proposal: [], uiux: ['proposal'], plan: ['proposal'], review: ['plan'] };
+function unmetGatePrereqs(gate, gates) {
+  const isApproved = (g) => gates?.[g]?.approved === true || gates?.[g] === true;
+  return (GATE_PREREQ[gate] || []).filter((p) => !isApproved(p));
+}
+
 function handleWriteEdit(input, cwd) {
   const filePath = input.tool_input?.file_path;
   const featureName = extractFeatureName(filePath);
@@ -139,23 +149,38 @@ function handleWriteEdit(input, cwd) {
 
 function handleAskUserQuestion(input, cwd) {
   const answers = input.tool_response?.answers ?? input.tool_response?.responses ?? {};
-  if (typeof answers !== 'object' || answers === null) return false;
+  if (typeof answers !== 'object' || answers === null) return null;
 
   const state = loadState(cwd);
-  if (!state) return false;
+  if (!state) return null;
 
   const featureName = findActiveFeature(state);
-  if (!featureName) return false;
+  if (!featureName) return null;
 
+  const warnings = [];
   for (const [question, answer] of Object.entries(answers)) {
     if (!isApprovalAnswer(answer)) continue;
     const gate = gateFromQuestion(question);
     if (!gate) continue;
 
-    const existing = state.features[featureName].approvalGates?.[gate];
+    const gates = state.features[featureName].approvalGates;
+    const existing = gates?.[gate];
     const alreadyApproved = existing === true || existing?.approved === true;
     if (alreadyApproved) continue;
 
+    // Gate monotonicity: fail-open. The human said "aprovado", so we DO approve
+    // (never block a human in the loop), but if a predecessor gate is still
+    // pending we surface a non-blocking warning — the CLI `morph-spec approve`
+    // hard-refuses the same shape; here we alert so the operator can reconcile.
+    const unmet = unmetGatePrereqs(gate, gates);
+    if (unmet.length) {
+      warnings.push(
+        `⚠️ [morph-spec] GATE FORA DE ORDEM — o Gate "${gate}" de "${featureName}" foi aprovado, ` +
+        `mas o(s) gate(s) anterior(es) ${unmet.join(', ')} não estão aprovados (ordem: ${unmet.join(' → ')} → ${gate}). ` +
+        `Aprove os gates anteriores ou reveja com 'morph-spec doctor'.`
+      );
+    }
+
     // An "aprovado" answer to AskUserQuestion is a human approving in the loop.
     // Route through the shared canonical gate writer so the hook and the CLI
     // (`morph-spec approve`) produce one consistent shape
@@ -163,7 +188,7 @@ function handleAskUserQuestion(input, cwd) {
     // and a manual approval stays distinguishable from a policy auto-approval.
     setGateApproved(featureName, gate, { approvedBy: 'manual' }, cwd);
   }
-  return true;
+  return warnings.length ? warnings.join('\n') : null;
 }
 
 async function main() {
@@ -176,17 +201,24 @@ async function main() {
   const input = readStdin();
   const toolName = input.tool_name;
 
+  let warning = null;
   try {
     if (toolName === 'Write' || toolName === 'Edit') {
       handleWriteEdit(input, cwd);
     } else if (toolName === 'AskUserQuestion') {
-      handleAskUserQuestion(input, cwd);
+      warning = handleAskUserQuestion(input, cwd);
     }
   } catch {
     // fail-open
   }
 
-  exit();
+  // A non-blocking order-violation warning is surfaced as injected context
+  // (hookSpecificOutput.additionalContext); everything else exits silently.
+  if (warning) {
+    exit({ hookSpecificOutput: { hookEventName: 'PostToolUse', additionalContext: warning } });
+  } else {
+    exit();
+  }
 }
 
 main().catch(() => exit());

package/framework/hooks/shared/state-writer.js

@@ -91,7 +91,7 @@ export function persistFeature(featureName, feature, projectPath) {
  */
 export function setGateApproved(featureName, gate, meta = {}, projectPath) {
   try {
-    const feature = readFeatureFile(featureName, projectPath) || createDefaultFeature();
+    const feature = readFeatureFile(featureName, projectPath) || createDefaultFeature(featureName);
     const now = new Date().toISOString();
     feature.approvalGates = feature.approvalGates || {};
     feature.approvalGates[gate] = {
@@ -106,11 +106,22 @@ export function setGateApproved(featureName, gate, meta = {}, projectPath) {
   }
 }
 
-/** Default feature shape (canonical object-form gates, incl. optional uiux). */
-export function createDefaultFeature() {
+/**
+ * Default feature shape (canonical object-form gates, incl. optional uiux).
+ * Stamps identity — name (the slug), workType, createdAt — so the implicit
+ * birth path (state-sync registering a feature on the first Write) never
+ * produces an anonymous {status,updatedAt} shell. `description` stays absent
+ * (a hook can't invent it); `list`/`doctor` flag its absence. Mirrors the CLI
+ * createFeature's stamping.
+ *
+ * @param {string} [featureName] - the feature slug, stamped as `name`
+ */
+export function createDefaultFeature(featureName) {
   const now = new Date().toISOString();
   return {
+    ...(featureName ? { name: featureName } : {}),
     status: 'in_progress',
+    workType: 'feature',
     createdAt: now,
     updatedAt: now,
     approvalGates: {

package/framework/schemas/feature.schema.json

@@ -5,10 +5,18 @@
   "type": "object",
   "required": ["status", "approvalGates"],
   "properties": {
+    "name": {
+      "type": "string",
+      "description": "Human-readable feature name, stamped at birth by `morph-spec create` (defaults to the slug) and by the state-sync hook's implicit registration. Kept out of the schema's `required` array — adding it there would invalidate every feature.json that predates identity stamping; instead `create` enforces it at birth and `morph-spec doctor`/`list` flag its absence leniently."
+    },
+    "description": {
+      "type": "string",
+      "description": "What/why of the feature. The one identity field a human must supply — `morph-spec create` refuses a new feature without it (--description, or --request which seeds it). Absent on features born via the implicit hook path; surfaced as a warning by `doctor`/`list`, never a hard read-time rejection (see name)."
+    },
     "status": {
       "type": "string",
-      "enum": ["draft", "in_progress", "completed"],
-      "description": "Feature lifecycle status. `completed` is stamped by `morph-spec archive` together with archivedAt."
+      "enum": ["draft", "in_progress", "completed", "abandoned"],
+      "description": "Feature lifecycle status. `completed` is stamped by `morph-spec archive` together with archivedAt. `abandoned` is stamped by `morph-spec delete --archive` together with abandonedAt (dead scaffold / killed draft, kept in .morph/archive)."
     },
     "createdAt": { "type": "string", "format": "date-time" },
     "updatedAt": {
@@ -21,6 +29,11 @@
       "format": "date-time",
       "description": "Stamped by `morph-spec archive`."
     },
+    "abandonedAt": {
+      "type": "string",
+      "format": "date-time",
+      "description": "Stamped by `morph-spec delete --archive` when a dead/abandoned feature is moved to .morph/archive."
+    },
     "approvalGates": {
       "type": "object",
       "description": "One entry per gate. Written ONLY by `morph-spec approve`/`advance` (approvedBy: \"auto\") or the state-sync hook on a human \"aprovado\" answer (approvedBy: \"manual\").",

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

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

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

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

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

@@ -4,7 +4,7 @@ description: Orquestra a execução autônoma de tasks de uma feature morph-spec
 version: core
 when-to-invoke: após Gate 2 aprovado, ao receber instrução "use /morph-apply" ou "implementar feature"
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-apply

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

@@ -4,7 +4,7 @@ description: Entende o negócio, os usuários e a arquitetura antes de qualquer
 version: core
 when-to-invoke: ao receber um novo request de feature, antes de morph-plan
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-brainstorming

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

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

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

@@ -4,7 +4,7 @@ description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de prod
 version: core
 when-to-invoke: ao receber "/morph-hotfix {feature}", quando a morph-proposal classifica o pedido como workType hotfix (Passo 0), ou o usuário diz "produção caiu / hotfix / urgente"
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-hotfix
@@ -28,10 +28,10 @@ Resolver uma queda ou bug crítico de produção o mais rápido possível — pr
 ### 1. Nascimento da feature
 
 ```
-morph-spec create {feature} --type hotfix
+morph-spec create {feature} --type hotfix --description "<o incidente: o que quebrou / sintoma>"
 ```
 
-Carimba os gates `proposal` e `plan` como `approvedBy: "policy:hotfix"` e cria as pastas `0-proposal/`, `2-plan/`, `3-implement/` num passo só — a feature já nasce em `implement` (fase derivada é gate-aware). Se a feature já existe, siga adiante sem recriar.
+Carimba `name` (o slug) + `description` (obrigatória no nascimento — descreva o incidente) e os gates `proposal`/`plan` como `approvedBy: "policy:hotfix"`, e cria as pastas `0-proposal/`, `2-plan/`, `3-implement/` num passo só — a feature já nasce em `implement` (fase derivada é gate-aware). Se a feature já existe, siga adiante sem recriar.
 
 ### 2. Scout — mapa do território (obrigatório)
 

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

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-implement

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

@@ -4,7 +4,7 @@ description: Guia a produção dos três artefatos de planejamento de uma featur
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-plan

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

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-proposal
@@ -38,10 +38,10 @@ Antes de qualquer trabalho de negócio, classifique o pedido. Se `{feature-name}
 morph-spec create {feature-name} --request "<pedido do usuário>"
 ```
 
-(ou `--type <tipo>` diretamente quando o tipo é óbvio pelo pedido — ex.: o usuário já diz "isso é um hotfix").
+(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>`. 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.
+- **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):
 
@@ -55,7 +55,7 @@ morph-spec create {feature-name} --request "<pedido do usuário>"
 - 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}` — 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. Não crie a estrutura à mão nem dependa do nascimento implícito via hook no primeiro Write. Depois siga o passo 2.
+  - 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)`
 

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

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-review

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

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-stack-scan

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

@@ -4,7 +4,7 @@ description: Localiza e carrega um standard específico do STANDARDS.json sob de
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "8.3.0"
+cliVersion: "8.4.0"
 ---
 
 # morph-standards

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@polymorphism-tech/morph-spec",
-  "version": "8.3.0",
+  "version": "8.4.0",
   "description": "MORPH-SPEC: NLH (Natural Language Harness) for spec-driven development with Claude Code",
   "keywords": [
     "claude-code",