@polymorphism-tech/morph-spec 4.11.1 → 4.13.0

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

@@ -53,6 +53,33 @@ Gather information before generating ideas. This step is what makes morph-aware
 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 1.5: Assess Complexity & Recommend Workflow
+
+Based on the context gathered in Step 1, evaluate the feature's complexity to select the appropriate workflow tier. Use this decision table:
+
+| Indicator | Fast-Track | Standard | Full |
+|-----------|-----------|----------|------|
+| Files affected | 1-3 | 3-10 | 10+ |
+| Entities/domains | 1 | 1-2 | 3+ |
+| External integrations | None | None | 1+ |
+| Infrastructure changes | No | No | Yes |
+| UI design needed | No | Optional | Yes |
+| Examples | CRUD field, rename, toggle, fix | Pagination, filter, export, refactor | Auth system, migration, platform redesign |
+
+**Actions:**
+1. Count entities, domains, integrations, and UI requirements from the feature request
+2. Match against the table above to determine the tier
+3. Set the workflow in state:
+   ```bash
+   morph-spec state set $ARGUMENTS workflow fast-track   # or standard / full
+   ```
+4. Inform the user of the recommendation via `AskUserQuestion` with options to confirm or override:
+   - Header: `Workflow`
+   - Question: "Based on complexity analysis, I recommend **{tier}** workflow ({N} phases). Override?"
+   - Options: `Confirm {tier}` / `Switch to standard` / `Switch to full` / `Switch to fast-track`
+
+> **Note:** The user can always override later with `morph-spec state set <feature> workflow <tier>`.
+
 ### Step 2: Ask Clarifying Questions
 
 Use `AskUserQuestion` to collect responses — **NEVER list questions as plain text**.
@@ -107,7 +134,7 @@ For each approach, document:
    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`.
+   Write the decision as an ADR (Architecture Decision Record) in `.morph/features/$ARGUMENTS/2-design/decisions.md`.
 
 3. **Update state** (mandatory — do not skip):
    ```bash

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

@@ -84,10 +84,10 @@ Types: `deploy`, `security`, `seo`, `performance`, `accessibility`, `legal-brazi
 - [ ] Response/distributed caching with invalidation
 - [ ] All I/O operations are async (no `.Result` / `.Wait()`)
 
-### Frontend (Blazor)
+### Frontend
 - [ ] Lazy loading, virtualization for large lists
 - [ ] Debounce search inputs
-- [ ] `@key` in loops, `ShouldRender()` for perf
+- [ ] Memoization for expensive renders
 
 ### Infrastructure
 - [ ] CDN for static assets, gzip/brotli compression

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

@@ -5,15 +5,11 @@ user-invocable: true
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep
 stacks:
   - dotnet
-  - blazor
 ---
 
 # Code Review Checklist
 
 > Comprehensive checklist for .NET code review: naming, architecture, clean code, duplication, and runtime patterns.
-> **Ref:** `framework/standards/core/coding.md` for naming conventions and style.
-> **Ref:** `framework/standards/core/architecture.md` for layer rules and SOLID.
-> **Ref:** `framework/standards/backend/database/ef-core.md` for DbContext patterns and background ops.
 > **Example:** `references/review-example.md` — filled-in review showing expected finding format and severity levels.
 > **Script:** `scripts/scan-csharp.mjs` — automated scan for CRITICAL/HIGH violations before manual review.
 > **Ref:** `references/review-guidelines.md` — false-positive rubric, confidence scoring, evidence format.
@@ -106,7 +102,7 @@ If skipping: output `"Skipping code-review: [reason]"` and stop.
 ## Async & Cancellation
 
 - [ ] `[CRITICAL]` CancellationToken propagated through entire call chain
-- [ ] `[CRITICAL]` No `.Result` or `.Wait()` (deadlock risk in Blazor Server)
+- [ ] `[CRITICAL]` No `.Result` or `.Wait()` (deadlock risk in ASP.NET)
 - [ ] `[HIGH]` No `async void` (except event handlers)
 - [ ] `[HIGH]` Timeout configured for external operations
 - [ ] `[MEDIUM]` `ConfigureAwait(false)` only in library code

package/framework/skills/level-0-meta/morph-code-review/scripts/scan-csharp.mjs

@@ -12,7 +12,7 @@
  *   node scan-csharp.mjs --diff                  # scan only changed files (git diff main...HEAD)
  *   node scan-csharp.mjs --diff --base=develop   # use different base branch
  *
- * Checks (ref: framework/standards/core/coding.md):
+ * Checks:
  *   - UPPER_SNAKE_CASE constants       → should be PascalCase
  *   - Hungarian notation               → strName, iCount, btnSubmit
  *   - Missing CancellationToken        → async methods without CT param

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

@@ -3,7 +3,7 @@ name: morph-frontend-review
 description: Complete frontend audit — validates design outputs (design-system, WCAG contrast,
   mockups), static accessibility scan (TSX + Razor), responsive screenshots at 3
   breakpoints via Playwright, axe-core a11y at runtime, and SEO (Next.js metadata). Covers Next.js
-  and Blazor. Triggered at end of phase-uiux and post-implementation.
+  Triggered at end of phase-uiux and post-implementation.
 argument-hint: "[feature-name]"
 user-invocable: true
 allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion,
@@ -12,7 +12,6 @@ allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion,
   mcp__playwright__browser_evaluate, mcp__playwright__browser_console_messages
 cliVersion: "4.8.19"
 stacks:
-  - blazor
   - nextjs
 ---
 
@@ -40,14 +39,14 @@ Beyond the stack, determine the **context** by examining what exists:
 
 ```bash
 # Check if design outputs exist
-ls .morph/features/$ARGUMENTS/2-ui/ 2>/dev/null
+ls .morph/features/$ARGUMENTS/1-ui/ 2>/dev/null
 
 # Check if implemented frontend files exist
-find . -name "*.tsx" -o -name "*.razor" 2>/dev/null | head -5
+find . -name "*.tsx" 2>/dev/null | head -5
 ```
 
-- If `.morph/features/$ARGUMENTS/2-ui/ui-design-system.md` exists → context includes **design validation**
-- If implemented frontend files exist (`.tsx`, `.razor`) → context includes **implementation validation**
+- If `.morph/features/$ARGUMENTS/1-ui/design-system.md` exists → context includes **design validation**
+- If implemented frontend files exist (`.tsx`) → context includes **implementation validation**
 - Both can coexist
 
 Store `stack`, `frontendPath`, `startCommand` and the detected context — all steps depend on them.
@@ -60,21 +59,21 @@ Store `stack`, `frontendPath`, `startCommand` and the detected context — all s
 morph-spec validate-feature $ARGUMENTS
 ```
 
-Verify existence and quality of the 4 mandatory outputs in `.morph/features/$ARGUMENTS/2-ui/`:
+Verify existence and quality of the 4 mandatory outputs in `.morph/features/$ARGUMENTS/1-ui/`:
 
 ```
-[ ] ui-design-system.md — color palette, typography tokens, spacing
-[ ] ui-mockups.md — wireframes with responsive states
-[ ] ui-components.md — technical component specs
-[ ] ui-flows.md — user journeys and edge cases
-[ ] WCAG AA Contrast: primary and text colors ≥ 4.5:1 (check ui-design-system.md)
+[ ] design-system.md — color palette, typography tokens, spacing
+[ ] mockups.md — wireframes with responsive states
+[ ] components.md — technical component specs
+[ ] flows.md — user journeys and edge cases
+[ ] WCAG AA Contrast: primary and text colors ≥ 4.5:1 (check design-system.md)
 [ ] Documented touch targets: ≥ 44x44px for mobile
 [ ] Loading/error/empty states defined in mockups
 ```
 
 **🚫 BLOCK** if `validate-feature` fails or mandatory outputs missing.
 
-Read `ui-design-system.md` and manually verify that primary and text colors have a contrast ratio
+Read `design-system.md` and manually verify that primary and text colors have a contrast ratio
 ≥ 4.5:1. Reference tools: WebAIM Contrast Checker (WCAG 2.1 AA criteria).
 
 ---
@@ -85,20 +84,19 @@ Read `ui-design-system.md` and manually verify that primary and text colors have
 node .claude/skills/morph-frontend-review/scripts/scan-accessibility.mjs $frontendPath
 ```
 
-The script automatically detects file extensions to determine Next.js (`.tsx`) vs
-Blazor (`.razor`). If `frontendPath` is not defined, the script uses `.` (project root).
+The script automatically detects file extensions for Next.js (`.tsx`).
+If `frontendPath` is not defined, the script uses `.` (project root).
 
 **Checks implemented:**
 
 | ID | Severity | Files | Checks |
 |----|-----------|---------|---------|
-| `IMG_MISSING_ALT` | CRITICAL | .tsx, .razor | `<img` missing `alt=` attribute |
-| `INPUT_MISSING_LABEL` | HIGH | .tsx, .razor | `<input`/`<InputText`/`<FluentTextField` without `aria-label`, `aria-labelledby`, or associated `<label for=` |
-| `HEADING_HIERARCHY` | HIGH | .tsx, .razor | Heading level skip (H1→H3 skipping H2) |
-| `LINK_NO_TEXT` | HIGH | .tsx, .razor | `<a` empty or with only icon and no `aria-label` |
-| `BUTTON_NO_TEXT` | HIGH | .tsx, .razor | `<button`/`<FluentButton` no text and no `aria-label` |
-| `AUTOPLAY_MEDIA` | MEDIUM | .tsx, .razor | `<video`/`<audio` with `autoPlay` without `muted` |
-| `FLUENT_CHECKBOX_NO_LABEL` | MEDIUM | .razor | `<FluentCheckbox` without `Label=` |
+| `IMG_MISSING_ALT` | CRITICAL | .tsx | `<img` missing `alt=` attribute |
+| `INPUT_MISSING_LABEL` | HIGH | .tsx | `<input` without `aria-label`, `aria-labelledby`, or associated `<label for=` |
+| `HEADING_HIERARCHY` | HIGH | .tsx | Heading level skip (H1→H3 skipping H2) |
+| `LINK_NO_TEXT` | HIGH | .tsx | `<a` empty or with only icon and no `aria-label` |
+| `BUTTON_NO_TEXT` | HIGH | .tsx | `<button` no text and no `aria-label` |
+| `AUTOPLAY_MEDIA` | MEDIUM | .tsx | `<video`/`<audio` with `autoPlay` without `muted` |
 
 **🚫 BLOCK** if any CRITICAL finding or HIGH count ≥ 3.
 
@@ -118,22 +116,6 @@ node .claude/skills/morph-code-review-nextjs/scripts/scan-nextjs.mjs $frontendPa
 
 **🚫 BLOCK** if CRITICAL findings found.
 
-### If DOTNET or FULLSTACK (Blazor):
-
-Manually verify the main checklist categories for the implemented feature:
-
-```
-[ ] Blazor components with correctly typed parameters
-[ ] EventCallback<T> for events — no direct Action/Func
-[ ] Dispose implemented where there are subscriptions (IDisposable)
-[ ] No business logic in .razor files (separate into @code or classes)
-[ ] StateHasChanged() called only when necessary
-[ ] Forms with EditForm and DataAnnotationsValidator
-[ ] Required fields with [Required] and defined error messages
-```
-
-**🚫 BLOCK** if any CRITICAL item is found.
-
 ---
 
 ## Step 4 — Responsive Screenshots (Playwright MCP)
@@ -149,7 +131,7 @@ node .claude/skills/morph-post-implementation/scripts/detect-dev-server.mjs "$st
 Extract the main feature URLs by reading `spec.md`:
 
 ```bash
-Read: .morph/features/$ARGUMENTS/1-design/spec.md
+Read: .morph/features/$ARGUMENTS/2-design/spec.md
 ```
 
 For each main page (max 3), capture screenshots at 3 breakpoints:
@@ -181,7 +163,7 @@ await mcp__playwright__browser_take_screenshot({
 ```
 
 Screenshots saved to: `.morph/features/$ARGUMENTS/visual-screenshots/`
-(works in both phase `2-ui` and `5-implement`)
+(works in both phase `1-ui` and `5-implement`)
 
 ### 4c. If dev server NOT available (exit 1):
 
@@ -313,7 +295,7 @@ Save to `.morph/features/$ARGUMENTS/visual-screenshots/morph-frontend-review-sum
 
 ### Step 1 — Design Outputs
 - validate-feature: ✅ PASS / 🚫 BLOCK
-- Outputs verified: ui-design-system.md, ui-mockups.md, ui-components.md, ui-flows.md
+- Outputs verified: design-system.md, mockups.md, components.md, flows.md
 - WCAG Contrast: {result}
 
 ### Step 2 — Static Accessibility Scan

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

@@ -108,7 +108,7 @@ Gather evidence to build a stack map. Run these in parallel:
 | `Glob` | `**/docker-compose*.yml` | Container services |
 | `Glob` | `database/migrations/**` | Supabase local dev |
 | `Glob` | `supabase/**` | Supabase project config |
-| `Glob` | `**/*.razor` | Blazor |
+
 | `Glob` | `**/Abstractions/IHandler.cs` | VSA pattern (KanaiyaKatarmal) |
 | `Glob` | `**/Pipelines/ValidationDecorator.cs` | VSA pipeline |
 | `Glob` | `**/Features/**/*Feature` | VSA feature folder suffix |
@@ -123,7 +123,7 @@ Read each found `package.json` for dependency names. Build an **evidence map**:
 ```
 stack:             [nextjs, dotnet, ...]
 integrations:      [supabase, docker, clerk, ...]
-uiLibrary:         shadcn | fluent-ui | mudblazor | null
+uiLibrary:         shadcn | null
 monorepo:          true | false
 frontendPath:      src/frontend (if monorepo)
 backendPath:       src/backend (if monorepo)
@@ -147,7 +147,7 @@ Ask at most 3 questions, only those that apply:
 |---|----------|-----------|---------|
 | 1 | *"In one sentence: what is the main purpose of **[ProjectName]**?"* | Always | README.md Overview |
 | 2 | *"Confirmed: frontend at `{frontendPath}`, backend at `{backendPath}`. Correct?"* | Monorepo detected | Validate paths before persisting |
-| 3 | *"Supabase Cloud (managed) or self-hosted?"* | Supabase detected | MCP URL configuration |
+| 3 | *"Supabase Cloud (managed) or self-hosted?"* | Supabase detected | Local dev configuration |
 
 Do **not** ask about technology already confirmed by file evidence.
 
@@ -348,10 +348,10 @@ And inform the user:
 ```
 ✓ Detected: Vertical Slice Architecture (IHandler.cs / *Feature folders)
   → config.json: architecture.style = "vertical-slice"
-  → morph-spec will use vsa-architect + contracts-vsa.cs for features
+  → morph-spec will use dotnet-senior + contracts-vsa.cs for features
 ```
 
-> This key is what activates `vsa-architect` instead of `domain-architect` during `/morph-proposal`.
+> This key is what activates `dotnet-senior` (VSA mode) during `/morph-proposal`.
 
 **If the project doesn't exist yet (new VSA project from scratch)**, also inform:
 
@@ -369,12 +369,8 @@ To create a new VSA project:
 For each detected integration with an available MCP:
 
 **Supabase detected:**
-> *"Configure Supabase MCP? Uses OAuth — no credentials needed."*
-- YES → write remote config to `.claude/settings.local.json`:
-  ```json
-  "supabase": { "type": "http", "url": "https://mcp.supabase.com/mcp" }
-  ```
-- NO → show snippet + `morph-spec mcp setup supabase`
+> *"Supabase CLI detected. Local Docker instance will be used for all database operations (`npx supabase start`)."*
+> No MCP configuration needed — CLI is the primary and only tool for Supabase interaction.
 
 **GitHub:**
 > *"Configure GitHub MCP? Requires Docker + a `GITHUB_PERSONAL_ACCESS_TOKEN`."*
@@ -396,6 +392,14 @@ For each detected integration with an available MCP:
   ```
 - NO → show snippet + `morph-spec mcp setup vercel`
 
+**Asaas detected** (integrations includes "asaas"):
+> *"Configure Asaas MCP? Provides API docs, schemas, and code examples for the Asaas payments API."*
+- YES → write config to `.claude/settings.local.json`:
+  ```json
+  "asaas": { "type": "http", "url": "https://docs.asaas.com/mcp" }
+  ```
+- NO → skip (use WebFetch on https://docs.asaas.com for API docs)
+
 Only offer Docker, Azure if explicitly detected in `.env.example`.
 
 > **Format rules for MCP configs:**
@@ -475,9 +479,9 @@ If the project stack suggests a non-standard workflow, ask the user:
 
 | Stack | Default Workflow | Alternative |
 |-------|-----------------|-------------|
-| Node.js CLI (no UI) | `nodejs-cli` (skips uiux/clarify/sync) | `standard` |
-| .NET + Blazor | `standard` (all phases) | — |
-| Next.js | `standard` (all phases) | — |
+| Simple feature | `fast-track` (proposal → tasks → implement) | `standard` |
+| Medium feature | `standard` (proposal → design → plan → tasks → implement) | `full` |
+| Complex feature | `full` (all phases including uiux + sync) | — |
 
 For Node.js CLI projects, update config:
 ```json

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

@@ -0,0 +1,225 @@
+---
+name: morph-parallel-dispatch
+description: Plan and execute parallel agent dispatch using P-Threads, F-Threads, and squad templates. Covers thread types, file scope isolation, dependency analysis, and conflict resolution for multi-domain features.
+user-invocable: true
+argument-hint: "[feature-name]"
+allowed-tools: Read, Bash, Glob, Grep
+---
+
+# Parallel Dispatch — MORPH-SPEC Thread Management
+
+> Orchestrate concurrent agent execution with strict file scope isolation, dependency-aware wave planning, and automatic conflict resolution.
+
+## Thread Types
+
+| Type | Code | Purpose | Lifecycle |
+|------|------|---------|-----------|
+| Base | B-Thread | Default implementation thread | Bounded by feature phase |
+| Parallel | P-Thread | Concurrent isolated execution | Short (1 task scope) |
+| Fusion | F-Thread | Best-of-N competing implementations | Short (1 prompt scope) |
+| Long-Running | L-Thread | Multi-session persistent work | Days/weeks |
+| Zero-Touch | Z-Thread | Fully autonomous execution | Bounded by trust level |
+
+## When to Use Parallel Execution
+
+| Condition | Decision |
+|-----------|----------|
+| 5+ independent tasks | Use P-Threads |
+| Multi-domain (backend + frontend) | Use P-Threads with squad templates |
+| 15+ files to create | Use P-Threads |
+| Tasks have zero dependency overlap | Use P-Threads |
+| Tasks share file scope | Do NOT parallelize |
+| Sequential data flow required | Do NOT parallelize |
+
+## Thread Lifecycle
+
+```
+pending --> running --> completed
+                    --> failed --> (retry) --> running
+                              --> killed
+```
+
+## Parallelization Planning
+
+### Step 1: Dependency Analysis
+
+```bash
+morph-spec detect-workflow $FEATURE_NAME
+
+# Identifies: parallelizable tasks, sequential chains, waves
+# Output:
+#   Parallelizable tasks: T001, T002, T003 (no dependencies)
+#   Sequential: T004 (depends on T001), T005 (depends on T002)
+#   Execution plan:
+#     Wave 1: [T001, T002, T003] (parallel)
+#     Wave 2: [T004, T005] (parallel, after wave 1)
+#     Wave 3: [T006] (sequential)
+```
+
+### Step 2: File Scope Assignment
+
+Assign exclusive file ownership to each parallel worker. No overlap allowed — if overlap is unavoidable, make it sequential.
+
+```
+Worker A (Backend):    Features/, Services/, Endpoints/, DTOs/
+Worker B (Frontend):   app/, components/, hooks/, styles/
+```
+
+**Example — Next.js + .NET VSA feature:**
+
+```
+P-Thread 1 (VSA Backend):
+  src/Features/UserAuth/
+    CreateUser.cs          (endpoint + handler)
+    GetUser.cs             (endpoint + handler)
+    UserValidator.cs       (FluentValidation)
+    Contracts/UserDto.cs   (shared DTOs)
+
+P-Thread 2 (Next.js Frontend):
+  app/users/
+    page.tsx               (route page)
+    layout.tsx             (layout)
+  components/users/
+    user-form.tsx           (shadcn/ui form)
+    user-table.tsx          (data table)
+  hooks/
+    use-users.ts            (React Query hook)
+```
+
+### Step 3: Choose Squad Template
+
+Pre-defined squad configurations for common feature shapes:
+
+| Template | Agents | Use Case |
+|----------|--------|----------|
+| `full-stack` | Backend lead + Frontend lead + Coordinator | Full-stack features |
+| `backend-only` | Backend specialists (3-4 agents) | API-only work |
+| `frontend-only` | Frontend specialists (2-3 agents) | UI-only work |
+
+```bash
+morph-spec squad-template list
+morph-spec squad-template show full-stack
+morph-spec squad-template use full-stack --feature=$FEATURE_NAME
+```
+
+## Execution Flow
+
+```
+Orchestrator
+    |
+    +-- spawn parallel: Worker A (files: Features/, Services/)
+    +-- spawn parallel: Worker B (files: app/, components/)
+    |
+    |   [Workers execute concurrently -- no interaction]
+    |
+    +-- wait-all (poll or explicit sync)
+    |
+    +-- merge results (check for conflicts)
+    +-- run integration validation
+    +-- report consolidated output
+```
+
+## P-Thread Rules
+
+1. **File scope isolation**: Each P-Thread has exclusive write access to its files
+2. **No cross-thread dependencies**: P-Thread tasks are self-contained
+3. **Shared read access**: All P-Threads can read spec.md, standards, contracts
+4. **Merge on completion**: Coordinator merges results after all P-Threads complete
+5. **Max concurrent**: Default 3, max 5 (configurable in llm-interaction.json)
+
+## Parallel vs Fusion
+
+| Aspect | Parallel (P-Thread) | Fusion (F-Thread) |
+|--------|---------------------|-------------------|
+| Goal | Divide scope | Compete on same scope |
+| Output | Different files | Same files, best one wins |
+| Workers collaborate? | No | No |
+| Merge | Combine all files | Select best implementation |
+| Use case | Large features | Design decisions, quality optimization |
+
+## Conflict Resolution
+
+### File Conflicts (two workers wrote same file)
+
+This should NOT happen if scopes are properly defined. If it does:
+
+```bash
+morph-spec agents review aggregate $FEATURE_NAME \
+  --agents=dotnet-senior,nextjs-expert \
+  --strategy=best-of-n
+```
+
+### Interface Mismatches (A expects contract B did not fulfill)
+
+- Document the mismatch in the coordinator report
+- Fix in post-merge sequential step
+- Update shared contracts/DTOs to reflect actual implementation
+
+## Long-Running Threads (L-Threads)
+
+L-Threads run periodic stop hooks every 30 minutes:
+
+```json
+{
+  "stopHooks": {
+    "enabled": true,
+    "interval": 30,
+    "maxRetries": 5,
+    "hooks": ["validate-and-continue", "validate-checkpoints"]
+  }
+}
+```
+
+### Resume Pattern
+
+```bash
+morph-spec bundle load $FEATURE_NAME
+# Load resume context, continue from checkpoint
+```
+
+## Thread State in state.json
+
+```json
+{
+  "threads": {
+    "thread-abc12345": {
+      "id": "thread-abc12345",
+      "type": "parallel",
+      "agent": "dotnet-senior",
+      "feature": "user-auth",
+      "status": "running",
+      "startedAt": "2026-02-19T00:00:00Z",
+      "events": [
+        { "type": "started", "timestamp": "..." },
+        { "type": "checkpoint_passed", "timestamp": "...", "checkpointNum": 1 }
+      ],
+      "metrics": {
+        "tasksCompleted": 3,
+        "checkpointsPassed": 1,
+        "errors": 0
+      }
+    }
+  }
+}
+```
+
+## Monitoring
+
+```bash
+morph-spec threads list $FEATURE_NAME
+morph-spec threads analytics $FEATURE_NAME
+morph-spec threads wait-all $FEATURE_NAME
+morph-spec threads wait-any $FEATURE_NAME
+```
+
+## Configuration
+
+```json
+{
+  "parallelExecution": {
+    "enabled": true,
+    "maxConcurrent": 3,
+    "defaultStrategy": "best-of-n"
+  }
+}
+```

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

@@ -104,8 +104,28 @@ Read validation output, fix reported issues, and re-run until it passes.
 
 ---
 
+### Step 4b — Verify RLS Policies (Supabase projects)
+
+> **Supabase CLI:** If the project uses Supabase, verify RLS policies on the local Docker instance:
+>
+> 1. Get DB URL: `npx supabase status` → extract `DB URL`
+> 2. Query: `psql <DB_URL> -c "SELECT tablename, policyname, cmd, qual FROM pg_policies WHERE schemaname = 'public'"`
+> 3. For each table modified in this feature, verify:
+>    - [ ] RLS is enabled (`ALTER TABLE ... ENABLE ROW LEVEL SECURITY`)
+>    - [ ] SELECT policy exists for authenticated users
+>    - [ ] INSERT/UPDATE/DELETE policies match feature requirements
+> 4. If any table is missing RLS → **flag as CRITICAL** (blocks PR)
+>
+> If local Supabase is not running, check for RLS policy files in the `supabase/migrations/` directory and verify they cover modified tables. If no Supabase in the stack, skip this step.
+
+---
+
 ## Step 5 — Smoke Test (Playwright MCP)
 
+> **Docker CLI:** Before smoke testing, verify local services are running: `docker ps --format "table {{.Names}}\t{{.Status}}"` — all expected containers should show "Up". If Supabase containers are down, run `npx supabase start` before proceeding.
+
+> **MCP:** Smoke testing via **Playwright MCP** is the primary method. If Playwright MCP is not available, fall back to `curl`/`WebFetch` for endpoint verification (limited — cannot test JS-rendered pages or interactions).
+
 ### 5a. Detect Dev Server
 
 ```bash

package/framework/skills/level-0-meta/morph-tool-usage-guide/SKILL.md

@@ -64,7 +64,7 @@ Dispatch specialist agents as **Task subagents** when ALL conditions are met:
 ```
 Feature with multiple active agents?
    │
-   ├─ design phase    → Dispatch domain-architect (complexity analysis)
+   ├─ design phase    → Dispatch architect (complexity analysis)
    │                    + tech leads (spec validation) — in PARALLEL
    │
    ├─ tasks phase     → Dispatch per-domain task planners (if spec has 50+ reqs
@@ -76,9 +76,9 @@ Feature with multiple active agents?
 ```
 
 **Key principle (from real-world usage):** Define subagents by **TASK**, not by **ROLE**.
-- ✅ "Analyze this proposal for DDD complexity and return level + blueprint" (task)
+- ✅ "Analyze this proposal for complexity and return level + blueprint" (task)
 - ✅ "Implement backend tasks T001-T005 for feature X" (task)
-- ❌ "Be a domain architect" (vague role assignment — poor results)
+- ❌ "Be an architect" (vague role assignment — poor results)
 
 ---
 
@@ -136,10 +136,8 @@ Criterion: if reading file B does not depend on the CONTENT of file A, read both
 | Phase | Primary MCPs | Dispatch subagents? |
 |-------|-------------|---------------------|
 | Proposal | GitHub (optional) | No |
-| Setup | GitHub (optional) | No |
 | UI/UX | Playwright, Context7 | No |
-| Design | Supabase, Context7, GitHub | Yes (domain-architect + schema in parallel) |
-| Clarify | Context7, GitHub | No |
+| Design | Supabase, Context7, GitHub | Yes (architect + schema in parallel) |
 | Plan | Context7, GitHub | No |
 | Tasks | Context7, GitHub | Yes (when spec has 20+ reqs or 3+ domains) |
 | Implement | Supabase, Context7, Playwright, GitHub | Yes (when tasks.total ≥ 6 and 2+ domains) |
@@ -218,7 +216,6 @@ For the canonical list of MCPs, their tools, phase relevance, and fallbacks, see
 | Setup | GitHub | `gh` CLI |
 | UI/UX | Playwright, Context7 | WebFetch, Read CSS |
 | Design | Supabase, Context7, GitHub | Grep + Read code |
-| Clarify | Context7, GitHub | WebSearch |
 | Tasks | Context7, GitHub | WebSearch, `gh` CLI |
 | Implement | Supabase, Context7, Playwright, GitHub | CLI tools |
 
@@ -236,7 +233,6 @@ When the `superpowers` plugin is installed, additional skills enhance each phase
 |-------|------------------|---------|
 | Setup | `using-git-worktrees` | Isolate feature work |
 | Design | `writing-plans`, `brainstorming` | Structure approach, explore alternatives |
-| Clarify | `systematic-debugging` | Investigate technical ambiguities |
 | Tasks | `writing-plans`, `executing-plans` | Plan and execute implementation |
 | Implement | `test-driven-development`, `systematic-debugging`, `requesting-code-review` | TDD, debug failures, review |