diff --git a/skills/boss/SKILL.md b/skills/boss/SKILL.md
index 19fa336..3114a32 100644
--- a/skills/boss/SKILL.md
+++ b/skills/boss/SKILL.md
@@ -55,7 +55,8 @@ re-enters by typing `/boss` again.
 ```
 NO AUTONOMOUS DISPATCH OUTSIDE A `/boss` SESSION.
 DONE-STATE = QUEUE EMPTY, NOT SUB-GOAL COMPLETE.
-BOUNCE-BACK ONLY ON THE THREE NAMED TRIGGERS.
+BOUNCE-BACK ONLY ON THE FOUR NAMED TRIGGERS.
+A NEW MILESTONE NEVER STARTS AUTONOMOUSLY — IT IS A BOUNCE-BACK.
 WHATSNEW.MD + NOTIFY ARE ONE TEXT, NOT TWO.
 ```
 
@@ -94,10 +95,13 @@ brainstorm → planner → implement → audit → fieldtest
 ```
 
 Match the chosen item to the right entry skill. If a milestone is
-new and no spec exists: `brainstorm`. If a spec exists but no plan:
-`planner`. If a plan exists: `implement`. If a milestone is closing:
-`audit`. If the iter is a bugfix: `debug`. Read each skill's
-SKILL.md trigger section if unsure.
+new and no spec exists: **bounce back first** (per §"Direction
+freedom" trigger 4 — new milestones never start autonomously);
+only after the user green-lights the milestone (and the session
+shape) does `brainstorm` get dispatched. If a spec exists but no
+plan: `planner`. If a plan exists: `implement`. If a milestone is
+closing: `audit`. If the iter is a bugfix: `debug`. Read each
+skill's SKILL.md trigger section if unsure.
 
 If the working tree is mid-flight (uncommitted changes left over
 from a previous session): inspect first, then resume the right
@@ -144,6 +148,23 @@ Bounce back to the user only when:
   project's direction (a fundamental design flaw, an external
   dependency failure, a discovered invariant violation).
 - The user has explicitly asked for a checkpoint.
+- **The next item on the queue is a new milestone** — i.e. a
+  roadmap entry that has no `docs/specs/` file yet and would
+  require dispatching `brainstorm` to even begin. Continuing
+  an open milestone (next iter, audit, fieldtest, post-audit
+  tidy) is autonomous; *starting* a new one is a bounce-back.
+
+  **Why this is different from the other three triggers.** Cross-
+  milestone work is high-context work. A fresh brainstorm alone
+  routinely consumes tens of thousands of tokens on grounding-
+  check reads, design Q&A, and spec drafting — on top of whatever
+  context the just-closed milestone left behind. I cannot compact
+  my own context window; only the user can decide that the right
+  shape for the next milestone is a fresh session rather than a
+  continuation. A new milestone is therefore the natural
+  checkpoint: stop, surface the candidate, let the user pick the
+  session shape (continue here / spawn fresh / defer / pick a
+  different roadmap item).
 
 A summary of what shipped is fine and welcome — but in
 autonomous mode, follow it with the next dispatch, not a
@@ -165,8 +186,10 @@ Two states call for a notify; nothing else does:
 
 2. **Problem-state.** A bounce-back trigger per §"Direction
    freedom" — design fork I cannot resolve, an unexpected
-   invariant violation, an external dependency failure, or the
-   user has explicitly asked for a checkpoint.
+   invariant violation, an external dependency failure, the
+   user has explicitly asked for a checkpoint, or the next
+   roadmap item is a new milestone (no spec yet) and starting
+   it would force a fresh `brainstorm`.
 
 A user-specified stop trigger ("until X is done, then notify")
 counts as done-state only if X is truly the last actionable item
@@ -236,6 +259,8 @@ Notify text verbatim.
 | "User said 'until X then notify', X just completed, notify now" | Check whether X was actually the last actionable thing. If hitting X leaves an open milestone with obvious follow-up, the user's intent was "wake me when there's nothing else to do" — continue. |
 | "Done-state hit, send notify, append WhatsNew later" | WhatsNew + notify are one text. Append first (atomic), send second. Splitting them is how the WhatsNew gets forgotten. |
 | "WhatsNew can name the iter code — user will figure out what it means" | No. WhatsNew is for the user-as-reader who did not watch me work. Iter codes, crate names, function identifiers, type names — all internal, all banned. |
+| "The previous milestone closed cleanly and the next roadmap item is obvious — just dispatch `brainstorm` and keep going" | No. Starting a new milestone is itself a bounce-back. A fresh `brainstorm` is high-context work, and I cannot compact my own context — only the user can decide whether the next milestone wants a fresh session or a continuation of this one. The "obviousness" of the candidate is irrelevant; the *cross-milestone hop* is the checkpoint, not the topic choice. |
+| "It's the same broad area as the milestone I just closed, that's not really a new milestone" | If there is no `docs/specs/<...>.md` file for it yet and it would route through `brainstorm` to get one, it IS a new milestone for this rule's purposes. The rule keys on "needs a fresh spec", not on subjective continuity. |
 
 ## Red Flags — STOP
 
@@ -245,6 +270,7 @@ Notify text verbatim.
 - About to write a WhatsNew entry that names a crate, an iter code, or an agent.
 - About to bounce back at every iter boundary "just to be safe" — that's reactive deference, not direction freedom.
 - About to send the WhatsNew text and the Notify text with different wording — they must be one verbatim text.
+- About to dispatch `brainstorm` on a roadmap item that does not yet have a spec file, without first bouncing back to the user. New milestones never start autonomously.
 
 ## Cross-references