Spaces:
Running on Zero
Running on Zero
Commit History
-
test(01-11): prove the tap unlocks audio under a strict autoplay policy at three layers
Every browser test ran with --autoplay-policy=no-user-gesture-required, the flag that hid the phone bug. This adds a strict profile and three tests that fail on the bug and pass on the fix, plus the live reproduction against b4d182b. - conftest: chromium_strict_autoplay launches under document-user-activation-required with no relaxed flag; StrictPage reads the page through a raw CDP session with userGesture:false and taps with raw mouse input, because Playwright's evaluate/wait_for_function/page.click evaluate with userGesture:true and activate the document (measured: hasBeenActive flips true, after which the sticky policy forgives a late resume). GESTURE_TAP_JS wraps AudioContext.resume and addEventListener so every resume() records whether it ran on a trusted input's call stack - the rule iOS enforces and no Chromium flag models. audio_unlock_probe is the shared assertion: unactivated + 'suspended' before the tap, 'running' BEFORE the server answers, 'running' at…73b5215 -
docs(01-10): record the mobile row as emulated, with the real-device row left open
No phone was available, so the row is Playwright device emulation and says so: the Pixel 7 descriptor on Chromium renders the avatar and completes a typed turn on both the direct URL and inside the Hub page's iframe (one three.js instance, arms posed, 7-8 fps under SwiftShader, speech-start 8.0-8.8 s after Enter); the iPhone 14 descriptor cannot be exercised because Playwright's Windows WebKit has no Web Audio API and the boot aborts before the stage mounts. AVTR-01 is deliberately not marked on this evidence; the section ends with what a real-device check must record to close it.50d6810 -
docs(01-10): record the cold start, the lip-sync review and the VRM decision
The three manual rows the plan could not automate are now on record with their evidence, so the phase's observation record is complete rather than pending: - Cold start: Hub API pause + restart of revision b4d182b; first HTTP 200 at 18.0 s, avatar ready at +38.1 s / first frame +39.6 s, first typed turn 7.2 s after Enter (the synthesiser is loaded at boot, so the first turn pays no model load). Raw stage transitions in docs/evidence. - Lip-sync: a 113-char, 20.6 s utterance recorded headed on the Space with the mouth sampled at ~100/s against the audio clock; all four AVTR-02 criteria hold (timeline end equals the decoded buffer to 0.000 ms, 60/60 per-event agreement across thirds, pauses fully shut, devoiced vowels at half weight). Video (LFS, *.webm now tracked), ten labelled face crops, a five-viseme reference sheet and the telemetry are committed under docs/evidence at 2.8 MB total. - Licences: the eight-asset checklist re-read against the tree; no gaps. - VRM: t…648b932 -
docs(01-05): record the spike verdict - CONFIRMED, inline transport - and close the plan
docs/SPIKE-VERDICT.md: every automated evidence row filled from the deployed suite on 487b8cf, plus the huggingface.co Space-page embed read from inside the cross-origin iframe (ready, one three.js instance, mountCount 1, arms posed, transport inline). Verdict CONFIRMED; AVATAR_TRANSPORT=inline ships, the iframe transport stays as the parity-tested fallback. 01-05-SUMMARY.md closes the plan. DPLY-01 marked complete (test_space_reachable passed against the public URL). AVTR-01 deliberately left Pending: the mobile row is recorded as NOT YET TESTED rather than invented. HANDOFF.json deleted - nothing is blocked; 01-08 is next. Hub-embed screenshot added as LFS evidence.199a6c3 -
docs(01-05): record the deployed rest pose, 5/5 deployed suite, and the remaining spike-verdict gate
Evidence screenshots move to Git LFS (*.png now tracked): the Hub's pre-receive hook rejects non-LFS binaries above 100 KB, and the deployed rest-pose capture is 106 KB. The two earlier captures are migrated in the same commit so docs/evidence is uniformly LFS.82717b7 -
fix(01-05): pose the arms out of the authored T-pose and assert it
A VRM's rest pose is a T-pose and nothing in the stage ever moved the arms, so the deployed avatar stood with both arms straight out while every AVTR-01 check passed (docs/evidence/2026-09-05-deployed-tpose.png). vrm-stage.js now rotates each upper arm 1.2 rad about Z toward the body and the forearm a further 0.2 rad, once, on the normalized bones at mount. The idle life only writes spine, hips and head, so the two never compete. The pose is measured every frame on the RAW skeleton after render and published as debug.armDown.{left,right}: the downward component of the world-space shoulder->elbow direction (-1 down, 0 T-pose). Measured -0.932 both sides, which is sin(1.2) exactly. Tests at all three layers assert armDown < -0.7 (ARM_DOWN_MAX): the standalone stage, both Gradio transports through the facade (so the field is proven to cross the iframe boundary), and the deployed Space. Each waits for the first rendered frame via breathValue rather than a fixed sleep, because the first …7a26764 -
docs(01-05): record the deployed T-pose and its actual cause
The user reported the avatar standing with both arms out. Capture the screenshot as evidence and separate the two explanations that look alike: this is not the two-three.js-instances failure. The instruments and the image agree the VRM parsed correctly — one three.js instance, real VRM 1.0 meta, correct materials. Nothing in this repo has ever posed the arms, and a VRM's authored rest pose is a T-pose. The idle offsets are all under 1.5 degrees. Record the fix, and the requirement that a deployed assertion pin the arms down afterwards: AVTR-01 passed every existing check while looking wrong, so its tests were measuring liveness and never posture. Also record the diagnostic trap that cost time here — window.Avatar.__debug is a snapshot refreshed only by getDebug(), so polling it directly reads frozen values and imitates a dead render loop.cf68e57