ersatztv/docs/decisions/archive/testing/scripted-playout-golden-deferred.md

key, title, status, since, supersedes, superseded-by, rule, signals, mechanics

key	title	status	since	supersedes	superseded-by	rule	signals	mechanics
testing.scripted-playout-golden-deferred	2026-07-22 — Sequential (YAML) playout gets a golden; Scripted is excluded from the golden net by construction (#381)	superseded	2026-07-22	none	testing.scripted-engine-in-process-net@2026-09-05	(superseded) The `PlayoutBuildGoldenTests` in-memory golden net covers Sequential (YAML) as of #381. Scripted's *end-to-end pipeline* is excluded — `ScriptedPlayoutBuilder` runs a user-authored external program that drives the engine over HTTP loopback, which the in-memory harness can't pin — so that full-pipeline (integration) harness is deferred to #563. But the scheduling *behavior* those scripts drive lives entirely in the in-process `SchedulingEngine` (the `ScriptedScheduleController` is a 1:1 pass-through to it), which IS directly unit/golden-testable; the earlier "Scripted is un-golden-able by construction" framing overstated the constraint by conflating transport with engine. #395 extracts that shared switch to `ContentEnumeratorBuilder` and adds a direct regression net (`ContentEnumeratorBuilderTests`) over it.	why is there no scripted golden; scripted transport vs engine; SchedulingEngine is in-process testable; Cli.Wrap external process is transport only; ScriptedScheduleController 1:1 pass-through; engine-level scripted regression net; EnumeratorForContent · paths: `ErsatzTV.Core.Tests/Scheduling/Goldens/PlayoutBuildGoldenTests.cs`, `ErsatzTV.Core.Tests/Scheduling/Engine/SchedulingEngineTests.cs`, `ErsatzTV.Core/Scheduling/Engine/SchedulingEngine.cs`, `ErsatzTV/Controllers/Api/ScriptedScheduleController.cs`, `ErsatzTV.Core/Scheduling/ScriptedScheduling/ScriptedPlayoutBuilder.cs` · issues: #381, #163, #395, #563	superseded by `testing.scripted-engine-in-process-net` (ersatztv#563), which stands up the deferred coverage in-process and corrects the "1:1 pass-through" description of `ScriptedScheduleController`

Sequential (YAML) is golden-able and TZ-independent. SequentialPlayoutBuilder reads a YAML schedule file (Playout.ScheduleFile) rather than a ProgramSchedule/Block calendar, but it is still a pure in-process build: content resolves from an in-memory-SQLite Collection by name, and the count/all/ duration handlers do UTC-only arithmetic off the caller-supplied start. So the Sequential_yaml case uses the exact same harness as Classic/Block — a committed input fixture (Goldens/Fixtures/sequential-schedule.yml) with two count: 2 instructions over one chronological collection — and needs no Assume/TZ guard (verified: it passes, not skips, under a non-UTC TZ, unlike Block). The fixture deliberately avoids the local-time-of-day handlers (wait_until, pad_to_next, pad_until) and shuffle order, which would reintroduce TZ- or seed-dependence. The builder checks the file via the injected IFileSystem but reads bytes with the static System.IO.File, so the test commits a real fixture on disk and stubs only IFileSystem.File.Exists; the JSON-schema validator is stubbed (it loads its schema from a runtime cache folder, irrelevant to characterizing builder output).

Scripted: transport is integration-only, but the engine is in-process testable. ScriptedPlayoutBuilder builds nothing itself — it Cli.Wrap-executes a user-authored external program, hands it http://localhost:{Settings.UiPort} + a build id, and after the process exits reads the result straight off the in-process engine (schedulingEngine.GetState()/GetAnchor()). The program drives the build by calling back over HTTP, but ScriptedScheduleController is a 1:1 pass-through: every action resolves the engine by build id and forwards to a single ISchedulingEngine method (AddCollection, AddCount, PadUntil, …) with no scheduling logic of its own. So "Scripted is un-golden-able" conflates two different things:

• The end-to-end pipeline (real external process + Kestrel on UiPort + HTTP loopback) genuinely is integration-test territory — the in-memory golden harness (shared SQLite, no I/O, deterministic clock) can't pin it, and that harness is deferred to #563. This part of the original decision stands.
• The scheduling behavior the scripts drive is 100% in SchedulingEngine, a plain DI-substitutable object already unit-tested (SchedulingEngineTests, new SchedulingEngine(…4 substitutes…)). It is directly drivable and snapshot-testable with no process and no HTTP — the same way the YAML golden drives its builder, just skipping the script/HTTP front-end. #395 extracts the enumerator-construction switch that the Scripted and Sequential/YAML engines share to ContentEnumeratorBuilder and adds a direct regression net (ContentEnumeratorBuilderTests) over it — the real safety net its dedup needs (not #563).

The #381 "documented decision" arm correctly deferred the pipeline golden; it overstated the case by writing off engine-level coverage too. Scripted scheduling behavior is now covered in-process; only the external-process pipeline remains #563's.