@curdx/flow 2.0.0-beta.1 → 2.0.0-beta.10

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

package/.claude-plugin/plugin.json

@@ -1,13 +1,13 @@
 {
   "name": "curdx-flow",
-  "version": "2.0.0-beta.1",
+  "version": "2.0.0-beta.10",
   "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",
     "email": "bydongxin@gmail.com"
   },
-  "homepage": "https://github.com/wdx/curdx-flow",
-  "repository": "https://github.com/wdx/curdx-flow",
+  "homepage": "https://github.com/curdx/curdx-flow",
+  "repository": "https://github.com/curdx/curdx-flow",
   "license": "MIT",
   "keywords": [
     "workflow",
@@ -31,13 +31,6 @@
         "-y",
         "@modelcontextprotocol/server-sequential-thinking"
       ]
-    },
-    "chrome-devtools": {
-      "command": "npx",
-      "args": [
-        "-y",
-        "chrome-devtools-mcp@latest"
-      ]
     }
   }
 }

package/CHANGELOG.md

@@ -2,6 +2,26 @@
 
 All notable changes to CurDX-Flow will be documented here.
 
+## [Unreleased]
+
+### Fixed (P0)
+
+- `cli/utils.js` — `findRuntime()` referenced `existsSync` without importing it; any user whose `bun`/`uv` was not on PATH hit `ReferenceError` during install or doctor.
+- `hooks/scripts/stop-watcher.sh` — `export STATE_FILE` was placed after the python heredoc, so the stop-hook execution strategy never activated. Moved the export before the heredoc.
+- `package.json` — `skills/` directory was missing from `files[]`; the 5 bundled skills were stripped from the published tarball.
+- `cli/uninstall.js` + `cli/upgrade.js` — `chrome-devtools-mcp` (added as a recommended plugin in beta.8) was missing from uninstall/upgrade lists, making it installable but uninstallable.
+- `cli/protocols.js` — `injectGlobalProtocols()` returned action `"created"` on both ternary branches, silently collapsing the append-to-existing-file case. Atomic write + corrupted-block detection added.
+
+### Changed (structural)
+
+- New `cli/registry.js` is the single source of truth for recommended plugins. `install.js`, `uninstall.js`, `upgrade.js`, and `doctor.js` all import from it.
+- `commands/start.md` and `commands/spec.md` now produce `.state.json` files that match `schemas/spec-state.schema.json` (field names: `spec_name` / `created` / `updated` / `version`; initial phase is `research`, not the undefined `created`).
+- All python heredocs inside hook scripts use quoted delimiters (`<<'PY'`) and read `STATE_FILE` via `os.environ`, closing a shell→python code-injection surface triggered by unusual spec names.
+
+### Removed
+
+- `hooks/scripts/fail-tracker.sh` and its `PostToolUseFailure` registration — the counter was written but never read by any consumer (the intended pua escalation was never implemented). Can be reintroduced when the consumer exists.
+
 ## [2.0.0-beta.1] - 2026-04-20
 
 ### BREAKING — Major redesign: Discipline Layer, not meta-framework

package/README.zh.md

@@ -23,8 +23,8 @@ CurDX-Flow 是一个 Claude Code 插件，把 6 个验证过的 AI 工程工作
 - **8 个可组合 Gate** — Karpathy / Verification / TDD / Coverage / Adversarial / Edge-Case / Security / DevEx
 - **4 种执行策略** — linear / subagent / stop-hook / wave（自动路由）
 - **10 个知识文档** — 规格驱动 / POC-First / 原子提交 / 执行策略 / ...
-- **5 个 hook 事件** — SessionStart / InstructionsLoaded / Stop / PreToolUse / PostToolUseFailure
-- **3 个自动安装的 MCP** — context7 / sequential-thinking / chrome-devtools
+- **4 个 hook 事件** — SessionStart / InstructionsLoaded / Stop / PreToolUse
+- **2 个自动安装的 MCP + 1 个推荐插件** — context7 / sequential-thinking（plugin.json 内置）+ chrome-devtools-mcp（recommended，beta.8 解耦）
 - **优雅降级** — 依赖缺失时进入 fallback 模式并清晰告知
 
 ## 为什么用

package/agent-preamble/preamble.md

@@ -30,35 +30,58 @@
 - Do not say done/fixed/working without evidence
 - Tests first, goals first
 
+### 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.
+
 ---
 
 ## L2: Mandatory Tool Rules (enforced)
 
 ### 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).
+
+**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.
 
-**Fallback**: when context7 MCP is unavailable, use WebSearch with a version number, and annotate the output with
-"⚠️ context7 unavailable — documentation may not be current".
+**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 |
+|------|-----------|
 
-- Planning (≥5 thoughts)
-- Architecture design (≥8 thoughts)
-- Epic decomposition (≥10 thoughts)
-- Adversarial review (≥6 thoughts)
-- Complex bug root-cause analysis (≥5 thoughts)
+**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.
+
+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({
@@ -70,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.
 
 ---
 
@@ -210,5 +233,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 when a single `Write` call would approach the output budget
+
+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
+
+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
+
+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-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
 
@@ -55,66 +64,42 @@ Based on input type:
 
 ### Step 2: Round 1 — Breadth Scan
 
-For each of the 6 categories, use sequential-thinking **one by one**:
-
-```
-Round 1: Architecture layer
-  Think: Are these decisions right? Will we regret them later? Any implicit coupling?
-
-Round 2: Implementation layer
-  Think: Code quality? Error handling? Boundaries?
+Walk through the applicable categories below. **Skip categories that don't apply** (e.g. no UI → UX is N/A; no auth → Security only if that absence is itself material) and note them as `N/A: <reason>` in your report. Use sequential-thinking proportional to the surface each category presents — 1 thought for a trivial check, more for genuinely complex surfaces.
 
-Round 3: Testing layer
-  Think: Coverage? Over-mocked? Falsely green?
+- **Architecture**: Are decisions right? Will we regret them in 6 months? Any implicit coupling?
+- **Implementation**: Code quality? Error handling? Boundaries?
+- **Testing**: Coverage? Over-mocked? Falsely green?
+- **Security**: Injection? Privilege escalation? Leakage? Auth bypass?
+- **Maintainability**: Naming? Structure? Can the next maintainer understand?
+- **UX** (if UI / API contract is involved): Error messages clear? Loading? Accessibility?
 
-Round 4: Security layer
-  Think: Injection? Privilege escalation? Leakage? Auth bypass?
-
-Round 5: Maintainability layer
-  Think: Naming? Structure? Can the next maintainer understand?
-
-Round 6: UX layer (if UI / API contract is involved)
-  Think: Are error messages clear? Loading? Accessibility?
-```
-
-**Key point**: every round must **specifically point out what was examined** (file:line), not vague thinking.
+**Key point**: whenever you examine a category, cite what you looked at (file:line or design-doc section), not vague thinking.
 
 ### Step 3: Judgment
 
 ```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
 
-For areas where Round 1 said "looks fine", use sequential-thinking for another 6 rounds:
+For the "looks fine" areas from Round 1, use sequential-thinking proportional to the residual uncertainty. Three lenses to rotate through (stop when the drill honestly surfaces nothing new, don't force all three):
 
-```
-Rounds 1-2: Trust but verify
-  - Round 1 I said architecture is fine — really?
-  - Did I only look at the surface?
-  - What pitfalls have similar projects (e.g., open-source comparisons) hit?
-
-Rounds 3-4: Counterfactual thinking
-  - What happens if this system is stress-tested by an adversarial user?
-  - As code evolves in 6 months, will this decision become a bottleneck?
-  - What about 10x/100x load?
-
-Rounds 5-6: Boundaries and implicits
-  - What "default behaviors" are in the code but unstated?
-  - Has the dependency library had any famous CVEs?
-  - What does this design assume users won't do? What if they do?
-```
+- **Trust but verify**: did I only look at the surface? What pitfalls have similar open-source projects hit?
+- **Counterfactual**: under adversarial stress? In 6 months as the codebase evolves? At 10x / 100x load?
+- **Boundaries and implicits**: what "default behaviors" are unstated? Any CVE history in the dependency? What does the design assume users won't do?
 
 ### Step 5: Fallback If Still Zero Findings
 
@@ -123,7 +108,7 @@ If Round 2 still yields no findings, you must output a **proof report**:
 ```markdown
 ## Adversarial Review — No Sufficient Findings (Proof Report)
 
-In 2 rounds × 6 dimensions = 12 rounds of sequential-thinking, I checked:
+Across Round 1 (breadth) and Round 2 (depth), I checked the following applicable dimensions (N/A ones listed separately):
 
 ### Architecture (specifically examined)
 - AD-01~05 in design.md
@@ -178,17 +163,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)
@@ -188,3 +188,16 @@ Next:
   - Review the design (especially AD-01/02/03)
   - /curdx-flow:spec --phase=tasks — break down tasks
 ```
+
+## Design discipline (stop-condition, not length-target)
+
+Document only the genuinely novel architectural decisions. No target length. Stop when:
+
+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).
+
+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` 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
 
@@ -238,7 +252,7 @@ If the user agrees, suggest a set of tasks to append to tasks.md:
 
 ## Forbidden
 
-- ✗ Skipping any of the 7 categories (even if the project is not internationalized, at least state "I18n not applicable, reason: X")
+- ✗ Silently skipping a category — N/A is fine, but every category that doesn't apply must be named with a one-line reason (e.g. "I18n: N/A — single-locale MVP")
 - ✗ Listing scenarios only from imagination (must grep the code + compare tests)
 - ✗ Not using sequential-thinking
 - ✗ Gap list without priority ordering
@@ -246,10 +260,10 @@ If the user agrees, suggest a set of tasks to append to tasks.md:
 
 ## Quality Self-Check
 
-- [ ] All 7 categories covered?
+- [ ] Every applicable category examined, with N/A reasons recorded for the rest?
 - [ ] 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>