[PROPOSAL] statusLine.refreshInterval exists — my own daemon premise was wrong (PENDING-152 A2)

The settings schema documents statusLine.refreshInterval: "re-run the status
line command every N seconds in addition to event-driven updates". So the
surface is event-driven by default and time-driven when the field is set.

That falsifies the load-bearing premise of PENDING-152's first daemon prong,
which I filed an hour ago claiming the delivery surface re-renders only on
session activity. I flagged it as unverified, which is the only reason it was
recoverable.

It also solves the case AMENDMENT 1 declared unmeasured: presence without
activity. A refreshInterval fires while the steward reads and drafts. So the
mumble need not be event-gated at all — its home is the status line's own
refresh, not a hook, which collapses body-rendering and mumble-clock into one
mechanism and satisfies REVIEWED-125 cond. 2 with time-derived variation.

The conclusion is unchanged: a daemon still buys nothing. But its support is
narrower and more honest — not because delivery is inherently gated, but
because the only interval a daemon covers has no audience and no legitimate
place to put the residue.

Probe installed at refreshInterval 10, logging invocations; backup taken;
surface confirmed free first.

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

PENDING.md

@@ -4165,3 +4165,50 @@ REVIEWED-125 deferred the re-derivation requiring **adjusted proportions**, on t
 **Run the status-line experiment before any body is built.** Ten minutes; settles §8a's design and REVIEWED-125 cond. 2; the difference between a body that idles visibly and one that only appears to.
 
 **Awaiting:** nothing on (a)–(c). The status-line experiment is the executor's next act and needs no ruling.
+
+### AMENDMENT 2 — 2026-08-22 — the unverified assumption resolved from the schema, AGAINST my own argument
+
+**Settled without the experiment.** The settings schema documents a `statusLine.refreshInterval` field:
+
+> *"Re-run the status line command every N seconds **in addition to event-driven updates**"* — number, minimum 1.
+
+**So the status line is event-driven BY DEFAULT, and time-driven when `refreshInterval` is set.**
+
+#### ⚠ PENDING-152's FIRST DAEMON PRONG IS WRONG AS FILED
+
+I wrote, as the load-bearing premise of a structural argument:
+
+> *"the delivery surface — the status line — re-renders on session activity, so the gate is relocated, not removed."*
+
+**That is true only of the default configuration.** With `refreshInterval` set, the surface re-renders on a timer regardless of session activity. **The delivery surface CAN be time-driven, and I asserted it could not.**
+
+I flagged this as an unverified assumption when I filed it. **The flag is the only reason it was recoverable** — an unflagged premise inside a "structural limit" reads as established and gets inherited. Disclosure of scope paying out again, this time on my own claim rather than a jurist's.
+
+#### ⚠ AND IT SOLVES THE CASE THE JURIST SAID WAS UNMEASURED
+
+AMENDMENT 1 recorded, correctly, that my data could not see **presence without activity** — the steward reading or drafting elsewhere, generating no hook events, which is exactly when drift consolidates. I declared it unmeasured and said measuring it would need an intrusive presence signal.
+
+**It does not need measuring, because it can be solved.** A status line with `refreshInterval: N` fires while the steward reads and drafts, with no events at all. **The mumble does not need to be event-gated in the first place.**
+
+#### Design consequence — the mumble's home changes
+
+**Filed:** a clock check inside `UserPromptSubmit` / `PostToolUse`.
+**Corrected:** the mumble is driven by the **status line's own refresh**, not by a hook. Frequency comes from `refreshInterval`; the 20-minute tick is a counter over refreshes rather than over events. No hook is involved and no event-gating remains within a session.
+
+This is cleaner than what was filed, and it collapses two problems into one mechanism: **the same refresh that renders the body's silence also drives the mumble's clock.**
+
+**It also satisfies REVIEWED-125 cond. 2 cheaply.** A surface re-rendering every N seconds can carry **time-derived** variation with no content derivation and no sprites or animation frames — exactly what condition 2 requires and what a static name cannot do.
+
+#### What SURVIVES from PENDING-152
+
+**The daemon's second failure stands, untouched and still decisive.** Between sessions **nothing runs at all** — not the status line, not its refresh. Ticks generated by a daemon while no session exists must be **dropped** (equivalent to no daemon) or **queued** (a backlog is state, which is memory, which is the hazard the hard cap was rejected for, arriving in a burst at session start).
+
+**So the conclusion is unchanged and its support is now narrower and more honest:** a daemon buys nothing, not because delivery is inherently gated — it isn't — but because the only interval a daemon could cover is the one where there is no audience and no legitimate place to put the residue.
+
+**The 20-minute interval, the proportions-by-dissolution finding, and the measured event data are all unaffected.**
+
+#### Probe installed, and how to remove it
+
+`~/.claude/settings.json` now carries a temporary `statusLine` running `~/.claude/statusline-probe.sh` at `refreshInterval: 10`, logging each invocation to `~/.claude/statusline-probe.log`. Backup at `~/.claude/settings.json.bak-2026-08-22`. **The surface was confirmed free before installing; nothing was displaced.** Remove by deleting the `statusLine` key. It prints `· probe` and carries **no name and no utterance** — transport, not voice, per the standing line. May require a config reload to begin firing.
+
+**Awaiting:** nothing. The empirical confirmation is a read of the probe log, not a decision.