XZBT

Labyricorn — Fri, 04 Sep 2026 00:00:00 +0000

XZBT is being built around a simple distinction: the runtime knows how; the exhibit defines what. A self-contained XZBT.html will interpret declarative .xzbt JSON exhibits to create procedural visuals, soundscapes, and evolving audiovisual performances without exhibit-authored JavaScript.

The intended experience is to open the HTML directly in a desktop Chromium browser, import exhibits, and run them offline. Parameters, state, audio and visual primitives, events, cadence, and scenarios will provide reusable building blocks for very different exhibits. The engine is intended to stay independent of any particular theme.

The MVP requirements and seven gap-closure decisions are documented. Implementation currently consists of a disposable Phase 0 feasibility probe and two minimal fixtures, Amber Study and Blue Study. This is an experiment in browser capabilities, not the production runtime or a completed MVP.

Manual Chrome testing has demonstrated ordinary import, exhibit selection, saved settings restored after a browser restart, native audio, embedded data-URL AudioWorklet loading, offline operation, and continued session operation during injected storage failures. Renamed and relocated copies also restored data in the tested environment; that behavior is not a general browser compatibility guarantee.

Development is stalled in Phase 0 at the GC1 feasibility gate. Directory-permission-denial or API-unavailability fallback remains unverified. Shared format contracts, semantic traces, and milestone preparation are also unfinished. Phase 1 and every subsequent implementation phase have not started. Performance benchmarks and the required development and release soaks remain future work.

The project repository contains the product requirements and planning baseline. The initial development log links the planning baseline and the subsequent probe and manual-evidence commit separately.

Establishing XZBT and testing direct-file feasibility

Labyricorn — Fri, 04 Sep 2026 00:00:00 +0000

XZBT began with a declarative audiovisual runtime proposal: one generic XZBT.html supplies capabilities, while .xzbt exhibits define the experience. The first milestone was to turn that vision into an MVP requirements document, explicit gap-closure decisions, a partial format specification, and verification gates.

The planning baseline was committed on September 4, 2026. The entry date follows the Phase 0 evidence commit's local calendar date. The later manual captures have September 5 UTC timestamps, still September 4 in the project's America/Los_Angeles time zone.

What exists now

A disposable Phase 0 probe exercises direct-file import, IndexedDB caching, settings, user-initiated audio, worklet packaging, and storage-failure handling. Amber Study and Blue Study are minimal import fixtures. The probe has its own database and no authored network requests. It is not the XZBT runtime and does not constitute Phase 1.

The Phase 0 evidence commit contains the probe, regression tests, and manual evidence described here. Results are recorded in docs/evidence/phase0, with the current stop and checklist in docs/IMPLEMENTATION_STATUS.md and docs/XZBT_0-1_Verification_Gates.md. This entry references that implementation and evidence revision; the planning baseline remains linked separately.

Browser investigation

The agent's browser tool rejected navigation to the local HTML under its URL policy. That prevented automated direct-file testing; it was not a failure of the runtime design. No security-policy workaround was used. The user performed the browser checks manually in regular, non-Incognito Chrome 152 on Windows.

Probe versions 1 and 2 failed to load an engine-owned Blob-URL AudioWorklet module with AbortError. Version 2 separated the tone test from worklet loading and improved diagnostics, confirming that native audio still worked. Version 3 embedded the same fixed processor through a data URL. The user then observed successful module loading, node construction, and connection. That packaging issue is resolved in the tested environment.

Testing completed so far

Check	Observed result
Ordinary file import and selection	The user confirmed importing both fixtures through the ordinary file input and selecting each worked.
Directory import	Completed successfully in the manual storage-failure run.
IndexedDB persistence	Both definitions, selection, activity settings, and master volume were saved and restored.
Full browser restart	Following the full-exit procedure, Blue Study activity restored to 0.37 and volume to 0.19 with zero new saves. Earlier reload-only captures remain classified separately.
Native audio	User-initiated tone was heard; tone nodes disconnected after completion. AudioContext suspend and resume states were observed. The captured sample rate was 48,000 Hz.
Embedded worklet	Version 3 loaded and connected its engine-owned data-URL processor without reported errors.
Renamed and relocated copies	The user confirmed both copies restored exhibits and settings before further import or edits. This does not guarantee portability between browsers or profiles.
Injected storage failure	Sixteen expected injected save errors occurred while activity changed in memory and directory import remained usable. The user heard the tone and confirmed the session-only warning. No successful saves occurred during that run.
Offline operation	Restoration, heard tone, and worklet loading succeeded. The user explicitly confirmed browser-scoped Offline mode was enabled throughout the run.
Static and stubbed checks	Probe JavaScript and fixture JSON parsed. Three Node regression tests passed using stubbed browser/audio APIs; these are not browser acceptance tests.

The offline capture used a Pixel 9 mobile user-agent string while reporting Win32 and the original Windows file path. It is consistent with device emulation, not evidence from a physical Android device. Its onlineFlag remained true; the offline result rests on the user's explicit developer-tool setting confirmation, not on that flag or the count of authored requests.

Injected write failure verifies the application's session fallback. It does not establish behavior under actual browser permission denial or real quota exhaustion. A silent worklet loading successfully also does not establish production audio quality, timing, or output protection.

Where Phase 0 is stalled

Phase 0 remains incomplete at GC1. The outstanding browser check is ordinary-picker fallback when directory access is actually denied or the directory API is unavailable. Successful directory import and successful ordinary import were observed separately; neither demonstrates that conditional failure path. Remembered source handles are optional and are not implemented in this probe.

After that evidence is obtained, Phase 0 still needs shared document/value/reference and ownership contracts, precise resolution and clock behavior, expected semantic traces, and milestone preparation. The format specification is deliberately marked partial. Passing GC1 alone will not complete Phase 0.

Phase 1, the runtime skeleton, has not started. Neither have Phases 2 through 9. There is no completed production schema, integrated audiovisual runtime, reference benchmark, or soak result. The two-hour development soak and eight-hour release soak remain later acceptance requirements.