Deterministic N→1 selection between a fan-out and an expensive stage (`select` reducer + `judge` scorer)

[dkackman]

tool/endpoint: the workflow language — a new select reducer task and a judge scorer task; list_tasks, validate_workflow, run_workflow; the manifest / get_job

repro: the README's headline shape, 4 stills → choose one → video, when the choice is a rule rather than a judgment:

still  (for_each over 4 seeds)
judge  (for_each over the same list: a number per still against a rubric)
pick   (select argmax(scores))
video  (LTX-2.5 image-to-video on previous_result:pick)

expected: expressible as one workflow. The rule that made the choice is recorded in the manifest (selected: position, member name, score) so the recipe replays; on a seeded run, changing only the rule reuses the cached stills and scores and regenerates only pick and the video.

actual: two jobs with the agent in between: job A fans out, the agent picks, keep_output, job B on asset:name. That is the right boundary for a subjective choice and stays. For a deterministic one it is a round trip that records the rule nowhere. Two gaps behind it: no task reduces a list to one member by a rule, and no task emits a number per candidate for a rule to read. (A third, found while writing this up: no reference hands a task all of one step's artifacts — every previous_result: iterates — so gather: over a for_each group is the only whole-list reference. The proposal builds on that rather than adding a reference kind.)

---

Proposal: docs/proposals/score-and-select.md — select with a closed rule set (argmax, argmin, first_above, first_below, index), judge as the first scorer reusing the image_to_text VLM loader, one catalog template, selected in the manifest. Explicit non-goals: when/skipped steps, retry, semantic selection.

Parked with owner:don + status:needs-approval per the protocol (engine/syntax change). Approval is flipping the owner label to owner:implementer. Sibling preflight ticket: #118.

Raised by an external reviewer's forum reply.