feat(director): the clock names the day, not just the hour [spec 04]

[wine-fall]

Implements specs/spec04/04-no-dead-air.md §3.4 (the clock beside the bucket).

Closes #162 — this PR carries the half of it that still stands after #165, with @Eis4TY as the commit author.

What

The grounding that landed in #165 tells the host the local time to the minute. It still could not tell a Monday from a Saturday: the six-hour scene bucket cannot, and neither could a bare 2:28 pm. formatClock now renders the weekday and the zero-padded date before the 12-hour local time — Monday 2026-08-31, 2:28 pm — so every prompt that speaks aloud knows which day it is. Same ICU-free hand-rolling as before, so the prompt text stays byte-stable across machines.

What is left out, and why

#162 also proposed stamping the on-air track's played/remaining seconds on the prompt (2:10 of 4:05 played, about 1:55 left). Dropped on purpose: self-initiated beats are composed two deep ahead of air (spec 04 §3.3, TALK_LOOKAHEAD = 2), so a countdown stamped at compose time is already false when the beat is spoken — and #165's red lines tell the model to say nothing that turns false when the music changes. Feeding it a precise, stale countdown works against that rule. Progress on the immediate reply path alone would be accurate, but is a separate, smaller change if it is ever wanted.

Where

• src/scene.ts — formatClock gains the weekday and date.
• specs/spec04/04-no-dead-air.md — §3.4 design note records the field's shape.
• test/scene.test.ts, test/prompts.test.ts, test/director-music.test.ts — the new shape pinned with injected clock values; the live-clock regex updated.

Verification

• pnpm test: the three test files above green; the full suite shows the same six config/app failures as clean main (a local-only isolation gap — the tests read the real ~/.murmur/voice.json; CI has no such file).
• pnpm run typecheck and oxlint: clean.
• Peer review (codex gpt-5.6-sol, xhigh): 0 findings.

AI coding brief

Original request. The user asked whether they had recently opened PRs fixing the radio host "talking fake". Two open PRs fixed the same fabrication bug: #165 (the user's own) and #162 (a stranger's, from a fork, opened four hours earlier the same day). Both edited the same lines. The user asked to merge both; then, on learning #162 was from someone they did not know, asked whether just the weekday/date part could be taken in a way that still credits its author.

Manual interventions. (1) The agent initially reported both PRs as the user's — wrong; the user's question exposed that #162 had a different author. (2) A first reconciliation carried #162's progress numbers onto all four prompts; the agent's own review against the look-ahead buffer showed those numbers go stale on the beat path, and the user chose to keep only the clock half. (3) Pushing to the contributor's fork was blocked by permissions, so credit is carried by commit authorship (the contributor's GitHub noreply address, which links to their account) instead of updating #162 in place.

Retro. Check PR authorship before summarising "your PRs" — a gh pr list --json author up front would have saved a round. When reconciling two PRs that fix the same bug, evaluate each feature against the runtime's timing (here the look-ahead buffer) before merging, not after.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DnTSsRfAnvPPhcbipAMrgW