docs: establish XZBT 0.1 MVP planning baseline

.env.example

@@ -0,0 +1,3 @@
+repo=https://git.labyricorn.com/Labyricorn/XZBT
+user=your-username
+pass=your-access-token

.gitignore

@@ -0,0 +1,4 @@
+# Local repository configuration and credentials
+.env
+.env.*
+!.env.example

README.md

@@ -1,3 +1,32 @@
 # XZBT
 
 Immersive visuals and creative soundscapes.
+
+XZBT is a self-contained browser runtime for declarative procedural audiovisual exhibits. `XZBT.html` provides capabilities; `.xzbt` documents define experiences.
+
+## Reading order and authority
+
+| Resource | Purpose | Status |
+| --- | --- | --- |
+| [MVP Product Requirements Document](XZBT_0-1_MVP_Product_Requirements_Document.md) | Product scope, user behavior, delivery requirements, and release acceptance | Document revision 0.2; format version remains 0.1 |
+| [Format Specification 0.1](docs/XZBT_0-1_Format_Specification.md) | Runtime semantics, contract inventory, and required authoring examples | Partial specification; identified contracts still require completion |
+| [Gap Closure Decisions](docs/XZBT_0-1_Gap_Closure_Decisions.md) | Decisions and rationale for the seven pre-implementation gaps | Decisions incorporated for planning; feasibility is not yet verified |
+| [Verification Gates](docs/XZBT_0-1_Verification_Gates.md) | Evidence required before architecture commitment, subsystem work, and release | All checks pending; no implementation results 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.
+
+The earlier ChatGPT discussion, **Discuss Application Vision** (conversation `6a9b5c32-1ffc-83e8-a219-fa8113167f03`), is historical design input. Its proposals must be reconciled into these local resources before they become implementation contracts. It is not a second source of executable instructions.
+
+## Planning entry point
+
+Begin the implementation plan with Phase 0 from the verification gates. Complete the launch-model prototype and shared semantic contracts before committing dependent architecture and detailed estimates. Carry workload measurements and release soak tests as later explicit gates; they are not prerequisites for drafting a plan.
+
+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.
+
+No runtime, schema implementation, benchmark, or completed feasibility test is supplied by this documentation revision.
+
+## Repository configuration
+
+Copy `.env.example` to `.env` for local repository configuration. `.env` and its variants are ignored by Git; never commit real credentials. The example contains placeholders only.
+
+The repository's existing [LICENSE](LICENSE) is preserved.

docs/XZBT_0-1_Format_Specification.md

@@ -0,0 +1,104 @@
+# XZBT Format Specification 0.1
+
+**XZBT format version:** 0.1  
+**Document revision:** 0.1  
+**Status:** Partial normative specification; contract completion required before dependent implementation  
+**Related resources:** [PRD](../XZBT_0-1_MVP_Product_Requirements_Document.md), [decisions](XZBT_0-1_Gap_Closure_Decisions.md), [verification](XZBT_0-1_Verification_Gates.md)
+
+This document defines shared semantic decisions and tracks the contracts still needed to implement the PRD. Existing PRD examples remain design inputs; a list of supported feature names is not a complete JSON grammar. No validator or complete JSON Schema has yet been produced.
+
+## 1. Format foundation
+
+Documents are UTF-8 JSON with `xzbt: "0.1"`, `meta.id`, and `meta.name` required. Unsupported format versions fail activation. Exhibit version and format version are separate. IDs use `^[a-z][a-z0-9_-]*$`; dots delimit reference paths.
+
+The following is a complete minimal exhibit. An exhibit that performs no audio or visual work is valid:
+
+```json
+{
+  "xzbt": "0.1",
+  "meta": {
+    "id": "empty-study",
+    "name": "Empty Study"
+  }
+}
+```
+
+Validate structure before activating resources. Follow structural validation with type, reference, graph, ownership, and resource-limit checks. Unknown fields in behavior-bearing objects are errors. Do not coerce strings to numbers or silently invent semantics for unsupported constructs.
+
+A structurally valid minimal exhibit does not prove expressive capability. Complete audiovisual examples and invalid fixtures remain required under GC2.
+
+## 2. Shared value resolution
+
+For each supported target, evaluate:
+
+```text
+base -> binding -> automation -> winning override -> modulation -> safety clamp
+```
+
+Skip stages not exposed by the target contract. A target cannot accept automation or modulation merely because it is numeric. Additive modulation is summed only where explicitly supported.
+
+Parameters store user configuration separately from exhibit defaults. State stores simulation values separately from parameters. A property may obtain its base through ValueSpec. State is not an implicit layer overwriting every parameter.
+
+References ordinarily read resolved values. Parameter controls read and edit stored user values, and display an override indicator when appropriate. Underlying bindings and automation continue to evaluate while masked by an override.
+
+Override lifetime and priority are independent. Use explicit priority when supported, otherwise inherit the originating scenario's priority; equal priorities resolve by activation order. Duration scope confers no additional priority. The complete action contract must define non-scenario default priority, permitted explicit priority fields, and ordering identifiers before implementation.
+
+On release, blend toward the current lower resolved value rather than a snapshot taken when the override started. User edits and changing bindings remain visible to that lower evaluation. Numeric release interpolation, interruptions by another override, and nonnumeric release behavior require exact contracts below.
+
+Reject conflicting ordinary bindings and dependency cycles that cannot be evaluated under documented semantics. Do not introduce an implicit previous-frame delay to make a cycle appear legal.
+
+### Required resolution examples
+
+| Case | Expected behavior |
+| --- | --- |
+| Bus gain is bound to activity, then directly overridden | The override supplies the pre-modulation value until release; the binding continues underneath |
+| Activity is overridden and referenced by a binding | The binding observes resolved activity |
+| User edits stored activity while its override is active | The stored edit persists; release approaches the updated lower value |
+| Two overrides compete | Higher priority wins; equal priority uses activation order |
+| Duration and scenario overrides compete | Priority and activation order decide, not scope |
+| A target has legal additive modulation | Modulation follows the winning override, then the safety clamp applies |
+
+## 3. Time and random evaluation
+
+The initial logical simulation step is 1/60 second. Rendering does not own simulation time. Audio scheduling maps logical time to the audio clock with a bounded horizon.
+
+Application pause and document visibility loss suspend logical progression and audio. Resume continues the same logical performance without a wall-clock catch-up burst. Visibility resume does not clear a user pause. Audio unlock does not replay expired sound invocations.
+
+Random and weighted-choice ValueSpecs are sampled at the containing object's documented instantiation or invocation boundary, not every render frame. Evolving randomness belongs to modulators. Nested ValueSpec evaluation boundaries and random time sampling must be specified per construct.
+
+Separate random streams isolate cadence, scenario instances, visual systems, sound instances, and manual sampling. Reproducibility is scoped to a runtime version, recorded numeric seed, and logical input sequence. Tests that use external or analysed signals must supply deterministic input traces.
+
+## 4. Ownership and termination
+
+Ownership propagates through nested events and actions. Scenario resources inherit the scenario owner unless the resource type allows an explicit persistent owner. Scenario-created duration overrides cannot outlive the owner, apart from their bounded release cleanup.
+
+Persistent `set` changes survive scenario failure. Termination cancels future work and guarantees cleanup, including when a termination hook fails. Release work transfers to a bounded cleanup owner and ultimately disposes all temporary resources.
+
+Condition triggers require a false condition before rearming after a successful firing. Each scenario definition may hold at most one deferred start request. Requests expire and recheck eligibility when dispatched. Exact timeout and ordering contracts remain required.
+
+Statically check event/scenario feedback where possible and bound runtime dispatch. Resource cleanup must remain possible after the ordinary dispatch budget is exhausted.
+
+## 5. Contract completion register
+
+All rows below require work; none claims a completed implementation. Complete shared contracts before implementing dependent subsystems. Use PRD section numbers as stable lookup references.
+
+| Contract | Existing PRD input | Required completion |
+| --- | --- | --- |
+| Document/schema | 9-14, 113-116, 121 | All structural shapes, unknown-field policy, metadata extensions, size/depth limits, diagnostic paths, full internal schema |
+| Values and conditions | 15-21, 33 | Operator arity and types, numerical errors, array/object literals, live versus sampled fields, seed algorithm and stream derivation |
+| References and bindings | 13, 17, 31-32 | Target-capability table, instance/input scope, evaluation order, cycles, disabled bindings, exact smoothing |
+| Actions and transitions | 22-30 | Fields and defaults per action, override priorities outside scenarios, target/command matrix, interrupted transitions, instance IDs |
+| Audio | 34-60 | Complete recipe/component shapes, node defaults, automation timing, clamp implementation, one-shot endings and tails, unlock behavior, master protection contract |
+| Cadence | 61-68 | Exact selection/cooldown/overlap fields, clocks, pool collisions, pending audio, manual sampling isolation and continuous-sample termination |
+| Visuals | 69-89 | Primitive/system/behavior fields, angle and motion units, transform order, depth projection, field behavior, morph compatibility, effect approximation and limits |
+| Events/scenarios | 90-102 | Trigger shapes, hooks and failure ordering, scope inheritance, deferred ordering/expiry, relative/repeated timeline semantics and termination boundaries |
+| Generated UI | 103-107 | Widget compatibility, button actions, parameter validation and override display, group/control ordering |
+| Runtime/library | 108-112, 117-127 | Clock/audio synchronization and stalls, import equality, update compatibility, transactions, failure recovery, persistence schema |
+
+## 6. Contract template and conformance artifacts
+
+Each construct must record its JSON shape; required and optional fields; types, units, ranges, and defaults; supported ValueSpec fields and evaluation timing; read/write namespaces; lifecycle and ownership; precedence; validation errors; runtime failure behavior; and resource costs or limits.
+
+Supply a valid minimal example, a meaningful composition example, invalid cases with expected diagnostics, and expected semantic traces where timing or ordering matters. Two contrasting complete exhibits must exercise parameters, sound, visuals, and a temporary scenario override early in development.
+
+Structural JSON Schema does not replace semantic validation. The internal schema and fixtures belong to 0.1 implementation work; public schema distribution and editor integration may follow later.

docs/XZBT_0-1_Gap_Closure_Decisions.md

@@ -0,0 +1,109 @@
+# XZBT 0.1 Gap Closure Decisions
+
+**Record version:** 0.1  
+**Status:** Incorporated into the planning baseline; implementation verification pending  
+**Related resources:** [PRD](../XZBT_0-1_MVP_Product_Requirements_Document.md), [format specification](XZBT_0-1_Format_Specification.md), [verification gates](XZBT_0-1_Verification_Gates.md)
+
+Numbering preserves the seven gaps discussed during PRD preparation. Recording a decision closes a design question; it does not establish that a browser feature, performance target, or lifecycle guarantee has passed testing.
+
+| Gap | Primary PRD placement | Supporting verification |
+| --- | --- | --- |
+| 1 | 3.4, 109-111, 122, 132, Phase 0 | GC1 |
+| 2 | Resource preface, 113, Phase 0, 145-146 | GC2 |
+| 3 | 31-32, 54, 104 | GC3 |
+| 4 | 14, 102, 117-118 | GC4 |
+| 5 | 91, 94, 99-101 | GC5 |
+| 6 | 58, 119-120, 133, 144 | GC6 |
+| 7 | 108-110, 126-128, 134-135, 143-145 | GC7 |
+
+## 1. Standalone HTML deployment model
+
+**Decision:** Opening `XZBT.html` directly in a desktop Chromium browser is the primary 0.1 launch method. The distributed application needs no server, installation, or network connection. Development tooling may use a local server, but it cannot substitute for testing the delivered file directly.
+
+Use IndexedDB for the exhibit cache and saved configuration. Always provide ordinary file-picker import. Directory import and remembered source handles are optional enhancements where available. A source handle is not the startup dependency: cached definitions are.
+
+Verify file import, audio unlock, cache writes, browser restart, and cache restoration in the actual target environment. If the selected audio implementation needs AudioWorklet, verify loading engine-owned worklet code from the self-contained artifact. Exhibit-authored executable code remains prohibited.
+
+Moving or renaming the HTML is a separate compatibility case. Do not promise that browser storage follows it. When storage is unavailable, retain session playback and explain that exhibits must be imported again on a later launch. This fallback does not waive the ordinary-mode persistence acceptance requirement.
+
+**Gate:** GC1 in the verification checklist. A failure of direct-file persistence in the chosen supported environment reopens the deployment decision; do not silently replace the distribution promise with hosted-only operation.
+
+**Basis:** [MDN file-origin behavior](https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Same-origin_policy#file_origins), [Chrome File System Access API](https://developer.chrome.com/docs/capabilities/web-apis/file-system-access), and [AudioWorklet requirements](https://developer.mozilla.org/en-US/docs/Web/API/AudioWorklet). These describe platform constraints, not evidence that the XZBT prototype has passed.
+
+## 2. One authoritative format specification
+
+**Decision:** Separate product requirements from exact authoring contracts. Maintain the companion Format Specification 0.1 and an internal structural JSON Schema, with additional semantic validation for references, graph legality, ownership, and limits.
+
+For each exposed construct, specify JSON shape, required fields, defaults, units, ranges, ValueSpec support and evaluation timing, readable/writable targets, lifecycle, errors, and examples. Reject unknown fields in behavior-bearing objects. Define any allowed metadata extensions explicitly rather than permitting arbitrary executable-looking configuration.
+
+Complete valid exhibits and invalid fixtures are required alongside each contract. Reconcile relevant details from the earlier discussion into the local specification. The current format document is a foundation and completeness register, not a claim that all grammar has been formalized.
+
+**Gate:** GC2. Exact shared contracts precede their implementations; remaining subsystem contracts may be completed in dependency order. Publishing the schema and editor autocomplete remain optional post-MVP work. Maintaining an internal schema is required for 0.1.
+
+## 3. Bindings, overrides, and automation
+
+**Decision:** Resolve each target through base value, binding, automation, winning override, modulation, and safety clamp, using only stages supported by that target. Parameters and state have separate storage; state is not a universal layer above user configuration.
+
+References ordinarily read resolved values. Configuration controls read and edit the user's stored parameter value and indicate an active override. Underlying bindings and automation continue evaluating while masked.
+
+Override scope controls lifetime; explicit or inherited priority controls precedence. Equal priorities use activation order. Duration overrides do not automatically outrank scenario overrides. Release transitions approach the currently resolved underlying value, including changes made while masked. Additive modulation may remain after an override only on targets whose contracts permit it.
+
+Reject competing ordinary bindings and unresolvable dependency cycles. The format specification must finish the target-capability and transition rules before the resolver is implemented.
+
+**Gate:** GC3. Expected traces cover direct target overrides, parameter overrides flowing through bindings, overlapping priorities, user edits, and release behavior.
+
+## 4. Clock and reproducibility
+
+**Decision:** Use a logical simulation clock with an initial fixed update step of 1/60 second. Rendering is independent. Map logical audio scheduling to the audio clock with a bounded scheduling horizon; the exact horizon and late-work policy require prototype measurements and a written contract.
+
+In 0.1, document visibility loss pauses the entire performance by default, including audio. Explicit application pause does the same. Resume from the previous logical position without replaying elapsed wall-clock time. Visibility return must not undo an explicit user pause. Background playback is a separately specified future capability.
+
+Visuals may start before audio is unlocked, as permitted by the PRD. On unlock, begin audio at the current logical position without replaying expired sounds; the format contract must specify how continuous ambience and partially elapsed sounds initialize.
+
+Derive isolated random streams from the exhibit seed for cadence, scenarios, visual systems, and sound instances. Manual SAMPLE playback has an independent stream. Record the actual numeric seed when the exhibit requests a random seed.
+
+Reproducibility means identical procedural decisions for the same runtime version, seed, and logical input sequence. It does not promise identical pixels or audio samples across devices. Deterministic tests use recorded or synthetic audio-analysis signals where such signals affect decisions.
+
+**Gate:** GC4. Render frequency, pause duration, and independent sound sampling must not perturb unrelated logical choices.
+
+**Basis:** [MDN Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) documents background frame/timer behavior. This decision supplies XZBT's product policy rather than relying on browser throttling as its scheduler.
+
+## 5. Scenario ownership and failure
+
+**Decision:** Propagate ownership through action execution and nested events. Indirectly created resources inherit the originating scenario unless a resource contract explicitly permits persistent ownership and the exhibit requests it.
+
+A duration override created under a scenario expires at its deadline or when the owner terminates, whichever happens first. State mutations are persistent and are not rolled back after completion, cancellation, or failure. Failure cleanup removes temporary effects; scenarios are not transactions.
+
+On termination, stop ordinary dispatch, cancel future work, run the applicable termination hook, and guarantee cleanup even when the hook fails. Bounded release fades may continue under a cleanup owner until final disposal. Hook execution order and permitted hook actions must be finalized in the format specification; no new failure-hook field is introduced by this record.
+
+Condition triggers fire once after the qualifying condition has held for the declared interval, then require a false condition before rearming. A scenario definition has at most one pending deferred request, with an expiry and an eligibility recheck at dispatch. Exact queue ordering and default expiry must be specified before implementation.
+
+Validate event/scenario trigger cycles where statically detectable. Enforce a per-update dispatch budget as a runtime backstop, with a visible diagnostic when exhausted. Cleanup must still run when ordinary dispatch is curtailed.
+
+**Gate:** GC5. Repeated completion, cancellation, and injected failures return resource counts to the expected baseline after bounded releases finish.
+
+## 6. Performance and audio acceptance
+
+**Decision:** Record a real reference computer, OS, browser version, device-pixel ratio, audio sample rate, and a 1920 x 1080 test viewport. Fix a benchmark exhibit combining particles, links, trails, post-processing, and overlapping procedural audio.
+
+Target 60 FPS. Use a provisional acceptance threshold of a 95th-percentile frame interval below 33.3 ms under the recorded benchmark workload. This is a reference-workload target, not a guarantee for every valid exhibit or device. Measure the workload before fixing final supported ceilings; do not silently reduce the workload between comparisons.
+
+Expose resource counters for nodes, voices, visual instances, subscriptions, and scheduler records. Repeated lifecycle tests must return to expected baseline after releases and queued disposal finish. Retained memory must plateau after warm-up; record sampling method and investigate sustained growth rather than treating a transient allocation peak as a leak.
+
+Require a two-hour development soak and an eight-hour release soak. Accelerated logical-time tests supplement, but do not replace, real-duration runs.
+
+Specify master protection as a tested output stage with finite samples, a defined digital peak ceiling, controlled release, and no bypass. The exact ceiling, tolerances, and release settings must be recorded before audio acceptance. Test worst-case overlapping recipes and listen for clicks and distortion. A digital peak ceiling is not a guarantee of physical listening volume.
+
+**Gate:** GC6. Early combined-load measurements inform architecture and limits; full benchmark acceptance and soak results are release gates.
+
+## 7. Release scope and library updates
+
+**Decision:** Preserve all PRD MVP completion criteria. Early integrated demonstrations are milestones, not a reduced definition of the finished MVP. Develop contrasting reference exhibits alongside supporting engine capabilities. Phase 9 completes and audits the suite.
+
+Identical imports are no-ops. Changed content with an existing exhibit ID requires an explicit replacement choice. Invalid source refreshes preserve the last valid definition and compatible settings. Compatible numeric preferences are clamped to changed bounds with notice; incompatible preferences revert to declared defaults. Removed parameters are discarded and new ones receive defaults. Define exact compatibility and content-equality rules before persistence implementation.
+
+Validate and prepare a replacement exhibit before stopping the working one. Preparation must not start audible or visible activity. If activation subsequently fails, dispose of the failed candidate and attempt to restart the previous exhibit with its saved configuration. A restarted exhibit is a fresh performance, not restoration of its prior scenario clock. Report failure if recovery also fails.
+
+Develop separate source modules and build them into a reproducible, self-contained `XZBT.html`. No runtime module, asset, font, or CDN dependency may be required outside the delivered file. Single-file distribution does not require single-file development.
+
+**Gate:** GC7. The implementation plan identifies integrated milestones, safe update paths, reference-exhibit coverage, and the single-file build check.

docs/XZBT_0-1_Verification_Gates.md

@@ -0,0 +1,123 @@
+# XZBT 0.1 Verification Gates
+
+**Status:** Planning checklist; every check is pending  
+**Related resources:** [PRD](../XZBT_0-1_MVP_Product_Requirements_Document.md), [decisions](XZBT_0-1_Gap_Closure_Decisions.md), [format specification](XZBT_0-1_Format_Specification.md)
+
+No tests, browser prototypes, benchmark results, or soak results have been run as part of the gap-closure documentation. Mark a check complete only with linked evidence. A recorded design decision is not a passing test.
+
+## Phase 0 and later gates
+
+Drafting the implementation plan may proceed now. Before committing the deployment architecture, pass GC1. Before implementing shared runtime semantics, complete the shared portions of GC2 and GC3-GC5 contracts and their expected traces. Early GC6 measurements inform expensive subsystem design. Full conformance and real-duration soak results remain release requirements.
+
+Subsystem-specific format details can be completed in dependency order as planned tasks. Do not require the finished engine or eight-hour soak before creating the plan.
+
+| Gap | Decision | Evidence status | Gate placement |
+| --- | --- | --- | --- |
+| GC1 | Recorded | Not run | Phase 0, before deployment architecture commitment |
+| GC2 | Recorded; format draft partial | Contracts and fixtures incomplete | Shared contracts in Phase 0; subsystem contracts before their implementation |
+| GC3 | Recorded; transition details open | Traces and tests pending | Shared resolver contract before Phase 2; tests with implementation |
+| GC4 | Recorded; audio mapping details open | Prototype and tests pending | Clock contract in Phase 0; synchronization tests in audio integration |
+| GC5 | Recorded; hook/queue details open | Traces and tests pending | Ownership contract before actions/audio; full tests with scenarios |
+| GC6 | Recorded; thresholds provisional | Reference setup and benchmark absent | Early combined-load prototype; development and release acceptance |
+| GC7 | Recorded | Plan/build/library checks pending | Milestone planning, then library/build integration |
+
+## 1. GC1: Direct-file feasibility
+
+- [ ] Record OS, browser version/profile, launch path, and storage mode.
+- [ ] Open the artifact directly from disk with network unavailable.
+- [ ] Import two exhibits with the ordinary file picker and activate each.
+- [ ] Save exhibit definitions, per-exhibit parameters, selection, and master volume to IndexedDB.
+- [ ] Close the browser fully, reopen the same HTML, and restore the cached library and settings without selecting source files again.
+- [ ] Verify user-initiated audio unlock and resumed playback.
+- [ ] If needed by the audio design, load engine-owned AudioWorklet code from the single-file artifact. Otherwise document why this check is not applicable.
+- [ ] Test renamed and moved HTML files; record observed storage behavior and the support boundary.
+- [ ] Test unavailable/failed storage; session playback works and the UI explains lack of persistence.
+- [ ] Test directory import/remembered handles where available and ordinary-picker fallback where unavailable or permission is denied.
+
+**Evidence:** prototype artifact, reproducible steps, environment record, observed results. If ordinary-mode persistence fails, reopen decision 1 before dependent architecture commitment.
+
+## 2. GC2: Format contract completeness
+
+- [ ] Complete shared document, type, reference, ValueSpec, ConditionSpec, time, and ownership contracts.
+- [ ] Fill the format-specification contract register in subsystem dependency order.
+- [ ] Implement an internal structural schema plus separate semantic validation.
+- [ ] Provide complete valid and invalid fixtures with expected diagnostics.
+- [ ] Reject unsupported versions, unknown behavior fields, invalid reference types, recursive components, illegal graph cycles, and excessive resources.
+- [ ] Produce two contrasting complete audiovisual exhibits early; expand toward all PRD challenge cases.
+- [ ] Reconcile prior conversation proposals into the local documents; resolve conflicts explicitly.
+
+**Evidence:** versioned specification/schema/fixtures and validation results. Naming a node or behavior does not close its contract.
+
+## 3. GC3: Resolution semantics
+
+- [ ] Record exact target capabilities, override defaults, smoothing, and interrupted transition rules.
+- [ ] Define expected traces for a bound bus gain receiving a direct override.
+- [ ] Define expected traces for a parameter override feeding a binding.
+- [ ] Verify stored user edits during masking and release toward the updated lower value.
+- [ ] Verify priority ties and competing duration/scenario overrides.
+- [ ] Verify automation continues while masked and permitted modulation applies after an override.
+- [ ] Verify numeric clamps and unsupported target/stage diagnostics.
+- [ ] Reject conflicting bindings and dependency cycles without introducing undocumented delays.
+
+**Evidence:** contract examples and deterministic resolver tests when implemented.
+
+## 4. GC4: Time and reproducibility
+
+- [ ] Define logical tick ordering, maximum work per turn, long-stall behavior, audio lookahead, and audio unlock alignment.
+- [ ] Define PRNG algorithm, seed normalization, and stream derivation for the runtime version.
+- [ ] Compare simulation traces at different render frequencies using the same logical inputs.
+- [ ] Hide/restore the document and explicitly pause/resume; no missed wall-clock work is replayed.
+- [ ] Verify visibility restoration does not undo an explicit pause.
+- [ ] Verify audio suspends/resumes consistently and expired pre-unlock one-shots are not replayed.
+- [ ] Verify manual SAMPLE does not perturb cadence/scenario random streams.
+- [ ] Use deterministic signal fixtures for audio-reactive decision tests.
+- [ ] Distinguish accelerated logical tests from real-time audio behavior and soak tests.
+
+**Evidence:** clock/PRNG contract, logical traces, and browser/audio observations. No cross-device pixel or waveform equality claim is required.
+
+## 5. GC5: Ownership and failure
+
+- [ ] Define hook ordering, allowed hook actions, failure propagation, cleanup deadlines, deferred expiry/order, and dispatch-budget behavior.
+- [ ] Start resources through nested events and confirm inherited scenario ownership.
+- [ ] Verify duration overrides terminate with their owner and bounded releases eventually dispose.
+- [ ] Verify persistent state mutations survive a later critical failure.
+- [ ] Inject failures into startup, ordinary actions, and termination hooks; cleanup still completes.
+- [ ] Verify condition triggers require a false condition before rearming.
+- [ ] Verify at most one pending deferred request per definition, expiry, and eligibility recheck.
+- [ ] Exercise event/scenario feedback and show bounded dispatch with diagnostics.
+- [ ] Repeat completion/cancellation/failure cycles; counters return to baseline after releases finish.
+
+**Evidence:** lifecycle traces, resource-count samples, and failure-injection results.
+
+## 6. GC6: Performance and audio acceptance
+
+- [ ] Record CPU/GPU/RAM, OS, browser version, 1920 x 1080 viewport, device-pixel ratio, sample rate, and relevant power settings.
+- [ ] Fix benchmark exhibit/version/seed and counts for particles, links, trails, effect passes, audio nodes, and concurrent voices.
+- [ ] Prototype combined visual/audio load early and record supported limits.
+- [ ] Define warm-up duration, measurement window, frame interval sampling, and retained-memory sampling method before collecting acceptance data.
+- [ ] Check the provisional p95 frame interval threshold of less than 33.3 ms and report progress toward the 60 FPS target.
+- [ ] Record active resource baselines and verify expected return after repeated lifecycle operations.
+- [ ] Specify and test digital output peak ceiling, numerical tolerance, finite samples, release behavior, and unavoidable master routing.
+- [ ] Stress overlapping recipes and listen for clicks, clipping, and objectionable release artifacts.
+- [ ] Run a two-hour development soak and an eight-hour release soak; record retained-memory trends, resource counts, frame intervals, audio glitches, and scheduler growth.
+
+**Evidence:** fixed workload, environment, measurement method, results, and investigated anomalies. Any threshold revision must be recorded before rerunning acceptance; do not silently change the benchmark to produce a pass.
+
+## 7. GC7: Scope, updates, and build
+
+- [ ] Map all PRD completion criteria and challenge cases to milestones and evidence.
+- [ ] Integrate two contrasting exhibits early; make Phase 9 the completion/audit phase for all five reference exhibits.
+- [ ] Define import equality and parameter compatibility precisely.
+- [ ] Verify identical imports are no-ops and changed same-ID content requires an explicit replacement choice.
+- [ ] Verify invalid refreshes leave the last valid definition and configuration intact.
+- [ ] Verify compatible parameter preservation, numeric bound changes with notice, removed/new parameters, and incompatible-type/enum resets.
+- [ ] Validate and prepare a candidate without observable playback before stopping the working exhibit.
+- [ ] Inject activation failure; dispose of the candidate and attempt a fresh restart of the previous exhibit with saved settings.
+- [ ] Build separate source modules into one self-contained HTML artifact reproducibly.
+- [ ] Test the delivered artifact directly and offline; no external runtime scripts, modules, assets, fonts, or CDN requests are required.
+
+**Evidence:** implementation-plan coverage, library failure tests, build instructions, and artifact verification.
+
+## Evidence record template
+
+For each result, record gate/check ID, date, specification revision, implementation revision or artifact hash, environment, fixture/seed, procedure, expected result, actual result, pass/fail/not-applicable status, linked logs or measurements, and unresolved limitations. A not-applicable result requires a reason. Do not prefill results from intended behavior.