CLAUDE.md: notification policy — done-state = queue empty, not sub-goal complete

The previous one-liner 'notify when done and nothing left to do'
left 'done' under-defined. Concrete failure mode (2026-05-12, this
session): test suite for an open milestone landed, I notified on
the user-specified stop trigger, but the milestone still had two
follow-up iters (DESIGN.md anchor + audit) plainly in scope. The
user's intent behind the trigger was 'wake me when there's
nothing else to do', not 'wake me at this checkpoint'.

The expanded section codes two states (done-state, problem-state),
explicitly names sub-goal completion as NOT a notify event, and
calibrates user-specified stop triggers: hit only if the trigger
leaves the queue truly empty.

CLAUDE.md

@@ -198,8 +198,33 @@ question.
 
 ### Notifications
 
-When the user is away, notify him when you're done and there
+Two states call for a notify; nothing else does:
-is nothing left to do.
+
+1. **Done-state.** The autonomous queue is empty — the milestone
+   closed, the audit ratified, and no further iteration is obvious
+   from the spec or the roadmap (or, in a user-scoped session,
+   every objective the user named has been completed and there is
+   nothing else queued). A finished sub-goal inside a still-open
+   milestone is *not* done-state. If the next iteration is obvious
+   and substantive, keep dispatching — "test suite landed", "audit
+   clean before close-fixes", "iter N done with N+1 in scope" are
+   internal progress, not notify events.
+
+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.
+
+A user-specified stop trigger ("until X is done, then notify")
+counts as done-state only if X is truly the last actionable item
+in the autonomous queue at that moment. If hitting X still leaves
+an open milestone with obvious follow-up iters, the right action
+is to continue past X without notifying — the user's intent
+behind the trigger is "wake me when there's nothing else to do",
+not "wake me at this specific checkpoint".
+
+Mid-flow progress notifications burn the user's attention without
+giving him a decision to make. When in doubt, continue.
 
 ~/.claude/notify.sh "Text"
 
@@ -208,7 +233,7 @@ summary: what I need from them, in one short line. Skip the
 "hi, I" framing — just the gist. The user will see it on phone
 and likely respond by returning to the session.
 
-By default, you act autonomous. The notification is the
+By default, I act autonomous. The notification is the
 exception, not the rule.
 
 ### Done-state notifications: WhatsNew.md