@curdx/flow 2.0.0-beta.3 → 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.3"
+    "version": "2.0.0-beta.4"
   },
   "plugins": [
     {

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "curdx-flow",
-  "version": "2.0.0-beta.3",
+  "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)

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

@@ -167,12 +167,26 @@ Then emit the 5-line summary (see "Output to User" below). No inline task listin
 - ✗ 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 |
+
+### Hard rule
+
+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.
+
+### Why this matters
+
+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.
 
 ## Output to User (5 lines max, after Write succeeds)
 

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-verifier.md

@@ -85,34 +85,61 @@ 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)
 
 For each FR / AC, attempt to **run the tests** to confirm:

package/package.json

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