---
key: testing.scripted-playout-golden-deferred
title: 2026-07-22 — Sequential (YAML) playout gets a golden; Scripted is excluded from the golden net by construction (#381)
status: active
since: '2026-07-22'
supersedes: none
superseded-by: none
rule: '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.'
signals: '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'
mechanics: docs/testing.md → Golden-file nets
---

**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.