Files
XZBT/docs/evidence/phase0/2026-09-04-user-run-v2.md
T

4.3 KiB

Phase 0 version 2 results and version 3 candidate fix

Result: Cache restored between loads; tone heard; suspend/resume observed; Blob worklet loading failed
Source: User-supplied version 2 JSON
Run started: 2026-09-05T02:26:04.668Z (September 4 in America/Los_Angeles)
Gate: GC1 remains incomplete; no advancement to Phase 1

Findings

Check Evidence Conclusion
Direct-file load protocol: "file:", secure context, Chrome 152 Observed in the user's browser
Restore on a later load restored: true, saves: 0, populated restoredAtLoad Both exhibits, Blue selection, and saved default parameter/volume values restored without a write in this run
Link to previous saved state savedAt: 2026-09-05T02:14:24.015Z Matches the preceding user-run save timestamp
Full browser restart No independent confirmation of process exit Still unverified; a later page load alone is insufficient
Distinctive edited settings Values remain at defaults Edited-value reconciliation/restoration is not demonstrated by this run
Native tone toneHeard: true, tone ended and nodes disconnected User confirms audible output
Suspend/resume suspendObserved: "suspended", resumeObserved: "running" AudioContext state changes observed
Worklet addModule rejected a blob:null/... URL while the context remained running Failure isolated to module loading; node construction was not reached
CSP Empty securityPolicyViolations list No page violation event captured; this does not prove absence of every browser restriction
Offline/directory/fault injection Online flag true; directory untested; injection false These checks remain pending

This run resolves the uncertainty about native audio output and demonstrates actual cache restoration between loads. It does not establish that all of GC1 passed.

Candidate module-loading correction

The combination of a local file: page, an opaque blob:null URL, and an addModule failure is consistent with a local Blob-module loading limitation. This remains a diagnosis to verify, not a proven universal restriction in Chrome 152.

The Recorder project's own implementation constructs a data:text/javascript;base64,... worklet module URL, with an explicit source comment explaining that some browsers reject local object URLs. This primary implementation informed the candidate fix; no Recorder dependency or code was imported into XZBT.

Probe version 3 encodes the same fixed ASCII processor source into a data: URL and passes it to the same audioWorklet.addModule() API. It replaces blob: with data: in the page's script-src allowlist. It does not disable CSP, add network sources, enable eval, change browser flags, or accept exhibit-authored executable modules. connect-src 'none' remains in effect. This changes application packaging, not the agent browser tool's URL policy; no blocked browser automation was attempted.

The probe's database and path remain unchanged. Attempt evidence now reports moduleURLScheme: "data:" and the fixed source size. Success would be reported as loaded from engine-owned data URL and connected; it must not be recorded until an actual user browser run reports it.

Version 3 artifact SHA-256: 97D6909953F1F22E5BF0CA8AD653605D57A078AB3CCDEDFA509C5E9B0C1A4B2A

Verification performed

Three Node control-flow regression tests passed using node --test prototypes/phase0/audio-probe.test.mjs. These use stubbed APIs. They cover rejection isolation, diagnostics, the embedded processor source's syntax, data URL construction, and avoiding duplicate registration after simulated success. They do not verify real browser module loading or CSP enforcement.

Next evidence

Reopen the same probe file, verify probeVersion: 3, enable audio, and test the worklet module. Share the evidence and any additional browser console error if it still fails. Confirm separately whether Chrome was fully exited between the earlier user runs. Preserve the remaining offline, edited-settings, directory/fallback, and failure-injection checks in the manual procedure.