docs(planning): reframe interview session-config framing

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

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

plugins/planning/CHANGELOG.md

@@ -3,6 +3,32 @@
 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.26.1]
+
+### Fixed
+
+- **`interview`'s session-config guidance no longer reads as a runtime imperative to
+  a nonexistent downstream session.** The mid-task "raise the model/effort" rule was
+  phrased as an instruction to an executing actor, but `/interview` terminates at
+  handoff and never wires that context into whatever session executes next — it is
+  now framed as a watch-for the interview hands the **user** at handoff. Separately,
+  the recommendation's header framed itself as configuring "the downstream execution
+  session," which the "Both domains" section then extended to general sessions even
+  though a general session is terminal with no downstream consumer (SKILL.md Step 5).
+  General/terminal sessions now frame the recommendation as config for the
+  current/next session, applied now; the "Both domains" scope is unchanged. The
+  handoff checklist's Step 5 is aligned to the same split.
+- **`interview`'s general-session config recommendation now lands early enough to
+  act on.** With the current/next-session framing, a recommendation first emitted at
+  the stop boundary arrives after the work it was derived from is complete — the
+  general session is terminal, so applying `/model`, effort, or `/advisor` there
+  cannot improve the reached understanding. General/terminal sessions now surface a
+  first read right after the Step 1 survey classifies the domain as general (when
+  survey signals warrant a change), refresh it at the stop boundary, and — when the
+  config was raised only at the end — offer to re-evaluate the reached understanding
+  under the raised config. Engineering timing is unchanged: the downstream execution
+  session has not started yet, so the stop/handoff boundary remains early enough.
+
 ## [0.26.0]
 
 ### Changed

plugins/planning/skills/interview/SKILL.md

@@ -207,10 +207,20 @@ Do NOT auto-clear or auto-invoke. Recommend; let the user pull the trigger.
 
 ## Session-config recommendation (model, effort, advisor)
 
-The interview already reads task complexity and ambiguity to drive its rounds — so at
-the stop/handoff boundary, turn that read into a recommendation for how the
-**downstream execution session** should be configured. Two orthogonal knobs, picked
-per the official distinction:
+The interview already reads task complexity and ambiguity to drive its rounds — turn
+that read into a recommendation for how the session carrying the work forward should
+be configured. *When* it lands follows from *what* it configures. Engineering work
+hands off to a **downstream execution session** that has not started yet, so its
+recommendation belongs at the stop/handoff boundary. A terminal session (general
+decisions, per Step 5 above) has nothing downstream — the session carrying the work
+IS the current one — so surface a first read **early**, right after the Step 1
+survey classifies the domain as general, whenever the survey's complexity/ambiguity
+signals warrant a config change: applied then, it can still improve the substantive
+rounds it was derived for. At the stop boundary, refresh that read as config for the
+**current/next session**, applied now; if the config was raised only at the end (or
+not at all), offer to re-evaluate the reached understanding under the raised config
+rather than presenting a knob that can no longer affect the finished work. Two
+orthogonal knobs, picked per the official distinction:
 
 - **Model tier (capability)** — raise the model when the assistant would be
   *confidently wrong despite full context* (a reasoning ceiling, not missing input).
@@ -231,8 +241,10 @@ failure **degrades, never halts** — fall back to the durable distinction and t
 user the current names could not be verified live so they confirm against `/model` /
 `/advisor`. Frame the whole thing as advisory (the skill cannot read the current
 effort/advisor state) and applicable to engineering and general sessions alike. The
-same signals run **mid-task** in the inverse direction — surface "too complex for the
-current model/effort" when execution warrants. Full detail, sources, and the
+same signals matter **mid-task**, in the inverse direction — but the interview
+terminates at handoff, so hand the user a watch-for ("if execution turns out too
+complex for the current model/effort, that's the cue to raise it") rather than an
+instruction to whatever session executes next. Full detail, sources, and the
 knob-picking signals in [`context/session-config.md`](context/session-config.md).
 
 ## What this skill does NOT do

plugins/planning/skills/interview/context/session-config.md

@@ -2,10 +2,14 @@
 
 Reference detail for the `## Session-config recommendation (model, effort, advisor)`
 section of `SKILL.md`.
-Read on demand when forming the recommendation at the interview's stop/handoff
-boundary. The interview already reads task complexity and ambiguity to drive its
-rounds; this turns that read into a recommendation for how the **downstream
-execution session** should be configured.
+Read on demand when forming the recommendation — at the stop/handoff boundary for an
+engineering session, or at the early post-survey surface (and again at the stop
+boundary) for a general/terminal session. The interview already reads task complexity
+and ambiguity to drive its rounds; this turns that read into a recommendation for how
+the session that carries the work forward should be configured — the **downstream
+execution session** an engineering session hands off to, or, when the session is
+terminal with no downstream consumer (a general decision, per SKILL.md Step 5), the
+**current/next session**, applied now.
 
 ## Two orthogonal knobs
 
@@ -78,12 +82,32 @@ capability (reading the live effort/advisor state) that does not exist.
 Complexity and ambiguity apply to engineering and general sessions alike — a hard
 general decision can warrant the top model just as a subtle refactor can. Surface the
 recommendation for both; it is orthogonal to the engineering/general domain split and
-to the `me`/`auto`/`lock` action.
+to the `me`/`auto`/`lock` action. Framing differs by what the session hands off to
+(SKILL.md Step 5): an engineering session's recommendation configures the
+**downstream execution session** it hands off to. A general session is **terminal** —
+nothing downstream exists — so its recommendation configures the **current or next
+session**, applied now (`/model` for the model, the effort setting for effort,
+`/advisor` for the advisor), not a session that will never exist.
+
+**Timing differs with the consumer.** The engineering recommendation configures a
+session that has not started yet, so the stop/handoff boundary is early enough. A
+general session's consumer is the session already running the interview — a
+recommendation first emitted at the stop boundary lands after the work it was derived
+from is complete. Surface a first read early, right after the Step 1 survey
+classifies the domain as general, whenever the survey's complexity/ambiguity signals
+warrant a config change — applied then, it improves the substantive rounds
+themselves. Refresh it at the stop boundary as config for the current/next session.
+When the config was raised only at the end, or the user declined a mid-session
+change, offer to re-evaluate the reached understanding under the raised config
+instead of leaving the recommendation purely prospective.
 
 ## Inverse direction — mid-task
 
-The same two signals run mid-task, not only at the interview boundary. If execution
-starts showing **confidently-wrong-despite-context** (raise the model) or
-**under-exploration / under-verification** (raise effort), surface "this may be too
-complex for the current model/effort" and recommend the upgrade with the same
-knob-picking logic — rather than grinding on under a config the task has outgrown.
+The same two signals matter mid-task, not only at the interview boundary — but the
+interview terminates at handoff (SKILL.md Step 5) and nothing wires this context into
+whatever session executes next. Hand it to the **user** as a watch-for at handoff,
+not as an instruction to an executing actor: tell them that if execution starts
+showing **confidently-wrong-despite-context** (a signal to raise the model) or
+**under-exploration / under-verification** (a signal to raise effort), that is their
+cue to raise the corresponding knob — same knob-picking logic as above — rather than
+grinding on under a config the task has outgrown.

plugins/planning/skills/interview/templates/checklist.md

@@ -9,7 +9,7 @@ Copy into `<memory_dir>/<topic-slug>/interview-checklist.md` (default `.work/`;
 - [ ] Step 2: Drive the frontier-rounds loop — each round asks every settled-prerequisite question as one numbered set in **inline prose** (`AskUserQuestion` only via the `use_ask_user_question` opt-in; `lock` synthesizes without Q&A); order rounds by blast radius; restate decided/open after each round
 - [ ] Step 3: Recognize the stop condition — frontier is empty (every load-bearing unknown resolved or captured as a named assumption) AND user has confirmed the restated shared understanding (`me`/`auto`; `lock` is exempt — invoking it IS the confirmation)
 - [ ] Step 4: Persist the contract — engineering: write the PLAN.md Brief section with goal + constraints + acceptance criteria + captured assumptions; general: write the shared-understanding summary, never a Brief (`me` mode: persist each answer incrementally as it locks in; flush before context overflows)
-- [ ] Step 5: Hand off — engineering: recommend the next skill (exploration/research for engineering-internal; chain after `/prd` for product-driven); general: deliver the summary and stop, no pipeline handoff. Both: recommend the downstream session's model / effort / advisor per the live-doc-sourced session-config guidance (never a pinned model name)
+- [ ] Step 5: Hand off — engineering: recommend the next skill (exploration/research for engineering-internal; chain after `/prd` for product-driven); general: deliver the summary and stop, no pipeline handoff. Both: recommend model / effort / advisor per the live-doc-sourced session-config guidance (never a pinned model name) — engineering configures the **downstream execution session** it hands off to; general/terminal configures the **current/next session**, applied now (nothing downstream exists) — first surfaced early, post-survey, so it could shape the rounds themselves; here refresh it and, if raised only now, offer to re-evaluate the result under the raised config
 
 ## Decision tree (`me` mode only)