feat!: close 7 feature-toggle gaps (user-scope-only, clean-break major version)

.devflow/decisions/decisions-ledger.jsonl

@@ -29,3 +29,4 @@
 {"id":"obs_3vt99r","type":"pitfall","pattern":"Assuming a workflow capability does not exist without checking existing agents — the Evaluator already implements intent-vs-implementation comparison","evidence":["are you sure devflow doesn't already do this? isn't it exactly what the evaluator is doing?","You're right to push back — the Evaluator is doing intent-vs-implementation comparison. Let me be precise about what it already does vs what's actually new.","No production tool compares plan/spec intent against implementation. (Confirmed across all 3 research tracks.) — this claim was made before checking devflow's own Evaluator agent"],"details":"area: bug-analysis workflow design, research phase; issue: research concluded no tool performs plan-intent vs implementation comparison, then proceeded to design this as a new capability — without checking whether devflow's own Evaluator agent already does this; impact: wasted design effort and potential duplication; the Evaluator already receives ORIGINAL_REQUEST, EXECUTION_PLAN, FILES_CHANGED, ACCEPTANCE_CRITERIA and performs goal-backward verification; resolution: before designing any new capability that sounds like it overlaps with existing agents (Evaluator, Scrutinizer, Reviewer), explicitly check the existing agent roster and their input contracts first","count":1,"confidence":0.9,"quality_ok":true,"status":"created","created":"2026-05-23T21:17:01.106Z","last_seen":"2026-05-23T21:17:01.106Z","artifact_path":"/Users/dean/Sandbox/devflow/.devflow/decisions/pitfalls.md#PF-005","anchor_id":"PF-005","decisions_status":"Retired"}
 {"id":"obs_pfyb8b","type":"decision","pattern":"Dynamic workflow plugin ships as pure-instruction command recipes — markdown that teaches the model to author and run a dynamic workflow at runtime, with ZERO authored orchestration code (no parser, scheduler, topo-sort, or formula), now or ever","details":"context: the devflow-dynamic plugin (tickets->plan->build delivery pipeline) needed a build/runtime architecture; an L0 ticket-DAG parser (Kahn topological sort run via Bash and passed to the workflow as args) had been drafted into the design doc as the one programmatic dependency; decision: ship the dynamic commands as pure-instruction command recipes — markdown that instructs the main model how to author and run a Claude Code dynamic workflow at runtime — carrying ZERO deterministic code that devflow authors (no parser, scheduler, topo-sort, FP-ratio/cycle formulas); every judgment (which tickets are independent, wave ordering, parallel vs serial, review-cycle counts) is LLM reasoning at runtime, done by agents that read the GitHub issues and their Depends-on relationships with gh; the recipes are thin orchestrators over devflows ALREADY-installed agents (agentType resolves the real agent identity/skills/per-agent model tier, confirmed by spike F5), so no agent prompts are inlined; rationale: a pure-instruction recipe survives the moving dynamic-workflow API, adapts to arbitrary input, and distributes through the command channel devflow already ships, while any authored parser/formula becomes a brittle deterministic dependency the user categorically rejected (not now, not ever); this extends the LLM-vs-plumbing principle from artifact CONTENT to workflow ORCHESTRATION","anchor_id":"ADR-019","decisions_status":"Accepted","date":"2026-06-12"}
 {"id":"obs_10svdf","type":"decision","pattern":"In the dynamic-build pipeline, every Coder code mutation runs a post-code quality pipeline in fixed order Validate->Simplify->Scrutinize, the Evaluator runs ONLY when there is an implementation plan (not after fixes), and the Resolver is split — a Coder writes fixes while adversarial verification strips false positives before any fix is attempted","details":"context: defining the agent topology for the /devflow:dynamic-build recipe (a fusion of /implement + /code-review + /resolve); decision: (1) the Simplifier->Scrutinizer->Evaluator order is a load-bearing, non-negotiable invariant; (2) every Coder mutation (initial implement, resolve-fix, alignment-fix, qa-fix) runs a post-code pipeline of Validate->Simplify->Scrutinize, but the Evaluator runs ONLY when there is an implementation plan to verify against — it is skipped after plain fixes; the Tester is part of this gate; (3) the Resolver is split into two halves — its validate-the-issue-is-real half becomes an adversarial verification pass that strips false positives BEFORE any fix, and its write-the-fix half is handled by a Coder (a Coder loads far more relevant context than a Resolver); rationale: the Evaluators job is to confirm the PLAN was implemented properly, so it is meaningless without a plan and wasteful on every fix; a Coder produces better fixes than a Resolver because of the context it loads; gating every fix behind adversarial false-positive verification prevents wasting Coder effort on non-real findings; preserving the Simplify/Scrutinize order on every code mutation keeps the same quality dynamic the static /implement pipeline enforces","anchor_id":"ADR-020","decisions_status":"Accepted","date":"2026-06-12"}
+{"id":"obs_cutline1","type":"pitfall","pattern":"Shell cut is line-oriented — using cut to extract a delimited field from a multi-line value silently corrupts the extraction, dropping all lines after the first","details":"area: scripts/hooks/dream-capture, shell string parsing with cut; issue: cut -d<delim> -f<N> operates per-line — when the delimiter appears only on the first line of a multi-line string (e.g., SOH joining CWD and a multi-line assistant message), cut extracts the field correctly from line 1 but emits every subsequent line verbatim, corrupting the extracted value; in dream-capture this meant CWD became a multi-line string containing the assistant message body, which failed the directory check silently; impact: systemic — working memory broken machine-wide for ~8 days across all projects; assistant turns silently dropped on every multi-line response; only single-line responses slipped through, making the failure appear intermittent; resolution: replace cut with bash parameter expansion (${PAYLOAD%%$SOH*}) which operates on the whole string regardless of newlines; lesson: never use cut to split fields that may contain newlines — cut is a line-oriented tool and will silently produce wrong results on multi-line values","anchor_id":"PF-013","decisions_status":"Active"}

.devflow/decisions/pitfalls.md

@@ -1,4 +1,4 @@
-<!-- TL;DR: 9 pitfalls. Key: PF-008, PF-009, PF-010, PF-011, PF-012 -->
+<!-- TL;DR: 10 pitfalls. Key: PF-009, PF-010, PF-011, PF-012, PF-013 -->
 # Known Pitfalls
 
 Area-specific gotchas, fragile areas, and past bugs.
@@ -83,3 +83,12 @@ Area-specific gotchas, fragile areas, and past bugs.
 - **Resolution**: drop Guard B, and diagnose hook flakiness by reproducing through the real run-hook preamble path with a truth table that varies only the trailing ? to isolate the actual cause
 - **Status**: Active
 - **Source**: self-learning:obs_preambleq1
+
+## PF-013: Shell cut is line-oriented — using cut to extract a delimited field from a multi-line value silently corrupts the extraction, dropping all lines after the first
+
+- **Area**: scripts/hooks/dream-capture, shell string parsing with cut
+- **Issue**: cut -d<delim> -f<N> operates per-line — when the delimiter appears only on the first line of a multi-line string (e.g., SOH joining CWD and a multi-line assistant message), cut extracts the field correctly from line 1 but emits every subsequent line verbatim, corrupting the extracted value
+- **Impact**: systemic — working memory broken machine-wide for ~8 days across all projects
+- **Resolution**: replace cut with bash parameter expansion (${PAYLOAD%%$SOH*}) which operates on the whole string regardless of newlines
+- **Status**: Active
+- **Source**: self-learning:obs_cutline1