feat(audio): complete phase 3c slice 3 automation

README.md

@@ -12,7 +12,7 @@ XZBT is a self-contained browser runtime for declarative procedural audiovisual
 | [Format Specification 0.1](docs/XZBT_0-1_Format_Specification.md) | Runtime semantics, contract inventory, and required authoring examples | Document revision 0.4; Phase 0 shared contracts and the complete Phase 3a-3c audio subsystem contract, remaining subsystem contracts in dependency order |
 | [Gap Closure Decisions](docs/XZBT_0-1_Gap_Closure_Decisions.md) | Decisions and rationale for the seven pre-implementation gaps | Record revision 0.3; GC1–GC5 Phase 0 evidence complete |
 | [Verification Gates](docs/XZBT_0-1_Verification_Gates.md) | Evidence required before architecture commitment, subsystem work, and release | Phase 0 complete; later subsystem, GC6, and GC7 checks scheduled |
-| [Implementation status](docs/IMPLEMENTATION_STATUS.md) | Current phase, stop reason, saved work, and resume prerequisites | Audio contract complete through Phase 3c; Phase 3c implementation, Phase 1 direct-file, and Phase 3 audible observations pending |
+| [Implementation status](docs/IMPLEMENTATION_STATUS.md) | Current phase, stop reason, saved work, and resume prerequisites | Implemented through Phase 3c slice 3; stopped before slice 4. Phase 1 direct-file and Phase 3 audible observations pending |
 | [Implementation plan](docs/XZBT_0-1_Implementation_Plan.md) | Sequenced phases, completion/challenge mapping, and GC6/GC7 verification schedule | Phase 1–9 plan recorded |
 
 The PRD is authoritative for product requirements. The format specification is authoritative for runtime semantics where a contract is explicitly defined. The decision record explains those choices; the verification gates define how to check them. These documents must be updated together when a decision changes. An unresolved conflict is a specification defect, not permission for an implementation to choose silently.
@@ -21,11 +21,11 @@ The earlier ChatGPT discussion, **Discuss Application Vision** (conversation `6a
 
 ## Planning entry point
 
-Phase 0 is complete, the production runtime is implemented through Phase 3b, and the audio subsystem contract is written through Phase 3c. Continue with Phase 3c implementation slice 2 (lifecycle and voices) from the implementation plan while preserving the verified launch model, shared semantic contracts, and production GC2/GC3 behavior. Two observations remain open in completed work: the Phase 1 direct-file two-fixture restart, and the Phase 3 audible acceptance — no sound has been heard from any build. Workload measurements and release soak tests remain later explicit gates.
+Phase 0 is complete, the production runtime is implemented through Phase 3c slice 3 (automation), and the audio subsystem contract is written through Phase 3c. Work is stopped at the user-requested slice-3 checkpoint. The next slice is 3c-4 (measured master protection), which requires user-observed hardware measurements and listening; it has not been started. The Phase 1 direct-file two-fixture restart and Phase 3 audible acceptance remain open — no sound has been heard from a production build. Workload measurements and release soak tests remain later explicit gates.
 
 The full PRD completion criteria remain the 0.1 release target. Early integrated demonstrations are milestones, not completed MVPs. Reference exhibits develop alongside the engine; Phase 9 completes and audits the suite.
 
-All 10 Phase 0 direct-file feasibility checks in GC1 are verified, and the GC2–GC5 contract oracles pass. Phase 1 turns those contracts into a standalone runtime shell with import, caching, activation control, diagnostics, and production seeded RNG. Phase 2 adds parameters, state, signals, values, conditions, actions, bindings, transitions, overrides, and per-exhibit parameter persistence. Phases 3a and 3b add the audio authoring contract — all sixteen graph node types, routing and modulation, graph legality, authoring limits, components, sounds and recipes, and buses — together with pure validation and expansion, deterministic instantiation, and Web Audio realization. Later Phase 3c, visual, cadence, scenario, UI, library-hardening, benchmark, and soak gates remain explicit in the implementation plan.
+All 10 Phase 0 direct-file feasibility checks in GC1 are verified, and the GC2–GC5 contract oracles pass. Phase 1 turns those contracts into a standalone runtime shell with import, caching, activation control, diagnostics, and production seeded RNG. Phase 2 adds parameters, state, signals, values, conditions, actions, bindings, transitions, overrides, and per-exhibit parameter persistence. Phases 3a and 3b add the audio graph contract and engine; Phase 3c slices 1–3 add the remaining audio contract, lifecycle/voice management, and automation. Master protection, visual, cadence, scenario, UI, library-hardening, benchmark, and soak gates remain explicit in the implementation plan.
 
 ## Repository configuration
 
@@ -65,9 +65,13 @@ npm run test:phase3
 
 Run every suite with `npm test`.
 
+Run just the Phase 3c slice-3 traces with `npm run test:phase3c3`. The [slice-3 evidence](docs/evidence/phase3/2026-09-05-phase3c-automation.md) records coverage and the remaining manual gates.
+
 The active performance supports typed parameters and state, read-only runtime signals, ValueSpec and ConditionSpec evaluation, ordered `set` and `override` actions, same-tick bindings with deterministic smoothing, numeric transitions, and priority-based temporary overrides. The audio subsystem validates and expands declared graphs without touching an `AudioContext`, instantiates them deterministically from the seeded stream, and realizes them through Web Audio; the application exposes gesture unlock, master volume, per-bus gain, and per-sound triggering. `exhibits/minimal-audio.xzbt` exercises components, modulation, buses, and both recipe modes.
 
-The Phase 3c contract (section 16) specifies automation, the lifecycle state machine, determinable one-shot endings, voice ceilings, master protection, and unlock behavior, but the runtime does not implement it yet: `automation` and `release` are still rejected as unknown fields. No sound has yet been heard from a build, and the audio acceptance challenge, peak and finite-sample capture, and listening observations remain open Phase 3 gates. Visuals, cadence, events, scenarios, and the final schema-driven UI remain assigned to later phases.
+The runtime implements recipe `release`, the seven-state lifecycle, determinable one-shot endings, voice ceilings, and graph-local `automation`. Tracks support `absolute`, `offset`, and `scale`, with `step`, `linear`, `exponential`, and `smooth` interpolation. Values are sampled once from the owning sound's seeded stream; duplicate targets and expanded limits are validated. Exposed component parameters participate without exposing component internals. Bus gains now use the shared binding → automation → override → modulation → clamp resolver. Bus automation/modulation registration is internal: the contract does not add document fields to buses or permit external node bindings/overrides.
+
+Master protection is still the placeholder chain. No sound has yet been heard from a production build; measured protection, the audio acceptance challenge, real GC4 synchronization, peak/finite-sample capture, and listening observations remain open Phase 3 gates. Visuals, cadence, events, scenarios, and the final schema-driven UI remain assigned to later phases.
 
 ## Local development server