Skip to content

Session handover — 2026-07-15 pt2

A follow-on to 2026-07-15, which segmented WCP's 27 missing videos into ranked render buckets. This session took the biggest bucket — fcr.gallery ×13 (pt1's agreed workstream #1) — and shipped its render/producer/schema/adapter, but hit a real stop on acquisition and did NOT deploy. The videos turned out to be Wix VOD channel videos, a third media surface the ADR-0010 API can't reach.

What shipped (committed, NOT deployed — inert without acquired refs)

Branch gallery-video-render-producer (commit 37c2aa7). The full gallery-video CODE path, A/B-proven zero-regression and reproducible-from-capture:

  • Schema: videos multiline field on fcr.gallery (the slideshowUrls/subItems line encoding; repeaters are scalar-only).
  • Producer: makeStyleLookup (lib/cms/seed-from-build.js) emits each gallery section's attributed video refs as /assets/videos/<mediaId>.mp4 lines, freshness-gated on the v8 mediaRefs.sectionAttribution key (presence-of-key, not version number — same discipline as CAPTURE_REQUIREMENTS); transformer.js stamps fcr.gallery.videos.
  • Render: gallery-wcp.astro draws a <video controls> strip below the image grid, deliberately outside .gallery-item (lightbox index untouched), omitted when absent; Gallery.astro adapter parses the lines field through getImageSrc.
  • Migration hook: migrateGalleryVideos in transform-seed-images.mjs (routes through the Media Manager migrateVideoRef path — which honestly reports video-not-in-wix-pool).

A/B (change stashed vs applied, _key-normalized): garvanbay 6 gallery blocks gain videos:"" + zero other diffs; WCP's 4 gallery-page category blocks carry exactly the 13 attributed refs (Commercial 4 / Residential 3 / Shed repair 2 / Misc 4), every other gallery block videos:"". CMS build compiles; check-renderers + video-domain validates pass.

The real stop — the videos are Wix VOD channels, not Media Manager assets

Measured, not inferred: 0 of 13 gallery videos appear in the Media Manager pool (mediaPool, mediaTypes=VIDEO, 46 files) by any id form (file id / media.video.id / posters[].id) — nor does the hero id, in the capture's id form. The live network trace settled it: the player enumerates them from GET /_api/vod/public/v3-to-v2/public/lists/<channelId>?media_type=secure_video (items carry source_url: null), gets a JWT from GET /_api/v1/access-tokens, and streams tokenized HLS (repackager.wixmp.com/.../master.m3u8?token=<JWT> + .ts). The captured mp4-shaped URL 400/403s on direct fetch. So the content plane has three Wix media surfaces, and ADR-0010's by-id join covers only the first two.

The seed graft (raw /assets/videos/ refs) was reverted so no dead <video> ships; videoDebt is unchanged this session (gallery shortfall still 13); WCP was not redeployed.

Where to look

  • Durable lesson: known-patterns "A Wix gallery's VIDEOS are VOD-channel HLS, not Media Manager" — and its detection rule (read the live network trace, don't re-derive the pool; the pool-truncation amendments condition you to reach for a pool fix, resist it).
  • Deferral contract: known-issues "WCP asset debt …" → the new sub-section "Gallery bucket (13) — render/producer SHIPPED, acquisition BLOCKED on Wix VOD" carries the reopen trigger and the channel ids from the trace.
  • ADR-0010 third amendment (VOD as a third media surface) + build Slice F (VOD-list API + access token + HLS→mp4 remux → R2), Planned.
  • ADR-0009 Slice 5 row — the gallery bucket note (Slice 5c: render/producer shipped, acquisition deferred).

Next

  1. VOD acquisition (ADR-0010 Slice F) — the deferred half of this slice. Enumerate the VOD channels (9ba179c0…, 4cd95f58…, + 2 more), mint per-video tokens, remux HLS→mp4 (needs an ffmpeg decision — cf. the Phase 5 oversize-video ffmpeg note in known-issues), upload to R2, graft the migrated refs into the committed WCP seed, redeploy, re-capture ours → confirm gallery videoDebt 13→0. Verify the other two buckets' source first — fcr.about ×11 may be Media-Manager (API-reachable today) or also VOD; one probe decides.
  2. fcr.about video bucket (11) — the next render bucket; one adapter/block decision covers every service page. Probe its source before assuming the API path works.
  3. Still open from earlier: garvanbay /contact hero (its HOLD, untouched); home-FAQ heading extraction (double-motivated — the 20th FAQ tone stamp + 3 dropped-live video homes); aligner role-aware anchoring; Slice 6 calibration.

The through-line

pt1's rule was measure the join before building it. This session is the same rule at the acquisition layer: the acquisition join was measured against live before a single video was downloaded — the by-id API path returned 0/13, the network trace named the real product, and the pre-registered "risk" (some videos may lack a Media-Manager home) became the finding. The split — ship the proven measurement/render, defer the newly-scoped acquisition, and never stamp a dead ref into a committed seed to move the number — is the honest close.