GENERATION

Generate against a shot, not a prompt

The resolver assembles the prompt, the reference set and the continuity frame from the graph. You supply intent; it supplies context.

THE RESOLVER

01CiteThe shot names its scene, cast, location and beat.
02ResolvePlates, continuity frame and look are ranked and capped.
03GenerateOne fully-formed call to the generation engine.
04ScoreContinuity is measured; a bad take can auto-retake.
The resolved set is stored on the take, so a result you like is exactly reproducible.

Calls

shoot.take(shot)
Generate one take using the resolved context.
shoot.extend(take)
Extend a take, inheriting its tail frame automatically.
shoot.retake(shot, note)
Regenerate with a correction note, keeping the old take.
shoot.select(take)
Mark a take as the chosen one. Updates the timeline.
RequestPOST /v1/shots/{id}/takes
{
  "note": "she hesitates before answering",
  "extend": false
}
Response200 OK
{
  "take": "tk_9f2c1",
  "status": "queued",
  "refs_used": 11,
  "continuity": null
}
From the CLI
$ picx shoot all --parallel 4

✓ 14 shots · 19 takes
  2 auto-retaken on continuity score
  → ./takes/

For users

Takes accumulate, they never overwrite. Try three versions of a shot and pick the one you like — the others stay.

For developers

Reference limits differ per engine. The resolver ranks by importance and truncates rather than failing, and reports refs_used so you can tell when it had to drop something.

Gotchas

  • Extensions inherit the tail frame, so extending a bad take compounds the problem. Retake instead.
  • Parallel shooting is capped per workspace. Above the cap, jobs queue rather than error.