fix(planning,playbooks,session-flow): bound /interview to decisions and scope verification to what ships

plugins/planning/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "planning",
-  "version": "0.27.1",
+  "version": "0.27.2",
   "userConfig": {
     "use_ask_user_question": {
       "type": "boolean",

plugins/planning/CHANGELOG.md

@@ -3,6 +3,34 @@
 All notable changes to the `planning` plugin are documented here. Format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
 
+## [0.27.2]
+
+### Fixed
+
+- **`/planning:interview` could be used as the execution container for bulk application
+  work, and nothing in the skill said not to.** Observed in a real multi-week effort: a
+  doc-alignment task ("apply the docs across the corpus, one agent per document") entered
+  the interview and came out as a 90-row decision ledger, because every per-document
+  application step was admissible as a decision row and each row then earned its own
+  adoption ceremony. The skill had no boundary to hit — its only anti-marathon signal was
+  the ballooning frontier, whose remedy is routing to `/planning:wayfind`, which is the
+  wrong remedy here: the decisions were not foggy, they were already settled and merely
+  numerous. `skills/interview/SKILL.md` now states the boundary as a sibling to that
+  paragraph, where the discrimination between the two signals is visible: for a corpus
+  application the interview's output is the small set of genuinely contested decisions
+  **plus an execution contract** — one line in the session's output artifact, routed by
+  domain like every other output (the Brief's `### Acceptance criteria` in an engineering
+  session, the shared-understanding summary in a general one) naming the per-unit
+  close-out loop (one source unit at a time: apply, verify, close) and what *closed*
+  means for a unit — and never one decision row per source unit. Naming the destination
+  is load-bearing: the loop had nowhere to live, which is why the decision ledger
+  absorbed it. An eval exercises the collapse. The tripwire is a count the reader can actually run —
+  candidate question count scaling with the number of source units rather than with the
+  number of genuine forks is execution masquerading as decisions, and it collapses into
+  the contract rather than routing to wayfind. `skills/interview/context/gotchas.md`
+  records the pattern under Scope and points at the SKILL.md section rather than
+  restating the rule.
+
 ## [0.27.1]
 
 ### Changed

plugins/planning/skills/interview/SKILL.md

@@ -79,6 +79,8 @@ When the effort is too big to hold at once AND still too foggy to phrase as shar
 
 **Question budget scales with what's already settled.** Upstream artifacts — research findings, exploration output, a PRD, a design resolution — count as settled prerequisites: an interview invoked after them starts with a smaller tree and fewer rounds; never re-ask what an artifact already answers. There is no numeric question cap, but a frontier that keeps *ballooning* (each round opens more branches than it closes) is the wayfind signal above, not a license for a marathon session — surface the routing recommendation instead of grinding on.
 
+**Bulk application work is not a decision set — the interview settles it once, it never executes it.** When the task applies a settled shape across a corpus (every document in a set, every file matching a pattern, every page of a spec), the interview's output is TWO things and no more: the small set of genuinely contested decisions, driven to decisions the normal way, plus an **execution contract** — one line in the session's output artifact, routed by domain like every other output: the Brief's `### Acceptance criteria` in an engineering session, the shared-understanding summary in a general one — naming the per-unit close-out loop (one source unit at a time: apply, verify, close) and what *closed* means for a unit. NEVER enumerate the per-unit applications as decision rows: an interview that becomes the execution container turns every application step into a decision needing its own adoption ceremony, and the corpus's size becomes the session's length. **Tripwire — count the candidates against the corpus:** when the candidate question count scales with the number of source units rather than with the number of genuine forks, that is execution masquerading as decisions — collapse the per-unit rows into the loop, keep only the forks, and say what you collapsed. Distinct from the ballooning frontier above and remedied differently: ballooning routes to `/planning:wayfind`, unit-scaling collapses into the execution contract and hands off to execution.
+
 Tone is collaborative but opinionated. You are not interrogating; you are helping the user think out loud by PROPOSING answers grounded in codebase evidence. When the user gives a definitive answer, lock it. When they hesitate, slow down and offer two or three concrete shapes the answer could take. Every option set names exactly ONE recommended option marked **(RECOMMENDED)** with a one-line basis. The surface follows the "Question surface" rule above: inline prose rounds by default, `AskUserQuestion` only when the user opted in and the round qualifies.
 
 ### Relentless mode (`me`)

plugins/planning/skills/interview/context/gotchas.md

@@ -27,3 +27,5 @@ Failure patterns from real sessions. Loaded on demand from `/interview` SKILL.md
 ## Scope
 
 - **Interviewing mechanical work** — typo, lint-only, whitespace skips the interview per skill policy. Behavior-changing work is interview-first.
+
+- **Interview used as the execution container for bulk work** — a corpus application yields one small contested-decision set plus an execution contract naming the per-unit loop, never one decision row per source unit with its own adoption ceremony. The tell is the count: candidate questions scaling with the number of source units instead of with genuine forks. Collapse (SKILL.md "Bulk application work is not a decision set").

plugins/planning/skills/interview/evals/evals.json

@@ -131,6 +131,20 @@
         "On a doc-fetch failure the skill degrades to the durable distinction with a visible note and does not halt the interview or guess a model name",
         "The recommendation is framed as advisory (applied via /model, /advisor, effort setting), not as a read of the user's current config"
       ]
+    },
+    {
+      "id": 11,
+      "name": "bulk-application-collapses-to-execution-contract",
+      "prompt": "/planning:interview me — we've settled on the new frontmatter shape for our docs site. Now I want to apply it across the 40 markdown pages under docs/. Interview me so we lock this down properly.",
+      "expected_output": "The interview recognizes a corpus application of an already-settled shape: its output is TWO things only — the small set of genuinely contested decisions (e.g. how to treat pages that deviate from the template, whether to batch the PRs), plus an execution contract, one line in the session's output artifact (the Brief's `### Acceptance criteria` here, since this is an engineering session) naming the per-unit close-out loop (one page at a time: apply, verify, close) and what closed means for a page. It NEVER enumerates the 40 pages as decision rows. If candidate questions start scaling with the page count rather than with genuine forks, the tripwire fires: the per-unit rows collapse into the loop, only the forks remain, and the collapse is stated. The signal is distinguished from a ballooning frontier — this does not route to /planning:wayfind, because the decisions are settled and merely numerous.",
+      "files": [],
+      "expectations": [
+        "Output is exactly two things for the corpus work: a small contested-decision set plus an execution contract naming the per-unit close-out loop — never one decision row per page",
+        "The execution contract lands as one line in the session's output artifact routed by domain (the Brief's `### Acceptance criteria` for this engineering task)",
+        "The contract names the per-unit loop (apply, verify, close, one unit at a time) and what closed means for a unit",
+        "Candidate question count scaling with the number of pages rather than genuine forks is treated as the tripwire: per-unit rows collapse into the loop and the collapse is stated",
+        "Does not route to /planning:wayfind for this signal — the unit-scaling remedy is the collapse into the execution contract, distinct from the ballooning-frontier remedy"
+      ]
     }
   ]
 }

plugins/playbooks/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "playbooks",
-  "version": "0.6.7",
+  "version": "0.6.8",
   "description": "Doctrine and knowledge playbooks as on-demand skills, plus a maintainer-facing update skill. boris — Boris Cherny's Claude Code workflow tips (howborisusesclaudecode.com); skill-authoring — Anthropic's internal skill-authoring playbook; fable-5 — Claude Fable 5's operating doctrine (self-authored, no upstream). The boris and skill-authoring packs vendor a verbatim upstream baseline; /playbooks:update drift-checks and syncs those baselines centrally (maintainers).",
   "author": {
     "name": "Melodic Software",

plugins/playbooks/CHANGELOG.md

@@ -4,6 +4,31 @@ All notable changes to the `playbooks` plugin are recorded here. The `version` i
 `.claude-plugin/plugin.json` is the delivery vehicle — a consumer receives a change
 only after that version increases.
 
+## [0.6.8]
+
+### Fixed
+
+- **`fable-5`'s fresh-context verification trigger had no scope, so it fired on the
+  bookkeeping about the work as readily as on the work.**
+  `skills/fable-5/context/orchestration.md` §"Fresh-context verification" triggers on "any
+  multi-file edit batch" and "before declaring any multi-part task complete" — conditions a
+  batch of ledger, checklist, and status-row edits satisfies as fully as a batch of source
+  files. Observed in a real campaign: verifiers were spawned to verify process records, and
+  then to verify the records those verifications produced, so the process fed itself and the
+  ceremony outgrew the work. The section now carries a scope qualifier on the trigger, where
+  the misfire happens: the trigger ranges over what a consumer receives — code, docs someone
+  reads, config — and memory-tier bookkeeping and process records take the in-context floor
+  and stop there, however many files a batch of them touched, because a record's blast radius
+  is the session that reads it. The recursion stop is stated explicitly rather than left to
+  follow: **never spawn a verifier to verify a record OF a verification** — the record is
+  downstream of an already-verified artifact, so verifying it re-verifies nothing and each
+  pass produces another record to verify.
+
+  `context/verification.md` is deliberately untouched: its "Adversarial self-review" section
+  already scales depth with blast radius and already points at this section as the owner of
+  the gate and its exception, so the pointer is the wiring and prose there would be a second
+  copy of one rule.
+
 ## [0.6.7]
 
 ### Added

plugins/playbooks/skills/fable-5/context/orchestration.md

@@ -71,6 +71,8 @@ The independence gradient runs further than fresh context alone: self-review (fl
 
 **TRIGGER — a fresh-context verifier is required in addition to the floor:** after any multi-file edit batch, and before declaring any multi-part task complete. Each trigger is exempt only when *every* batch it covers is mechanical — a transform with no judgment call, so a second author given the same rule would produce the same edit — *and* behavior-preserving (the planning chapter's distinction) *and* narrow in blast radius; a hand-designed refactor fails the first condition however well it preserves behavior. All three are required, because only a judgment-free transform carries none of the producer-blind-spot risk an independent reader exists to catch — so the post-batch trigger weighs that one batch, while the completion trigger weighs every batch in the task and one behavior-changing batch anywhere in it keeps the gate, however mechanical the last batch was. A subjective verdict, or a wide blast radius, defeats the exemption inside a trigger that already fired; neither creates a trigger on its own, so a subjective single-file, single-part change still takes only the floor. Outside these two triggers, the in-context floor suffices.
 
+**Scope — ceremony scales with blast radius, and the trigger ranges over the shipped artifact, never the record of the work.** What a consumer receives — code, docs someone reads, config — carries the full independent-verifier gate above. Memory-tier bookkeeping and process records — ledgers, checklists, status rows, adoption logs, sweep instrumentation — take the in-context floor and stop there, however many files a batch of them touched: a record's blast radius is the session that reads it, and spending an independent verifier on one buys nothing the artifact's own verification did not already buy. **Never spawn a verifier to verify a record OF a verification** — the record is downstream of an already-verified artifact, so verifying it re-verifies nothing and each pass produces another record to verify; that is the loop that feeds itself. Re-verify the artifact, or verify nothing.
+
 Hand the verifier two things only: the artifact, and binary criteria checkable against the artifact by reading, searching, or counting — a holistic quality question invites a rubber stamp; a criterion with a yes/no answer does not. Withhold your rationale for the changes: a verifier that reads your justification inherits your blind spots and audits your story instead of your artifact.
 
 > Weak: "Review my changes and confirm they look good."

plugins/session-flow/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "session-flow",
-  "version": "0.17.21",
+  "version": "0.17.22",
   "description": "Session-lifecycle toolkit of thirteen skills: workflow (navigate a staged dev workflow and suggest the next stage), handoff (write a save-point and resume prompt for /clear-and-resume), continue-in-background (delegate the task to a fresh background agent that continues it now — same save-point engine as handoff, delivered by launching a detached claude --bg session seeded with the resume prompt; launches only on explicit user request), keep-going (recover and continue after any interruption OR when live off-thread work looks stalled — inventory off-thread work, inspect its real output, act only on evidence, then continue; after a usage limit lifts it continues rather than summarizing-and-stalling), find-handoff (recover a lost handoff after /clear — when the resume prompt was written but never copied — via a read-only detection ladder: known-location glob of the handoffs dir, then a bounded, recency-ranked transcript scan for the handoff directive and dashed-rail markers, then a confirm-before-resume gate; surfaces only the resume prompt + metadata, never raw transcript content), clean-stop (get to a durable, linked stopping point before the machine may go away — sweep every repo/worktree for uncommitted, unpushed, or PR-less work, push it durable, put breadcrumbs in PR/issue bodies, then give a free-and-clear verdict), retro (structured end-of-session retrospective with transcript metrics and learning codification), running-retro (in-flight retrospective checkpoints that spawn a subagent to analyze the transcript so far and append classified findings to a cumulative running ledger — capture and route only, the live counterpart to retro; also owns a detached-observer substrate that can watch a session out-of-band and run the checkpoint autonomously after the session ends), orient (read-only session orientation — synthesize where we stand, what we are doing, and why, from durable + off-thread state the built-in /recap never sees: ledgers, handoffs, workflow checklists, running-retro ledgers, open PRs and work-items, and git), orchestrate (arm a session or worker with proactive-orchestration imperatives), reanchor (verify a session's working assumptions are still true against live reality — referenced PRs/issues/branches, base-branch drift, renamed/version-drifted surfaces, stale memory-tier files — before building on them), reconcile (retire finished off-thread work and reconcile this session's task ledger with reality — the prune-and-reconcile counterpart to keep-going's resume: inventory the work this session spawned, inspect its real state, retire the finished and close proven-done tasks, auto-settling the finished and gating any kill of still-running work; sibling sessions in the project are reported read-only), and setup (check-centric verification of the observer's runtime prerequisites and configuration).",
   "author": {
     "name": "Melodic Software",

plugins/session-flow/CHANGELOG.md

@@ -1,5 +1,26 @@
 # Changelog — session-flow plugin
 
+## [0.17.22]
+
+### Fixed
+
+- **`/session-flow:orchestrate`'s FRESH-CONTEXT VERIFY imperative told a session to hand
+  every edit batch to a separate verifier without saying which edits count, so it licensed
+  verifying the bookkeeping about the work.** A campaign's ledgers, checklists, and status
+  rows are edit batches too; applied to them the imperative spawns verifiers on process
+  records, and on the records those verifications produce. Imperative 3 in
+  `skills/orchestrate/SKILL.md` now scopes itself to what ships: a process record about the
+  work (ledger, checklist, status log) is not the work and stays at self-check however many
+  of them a batch touched, and a record OF a verification is never itself verified. An eval
+  exercises the discrimination.
+
+  The clause is terse and self-contained on purpose, and it is the one place this rule is
+  restated. The `playbooks` plugin's `fable-5` orchestration chapter owns the rule with its
+  rationale; this skill's imperatives also **export** as a paste-ready brief for a target
+  that leaves the session, and that brief is model- and tool-agnostic by construction —
+  nothing in it may depend on a repo file — so a pointer is not an expressible form here.
+  It sits in the sub-clause body, leaving the `compact` headline-only export unchanged.
+
 ## [0.17.21]
 
 ### Fixed

plugins/session-flow/skills/orchestrate/SKILL.md

@@ -54,7 +54,9 @@ told:
    and judge the final STATE, not the process — an uncriteriaed verifier just rubber-stamps. When
    the verdict is high-stakes, prefer a different-vendor advisor when one is set up and able to
    judge this artifact — its blind spots are uncorrelated with yours — with the fresh-context
-   same-vendor verifier as the fallback.
+   same-vendor verifier as the fallback. Scope it to what ships: a process record about the work
+   (ledger, checklist, status log) is not the work and stays at self-check, however many of them a
+   batch touched, and a record OF a verification is never itself verified — that loop feeds itself.
 4. RUN WORKERS WELL — prefer non-blocking dispatch: keep working while independent workers run.
    Reuse a long-lived worker across subtasks when your runtime supports it (saves cost via cache).
    Watch running workers and intervene the moment one drifts or is missing context.