The review page

When to use

Every time something renders that the creator should see: a draft, a still set, a shot clip, a comparison. Also when setting up a new project (build the page first), and when they give feedback on something posted. The channel calls its page the WIP page.

What the page is

• One entry per pass. Each draft, still set or clip is its own entry: a title, when it was added, its known issues at the top, then what changed and what to look at, then the media, then a link to the previous pass of the same thing.
• Newest first, by when it was added. An edited entry keeps its old place, so every pass the creator should see is a new entry, never an in-place revision of an old one. Keep the earlier passes and their media so the progression can be followed.
• Review marks are separate from approval. The director marks an entry "waiting review" once it has checked it, and passes at the same thing share a subject so only the newest one waits. When the creator gives feedback, the entry becomes "reviewed", with a one-line note of what they said and when. Reviewed never means approved.
• Media is referenced where it lives, never copied into the page.

If the project has no page yet, a folder of one JSON file per entry and a static page that lists them newest first and plays their media is enough. One entry might look like this:

{
  "id": "chorus-1-draft-4",
  "title": "Chorus 1, draft 4",
  "createdAt": "2026-10-12T14:05:00-04:00",
  "subject": "chorus-1",
  "knownIssues": ["f1520–1524: the sign's letters flicker (two coplanar faces); fixed in draft 5"],
  "body": "What changed since draft 3, and what to look at.",
  "media": [
    { "type": "video", "src": "renders/chorus-1-d4.mp4" },
    { "type": "image", "src": "renders/chorus-1-d4-loop.avif" }
  ],
  "previous": "chorus-1-draft-3",
  "review": { "state": "waiting" }
}

Posting

1. Render, scan for blank frames, post at once with the known issues on top, then fix. Never batch several drafts, and never hold one back for a peer's sign-off. The creator wants to watch the work move; a review becomes notes on the posted entry.
2. Known issues are everything you already know is wrong, in plain words, with frame numbers.
3. A shot clip carries its own song (muxed in) and plays on its own. A clip that plays against the full song needs its start offset in seconds, never in frames.
4. Every new version gets a new file name. Players and caches remember a clip by its URL, and the cut may still use the old file. Never overwrite a delivered file.
5. Looping previews are 10-bit AVIF made from the render's mp4 (ffmpeg -i in.mp4 -c:v libsvtav1 -crf 23 -preset 6 -pix_fmt yuv420p10le -f avif out.avif), never lossy WebP, which broke dark gradients into blocks. Zoom into a flat dark area to check for blocks before posting.
6. Read the stored entry back after writing it. A refused update can look like success.
7. Anything the creator should see is an entry, never a file path in chat.
8. Third-party references stay off the page. Other people's films and footage are for matching locally; the page shows only your own work.

Taking feedback

• When the creator gives notes on an entry, mark it reviewed with their words and the time, and route the notes to the session that owns it, verbatim (directing-sessions).
• A session that gets notes directly in its own chat marks its own entry reviewed and tells the director.
• Never mark your own entry as waiting review; the director does that after checking it.

Verify

• The new entry is at the top of the page, its media loads, and the clip plays its picture with its sound.
• Its known issues are the first thing on it.
• The previous pass is still there, unchanged, and linked.