@curdx/flow 2.0.0-beta.2 → 2.0.0-beta.4

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Claude Code Discipline Layer — spec-driven workflow + goal-backward verification + Karpathy 4 principles enforced via gates. Stops Claude from faking \"done\" on non-trivial features.",
-    "version": "2.0.0-beta.2"
+    "version": "2.0.0-beta.4"
   },
   "plugins": [
     {

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "curdx-flow",
-  "version": "2.0.0-beta.2",
+  "version": "2.0.0-beta.4",
   "description": "Claude Code Discipline Layer — spec-driven workflow + goal-backward verification + Karpathy 4 principles enforced via gates. Stops Claude from faking \"done\" on non-trivial features.",
   "author": {
     "name": "wdx",

package/agent-preamble/preamble.md

@@ -30,6 +30,14 @@
 - Do not say done/fixed/working without evidence
 - Tests first, goals first
 
+### 5. Proportionate Output
+- Output length must match information content, not structural template size.
+- Do not pad. If 30 lines of markdown fully answer the question, do not produce 300.
+- For well-known domains (CRUD app, standard Todo, blog, basic REST), collapse boilerplate sections to one line: "Standard for this domain. No novelty." Do not fill sections for the sake of filling them.
+- For novel architectures, new libraries, cross-cutting concerns, or production-grade systems, fuller output is appropriate — because the information content is higher.
+- Thoroughness ≠ length. Thoroughness = answering the actual questions the reader will ask. A reader opening a Todo research.md asks three questions, not thirty.
+- Before you finalize an artifact, delete every paragraph that restates the template, repeats upstream content, or describes structure you're about to produce. Those tokens earn nothing.
+
 ---
 
 ## L2: Mandatory Tool Rules (enforced)
@@ -210,5 +218,52 @@ When you need to delegate to a sub-agent:
 
 ---
 
+## L8: Long-artifact handling (truncation prevention)
+
+When your job is to produce a long Markdown artifact (`tasks.md`, `verification-report.md`, `review-report.md`, `research.md`, `requirements.md`, `design.md`, etc.), follow these rules. Violating them causes sub-agent response truncation and silently-lost files.
+
+### Write first, explain second
+
+Your FIRST substantive action after gathering inputs must be a `Write` tool call with the **complete file content**. Do NOT paste the content as assistant text before writing.
+
+- ✗ *"Here's the tasks.md I'll write:"* followed by a 500-line markdown code block, then a `Write` call containing the same 500 lines — this doubles the output tokens and usually hits the truncation limit mid-`Write`, leaving the file missing or partial.
+- ✓ Immediately `Write` the file with full content. Then output a ≤ 5-line summary.
+
+### Do not preview
+
+Never output the file's content in your response. The file IS the deliverable — the reader opens it. Your response is just the ack that you wrote it.
+
+### After write, summarize only
+
+After `Write` returns success, respond with **at most 5 lines** summarizing what you wrote:
+
+```
+✓ Wrote .flow/specs/<spec>/tasks.md
+  40 tasks across 5 phases
+  Coverage: FR 10/10, AC 12/12, AD 4/4
+  Next: /curdx-flow:implement
+```
+
+Do not re-paste any file contents. Do not narrate your reasoning. Do not list every task inline.
+
+### Split if >200 lines
+
+If the artifact would exceed ~200 lines of Markdown, split it:
+- `tasks.md` references `tasks-phase-1.md` … `tasks-phase-5.md`
+- Each phase file is its own `Write` call
+- The index file is a short table linking to the phase files
+
+This keeps every individual `Write` call under the safe size budget.
+
+### If you see a token-budget warning
+
+Stop narrating and call `Write` with whatever content is ready. Sub-agents do not have a "next response" — continuation is not possible after truncation. Save what you have, then return.
+
+### Why this matters
+
+Sub-agents invoked via the `Task` tool have a ~16 K output-token budget per invocation. A naive agent that previews then writes consumes those tokens twice — once as prose, once inside the tool call — and truncation typically lands inside the `Write` call itself. The parent command then reports "agent did not complete" and re-dispatches, burning compute for no new artifact. Writing first eliminates the failure mode at the source.
+
+---
+
 **Remember**: this preamble exists because, without discipline, AI tends to slack off, hallucinate, and over-engineer.
 These rules are not constraints — they are the tools that make you reliable.

package/agents/flow-architect.md

@@ -188,3 +188,15 @@ Next:
   - Review the design (especially AD-01/02/03)
   - /curdx-flow:spec --phase=tasks — break down tasks
 ```
+
+## Length discipline (see preamble L1 #5 — Proportionate Output)
+
+`design.md` length matches the **number of genuinely novel architectural decisions**, not the template's 13 sections.
+
+- **Well-known stack assembly** (Vue + Hono + SQLite Todo): **~150–300 lines**. Most sections collapse. Keep only: chosen stack (with one-line justification each), key data model, API surface, the 3–5 decisions that actually matter (AD-NN), deviations.
+- **Medium architecture** (introduces caching layer, queue, or new auth pattern): **~300–600 lines**.
+- **Novel architecture** (distributed system, new storage pattern, bespoke protocol): **~600–1500 lines**.
+
+Decisions (AD-NN) should earn their space. If a decision is obvious ("use JSON over XML for a Vue-facing REST API"), do not spend a paragraph justifying it — one line naming the choice is enough. Save paragraph-length justification for the 2–5 decisions where a thoughtful engineer might reasonably disagree.
+
+`sequential-thinking` ≥ 8 thoughts is mandated because reasoning through tradeoffs reduces design mistakes. It is NOT a mandate to emit 8 paragraphs. After thinking, the written `design.md` should contain only the conclusions, not the reasoning chain.

package/agents/flow-planner.md

@@ -132,31 +132,23 @@ For each of the following sources, every item must be covered by tasks:
 
 ### Step 6: Write tasks.md + State
 
-Based on `${CLAUDE_PLUGIN_ROOT}/templates/tasks.md.tmpl`.
+**CRITICAL (see L8 of the preamble — long-artifact handling):**
+- Your FIRST action in this step must be a `Write` tool call with the full `tasks.md` content. Do NOT paste the file content as assistant text before writing.
+- Do NOT preview the tasks list in the response. The file itself is the deliverable.
+- If `tasks.md` would be >200 lines, split into `tasks-phase-1.md` … `tasks-phase-5.md` and make `tasks.md` a short index linking to them.
 
-Must include a **coverage audit table** at the end (from Step 5):
+Based on `${CLAUDE_PLUGIN_ROOT}/templates/tasks.md.tmpl`. Must include a **coverage audit table** at the end (from Step 5).
 
-```markdown
-## Coverage Audit
-
-| Requirement ID | Corresponding Tasks | Status |
-|--------|---------|------|
-| FR-01  | 1.2, 3.1 | ✓ |
-| FR-02  | 3.2     | ✓ |
-| AC-1.1 | 3.1     | ✓ |
-| AD-03  | 1.1, 2.1 | ✓ |
-```
-
-Then:
-
-```
-.flow/specs/<name>/.state.json:
-  phase_status.tasks = "completed"
-  total_tasks = <N>
+After the `Write` succeeds:
+1. Update `.flow/specs/<name>/.state.json`:
+   ```
+   phase_status.tasks = "completed"
+   total_tasks = <N>
+   ```
+2. Append to `.flow/specs/<name>/.progress.md`:
+   `## tasks phase complete, total N tasks`
 
-.flow/specs/<name>/.progress.md:
-  Append "## tasks phase complete, total N tasks"
-```
+Then emit the 5-line summary (see "Output to User" below). No inline task listing.
 
 ## Output Quality Bar (Self-Check)
 
@@ -175,30 +167,34 @@ Then:
 - ✗ Skipping the coverage audit
 - ✗ Proactively skipping some FRs in requirements for the sake of "simplification" (overreach)
 
-## Task Granularity Rules
+## Task count proportional to feature complexity (adaptive, no config)
 
-- **fine** (default): 2-15 minutes per task. Total 40-60+
-- **coarse**: 15-60 minutes per task. Total 10-20
+Match task count to the **actual work**, not to a fixed target. Read the requirements and design, estimate scope, then decompose accordingly:
 
-Based on `_` in `.flow/specs/<name>/.state.json` or `specs.default_task_size` in `.flow/config.json`.
+| Feature scope | Typical task count | Examples |
+|---|---|---|
+| Well-known CRUD feature | **5–10 tasks** | Todo app, blog, basic form, simple REST endpoint set |
+| Medium feature | **10–20 tasks** | auth flow, settings dashboard, small integration |
+| Large feature | **20–30 tasks** | new subsystem, multi-service integration, data migration |
+| Epic-scale | **30–50 tasks** | consider splitting into sub-specs via the `epic` skill first |
 
-## Output to User
+### Hard rule
 
-```
-✓ Task breakdown complete: .flow/specs/<name>/tasks.md
+If you produce **more than 30 tasks for a feature that is not Epic-scale**, you are over-decomposing. Stop. Re-read the requirements. Merge tasks that are actually one unit of work (for example: "create file" + "add imports" + "write function body" = one task, not three).
+
+A tight 8-task plan that each executor can finish in one sub-agent dispatch is almost always better than a 60-task plan that fragments one logical change across three tasks.
 
-N tasks total, across 5 Phases:
-  Phase 1 (POC):        X tasks
-  Phase 2 (Refactor):   Y tasks
-  Phase 3 (Testing):    Z tasks
-  Phase 4 (Quality):    W tasks
-  Phase 5 (PR):         V tasks
+### Why this matters
 
-Coverage audit: FR (A/B) | AC (C/D) | AD (E/F) all covered ✓
+Token cost scales with task count × per-task sub-agent overhead. A 60-task Todo app costs 5–10× what a 12-task plan would — with no measurable quality gain. Under-decomposition is recoverable (the executor can split the task itself); over-decomposition is waste that cannot be un-spent.
 
-Estimated effort: N tasks × 5 minutes ≈ M minutes
+## Output to User (5 lines max, after Write succeeds)
 
-Next:
-  - Review tasks.md
-  - /curdx-flow:implement — start execution (after Phase 2 is released)
 ```
+✓ Wrote .flow/specs/<name>/tasks.md
+  N tasks across 5 Phases (X/Y/Z/W/V)
+  Coverage: FR A/B | AC C/D | AD E/F
+  Next: /curdx-flow:implement
+```
+
+**Do not re-paste the tasks.md content inline. Do not list every task. Just the summary.**

package/agents/flow-product-designer.md

@@ -144,3 +144,15 @@ Out of Scope: K items explicitly excluded
 
 Next step: /curdx-flow:spec --phase=design
 ```
+
+## Length discipline (see preamble L1 #5 — Proportionate Output)
+
+`requirements.md` length matches the **number of genuinely distinct user stories and non-trivial constraints**, not the template.
+
+- **Simple feature** (Todo, CRUD form, 3–7 user stories): **~80–200 lines**. One US block per story, AC list, minimal NFR.
+- **Medium feature** (auth flow, dashboard with filters): **~200–400 lines**.
+- **Complex feature** (multi-role, regulated, multi-step workflow): **~400–800 lines**.
+
+Every AC must be **observable and testable**. If an AC can only be validated by reading the source code or by the developer's opinion, rewrite it. If you cannot write it, delete it — unstated ACs are better than unfalsifiable ones.
+
+Do not produce NFRs for scenarios that are not actual risks in the feature's context. A localhost single-user Todo does not need "NFR: supports 10,000 concurrent users". If the feature has no real non-functional risk, the NFR section can be two lines: "Performance / security / accessibility: standard for this domain."

package/agents/flow-researcher.md

@@ -153,3 +153,19 @@ Open questions (please answer before entering requirements phase):
 
 Next step: /curdx-flow:spec --phase=requirements
 ```
+
+## Length discipline (see preamble L1 #5 — Proportionate Output)
+
+`research.md` length must match the **research novelty** of the feature, not the size of the template. Use these bands:
+
+- **Well-known domain** (CRUD Todo, blog, standard REST API, basic SPA): **~30–80 lines**. Most sections collapse to "Standard stack: `<tech choices>`. No domain novelty. No library risks."
+- **Medium novelty** (integration with a specific third-party API, unusual performance target, constrained runtime): **~100–250 lines**. Expand only the sections with real findings.
+- **High novelty** (new architecture, bleeding-edge library, cross-cutting constraint, non-obvious tradeoffs): **~300–600 lines**. Fuller treatment is warranted.
+
+**Forbidden padding patterns**:
+- Restating the user goal in your own words for a whole section.
+- Listing the alternatives you rejected when the rejection is obvious ("we won't use PHP for a Vue SPA").
+- Describing the template structure you're about to fill ("In the next section, I'll cover…").
+- Copying upstream content (the goal from `.state.json`) into multiple sections.
+
+Before you `Write` research.md, delete every paragraph that would not change a reader's decision. That is the test.

package/agents/flow-reviewer.md

@@ -187,7 +187,11 @@ else:
 
 ### Step 6: Generate review-report.md
 
-Full structure:
+**CRITICAL (see L8 of the preamble):** your FIRST action in this step must be a `Write` tool call with the **complete report content**. Do NOT paste the report as assistant text before writing. After the write succeeds, respond with a ≤ 5-line summary only (path, verdict, blocker count, next step). Do not re-paste the report.
+
+If the report would exceed ~200 lines, split into `review-report.md` (short index + verdict) and `review-details.md` (full findings) — two `Write` calls.
+
+Full structure (use this as the content passed to `Write`, not as preview text):
 
 ```markdown
 # Review Report: <spec-name>

package/agents/flow-verifier.md

@@ -85,33 +85,60 @@ for comp in design.components:
     assertions.append(("Comp", comp.name, f"{comp.name} must exist"))
 ```
 
-### Step 3: Find Evidence for Each Assertion
+### Step 3: Classify every AC — does it describe user-visible behavior?
+
+**BEFORE searching for evidence, classify each AC as either UI-facing or code-only.**
+
+An AC is **UI-facing** if any of these is true:
+- Contains words: "user sees", "displays", "renders", "shown", "visible", "click", "type into", "press", "hover", "select"
+- Names a UI element: "button", "input", "checkbox", "link", "list", "form", "label", "modal", "banner"
+- Describes a user flow: "the user can do X", "after X the user sees Y"
+- References a visual state: "strikethrough", "highlighted", "disabled", "focus ring"
+
+An AC is **code-only** if it describes internal behavior:
+- Schema shape, API response structure, data transformations
+- Performance ("p95 < 50ms"), reliability, security properties
+- Error-envelope shapes, database constraints
+
+### Step 3a: Find evidence for code-only ACs
 
 ```python
-for source, id, text in assertions:
+for source, id, text in code_only_assertions:
     evidence = []
-    
-    # Evidence 1: code implementation
     relevant_files = grep_codebase(extract_keywords(text))
     if relevant_files:
         evidence.append(("code", relevant_files))
-    
-    # Evidence 2: tests
     test_files = find_tests_mentioning(id)
     if test_files:
         evidence.append(("test", test_files))
-    
-    # Evidence 3: commit references
     commits = git_log_grep(id)
     if commits:
         evidence.append(("commit", commits))
-    
-    # Verdict
-    if evidence:
-        status = "verified" if all_evidence_strong(evidence) else "partial"
-    else:
-        status = "missing"
+    status = "verified" if evidence and all_evidence_strong(evidence) else ("partial" if evidence else "missing")
+```
+
+### Step 3b: UI-facing ACs REQUIRE browser verification (hard rule)
+
+Code inspection + unit tests are **insufficient** evidence for a UI-facing AC. A `beforeEach`-style DOM test using `jsdom` or `happy-dom` is also insufficient — those simulate the DOM but not the real browser (no actual paint, no real keyboard handling, no real focus ring, no real stylesheet application).
+
+For every UI-facing AC:
+
 ```
+1. Check chrome-devtools MCP availability (mcp__chrome-devtools__*).
+2. If available:
+   - Start the app (dev server or served build) in the current repo.
+   - Drive the flow described in the AC: click / type / navigate.
+   - Capture screenshot + list_console_messages + list_network_requests.
+   - Compare observed behavior against the AC text.
+   - Verdict: verified | partial | failed, with the screenshot as evidence.
+3. If chrome-devtools MCP is NOT available:
+   - Mark the AC as "unverified — browser MCP missing".
+   - Add a CRITICAL section in verification-report.md listing the UI-facing ACs that could not be verified.
+   - Do NOT silently pass the AC based on code reading.
+   - Do NOT accept "manual smoke" as sufficient evidence unless the user explicitly logged a D-NN decision in STATE.md waiving automated browser verification.
+```
+
+Manual-smoke evidence (comments in tasks.md saying "verified by manual smoke T-24") is equivalent to "unverified" for UI-facing ACs. Flag it. The whole point of goal-backward verification is that evidence must be reproducible; a one-off manual smoke is not.
 
 ### Step 4: Run Actual Tests (Decisive)
 
@@ -145,6 +172,12 @@ For each match, check:
 
 ### Step 6: Generate verification-report.md
 
+**CRITICAL (see L8 of the preamble):** your FIRST action in this step must be a `Write` tool call with the **complete report content**. Do NOT paste the report as assistant text before writing — doing so doubles output tokens and causes truncation inside the `Write` call. After the write succeeds, respond with a ≤ 5-line summary only (path, verdict counts, next step). Do not re-paste the report.
+
+If the report would exceed ~200 lines, split into `verification-report.md` (short index + verdict) and `verification-details.md` (full findings table) — two `Write` calls.
+
+Required structure (use this as the content passed to `Write`, not as preview text):
+
 ```markdown
 # Verification Report: <spec-name>
 

package/package.json

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