feat(audio): implement phase 3c master protection

README.md

@@ -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 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.
+Phase 0 is complete, and the production runtime is implemented through Phase 3c slice 4 (master protection), with 102 automated tests passing. Slice 4's hardware measurement and listening acceptance remain pending; the [standalone audio acceptance page](prototypes/phase3/XZBT-audio-acceptance.html) and [run instructions](prototypes/phase3/README.md) are ready for user testing. The Phase 1 direct-file two-fixture restart and Phase 3 audible acceptance remain open — no sound has been heard from a production build. Combined 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 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.
+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 adds the remaining audio contract, lifecycle/voice management, automation and master protection. Measured protection acceptance, visual, cadence, scenario, UI, library-hardening, benchmark, and soak gates remain explicit in the implementation plan.
 
 ## Repository configuration
 
@@ -71,7 +71,7 @@ The active performance supports typed parameters and state, read-only runtime si
 
 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.
+Master protection now uses an engine-owned AudioWorklet limiter with finite-sample guards and output measurement support. `npm run build:audio-acceptance` builds the self-contained hardware capture page using the production engine and frozen stress/challenge fixtures. No sound has yet been heard from a production build; real-browser measured protection, the audio acceptance challenge, real GC4 synchronization and listening observations remain open Phase 3 gates. See the [slice-4 evidence](docs/evidence/phase3/2026-09-05-phase3c-protection.md). Visuals, cadence, events, scenarios, and the final schema-driven UI remain assigned to later phases.
 
 ## Local development server