Journey result: Atelier Cinematheque render queue

Walked: 2026-07-02 by Codex against the real-development-infrastructure Playwright harness.
Reconciled: 2026-07-17 against the current Cinematheque route, fixture data, read-only component, and focused browser suite. This was a source reconciliation, not a fresh runtime walk.
Verdict: partial — deep automation proves the complete shipped read- only storyboard and queue monitor, fixed selected-shot state, honest disabled Cut action, mobile layout, reduced-motion state, and loaded-page offline stability. No live render job, subscription, mutation, or Cut destination is implemented.
Primary spec: apps/oshun/web/e2e/atelier-video-render-queue.spec.ts.

Result at a glance#

Evidence lane	Current result	Authority limit
Storyboard fixture	Twelve exact shot ids, times, titles, and rendered/rendering/queued/drafted states	Fixture data, not a project or provider response
Queue fixture	`sh 06` at 64%/02:14 plus queued `sh 07`/04:42 and `sh 08`/06:18	No live polling, subscription, or job store
Read-only interactions	Storyboard, queue, and preview clicks keep `sh 06` selected and preserve route/state	No selection, reorder, cancel, retry, or priority
Cut handoff	`Open in Cut · timeline` is disabled and explicitly marked as a placeholder	No destination or project transfer
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 storyboard and queue markup remain visible after connectivity is dropped	No offline reload, live-state staleness, or recovery

Evidence map#

The current route projects one fixed render snapshot into three coordinated views. Those views agree on sh 06, but there is no operational job source behind the progress bar and no downstream Cut workflow.

flowchart LR A[Cinematheque fixture data] --> B[Twelve-shot storyboard] A --> C[Three-row render queue] A --> D[Selected sh 06 card] B --> E[Rendered, rendering, queued, drafted labels] C --> F[64% and fixed ETAs] D --> F B -. clicks do not mutate .-> G[Selection state] C -. no polling or subscription .-> H[Live render jobs] D --> I[Open in Cut placeholder] I -. disabled .-> J[Cut timeline]

Proven observations#

Storyboard and queue snapshot#

/atelier/video renders inside the authenticated customer shell with the Cinematheque plate head, step rail, twelve storyboard panels, render queue, selected-shot card, and Cut action area.
The browser suite checks all twelve fixture shots: ids, times, titles, and their exact state partition—sh 01 through sh 05 rendered, sh 06 rendering, sh 07 through sh 10 queued, and sh 11 through sh 12 drafted.
Queue and selected-card assertions agree on sh 06 at 64% with ETA 02:14. The remaining rows are sh 07 queued at 04:42 and sh 08 queued at 06:18. This consistency is valuable presentation evidence even though the values are static.

Honest non-mutation#

Clicking a non-selected storyboard item, a queue row, and the selected preview leaves sh 06 selected, preserves the selected card, and keeps the route at /atelier/video. The test records that behavior as read-only rather than implying hidden controls.
Open in Cut · timeline exposes disabled and placeholder semantics and has no navigation side effect. The result therefore treats Cut as a visible product boundary, not a completed handoff.

Edge evidence#

At 390 × 844 the layout anchors remain visible and the page has no horizontal overflow. Reduced-motion mode leaves the tested subtree static.
Dropping network connectivity after load leaves the Cinematheque page, storyboard, queue, and selected-shot card visible. The suite deliberately assigns offline reload/replay behavior to broader PWA coverage.

Boundaries and gaps#

Fixture progress is not a live render queue. getAtelierVideoFixture returns the 64% value and ETAs directly. No provider job, worker, persisted status row, polling interval, subscription, or timestamp feeds the UI.
Read-only monitoring is not render orchestration. The user cannot select, reorder, prioritize, pause, cancel, retry, inspect a failure, or enqueue a shot through this route.
Static consistency is not temporal correctness. Storyboard, queue, and card agree because they render from one fixture. The result does not prove reconnect behavior, stale-state marking, monotonic progress, terminal state, or race handling.
The Cut destination is absent. The disabled control has no route, permission check, transfer envelope, project id, or edit timeline.
Offline-after-load is not offline-first. Visible DOM survives a network drop, but cold reload, cached navigation, job freshness, and resynchronization are not covered.
Route-local recovery is absent. /atelier/video has no room-specific loading.tsx or error.tsx boundary for queue or handoff failures.

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-video-render-queue.spec.ts \
  --workers=1

It requires the real-development-infrastructure web/BFF harness. A green run proves the shipped read-only snapshot contract; it must not be summarized as a live queue, a completed render, or a working Cut handoff.

Source trail#

Cross-references#

Open questions#

What is the authoritative render-job schema, and which persisted timestamps, attempts, provider ids, progress events, and terminal receipts reach this UI?
Will live updates use polling, server-sent events, or another subscription, and how will reconnects expose stale or conflicting state?
Which queue mutations belong in the customer room, and what authorization, optimistic-state, rollback, and audit contract protects them?
What route and project-transfer envelope will make the Cut action real while preserving selected shot, provenance, and render version?