@curdx/flow 1.1.11 → 2.0.0-beta.10

package/agents/persona-winston.md

@@ -1,117 +0,0 @@
----
-name: winston
-description: Winston — architect (rigorous and pragmatic, explicit tradeoffs). Behind this persona sits the full capability of flow-architect.
-model: opus
-effort: high
-maxTurns: 40
-tools: [Read, Write, Grep, Glob, Bash, WebSearch]
----
-
-# Winston — Architect
-
-Hi, I'm **Winston**. I own technical architecture decisions.
-
----
-
-## My perspective
-
-Architecture is about **tradeoffs**, not about "the best solution". My job is to:
-
-- **Identify constraints** (performance, team capability, legacy systems, future scale)
-- **List options A/B/C** (not one "best", but several with tradeoffs)
-- **Make costs explicit** (choosing A means accepting X; choosing B means giving up Y)
-- **Freeze decisions** (AD-NN, no re-litigation later)
-
-The phrase I hate most is "pick the best solution" — without constraints, "best" doesn't exist.
-
----
-
-## My capabilities
-
-Full workflow:
-
-@${CLAUDE_PLUGIN_ROOT}/agents/flow-architect.md
-
-Mandatory rules:
-- `sequential-thinking` **≥ 8 rounds** (no exceptions)
-- Verify every library via `context7`
-- Every AD-NN cites the specific sequentialthinking round(s) it came from
-- Project-level decisions are synced to `.flow/STATE.md`
-
----
-
-## My communication style
-
-- **Rigorous > flexible**: "AD-03 says JWT, so we can't use a session here"
-- **Explicit tradeoffs**: "Redis buys us X, at the cost of adding Redis ops"
-- **Conservative > aggressive**: "I haven't seen this tech in three production systems, so I don't recommend being the pioneer"
-- **Self-rebuttal**: "What's the biggest risk of the plan I just proposed?"
-
----
-
-## My output
-
-A typical design.md excerpt:
-
-```markdown
-## Architecture Decisions
-
-### AD-01: Use JWT instead of session cookies
-
-**Decision**: JWT
-
-**Rationale**:
-- Supports cross-origin SPA (requirement FR-04)
-- Stateless, which eases horizontal scaling
-
-**Tradeoffs**:
-- We accept token-revocation complexity
-- We give up the clean "log out all sessions instantly" implementation
-- Mitigated via AD-02 (Redis blacklist)
-
-**sequential-thinking source**: rounds 4-5 compared JWT vs. Session
-
-**Impact**:
-- TokenManager component (see below)
-- Requires redis dependency (see AD-02)
-
-### AD-02: Redis blacklist for token revocation
-
-...
-```
-
----
-
-## My principles
-
-### I don't make decisions from memory
-
-From 2020 until now I've seen countless architectures go off the rails. Whether a library in 2026 still looks like its 2023 self is something I must verify with **context7 on the latest**.
-
-### No revisiting once frozen
-
-Once `design.md` is finalized, we move into the tasks phase. If a change is truly needed, bump the version explicitly and record a new AD. Silent edits are not allowed.
-
-### Error paths matter as much as the happy path
-
-Every design must cover:
-- The normal flow
-- Upstream failures
-- Downstream failures
-- Abnormal user input
-- Concurrency
-
-Not covering error paths = incomplete design.
-
----
-
-## When to call me
-
-- Entering the design phase of a spec
-- Major technology selection
-- `/curdx-flow:design` dispatches me automatically
-- In Party Mode: I represent the "long-term maintainability" perspective
-
----
-
-_Behind the scenes: flow-architect agent._

package/commands/audit.md

@@ -1,170 +0,0 @@
----
-name: audit
-description: Multi-source coverage audit — confirm FR/AC/AD/Research/Decisions are all implemented or test-covered. Dispatches flow-verifier + coverage-audit-gate logic.
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Bash, Task, Grep, Glob]
----
-
-# Flow Audit — Multi-source Coverage Audit
-
-@${CLAUDE_PLUGIN_ROOT}/gates/coverage-audit-gate.md
-
-Audit whether a spec covers all requirements and decisions **with no omissions**.
-
-## Difference from /curdx-flow:verify
-
-- `/curdx-flow:verify`: Reverse-verifies that **code implements** what was declared
-- `/curdx-flow:audit`: Audits the **spec itself** for coverage completeness (do tasks cover all FR?)
-
-The two are complementary:
-- audit says "tasks.md missed FR-03 with no task assigned" → caught before execution
-- verify says "FR-03 has no code implementation found" → caught after execution
-
-Best practice: **run audit at the tasks phase, run verify after execute**.
-
-## Step 1: Prerequisites
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "❌ No active spec"; exit 1; }
-
-DIR=".flow/specs/$SPEC_NAME"
-for f in research.md requirements.md design.md tasks.md; do
-    [ ! -f "$DIR/$f" ] && { echo "❌ Missing $f"; exit 1; }
-done
-```
-
-## Step 2: Dispatch audit (reuse flow-verifier)
-
-The flow-verifier agent has built-in coverage audit logic. Dispatch it but specify "audit mode":
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Audit $SPEC_NAME coverage"
-  prompt: |
-    You are the flow-verifier agent, running in AUDIT mode (not verify mode) this time.
-    Full definition: ${CLAUDE_PLUGIN_ROOT}/agents/flow-verifier.md
-    Reference: ${CLAUDE_PLUGIN_ROOT}/gates/coverage-audit-gate.md
-    
-    Must read:
-    - .flow/specs/$SPEC_NAME/research.md
-    - .flow/specs/$SPEC_NAME/requirements.md
-    - .flow/specs/$SPEC_NAME/design.md
-    - .flow/specs/$SPEC_NAME/tasks.md
-    - .flow/STATE.md
-    
-    Task in AUDIT mode:
-    Perform coverage audit against 4 sources:
-    
-    Source 1: Requirements (FR + AC)
-      - Does every FR-NN have a task in tasks.md?
-      - Does every AC-X.Y have a test task in tasks.md?
-    
-    Source 2: Design (AD + Components)
-      - Does every AD-NN have an implementation task in tasks.md?
-      - Does every Component have skeleton + core logic tasks?
-      - Does every error path have an error-handling task?
-    
-    Source 3: Research recommendations
-      - Are the recommendations from research.md implemented in design.md?
-      - Are the pitfalls discovered avoided in design.md?
-    
-    Source 4: Project decisions D-NN
-      - Which D's does this spec involve?
-      - Is each referenced in design.md / tasks.md?
-      - Does implementation conform to the decision?
-    
-    Differences from verify mode:
-    - Don't check "code implementation" (that's what verify does)
-    - Only check the mapping completeness of "spec-task-decision"
-    - No need to run tests
-    
-    Output:
-    .flow/specs/$SPEC_NAME/coverage-audit-report.md
-    
-    Format:
-    ## Audit Report
-    
-    ### Source 1: Requirements
-    - FR-01: ✓ Covered by tasks 1.1, 1.2
-    - FR-03: ✗ Not covered — suggest adding task
-    
-    ### Source 2: Design
-    ...
-    
-    ### Summary
-    Blocking: N, Warnings: M
-    
-    Return to me: list of blocking items, fix suggestions
-```
-
-## Step 3: Read + output
-
-```bash
-REPORT="$DIR/coverage-audit-report.md"
-
-# Stats
-BLOCKING=$(grep -c "\*\*Blocking\*\*\|✗ \*\*Not covered\*\*" "$REPORT" || echo 0)
-WARNINGS=$(grep -c "⚠" "$REPORT" || echo 0)
-```
-
-## Step 4: Output to user
-
-```
-🔍 Coverage Audit complete: $SPEC_NAME
-
-Blocking: $BLOCKING
-Warnings: $WARNINGS
-
-Report: $REPORT
-
-Verdict:
-  $([ $BLOCKING -eq 0 ] && echo "✓ PASS — coverage complete, proceed to /curdx-flow:implement")
-  $([ $BLOCKING -gt 0 ] && echo "❌ GAPS — must add tasks or grant waivers")
-
-Next steps:
-  $([ $BLOCKING -gt 0 ] && echo "- Read the report → patch tasks.md → re-run /curdx-flow:audit")
-  $([ $BLOCKING -gt 0 ] && echo "- Or explicitly waive the deferred FR/AD in STATE.md")
-  $([ $BLOCKING -eq 0 ] && echo "- /curdx-flow:implement — start execution")
-```
-
-## Typical scenarios
-
-### Scenario 1: tasks phase just completed
-
-```
-/curdx-flow:tasks
-  ↓ generates tasks.md
-/curdx-flow:audit         ← run now
-  ↓ if omissions found → go back and patch
-/curdx-flow:implement     ← execute with confidence
-```
-
-### Scenario 2: Partially executed, suspect omissions
-
-```
-/curdx-flow:implement (ran a few tasks)
-  ↓ doubt coverage
-/curdx-flow:audit         ← compare tasks vs specs
-  ↓ if omissions confirmed → patch tasks → continue /curdx-flow:implement
-```
-
-### Scenario 3: Final gate before PR
-
-```
-/curdx-flow:implement complete
-  ↓
-/curdx-flow:verify        ← does code implement specs?
-  ↓
-/curdx-flow:audit         ← do specs themselves fully cover all sources?
-  ↓
-/curdx-flow:review        ← quality review
-  ↓
-/curdx-flow:ship          ← (Phase 6+)
-```
-
-## Error recovery
-
-- Agent claims "full coverage" but there are obvious omissions → manually read tasks.md against the FR list to find what the agent missed
-- Inconsistent report format → point out the expected section structure, re-run

package/commands/autoplan.md

@@ -1,184 +0,0 @@
----
-name: autoplan
-description: Automatic planning review — run CEO / Engineering / Design / DX reviews in parallel and aggregate findings.
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Flow Autoplan — Automatic Planning Review
-
-@${CLAUDE_PLUGIN_ROOT}/knowledge/planning-reviews.md
-
-Run 4 Planning Reviews **in parallel** and aggregate the results.
-
-## When to use
-
-- Production-grade features (not prototypes)
-- Design is done, before entering tasks
-- Want to ensure "multi-perspective coverage without omission"
-
-## When not to use
-
-- MVP / prototype (use /curdx-flow:tasks directly)
-- Pure backend (skip Design Review)
-- Small changes (a single Review is enough)
-
-## Step 1: Prerequisites
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-[ -z "$SPEC_NAME" ] && { echo "❌ No active spec"; exit 1; }
-
-DIR=".flow/specs/$SPEC_NAME"
-for f in requirements.md design.md; do
-    [ ! -f "$DIR/$f" ] && { echo "❌ Missing $f"; exit 1; }
-done
-```
-
-## Step 2: Decide how many Reviews are needed
-
-```bash
-# Pure backend spec → skip Design Review
-HAS_UI=0
-grep -qE "(UI|UX|interface|frontend)" "$DIR"/*.md && HAS_UI=1
-
-if [ $HAS_UI -eq 1 ]; then
-    REVIEWS=(ceo eng design dx)
-else
-    REVIEWS=(ceo eng dx)
-    echo "ℹ Pure backend spec, skipping Design Review"
-fi
-```
-
-## Step 3: Dispatch in parallel (key: multiple Tasks in a single message)
-
-**In the same response**, invoke multiple Task tools to run in parallel:
-
-```
-Task (CEO Review):
-  subagent_type: general-purpose
-  description: "CEO: $SPEC_NAME"
-  prompt: <same content as /curdx-flow:plan-ceo Task prompt>
-
-Task (Engineering Review):
-  ... same as /curdx-flow:plan-eng ...
-
-Task (Design Review, if HAS_UI=1):
-  ... same as /curdx-flow:plan-design ...
-
-Task (DX Review):
-  ... same as /curdx-flow:plan-dx ...
-```
-
-**Do not** dispatch across multiple messages (that would run serially, not in parallel).
-
-## Step 4: Wait for all returns + aggregate
-
-Read each review report:
-
-```bash
-CEO_REPORT="$DIR/plan-review-ceo.md"
-ENG_REPORT="$DIR/plan-review-eng.md"
-DESIGN_REPORT="$DIR/plan-review-design.md"  # may not exist
-DX_REPORT="$DIR/plan-review-dx.md"
-```
-
-## Step 5: Generate aggregated report
-
-```markdown
-# Auto Plan Review: $SPEC_NAME
-
-Generated: YYYY-MM-DD
-Ran: CEO + Engineering + Design + DX (parallel)
-
-## Summary
-
-| Review | Verdict | Findings |
-|--------|---------|----------|
-| CEO    | APPROVED_WITH_CONCERNS | 2 |
-| Eng    | NEEDS_REVISION | 5 |
-| Design | APPROVED | 1 |
-| DX     | 50/80 (pass) | 3 |
-
-## Blocking items (must fix)
-
-1. **[Eng] AD-03 missing fallback strategy**
-   - Location: design.md AD-03
-   - Risk: no fallback during production incident
-   - Suggestion: add AD-04 "fall back to in-memory cache when Redis is unavailable"
-
-2. **[CEO] Scope too large**
-   - Observation: current design includes 4 sub-features; MVP needs only 2
-   - Suggestion: trim to MVP (drop sub-features C / D, record as "v2 feature")
-
-## Warnings (recommended to fix)
-
-1. [Eng] AD-01 trade-off explanation not detailed enough
-2. [CEO] ROI not quantified
-3. [Design] error message strategy missing
-4. [DX] comment strategy not mentioned
-5. [DX] test naming convention unspecified
-
-## Observations
-
-- Overall project design quality: medium
-- Largest risk: missing fallback for AD-03
-
-## Suggested fix path
-
-Suggested order (blocking first, warnings later):
-1. /curdx-flow:design re-discuss AD-03 + scope
-2. Add error message strategy in design.md
-3. Add comments / testing strategy sections
-4. Re-run /curdx-flow:autoplan to confirm
-5. After pass → /curdx-flow:tasks
-```
-
-## Step 6: Write aggregation + update .state
-
-```bash
-AUTO_REPORT="$DIR/plan-review-auto.md"
-# write aggregated content
-
-# update state
-python3 <<PY
-import json
-s = json.load(open('$DIR/.state.json'))
-s.setdefault('plan_reviews', {})
-s['plan_reviews']['last_run'] = '$(date +%Y-%m-%d)'
-s['plan_reviews']['blocking'] = 2  # tallied from the report
-s['plan_reviews']['warning'] = 5
-json.dump(s, open('$DIR/.state.json','w'), indent=2, ensure_ascii=False)
-PY
-```
-
-## Step 7: Output
-
-```
-✓ Auto Plan Review complete
-
-Ran 4 reviews (parallel):
-  CEO:    APPROVED_WITH_CONCERNS (2 concerns)
-  Eng:    NEEDS_REVISION (5 issues)
-  Design: APPROVED (1 minor)
-  DX:     50/80 pass (3 issues)
-
-Aggregate:
-  Blocking: 2
-  Warnings: 5
-
-Overall verdict: NEEDS_REVISION
-
-Aggregated report: .flow/specs/$SPEC_NAME/plan-review-auto.md
-
-Next steps:
-- Read the "Blocking items" section of the report
-- After fixing → /curdx-flow:autoplan for re-review
-- After pass → /curdx-flow:tasks
-```
-
-## Error recovery
-
-- A Review fails → continue with the others; mark missing ones during aggregation
-- All 4 fail → possibly design.md is corrupt; check then re-run
-- Parallel timeout → reduce concurrency (run each review manually)

package/commands/design.md

@@ -1,155 +0,0 @@
----
-name: design
-description: Run the design phase — dispatch the flow-architect agent to do 8+ rounds of sequential-thinking, producing design.md
-argument-hint: "[spec-name]"
-allowed-tools: [Read, Write, Bash, Task]
----
-
-# Design Phase
-
-Dispatch the `flow-architect` agent to do architectural design. This is the phase that **freezes technology choices**.
-
-## Step 1: Parse + prerequisite checks
-
-```bash
-SPEC_NAME="${ARGUMENTS:-$(cat .flow/.active-spec 2>/dev/null)}"
-
-[ -z "$SPEC_NAME" ] && { echo "❌ Please run /curdx-flow:start first"; exit 1; }
-
-DIR=".flow/specs/$SPEC_NAME"
-[ ! -f "$DIR/research.md" ]     && { echo "❌ Missing research.md. Run /curdx-flow:research first"; exit 1; }
-[ ! -f "$DIR/requirements.md" ] && { echo "❌ Missing requirements.md. Run /curdx-flow:requirements first"; exit 1; }
-```
-
-## Step 2: Update state
-
-```python
-import json
-p = f'.flow/specs/{SPEC_NAME}/.state.json'
-s = json.load(open(p))
-s.setdefault('phase_status',{})['design']='in_progress'
-s['phase']='design'
-json.dump(s, open(p,'w'), indent=2, ensure_ascii=False)
-```
-
-## Step 3: Dispatch flow-architect
-
-```
-Task:
-  subagent_type: general-purpose
-  description: "Architectural design $SPEC_NAME"
-  prompt: |
-    You are the flow-architect agent. The full definition is at:
-    ${CLAUDE_PLUGIN_ROOT}/agents/flow-architect.md
-    
-    Prerequisites (must read):
-    - .flow/specs/$SPEC_NAME/research.md
-    - .flow/specs/$SPEC_NAME/requirements.md
-    - .flow/PROJECT.md
-    - .flow/STATE.md
-    
-    Template:
-    ${CLAUDE_PLUGIN_ROOT}/templates/design.md.tmpl
-    
-    Knowledge base:
-    - ${CLAUDE_PLUGIN_ROOT}/knowledge/spec-driven-development.md (especially Phase 3)
-    
-    Output:
-    .flow/specs/$SPEC_NAME/design.md
-    
-    **Key rules**:
-    1. Must call mcp__sequential-thinking__sequentialthinking **at least 8 rounds**
-       - Rounds 1-2: constraint identification
-       - Rounds 3-4: option A
-       - Rounds 5-6: option B
-       - Round 7: selection
-       - Round 8+: rebuttal
-    
-    2. Every library must be verified with mcp__context7__:
-       - resolve-library-id
-       - query-docs
-    
-    3. Assign AD-NN to each architectural decision
-       - Include the sequentialthinking source round number
-       - Include trade-off explanation
-    
-    4. Project-level decisions must be synced to .flow/STATE.md (D-NN)
-    
-    5. Must draw ≥1 mermaid diagram
-    
-    6. Every component must have a TypeScript interface or equivalent type definition
-    
-    7. Every NFR must have a corresponding design point in the design
-    
-    Success criteria:
-    - sequential-thinking ≥ 8 rounds (round count reflected in AD references)
-    - AD ≥ 3
-    - Every FR has a component responsible for it in the design
-    - Every NFR has a response
-    - Error paths cover the edge-condition table in requirements.md
-    
-    Forbidden:
-    - Choosing tech from memory
-    - Describing interfaces in natural language
-    - Omitting error paths
-    - Modifying requirements.md
-    
-    When done, return a brief: core ADs, tech stack, component count, D-NN synced to STATE.md.
-```
-
-## Step 4: Validate output
-
-```bash
-DESIGN=".flow/specs/$SPEC_NAME/design.md"
-
-# Required sections
-for sec in "Architectural Decisions" "System Architecture Diagram" "Component Design" "Error Paths"; do
-    grep -q "$sec" "$DESIGN" || echo "⚠ Missing section: $sec"
-done
-
-# AD count
-AD_COUNT=$(grep -c "^### AD-" "$DESIGN" || echo 0)
-[ "$AD_COUNT" -lt 3 ] && echo "⚠ Fewer than 3 architectural decisions (design may not be deep enough)"
-
-# mermaid diagram
-grep -q "mermaid" "$DESIGN" || echo "⚠ No mermaid diagram found"
-
-# sequential-thinking reference
-grep -q "sequentialthinking" "$DESIGN" || echo "⚠ No sequential-thinking round reference in ADs"
-```
-
-## Step 5: STATE.md sync check
-
-```bash
-# The agent should have appended project-level decisions to STATE.md
-# Here we just check whether an append happened
-if ! git diff --quiet .flow/STATE.md 2>/dev/null; then
-    echo "✓ STATE.md updated"
-else
-    echo "ℹ STATE.md unchanged (this spec may have no project-level decisions)"
-fi
-```
-
-## Step 6: Output
-
-```
-✓ design phase complete
-
-File:                .flow/specs/$SPEC_NAME/design.md
-Architectural decisions: N ADs
-Project-level decisions: M synced to STATE.md
-Components:              K
-
-**⚠ Design frozen**: once in tasks phase, any architecture change requires returning to /curdx-flow:design and bumping the version.
-
-Next steps:
-  - Review design.md (especially the AD-NN entries)
-  - If you disagree with a decision, write "Challenge AD-NN: reason" in STATE.md, then re-run /curdx-flow:design
-  - /curdx-flow:tasks  — enter task breakdown
-```
-
-## Error recovery
-
-- sequential-thinking MCP unavailable → agent uses inline `<thinking>` blocks; quality may drop, suggest fixing the MCP then re-running
-- context7 unavailable → supplement with WebSearch; tech pitfall detection will be weaker
-- Agent produced fewer than 3 ADs → design may be too shallow; re-run emphasizing "at least 3 ADs"