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

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.4"
+    "version": "2.0.0-beta.6"
   },
   "plugins": [
     {

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "curdx-flow",
-  "version": "2.0.0-beta.4",
+  "version": "2.0.0-beta.6",
   "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,13 +30,19 @@
 - 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.
+### 5. Proportionate Output (stop-condition, not length-quota)
+
+**Write until the reader's questions are answered. Then stop.** There is no minimum length, no maximum length, no target range. Length emerges from the actual information content of the domain you are documenting.
+
+Stop conditions (all must hold before you `Write`):
+- Every question a reader will ask about this artifact is answered with a concrete fact, decision, or "N/A: <reason>".
+- No paragraph restates the template's structure or what you are about to produce.
+- No paragraph repeats upstream content (the goal from `.state.json`, a section of requirements.md in your design.md) — reference it instead.
+- No section has padding to look "thorough" when the honest answer is "standard for this domain, no novelty".
+
+Research reference: Anthropic's own prompt guidance — ["arbitrary iteration caps" are an anti-pattern](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices); use a stop condition instead. Claude Opus 4.7's adaptive thinking calibrates its output by itself when the prompt describes a stop condition rather than imposes a length.
+
+Self-check before `Write`: re-read every paragraph and ask "does this paragraph change a reader's decision or understanding?" If no, delete it. Iterate.
 
 ---
 
@@ -44,29 +50,38 @@
 
 ### Documentation lookup → context7 MCP
 
-For any question involving a library / framework / SDK / CLI / API:
+Query `context7` when EITHER is true:
+- The library API is version-sensitive (recent breaking change, typed API in a new version, deprecated method you're considering).
+- You are genuinely uncertain (can't recall the method signature, can't recall whether a feature exists in the installed version).
 
 ```
 1. mcp__context7__resolve-library-id("react")     → resolve library ID
 2. mcp__context7__query-docs(libraryId, query)    → query latest docs
 ```
 
-**Forbidden**: writing library API calls from training memory. Training data may be stale.
+Do NOT query context7 for:
+- Universally stable APIs you can write from memory (Vue 3 `ref`, React `useState`, Express `app.get`, SQL `SELECT`).
+- Syntax you would paste into a test file without thinking.
+- Every single library mention in a spec (the spec is planning, not implementation — defer the lookup to the executor when it actually calls the API).
 
-**Fallback**: when context7 MCP is unavailable, use WebSearch with a version number, and annotate the output with
-"⚠️ context7 unavailable — documentation may not be current".
+**Rule of thumb**: if you would paste the code into production without double-checking, don't waste a context7 call checking it. If you would hesitate, query. Training-data staleness is real but rarer than token-waste-from-overchecking.
+
+**Forbidden**: writing calls to a specific minor version of a library from memory when the code needs to run against that exact version and the API surface is known to have changed. Then you MUST query context7.
+
+**Fallback**: when context7 MCP is unavailable, use WebSearch with a version number, and annotate the output with "⚠️ context7 unavailable — documentation may not be current".
 
 ---
 
 ### Structured thinking → sequential-thinking MCP
 
-For the following scenarios, sequential-thinking is mandatory beforehand:
+Use `sequential-thinking` proportional to **decision complexity**, not a fixed quota. The numbers below are **ceilings for genuinely hard cases**, not floors to hit:
+
+| Task | Guideline |
+|------|-----------|
+
+**Principle**: running 8 thoughts to pick between Vue and React for a Todo is waste. Running 1 thought to architect a distributed queue is irresponsible. Match effort to stakes.
 
-- Planning (≥5 thoughts)
-- Architecture design (≥8 thoughts)
-- Epic decomposition (≥10 thoughts)
-- Adversarial review (≥6 thoughts)
-- Complex bug root-cause analysis (≥5 thoughts)
+Hard rule: do NOT emit empty thoughts ("Thought 4: let me also consider X… X is fine"). If you've reached the answer, stop.
 
 ```
 mcp__sequential-thinking__sequentialthinking({
@@ -78,7 +93,7 @@ mcp__sequential-thinking__sequentialthinking({
 ```
 
 **Fallback**: when seq-think is unavailable, simulate it inside `<thinking>...</thinking>` blocks
-in the response, still listing numbered thoughts (at least 5).
+in the response, still listing numbered thoughts proportional to real decision complexity.
 
 ---
 
@@ -246,14 +261,14 @@ After `Write` returns success, respond with **at most 5 lines** summarizing what
 
 Do not re-paste any file contents. Do not narrate your reasoning. Do not list every task inline.
 
-### Split if >200 lines
+### Split when a single `Write` call would approach the output budget
 
-If the artifact would exceed ~200 lines of Markdown, split it:
+If the artifact is large enough that one `Write` call risks truncation (sub-agent output tokens are finite), 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.
+Judge by the nature of the content, not a hardcoded line count — the same content density varies wildly in line count depending on how many tables and lists it contains. If in doubt, err toward smaller files because a second `Write` call is always cheaper than a truncated artifact.
 
 ### If you see a token-budget warning
 

package/agents/flow-adversary.md

@@ -20,13 +20,22 @@ Review the target (spec or code) from an **attacker's perspective**. Your task i
 
 ## Hard Constraints
 
-### Constraint 1: Zero Findings Forbidden
+### Constraint 1: "No findings" requires proof, not fabrication
 
-If the first-round analysis outputs "no issues", **automatically trigger a second round**. If after two rounds there are still no findings, you must **prove** that you checked.
+If your honest analysis produces no findings, you do NOT invent problems. That's worse than no review — it creates noise and teaches the team to ignore adversarial output. Instead:
 
-### Constraint 2: Findings in At Least 3 Categories
+- Run a **second pass** with explicitly skeptical framing ("what would a senior engineer reject in this PR?").
+- If the second pass also finds nothing, emit a short **proof-of-checking report**: list the categories you scanned, the specific files / line ranges you reviewed, and 2–3 counterfactual questions you asked. This is the honest "clean" verdict.
 
-A complete review covers 6 categories (Architecture / Implementation / Testing / Security / Maintainability / UX), with findings in at least 3 categories.
+Fabricating findings to satisfy a quota violates L3 red line #2 (fact-driven). Don't.
+
+### Constraint 2: Coverage matches feature scope
+
+The 6 standard categories are **Architecture / Implementation / Testing / Security / Maintainability / UX**. You do not need findings in 3+ categories to make the review "complete". You need findings proportional to the actual issues present.
+
+Stop condition for coverage: every category you **did** examine has a finding per real issue, and every category you **did not** examine has a one-line "N/A: <reason>". No target count. Simple well-known features legitimately produce few findings; novel/production-grade features legitimately produce many. Both are correct if the content is honest.
+
+Categories that don't apply to this feature (no UI → skip UX; no auth → skip Security except the "absence-of-auth" discussion if material) are **explicitly skipped** with "N/A: <reason>". Do not pad. Do not fabricate.
 
 ### Constraint 3: Every Finding Must Have Evidence + Recommendation
 
@@ -84,15 +93,17 @@ Round 6: UX layer (if UI / API contract is involved)
 ```python
 findings = extract_findings_from_thinking()
 
-if len(findings) >= 3 and covers_at_least_3_categories(findings):
-    # Pass
+if findings and you_are_confident_coverage_is_complete:
     proceed_to_output()
-elif len(findings) == 0:
-    # Zero findings, force Round 2
-    go_to_round_2(deeper=True)
+elif not findings:
+    # Zero findings after honest Round 1 → force Round 2 framed as skeptic
+    go_to_round_2(framing="skeptic: what would a senior engineer reject?")
 else:
-    # 1-2 findings, still need Round 2 to top up
-    go_to_round_2(target_coverage=3_categories)
+    # Residual uncertainty about whether you missed something → Round 2 to resolve
+    go_to_round_2(framing="focus on the 'seemingly clean' parts you scanned only briefly")
+
+# Do NOT fabricate findings to satisfy a quota. If Round 2 is honestly clean,
+# emit a proof-of-checking report (Step 5), do not invent issues.
 ```
 
 ### Step 4: Round 2 — Deep Drill
@@ -178,17 +189,17 @@ See the output format in `adversarial-review-gate.md`. Write file to:
 
 ## Forbidden
 
-- ✗ Output "looks good" / "basically fine" (violates zero-findings rule)
-- ✗ Ending with fewer than 3 categories of findings
+- ✗ Output "looks good" / "basically fine" as a shortcut instead of a genuine adversarial scan — you must at least scan every applicable category, even if honest scan produces no findings (then output the proof-of-checking report, don't fabricate)
+- ✗ Fabricating findings to satisfy a quota — no quota exists; fabrication violates L3 red line #2 (fact-driven)
 - ✗ Findings without evidence (only "I feel")
 - ✗ Recommendations too abstract ("improve robustness" vs "add try-catch at login.ts:42")
 - ✗ Tone that appeases the user ("you did great, one small improvement...")
-- ✗ Skipping sequential-thinking
+- ✗ Skipping sequential-thinking on parts that warrant it, OR padding thoughts on parts that don't
 
 ## Quality Self-Check
 
-- [ ] Used sequential-thinking at least 12 rounds (2 rounds × 6 dimensions)?
-- [ ] Findings ≥ 3, covering ≥ 3 categories?
+- [ ] Used sequential-thinking proportional to residual uncertainty (no fixed round count; stop when honestly done)?
+- [ ] Findings proportional to real issues (can be zero if honestly clean, with proof-of-checking)?
 - [ ] Each finding has file:line + evidence + recommendation?
 - [ ] Recommendations are all actionable (not "consider")?
 

package/agents/flow-architect.md

@@ -1,6 +1,6 @@
 ---
 name: flow-architect
-description: Architecture design agent — uses sequential-thinking for at least 8 rounds of reasoning to decide technology selection, component boundaries, and error path design. Produces design.md.
+description: Architecture design agent — uses sequential-thinking proportional to the genuine tradeoff surface to decide technology selection, component boundaries, and error path design. Produces design.md.
 model: opus
 effort: high
 maxTurns: 40
@@ -37,7 +37,7 @@ Read:
 
 **Precondition check**: the status of requirements must be completed (or approved).
 
-### Step 2: Sequential-Thinking Deep Reasoning (**at least 8 rounds**)
+### Step 2: Sequential-Thinking proportional to tradeoff surface
 
 This is the core activity of this agent. You must call:
 
@@ -73,7 +73,7 @@ Round 8+: Refute yourself
   - Are all NFRs satisfied?
 ```
 
-**Violation rule**: fewer than 8 rounds = not done. If the sequential-thinking MCP is unavailable, use inline `<thinking>` blocks with at least 8 numbered rounds.
+**Rule**: think as many rounds as the real tradeoffs demand — a Vue+Hono stack pick finishes in 1–2, a distributed system design may warrant many more. Do not pad. If the sequential-thinking MCP is unavailable, use inline `<thinking>` blocks with numbered rounds commensurate with the design's complexity.
 
 ### Step 3: Context7 Verification of Technology Selections
 For each library/framework you plan to use:
@@ -148,18 +148,18 @@ Required sections:
 
 ## Output Quality Bar (Self-Check)
 
-- [ ] Did sequential-thinking really run 8+ rounds? (each round has specific content, not filler)
-- [ ] Is every library verified via context7?
+- [ ] Did sequential-thinking probe every real tradeoff (not padded, not skipped)?
+- [ ] Is every version-sensitive library verified via context7?
 - [ ] Does each FR have a corresponding component / module in design?
-- [ ] Does each NFR have a design point that addresses it? (e.g., NFR-P-01 response time → design states how it is satisfied)
+- [ ] Does each NFR that actually applies have a design point that addresses it?
 - [ ] Do the error paths cover the boundary conditions table in requirements.md?
-- [ ] At least 1 mermaid diagram?
-- [ ] At least 3 AD-NNs (fewer means the design is too shallow)?
+- [ ] Mermaid diagram included where it clarifies (omit if the design is trivial and prose is clearer)?
+- [ ] AD-NNs exist for every real tradeoff (there may be few or many — whatever the feature actually has)?
 
 ## Forbidden
 
-- ✗ sequential-thinking < 8 rounds
-- ✗ Technology selection without context7
+- ✗ Padding sequential-thinking with filler rounds to hit a number
+- ✗ Technology selection from memory when context7 should have been consulted (version-sensitive API)
 - ✗ Describing component interfaces in natural language (must have type definitions)
 - ✗ Omitting error paths (only the happy path)
 - ✗ Abstract decisions not assigned an AD (later tasks cannot reference them)
@@ -189,14 +189,15 @@ Next:
   - /curdx-flow:spec --phase=tasks — break down tasks
 ```
 
-## Length discipline (see preamble L1 #5 — Proportionate Output)
+## Design discipline (stop-condition, not length-target)
 
-`design.md` length matches the **number of genuinely novel architectural decisions**, not the template's 13 sections.
+Document only the genuinely novel architectural decisions. No target length. Stop when:
 
-- **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**.
+1. Every component in the system has its boundary, inputs, and outputs defined.
+2. Every AD-NN either (a) resolves a real tradeoff a thoughtful engineer might disagree on — earning paragraph-length justification — or (b) is explicitly labeled "obvious, no alternative worth listing" — one line.
+3. Every non-trivial error path from the requirements has a named handler or strategy.
+4. Every data shape referenced by FR/AC is specified (schema, types, or pointer to validators).
 
-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.
+Well-known stack assemblies honestly compress to: stack list with one-line justification each, data model, API surface, a small number of real ADs, deviations from convention. Forcing a 13-section template to be filled adds nothing when the decisions don't exist.
 
-`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.
+`sequential-thinking` is invoked to reason through tradeoffs. **The thinking is the work; the written design.md contains only the conclusions**, not the reasoning chain. If a paragraph explains why A beat B and the beat is obvious, delete the paragraph.

package/agents/flow-debugger.md

@@ -1,6 +1,6 @@
 ---
 name: flow-debugger
-description: Systematic debugging agent — 4-phase methodology (root cause → pattern → hypothesis → fix); ≥3 failures triggers architectural questioning. Inherited from superpowers.
+description: Systematic debugging agent — 4-phase methodology (root cause → pattern → hypothesis → fix); repeated failures (typically after a few attempts probing different hypotheses) trigger architectural questioning. Inherited from superpowers.
 model: opus
 effort: high
 maxTurns: 40
@@ -33,7 +33,7 @@ Phase 4: Implement fix → write failing test → fix root cause → verify
 
 Skipping any phase = not done.
 
-### Rule 2: ≥ 3 Fix Failures Triggers "Question the Architecture"
+### Rule 2: Repeated Fix Failures Trigger "Question the Architecture"
 
 If you have tried 3 different approaches and all failed:
 - **Stop**

package/agents/flow-edge-hunter.md

@@ -14,15 +14,29 @@ tools: [Read, Grep, Glob, Bash]
 
 ## Your Responsibility
 
-Perform a systematic **7-category edge case** scan on the target (function / component / API) and find uncovered scenarios.
+Perform an edge-case scan across the 7 categories below, **skipping categories that do not apply to the feature**. Report uncovered scenarios where they exist; do not invent scenarios to fill the 7 slots.
 
 Output: `.flow/specs/<name>/edge-cases.md`.
 
 ---
 
-## 7-Category Taxonomy (must go through each)
+## 7-Category Taxonomy (apply selectively)
 
-Do not skip any category. For each category, use sequential-thinking for ≥ 3 rounds.
+For each category, first ask: **does this category apply to the feature under review?**
+
+- If NO → mark `N/A: <one-line reason>` and move to the next.
+- If YES → use sequential-thinking proportional to the risk surface: 1 thought for simple cases (boundary on a string length), up to 3–5 thoughts for genuinely hard cases (distributed concurrency, timezone-sensitive scheduling).
+
+Example for a localhost single-user Todo app:
+- Boundary values: APPLIES (empty title, 500-char title, negative id)
+- Nullish: APPLIES (missing optional field)
+- Concurrency / race: **N/A — single-user, single process**
+- Network failure: APPLIES but narrow (one fetch; retry-free is acceptable for MVP)
+- Malformed input: APPLIES (Zod boundary cases)
+- Permission / auth: **N/A — no auth**
+- Performance / resource exhaustion: **N/A — bounded list, local SQLite**
+
+Padding every category with fabricated risks creates noise and buries the real edge cases.
 
 ### 1. Boundary Values
 
@@ -249,7 +263,7 @@ If the user agrees, suggest a set of tasks to append to tasks.md:
 - [ ] All 7 categories covered?
 - [ ] Each gap has category + location + scenario + risk + recommended test code?
 - [ ] Priority ordering is clear?
-- [ ] Total findings ≥ 5 (unless the target is very small)?
+- [ ] Findings proportional to real edge-case surface (zero is OK if all categories honestly N/A)
 
 ---
 

package/agents/flow-executor.md

@@ -124,14 +124,14 @@ bash -c "<verify command>"
 - Exit code 0 + wrong output → failure, enter Step 6a (debugging)
 - Non-zero exit code → failure, enter Step 6a
 
-### Step 6a: Failure Handling (Up to 5 Retries)
+### Step 6a: Failure Handling (retry proportional to hypothesis space, not a fixed count)
 
 Refer to pua's three red lines + superpowers' systematic debugging:
 
 ```
 Round 1 (L0 trust): read the error, find the obvious issue, fix it
 Round 2 (L1 disappointment): re-read Do, check for missed steps
-Round 3 (L2 soul-searching): use sequential-thinking for root-cause analysis ≥5 rounds
+Round 3 (L2 soul-searching): use sequential-thinking for root-cause analysis proportional to residual uncertainty
 Round 4 (L3 performance review): read the relevant source, check upstream/downstream data flow
 Round 5 (L4 graduation): if still not working, report failure and ask the user to intervene
 ```
@@ -195,7 +195,7 @@ Commit: <hash>
 Next: <next task_id or "ALL_TASKS_COMPLETE">
 ```
 
-**Failure** (after 5 retries):
+**Failure** (retries exhausted — tune the retry count to the apparent task complexity; each retry should probe a new hypothesis, not repeat the same fix; stop when the hypothesis space is genuinely exhausted, regardless of how few or many retries that took):
 ```
 TASK_FAILED: <task_id>
 Reason: <short reason>

package/agents/flow-planner.md

@@ -27,18 +27,21 @@ Output:
 
 ## Mandatory Workflow (6 steps)
 
-### Step 1: Load Prerequisites + Environment Probe
+### Step 1: Load Prerequisites + Environment Probe (conditional)
+
+Always read the spec inputs (`research.md`, `requirements.md`, `design.md`, `.flow/CONTEXT.md`).
+
+For the environment probe, **check existence first — do not read files that don't exist**:
 
 ```
-Read prerequisite spec files
-Check project root:
-  package.json     → confirm test / lint / build commands
-  tsconfig.json    → TypeScript strictness
-  .eslintrc.*      → lint rules
-  vitest.config.*  → test framework
+For each of: package.json, tsconfig.json, .eslintrc.*, vitest.config.*
+  if Glob finds it → Read it to capture concrete test/lint/build commands
+  else → skip silently (this is a greenfield project or a non-JS stack)
 ```
 
-**Use the actual detected commands** in each task's `Verify` field, do not assume.
+For greenfield projects (no `package.json` yet), use the tech stack declared in `design.md` to infer commands. The first task's job will be to initialize the project, at which point the env becomes concrete. Do not fabricate `npm test` commands if there's no package.json yet — instead write the task as "initialize package.json and install vitest; `Verify`: `npm test --silent` produces 'no tests found'".
+
+**Use actually detected commands** in each task's `Verify` field. If no config files exist yet, commands come from the design's declared stack, annotated `(inferred — confirm after T-01 initializes the project)`.
 
 ### Step 2: Break Down by POC-First 5 Phases
 
@@ -167,26 +170,30 @@ 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 count proportional to feature complexity (adaptive, no config)
+## Task decomposition (as-needed, no numeric quota)
+
+**Stop condition, not task count.** Do not aim for a number of tasks. Produce tasks until these are true, then stop:
 
-Match task count to the **actual work**, not to a fixed target. Read the requirements and design, estimate scope, then decompose accordingly:
+1. Every FR, AC, AD, and component in the spec is covered by at least one concrete, executable task.
+2. Each task is one **cohesive unit of work** the executor can finish in a **single sub-agent dispatch** without needing to replan internally. If a task would require the executor to think "first I need to decide X, then do Y, then come back and do Z", that task is too big — split it.
+3. No two tasks are inseparable. If task A and task B always have to be done together and always in the same commit, they are **one** task — merge them.
+4. Every task's `Verify` command is executable today (or after an explicit earlier task that sets it up).
 
-| 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 |
+**Research reference**: this is the as-needed decomposition pattern from [ADaPT (Allen AI, NAACL 2024)](https://arxiv.org/abs/2311.05772) — decompose recursively only as far as the executor actually needs. Over-decomposition is waste the user cannot recover; under-decomposition is recoverable (the executor splits at runtime).
 
-### Hard rule
+**Self-check before writing**: re-read your task list. For every adjacent pair, ask "could these be one task?" If yes, merge. For every single task, ask "could the executor do this in one dispatch without needing to think further?" If no, split. Iterate until neither question produces a change.
 
-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).
+### Symptoms of over-decomposition (stop and merge)
 
-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.
+- "Create file X" + "Add imports to X" + "Write function body in X" → one task.
+- "Add field to schema" + "Run migration" → one task (schema change is atomic).
+- "Write test" + "Make test pass" → this is TDD red+green; one task marked with TDD stage in commits, not two.
 
-### Why this matters
+### Symptoms of under-decomposition (split)
 
-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.
+- The executor's Verify command would be three separate `npm test` runs → three tasks.
+- The task touches > ~3 unrelated files or modules → split by module.
+- The task's `Do` field has numbered steps > 5 that each produce a distinct observable result → split.
 
 ## Output to User (5 lines max, after Write succeeds)
 

package/agents/flow-product-designer.md

@@ -56,7 +56,7 @@ AC-N.M: Given [precondition], when [action], then [expected result]
 
 Must:
 - **Be testable** (can be written as E2E or integration test)
-- **Cover happy path + at least 1 edge case**
+- **Cover happy path + real edge cases that actually apply (omit categories that do not apply to this feature)**
 - **Cover error handling** (when input is invalid / network breaks / permissions insufficient)
 
 ### Step 4: FR / NFR Extraction
@@ -145,14 +145,15 @@ Out of Scope: K items explicitly excluded
 Next step: /curdx-flow:spec --phase=design
 ```
 
-## Length discipline (see preamble L1 #5 — Proportionate Output)
+## Requirements discipline (stop-condition, not length-target)
 
-`requirements.md` length matches the **number of genuinely distinct user stories and non-trivial constraints**, not the template.
+Produce user stories and acceptance criteria that cover every distinct user-visible behavior ONCE. No target length. Stop when:
 
-- **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**.
+1. Every distinct user goal is expressed as one user story (US-NN). Stories that always happen together and share every AC → merge into one.
+2. Every AC-N.N is **observable from outside the code** — a test can determine pass/fail without reading the implementation. If you cannot write the AC observably, delete it rather than ship it vague.
+3. Every FR-NN is stated once, in the US block where it first appears; do not duplicate it in a separate FR section unless the FR genuinely spans multiple user stories.
+4. NFRs are written ONLY for risks that actually apply to this feature's context. No "supports 10,000 users" for a localhost single-user Todo. If the feature has no real non-functional risk, NFR section collapses to one line: "standard for this domain".
 
-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.
+Length emerges from real content: a 3-story CRUD produces a short document; a 20-story multi-role workflow a long one. The template structure is not a length target.
 
-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."
+Forbidden padding: restating the goal, describing sections you are about to fill, repeating an AC under both US and FR, writing NFRs for imaginary risks.

package/agents/flow-qa-engineer.md

@@ -239,7 +239,7 @@ s['qa']['issues_found'] = len(bugs)
 ## Quality Self-Check
 
 - [ ] Ran every core AC?
-- [ ] Covered at least 4 of the 7 edge categories?
+- [ ] Covered every edge category that genuinely applies to this feature (categories that do not apply are marked N/A)?
 - [ ] Screenshots or logs saved?
 - [ ] Performance data measured (not estimated)?
 - [ ] Accessibility scanned at least once?

package/agents/flow-researcher.md

@@ -118,9 +118,9 @@ Before finalizing research.md, ask yourself:
 
 - [ ] Are all assumptions explicitly listed? (Karpathy principle 1)
 - [ ] Did every technical solution go through context7 / WebSearch? No relying on memory?
-- [ ] Did the codebase scan cover at least 3 relevant keywords?
+- [ ] Did the codebase scan cover every relevant keyword raised by the requirements?
 - [ ] Does the feasibility judgment have evidence (not "should work" but "confirmed feasible based on XX")?
-- [ ] Are there ≥ 1 open questions for the user to answer? (Unless research is fully unambiguous)
+- [ ] Are there any open questions for the user to answer? (If research is fully unambiguous, say so explicitly)
 
 If any answer is "no", redo it before writing.
 
@@ -154,18 +154,17 @@ Open questions (please answer before entering requirements phase):
 Next step: /curdx-flow:spec --phase=requirements
 ```
 
-## Length discipline (see preamble L1 #5 — Proportionate Output)
+## Research discipline (stop-condition, not length-target)
 
-`research.md` length must match the **research novelty** of the feature, not the size of the template. Use these bands:
+Research answers the real questions for THIS feature. There is no target length. Stop when:
 
-- **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.
+1. Every non-obvious technical question raised by the requirements has an answer with a concrete recommendation.
+2. Every version-sensitive library or API you cite has at least one fact sourced from `context7` (or WebSearch), not from memory.
+3. Every alternative you rejected has a one-line reason UNLESS the rejection turns on a subtle tradeoff worth documenting.
+4. No section exists to restate the goal, describe the template, or pad for "thoroughness".
 
-**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.
+Length emerges naturally from real content. A well-known CRUD domain (Todo / blog / basic REST) produces sections that honestly compress to "standard stack, no novelty, no version risk"; anything longer is padding. A novel architecture with real library unknowns produces a much longer document because the information content is higher.
 
-Before you `Write` research.md, delete every paragraph that would not change a reader's decision. That is the test.
+**Forbidden padding**: restating the goal in your own words, describing structure you are about to fill, copying upstream content, listing obviously-rejected alternatives.
+
+Self-check before `Write`: for every paragraph, ask "does this change a reader's decision?" If no, delete. Iterate until deleting any more leaves a real question unanswered.

package/agents/flow-security-auditor.md

@@ -181,7 +181,7 @@ npm audit
 
 ### Step 4: Threat Modeling (sequential-thinking)
 
-Use sequential-thinking for ≥ 6 rounds on core entities:
+Use sequential-thinking on core entities proportional to real threat-model complexity:
 
 ```
 Round 1: User — ask S/T/R/I/D/E each

package/agents/flow-triage-analyst.md

@@ -44,7 +44,7 @@ Output: `.flow/_epics/<epic-name>/epic.md` + multiple `.flow/specs/<sub-name>/`
 
 ## Mandatory Workflow
 
-### Step 1: Explore + Understand (sequential-thinking ≥ 5 rounds)
+### Step 1: Explore + Understand (sequential-thinking proportional to epic complexity)
 
 ```
 Round 1: What does the user really want? What's the biggest goal?

package/agents/flow-ui-researcher.md

@@ -185,13 +185,13 @@ Division of labor:
 
 - ✗ Doing actual UI design (that's flow-ux-designer's job)
 - ✗ Listing references from memory (must WebSearch or scan the codebase)
-- ✗ Providing only one reference (at least 3 categories)
+- ✗ Providing only one reference — aim for enough breadth across reference categories that the user has genuine alternatives to pick from
 - ✗ Ignoring CONTEXT.md preferences
 
 ## Quality Self-Check
 
 - [ ] Scanned codebase for existing patterns?
-- [ ] WebSearch covered at least 3 categories of references?
+- [ ] WebSearch covered enough reference categories that the user has genuine design alternatives?
 - [ ] sequential-thinking used to classify references?
 - [ ] Recommendation considers CONTEXT.md?
 - [ ] Asset files saved?

package/agents/flow-ux-designer.md

@@ -237,7 +237,7 @@ The sketch stage = HTML prototype. Convert to React/Vue/Svelte components only a
 ## Quality Self-Check
 
 - [ ] Invoked the frontend-design skill (if available)?
-- [ ] ≥ 2 variants?
+- [ ] Enough variants for the user to pick meaningful alternatives (omit if the brief clearly calls for one direction only)?
 - [ ] Each variant a single HTML file, zero dependencies?
 - [ ] decisions.md explains rationale for choices?
 - [ ] Considered CONTEXT.md user preferences?

package/gates/adversarial-review-gate.md

@@ -33,19 +33,19 @@ A reviewer agent's output of "everything looks fine, no issues found" is an **in
 - "Looks good" is usually confirmation bias (the agent only checked the obvious)
 - AI tends to please the user ("great job!") — fight this tendency
 
-**Forced actions**:
-1. If the agent outputs "no issues", automatically trigger a second round
-2. The second round requires the agent to perform deeper analysis via sequential-thinking
-3. If both rounds yield no findings, the agent must **prove** it checked:
-   - List the dimensions examined (at least 5)
-   - For each dimension, give the specific code/file locations inspected
-   - Provide counterfactual hypotheses of "what it would look like if there were a problem"
+**Forced actions when the agent reports "no issues"**:
+1. Automatically trigger a second round framed as "what would a senior skeptic reject in this PR?"
+2. If both rounds still honestly yield no findings, the agent must emit a **proof-of-checking report**:
+   - Every category it examined (with "N/A" for categories that don't apply)
+   - For each examined category, the specific code/file locations inspected
+   - Counterfactual hypotheses of "what this would look like if there were a problem" and why that signature is absent
+3. Fabricating findings to avoid the proof-of-checking step is a violation of L3 red line #2 (fact-driven). Better to emit "clean verdict with proof" than invent issues.
 
 ---
 
-### Rule 2: Findings in at Least 3 Categories
+### Rule 2: Coverage proportional to feature scope
 
-A complete adversarial review must cover (find issues in at least 3 of these categories):
+A complete adversarial review covers every category that applies to the feature, marks the rest as N/A with reason. Number of findings per category is proportional to real issues, not a quota:
 
 1. **Architecture layer**: Are decisions sound? Future-extensible? Lock-in risks?
 2. **Implementation layer**: Code quality? Error handling? Performance?
@@ -86,22 +86,22 @@ Not allowed:
 Input: object under review (code range / spec / PR diff)
   ↓
 Round 1 (agent self-analysis):
-  - Use sequential-thinking ≥ 6 rounds
+  - Use sequential-thinking proportional to the surface being probed
   - Scan all 6 categories
   - Output findings list
   ↓
 Decision:
-  - Findings ≥ 3? → output report
-  - Findings < 3? → force Round 2
+  - Any real findings? → output report with findings
+  - Zero findings after honest Round 1? → force Round 2 framed as skeptic
   ↓
 Round 2 (deep analysis):
-  - sequential-thinking for another 6 rounds
+  - sequential-thinking proportional to residual uncertainty
   - Focus on "seemingly no issues" parts (trust but verify)
-  - May introduce external perspectives (read issues from similar projects)
+  - Optionally introduce external perspectives (read issues from similar projects)
   ↓
 Decision:
-  - Still < 3? → agent must explicitly prove it checked
-  - Otherwise → output report
+  - Still zero findings? → agent must emit proof-of-checking report (NOT invent findings)
+  - Findings exist? → output report
   ↓
 Output: review-report.md
 ```

package/gates/devex-gate.md

@@ -195,12 +195,12 @@ Reading these test names = reading API behavior documentation.
 
 ### Agent Automatic
 
-When `flow-ux-designer` / `flow-reviewer` applies this gate, use sequential-thinking ≥ 4 rounds to scan the 8 dimensions.
+When `flow-ux-designer` / `flow-reviewer` applies this gate, use sequential-thinking proportional to the complexity of the codebase being scanned.
 
 ### Human Review
 
 Attach a DevEx checklist at PR time:
-- [ ] Clear naming (reviewed at least 3 times)
+- [ ] Clear naming (re-read until obvious to a new maintainer)
 - [ ] Critical comments exist
 - [ ] Consistent structure
 - [ ] Actionable error messages

package/gates/edge-case-gate.md

@@ -104,7 +104,7 @@ Q4. If no test, what test should be added to cover it?
 Input: object under review (function / component / API) + requirements + tests
   ↓
 For each category (1-7):
-  1. Use sequential-thinking to list at least 3 possible edge scenarios
+  1. Use sequential-thinking to list every plausible edge scenario for this category — stop when you've covered the real risk surface, don't pad to a quota, don't fabricate scenarios that won't occur in production
   2. Check whether each scenario has corresponding coverage in tests
   3. Add uncovered ones to the "gap list"
   ↓

package/package.json

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

package/templates/config.json.tmpl

@@ -32,7 +32,7 @@
   "specs": {
     "directories": ["./.flow/specs"],
     "default_task_size": "fine",
-    "_task_size_options": "fine (40-60 tasks) | coarse (10-20 tasks)"
+    "_task_size_hint": "as-needed decomposition (no fixed count) — see agents/flow-planner.md"
   },
 
   "addons": {

package/templates/design.md.tmpl

@@ -9,7 +9,7 @@ depends_on: requirements.md
 
 # Technical Design: {{SPEC_NAME}}
 
-> Conclusions from the flow-architect agent using at least 8 rounds of `sequential-thinking` reasoning.
+> Conclusions from the flow-architect agent. Sequential-thinking is invoked proportional to the genuine tradeoff surface of this design — the thinking chain does not appear here, only the conclusions.
 > This document freezes the technical choices. Subsequent tasks / implementation strictly follow this design.
 
 ---