XZBT · Devlog
Establishing XZBT and testing direct-file feasibility
The planning baseline is committed, and manual browser tests have resolved the worklet-loading problem. Phase 0 remains stalled on conditional directory fallback evidence and unfinished shared contracts.
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.
Work stopped in accordance with the request to report problems before advancing. The next step is to obtain the remaining conditional fallback evidence, complete the Phase 0 contracts and traces, and then review the gate before beginning Phase 1. The resolved Blob-module failure does not need to be repeated unless relevant code changes.