LabyricornandClaude Opus 5
0af58da89d
The first visual code that draws. Sections 17.4 through 17.14 are implemented against Format Specification revision 0.8, and the standalone artifact now has a stage canvas that renders a declared scene. The renderer is split so that the automated traces of 17.16 can run without a display, which is what those traces require. visual-engine.js resolves an exhibit's objects once at their instantiation boundary, composes the scene-to-device chain, sorts by depth, applies fog and the compositing order, and emits a **frame plan** in device pixels; visual-canvas2d.js turns a plan into drawing calls. A plan carries the numeric oracles the traces ask for - a known scene point at a known display point, a perspective factor, a fog fraction, a sort order - where a canvas carries only pixels. visual-math.js implements the affine matrices, the normative local transform of 17.11, the directed arc sweep of 17.9 with its bound checked before normalization, and section 2 color parsing with the fog and ramp arithmetic of 17.6 and 18.2. Colors outside the four documented forms are ERR_TYPE_MISMATCH: exact components are what make per-object fog renderer-independent. visual-geometry.js reduces all fourteen primitives to subpaths of lines and cubic Beziers, so an affine map carries geometry exactly rather than approximately. It implements the local extents and anchors of 17.9 - a rectangle anchored top-left, circular primitives centered - the uniform cardinal form of catmull-rom with its open-duplication and closed-wrap index rules, the straight closing segment of a closed bezier spline, and endpoint-parameterized elliptical arcs. The composition chain of 19.3 is implemented as written: the fit matrix carries the contain and cover centering offsets, the camera center is mapped into CSS coordinates before the translation is formed, perspective acts about the projection center, and the device-pixel multiplier is applied exactly once and drops below 1 on a display larger than 4096. Scalars with no axis - stroke widths, radii, dash lengths - take the single uniform factor g, so a nonuniform stretch never distorts a stroke. Depth follows 17.6: effective depth accumulates z and translate.z up the tree, sortable units order farthest-first with the documented tie-break, a point's own z projects that point without making it a sortable unit, and an object at or behind the eye is culled with no diagnostic. Compositing follows 17.12: opacity multiplies down the tree while layer opacity applies once at the layer, and the sixteen buffer allocations per frame are granted nearest-first so refusals fall on the far content, each diagnosed under the 19.5 cadence rather than omitted silently. visual-validation.js gains the object tree: the fifteen object types and their declared fields, no `id` and no `layer` on an object, a declared fill on a stroke-only primitive, a mask only on a group and only naming its own child, path legality, spline modes and point counts, gradient stop order, and every authoring limit of 19.5 that applies to a drawn object. While implementing V10 I corrected the buffer-accounting rule I had written into 17.12: counting buffers as concurrently live made 19.5's farthest-first shedding nearly unreachable, since group nesting is already capped at 8. The rule is now 16 allocations per frame, which is the per-frame reading "pass budget" has carried since 17.5 first used it. The arc-sweep prose is likewise corrected to normalize the signed delta, so 350 -> 10 clockwise is the 20-degree sweep the text always claimed rather than 340 the long way round. test/phase4-renderer.test.mjs adds 22 tests covering traces 1 through 13 of 17.16 plus buffer shedding and the backend's call order. npm test goes from 131 to 153 passing. Traces 15 and 16 remain user-observed, and no procedural system, automation track, or post-effect executes yet - 4e and 4f own those. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_0162Jb1J36judZNT8fHabGVt
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 | Product scope, user behavior, delivery requirements, and release acceptance | Document revision 0.3; format version remains 0.1 |
| Format Specification 0.1 | 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 | Decisions and rationale for the seven pre-implementation gaps | Record revision 0.3; GC1–GC5 Phase 0 evidence complete |
| Verification Gates | Evidence required before architecture commitment, subsystem work, and release | Phase 0 complete; later subsystem, GC6, and GC7 checks scheduled |
| Implementation status | 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 | 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.
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
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 and run instructions 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 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
The storage-failure evidence additionally confirms session settings changes, directory import, and heard native playback during injected write failures. The user also confirmed the visible session-only warning; the injected-storage-failure check passed.
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 is preserved.
Phase 1–2 runtime
Build the standalone, dependency-free runtime with the pinned Node version in .nvmrc:
npm run build
This deterministically combines the modules in src/runtime, the application shell, and local styles into XZBT.html. Open that file directly in a supported desktop Chromium browser, then import the three minimal exhibits from exhibits. Imported definitions and the last active exhibit are cached in IndexedDB and restored on reopen when browser storage is available. The diagnostics panel reports validation, lifecycle, and storage failures; storage failure leaves the current session usable.
Run the Phase 1 production-module, lifecycle, fixture, PRNG-vector, cache, and reproducible-build tests with:
npm run test:phase1
Run the Phase 2 common-grammar conformance suite with:
npm run test:phase2
Run the Phase 3 audio subsystem suite with:
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 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 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 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. Visuals, cadence, events, scenarios, and the final schema-driven UI remain assigned to later phases.
Local development server
For automated browser development checks, start the dependency-free loopback server with:
node tools/dev-server.mjs
It binds only to 127.0.0.1:5173 and serves the workspace through http://localhost:5173/; the root route opens the Phase 0 probe for layout or control-flow inspection only. Set XZBT_DEV_PORT to use a different port. This server is a development aid, not part of the delivered runtime.
Do not use localhost results as Phase 0 direct-file evidence. Serving changes the origin, security model, and module-loading path. The final XZBT.html must still be opened and tested directly from disk for every GC1 conclusion.