@polymorphism-tech/morph-spec 7.7.3 → 7.8.1

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "7.7.3",
+  "version": "7.8.1",
   "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.7.3 by Polymorphism Tech*
+*morph-spec v7.8.1 by Polymorphism Tech*

package/docs/QUICKSTART.md

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

package/framework/CLAUDE.md

@@ -17,7 +17,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Modificar o contrato do plano depois do Gate 2: `spec.md`, `mandate.md`, e os campos de plano de `tasks.json` (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`) estão congelados.
 - Tocar os campos de contrato do plano em `tasks.json` após o Gate 2 (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`) — o hook `protect-spec-files` faz diff semântico e bloqueia mudanças neles, seja via `Write` ou `Edit`. (Os campos mutáveis `status`/`outputs`/`notes` continuam graváveis por `Write` ou `Edit` — ver SEMPRE.)
 - Listar perguntas em texto simples — sempre use a tool `AskUserQuestion` (1-4 perguntas por chamada).
-- Usar `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, ou SQL cru sem justificativa.
+- Usar `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`), ou SQL cru sem justificativa.
 
 **SEMPRE:**
 - Auto-advance entre tarefas durante a fase implement — não pause sem ambiguidade bloqueante.

package/framework/MORPH.md

@@ -48,10 +48,11 @@ Padrões proibidos automaticamente injetados no mandate:
 - `Guid.NewGuid()` → `Guid.CreateVersion7()`
 - Classes não-sealed sem justificativa
 - Exceptions como fluxo de controle
-- Camada de Service/Manager entre handler e dados — o handler fala com `IRepository<T>` ou `DbContext`, nunca com um service
+- Camada de Service/Manager entre handler e dados — o handler fala com o `ApplicationDbContext` direto, nunca com um service
+- Repository genérico (`IRepository<T>`/`IUnitOfWork`) — redundante sobre EF Core: `DbSet<T>` já é repository, `DbContext` já é unit of work
 - SQL cru (`FromSqlRaw`, `ExecuteQuery(string)`) sem justificativa em `decisions.md` — use LINQ
 
-Acesso a dados em VSA é híbrido: `IRepository<T>` + `IUnitOfWork` para CRUD simples; `ApplicationDbContext` injetado direto no slice quando a query for específica (joins, projeção, paginação, filtros compostos).
+Acesso a dados em VSA: o handler injeta `ApplicationDbContext` direto no slice — `DbSet<T>` já é repository, `DbContext` já é unit of work. Para concorrência ou SQL específico, crie um store dedicado hand-written com justificativa em `decisions.md`. NUNCA camada de Service/Manager; NUNCA repository genérico.
 
 ---
 

package/framework/agents.json

@@ -22,7 +22,7 @@
         "backend-dotnet-fluent-validation-vsa"
       ],
       "mcp": ["context7"],
-      "persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados híbrido: IRepository<T> + IUnitOfWork para CRUD, DbContext direto no slice para queries específicas; nunca uma camada de Service/Manager. Não usa exceptions como fluxo. Consulta o standard antes de escrever cada slice. Nomeia tudo em PascalCase para tipos, camelCase para parâmetros."
+      "persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados: ApplicationDbContext injetado direto no slice (DbSet<T> já é repository, DbContext já é unit of work); para concorrência ou SQL específico, store dedicado hand-written com justificativa em decisions.md; nunca uma camada de Service/Manager; nunca repository genérico (IRepository<T>/IUnitOfWork). Não usa exceptions como fluxo. Consulta o standard antes de escrever cada slice. Nomeia tudo em PascalCase para tipos, camelCase para parâmetros."
     },
     "ef-modeler": {
       "title": "EF Core / Database Modeler",

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