@curdx/flow 2.0.21 → 2.2.0

package/{commands/implement.md → skills/implement/SKILL.md}

@@ -2,7 +2,8 @@
 name: implement
 description: Execute spec tasks — the Strategy Router picks linear/subagent/stop-hook/wave based on task characteristics. Atomic commit per task.
 argument-hint: "[spec-name] [--strategy=auto|linear|subagent|stop-hook|wave] [--task=<id>] [--quick]"
-allowed-tools: [Read, Write, Edit, Bash, Task, Grep, Glob]
+disable-model-invocation: true
+allowed-tools: [Read, Write, Edit, Bash, Agent, Grep, Glob]
 ---
 
 # Flow Implement — Execute Spec
@@ -77,7 +78,7 @@ echo "✓ Selected strategy: $STRATEGY"
 
 **Decision tree explanation**:
 - Few tasks / strong dependencies → `linear` (main agent executes sequentially)
-- Many parallel opportunities → `wave` (parallel Task dispatch within a wave)
+- Many parallel opportunities → `wave` (parallel Agent dispatch within a wave)
 - Long chain + quick mode → `stop-hook` (auto-loop, requires hook support)
 - Medium scale → `subagent` (isolated context per task)
 
@@ -127,7 +128,7 @@ If there are 5 failures, stop + TASK_FAILED.
 For each remaining task, dispatch flow-executor:
 
 ```
-Task:
+Agent:
   subagent_type: general-purpose
   description: "Execute $SPEC_NAME task $TASK_ID"
   prompt: |
@@ -159,160 +160,19 @@ After the agent completes, read the output marker:
 
 ### Strategy: wave
 
-@${CLAUDE_PLUGIN_ROOT}/knowledge/wave-execution.md
+See `skills/implement/references/wave-execution.md` for the full walkthrough.
+Knowledge-layer canonical algorithm: `@${CLAUDE_PLUGIN_ROOT}/knowledge/wave-execution.md`.
 
-**Core**: consecutive `[P]` tasks form a wave, dispatch multiple Tasks in parallel within a single message, serial across waves.
+**Core**: consecutive `[P]` tasks form a wave; dispatch multiple Agent calls in parallel within a single response; serial across waves. The execution loop is:
 
-#### Step 1: DAG Analysis
+1. **DAG analysis** — group remaining `[ ]` tasks by `[P]` / `[SEQUENTIAL]` / `[VERIFY]` tags; conflicting `Files` sets split into a new wave.
+2. **Pre-conflict detection** — within each wave, assert per-task `Files` are disjoint; auto-split if not.
+3. **Dispatch** — list multiple `Agent(...)` tool calls in a single main-agent response (splitting across responses = serial degradation; nested `Agent` dispatches forbidden). Each Agent prompt follows the subagent strategy's uniform format (see `references/wave-execution.md` Step 3).
+4. **Aggregate** — parse each result for `TASK_COMPLETE` / `TASK_FAILED`; run post-hoc conflict detection via git diff to confirm executors only touched declared files.
+5. **Failure handling** — 0 failed → next wave; 1 failed → `config.wave_fail_policy` (`continue-on-single` or `stop-on-any`); ≥2 failed → likely environment issue, stop immediately; cumulative `failed_attempts >= 3` → stop, user intervention.
+6. **Progress feedback** — print a wave summary after each wave (see `references/wave-execution.md` Step 6).
 
-Read remaining `[ ]` tasks from tasks.md and group per the rules:
-
-```
-for task in remaining tasks:
-    if task has [SEQUENTIAL] or [VERIFY]:
-        → own wave (breaks parallelism)
-    elif task has [P]:
-        → check whether Files conflict with current_wave
-          conflict → start a new wave
-          no conflict → add to current_wave
-    else:
-        → own wave (no [P] = serial)
-```
-
-Output wave list:
-```
-Wave 1 [P×3]: 1.1 1.2 1.3
-Wave 2 [VERIFY]: 1.4
-Wave 3: 1.5
-Wave 4 [P×2]: 1.6 1.7
-```
-
-#### Step 2: Pre-Conflict Detection
-
-For each wave, verify that Files across all tasks are **disjoint**:
-
-```python
-for wave in waves:
-    all_files = []
-    for task in wave:
-        if set(task.files) & set(all_files):
-            warn(f"Within wave, {task.id} modifies the same file as a prior task")
-            # split into the next wave
-        all_files.extend(task.files)
-```
-
-If the planner mis-tagged `[P]` (modifies the same file), split the wave automatically at execution time rather than failing outright.
-
-#### Step 3: Dispatch a Single Wave (**key: within a single response**)
-
-```
-# List multiple Task tool calls in one response of the main agent:
-Task(description="Execute 1.1", prompt=<...flow-executor + task_id=1.1...>)
-Task(description="Execute 1.2", prompt=<...flow-executor + task_id=1.2...>)
-Task(description="Execute 1.3", prompt=<...flow-executor + task_id=1.3...>)
-```
-
-Each Task prompt follows a uniform format (similar to subagent strategy):
-
-```
-You are the flow-executor agent. Full definition:
-${CLAUDE_PLUGIN_ROOT}/agents/flow-executor.md
-
-Execute a single task:
-  spec_name: $SPEC_NAME
-  task_id: <specific ID, e.g., 1.2>
-  quick_mode: $QUICK
-
-**You may only modify the following files** (touching anything else is disallowed):
-  <task.files>
-
-Required reading:
-- .flow/specs/$SPEC_NAME/tasks.md
-- .flow/specs/$SPEC_NAME/.state.json  
-- .flow/specs/$SPEC_NAME/design.md (if referencing AD-NN)
-
-Output:
-- TASK_COMPLETE: <task_id>  or
-- TASK_FAILED: <task_id> + reason
-```
-
-**Not allowed**:
-- Splitting multiple Task calls across multiple responses (that is serial degradation)
-- Nesting another Task dispatch inside a Task
-
-#### Step 4: Aggregate Wave Results
-
-Wait for all Tasks to return:
-
-```python
-completed = []; failed = []
-for task, result in zip(wave, results):
-    if "TASK_COMPLETE" in result:
-        completed.append(task)
-    elif "TASK_FAILED" in result:
-        failed.append(task)
-
-# Post-hoc conflict detection (verify executors did not touch out-of-scope files)
-for task in completed:
-    actual_files = git_diff_files_touched_by(task)
-    declared = set(task.files)
-    unexpected = actual_files - declared
-    if unexpected:
-        warn(f"Task {task.id} modified undeclared files: {unexpected}")
-```
-
-#### Step 5: Wave Failure Handling
-
-```
-len(failed) == 0:
-  → continue to the next wave
-
-len(failed) == 1:
-  → failed_attempts += 1
-  → based on config.wave_fail_policy:
-      "continue-on-single": continue to the next wave, report failure at the end
-      "stop-on-any": stop immediately
-
-len(failed) >= 2:
-  → likely environment issue (missing deps/tsc error/permissions)
-  → stop immediately, suggest npx @curdx/flow doctor
-  
-failed_attempts >= 3 (cumulative):
-  → stop, user intervention required
-```
-
-#### Step 6: Progress Feedback
-
-```
-▶ Wave 2/5 complete
-  ✓ 1.1 feat(auth): create module skeleton (abc123)
-  ✓ 1.2 feat(user): create user types (def456)
-  ✓ 1.3 feat(session): init token module (ghi789)
-
-▶ Wave 3/5 starting (VERIFY)...
-```
-
-#### Configuration
-
-`.flow/config.json`:
-```json
-{
-  "execution": {
-    "strategy": "wave",
-    "max_parallel": 5,
-    "wave_fail_policy": "continue-on-single"
-  }
-}
-```
-
-- `max_parallel`: max N parallel within a wave (to avoid API rate limits, default 5)
-- `wave_fail_policy`: single-task failure behavior
-
-#### Pitfalls (see knowledge/wave-execution.md for the detailed version)
-
-- Stray `[P]` → conflict detection as a safety net
-- Wave too large → max_parallel auto-splits
-- Implicit read-write dependencies → planner should avoid this kind of `[P]`
+Configuration under `.flow/config.json.execution`: `strategy: "wave"`, `max_parallel: 5` (wave-parallel ceiling), `wave_fail_policy: "continue-on-single" | "stop-on-any"`.
 
 ### Strategy: stop-hook
 

package/skills/implement/references/wave-execution.md

@@ -0,0 +1,162 @@
+# Wave Execution Strategy — Detailed Walkthrough
+
+Skill-scoped reference for `skills/implement/SKILL.md`. Loaded only when the
+implement skill routes to the `wave` strategy. The knowledge-layer canonical
+algorithm lives in `@${CLAUDE_PLUGIN_ROOT}/knowledge/wave-execution.md`;
+this file is the walkthrough the skill itself embeds for implementers.
+
+**Core**: consecutive `[P]` tasks form a wave, dispatch multiple Agent calls in
+parallel within a single message, serial across waves.
+
+## Step 1: DAG Analysis
+
+Read remaining `[ ]` tasks from tasks.md and group per the rules:
+
+```
+for task in remaining tasks:
+    if task has [SEQUENTIAL] or [VERIFY]:
+        → own wave (breaks parallelism)
+    elif task has [P]:
+        → check whether Files conflict with current_wave
+          conflict → start a new wave
+          no conflict → add to current_wave
+    else:
+        → own wave (no [P] = serial)
+```
+
+Output wave list:
+```
+Wave 1 [P×3]: 1.1 1.2 1.3
+Wave 2 [VERIFY]: 1.4
+Wave 3: 1.5
+Wave 4 [P×2]: 1.6 1.7
+```
+
+## Step 2: Pre-Conflict Detection
+
+For each wave, verify that Files across all tasks are **disjoint**:
+
+```python
+for wave in waves:
+    all_files = []
+    for task in wave:
+        if set(task.files) & set(all_files):
+            warn(f"Within wave, {task.id} modifies the same file as a prior task")
+            # split into the next wave
+        all_files.extend(task.files)
+```
+
+If the planner mis-tagged `[P]` (modifies the same file), split the wave automatically at execution time rather than failing outright.
+
+## Step 3: Dispatch a Single Wave (key: within a single response)
+
+```
+# List multiple Agent tool calls in one response of the main agent:
+Agent(description="Execute 1.1", prompt=<...flow-executor + task_id=1.1...>)
+Agent(description="Execute 1.2", prompt=<...flow-executor + task_id=1.2...>)
+Agent(description="Execute 1.3", prompt=<...flow-executor + task_id=1.3...>)
+```
+
+Each Agent prompt follows a uniform format (similar to subagent strategy):
+
+```
+You are the flow-executor agent. Full definition:
+${CLAUDE_PLUGIN_ROOT}/agents/flow-executor.md
+
+Execute a single task:
+  spec_name: $SPEC_NAME
+  task_id: <specific ID, e.g., 1.2>
+  quick_mode: $QUICK
+
+**You may only modify the following files** (touching anything else is disallowed):
+  <task.files>
+
+Required reading:
+- .flow/specs/$SPEC_NAME/tasks.md
+- .flow/specs/$SPEC_NAME/.state.json
+- .flow/specs/$SPEC_NAME/design.md (if referencing AD-NN)
+
+Output:
+- TASK_COMPLETE: <task_id>  or
+- TASK_FAILED: <task_id> + reason
+```
+
+**Not allowed**:
+- Splitting multiple Agent calls across multiple responses (that is serial degradation)
+- Nesting another Agent dispatch inside an Agent
+
+## Step 4: Aggregate Wave Results
+
+Wait for all Agent calls to return:
+
+```python
+completed = []; failed = []
+for task, result in zip(wave, results):
+    if "TASK_COMPLETE" in result:
+        completed.append(task)
+    elif "TASK_FAILED" in result:
+        failed.append(task)
+
+# Post-hoc conflict detection (verify executors did not touch out-of-scope files)
+for task in completed:
+    actual_files = git_diff_files_touched_by(task)
+    declared = set(task.files)
+    unexpected = actual_files - declared
+    if unexpected:
+        warn(f"Task {task.id} modified undeclared files: {unexpected}")
+```
+
+## Step 5: Wave Failure Handling
+
+```
+len(failed) == 0:
+  → continue to the next wave
+
+len(failed) == 1:
+  → failed_attempts += 1
+  → based on config.wave_fail_policy:
+      "continue-on-single": continue to the next wave, report failure at the end
+      "stop-on-any": stop immediately
+
+len(failed) >= 2:
+  → likely environment issue (missing deps/tsc error/permissions)
+  → stop immediately, suggest npx @curdx/flow doctor
+
+failed_attempts >= 3 (cumulative):
+  → stop, user intervention required
+```
+
+## Step 6: Progress Feedback
+
+```
+▶ Wave 2/5 complete
+  ✓ 1.1 feat(auth): create module skeleton (abc123)
+  ✓ 1.2 feat(user): create user types (def456)
+  ✓ 1.3 feat(session): init token module (ghi789)
+
+▶ Wave 3/5 starting (VERIFY)...
+```
+
+## Configuration
+
+`.flow/config.json`:
+```json
+{
+  "execution": {
+    "strategy": "wave",
+    "max_parallel": 5,
+    "wave_fail_policy": "continue-on-single"
+  }
+}
+```
+
+- `max_parallel`: max N parallel within a wave (to avoid API rate limits, default 5)
+- `wave_fail_policy`: single-task failure behavior
+
+## Pitfalls
+
+See `@${CLAUDE_PLUGIN_ROOT}/knowledge/wave-execution.md` for the detailed version.
+
+- Stray `[P]` → conflict detection as a safety net
+- Wave too large → max_parallel auto-splits
+- Implicit read-write dependencies → planner should avoid this kind of `[P]`

package/{commands/init.md → skills/init/SKILL.md}

@@ -2,6 +2,7 @@
 name: init
 description: Initialize the CurdX-Flow project structure (create the .flow/ directory and core files)
 argument-hint: "[--force]"
+disable-model-invocation: true
 allowed-tools: [Read, Write, Bash, AskUserQuestion]
 ---
 

package/{commands/review.md → skills/review/SKILL.md}

@@ -1,8 +1,9 @@
 ---
 name: review
-description: Two-stage code review — Stage 1 spec compliance, Stage 2 code quality. Optional flags add adversarial review or edge-case hunting.
-argument-hint: "[--stage=<1|2|both>] [--adversarial] [--edge-case]"
-allowed-tools: [Read, Bash, Task, Grep, Glob]
+description: Two-stage code review — Stage 1 spec compliance, Stage 2 code quality. Optional flags add adversarial review, edge-case hunting, or developer-experience audit.
+argument-hint: "[--stage=<1|2|both>] [--adversarial] [--edge-case] [--devex]"
+disable-model-invocation: true
+allowed-tools: [Read, Bash, Agent, Grep, Glob]
 ---
 
 # Two-Stage Code Review
@@ -18,6 +19,7 @@ Distinct from `/curdx-flow:verify`:
 | `--stage=<1\|2\|both>` | `both` | Stage 1 = spec compliance only. Stage 2 = code quality only. `both` = sequential. |
 | `--adversarial` | off | Add an adversarial review pass across applicable categories (zero findings requires proof-of-checking, not fabrication). |
 | `--edge-case` | off | Add edge-case hunting across applicable categories. Produces a test-gap checklist. |
+| `--devex` | off | Apply the DevEx audit: naming, comments, structure, error handling, setup, types, tests, and developer loop. Gate: `@${CLAUDE_PLUGIN_ROOT}/gates/devex-gate.md`. |
 
 ## Preflight
 
@@ -38,6 +40,7 @@ done
 FLAG_STAGE=$(echo "$ARGUMENTS" | grep -oP -- '--stage=\K[^\s]+' || echo "both")
 FLAG_ADV=$(echo "$ARGUMENTS" | grep -q -- '--adversarial' && echo 1 || echo 0)
 FLAG_EDGE=$(echo "$ARGUMENTS" | grep -q -- '--edge-case' && echo 1 || echo 0)
+FLAG_DEVEX=$(echo "$ARGUMENTS" | grep -q -- '--devex' && echo 1 || echo 0)
 ```
 
 ## Stage 1 — Spec compliance
@@ -89,6 +92,27 @@ Dispatch `flow-edge-hunter` across the applicable categories (skip N/A with one-
 
 Output: test-gap checklist with suggested test cases.
 
+## Optional: DevEx audit
+
+If `--devex`:
+Pass the DevEx gate at `@${CLAUDE_PLUGIN_ROOT}/gates/devex-gate.md` as
+additional context to `flow-reviewer`. The gate adds these dimensions to
+Stage 2:
+
+1. **Naming** — identifier clarity, consistency across modules.
+2. **Comments** — only non-obvious WHY; no redundant WHAT.
+3. **Structure** — file and function sizes, colocation of related code.
+4. **Error handling** — at system boundaries only; no defensive guards inside trusted paths.
+5. **Setup** — `npm install && npm test` green on a fresh clone.
+6. **Types** — strictness, no unexplained `any` / `unknown`.
+7. **Tests** — failure messages, fixture clarity, no flake.
+8. **Dev loop** — time from code-change to feedback.
+
+`flow-reviewer` is NOT edited for `--devex` — the gate file is injected
+into the reviewer dispatch prompt as reference context, so the agent
+stays generic. Output: a "DevEx" section in the review report with
+per-dimension verdicts.
+
 ## Report
 
 **Landing check**: sub-agent responses can be truncated. After dispatching review agents, verify the report actually landed on disk:
@@ -121,6 +145,15 @@ Consolidated output: `.flow/specs/$SPEC_NAME/review-report.md`:
 ## Edge Cases (if run)
 ...
 
+## DevEx (if run)
+- Naming:         <verdict>
+- Structure:      <verdict>
+- Error handling: <verdict>
+- Setup:          <verdict>
+- Types:          <verdict>
+- Tests:          <verdict>
+- Dev loop:       <verdict>
+
 ## Verdict
 - [ ] APPROVED
 - [X] CHANGES REQUIRED — <n> blockers
@@ -135,6 +168,7 @@ Consolidated output: `.flow/specs/$SPEC_NAME/review-report.md`:
   Stage 2 findings: <n>
   Adversarial findings: <n>   (if --adversarial)
   Edge-case gaps: <n>         (if --edge-case)
+  DevEx findings: <n>         (if --devex)
   Verdict: CHANGES REQUIRED
 
 Report: .flow/specs/<name>/review-report.md
@@ -149,4 +183,5 @@ Next: address blockers, then re-run /curdx-flow:review.
 - `flow-edge-hunter` agent: `@${CLAUDE_PLUGIN_ROOT}/agents/flow-edge-hunter.md`
 - `adversarial-review-gate`: `@${CLAUDE_PLUGIN_ROOT}/gates/adversarial-review-gate.md`
 - `edge-case-gate`: `@${CLAUDE_PLUGIN_ROOT}/gates/edge-case-gate.md`
+- `devex-gate`: `@${CLAUDE_PLUGIN_ROOT}/gates/devex-gate.md`
 - Knowledge: `@${CLAUDE_PLUGIN_ROOT}/knowledge/two-stage-review.md`

package/skills/security-audit/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: security-audit
-description: Invoke when the user wants a security review — OWASP Top 10, STRIDE threat modeling, credential handling, injection, secrets, sensitive data handling. Triggers on "security", "auth", "authentication", "credential", "password", "secret", "API key", "token", "OWASP", "STRIDE", "CVE", "vulnerability", "injection", "XSS", "CSRF", "SSRF", "SQL injection", "hardcoded secret", "sensitive data", "leak", "will my API key leak", "is this safe".
+description: Use when the user needs security review of code, specs, credentials, sensitive data, or dependency risk.
+when_to_use: Triggers on "security", "auth", "authentication", "credential", "password", "secret", "API key", "token", "OWASP", "STRIDE", "CVE", "vulnerability", "injection", "XSS", "CSRF", "SSRF", "SQL injection", "hardcoded secret", "sensitive data", "leak", "will my API key leak", "is this safe".
 allowed-tools: [Read, Grep, Glob, Bash, WebSearch]
 ---
 

package/{commands/spec.md → skills/spec/SKILL.md}

@@ -2,7 +2,8 @@
 name: spec
 description: Generate or refresh a feature specification. By default runs research → requirements → design → tasks in sequence. Flags let you target a single phase, stop early, regenerate, or tack on a multi-dimensional planning review.
 argument-hint: "[--phase=<X[,Y,...]>] [--until=<X>] [--review[=<dim[,dim]>]] [--regenerate] [--resume]"
-allowed-tools: [Read, Write, Bash, Task, AskUserQuestion]
+disable-model-invocation: true
+allowed-tools: [Read, Write, Bash, Agent, AskUserQuestion]
 ---
 
 # Generate or Refresh the Active Spec
@@ -70,7 +71,7 @@ Read and update `.state.json.phase` after each phase succeeds.
 
 ## Phase execution
 
-For each phase in the resolved list, dispatch a sub-agent via the `Task` tool:
+For each phase in the resolved list, dispatch a subagent via the `Agent` tool:
 
 ### research → `flow-researcher`
 Inputs: spec goal + one-line description from `.state.json`.
@@ -176,7 +177,7 @@ If `--review` (or `--review=<dims>`) is present:
 
 1. **Precondition**: `design.md` must exist. If missing, error: "Design missing. Run `/curdx-flow:spec --phase=design` first."
 2. Parse the dims: `all` expands to `ceo,eng,design,dx`.
-3. Dispatch review agents in parallel via `Task` (one per dim):
+3. Dispatch review agents in parallel via `Agent` (one per dim):
 
 | Dim | Agent | Focus |
 |-----|-------|-------|

package/{commands/start.md → skills/start/SKILL.md}

@@ -2,7 +2,8 @@
 name: start
 description: Smart entry point — create a new spec, resume an existing one, or switch between specs. Replaces v1's /start + /switch.
 argument-hint: "[<spec-name>] [\"<one-line goal>\"] [--resume] [--list] [--mode=<fast|standard|enterprise>]"
-allowed-tools: [Read, Write, Bash, AskUserQuestion, Task]
+disable-model-invocation: true
+allowed-tools: [Read, Write, Bash, AskUserQuestion, Agent]
 ---
 
 # Start or Resume a Feature Spec

package/skills/ui-sketch/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: ui-sketch
-description: Invoke when the user wants UI design drafts — components, layouts, variants, mockups, CSS/theme/styling decisions. Triggers on "design UI", "UI design", "component layout", "variants", "wireframe", "mockup", "prototype", "sketch", "draft layout", "visual design", "styling", "CSS", "theming", "dark mode", "responsive design", "color scheme", "build me a UI", "show several variants", "try different colors".
+description: Use when the user needs UI design drafts, layout variants, mockups, prototypes, or styling direction.
+when_to_use: Triggers on "design UI", "UI design", "component layout", "variants", "wireframe", "mockup", "prototype", "sketch", "draft layout", "visual design", "styling", "CSS", "theming", "dark mode", "responsive design", "color scheme", "build me a UI", "show several variants", "try different colors".
 allowed-tools: [Read, Write, Bash, WebSearch]
 ---
 

package/skills/verify/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: verify
+description: Goal-backward verification — trace from every FR / AC / AD in the active spec to the code and tests, detect stubs and fake completions. The differentiator command. Optionally adds multi-source coverage audit with --strict.
+argument-hint: "[--strict]"
+disable-model-invocation: true
+context: fork
+agent: flow-verifier
+---
+
+# Goal-Backward Verification
+
+Verify the active `.flow/` spec using goal-backward analysis. This is the
+differentiator step — catches Claude's most common failure: claiming "done"
+while the code is a stub, a fake completion, or an untested AC.
+
+**Arguments**: `$ARGUMENTS` (optionally `--strict` for multi-source coverage audit).
+
+## Preflight
+
+- `.flow/` must exist and `.flow/.active-spec` must be non-empty.
+- `.flow/specs/<active>/requirements.md`, `design.md`, `tasks.md` must all exist.
+
+If any precondition fails, emit a clear error and stop.
+
+## What to verify
+
+Read the active spec's `requirements.md` (for FR-NN and AC-N.N),
+`design.md` (for AD-NN), `tasks.md` (for T-N.M with per-task Verify
+commands), and `.flow/STATE.md` (for D-NN decisions).
+
+For EACH assertion in the spec, walk goal-backward:
+
+1. Classify the assertion as **UI-facing** (uses words like "user sees",
+   "click", "render", or names a UI element) vs. **code-only** (schema,
+   API response, performance, error envelope, etc.).
+2. For **code-only**: grep the codebase for matching symbols, find the
+   implementing file + line, find a test that exercises it, run the test
+   (`npm test` or the declared `Verify` command), capture pass/fail.
+3. For **UI-facing**: browser verification via `mcp__chrome_devtools__*`
+   is required. `jsdom` / `happy-dom` unit tests are insufficient. If the
+   browser MCP isn't available, mark the AC **unverified — browser MCP
+   missing** and include a CRITICAL section in the report; do NOT
+   silently pass based on code reading alone.
+
+Also scan for **stub / fake-completion** patterns on FR-covered paths:
+
+- `throw new Error("not implemented")`, `// TODO:` on critical paths
+- `return null` / `return {}` where real output is expected
+- tests with only `it.skip(...)` or no assertions
+- code returning mocked fixtures instead of calling real collaborators
+
+Run the per-task `Verify` commands from `tasks.md` and record pass/fail.
+
+## --strict mode
+
+When `$ARGUMENTS` contains `--strict`, also apply the multi-source coverage
+audit at `@${CLAUDE_PLUGIN_ROOT}/gates/coverage-audit-gate.md`. Cross-check:
+
+- Every FR ↔ AC ↔ AD ↔ task ↔ test ↔ commit must reference each other.
+- Research conclusions: was the recommended library / approach actually used?
+- Every D-NN in `.flow/STATE.md` that references this spec is honored.
+
+## Deliverables
+
+Write `.flow/specs/<name>/verification-report.md` with:
+
+- Summary counts (FR / AC / AD coverage, stub count, failing Verify count)
+- Detailed Checklist (one section per FR / AC / AD with Evidence + Verdict)
+- Stub / fake findings with file paths
+- Verdict: `PASS` / `PARTIAL` / `MISSING`
+
+Exact format schema is in `agents/flow-verifier.md` Step 6 (loaded via the
+`agent: flow-verifier` frontmatter field — its system prompt governs).
+
+**Landing check**: your FIRST substantive action after gathering findings
+must be the `Write` tool call with the complete report. Do NOT preview the
+report as assistant text first; that doubles output tokens and risks
+truncating inside the Write call. After Write succeeds, respond with a
+≤ 5-line summary only.
+
+## Apply the gate
+
+Per `@${CLAUDE_PLUGIN_ROOT}/gates/verification-gate.md`:
+
+- Any `STUB` or `MISSING` finding on a non-deferred FR blocks completion.
+- Any failing Verify command blocks completion.
+- Waive only with an explicit D-NN decision logged in `.flow/STATE.md`.
+
+## Output to user (≤ 5 lines after Write succeeds)
+
+```
+✓ Verification complete: <spec-name>
+  FR coverage: N/M implemented (S stub, K missing)
+  AC coverage: N/M tested
+  Verdict: PASS | PARTIAL | MISSING
+  Report: .flow/specs/<name>/verification-report.md
+```
+
+Next: address findings, then re-run `/curdx-flow:verify`, or run `/curdx-flow:review`.

package/templates/CONTEXT.md.tmpl

@@ -50,4 +50,4 @@
 
 ---
 
-_Generated by `/flow-init` on {{CREATED_DATE}}. Update to match your actual preferences._
+_Generated by `/curdx-flow:init` on {{CREATED_DATE}}. Update to match your actual preferences._

package/templates/PROJECT.md.tmpl

@@ -56,4 +56,4 @@ TODO:
 
 ---
 
-_Generated by `/flow-init` on {{CREATED_DATE}}. Maintainer: {{USER_NAME}}_
+_Generated by `/curdx-flow:init` on {{CREATED_DATE}}. Maintainer: {{USER_NAME}}_

package/templates/config.json.tmpl

@@ -2,13 +2,14 @@
   "$schema": "https://raw.githubusercontent.com/wdx/curdx-flow/main/schemas/config.schema.json",
   "version": "1.0",
   "mode": "standard",
-  "_mode_options": "sketch | fast | standard | enterprise | autonomous",
+  "_mode_options": "fast | standard | enterprise",
 
   "execution": {
     "strategy": "auto",
     "_strategy_options": "auto | subagent | stop-hook | wave | linear",
     "max_parallel": 5,
-    "subagent_threshold": 8
+    "subagent_threshold": 8,
+    "wave_fail_policy": "continue-on-single"
   },
 
   "gates": {
@@ -18,14 +19,13 @@
     ],
     "standard_mode": [
       "tdd-gate",
-      "coverage-audit-gate",
-      "simplicity-gate"
+      "coverage-audit-gate"
     ],
     "enterprise_mode": [
       "adversarial-review-gate",
       "edge-case-gate",
-      "hard-gate",
-      "security-gate"
+      "security-gate",
+      "devex-gate"
     ]
   },
 

package/templates/progress.md.tmpl

@@ -45,7 +45,7 @@ _(none)_
 
 <!-- What to do next. Must be filled in before ending the session. -->
 
-- [ ] Enter the research phase: run `/flow-research`
+- [ ] Enter the research phase: run `/curdx-flow:spec --phase=research`
 
 ## Questions for User
 
@@ -55,4 +55,4 @@ _(none)_
 
 ---
 
-_Spec initialized on {{CREATED_DATE}}._
+_Spec initialized by `/curdx-flow:start` on {{CREATED_DATE}}._