@polymorphism-tech/morph-spec 7.9.0 → 7.9.2

package/claude-plugin.json

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

@@ -3,7 +3,7 @@
 ## Setup
 
 ```bash
-npm install -g @polymorphism-tech/morph-spec   # install globally
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online   # install/upgrade globally
 morph-spec init                                 # initialize project
 morph-spec init --wizard                        # interactive wizard
 morph-spec init --force                         # overwrite existing
@@ -12,6 +12,10 @@ morph-spec doctor                               # health check
 morph-spec --version
 ```
 
+> `--prefer-online` faz parte do comando canônico: sem ele, o cache local do
+> npm segura o packument velho por ~5 min após uma release e o install falha
+> com `ETARGET` (o CDN do registry também leva alguns minutos para propagar).
+
 ---
 
 ## Phase workflow
@@ -196,4 +200,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v7.9.0 by Polymorphism Tech*
+*morph-spec v7.9.2 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -3,7 +3,7 @@
 ## Install
 
 ```bash
-npm install -g @polymorphism-tech/morph-spec
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online
 ```
 
 > The installer automatically configures your PowerShell PATH on Windows. If `morph-spec` is not found, open a new terminal window.
@@ -162,8 +162,8 @@ morph-spec state list
 When a new version of `@polymorphism-tech/morph-spec` is published:
 
 ```bash
-# Update the CLI
-npm install -g @polymorphism-tech/morph-spec@latest
+# Update the CLI (--prefer-online bypasses the ~5 min local packument cache)
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online
 
 # Update framework files in your project
 morph-spec update
@@ -197,4 +197,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.9.0 by Polymorphism Tech*
+*morph-spec v7.9.2 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 (**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.
+- Incluir as 3 cláusulas de protocolo em todo dispatch de sub-agent (**ato final = relatório via `SendMessage` para `main` como a ÚLTIMA tool call, encerrando imediatamente depois — zero texto extra, zero "aguardando confirmação"** — ú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. **Ao consumir o relatório, libere a sessão do sub-agent com `TaskStop`** — não deixe o idle-detector do harness ser o único a encerrá-la.
 
 ## Slash commands
 

package/framework/MORPH.md

@@ -236,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. **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.
+1. **ATO FINAL: enviar o relatório completo via `SendMessage` para `main` como a ÚLTIMA tool call do turno, e encerrar IMEDIATAMENTE depois** — a última mensagem em texto NÃO chega ao orquestrador; só SendMessage chega. Zero texto adicional, zero nova tool call, zero "aguardando confirmação" depois do SendMessage: é o encerramento, não um passo intermediário. Terminar idle sem SendMessage, ou continuar agindo depois dele, é **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).
 
@@ -247,7 +247,7 @@ O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais
 - Quando o feedback do sub-agent precisaria ser discutido em tempo real — dispatch é assíncrono.
 - Quando a tarefa envolve mudanças de arquitetura que o Orchestrator precisa validar antes de executar.
 
-**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa.
+**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa. **Libere a sessão do sub-agent imediatamente ao consumir o relatório** — `TaskStop(task_id: <id/nome retornado pelo dispatch>)`, tratando falha (agente já finalizado sozinho) como não-fatal — não espere o idle-detector do harness fazer isso sozinho minutos depois.
 
 > **Anti-padrão a evitar:** implementar múltiplas tasks de domínios diferentes inline, em sequência, na thread principal — "eu já sei o padrão de cada uma". Isso é exatamente o sinal de que o sistema de delegação foi ignorado. Quando uma feature cruza ≥2 domínios, o caminho default é o Orchestrator despachando especialistas, não o Orchestrator virando faz-tudo.
 

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