Journey result: Atelier motion to Cinematheque

Walked: 2026-07-02 by Codex against the real-development-infrastructure Playwright harness.
Reconciled: 2026-07-17 against the current Stage of Motion component, fixture data, Cinematheque query parser, and focused browser suite. This was a source reconciliation, not a fresh runtime walk.
Verdict: partial — deep automation proves the complete shipped read- only room, honest placeholder actions, exact URL-scoped Cinematheque handoff, receiving context panel, mobile layout, reduced-motion state, and loaded-page offline stability. Motion authoring and durable project transfer are not implemented.
Primary spec: apps/oshun/web/e2e/atelier-motion-to-cinematheque.spec.ts.

Result at a glance#

Evidence lane	Current result	Authority limit
Motion room fixture	Five tracks, three takes, kept take 02, frame 074/144 playhead, 24-joint rig, and 41% bake state	Server-returned fixture, not a mutable project
Read-only interactions	Ruler, selected keyframe, and viewport clicks leave the playhead and route unchanged	Proves non-mutation, not editing
Draft controls	`New take` and `Re-target rig` are disabled, labeled placeholders	No creation, rig binding, or job lifecycle
Cinematheque handoff	Real link carries fixed shot, take, voice, and light query context; receiver renders exact values	URL-scoped context, not a persisted project id
Responsive/accessibility	390 px no-overflow stack, reduced-motion static subtree, and inherited serious/critical axe gate	Focused viewport and automated checks only
Offline-after-load	Loaded fixture markup remains visible after connectivity is dropped	No offline reload, write queue, or replay guarantee

Evidence map#

The current journey transfers a small fixed context envelope through the URL. Both rooms display that context honestly, while the motion surface itself stays read-only and no durable project record crosses the boundary.

flowchart LR A[Motion fixture data] --> B[Stage of Motion room] B --> C[Five-track read-only timeline] B --> D[Three read-only takes] B --> E[41% fixture bake card] B --> F[Open in Cinematheque link] F --> G[Fixed query context] G --> H[Cinematheque parser] H --> I[Inbound motion context panel] B -. disabled .-> J[New take] B -. disabled .-> K[Re-target rig] G -. no project id .-> L[Durable project state]

Proven observations#

Stage of Motion contract#

/atelier/motion renders inside the authenticated customer shell with a visible Stage of Motion plate head and the expected fixture dimensions: five tracks, three takes, take 02 marked kept, frame 074 of 144, and a 41% bake card representing 59 of 144 frames.
The suite checks every track label, curve, key count, keyframe position, 13-frame ruler label, selected frame-72 accent, and the stable playhead position. Forced clicks on the ruler, a keyframe, and the viewport do not change the current frame or navigate away.
The actions labelled “New take” and “Re-target rig” carry disabled and placeholder semantics. Their lack of navigation is asserted rather than presented as hidden product functionality.

Downstream handoff#

“Open in Cinematheque” is an actual link to /atelier/video?from=motion&shot=sh-03&take=take-02&voice=foundry-take-03&light=forms-cream-north.
The receiving route accepts the handoff only when all expected query values match. It translates them into the visible shot sh 03, take take 02, inherited voice foundry · take 03, inherited light forms · cream-north, and state url-context.
The test follows the link and asserts the exact inbound panel on /atelier/video, proving a real two-route browser transition rather than a documentation-only URL convention.

Edge evidence#

At 390 × 844 the page, stage, and clip panel fit without horizontal overflow. The route also exposes static reduced-motion state through the test harness.
After the page is loaded, dropping the browser context offline leaves the room, stage SVG, and frame-74 playhead visible. The test deliberately does not claim an offline reload or replay path.

Boundaries and gaps#

Read-only proof is not motion authoring. The timeline, rig viewport, takes, playhead, and bake status are fixture-backed presentation. No drag, scrub, key edit, viewport rotation, take creation, retarget, save, undo, or render job is performed.
URL context is not durable project state. The handoff carries a fixed query envelope without an owner-scoped project id, version, write, receipt, conflict policy, or resume token.
Offline-after-load is not offline-first. Existing DOM remains visible when the network drops; the result does not prove cold reload, cached navigation, queued edits, synchronization, or conflict recovery.
The query parser is intentionally narrow. Any missing or changed value suppresses the inbound panel. There is no general schema/version negotiation for arbitrary shots, takes, voices, or light rigs.
Route-local recovery is absent. /atelier/motion and /atelier/video do not ship room-specific loading.tsx or error.tsx boundaries.
Automated accessibility is not manual AT QA. The shared fixture guards serious/critical WCAG findings, but the result does not certify screen-reader timeline comprehension or keyboard editing because editing does not exist.

Re-run evidence#

The current focused browser suite is:

bash

PW_BROWSER_CHANNEL=chrome pnpm exec playwright test \
  -c apps/oshun/web/playwright.config.ts \
  apps/oshun/web/e2e/atelier-motion-to-cinematheque.spec.ts \
  --workers=1

It requires the real-development-infrastructure web/BFF harness. A green run proves the shipped read-only and URL-handoff contract; it must not be summarized as motion authoring, a completed bake, or durable Cinematheque transfer.

Source trail#

Cross-references#

Open questions#

Which mutable timeline operations belong in the customer Atelier, and which should transfer into the authoring Studio?
What owner-scoped project/version contract should replace the fixed query envelope, and how will stale or unauthorized references fail?
What job record, progress source, cancel/retry behavior, and receipt will make bake state operational rather than fixture presentation?
What room-specific loading, error, offline-reload, and recovery states should preserve enough context for the user to continue safely?