@polymorphism-tech/morph-spec 4.10.0 → 4.10.2

package/framework/rules/morph-workflow.md

@@ -1,3 +1,8 @@
+---
+stacks:
+  - "*"
+---
+
 # MORPH-SPEC Workflow Rules
 
 > Always-active rules for all MORPH-SPEC managed projects.
@@ -18,16 +23,58 @@ UI-heavy features also include **UI/UX** phase (`2-ui/`) between Design and Task
 
 ---
 
+## Phase Sequence
+
+```
+proposal → setup → [uiux] → design → clarify → plan → tasks → implement → [sync]
+```
+
+Use `morph-spec status {feature}` to see current phase and pending approval gates.
+
+---
+
 ## Phase Commands
 
 | Command | Purpose |
 |---------|---------|
-| `/morph-proposal {feature}` | Full spec pipeline (phases 1–4, pauses for approval) |
+| `/morph-proposal {feature}` | Full spec pipeline (phases 1-4, pauses for approval) |
 | `/morph-apply {feature}` | Implement feature (phase 5) |
 | `/morph-status` | Feature dashboard |
 
 ---
 
+## State & Outputs
+
+| Path | Notes |
+|------|-------|
+| `.morph/state.json` | **READ-ONLY** — use `morph-spec` CLI to update |
+| `.morph/features/{feature}/{phase}/` | Feature outputs organized by phase |
+| `.morph/framework/` | **READ-ONLY** — framework files managed by morph-spec |
+| `.morph/config/config.json` | Project configuration (editable) |
+
+### mark-output types
+
+Use `morph-spec state mark-output <feature> <type>` with one of these exact type names:
+
+| Type | Phase | kebab alias |
+|------|-------|-------------|
+| `proposal` | proposal | — |
+| `schemaAnalysis` | design | `schema-analysis` |
+| `spec` | design | — |
+| `contracts` | design | — |
+| `contractsVsa` | design | `contracts-vsa` |
+| `decisions` | design | — |
+| `clarifications` | clarify | — |
+| `plan` | plan | — |
+| `tasks` | tasks | — |
+| `uiDesignSystem` | uiux | `ui-design-system` |
+| `uiMockups` | uiux | `ui-mockups` |
+| `uiComponents` | uiux | `ui-components` |
+| `uiFlows` | uiux | `ui-flows` |
+| `recap` | implement | — |
+
+---
+
 ## Output Paths
 
 All outputs go in `.morph/features/{feature}/`:
@@ -57,7 +104,8 @@ Run a checkpoint every 3 completed tasks:
 
 ## Approval Gates
 
-**Design Gate:** Before moving from Design → Tasks, spec must be approved.
+**Design Gate:** Before moving from Design → Plan, spec must be approved.
+**Plan Gate:** Before moving from Plan → Tasks, plan must be approved.
 **Implementation Gate:** Before starting implementation, task list must be approved.
 
 Check approval status: `morph-spec approval-status {feature}`
@@ -85,4 +133,11 @@ Do not modify test files to make a failing test pass when the implementation is
 
 ---
 
+## Context Window Tip
+
+When using 3+ MCPs, add `"experimental": { "mcpCliMode": true }` to `.claude/settings.json`.
+MCP tools load on-demand instead of all at startup — keeps context clean for actual work.
+
+---
+
 *MORPH-SPEC by Polymorphism Tech*

package/framework/rules/nextjs-standards.md

@@ -2,6 +2,8 @@
 paths:
   - "**/*.tsx"
   - "**/*.ts"
+stacks:
+  - nextjs
 ---
 
 # Next.js Standards

package/framework/rules/testing-standards.md

@@ -4,6 +4,9 @@ paths:
   - "**/*.test.*"
   - "**/*.spec.*"
   - "**/*Tests.cs"
+stacks:
+  - dotnet
+  - blazor
 ---
 
 # Testing Standards

package/framework/skills/level-0-meta/morph-brainstorming/SKILL.md

@@ -3,6 +3,7 @@ name: morph:brainstorming
 description: Morph-spec-aware brainstorming that loads project context, explores multiple design approaches, asks clarifying questions, and produces proposal.md or decisions.md. Use before designing a feature, when facing architectural decisions with multiple valid approaches, or when a feature needs requirements exploration before committing to a direction.
 user-invocable: true
 argument-hint: "[feature-name or topic]"
+allowed-tools: Read, Bash, Glob, Grep, AskUserQuestion
 ---
 
 # Brainstorming — MORPH-SPEC Integrated
@@ -17,20 +18,16 @@ argument-hint: "[feature-name or topic]"
 - **Phase 2 (Design):** Explore architectural alternatives before writing `spec.md`
 - **Any phase:** When facing a decision with multiple valid approaches
 
-## Prerequisites
+## Recommended Tools
 
-Before brainstorming, load project context:
-
-```bash
-# Load current state
-npx morph-spec state get {feature-name}
-
-# Read project config
-Read: .morph/config/config.json
-
-# Read existing proposal (if Phase 2)
-Read: .morph/features/{feature}/0-proposal/proposal.md
-```
+| Action | Tool | Alternative |
+|--------|------|-------------|
+| Load feature state | **Bash** `npx morph-spec state get $ARGUMENTS` | — |
+| Read project config | **Read** `.morph/config/config.json` | — |
+| Scan existing code | **Glob** / **Grep** | — |
+| Research libraries | **Context7 MCP** `query_docs()` | **WebSearch** |
+| Ask clarifying questions | **AskUserQuestion** (never plain text) | — |
+| Render proposal template | **Bash** `npx morph-spec template render docs/proposal ...` | — |
 
 ---
 
@@ -38,38 +35,35 @@ Read: .morph/features/{feature}/0-proposal/proposal.md
 
 ### Step 1: Explore Context
 
-**Gather information before generating ideas:**
+Gather information before generating ideas. This step is what makes morph-aware brainstorming different from generic brainstorming — it grounds your thinking in the actual project state and constraints.
 
-1. **Read state.json** — current phase, active agents, existing outputs
-2. **Read config.json** — stack, architecture, project name
-3. **Read existing outputs** — proposal.md, spec.md (if they exist)
-4. **Scan codebase** — use Glob/Grep to understand existing patterns
-5. **Check integrations.json** — available MCPs and plugins
-
-**Use MCP tools when available:**
-- **Context7** → look up library capabilities relevant to the feature
-- **Supabase** → check existing schema for data-related features
-- **GitHub** → check existing issues/PRs for related work
+1. **Read state** — `npx morph-spec state get $ARGUMENTS` → current phase, active agents, existing outputs, task history
+2. **Read config** — `.morph/config/config.json` → stack, architecture style (VSA vs standard), project name, integrations
+3. **Check architecture** — `cat .morph/config/config.json | grep -A3 architecture` → determines which agents and patterns apply
+4. **Read existing outputs** — proposal.md, spec.md, decisions.md (if they exist from prior work)
+5. **Check active agents** — `npx morph-spec dispatch-agents $ARGUMENTS design --table` → which specialists are available
+6. **Scan codebase** — use Glob/Grep to understand existing patterns, domain models, and service boundaries relevant to the feature
+7. **Check MCP tools** — if Context7, GitHub, or other MCPs are available, use them for research
 
 ### Step 2: Ask Clarifying Questions
 
 Use `AskUserQuestion` to collect responses — **NEVER list questions as plain text**.
 
-- Máximo 4 perguntas por chamada. Se precisar de 5, faça 2 chamadas sequenciais (Q1-Q4 → Q5).
-- Para cada pergunta, defina 2-4 opções representativas (o usuário pode usar "Other" para resposta livre).
-- **Aguarde o retorno do tool antes de prosseguir para o Step 3.**
+- Maximum 4 questions per call. If you need 5+, make sequential calls (Q1-Q4, then Q5).
+- Each question needs 2-4 representative options (the user can type a free response via "Other").
+- **Wait for the tool response before proceeding to Step 3.**
 
-Perguntas-padrão a adaptar para o contexto da feature:
+Starter questions to adapt to the feature context:
 
-| Header (≤12 chars) | Pergunta | Opções sugeridas |
+| Header (<=12 chars) | Question | Suggested Options |
 |--------------------|----------|------------------|
-| `Escopo` | Qual é a versão mínima viável desta feature? | MVP básico / Versão completa / Em aberto |
-| `Constraints` | Há restrições de performance, budget ou prazo? | Sem restrições / Performance crítica / Budget limitado |
-| `Integração` | Precisa integrar com features ou sistemas existentes? | Sim, integra com X / Feature isolada / A definir |
-| `Usuários` | Quem são os usuários primários? | End-users / Admins / Sistema interno |
-| `Sucesso` | Como saberemos que a feature funciona corretamente? | Métricas definidas / Testes de aceitação / Feedback do usuário |
+| `Scope` | What's the minimum viable version of this feature? | Basic MVP / Full version / Open-ended |
+| `Constraints` | Any performance, budget, or timeline constraints? | No constraints / Performance-critical / Budget-limited |
+| `Integration` | Does this need to integrate with existing features/systems? | Yes, integrates with X / Isolated feature / TBD |
+| `Users` | Who are the primary users? | End-users / Admins / Internal system |
+| `Success` | How will we know this feature works correctly? | Defined metrics / Acceptance tests / User feedback |
 
-> Adapte as opções ao contexto real da feature — as acima são ponto de partida, não template fixo.
+> Adapt the options to the actual feature context — these are starting points, not a fixed template.
 
 ### Step 3: Generate 2-3 Approaches
 
@@ -95,16 +89,27 @@ For each approach, document:
 
 ### Step 4: Recommend and Document
 
-1. **Recommend** the best approach with reasoning
-2. **Write output** to the appropriate location:
-   - Phase 0 → render `docs/proposal` template → `.morph/features/{feature}/0-proposal/proposal.md`
-   - Phase 2 → document in `decisions.md` as an ADR
+1. **Recommend** the best approach with clear reasoning
+2. **Write output** to the appropriate location based on the current phase:
 
-3. **Update state:**
-```bash
-npx morph-spec state mark-output {feature-name} proposal    # Phase 0
-npx morph-spec state mark-output {feature-name} decisions    # Phase 2
-```
+   **Phase 0 (Proposal):**
+   ```bash
+   npx morph-spec template render docs/proposal ".morph/features/$ARGUMENTS/0-proposal/proposal.md" '{"FEATURE_NAME":"...", "DATE":"..."}'
+   ```
+   Then edit the rendered file to add the brainstorming results.
+
+   **Phase 2 (Design):**
+   Write the decision as an ADR (Architecture Decision Record) in `.morph/features/$ARGUMENTS/1-design/decisions.md`.
+
+3. **Update state** (mandatory — do not skip):
+   ```bash
+   npx morph-spec state mark-output $ARGUMENTS proposal    # Phase 0
+   npx morph-spec state mark-output $ARGUMENTS decisions    # Phase 2
+   ```
+   Then verify the output was recorded:
+   ```bash
+   npx morph-spec state get $ARGUMENTS
+   ```
 
 ---
 
@@ -116,7 +121,7 @@ This skill replaces `superpowers:brainstorming` within morph-spec workflows. It
 - Automatic context loading from `.morph/` state and config
 - Template rendering for outputs (proposal.md, decisions.md)
 - State tracking via `morph-spec state mark-output`
-- MCP integration for research (Context7, Supabase)
+- MCP integration for research (Context7, GitHub)
 
 For brainstorming **outside** morph-spec workflows, the original `superpowers:brainstorming` skill remains available.
 
@@ -124,10 +129,10 @@ For brainstorming **outside** morph-spec workflows, the original `superpowers:br
 
 ## Anti-patterns
 
-- Never skip brainstorming for features with multiple valid approaches
-- Never commit to an approach without documenting alternatives
-- Never brainstorm without loading project context first
-- Never write code before completing the brainstorming output
+- Skipping brainstorming for features with multiple valid approaches — exploring alternatives prevents tunnel vision
+- Committing to an approach without documenting alternatives — future decisions need context on what was considered
+- Brainstorming without loading project context first — leads to approaches that don't fit the existing architecture
+- Writing code before completing the brainstorming output — premature implementation before agreement
 
 ---
 

package/framework/skills/level-0-meta/morph-checklist/SKILL.md

@@ -7,15 +7,21 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep
 
 # MORPH Checklists
 
-Types: `deploy`, `security`, `seo`, `performance`, `accessibility`, `legal-brazil`, `simulation` (ver skill: `morph:simulation-checklist`)
+Types: `deploy`, `security`, `seo`, `performance`, `accessibility`, `legal-brazil`, `simulation` (see skill: `morph:simulation-checklist`)
 
 ---
 
 ## Deploy
 
+### MORPH-SPEC Validation (run first)
+- [ ] `npx morph-spec validate-feature {feature}` — passes with 100% pass rate
+- [ ] `npx morph-spec approval-status {feature}` — all gates approved (design, plan, tasks)
+- [ ] `npx morph-spec state get {feature}` — phase is `implement`, all tasks `done`
+- [ ] Recap generated: `.morph/features/{feature}/5-implement/recap.md` exists
+
 ### Pre-Deploy
 - [ ] `dotnet build --configuration Release` passes
-- [ ] `dotnet test` passes
+- [ ] `dotnet test` passes (100% pass rate required — zero tolerance)
 - [ ] Migrations applied (`dotnet ef database update`)
 - [ ] Env vars configured (connection strings, API keys, feature flags)
 
@@ -94,28 +100,45 @@ Types: `deploy`, `security`, `seo`, `performance`, `accessibility`, `legal-brazi
 - [ ] Alt text on images, captions on videos
 - [ ] Contrast >= 4.5:1 (AA), color not sole indicator
 - [ ] Keyboard navigation works, focus visible
-- [ ] Skip links, `<html lang="pt-BR">`
+- [ ] Skip links, `<html lang="...">` with correct locale
 - [ ] Labels on all inputs, clear error messages
 - [ ] Valid HTML, ARIA used correctly
 
 ---
 
-## Legal Brazil (LGPD)
-
-### Documentation
-- [ ] Privacy policy (data collected, purpose, legal basis, DPO contact)
-- [ ] Terms of use (service description, responsibilities, forum)
-
-### Consent & Rights
-- [ ] Cookie banner with granular options
-- [ ] Explicit consent for marketing, revocation option
-- [ ] Data access, correction, deletion, portability
-
-### Technical
-- [ ] Data minimization, defined retention periods
-- [ ] Anonymization/pseudonymization where possible
-- [ ] Access logs for personal data
-- [ ] Incident response plan (ANPD notification in 72h)
+## Legal Brazil (LGPD — Lei 13.709/2018)
+
+The Brazilian General Data Protection Law (LGPD) applies to any application that processes personal data of individuals in Brazil. Non-compliance can result in fines up to 2% of revenue (capped at R$50M per violation) from ANPD (Autoridade Nacional de Protecao de Dados).
+
+### Documentation (Art. 9, 23, 41)
+- [ ] Privacy policy published and accessible from every page — must include: categories of data collected, legal basis per category (Art. 7), processing purpose, retention period, DPO (Encarregado) contact name and email
+- [ ] Terms of use covering: service description, user responsibilities, governing forum (Brazilian jurisdiction required)
+- [ ] ROPA (Record of Processing Activities) — internal document mapping data flows per Art. 37
+
+### Consent & Data Subject Rights (Art. 7-9, 15-18)
+- [ ] Cookie consent banner with **granular opt-in** (not just "accept all") — separate toggles for analytics, marketing, essential
+- [ ] Explicit consent for marketing communications — checkbox unchecked by default, revocable at any time
+- [ ] Data subject rights page implementing all Art. 18 rights:
+  - [ ] Access: user can view all personal data held
+  - [ ] Correction: user can update inaccurate data
+  - [ ] Deletion: user can request full account/data deletion (Art. 18, IX)
+  - [ ] Portability: user can export data in machine-readable format (JSON/CSV)
+  - [ ] Opposition: user can object to specific processing
+- [ ] Rights requests processed within 15 days (Art. 19)
+
+### Technical Controls (Art. 46-49)
+- [ ] PII encrypted at rest (AES-256) and in transit (TLS 1.2+)
+- [ ] Data minimization: only collect what the legal basis justifies
+- [ ] Defined retention periods per data category — automatic purge after expiry
+- [ ] Anonymization/pseudonymization for analytics and logs
+- [ ] Access logs for all personal data operations (who accessed what, when)
+- [ ] Incident response plan: ANPD notification within **72 hours** of breach (Art. 48), user notification "within reasonable time"
+- [ ] Data Protection Impact Assessment (DPIA/RIPD) for high-risk processing (Art. 5, XVII)
+
+### DPO (Encarregado — Art. 41)
+- [ ] DPO designated and publicly identified (name + contact on privacy policy)
+- [ ] DPO contact channel operational (email or form)
+- [ ] DPO handles ANPD communications and data subject requests
 
 ---
 

package/framework/skills/level-0-meta/morph-code-review/SKILL.md

@@ -3,6 +3,9 @@ name: morph:code-review
 description: .NET/C# code review checklist covering naming conventions, architecture layer integrity, async patterns, logging, error handling, DI lifetimes, and DTO contracts. Use after implementing .NET code, before creating PRs, or when reviewing C# code for compliance with MORPH-SPEC standards.
 user-invocable: true
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
+stacks:
+  - dotnet
+  - blazor
 ---
 
 # Code Review Checklist
@@ -23,12 +26,12 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep
 git diff --name-only main...HEAD -- "*.cs" | wc -l
 ```
 
-**Pular revisão se:**
-- 0 arquivos `.cs` alterados → sem código backend para revisar
-- Apenas mudanças em `*.json`, `*.csproj`, `*.md`, arquivos de migration → escopo de infra
-- Já existe `.morph/features/$ARGUMENTS/5-implement/code-review.md` criado hoje → já revisado
+**Skip review if:**
+- 0 `.cs` files changed → no backend code to review
+- Only changes in `*.json`, `*.csproj`, `*.md`, migration files → infrastructure scope
+- `.morph/features/$ARGUMENTS/5-implement/code-review.md` already exists from today → already reviewed
 
-Se skip: output `"Skipping code-review: [motivo]"` e parar.
+If skipping: output `"Skipping code-review: [reason]"` and stop.
 
 ---
 

package/framework/skills/level-0-meta/morph-code-review-nextjs/SKILL.md

@@ -3,6 +3,8 @@ name: morph:code-review-nextjs
 description: Next.js code review checklist covering naming conventions, component architecture (Server vs Client), data fetching patterns, form implementation, state management, TypeScript/Zod discipline, feature boundaries, and testing. Use after implementing Next.js code, before creating PRs, or when reviewing TSX/TS code for compliance with MORPH-SPEC Next.js standards.
 user-invocable: true
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
+stacks:
+  - nextjs
 ---
 
 # Next.js Code Review Checklist
@@ -27,12 +29,12 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep
 git diff --name-only main...HEAD -- "*.tsx" "*.ts" | wc -l
 ```
 
-**Pular revisão se:**
-- 0 arquivos `.tsx`/`.ts` alterados → sem código frontend para revisar
-- Apenas mudanças em `*.json`, `*.md`, arquivos de config → escopo de infra
-- Já existe `.morph/features/$ARGUMENTS/5-implement/code-review-nextjs.md` criado hoje → já revisado
+**Skip review if:**
+- 0 `.tsx`/`.ts` files changed → no frontend code to review
+- Only changes in `*.json`, `*.md`, config files → infrastructure scope
+- `.morph/features/$ARGUMENTS/5-implement/code-review-nextjs.md` already exists from today → already reviewed
 
-Se skip: output `"Skipping code-review-nextjs: [motivo]"` e parar.
+If skipping: output `"Skipping code-review-nextjs: [reason]"` and stop.
 
 ---