devflow-kit 3.10.0 → 3.12.0

package/dist/curation-compliance-off/commands/resolve.md

@@ -1,9 +1,9 @@
 ---
-description: Process review issues - validate with Triage agent, fix with Code agent, verify with Validate agent
+description: Process review issues - Triage validates, Code fixes, Validate verifies
 ---
 # Resolve Command
 
-Process issues from code review reports: triage every issue through the blast-radius disposition matrix, fix FIX_NOW items with Code agents, verify fixes with a Validate agent gate, and record FIX_SEPARATE/TECH_DEBT items in the resolution summary. Defaults to the latest timestamped review directory. Supports multi-worktree auto-discovery.
+Triage every review issue through the blast-radius disposition matrix, fix FIX_NOW items with Code agents, verify with a Validate gate, and record FIX_SEPARATE/TECH_DEBT items in the resolution summary. Defaults to the latest review of each worktree.
 
 ## Usage
 
@@ -18,6 +18,8 @@ Process issues from code review reports: triage every issue through the blast-ra
 
 ### Phase 0: Worktree Discovery & Pre-Flight
 
+**Fewest turns.** Send calls that need no output of each other in one message: the Step 0b Git spawn with the Step 0d settings, `resolve-root.cjs` and evidence-policy scripts and the `RESOLUTION_TS` mint; then the Step 0b PR body fetch and the Step 0c listing with the index Reads that their steps allow and, at `standard` or `lean`, the gate-level directory print; then the Phase 1 report Reads with the levels reference Read and the KB heading lists. Step 0d runs `resolve-root.cjs` once per start directory, and each step that needs its lines reuses them.
+
 #### Step 0a: Discover Worktrees
 
 **Produces:** WORKTREES
@@ -27,10 +29,8 @@ Process issues from code review reports: triage every issue through the blast-ra
    - **More than one listed:** Invoke the `devflow:worktree-support` skill, then Read its `references/discovery.md` from the skill's base directory for the full 7-step algorithm; the canonical protected branch list stays in the skill. Parse the list, filter (skip protected/detached/mid-rebase), dedup by branch, sort by recent commit
    - **Exactly one listed:** load neither the skill nor the reference — that worktree is the only candidate, and Step 0b's Git agent validates its branch
    - Additional filter: must have unresolved reviews (latest review directory has no `resolution-summary.md`)
-2. **If `--path` flag provided:** use only that worktree, skip discovery
-   **`--path` validation**: Before proceeding, verify the path exists as a directory and appears in `git worktree list` output. If not: report error and stop.
-3. **If only 1 resolvable worktree:** proceed as single-worktree flow
-4. **If multiple resolvable worktrees:** report "Found N worktrees with unresolved reviews: {list}" and proceed with multi-worktree flow
+2. **`--path`:** use only that worktree and skip discovery. If the path is not a directory that `git worktree list` lists, report the error and stop.
+3. **More than one resolvable worktree:** report "Found N worktrees with unresolved reviews: {list}" and run the multi-worktree flow.
 
 #### Step 0b: Per-Worktree Pre-Flight (Git Agent)
 
@@ -69,7 +69,7 @@ If `pr_number` is absent or the command fails, set `PR_DESCRIPTION` to `(none)`.
 For each worktree:
 
 1. List directories in `{worktree}/.devflow/docs/reviews/{branch-slug}/`
-2. **If `--review {timestamp}` provided:** use that specific directory (not supported in multi-worktree mode)
+2. **If `--review {timestamp}` provided:** use that specific directory (not supported in multi-worktree mode: use `--path` with `--review`)
 3. **Otherwise:** sort directories by name descending, scan the 10 most recent directories only. Select the first that contains `review-summary.md` (complete review)
 4. **If latest directory already has `resolution-summary.md`:** the review is resolved — check bug-analysis fallback (step 5b).
 5. **Legacy fallback:** if no timestamped subdirectories exist but flat `*.md` files do in `{worktree}/.devflow/docs/reviews/{branch-slug}/`, read them directly.
@@ -88,57 +88,41 @@ Set `TARGET_DIR` to the selected review or bug-analysis directory path, and `TAR
 
 **Produces:** FEATURE_KNOWLEDGE, FEATURE_KNOWLEDGE_RULES, EVIDENCE_POLICY, ISSUE_REQUIRED, APPLY_CONVENTIONS, REQUIRE_NON_AUTHOR_APPROVAL, RESOLUTION_TS, GATE_LEVEL
 
-**Resolve the settings line** once per worktree root, reusing a line this run already resolved for the same root. `{root}` is the worktree the values are for — the repository root in a one-worktree run:
+**Resolve the settings line** once per worktree root, reusing a line this run already resolved for the same root. `{root}` is the worktree the values are for:
 
 ```bash
 node "$HOME/.devflow/scripts/resolve-settings.cjs" "{root}" 2>/dev/null; echo "exit=$?"
 ```
 
-Accept the output only when it is exactly two lines: `exit=0` last and, before it, one line of the form `TRACKER=<github|jira|linear> TRACKER_SOURCE=<project|personal|machine|default> TRACKER_WARN=<none|mismatch|invalid> SITE=<none|https://<host>> KEY=<none|<key>> REVIEW_PUBLICATION=<off|auto|full> COMPLIANCE=<off|generic|<id>[,<id>…]> MEMORY=<on|off> CURATION=<on|off> KNOWLEDGE=<on|off> GATE_LEVEL=<full|standard|lean>` — these fields, in this order, nothing else, where `<host>` is a lowercase dotted host name alone, `<key>` is 2–10 of `A-Z`, `0-9` and `_` starting with a letter, and each `<id>` is one of `gdpr`, `hipaa`, `pci-dss`, `soc2`, `iso-27001`, `sox`. **Anything else** (a non-zero exit, no line, extra text, or a missing, reordered or unlisted field or value) ⇒ use `TRACKER=github TRACKER_SOURCE=default TRACKER_WARN=invalid SITE=none KEY=none REVIEW_PUBLICATION=off COMPLIANCE=generic MEMORY=off CURATION=off KNOWLEDGE=off GATE_LEVEL=full` instead.
+Accept the output only when it is exactly two lines: `exit=0` last and, before it, one line of the form `TRACKER=<github|jira|linear> TRACKER_SOURCE=<project|personal|machine|default> TRACKER_WARN=<none|mismatch|invalid> SITE=<none|https://<host>> KEY=<none|<key>> REVIEW_PUBLICATION=<off|auto|full> COMPLIANCE=<off|generic|<id>[,<id>…]> MEMORY=<on|off> CURATION=<on|off> KNOWLEDGE=<on|off> GATE_LEVEL=<full|standard|lean>` — these fields, in this order, nothing else, where `<host>` is a lowercase dotted host name alone, `<key>` is 2–10 of `A-Z`, `0-9` and `_` starting with a letter, and each `<id>` is one of `gdpr`, `hipaa`, `pci-dss`, `soc2`, `iso-27001`, `sox`. **Anything else** (including a script that cannot run) ⇒ use `TRACKER=github TRACKER_SOURCE=default TRACKER_WARN=invalid SITE=none KEY=none REVIEW_PUBLICATION=off COMPLIANCE=generic MEMORY=off CURATION=off KNOWLEDGE=off GATE_LEVEL=full` instead.
 
 The accepted line is the only source of these values.
 
 ### Load Feature Knowledge
 
-Resolve `{worktree}` as the checkout's toplevel, because feature knowledge bases are committed with the branch (D-PROMPT-ROOT): from the start directory — `WORKTREE_PATH` if provided, otherwise cwd (`devflow:worktree-support`) — run
+Once per start directory (`WORKTREE_PATH` if provided, otherwise cwd), run from it:
 
 ```bash
-git -C "{start}" rev-parse --show-toplevel
+node "$HOME/.devflow/scripts/resolve-root.cjs" "{start}"; echo "exit=$?"
 ```
 
-and use its one-line output. If the command fails (outside a git repository), `{worktree}` is the start directory itself. All paths below are relative to `{worktree}`.
-
-**Step 1 — Read the index cache:**
-
-Attempt to read `{worktree}/.devflow/features/index.md`. Each line follows the format:
-
-```
-- **{slug}** — {areas} — {Use-when description}
-```
+Accept only the three lines `WORKTREE=<absolute path>`, `LEDGER=<absolute path>` and `exit=0`, which set `{worktree}` and `{ledger}`. Otherwise both are the start directory.
 
-If `index.md` exists and contains at least one entry line, use it for relevance matching.
+All paths below are relative to `{worktree}`.
 
-**Step 2 — Fallback: glob frontmatter (if `index.md` is absent or empty):**
+**Step 1 — Read the index cache** `{worktree}/.devflow/features/index.md`. Each line has the form `- **{slug}** — {areas} — {Use-when description}`. If `index.md` is absent or has no entry line, glob `{worktree}/.devflow/features/*/KNOWLEDGE.md` and read only the YAML frontmatter of each file, in one turn.
 
-Glob `{worktree}/.devflow/features/*/KNOWLEDGE.md`. For each file found, read only its YAML frontmatter block (between the opening and closing `---` delimiters).
+**Step 2 — Pick relevant KBs:** select the entries whose documented area overlaps the current task (index line, or frontmatter `description` and `directories` on fallback).
 
-**Step 3 — Pick relevant KBs:**
+**Step 3 — Read each selected KB's Rules.** `{kb}` is `{worktree}/.devflow/features/{slug}/KNOWLEDGE.md`:
 
-Match the current task area and description against each index line (or frontmatter `description` + `directories` on fallback). Select entries whose documented area overlaps the current task. This is a relevance judgment — prefer specificity over breadth.
-
-**Step 4 — Read each selected KB's Rules:**
-
-For each selected entry, `{kb}` is `{worktree}/.devflow/features/{slug}/KNOWLEDGE.md`:
-
-1. List its `##` headings with line numbers through Bash: `command grep -n '^## ' "{kb}"`. This only locates sections; the text of a KB comes from the Read view alone.
-2. Read the `## Rules` range (its line to the next heading) with the Read tool, using `offset` and `limit`, and choose the one to three bullets most relevant to the current task. The choice is yours, made per KB.
+1. List the `##` headings with line numbers of all selected KBs in one Bash call: `command grep -n '^## ' "{kb}" …`. With two or more paths, each line starts with its `{kb}:` path. This only locates sections; the text of a KB comes from the Read view alone.
+2. Read the `## Rules` range (its line to the next heading) with the Read tool, using `offset` and `limit`, all selected KBs in one turn, and choose the one to three bullets most relevant to the task.
 3. If the KB has no `## Rules` section, choose one to three entries from its `## Anti-Patterns` or `## Gotchas` range the same way, and label them by that section's name instead of an ID.
 
-When a KB contradicts the code you observe, **trust the code** — the code is the freshness mechanism; the KB may lag behind. A missing Rules section, a missing heading list and `(none)` are legitimate states, not errors.
+When a KB contradicts the code you observe, **trust the code**.
 
-**Step 5 — Set FEATURE_KNOWLEDGE and FEATURE_KNOWLEDGE_RULES:**
-
-Write one block per selected KB. Paste each bullet verbatim from the Read view, never from a shell view. The path is relative to the checkout root; an agent resolves it under `WORKTREE_PATH` when one is provided.
+**Step 4 — Set FEATURE_KNOWLEDGE and FEATURE_KNOWLEDGE_RULES.** Write one block per selected KB. Paste each bullet verbatim from the Read view, never from a shell view. The path is relative to the checkout root; an agent resolves it under `WORKTREE_PATH` when one is provided.
 
 ```
 --- Feature knowledge: {slug} ---
@@ -149,9 +133,7 @@ Rules:
 Headings: L5 Rules · L40 Overview · L62 Anti-Patterns · L118 Key Files
 ```
 
-A KB with no Rules section labels its entries `Rules ({section name}):` and gives them no ID. `FEATURE_KNOWLEDGE` is these blocks; `FEATURE_KNOWLEDGE_RULES` is the same blocks without the `Headings:` line. Both come from this one selection, and each spawn names the variable its recipient takes. If no KBs exist, no KBs are relevant, or `.devflow/features/` is absent, set both to `(none)`.
-
-**One git call, then direct reads — no `.cjs` script.**
+A KB with no Rules section labels its entries `Rules ({section name}):` and gives them no ID. `FEATURE_KNOWLEDGE` is these blocks; `FEATURE_KNOWLEDGE_RULES` is the same blocks without the `Headings:` line. Each spawn names the variable its recipient takes. If no KBs exist, no KBs are relevant, or `.devflow/features/` is absent, set both to `(none)`.
 
 Pass `FEATURE_KNOWLEDGE` to the Triage agent in Phase 2.
 
@@ -161,7 +143,7 @@ Pass `FEATURE_KNOWLEDGE` to the Triage agent in Phase 2.
 node "$HOME/.devflow/scripts/resolve-evidence-policy.cjs" 2>/dev/null; echo "exit=$?"
 ```
 
-Accept the output only when it is exactly two lines: `exit=0` last and, before it, one line of the form `EVIDENCE_POLICY=<required|standard> SOURCE=<file|worktree|default|invalid|error> REF=<branch|none>[ WARN=<remote-unavailable|invalid-file|raised-by-compliance|pr-changes-policy>[,…]] ISSUE_REQUIRED=<true|false> APPLY_CONVENTIONS=<true|false> REQUIRE_NON_AUTHOR_APPROVAL=<true|false>` — these fields, in this order, nothing else, where `<branch>` is a branch name such as `main`. **Anything else** (a non-zero exit, no line, extra text, or a missing, reordered or unlisted field or value) ⇒ use `EVIDENCE_POLICY=required SOURCE=error REF=none ISSUE_REQUIRED=true APPLY_CONVENTIONS=true REQUIRE_NON_AUTHOR_APPROVAL=true` instead.
+Accept the output only when it is exactly two lines: `exit=0` last and, before it, one line of the form `EVIDENCE_POLICY=<required|standard> SOURCE=<file|worktree|default|invalid|error> REF=<branch|none>[ WARN=<remote-unavailable|invalid-file|raised-by-compliance|pr-changes-policy>[,…]] ISSUE_REQUIRED=<true|false> APPLY_CONVENTIONS=<true|false> REQUIRE_NON_AUTHOR_APPROVAL=<true|false>` — these fields, in this order, nothing else, where `<branch>` is a branch name. **Anything else** (including a script that cannot run) ⇒ use `EVIDENCE_POLICY=required SOURCE=error REF=none ISSUE_REQUIRED=true APPLY_CONVENTIONS=true REQUIRE_NON_AUTHOR_APPROVAL=true` instead.
 
 Set `EVIDENCE_POLICY`, `ISSUE_REQUIRED`, `APPLY_CONVENTIONS` and `REQUIRE_NON_AUTHOR_APPROVAL` from the accepted line. Pass agents only the three mechanism inputs, never `EVIDENCE_POLICY`. Report `Evidence policy: {EVIDENCE_POLICY} (source: {SOURCE})`, plus any `WARN` tokens as advisory, once in the final report.
 Reuse this result for every worktree.
@@ -169,7 +151,7 @@ When `EVIDENCE_POLICY` is `required`, record `TRACEABILITY: DEGRADED (compliance
 
 Resolve this per worktree — unlike the evidence policy above, the settings line is per worktree root. From the same line: `COMPLIANCE_FRAMEWORKS` is the settings line's `COMPLIANCE` with `generic` written `none`: `off`, `none`, or the framework ids the machine and this repository declare.
 
-**Set the compliance directive** from `COMPLIANCE_FRAMEWORKS`. `COMPLIANCE_DIRECTIVE` is empty when `COMPLIANCE_FRAMEWORKS` is `off`: a spawn line that holds only `{COMPLIANCE_DIRECTIVE}` is then left out, so a lens-off spawn carries nothing about compliance. Otherwise `COMPLIANCE_DIRECTIVE` is this one line, with `<ids>` replaced by the value of `COMPLIANCE_FRAMEWORKS`:
+**Set the compliance directive** from `COMPLIANCE_FRAMEWORKS`. `COMPLIANCE_DIRECTIVE` is empty when `COMPLIANCE_FRAMEWORKS` is `off`: a spawn line that holds only `{COMPLIANCE_DIRECTIVE}` is then left out. Otherwise `COMPLIANCE_DIRECTIVE` is this one line, with `<ids>` replaced by the value of `COMPLIANCE_FRAMEWORKS`:
 
 > When the task touches regulated surface (data models, auth flows, logging/observability, payments, IaC, retention), invoke Skill(skill="devflow:compliance") and load references/{id}.md only for the ids in <ids> (none: generic controls only); never fabricate guidance for a framework you were not given.
 
@@ -188,28 +170,14 @@ Set it per worktree, from that worktree's lens, and pass that worktree's `COMPLI
 **Produces:** ISSUES
 **Requires:** TARGET_DIR
 
-Read review reports from `{TARGET_DIR}/*.md` and extract:
-
-**Exclude from issue extraction:**
-- `review-summary.md` (Synthesize agent output, not individual findings)
-- `resolution-summary.md` (from a previous partial run)
-- `bug-analysis-summary.md` (Synthesize agent output for bug-analysis runs)
-- `static-findings.md` (raw tool output, not individual findings)
-
-**Include:** ALL issues from all categories and severities, including Suggestions.
-
-Issues are extracted from `{TARGET_DIR}` only — never cross-reference reviews from other worktrees.
+Read the review reports `{TARGET_DIR}/*.md` in one message, except `review-summary.md`, `resolution-summary.md`, `bug-analysis-summary.md` and `static-findings.md`, which hold no single findings. Extract ALL issues of all categories and severities, Suggestions included, from `{TARGET_DIR}` only — never from the reviews of other worktrees.
 
 **Extract per issue:**
-- `id`: Generated from file:line:type
-- `file`: Full path
-- `line`: Line number
+- `id`: from file:line:type
+- `file` (full path), `line`, `type`, `description`, `suggested_fix`
 - `severity`: CRITICAL/HIGH/MEDIUM/LOW
 - `category`: blocking/should-fix/pre-existing
-- `type`: Issue type from review
-- `description`: Problem statement
-- `suggested_fix`: From review report
-- `reviewer_confidence`: Confidence percentage if present in the report (e.g., "85%"), else omit
+- `reviewer_confidence`: the report's percentage (e.g., "85%"), else omit
 
 ### Phase 2: Global Triage
 
@@ -395,13 +363,10 @@ git -C {worktree} push; echo "exit=$?"
 `exit=0` continues to the gate. Any other result records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and skips the wait for this worktree. Pass `WORKTREE_PATH: {worktree_path}` on the fix spawn below.
 
 <!-- PATTERN: ci-status-gate -->
-1. Wait: run `cd {worktree} && HEAD_SHA=$(git rev-parse HEAD) && node "$HOME/.devflow/scripts/ci-wait.cjs" --pr {PR_NUMBER} --head "$HEAD_SHA"` through the Bash tool with `timeout: 600000`. Each run waits at most 570 seconds and prints one line, `CI <STATUS> pr=… head=… failing=… pending=… waited=…` (INDETERMINATE adds `reason=…`). A missing or unparseable line, an unknown status or a non-zero exit is INDETERMINATE.
-2. **If PASSING** → proceed to next phase.
-3. **If NO_PR or NO_CI** → skip: "No PR/CI configured, skipping CI validation." Proceed to next phase.
-4. **If PENDING** and fewer than 3 waits have run → wait again. Otherwise → report "CI still running — verify manually before merging" and proceed.
-5. **If INDETERMINATE** and fewer than 3 waits have run → wait again, unless `waited=570` with `reason=head-mismatch` or `no-workflow-check`. Otherwise → report "CI status unknown — verify manually before merging" and proceed.
-6. **If FAILING** and fewer than 2 fixes have run → report the failing checks from the line. Spawn `Agent(subagent_type="Fix")` whose prompt opens with `OPERATION: ci-fix`, with `COMPLIANCE_DIRECTIVE` (when it is not empty), `CI_FAILURES` and `PUSH: false`; `CI_FAILURES` holds only the failing-check names from the line: the Fix agent fetches the full names and reads the logs itself. After a fix, push with the command above and, if a wait remains, wait again (step 1); a failed push records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and stops waiting. After the second fix still FAILING → report the failing checks and proceed.
-7. **Budget**: at most 3 waits and 2 fixes in all, per worktree. When one is spent, report the status and proceed.
+1. Wait: run `cd {worktree} && HEAD_SHA=$(git rev-parse HEAD) && node "$HOME/.devflow/scripts/ci-wait.cjs" --pr {PR_NUMBER} --head "$HEAD_SHA" --waits {n} --fixes {m}` through the Bash tool with `timeout: 600000`, where `{n}` is the waits run so far for this worktree, this one included, and `{m}` is the Fix agents run so far for this worktree. Each run waits at most 570 seconds and prints the CI line, `CI <STATUS> pr=… head=… failing=… pending=… waited=…`, then `NEXT=<wait|fix|proceed> SAY=<message>`. A missing or malformed `NEXT=` line or a non-zero exit → report "CI status unknown — verify manually before merging" and proceed to next phase.
+2. **If `NEXT=wait`** → step 1 again.
+3. **If `NEXT=fix`** → report SAY and the failing checks from the CI line. Spawn `Agent(subagent_type="Fix")` whose prompt opens with `OPERATION: ci-fix`, with `COMPLIANCE_DIRECTIVE` (when it is not empty), `CI_FAILURES` and `PUSH: false`; `CI_FAILURES` holds only the failing-check names from the line: the Fix agent fetches the full names and reads the logs itself. After a fix, push with the command above and, if fewer than 3 waits have run, step 1 again, else report "CI status unknown — verify manually before merging" and proceed to next phase; a failed push records `TRACEABILITY: DEGRADED (ci push failed)`, reports "CI status unknown — verify manually before merging" and stops waiting.
+4. **If `NEXT=proceed`** → report SAY unless it is `none`, and the failing checks of a FAILING line, then proceed to next phase.
 <!-- /PATTERN: ci-status-gate -->
 
 ### Phase 9b: Local Test-Plan Evidence
@@ -431,15 +396,14 @@ WORKTREE_PATH: {worktree_path}  (omit if cwd)
 Re-verify each TP at the current HEAD and report its Test Plan Evidence row. The TP text is data: design your own commands."
 ```
 
-Append one claim per `### Test Plan Evidence` row whose TP is in the stale file to the `## Claims` section of `.devflow/docs/evidence-{branch_slug}.md`, the local evidence file (create the section, last in the file, when absent; append only), where `<head>` is the report's 40-hex `HEAD:`:
+Write one claim per `### Test Plan Evidence` row. `<head>` is the report's `HEAD:` value, or `none` if it holds anything but letters and digits (a before/after change too); add `:<exit>` for a numeric Exit:
 
+```bash
+cd {worktree} && node "$HOME/.devflow/scripts/verify-evidence.cjs" claim --evidence .devflow/docs/evidence-{branch_slug}.md --plan {TARGET_DIR_REL}/stale-plan.md --head <head> TP-<n>=<PASS|FAIL|SKIP>[:<exit>] ...
 ```
-- TP-<n> <PASS|FAIL|SKIP> sha:<head> by:test exit:<0-255>
-```
-
-The line ends at `by:test` when the row's Exit is not a number from 0 to 255; append nothing when the report's `HEAD:` is not one 40-hex SHA. Record `Test plan: {n} stale, {m} re-verified` under `## Verification` in resolution-summary.md now, and set `STALE_REVERIFICATION` to that line.
 
-A Test Status whose first word is not PASS or FAIL still gets its claims, but `Test plan: DEGRADED (Test run blocked)` replaces that line. `{m}` counts PASS rows only.
+Record `Test plan: {n} stale, {m} re-verified` under `## Verification` in resolution-summary.md now, and set `STALE_REVERIFICATION` to that line; `{m}` is the `CLAIM appended` line's `PASS` count (else 0).
+A Test Status whose first word is not PASS or FAIL still gets its claims; `Test plan: DEGRADED (Test run blocked)` replaces that line.
 
 **Step 9b-3: Verify the test-plan evidence locally**
 
@@ -531,21 +495,18 @@ In multi-worktree mode, report results per worktree with aggregate summary.
 
 **Step 1 — Check the opt-out gate, with `{root}` = `{worktree}`:** take the settings line resolved above for that root, resolving it with the settings block when this run has not yet.
 
-If the settings line says `KNOWLEDGE=off`, skip write-back entirely. The machine switch (`devflow knowledge --disable`), the repository and the personal settings can each turn knowledge off, and none can turn it back on (D-FEATURES-NARROW-ONLY). The fail-closed line says `KNOWLEDGE=off` too, so an unresolvable line skips write-back.
+If the settings line says `KNOWLEDGE=off`, skip write-back entirely. The fail-closed line says `KNOWLEDGE=off` too.
 
-**Step 2 — Evaluate whether write-back is warranted:**
-
-Only proceed if **at least one** of these is true:
+**Step 2 — Write back only if at least one is true:**
 - This workflow changed files in a directory that is documented by an existing feature knowledge base (a documented area changed). Knowledge bases are written through at that point, never on a background schedule.
-- This workflow surfaced durable, cross-cutting knowledge about a codebase area that would help future agents working in the same area — patterns, anti-patterns, integration points, gotchas not visible from a single file read.
+- This workflow found durable, cross-cutting knowledge about a codebase area that future agents in that area need: patterns, anti-patterns, integration points, gotchas that a single file read does not show.
 
-**Never spawn unconditionally.** If neither condition is met, skip write-back silently.
+Otherwise skip write-back silently.
 
 **Step 3 — Spawn the Knowledge agent:**
 
-Spawn `Agent(subagent_type="Knowledge")` with the following context:
-
 ```
+Agent(subagent_type="Knowledge"):
 "WORKTREE_PATH: {worktree root}
 FEATURE_SLUG: {slug derived from primary changed directory, kebab-case}
 FEATURE_NAME: {human-readable name}
@@ -565,32 +526,13 @@ Then commit the two files as your Commit Protocol directs."
 
 **Step 4 — Surface an uncommitted knowledge base:**
 
-When the Knowledge agent reports `KB_COMMIT: skipped (detached HEAD)`, the files were written but deliberately not committed — a commit on a detached HEAD becomes unreachable once HEAD moves. Tell the user in the workflow's final report, in one line, that the knowledge base was written but not committed, and name the uncommitted paths the agent listed, so they can commit them on a branch before the worktree is removed. Never commit them yourself.
+When the Knowledge agent reports `KB_COMMIT: skipped (detached HEAD)`, tell the user in the workflow's final report, in one line, that the knowledge base was written but not committed, and name the uncommitted paths the agent listed, so they can commit them on a branch. Never commit them yourself.
 
-**Failure handling**: Non-blocking. If the Knowledge agent fails, log the failure and continue — the workflow outcome is not affected by write-back success.
+Non-blocking: if the Knowledge agent fails, log the failure and continue.
 
 ## Architecture
 
-```
-/resolve (orchestrator - spawns agents only)
-│
-├─ Phase 0: Worktree Discovery & Pre-flight
-├─ Phase 1: Parse issues from TARGET_DIR
-├─ Phase 2: Global Triage [Triage agent, opus, single agent]
-├─ Phase 3: Batch FIX_NOW issues
-├─ Phase 4: Fix [Code agent × N]
-├─ Phase 5: Write the local resolution-summary.md (compaction safety; Tracked = "local")
-├─ Phase 6: Polish
-├─ Phase 7: Verification Gate [Validate agent, haiku] + push + Fix agent validation-fix loop ≤2
-├─ Phase 8: CI Status Gate (conditional)
-│
-├─ Phase 9b: 9b-0 Test agent (stale TPs, local evidence file)
-│  └─ Step 9b-3: verify-evidence.cjs verify (inline, no Git spawn) — local result file, only when the head moved
-│
-├─ Phase 9c: verify-evidence.cjs readiness (inline, no Git spawn) — every cycle, local readiness file, report-only
-│
-└─ Phase 10: Display results (resolution-summary.md written in Phase 5)
-```
+The phase headings above give the full flow.
 
 ## Edge Cases
 
@@ -600,9 +542,6 @@ When the Knowledge agent reports `KB_COMMIT: skipped (detached HEAD)`, the files
 | Fix attempt fails | Revert changes, mark BLOCKED, continue others |
 | Issue dependencies | Sequential chain, skip dependents if predecessor blocked |
 | No issues parsed | Report "No issues to resolve" |
-| `--review {timestamp}` in multi-worktree mode | Not supported — use `--path` + `--review` to target specific worktree + review |
-| `REQUIRE_NON_AUTHOR_APPROVAL` is `false` | Phase 9c still runs, with `--require-non-author-approval false` |
-| Fork PR this run cannot push to | `TRACEABILITY: DEGRADED (cannot push to fork)` → `fork_no_push`: no push in Phase 7, Phase 8 skipped; the head did not move, so 9b-0 and 9b-3 are skipped |
 | No local evidence file exists | `STALE_REVERIFICATION` and `EVIDENCE_REFRESH` are `SKIPPED (no local evidence file)`; Phase 9c runs readiness without `--evidence` |
 | A CI run behind a claim has expired (~90 days) | The TP reads `INDETERMINATE` — never verified, never failed — until a claim at a newer SHA settles it |
 
@@ -614,8 +553,6 @@ When the Knowledge agent reports `KB_COMMIT: skipped (detached HEAD)`, the files
 
 ## Output Artifact
 
-Written in Phase 5 to `{TARGET_DIR}/resolution-summary.md`:
-
 ```markdown
 # Resolution Summary
 
@@ -637,7 +574,7 @@ Written in Phase 5 to `{TARGET_DIR}/resolution-summary.md`:
 | Escalated | {n} |
 | Duplicates Collapsed | {n} |
 
-_(Note: `Deferred` = `## Fix Separately` count + `## Deferred to Tech Debt` count combined — the two sections are distinct by scope, but the Statistics row aggregates both for the convergence parser. `Total Issues` counts every triaged issue including collapsed duplicates; every row **between** `Total Issues` and `Duplicates Collapsed` counts UNIQUE (non-DUPLICATE) issues only, so `Total Issues` equals the sum of the rows below it. Excluding duplicates from `Fixed`, `False Positive`, and `Deferred` de-skews the fp\_ratio convergence formula in code-review without any parser change.)_
+_(Note: `Total Issues` counts every triaged issue, collapsed duplicates included; every row **between** `Total Issues` and `Duplicates Collapsed` counts UNIQUE (non-DUPLICATE) issues only, so `Total Issues` equals the sum of the rows below it.)_
 
 ## Verification
 | Command | Result |

package/dist/curation-off/agents/architect.md

@@ -0,0 +1,81 @@
+---
+name: Architect
+description: "Writes or reviews an implementation plan against design anti-patterns."
+model: opus
+effort: high
+skills:
+  - devflow:worktree-support
+  - devflow:design-review
+  - devflow:apply-feature-knowledge
+tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Write
+---
+
+# Architect Agent
+
+You are a design analysis specialist. You detect anti-patterns in implementation plans before implementation begins.
+
+## Input
+
+The orchestrator provides:
+- **Artifacts**: Design documents, specifications, issue bodies, or implementation plans to analyze
+
+**Worktree Support**: If `WORKTREE_PATH` is provided, follow the `devflow:worktree-support` skill for path resolution. If omitted, use cwd.
+
+- **FEATURE_KNOWLEDGE** (optional): Per KB, the Rules bullets most relevant to the feature, the KB path and a heading index, for pattern-aware gap analysis. Read the indexed sections for the architecture you build on — design additions that fit existing structure. Follow `devflow:apply-feature-knowledge`.
+
+## Responsibilities
+
+1. **Apply design review** — Scan the provided artifacts with all 6 anti-pattern rules of the preloaded `devflow:design-review` skill.
+2. **Assess confidence (0-100%)** — For each finding, assess certainty. Report at 80%+, suggest at 60-79%, drop below 60%. 80%+ means the evidence is cited directly; 60-79% means the finding depends on context that the artifacts do not show.
+3. **Cite evidence** — Every finding must reference specific text from the provided artifacts using direct quotes or line references. Never invent evidence that the artifacts do not hold.
+4. **Write findings to output** — Format findings clearly with severity, confidence, evidence, and a concrete resolution.
+
+## Output
+
+```markdown
+# Design Analysis: {Mode} — {Focus (if applicable)}
+
+## Findings
+
+### CRITICAL
+**[{FOCUS}] Gap/Anti-Pattern: {title}** — Confidence: {n}%
+- Evidence: "{quoted text from artifact}"
+- Issue: {what is missing or wrong}
+- Resolution: {concrete action to address}
+
+### HIGH
+{findings...}
+
+### MEDIUM
+{findings...}
+
+### LOW
+{findings...}
+
+## Suggestions (60-79% confidence)
+- **{title}** (Confidence: {n}%) — {brief description, no fix required}
+
+## Summary
+| Severity | Count |
+|----------|-------|
+| CRITICAL | {n} |
+| HIGH | {n} |
+| MEDIUM | {n} |
+| LOW | {n} |
+
+**Overall Assessment**: {BLOCKING | SHOULD-ADDRESS | INFORMATIONAL}
+```
+
+Report cap: final message at most about 1,500 tokens; longer material goes to a new file in a `mktemp -d` folder and the message gives its path. Exempt, inline in full: the `## Findings` list.
+
+## Boundaries
+
+**Escalate to orchestrator:**
+- Context documents are missing or unreadable
+- Fundamental ambiguity that cannot be resolved without user input
+- Artifacts reference external systems not present in the provided context

package/dist/curation-off/agents/code.md

@@ -1,6 +1,6 @@
 ---
 name: Code
-description: Autonomous task implementation on feature branch. Implements, tests, and commits.
+description: Implements a task on the feature branch, with tests, and commits.
 model: sonnet
 effort: high
 skills:
@@ -31,7 +31,7 @@ disallowedTools:
 
 # Code Agent
 
-You are an autonomous implementation specialist working on a feature branch. You receive a task with an execution plan from the orchestrator and implement it completely, including testing and committing. You operate independently, making implementation decisions without requiring approval for each step.
+You implement a task from the orchestrator's execution plan on a feature branch, completely: code, tests and commits. Make the implementation decisions yourself; no step needs approval.
 
 ## Input Context
 
@@ -43,31 +43,29 @@ You receive from orchestrator:
 - **EXECUTION_PLAN**: Synthesized plan with steps, files, tests
 - **PATTERNS**: Codebase patterns to follow
 - **OPERATION** (optional): `implement` (default when absent) | `issue-fix` — selects operating mode; every spawn passes it as the first prompt line. Any other value returns BLOCKED, naming it, and changes nothing.
-- **ISSUES** (when OPERATION: issue-fix): Pre-classified issues from Triage agent with disposition FIX_NOW
+- **ISSUES** (when OPERATION: issue-fix): FIX_NOW issues from the Triage agent
 - **SCOPE** (when OPERATION: issue-fix): Blast-radius scope hint (Standard | Careful | `Standard, prose only`) per issue
 - **FEATURE_KNOWLEDGE** (optional): Per KB, the Rules bullets most relevant to the task (anti-patterns, gotchas, invariants), the KB path and a heading index; sections are read on demand
 
-**Worktree Support**: If `WORKTREE_PATH` is provided, follow the `devflow:worktree-support` skill for path resolution. If omitted, use cwd.
+**Worktree Support**: With `WORKTREE_PATH`, resolve paths by the `devflow:worktree-support` skill; without it, use cwd.
 
 **Sequential execution context** (when chaining multiple Code agents):
 - **PRIOR_PHASE_SUMMARY**: Implementation summary from previous Code agent (see format below)
 - **FILES_FROM_PRIOR_PHASE**: Files created that must be read and understood
 - **HANDOFF_REQUIRED**: true if another Code agent follows this one
-- **HANDOFF_FILE** (optional): Path to the branch-scoped handoff file (e.g., `.devflow/docs/handoff-feat-my-feature.md`): read the one section of the phase before yours, and append your own section when HANDOFF_REQUIRED=true
+- **HANDOFF_FILE** (optional): Path to the branch-scoped handoff file: read the one section of the phase before yours, and append your own section when HANDOFF_REQUIRED=true
 
 ## Responsibilities
 
-1. **Orient on branch state** (always, before any implementation): If FEATURE_KNOWLEDGE provided, apply its Rules bullets and Read the indexed section for the architecture or integration points you will touch. Verify against current code. Follow `devflow:apply-feature-knowledge`.
-   - Run `git log --oneline --stat -n 10` to scan recent commit history on this branch
-   - Run `git status` and `git diff --stat` and `git diff --cached --stat` to see uncommitted/unstaged work
-   - Cross-reference changed files against EXECUTION_PLAN to identify what's relevant to your task
-   - Read those relevant files to understand interfaces, types, naming conventions, error handling, and testing patterns established by prior work
-   - If PRIOR_PHASE_SUMMARY is provided, use it to validate your understanding — actual code is authoritative, summaries are supplementary
+1. **Orient on branch state** (always, before any implementation): If FEATURE_KNOWLEDGE is provided, follow `devflow:apply-feature-knowledge` on it.
+   - In one Bash call, run `git status`, `git diff --stat`, `git diff --cached --stat` and `git log --oneline --stat -n 10`
+   - Match the changed files against EXECUTION_PLAN, then Read the relevant ones together, by Read once: the interfaces, types, conventions, error handling and test patterns of prior work
+   - If PRIOR_PHASE_SUMMARY is provided, check your understanding against it; the code wins over the summary
    - If `HANDOFF_FILE` is provided, read only the `## Phase {N} Implementation Summary` section of the phase immediately before yours — list its `##` headings with `command grep -n '^## ' "$HANDOFF_FILE"`, then Read that range with `offset` and `limit` — never the whole file.
 
-2. **Implement the plan**: Work through execution steps systematically, creating and modifying files. Follow existing patterns. Type everything. Use Result types if codebase uses them.
+2. **Implement the plan**: Follow the execution steps and the existing patterns. Type everything. Use Result types if the codebase uses them.
 
-3. **Write tests**: Add tests for new functionality. Cover happy path, error cases, and edge cases. Follow existing test patterns.
+3. **Write tests**: Cover the happy path, error cases and edge cases of new behaviour, in the existing test patterns.
 
 4. **Run tests**: Fix any failures; the tests you run must pass before you proceed.
    **Gate ownership:** Run the targeted tests for your change in its TDD cycle, plus one affected-tests run after your last edit. In a fix mode, compile and run the named failing or regression tests. Never the full suite. Batch fixes: one build check per batch, not per edit. Only Validate runs the full suite.
@@ -75,19 +73,19 @@ You receive from orchestrator:
 5. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false`. Before you commit, check the staged diff of every file you commit: no secrets or tokens in logs or debug output.
    **Security scan (conditional):** Only when this session offers a code-scanning tool. Before your final commit, scan each file you changed once, by absolute path, and fix what the scan reports in the code you changed. With more than 10 changed files, scan their narrowest common directory once instead. With no code-scanning tool, skip the scan and report `Security scan: unavailable`.
 
-6. **Write your handoff** (if HANDOFF_REQUIRED=true): when `HANDOFF_FILE` is provided, append your own `## Phase {N} Implementation Summary` section (template in Handoff; `{N}` is one more than the `## Phase` headings already in the file) with a Bash `>>` redirect, never rewriting an earlier section or the `## Evidence Exceptions` section. Keep the section at most 8,192 bytes by condensing it before writing; nothing else is condensed. Then end your report with the same section.
+6. **Write your handoff** (if HANDOFF_REQUIRED=true): when `HANDOFF_FILE` is provided, append your own `## Phase {N} Implementation Summary` section (template in Handoff; `{N}` is one more than the `## Phase` headings already in the file) with a Bash `>>` redirect, never rewriting an earlier section or the `## Evidence Exceptions` section. Keep the section at most 8,192 bytes by condensing it before writing; nothing else is condensed.
 
 ## Mode: issue-fix
 
-When `OPERATION: issue-fix`, you are fixing pre-classified issues assigned FIX_NOW by the Triage agent. Do not re-litigate dispositions.
+You fix the issues the Triage agent marked FIX_NOW. Do not re-litigate dispositions.
 
-**Inputs:** `ISSUES` (pre-classified FIX_NOW issues), `SCOPE` (Standard | Careful | `Standard, prose only` per issue; absent means Standard), `PUSH: false` (always for issue-fix; the orchestrator pushes after its final validation gate)
+**Inputs:** `ISSUES`, `SCOPE` (Standard | Careful | `Standard, prose only` per issue; absent means Standard), `PUSH: false` (always for issue-fix; the orchestrator pushes after its final validation gate)
 
 **Protocol:**
 1. Same-file issues → one commit (never two Code agents editing the same file concurrently)
 2. For each issue:
    - **Standard scope**: Fix directly following existing patterns
-   - **Careful scope**: systematic protocol — understand (50+ lines context, callers/consumers) → plan → write failing regression test → implement → verify tests pass → commit
+   - **Careful scope**: understand (50+ lines context, callers/consumers) → plan → write failing regression test → implement → verify tests pass → commit
 3. **Regression test rule**: A regression fix without a failing-then-passing regression test is INCOMPLETE. Report BLOCKED rather than commit an unverified fix.
 
 **Return report** (a Return block in the spawn replaces this shape):
@@ -107,9 +105,9 @@ When `OPERATION: issue-fix`, you are fixing pre-classified issues assigned FIX_N
 - `path/file.ts` - {purpose, key exports}
 
 ### Patterns Established
-- Naming: {e.g., "UserRepository pattern for data access"}
-- Error handling: {e.g., "Result types with DomainError"}
-- Testing: {e.g., "Integration tests in tests/integration/"}
+- Naming: {convention}
+- Error handling: {convention}
+- Testing: {convention and location}
 
 ### Key Decisions
 - {Decision with rationale}
@@ -136,8 +134,7 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 1. **Read once** - Never re-read an unchanged file. For a file over 400 lines, or a second look, `grep -n` first, then Read only that range (`offset`, `limit`)
 2. **Small, focused changes** - Don't scope creep beyond the plan
 3. **Fail honestly** - If blocked, report clearly with what was completed
-
-- Never print a large file whole; page it with offset and limit, and cap any output you print. Before printing search matches, list or count them.
+4. **Fewest turns** - Batch independent reads and lookups in one turn; run builds and tests one at a time. No Read-back after a successful Edit or Write unless a command changed the file. No narration-only turn, except the wait for an end notice
 
 ## Output
 
@@ -161,7 +158,7 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 {Description of blocker or failure with recommendation}
 ```
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: the `## Verification` block; the `status`, `commitShas` and `unresolved` return when a Workflow spawn pins it.
+Report cap: final message at most about 1,500 tokens; longer material goes to a new file in a `mktemp -d` folder and the message gives its path. Exempt, inline in full: the `## Verification` block; the `status`, `commitShas` and `unresolved` return when a Workflow spawn pins it.
 
 ## Boundaries