Quikcast feature freeze

Frozen build identity and evidence

• Source commit: b08268cb5d7230eccbecb2399f04891c0373ee3f (Add management API and drain lifecycle). At review start the working tree was clean and this commit contained the relay implementation.

• Debug executable SHA-256: 0f259dc7b8b062a87af33e09bff1a75acd39ad80dc2bff842be2d7a1daa8af7c.

• The 39 source/test/manifest/configuration/fixture/tool identities in evidence/relays/validation.json all matched the working tree. That includes production sources, Cargo.toml/Cargo.lock and the relay tests. Its binary identity matched the current executable and all fresh client proofs below.

• The recorded 88 passing tests and format/Clippy/build/check results remain applicable to that unchanged implementation. This review checked their identities rather than re-running unchanged correctness suites. The relay milestone review documents their coverage.

• Only documentation and a functional-only switch in the external HLS proof tool changed during this review. No production code, configuration values, dependencies or media fixtures changed. No daemon was deployed or existing development session modified.

Source-identity maps and the fresh proof reports are indexed by evidence/feature-freeze-2026-10-08/review.json. Generated captures remain ignored according to the existing repository evidence policy; the declaration/runbook themselves are tracked documentation. A later correctness change must record new build identities and repeat the affected checks before claiming this baseline's evidence applies.

Included functionality

1. Continuous encoded audio distribution: MP3, AAC ADTS, Ogg Vorbis and Ogg Opus, within the documented parser/channel/mapping subsets; source interoperability, source ownership, bounded rings/listeners and safe supported late joins.

2. Bounded ICY station/track behavior for MP3/AAC, source-authenticated metadata updates, and in-band Ogg metadata. Continuous source generations own their listeners and track state.

3. Independent typed ingest/publication and whole-object serving of externally produced MPEG-TS HLS assets, including its existing retention/budgets, GET/HEAD, ETags and optional configured CORS. No continuous/HLS conversion.

4. Continuous HTTP/HTTPS relays with static URLs and independent optional upstream Basic credentials, exclusive configured mount ownership, shared source publication, bounded remote metadata handling, supervised deadlines/backoff, native visibility/statistics, stop/reconnect and drain/shutdown behavior.

5. Static canonical mount configuration and source/HLS/management credential scopes; restart-based changes/rotation; volatile listeners, statistics, generations and HLS state.

6. Native operational inspection/control, active listener limits, trusted XFF inspection, health/readiness/metrics/logging, one-way drain, bounded shutdown and producer recovery/repopulation after restart.

7. The operator runbook, native API contract, example configuration and standalone project identity.

No selected feature in this scope remains an unfinished planned implementation item. Relay metadata/retry/control/ownership are included parts of relay completeness, not post-freeze additions. Remaining real-client exercises validate the scope and may reveal correctness or compatibility blockers; they are not silently counted as completed work.

Accepted contract and explicit dispositions

Keep the current supported operating model: Unix logging with a draining nonregular stdout collector; external inbound TLS termination and private loopback management; correctly configured nonbuffering live-stream proxies; static configuration/rotation by restart; ephemeral runtime/HLS state; configured application bounds with separate OS/proxy headroom; generation-scoped listener disconnection and client reconnection. Administrative access has no privileged capacity reservation under complete inbound saturation.

Keep the existing narrow media/client contract. Ogg comments remain in-band. HLS is MPEG-TS and whole-object; Range returns 416. The fresh FFmpeg HLS proof explicitly disables HTTP seeking/persistence. No selected target failure currently establishes required Range support; default browser/native player compatibility is still a pending manual-validation item. Relays do not follow redirects or accept legacy ICY 200 OK status lines, private/custom CA configuration or client certificates. These limitations are explicit rather than universal interoperability claims.

Disposition of the roadmap's full candidate inventory:

• Included and complete: the continuous relay group (ingest, metadata, backoff/deadlines, lifecycle/native operations) and standalone documentation.

• Deferred optional tooling: operator CLI, deployment examples/service packaging and bounded mount chaining. None is a freeze blocker or authorized implementation now.

• Deferred server expansion: fallback, takeover, priorities, automatic multi-source failover, origin/edge deployment packaging, runtime reload, restart-free rotation, native inbound TLS, PROXY protocol, additional continuous codecs, fMP4/CMAF, raw AAC HLS, LL-HLS, HLS encryption and persistent/disk-backed HLS. Ordinary origin-to-edge continuous delivery already works through relays; no extra clustering feature is selected.

• Conditional and unselected: Range and narrow encoder/player/relay compatibility changes. A reproducible mandatory-client failure requires an explicit compatibility/scope review before a change; broad parity remains excluded.

• Rejected from this scope: core listener-history/audit/runtime databases, public station directories, broad Icecast parity, distributed coordination/consensus/shared databases/service meshes, runtime encoding/decoding/transcoding/AutoDJ, continuous ↔ HLS bridging and RadioPlatform integration. External analytics/audit collection remains a deployment responsibility; future separately authorized consumers of the native API are not prohibited.

Fresh functional checks on 2026-10-08

Installed reference clients: FFmpeg 8.1.2 and curl 8.7.1. The following checks passed against the frozen binary:

• Continuous wire preservation, late join and external FFmpeg decoding for MP3, AAC, AAC-plus MIME, Vorbis audio/application MIME and Opus: six supported MIME cases, four codecs, all decoder exit codes 0. The raw source adapter in this proof is a Python fixture sender; this result is not a fresh BUTT/Liquidsoap/FFmpeg encoder session or an interactive listening judgment.

• Independent HLS HTTP publication/playback with concurrent continuous delivery: 31 HTTP operations passed, FFmpeg playback completed, source identities stayed unchanged and the proof server exited with code 0. The harness exercised whole-object GET/HEAD, Range rejection, ETag revalidation, configured CORS, publication/generation/authentication failures and final ENDLIST. It used a finalized HLS playlist, so rolling live-player behavior remains pending.

• Quikcast origin → continuous relay → curl: encoded bytes matched the continuous fixture; station/track metadata and administrative stop passed. Curl exit 28 was the expected finite test timeout on a healthy continuous response, not a reported playback failure. Throwaway test processes were cleaned up.

Reproduce only these functional checks with fresh output directories:

The legacy HLS script contains a latency workload. This review added/used --functional-only to skip it; playlist_workload.skipped=true is recorded. Do not invoke its historical performance mode during this gate. No profiler, microbenchmark, load generator, capacity test, tuning or optimization was run. Decoded media duration and received-byte counts establish functional delivery, not performance.

Remaining validation gate and allowed work

Follow the manual validation checklist. Required operator encoder/player/proxy targets and exact versions are still to be confirmed; available local references do not substitute for those targets. Prior user-reported BUTT success remains historical, unsealed evidence. No fresh interactive BUTT, VLC, browser HLS, public/private proxy or intended-deployment session is marked passed here.

After freeze, allow correctness fixes, documented compatibility investigation, validation and later optimization/hardening in dependency order. Adding planned functionality requires an explicit new scope decision and renewed freeze review. A mandatory-client failure can reopen the relevant scope/contract decision; it blocks profiling regardless of freeze status. Do not turn a validation failure into automatic authorization for broad compatibility, new containers/codecs or source policy.

Exit to profiling requires: named mandatory clients/deployment, satisfactory end-to-end manual results, closed correctness/compatibility blockers and explicit review of that evidence. Production qualification follows the later optimization/hardening milestone. This declaration alone is not permission to begin measurement or production work.

PERFORMANCE OPTIMIZATION REMAINS BLOCKED UNTIL MANUAL VALIDATION IS SATISFACTORY.