[PROPOSAL] Mumble tick measured; the daemon fails on §8's own criterion (PENDING-152)

Filed as an §8 amendment per REVIEWED-125. Measurement settles both open
questions at once.

4,015 inter-event intervals over 6 sessions: median gap 1.7s, p90 17.5s. A
clock check inside an event hook is late by under two seconds during active
work. The silent-afternoon half of the worry is real and costless — those gaps
are dormancy between sessions, and §9 sends output to the steward, who is not
there.

Proportions need no adjustment: 73/20/7 was calibrated for a time-uniform tick
and restoring the generator restores their meaning. The free parameter is the
interval. Proposed 20 min, hardcoded, from a measured 121 median active minutes
per session.

The daemon is costed and rejected, not dismissed, and not on cost: it has no
channel into a session, so delivery stays event-gated; and ticks generated with
no session must be dropped (equivalent to event-gating) or queued — and a queue
is memory, the hazard for which the hard cap was rejected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JQKeKY9T9d95KpvHwwok8T

PENDING.md

@@ -4045,3 +4045,81 @@ And the evidence predates every argument made about it. If the pairs turn out to
 
 **Files affected:** none yet — read-only. Filename defects noted, **not repaired**: they are the 2025 record and renaming is a separate `[FIX]` the steward owns.
 **Awaiting:** steward authorization of the design; jurist or steward to commit to step 2 before step 1 runs.
+
+---
+
+## PENDING-152 — The mumble tick: event-gating measured, and the daemon costed and rejected on §8's own criterion
+**Date:** 2026-08-22
+**Tag:** [PROPOSAL]
+**Summary:** Filed as an amendment to v2 §8, per REVIEWED-125 (*"if the executor's answer requires the trigger key to change, that is an amendment to §8 and is filed as such"*). Answers the deferred re-derivation and the daemon question together, because measurement settles both.
+
+### The worry, stated as the jurist put it
+
+> *A clock check inside an event hook is still event-gated: on a silent afternoon the clock ticks and nothing fires; on a heavy morning it fires at the first opportunity. That's the burst problem returning through the back door.*
+
+### Measured — 6 sessions, 4,015 inter-event intervals
+
+Hook-firing events are `UserPromptSubmit` / `PreToolUse` / `PostToolUse`, not governance events, so the relevant quantity is the gap between *those*.
+
+| | |
+|---|---|
+| median gap | **1.7 s** |
+| p90 | 17.5 s |
+| p99 | 290 s |
+| intervals exceeding a 30-min tick | **22 / 4,015 = 0.55%** |
+
+**During active work a clock check inside an event hook is late by under two seconds at the median.** The event stream is dense enough that it approximates a real timer to within noise.
+
+### ⚠ The silent-afternoon half is real and costless, and this is the load-bearing point
+
+The long gaps exist — max 189,161 s (52 h). But they are **dormancy between sessions**, and §9 says output reaches **the steward**. **During those silences there is nobody to mumble to.** A tick that cannot fire while the steward is absent has lost nothing: the fool has no audience, and a mumble delivered to an empty room is not a mumble the design wanted.
+
+Separated properly: median **121 active minutes** per session (mean 118), against 3–53% activity ratios — i.e. sessions are short bursts of work inside long dormancy.
+
+### The burst problem is solved, not declared away
+
+A 20-minute time tick over a 121-minute active session yields ~6 ticks **whether that session carried 5 governance events or 500.** The tick is bounded by time, not by event count — which is exactly the property §8 was rewritten to obtain. The residual event-gating shifts *when within a ~2 s window* a tick lands, and nothing else.
+
+### Proportions — NO adjustment, and that is the answer rather than an evasion
+
+REVIEWED-125 deferred the re-derivation asking for **adjusted proportions**. On measurement, adjusting them would be wrong: **73/20/7 was calibrated against a time-uniform tick, and restoring the generator to time restores the proportions to their calibrated meaning.** v2 §8 said this — *"restore the original generator, not patch the re-keyed one"* — and the numbers bear it out. Adjusting now would correct for a defect that no longer exists.
+
+**The free parameter is the TICK INTERVAL, and that is what must be pre-registered and hardcoded.**
+
+| tick | ticks/session | utterances/session | per day (1.39 sessions/day) |
+|---|---|---|---|
+| 10 min | 12.1 | 3.3 | 4.6 |
+| 15 min | 8.1 | 2.2 | 3.0 |
+| **20 min (proposed)** | **6.1** | **1.6** | **2.3** |
+| 30 min | 4.0 | 1.1 | 1.5 |
+
+**Proposed: 20 minutes of in-session wall clock, hardcoded, 73/20/7 drawn at each tick, no cap.** Mumble ≈ 2.3/day against voice at 2–3/day, so the two tiers are comparable in volume and neither drowns the other. v2 §8's stated adjustment path runs one way — *"if it reads as noise, the interval lengthens"* — so starting at 20 and lengthening matches it; starting at 30 would require shortening, which that path does not license.
+
+### ⚠ THE DAEMON — costed, and it FAILS on §8's own criterion
+
+Not dismissed. Costed, and the cost is not the reason it fails.
+
+**What it buys:** a true wall-clock tick, independent of session activity.
+
+**What it costs:** a launchd agent (plist, persistent process, sleep/wake handling, restart-on-reboot) — real but modest.
+
+**Why it fails, and this is decisive:**
+
+1. **A daemon has no channel into a Claude Code session.** It can write a file. The status line reads the file. **But the status line re-renders on session activity** — so the tick's *delivery* is event-gated even when its *generation* is not. The daemon moves the gating one layer down and does not remove it.
+2. **Ticks generated while no session exists must be either dropped or queued.** Dropped ⇒ behaviourally identical to event-gating, at the cost of a daemon. Queued ⇒ **a backlog is state, and state is memory — the exact hazard for which REVIEWED-125 rejected the hard cap** (*"a budget-spent state… memory is the beginning of learnability"*).
+3. **A queued backlog arrives in a burst at session start** — reproducing the burst problem the daemon was introduced to fix, now concentrated at the seam where the voice already speaks.
+
+**A real timer delivers what §8 claims only if the delivery surface is also time-driven. It is not.** So the honest position is not *"we accept an event-gated compromise because a daemon is expensive"* — it is **"a daemon does not buy the property, and buying it would require the memory §8 forbids."**
+
+### One unverified assumption, with the method to settle it
+
+**Whether Claude Code re-renders the status line on a timer or only on session activity.** Not verified; it bears on point 1 above and on §8a's body. **Settle by experiment:** configure a status line that prints the current clock time, leave a session idle, and observe whether the displayed time advances. If it does, the body can render time-derived variation unaided (satisfying REVIEWED-125 cond. 2 cheaply) and point 1 weakens for the *body* — though not for the mumble, whose content still originates in the session.
+
+### What this does NOT claim
+
+- **Not zero event-gating.** ~1% of intervals exceed 290 s, so roughly one tick in a hundred could land up to ~5 minutes late. Declared rather than smoothed.
+- **Not a general result.** Six sessions, one steward, this machine. The timestamps are mechanical rather than authored, so the corpus is not self-report — but the working pattern is one person's.
+- **Nothing about §8a's body.** That is REVIEWED-125 cond. 2 and is separate.
+
+**Files affected:** none yet. No implementation; §4 order and the transport-not-voice line both hold.
+**Awaiting:** steward and jurist on the 20-minute interval and on the daemon rejection.