Building each episode around four tracked frames.

THE WORK

The project.

The Glass Archive organizes generation around an episode before the first frame is rendered. Its dispatcher claims a ready story seed, verifies the lock owner, and creates an episode with four pending frame records. The worker can then attach returned assets to those identities while the registry shows what is still waiting, rather than reconstructing the episode from a group of finished files.

The source lock also scopes recovery: a failed handoff releases only the seed still owned by that execution. Episode numbering needs a separate rule, however. The current allocator reads the highest number and adds one, so two dispatchers holding different stories can still choose the same next episode. This account describes the exported implementation and that unresolved concurrency case, not an executed collision or verified live run.

IMPLEMENTATION

Design choices.

1. Claim acquisition is followed by verification. Reaching an update node doesn't prove that it returned one usable row owned by this execution; the readback checks that before episode allocation proceeds.
2. Episode and frame records exist before rendering. They provide explicit pending state and attachment targets, although the separate upserts don't form one atomic allocation transaction.
3. Story ownership is distinct from episode-number reservation. Max-plus-one is easy to derive from the registry, but different valid seed owners can read the same maximum. The shared number still needs concurrency control.
4. Eligible seeds are chosen uniformly at random. A ranking-oriented node name doesn't make the selected story the highest-scored candidate, so the account follows the actual selection code.
5. Failed handoffs release only a still-owned seed. This avoids clearing another owner's lock, but a lost response after worker acceptance remains ambiguous. An idempotent handoff or acceptance readback is needed before requeueing can resolve that case.

HOW IT FITS TOGETHER

Architecture.

• The story pool records eligibility, lock owner and expiry. After selecting an eligible seed, the dispatcher conditionally claims it and reads back by external key, locked status and owner. Missing, multiple or mismatched rows stop allocation.
• The allocator reads the season registry and adds one to the maximum episode number, rolling over after ten episodes. It upserts metadata by the calculated episode key; that shared calculation is separate from ownership of the selected story.
• The dispatcher creates four pending frame records before handing work to the worker. Provider generation and storage use those episode and frame identities, so an artifact can be attached to the intended frame as it arrives.
• A rejected or unrecognized handoff response marks the episode failed. Recovery releases the source seed only if its key and owner still match, preserving another execution's claim while leaving lost-response acceptance to resolve.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app