Staleness rules

crowmaki commented

2026-10-06 03:55:54 +00:00

Owner

Part of #1
Blocked by: #11

Question

When is a Take stale? Cover a new Lock snapshot on a Reference set it used (directly or through an Atlas), a changed Board or Keyframe, a changed Performance, a changed prompt or Setup fields, and a changed shipped workflow version. Is staleness stored or computed? What does the user do with it?

Part of #1 Blocked by: #11 ## Question When is a Take stale? Cover a new Lock snapshot on a Reference set it used (directly or through an Atlas), a changed Board or Keyframe, a changed Performance, a changed prompt or Setup fields, and a changed shipped workflow version. Is staleness stored or computed? What does the user do with it?

crowmaki added the

wayfinder:grilling

label

2026-10-06 03:55:54 +00:00

crowmaki referenced this issue

2026-10-06 03:56:08 +00:00

Wayfinder: AI Studio end-to-end slice spec #1

crowmaki commented

2026-10-06 06:28:23 +00:00

Author

Owner

From "Dailies review and circling" (#7): stale Takes can still be promoted (with a warning naming the stale inputs); the resulting final keeps the stale flag. "Same take, new seed" defaults to current inputs; stale Takes also offer "with original inputs".

crowmaki commented

2026-10-07 03:42:51 +00:00

Author

Owner

From "Prompt composer phrasing" (#9): a Shot's prompt override has its own staleness. When the composed prompt differs from the override's fork base, the Shot shows only an unobtrusive "composer changed" marker; the three-way reconcile opens only on demand, and queuing does not prompt. Slot tags in an override that point at an empty or reassigned slot are a blocking error, not staleness. Takes record the exact prompt text, so "changed prompt" can be judged by text comparison.

crowmaki commented

2026-10-07 04:06:04 +00:00

Author

Owner

From "Reference slot budget" (#10): a change in the set of references a Shot would send (a new or removed candidate, a changed Project order on an unedited Shot) shows the same quiet marker as "composer changed". Forced drops never block queuing; only override tags that no longer match a slot do. Dailies compares a Take's recorded slot assignment with the current one.

crowmaki commented

2026-10-07 04:45:44 +00:00

Author

Owner

From ".studio schema" (#11): additional staleness triggers: a change to the Shot's effective aspect ratio (Project ratio or Shot override); a new Performance version (or the Scene's performance_off flag flipping); the current Lock snapshot no longer being the one the Take used (current = highest number). Take provenance is take_input rows with real FKs plus Shot/Setup text fields recorded by value or hash, so staleness can be computed by query. Changing the Project's default generation profile does NOT make Takes stale.

From ".studio schema" (#11): additional staleness triggers: a change to the Shot's effective aspect ratio (Project ratio or Shot override); a new Performance version (or the Scene's performance_off flag flipping); the current Lock snapshot no longer being the one the Take used (current = highest number). Take provenance is `take_input` rows with real FKs plus Shot/Setup text fields recorded by value or hash, so staleness can be computed by query. Changing the Project's default generation profile does NOT make Takes stale.

crowmaki self-assigned this

2026-10-07 04:48:10 +00:00

crowmaki commented

2026-10-07 05:01:06 +00:00

Author

Owner

Resolution

Definition: the re-roll diff. A Take is stale when a re-roll with the Shot's current inputs would send a different job. The Take's own seed and generation profile are ignored. Staleness is computed from the Take's provenance (take_input rows plus recorded text and hashes) compared with the Shot's current job. It is never stored as a flag. Each difference is a named Stale reason, grouped into these kinds: References, Board/Keyframes, Performance, Prompt, Framing, Workflow. The triggers listed in the question and comments are examples of this rule, not a closed list. These cases follow from the rule:
- A changed Atlas setting or grouping (megapixel budget, regroup) changes the Atlas pixels, so it is a References reason.
- A soft-deleted input (for example, a removed Board) is a reason.
- A changed Line range on the Shot changes the prompt, so it is a Prompt reason.
- A changed slot assignment is a reason, even when it uses the same images.
- On a Shot with a prompt override, the Takes are compared with the override text. A composer change alone only shows the Shot's "composer changed" marker, until the user edits the override.
Workflow updated is a lower tier. It is shown in the Take details and in the inputs comparison. It gives no stale badge, no Promotion warning and no hit in stale filters. Only shipped workflow versions marked as changing output can cause this reason. A version that only fixes how a node runs causes no reason.
Accepted reasons. The user can accept a Stale reason on one Take. The app stores the input's current value (for example, "accepted Lock snapshot 3 of this Reference set"). The reason stops counting while the input keeps that value, and comes back when the input changes again. "Accept all" writes one acceptance for each current reason; it is not a blanket flag. Accepting never changes the Take's provenance.
Promotion uses the recorded inputs. The Promotion job rebuilds conditioning from what the draft used: the recorded prompt text, the recorded slot assignment, and the recorded Atlas and Tile blobs (kept by ADR-0004). It never uses the current inputs. Staleness is a property of the Take, so its draft and final Renditions are stale together. To get the new inputs, the user re-rolls.
Where staleness shows:
- Dailies: a badge on every stale Take tile and table row, and a Stale column that can be sorted and filtered. The details panel lists the reasons, each with an Accept button.
- Shot and Scene listings: a marker only when a circled Take is stale, shown as a count ("2 circled stale"). It sits beside the "composer changed" and over-budget markers.
- Animatic: a small corner mark on a playing Take event that is stale. Board events never get this mark.
- Export: stale Takes never block export. The metadata CSV Comments field gets "Stale: ".
Batch re-roll. The action "Re-roll stale circled Takes" is available per Scene, and per Reference set ("Takes affected by Turnaround v3"). It works like this:
- It queues one new-seed Take for each affected Shot, with the current inputs and the circled Take's generation profile.
- The new Takes are drafts by default. A toggle on the confirm sheet makes them single-pass finals instead.
- The confirm sheet also shows the number of Takes and an estimated render time.
- It skips a Shot that already has a queued or running Take with current inputs.
- New Takes arrive in Dailies as unseen. The action never circles or uncircles a Take.

Glossary: added Stale take, Stale reason and Accepted reason to CONTEXT.md.

## Resolution 1. **Definition: the re-roll diff.** A Take is stale when a re-roll with the Shot's current inputs would send a different job. The Take's own seed and generation profile are ignored. Staleness is computed from the Take's provenance (`take_input` rows plus recorded text and hashes) compared with the Shot's current job. It is never stored as a flag. Each difference is a named **Stale reason**, grouped into these kinds: References, Board/Keyframes, Performance, Prompt, Framing, Workflow. The triggers listed in the question and comments are examples of this rule, not a closed list. These cases follow from the rule: - A changed Atlas setting or grouping (megapixel budget, regroup) changes the Atlas pixels, so it is a References reason. - A soft-deleted input (for example, a removed Board) is a reason. - A changed Line range on the Shot changes the prompt, so it is a Prompt reason. - A changed slot assignment is a reason, even when it uses the same images. - On a Shot with a prompt override, the Takes are compared with the override text. A composer change alone only shows the Shot's "composer changed" marker, until the user edits the override. 2. **Workflow updated is a lower tier.** It is shown in the Take details and in the inputs comparison. It gives no stale badge, no Promotion warning and no hit in stale filters. Only shipped workflow versions marked as changing output can cause this reason. A version that only fixes how a node runs causes no reason. 3. **Accepted reasons.** The user can accept a Stale reason on one Take. The app stores the input's current value (for example, "accepted Lock snapshot 3 of this Reference set"). The reason stops counting while the input keeps that value, and comes back when the input changes again. "Accept all" writes one acceptance for each current reason; it is not a blanket flag. Accepting never changes the Take's provenance. 4. **Promotion uses the recorded inputs.** The Promotion job rebuilds conditioning from what the draft used: the recorded prompt text, the recorded slot assignment, and the recorded Atlas and Tile blobs (kept by ADR-0004). It never uses the current inputs. Staleness is a property of the Take, so its draft and final Renditions are stale together. To get the new inputs, the user re-rolls. 5. **Where staleness shows:** - **Dailies:** a badge on every stale Take tile and table row, and a Stale column that can be sorted and filtered. The details panel lists the reasons, each with an Accept button. - **Shot and Scene listings:** a marker only when a *circled* Take is stale, shown as a count ("2 circled stale"). It sits beside the "composer changed" and over-budget markers. - **Animatic:** a small corner mark on a playing Take event that is stale. Board events never get this mark. - **Export:** stale Takes never block export. The metadata CSV Comments field gets "Stale: <kinds>". 6. **Batch re-roll.** The action "Re-roll stale circled Takes" is available per Scene, and per Reference set ("Takes affected by Turnaround v3"). It works like this: - It queues one new-seed Take for each affected Shot, with the current inputs and the circled Take's generation profile. - The new Takes are drafts by default. A toggle on the confirm sheet makes them single-pass finals instead. - The confirm sheet also shows the number of Takes and an estimated render time. - It skips a Shot that already has a queued or running Take with current inputs. - New Takes arrive in Dailies as unseen. The action never circles or uncircles a Take. Glossary: added **Stale take**, **Stale reason** and **Accepted reason** to CONTEXT.md.

crowmaki referenced this issue

2026-10-07 05:01:06 +00:00

Render worker scheduling #18

crowmaki closed this issue

2026-10-07 05:01:06 +00:00

crowmaki referenced this issue

2026-10-07 07:14:03 +00:00

Marking Lines in a Performance #23

crowmaki referenced this issue

2026-10-07 07:24:15 +00:00

Spec: AI Studio end-to-end slice #24

crowmaki referenced this issue