docs(cross-project-broadcast): codify capability-and-rule cadence guideline

Adds one bullet to When NOT to Use and a new Cadence Guideline
section that names the per-commit-broadcast anti-pattern explicitly.
The new section lays out the five reasons broadcasts stay
capability-and-rule-level rather than commit-level: cost per
broadcast across the fleet, signal-to-noise on project-internal
commits, the rsync-already-does-the-work observation, aggregation
winning over per-commit pings, and the train-projects-to-ignore-inbox
risk.

The end-of-session bundling guidance lands too. If a session ships
several broadcastable changes, bundle them into one broadcast at
session end instead of firing one per commit.

Source: session-end conversation 2026-05-29 surveying today's
cross-project changes. Today's session shipped 13 cross-project
items (4 new workflows, 6 workflow updates, 2 new scripts, 1 new
bin tool). A per-commit broadcast cadence would have fired 13 inbox
files across 23 targets, or 299 total inbox files. One consolidated
broadcast (or no broadcast at all, since Craig already coordinated
manually) covered the same ground.

1 files changed, 14 insertions, 1 deletions

diff --git a/claude-templates/.ai/workflows/cross-project-broadcast.org b/claude-templates/.ai/workflows/cross-project-broadcast.org
index 3a6294c..63af84f 100644
--- a/claude-templates/.ai/workflows/cross-project-broadcast.org
+++ b/claude-templates/.ai/workflows/cross-project-broadcast.org
@@ -25,7 +25,20 @@ Automatic invocation:
 
 - *Project-specific work.* A handoff intended for one project goes through =inbox-send= directly, not broadcast.
 - *Routine status updates.* The session log and todo.org cover routine work. Broadcast is for capability- or rule-level changes.
-- *Bulk noise.* Every broadcast adds N inbox files. Use sparingly; ask whether projects actually need to know.
+- *Bulk noise.* Every broadcast adds N inbox files. Use sparingly. Ask whether projects actually need to know.
+- *Every commit.* Most commits are project-internal hygiene (audit, intake, TODO updates) that the other projects don't care about. Even cross-project workflow updates rsync into every project's =.ai/= at next startup, so the capability lands without a broadcast. Broadcast only when projects need to *act* on the change (use a new tool, migrate before a deprecation, change their behavior per a new rule). Resist the urge to fan out a "here's what shipped today" digest. The startup rsync already carries the bits; the broadcast carries the *attention*, and attention is the costly resource.
+
+* Cadence Guideline
+
+Broadcasts are capability-and-rule-level events, not commit-level events. A reasonable cadence is one to four broadcasts per month, depending on what landed. Five reasons for the restraint:
+
+1. Each broadcast costs N inbox processings across the fleet (currently ~23 targets). Daily broadcasts mean daily noise.
+2. Most commits are project-internal. Other projects do not need to read about another project's TODO sweeps, audit passes, or hygiene work.
+3. The startup rsync already does the capability work. Broadcasts add awareness, not availability.
+4. Aggregation wins. One weekly "here's what shipped" digest beats ten per-commit pings on every dimension. Fewer inbox files, easier to skim, easier to defer reading.
+5. Per-commit broadcasts train projects to ignore inbox. Then a real handoff gets missed.
+
+If a session ships several broadcastable changes, bundle them into one broadcast at session end rather than firing one per commit.
 
 * The Workflow