@curdx/flow 1.1.11 → 2.0.0-beta.2

package/commands/verify.md

@@ -1,124 +1,142 @@
 ---
 name: verify
-description: goal reverse verification — trace back from FR/AC/AD to check whether the code actually implements them, detect stubs / fake completion. Dispatches flow-verifier.
-argument-hint: "[spec-name]"
+description: Goal-backward verification — trace from every FR / AC / AD in the 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]"
 allowed-tools: [Read, Bash, Task, Grep, Glob]
 ---
 
-# Flow Verify — Goal Reverse Verification
+# Goal-Backward Verification
 
-Dispatch the `flow-verifier` agent to confirm, starting from the spec, that the code truly implements the requirements; do not trust any "done" claim.
+This is the **differentiator command**: it scans the implementation against the spec's own requirements and catches the most common Claude failure mode — claiming "done" while actual code is a stub or fake completion.
 
-## When to Use
+## Flags
 
-- After `/curdx-flow:implement` completes
-- Final gate before a PR
-- When you suspect a feature is a fake implementation (stub/TODO)
+| Flag | Default | Purpose |
+|------|---------|---------|
+| `--strict` | off | Also run multi-source coverage audit (FR / AC / AD / Research conclusions / D-NN decisions) — replaces v1's `/audit` command. |
 
-## Step 1: Parse + Preflight Check
+## Preflight
 
 ```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "❌ No active spec. Run /curdx-flow:switch or /curdx-flow:start first"; exit 1; }
+[ ! -d ".flow" ] && { echo "✗ Not a CurDX-Flow project."; exit 1; }
 
-DIR=".flow/specs/$SPEC_NAME"
-for f in requirements.md design.md; do
-    [ ! -f "$DIR/$f" ] && { echo "❌ Missing $f. Complete /curdx-flow:requirements /curdx-flow:design first"; exit 1; }
+SPEC_NAME=$(cat .flow/.active-spec 2>/dev/null)
+[ -z "$SPEC_NAME" ] && { echo "✗ No active spec. Run /curdx-flow:start first."; exit 1; }
+
+SPEC_DIR=".flow/specs/$SPEC_NAME"
+for f in requirements.md design.md tasks.md; do
+  [ ! -f "$SPEC_DIR/$f" ] && {
+    echo "✗ $SPEC_DIR/$f missing. Run /curdx-flow:spec first.";
+    exit 1;
+  }
 done
+
+FLAG_STRICT=$(echo "$ARGUMENTS" | grep -q -- '--strict' && echo 1 || echo 0)
 ```
 
-## Step 2: Determine Scope
+## Workflow
 
-```bash
-# Read the commit range for the execute phase
-# From .state.json or git reflog
-
-LAST_EXEC_START=$(python3 -c "
-import json
-s = json.load(open('$DIR/.state.json'))
-# Custom field or inferred from git
-print(s.get('execute_state', {}).get('start_commit', ''))
-")
-
-# If unavailable, use main..HEAD
-RANGE="${LAST_EXEC_START:-main}..HEAD"
-echo "Verification scope: $RANGE"
-```
+### Step 1: Dispatch `flow-verifier`
 
-## Step 3: Dispatch flow-verifier
+Delegate to the `flow-verifier` agent with:
+- `requirements.md` (source of FR-NN, AC-N.N, US-NN)
+- `design.md` (source of AD-NN)
+- `tasks.md` (source of T-N.M and their Verify commands)
+- Repository root (to scan code + tests)
 
-```
-Task:
-  subagent_type: general-purpose
-  description: "verify $SPEC_NAME"
-  prompt: |
-    You are the flow-verifier agent. Full definition:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-verifier.md
-    
-    Must read:
-    - .flow/specs/$SPEC_NAME/requirements.md
-    - .flow/specs/$SPEC_NAME/design.md
-    - .flow/specs/$SPEC_NAME/tasks.md
-    - .flow/specs/$SPEC_NAME/.state.json
-    - .flow/STATE.md
-    
-    Verification scope: commits $RANGE
-    
-    Tasks:
-    1. Extract every FR / AC / AD / Component / error-path assertion
-    2. Find evidence for each assertion (code + test + actual run)
-    3. Scan for stub patterns (TODO / Not implemented / return {})
-    4. Generate verification-report.md
-    5. Update phase_status.verify in .state.json
-    
-    Output file:
-    .flow/specs/$SPEC_NAME/verification-report.md
-    
-    Return a brief:
-    - Fully verified / partially verified / not verified counts
-    - Number of fake implementations
-    - List of blockers
-    - Suggested next step
-```
+The agent performs goal-backward tracing:
+1. For each **FR-NN**: search for code that implements it. Classify as `IMPLEMENTED` / `STUB` / `MISSING` / `UNCERTAIN`.
+2. For each **AC-N.N**: search for a test that exercises it. Classify as `TESTED` / `UNTESTED`.
+3. For each **AD-NN**: check that the design decision is reflected in code structure / interfaces.
+4. Detect suspicious patterns:
+   - `throw new Error("not implemented")` / `TODO` / `NotImplementedError`
+   - `return null` / `return {}` in places that should produce real output
+   - test files with only `it.skip(...)` or no assertions
+   - code that returns mocked fixtures instead of calling real collaborators
+
+### Step 2: Run the Verify commands from `tasks.md`
+
+For every task listed in `tasks.md`, run its declared `Verify:` command and record pass/fail. This is the most objective check — if the task said `npm test -- auth.spec.ts`, run exactly that.
+
+### Step 3: (Strict only) Multi-source coverage audit
+
+If `--strict`:
+- Cross-check every FR / AC / AD / decision against the implementation
+- Cross-check every research conclusion: was the recommended library / approach actually used?
+- Cross-check every D-NN decision in `.flow/STATE.md` that references this spec
+
+### Step 4: Produce `verification-report.md`
 
-## Step 4: Read Report + Decide
+**Landing check**: sub-agent responses can be truncated by the model's output-length limit. After dispatching `flow-verifier`, verify the report actually landed:
 
 ```bash
-REPORT="$DIR/verification-report.md"
-[ ! -f "$REPORT" ] && { echo "❌ verifier did not produce a report"; exit 1; }
-
-# Parse the verdict from the report
-VERIFIED=$(grep -c "^\- ✓" "$REPORT" || echo 0)
-PARTIAL=$(grep -c "^\- ⚠" "$REPORT" || echo 0)
-MISSING=$(grep -c "^\- ✗" "$REPORT" || echo 0)
-STUBS=$(grep -c "^\- 🚨" "$REPORT" || echo 0)
+REPORT=".flow/specs/$SPEC_NAME/verification-report.md"
+if [ ! -f "$REPORT" ] || [ "$(wc -c < "$REPORT" 2>/dev/null | tr -d ' ')" -lt 300 ]; then
+  echo "⚠ Report missing or truncated. Re-dispatching flow-verifier with a terse 'write the report now' prompt."
+  # Re-dispatch pattern:
+  #   "Your only job right now is to Write the verification-report.md using the
+  #    findings you already gathered. Do not re-scan. Do not narrate. Write
+  #    the file and stop."
+fi
 ```
 
-## Step 5: Output to User
+Write to `.flow/specs/$SPEC_NAME/verification-report.md`:
 
+```markdown
+# Verification Report — <spec-name>
+
+**Generated**: <ISO8601>
+**Mode**: strict | normal
+
+## Summary
+- FR coverage:  N/M implemented (K stubs, L missing)
+- AC coverage:  N/M tested
+- AD coverage:  N/M reflected
+- Verify commands: N/M passing
+
+## Findings
+
+### Missing implementations
+- FR-02: <description>. No matching code found in <paths searched>.
+
+### Stubs / fake completions
+- FR-05: Implemented in `src/auth.ts:42` but body is `throw new Error("not implemented")`.
+
+### Untested acceptance criteria
+- AC-1.3: No test asserts token refresh after 15 min expiry.
+
+### Failing Verify commands
+- T-2.1: `npm test auth.spec.ts` → 3 failed
+
+## Verdict
+- [ ] PASS — all items covered and passing
+- [X] PARTIAL — <n> findings must be addressed before shipping
+- [ ] MISSING — substantive implementation gaps
 ```
-✓ Verify complete: $SPEC_NAME
 
-Stats:
-  ✓ Fully verified:     $VERIFIED
-  ⚠ Partially verified: $PARTIAL
-  ✗ Not verified:       $MISSING
-  🚨 Fake implementations: $STUBS
+### Step 5: Apply `verification-gate`
+
+Hard rule from `@${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 user D-NN decision logged to `.flow/STATE.md`.
 
-Report: .flow/specs/$SPEC_NAME/verification-report.md
+## Reporting
+
+```
+✓ Verification complete
+  FR coverage: 8/10 implemented (1 stub, 1 missing)
+  AC coverage: 9/12 tested
+  Verify commands: 14/15 passing
+  Verdict: PARTIAL
 
-Verdict:
-  $([ $MISSING -gt 0 ] && echo '❌ BLOCKED — unimplemented FR/AC/AD exist, return to /curdx-flow:implement to fill in')
-  $([ $STUBS -gt 0 ] && echo '❌ BLOCKED — fake implementations found')
-  $([ $MISSING -eq 0 ] && [ $STUBS -eq 0 ] && echo '✓ PASS — can proceed to /curdx-flow:review')
+Findings written to: .flow/specs/<name>/verification-report.md
 
-Next step:
-  $([ $MISSING -gt 0 ] && echo 'fix blockers → /curdx-flow:implement --task=<new task>')
-  $([ $MISSING -eq 0 ] && echo '/curdx-flow:review — enter code quality review')
+Next: address findings, then re-run /curdx-flow:verify, or run /curdx-flow:review.
 ```
 
-## Error Recovery
+## References
 
-- verifier times out → reduce spec scope (verify only specific FRs), then rerun
-- Some Verify commands are unavailable (e.g. require a DB connection) → mark "needs manual verification" in the report
-- verifier output is vague → prompt to look at specific sections of the report
+- `flow-verifier` agent: `@${CLAUDE_PLUGIN_ROOT}/agents/flow-verifier.md`
+- `verification-gate`: `@${CLAUDE_PLUGIN_ROOT}/gates/verification-gate.md`
+- `coverage-audit-gate` (used in strict mode): `@${CLAUDE_PLUGIN_ROOT}/gates/coverage-audit-gate.md`

package/gates/adversarial-review-gate.md

@@ -210,7 +210,7 @@ I have examined the following dimensions across 2 rounds of analysis:
 
 Recommendations:
 - Human review (at least walk through the diff once)
-- Consider /curdx-flow:qa for real browser/integration testing (Phase 5+)
+- Consider the `browser-qa` skill for real browser/integration testing (Phase 5+)
 - Wait until deployment to staging to observe
 ```
 

package/gates/coverage-audit-gate.md

@@ -17,7 +17,7 @@ depends_on: []
 
 - End of the tasks phase (last step of flow-planner)
 - Before the execution phase completes (when /curdx-flow:verify runs)
-- Explicitly requested by /curdx-flow:audit
+- Explicitly requested by /curdx-flow:verify --strict
 
 ---
 

package/gates/devex-gate.md

@@ -13,7 +13,7 @@ depends_on: []
 
 ## Trigger Timing
 
-- When `/curdx-flow:plan-dx` runs (design phase)
+- When `/curdx-flow:spec --review=dx` runs (design phase)
 - When `/curdx-flow:review --devex` runs (code phase)
 - Enabled by default in open-source / multi-person collaboration scenarios
 

package/gates/edge-case-gate.md

@@ -18,7 +18,7 @@ depends_on: []
 - After the requirements phase ends (to supplement edge conditions)
 - After the design phase (to check error-path completeness)
 - After tests are written (to check whether only the happy path is covered)
-- Explicitly requested by /curdx-flow:audit
+- Explicitly requested by /curdx-flow:verify --strict
 
 ---
 

package/gates/security-gate.md

@@ -13,7 +13,7 @@ depends_on: []
 
 ## Trigger Timing
 
-- When `/curdx-flow:security` runs
+- When the `security-audit` skill runs
 - Before `/curdx-flow:ship` (auto-triggered, Phase 6+)
 - When committing specs involving auth / payments / PII
 
@@ -130,8 +130,8 @@ Production environment only accepts HTTPS. HTTP requests → 301 to HTTPS.
 # Run all scans
 bash scripts/security-scan.sh  # provided by project (if available)
 
-# Or use flow-security-auditor agent
-/curdx-flow:security
+# Or use flow-security-auditor agent via the `security-audit` skill
+# (or say "audit for security issues")
 ```
 
 ### Dependency CVE

package/hooks/scripts/session-start.sh

@@ -36,7 +36,7 @@ if [ "$LAST_CHECK" != "$TODAY" ]; then
 
   if [ "${#MISSING[@]}" -gt 0 ]; then
     JOINED="$(IFS=,; echo "${MISSING[*]}")"
-    ADDITIONAL_CONTEXT+="## CurDX-Flow Recommended Plugins Check\n\nThe following recommended plugins were not detected: **${JOINED}**\n\nRun \`/curdx-flow:install-deps\` for interactive one-shot install. Run \`/curdx-flow:doctor\` for the full health report.\n\n"
+    ADDITIONAL_CONTEXT+="## CurDX-Flow Recommended Plugins Check\n\nThe following recommended plugins were not detected: **${JOINED}**\n\nRun \`npx @curdx/flow install --all\` for interactive one-shot install. Run \`npx @curdx/flow doctor\` for the full health report.\n\n"
   fi
 
   echo "$TODAY" > "$MARKER" 2>/dev/null || true

package/knowledge/epic-decomposition.md

@@ -238,13 +238,13 @@ Week 5-6: Spec 4 (refund) + Spec 5 (query)
 ## Epic Lifecycle
 
 ```
-1. /curdx-flow:triage "Epic goal"
+1. Invoke the `epic` skill with "Epic goal" (auto-invoked; or say "break this big feature down")
      ↓ flow-triage-analyst decomposes
 2. Generates .flow/_epics/<name>/epic.md + sub-spec skeletons
 3. User reviews epic.md
      ↓
 4. For each sub-spec:
-   /curdx-flow:switch <sub-spec-name>
+   /curdx-flow:start <sub-spec-name>
    /curdx-flow:spec
    /curdx-flow:implement
    /curdx-flow:review

package/knowledge/execution-strategies.md

@@ -252,7 +252,7 @@ Can you switch strategies mid-execution? Not recommended.
 - Any → Wave: needs `[P]` markers in tasks.md
 
 If you really must switch, do it manually:
-1. `/curdx-flow:doctor` to check status
+1. `npx @curdx/flow doctor` to check status
 2. Manually edit `.flow/specs/<name>/.state.json`'s `strategy` field
 3. Rerun `/curdx-flow:implement`
 
@@ -262,13 +262,13 @@ If you really must switch, do it manually:
 
 ### View progress
 ```bash
-/curdx-flow:status        # global
-/curdx-flow:status <name> # single-spec details
+/curdx-flow:start --list        # global
+# For single-spec details, inspect .flow/specs/<name>/.progress.md
 ```
 
 ### Interrupt
 - `Ctrl+C` interrupts the current session → Stop event triggers, state is saved
-- Next `/curdx-flow:switch <name>` resumes from `task_index`
+- Next `/curdx-flow:start <name>` (or `/curdx-flow:start --resume`) resumes from `task_index`
 
 ### Snapshots
 `/curdx-flow:save <label>` saves a checkpoint (Phase 5+ rollout).

package/knowledge/planning-reviews.md

@@ -26,7 +26,7 @@ design.md
 
 Each review is dispatched independently (different agent / context) to avoid perspective convergence.
 
-Finally `/curdx-flow:autoplan` ties them together: runs all 4 reviews in one pass.
+Finally `/curdx-flow:spec --review=all` ties them together: runs all 4 reviews in one pass.
 
 ---
 
@@ -115,7 +115,7 @@ Essentially runs `flow-architect` again — but this time not to generate the de
 
 ### Dispatch
 
-`flow-ux-designer` (Emma) switches into review mode.
+`flow-ux-designer` switches into review mode.
 
 ---
 
@@ -153,10 +153,10 @@ Phase 5 implementation: reuse `flow-reviewer` + `@gates/devex-gate.md`.
 
 ---
 
-## /curdx-flow:autoplan — Run All 4 at Once
+## /curdx-flow:spec --review=all — Run All 4 at Once
 
 ```bash
-/curdx-flow:autoplan
+/curdx-flow:spec --review=all
 ```
 
 Workflow:
@@ -183,7 +183,7 @@ Output:
 ...
 
 ## Recommendations
-1. Return to /curdx-flow:design to fix blockers
+1. Return to /curdx-flow:spec --phase=design to fix blockers
 2. Record warnings in STATE.md, address in tasks phase
 ```
 
@@ -191,7 +191,7 @@ Output:
 
 ## When to Skip Planning Reviews
 
-- **MVP / prototype**: time-pressured, run /curdx-flow:tasks first, review after launch
+- **MVP / prototype**: time-pressured, run /curdx-flow:spec --phase=tasks first, review after launch
 - **Tiny changes**: a single file < 50 lines doesn't warrant a 4-dimension review
 - **Similar work done before**: reuse prior review conclusions
 

package/knowledge/spec-driven-development.md

@@ -147,7 +147,7 @@ Regardless of the path taken, the 4 files must satisfy:
 ## Spec vs Epic Difference
 
 - **Spec**: a single independently-deliverable feature. Typically 1-2 weeks of effort.
-- **Epic**: a collection of specs. `/curdx-flow:triage` breaks down a large goal into multiple specs.
+- **Epic**: a collection of specs. The `epic` skill (auto-invoked, or say "break this big feature down") breaks down a large goal into multiple specs.
 
 `.flow/specs/<name>/` is a single-spec directory.
 `.flow/_epics/<name>/` is an Epic directory (contains the dependency graph and sub-spec list).
@@ -159,8 +159,8 @@ Regardless of the path taken, the 4 files must satisfy:
 SDD is not dogma. The following scenarios may skip phases:
 
 - **One-off scripts** (`/curdx-flow:fast` mode) — skip all specs
-- **UI prototype exploration** (`/curdx-flow:sketch` mode) — only research + design sketches
-- **Emergency hotfix** (`/curdx-flow:spike` mode) — validating the assumption is enough
+- **UI prototype exploration** (the `ui-sketch` skill) — only research + design sketches
+- **Emergency hotfix** (`/curdx-flow:fast "spike: validate <hypothesis>"` mode) — validating the assumption is enough
 
 But **production code changes** should follow the full flow. Rationale:
 - Code may be only 20 lines, but impact may reach all users

package/knowledge/two-stage-review.md

@@ -206,7 +206,7 @@ Some reviewers list 50 minor improvements — the user can't process.
 ## Relationship to Other Phases
 
 ```
-/curdx-flow:tasks  →  tasks.md contains task list
+/curdx-flow:spec --phase=tasks  →  tasks.md contains task list
      ↓
 /curdx-flow:implement  →  code + tests + commits
      ↓
@@ -218,7 +218,7 @@ Some reviewers list 50 minor improvements — the user can't process.
      ↓                     ↓
      ↓              review-report.md
      ↓
-(optional) /curdx-flow:audit  →  adversarial review + edge cases
+(optional) /curdx-flow:verify --strict  →  adversarial review + edge cases
                     ↓
                     adversarial-review.md
                     edge-cases.md

package/knowledge/wave-execution.md

@@ -254,7 +254,7 @@ Decision:
   - 1.1 and 1.3 commits retained
   - Main agent decides:
     A: continue to Wave 2 (skip 1.2, possible cascading failure)
-    B: dispatch David (flow-debugger) to fix 1.2, then continue
+    B: dispatch flow-debugger to fix 1.2, then continue
     C: stop and report, let the user intervene
 
   Default: A, but failed_attempts += 1; after threshold switch to C
@@ -268,7 +268,7 @@ Wave 1 all TASK_FAILED
 Decision:
   - Usually indicates an upstream environment problem (missing deps, tsc config wrong)
   - Stop immediately
-  - Suggest user run /curdx-flow:doctor to diagnose
+  - Suggest user run `npx @curdx/flow doctor` to diagnose
 ```
 
 ### Inter-wave dependency broken
@@ -307,7 +307,7 @@ Decision:
 
 ### In-progress view
 
-`/curdx-flow:status` shows:
+Inspecting `.flow/specs/<name>/.progress.md` (or running `/curdx-flow:start --list`) shows:
 ```
 Spec: auth-system
 Strategy: wave
@@ -321,7 +321,7 @@ Progress: Wave 2/5 (60%)
 ### Ctrl+C interruption
 
 - Running Task calls in the current wave keep going (Claude Code's Task is an independent process)
-- Next `/curdx-flow:switch` shows some tasks already committed
+- Next `/curdx-flow:start --resume` shows some tasks already committed
 - Resume from the failing task
 
 ---
@@ -367,7 +367,7 @@ Phase 6+ will consider automatic fallback.
 ### 1. `[P]` markers incorrect
 
 If the planner missed a dependency, `[P]` may be wrong. Solutions:
-- Before execution, confirm tasks coverage via `/curdx-flow:audit`
+- Before execution, confirm tasks coverage via `/curdx-flow:verify --strict`
 - Conflict detection as a safety net (validate Files before dispatch)
 
 ### 2. A wave too large

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@curdx/flow",
-  "version": "1.1.11",
+  "version": "2.0.0-beta.2",
   "description": "CLI installer for CurDX-Flow — AI engineering workflow meta-framework for Claude Code",
   "type": "module",
   "bin": {

package/agents/persona-amelia.md

@@ -1,128 +0,0 @@
----
-name: amelia
-description: Amelia — developer (strict execution, quality-first). Backed by the full capabilities of flow-executor.
-model: sonnet
-effort: medium
-maxTurns: 30
-tools: [Read, Write, Edit, Bash, Grep, Glob]
----
-
-# Amelia — Developer
-
-Hi, I'm **Amelia**. I turn designs into code.
-
----
-
-## My Perspective
-
-My job is **strict execution**. The design has been discussed, the requirements are nailed down, the tasks are broken out. My responsibilities:
-
-- **Follow tasks.md** (no freelancing)
-- **Karpathy surgical edits** (change only what must change)
-- **TDD red/green/yellow** (tests first)
-- **Atomic commits** (one task, one commit)
-- **Verify must pass** (evidence required when claiming done)
-
----
-
-## My Capabilities
-
-Full workflow:
-
-@${CLAUDE_PLUGIN_ROOT}/agents/flow-executor.md
-
-Key rules:
-- 5-round retry (pua-style escalation)
-- Emit `TASK_COMPLETE` / `TASK_FAILED` / `ALL_TASKS_COMPLETE`
-- Atomic commit per task (conventional format)
-- Update `.progress.md` and `.state.json`
-
----
-
-## My Communication Style
-
-- **Concise > verbose**: execution doesn't need long explanations
-- **Evidence > claims**: not "should be good", but "ran the test, passed"
-- **Stay on task**: don't challenge the design during execution (raise concerns during the design phase)
-- **Clear failures**: after 3 failures, I say `TASK_FAILED` honestly — no forcing it
-
----
-
-## The Rules I Follow
-
-### 1. No production code without a failing test first
-
-In the Phase 3 (Testing) stage, TDD is ironclad. Any waiver must be recorded in STATE.md.
-
-### 2. Only touch the files listed in the Files field
-
-If the task says modify `auth/login.ts`, I won't "casually" touch `utils/string.ts`.
-
-### 3. Verify must actually run
-
-"Tests should pass" is not allowed. Must run `npm test` and capture the exit code.
-
-### 4. Honest commit messages
-
-No hedging words (maybe / probably / should). If uncertain, don't commit.
-
-### 5. Don't ask the user in Quick mode
-
-In an automated loop (stop-hook or --quick), I proceed on the basis of `.flow/CONTEXT.md` preferences + the most reasonable assumption, recording the assumption to `.progress.md`.
-
----
-
-## Typical Output (after finishing a task)
-
-```
-✓ Task 1.2 complete — feat(auth): implement login endpoint (abc123f)
-
-Verify passed:
-  npm test -- auth/login.test.ts
-  ✓ Test Suites: 1 passed
-  ✓ Tests: 3 passed
-
-Files changed:
-  src/auth/login.ts (+45 -2)
-  src/auth/login.test.ts (+38)
-
-.progress.md updated: task 1.2 learned "bcrypt.compare needs await"
-
-TASK_COMPLETE: 1.2
-Next: 1.3
-```
-
----
-
-## When to Call Me
-
-- Entering a spec's execute phase
-- `/curdx-flow:implement` auto-dispatches me (as a subagent or stop-hook loop)
-- In Party Mode: I represent the "can we actually build it" perspective
-
----
-
-## When I Fail
-
-I say so honestly, without hiding it:
-
-```
-✗ Task 1.2 failed (after 5 attempts)
-
-Attempts:
-  1. Direct implementation → bcrypt not found (dependency issue)
-  2. Install bcrypt → permission error
-  3. Use npm sudo → broke node_modules
-  4. Switch to bcryptjs → wrong import path
-  5. Fix path → some test still failing, unclear why
-
-TASK_FAILED: 1.2
-Suggestions:
-  - Have the user investigate the bcrypt permission issue
-  - Or consider dispatching flow-debugger / David for root-cause analysis
-  - Or grant a STATE.md waiver for this task
-```
-
----
-
-_Backed by: flow-executor agent._