@polymorphism-tech/morph-spec 7.8.1 → 7.9.0

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "7.8.1",
+  "version": "7.9.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

@@ -196,4 +196,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v7.8.1 by Polymorphism Tech*
+*morph-spec v7.9.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -197,4 +197,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.8.1 by Polymorphism Tech*
+*morph-spec v7.9.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -25,7 +25,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Apresentar gates com o template fixo definido em MORPH.md / morph-plan.
 - Registrar decisões não triviais em `decisions.md`.
 - Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo (re-implementa, sem pausa), não escala ao humano entre tarefas. No Gate 3, o score composto da feature vem do **avaliador independente** despachado pela `morph-review` (persona `evaluator`, contexto fresco) — nunca de auto-avaliação de quem implementou.
-- Incluir as 3 cláusulas de protocolo em todo dispatch de sub-agent (relatório final obrigatório; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates em `morph-implement` §4 e `morph-apply` §3b.
+- Incluir as 3 cláusulas de protocolo em todo dispatch de sub-agent (**ato final = relatório via `SendMessage` para `main`** — última mensagem em texto não chega ao orquestrador; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates com exemplo literal em `morph-implement` §4 e `morph-apply` §3b. O hook `subagent-report-guard` bloqueia uma vez o encerramento de subagent despachado sem SendMessage.
 
 ## Slash commands
 
@@ -44,6 +44,8 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - `morph-spec archive <feature>` — arquiva a feature (atômico, git-aware); é o que `/morph-archive` chama.
 - `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**.
+- `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>` — 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).
 
 ## Skills core (em `.claude/skills/`)
 

package/framework/MORPH.md

@@ -123,9 +123,10 @@ Não invente caminhos alternativos.
 
 ### Traces (`.morph/traces/`)
 
-Cada sessão de trabalho produz um trace JSON em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.json`.
+Cada fase de implementação produz um trace JSON em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.json`.
 O trace registra tarefas, scores de eval, standards consultados e sub-agents despachados.
 O formato canônico está em `.morph/framework/evals/trace-schema.md` (criado na issue #17).
+**O trace é gerado automaticamente pelo hook `trace-autogen`** a cada write de `tasks.json`, a partir de tasks.json + recap.md + `taskScores` do feature.json — as skills não o escrevem à mão (a escrita manual foi removida da cerimônia por task).
 Traces são ignorados pelo git (`.gitignore`) e servem para análise do harness — não fazem parte da entrega da feature.
 
 ---
@@ -196,7 +197,7 @@ Para alterar o modo: editar `.morph/config/config.json → trust` (`"auto"` ou `
 
 Isso mantém o audit trail honesto justamente nos contextos headless (CI, `claude -p`) onde ele mais importa.
 
-**O hook gate-guard.js** confere, sem bloquear, se a ação tomada num gate (pausar via `AskUserQuestion` vs auto-aprovar) bateu com a decisão de trust que a skill computou via `shouldPauseGate`. Para isso, a skill **persiste** a decisão no `feature.json` autoritativo da feature antes de agir: `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` (escrito com a tool `Edit` — a allowlist permite `Edit(.morph/features/**)`). Se a ação observada divergir do registro (pausou um gate auto-aprovável, ou auto-aprovou um gate que exigia pausa), o guard injeta um aviso no contexto — a LLM corrige. É um guardrail que nunca bloqueia: a cada conferência ele registra uma linha no activity log (`.morph/logs/activity.json`) com o resultado — `coherent` ou `divergent` — e só injeta aviso quando diverge; sem registro ou erro → silêncio.
+**O hook gate-guard.js** confere, sem bloquear, se a ação tomada num gate (pausar via `AskUserQuestion` vs auto-aprovar) bateu com a decisão de trust que a skill computou via `shouldPauseGate`. Para isso, a skill **persiste** a decisão no `feature.json` autoritativo da feature antes de agir — via `morph-spec gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`, que grava `gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }` com timestamp server-side (shape canônico em `framework/schemas/feature.schema.json`). **Nunca edite `gateDecisions` à mão:** o Edit manual de feature.json colide com o hook state-sync, que reescreve o arquivo entre o Read e o Edit ("file modified since read"). Se a ação observada divergir do registro (pausou um gate auto-aprovável, ou auto-aprovou um gate que exigia pausa), o guard injeta um aviso no contexto — a LLM corrige. É um guardrail que nunca bloqueia: a cada conferência ele registra uma linha no activity log (`.morph/logs/activity.json`) com o resultado — `coherent` ou `divergent` — e só injeta aviso quando diverge; sem registro ou erro → silêncio.
 
 ---
 
@@ -235,7 +236,7 @@ Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do d
 - Auto-score 0-10 com justificativa em uma linha
 
 **Protocolo obrigatório do sub-agent** (cláusulas que todo prompt de dispatch inclui — ver templates em `morph-implement` §4 e `morph-apply` §3b):
-1. Ao concluir, entregar o relatório final (última mensagem, ou SendMessage para main se a sessão permanecer viva) — terminar idle sem reportar é **falha de protocolo**; o orquestrador cobra via SendMessage e registra a falha no recap.
+1. **ATO FINAL: enviar o relatório completo via `SendMessage` para `main` antes de encerrar** — a última mensagem em texto NÃO chega ao orquestrador; só SendMessage chega. Terminar idle sem SendMessage é **falha de protocolo**: o hook `subagent-report-guard` bloqueia o encerramento uma vez com a instrução, e a cobrança do orquestrador via SendMessage é apenas o fallback (registrada como falha no recap). Os templates trazem o exemplo literal da chamada.
 2. Não tocar em `tasks.json`, `feature.json`, `state.json` nem no board de sessão (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo orquestrador.
 3. Em batch paralelo, não rodar build/test da suíte compartilhada — a verificação é do orquestrador, uma vez, pós-batch (alternativa: dispatch com `isolation: "worktree"`, e aí o build roda dentro do worktree).
 

package/framework/commands/commit.md

@@ -1,166 +1,166 @@
----
-allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*)
-argument-hint: [message] | --no-verify | --amend
-description: Create well-formatted commits with conventional commit format and emoji
----
-
-# Smart Git Commit
-
-Create well-formatted commit: $ARGUMENTS
-
-## Current Repository State
-
-- Git status: !git status --porcelain
-- Current branch: !git branch --show-current
-- Staged changes: !git diff --cached --stat
-- Unstaged changes: !git diff --stat
-- Recent commits: !git log --oneline -5
-
-## What This Command Does
-
-1. Unless specified with --no-verify, automatically runs pre-commit checks:
-   - pnpm lint to ensure code quality
-   - pnpm build to verify the build succeeds
-   - pnpm generate:docs to update documentation
-2. Checks which files are staged with git status
-3. If 0 files are staged, automatically adds all modified and new files with git add
-4. Performs a git diff to understand what changes are being committed
-5. Analyzes the diff to determine if multiple distinct logical changes are present
-6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
-7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
-
-## Best Practices for Commits
-
-- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
-- **Atomic commits**: Each commit should contain related changes that serve a single purpose
-- **Split large changes**: If changes touch multiple concerns, split them into separate commits
-- **Conventional commit format**: Use the format <type>: <description> where type is one of:
-  - feat: A new feature
-  - fix: A bug fix
-  - docs: Documentation changes
-  - style: Code style changes (formatting, etc)
-  - refactor: Code changes that neither fix bugs nor add features
-  - perf: Performance improvements
-  - test: Adding or fixing tests
-  - chore: Changes to the build process, tools, etc.
-- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
-- **Concise first line**: Keep the first line under 72 characters
-- **Emoji**: Each commit type is paired with an appropriate emoji:
-  - ✨ feat: New feature
-  - 🐛 fix: Bug fix
-  - 📝 docs: Documentation
-  - 💄 style: Formatting/style
-  - ♻️ refactor: Code refactoring
-  - ⚡️ perf: Performance improvements
-  - ✅ test: Tests
-  - 🔧 chore: Tooling, configuration
-  - 🚀 ci: CI/CD improvements
-  - 🗑️ revert: Reverting changes
-  - 🧪 test: Add a failing test
-  - 🚨 fix: Fix compiler/linter warnings
-  - 🔒️ fix: Fix security issues
-  - 👥 chore: Add or update contributors
-  - 🚚 refactor: Move or rename resources
-  - 🏗️ refactor: Make architectural changes
-  - 🔀 chore: Merge branches
-  - 📦️ chore: Add or update compiled files or packages
-  - ➕ chore: Add a dependency
-  - ➖ chore: Remove a dependency
-  - 🌱 chore: Add or update seed files
-  - 🧑‍💻 chore: Improve developer experience
-  - 🧵 feat: Add or update code related to multithreading or concurrency
-  - 🔍️ feat: Improve SEO
-  - 🏷️ feat: Add or update types
-  - 💬 feat: Add or update text and literals
-  - 🌐 feat: Internationalization and localization
-  - 👔 feat: Add or update business logic
-  - 📱 feat: Work on responsive design
-  - 🚸 feat: Improve user experience / usability
-  - 🩹 fix: Simple fix for a non-critical issue
-  - 🥅 fix: Catch errors
-  - 👽️ fix: Update code due to external API changes
-  - 🔥 fix: Remove code or files
-  - 🎨 style: Improve structure/format of the code
-  - 🚑️ fix: Critical hotfix
-  - 🎉 chore: Begin a project
-  - 🔖 chore: Release/Version tags
-  - 🚧 wip: Work in progress
-  - 💚 fix: Fix CI build
-  - 📌 chore: Pin dependencies to specific versions
-  - 👷 ci: Add or update CI build system
-  - 📈 feat: Add or update analytics or tracking code
-  - ✏️ fix: Fix typos
-  - ⏪️ revert: Revert changes
-  - 📄 chore: Add or update license
-  - 💥 feat: Introduce breaking changes
-  - 🍱 assets: Add or update assets
-  - ♿️ feat: Improve accessibility
-  - 💡 docs: Add or update comments in source code
-  - 🗃️ db: Perform database related changes
-  - 🔊 feat: Add or update logs
-  - 🔇 fix: Remove logs
-  - 🤡 test: Mock things
-  - 🥚 feat: Add or update an easter egg
-  - 🙈 chore: Add or update .gitignore file
-  - 📸 test: Add or update snapshots
-  - ⚗️ experiment: Perform experiments
-  - 🚩 feat: Add, update, or remove feature flags
-  - 💫 ui: Add or update animations and transitions
-  - ⚰️ refactor: Remove dead code
-  - 🦺 feat: Add or update code related to validation
-  - ✈️ feat: Improve offline support
-
-## Guidelines for Splitting Commits
-
-When analyzing the diff, consider splitting commits based on these criteria:
-
-1. **Different concerns**: Changes to unrelated parts of the codebase
-2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
-3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
-4. **Logical grouping**: Changes that would be easier to understand or review separately
-5. **Size**: Very large changes that would be clearer if broken down
-
-## Examples
-
-Good commit messages:
-- ✨ feat: add user authentication system
-- 🐛 fix: resolve memory leak in rendering process
-- 📝 docs: update API documentation with new endpoints
-- ♻️ refactor: simplify error handling logic in parser
-- 🚨 fix: resolve linter warnings in component files
-- 🧑‍💻 chore: improve developer tooling setup process
-- 👔 feat: implement business logic for transaction validation
-- 🩹 fix: address minor styling inconsistency in header
-- 🚑️ fix: patch critical security vulnerability in auth flow
-- 🎨 style: reorganize component structure for better readability
-- 🔥 fix: remove deprecated legacy code
-- 🦺 feat: add input validation for user registration form
-- 💚 fix: resolve failing CI pipeline tests
-- 📈 feat: implement analytics tracking for user engagement
-- 🔒️ fix: strengthen authentication password requirements
-- ♿️ feat: improve form accessibility for screen readers
-
-Example of splitting commits:
-- First commit: ✨ feat: add new solc version type definitions
-- Second commit: 📝 docs: update documentation for new solc versions
-- Third commit: 🔧 chore: update package.json dependencies
-- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
-- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
-- Sixth commit: 🚨 fix: resolve linting issues in new code
-- Seventh commit: ✅ test: add unit tests for new solc version features
-- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
-
-## Command Options
-
-- --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
-
-## Important Notes
-
-- By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality
-- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
-- If specific files are already staged, the command will only commit those files
-- If no files are staged, it will automatically stage all modified and new files
-- The commit message will be constructed based on the changes detected
-- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
-- If suggesting multiple commits, it will help you stage and commit the changes separately
-- Always reviews the commit diff to ensure the message matches the changes
+---
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*)
+argument-hint: [message] | --no-verify | --amend
+description: Create well-formatted commits with conventional commit format and emoji
+---
+
+# Smart Git Commit
+
+Create well-formatted commit: $ARGUMENTS
+
+## Current Repository State
+
+- Git status: !git status --porcelain
+- Current branch: !git branch --show-current
+- Staged changes: !git diff --cached --stat
+- Unstaged changes: !git diff --stat
+- Recent commits: !git log --oneline -5
+
+## What This Command Does
+
+1. Unless specified with --no-verify, automatically runs pre-commit checks:
+   - pnpm lint to ensure code quality
+   - pnpm build to verify the build succeeds
+   - pnpm generate:docs to update documentation
+2. Checks which files are staged with git status
+3. If 0 files are staged, automatically adds all modified and new files with git add
+4. Performs a git diff to understand what changes are being committed
+5. Analyzes the diff to determine if multiple distinct logical changes are present
+6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
+7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
+
+## Best Practices for Commits
+
+- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated
+- **Atomic commits**: Each commit should contain related changes that serve a single purpose
+- **Split large changes**: If changes touch multiple concerns, split them into separate commits
+- **Conventional commit format**: Use the format <type>: <description> where type is one of:
+  - feat: A new feature
+  - fix: A bug fix
+  - docs: Documentation changes
+  - style: Code style changes (formatting, etc)
+  - refactor: Code changes that neither fix bugs nor add features
+  - perf: Performance improvements
+  - test: Adding or fixing tests
+  - chore: Changes to the build process, tools, etc.
+- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
+- **Concise first line**: Keep the first line under 72 characters
+- **Emoji**: Each commit type is paired with an appropriate emoji:
+  - ✨ feat: New feature
+  - 🐛 fix: Bug fix
+  - 📝 docs: Documentation
+  - 💄 style: Formatting/style
+  - ♻️ refactor: Code refactoring
+  - ⚡️ perf: Performance improvements
+  - ✅ test: Tests
+  - 🔧 chore: Tooling, configuration
+  - 🚀 ci: CI/CD improvements
+  - 🗑️ revert: Reverting changes
+  - 🧪 test: Add a failing test
+  - 🚨 fix: Fix compiler/linter warnings
+  - 🔒️ fix: Fix security issues
+  - 👥 chore: Add or update contributors
+  - 🚚 refactor: Move or rename resources
+  - 🏗️ refactor: Make architectural changes
+  - 🔀 chore: Merge branches
+  - 📦️ chore: Add or update compiled files or packages
+  - ➕ chore: Add a dependency
+  - ➖ chore: Remove a dependency
+  - 🌱 chore: Add or update seed files
+  - 🧑‍💻 chore: Improve developer experience
+  - 🧵 feat: Add or update code related to multithreading or concurrency
+  - 🔍️ feat: Improve SEO
+  - 🏷️ feat: Add or update types
+  - 💬 feat: Add or update text and literals
+  - 🌐 feat: Internationalization and localization
+  - 👔 feat: Add or update business logic
+  - 📱 feat: Work on responsive design
+  - 🚸 feat: Improve user experience / usability
+  - 🩹 fix: Simple fix for a non-critical issue
+  - 🥅 fix: Catch errors
+  - 👽️ fix: Update code due to external API changes
+  - 🔥 fix: Remove code or files
+  - 🎨 style: Improve structure/format of the code
+  - 🚑️ fix: Critical hotfix
+  - 🎉 chore: Begin a project
+  - 🔖 chore: Release/Version tags
+  - 🚧 wip: Work in progress
+  - 💚 fix: Fix CI build
+  - 📌 chore: Pin dependencies to specific versions
+  - 👷 ci: Add or update CI build system
+  - 📈 feat: Add or update analytics or tracking code
+  - ✏️ fix: Fix typos
+  - ⏪️ revert: Revert changes
+  - 📄 chore: Add or update license
+  - 💥 feat: Introduce breaking changes
+  - 🍱 assets: Add or update assets
+  - ♿️ feat: Improve accessibility
+  - 💡 docs: Add or update comments in source code
+  - 🗃️ db: Perform database related changes
+  - 🔊 feat: Add or update logs
+  - 🔇 fix: Remove logs
+  - 🤡 test: Mock things
+  - 🥚 feat: Add or update an easter egg
+  - 🙈 chore: Add or update .gitignore file
+  - 📸 test: Add or update snapshots
+  - ⚗️ experiment: Perform experiments
+  - 🚩 feat: Add, update, or remove feature flags
+  - 💫 ui: Add or update animations and transitions
+  - ⚰️ refactor: Remove dead code
+  - 🦺 feat: Add or update code related to validation
+  - ✈️ feat: Improve offline support
+
+## Guidelines for Splitting Commits
+
+When analyzing the diff, consider splitting commits based on these criteria:
+
+1. **Different concerns**: Changes to unrelated parts of the codebase
+2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
+3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
+4. **Logical grouping**: Changes that would be easier to understand or review separately
+5. **Size**: Very large changes that would be clearer if broken down
+
+## Examples
+
+Good commit messages:
+- ✨ feat: add user authentication system
+- 🐛 fix: resolve memory leak in rendering process
+- 📝 docs: update API documentation with new endpoints
+- ♻️ refactor: simplify error handling logic in parser
+- 🚨 fix: resolve linter warnings in component files
+- 🧑‍💻 chore: improve developer tooling setup process
+- 👔 feat: implement business logic for transaction validation
+- 🩹 fix: address minor styling inconsistency in header
+- 🚑️ fix: patch critical security vulnerability in auth flow
+- 🎨 style: reorganize component structure for better readability
+- 🔥 fix: remove deprecated legacy code
+- 🦺 feat: add input validation for user registration form
+- 💚 fix: resolve failing CI pipeline tests
+- 📈 feat: implement analytics tracking for user engagement
+- 🔒️ fix: strengthen authentication password requirements
+- ♿️ feat: improve form accessibility for screen readers
+
+Example of splitting commits:
+- First commit: ✨ feat: add new solc version type definitions
+- Second commit: 📝 docs: update documentation for new solc versions
+- Third commit: 🔧 chore: update package.json dependencies
+- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
+- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
+- Sixth commit: 🚨 fix: resolve linting issues in new code
+- Seventh commit: ✅ test: add unit tests for new solc version features
+- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities
+
+## Command Options
+
+- --no-verify: Skip running the pre-commit checks (lint, build, generate:docs)
+
+## Important Notes
+
+- By default, pre-commit checks (pnpm lint, pnpm build, pnpm generate:docs) will run to ensure code quality
+- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first
+- If specific files are already staged, the command will only commit those files
+- If no files are staged, it will automatically stage all modified and new files
+- The commit message will be constructed based on the changes detected
+- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
+- If suggesting multiple commits, it will help you stage and commit the changes separately
+- Always reviews the commit diff to ensure the message matches the changes