CLAUDE: codify push-notification discipline

User wired up Telegram push notifications. New subsection under
"Direction freedom" pins down the discipline: only notify when
something is genuinely wanted from the user — exactly the
existing bounce-back triggers (real design judgement, genuinely
unexpected event, explicit checkpoint). Never for routine
progress or FYI updates.

The notification is the exception, not the rule. Default mode
stays autonomous. The notification body is the actionable
summary, one short line, phone-screen friendly.

CLAUDE.md

@@ -117,6 +117,33 @@ A summary of what shipped is fine and welcome — but in
 autonomous mode, follow it with the next dispatch, not a
 question.
 
+### Notifications
+
+The user has push notifications wired (Telegram). Use
+`PushNotification` ONLY when there is something I genuinely
+want from them — i.e. exactly the bounce-back triggers above:
+
+- A real design judgement I have not made myself (architectural
+  fork, multiple substantive options none clearly default).
+- A genuinely unexpected event that changes the project's
+  direction (fundamental design flaw, dependency failure,
+  invariant violation, refuting bench result).
+- An explicit checkpoint the user asked for.
+
+**Do NOT notify** for: shipping iters that completed cleanly,
+routine progress, "just FYI" status, or summaries when nothing
+needs their input. The Telegram message is a poke; an
+unnecessary one accumulates as noise. Err toward not sending.
+
+When notifying, the message body should be the actionable
+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 either via Telegram or by returning to the
+session.
+
+The default mode is autonomous. The notification is the
+exception, not the rule.
+
 ## Iter cycle
 
 Work is organised into **iters** — tightly scoped commits that