The speaker travels with the plan — T524–T529 (gh-#772)

[genwave-radio]

🎙️ PR-4 — the speaker travels with the plan (T524–T529)

Fourth PR of the orchestrator split (gh-#401), closing out STORY-456 of gh-#772. Follows #805 (PR-1), #808 (PR-2) and #818 (PR-3).

🎯 What changes

A break's speech now carries the speaker it was planned with, instead of re-reading whoever happens to be active when the render finally runs. That read was live: a persona switch between planning a break and rendering it could put the wrong voice, pace and pronunciation rules on segments that had already been scheduled under someone else.

Task	Change
T524	SpeakerSnapshot + SpeechCorrection on the contract; SegmentRequest.Speaker additive
T525	ISpeakerSnapshotSource + card-by-id seam; SpeakerSnapshotSource reads a card once
T526	The render branches on a planned speaker; ambient caches untouched
T527	BreakPlanner resolves a speaker per slot through a per-plan memo
T528	The seam index spec reads the committed SEAMS.md
T529	The AC13 dev-station wire evidence, honestly scoped

The branch is additive throughout: RenderCopyAsync takes the snapshot arm only when SegmentRequest.Speaker is non-null and falls through to the existing ambient path otherwise, so nothing that does not stamp a speaker changes behaviour. The two arms use structurally disjoint cache keys, so they cannot collide.

✅ Gate

Full solution, Release, warnings as errors:

Core 185 · Context 78 · Orchestration 523/42sk · Ads 222 · Plugins 53
MediaLibrary 169 · Tts 889/2sk · Host 3077/13sk · Architecture 174/9sk
0 failed · 0 warnings

Smoked on the Release binary against a real Postgres: /health → 200 Healthy, station schema migrated, no DI resolution failures building the Orchestrator/BreakPlanner graph.

🔬 T529 — what the dev-station run proves, and what it does not

Worth reading before merging, because the honest scope is narrower than the task line implies.

Established. The run flips segment_schedule day 6 once per trial and holds, in both directions, landing each flip inside the plan→render window by freezing the kokoro container the moment the outbound synth call starts and releasing it after. Four booth_log rows — 94739/94740 under a beta plan, 94744/94745 under an alpha plan — each name the persona their break was planned under, ~8s after the schedule was written to the other one. LogRenderOutcome names the same persona at the same instant.

Not established. That ~8s gap sits inside both the per-unit-plan ResolveAsync horizon and the 30s StalenessBound on the three card caches, so a still-re-resolving implementation would have produced identical rows. The rows are a plan-time-stamp regression guard, not timing evidence for which arm rendered them. The run's own 59s and 74s settle times are the measure of that.

Pace has no measured wire ratio. No production door drives arbitrary copy through TtsSegmentSource under a chosen persona — /api/tts/preview and /api/safe-segments both call ITtsSynthesizer directly, below the planner. Durations came out in the right direction but the artifacts could not be paired to copy text with confidence, so they are reported without a derived ratio rather than dressed up as one. Pace-freezing rests on construction instead: the snapshot arm returns rules, pace and hash as one tuple, so a non-null Speaker fixes pace to the plan-time value.

All of this is written into the two Skip = consts, so the limit travels with the code rather than living in a PR description.

👂 Owed

An ear check on the demo box that the planned persona's pace actually airs — same shape as the T430 and T454 ear checks. That is the one claim in STORY-456's AC13 no automated or dev-station evidence in this PR covers.

📦 Next

T530 is the pins PR (compose.pinned + CHANGELOG), which also regenerates the Abstractions surface baseline and deletes PendingPublicationSurfaceAllowlist. One ordering note found while scoping it: publish-nuget.yml triggers on v* tags, so the 5.10.0 package will not exist until the tag. The surface fact reads the live-built assembly rather than a package, so T530 regenerates from the build at its own commit — which is the same tree the tag publishes. Nothing in PR-5 touches src/GenWave.Abstractions, so that baseline stays valid through the tag.