assigning frames to a job or an annotator has no domain concept

[JArmandoAnaya]

The gap

The batch-view redesign asked for an Assign bulk action: select some frames, then hand them to
somebody or something. There is no domain concept for it, on either reading of what "assign"
could mean.

Reading one, assign to a job. Jobs are cut exactly once, at approval, by partition_assets,
and that partition is exact — the jobs are disjoint and their union is the batch. There is no
move-an-asset-between-jobs operation in JobService, and adding one means first deciding what
happens to work already recorded against the asset in its old job.

Reading two, assign to a person. There is no person. VisionSet has no user model at all. The
nearest thing to an identity is a named API token issued by TokenService, which is a credential
rather than an assignee, and AnnotationJob has no owner column.

What has to be decided before anything is built

1. Which reading is wanted. They are different features with different costs, and only the
   second is what "assign" usually means in an annotation tool.
2. If it is to a person: does VisionSet grow an identity model, and is that the same decision
   as multi-user workspaces? That is a founder call rather than a design detail — it reaches
   auth, the workspace boundary, and every audit record in the product.
3. If it is to a job: what a reassignment does to annotations already written under the old
   job, and whether TaskGroup rounds — one round of work per batch, with a review round as a
   second group beside the first — are the mechanism, rather than something new.

Why it is parked rather than planned

Both readings land in the same neighbourhood as the other unmilestoned post-beta tracks: the
AI-assist substrate with its review loop (#81), and annotation versioning, which is the design's
main dropdown and its Merge action (#127). Whichever of those is answered first probably
decides the shape of this one, and answering this one in isolation risks building a second
mechanism for the same thing.

The issue was filed out of the batch-view redesign, where Assign was cut for having nothing
behind it.

[JArmandoAnaya]

The parent of this issue is the batch-view redesign (#284), which turned the batch view into a workspace with status, approval and a full-width grid. Assign was cut from that redesign for having no API behind it.

[JArmandoAnaya]

The gate this issue inherits is live again, as the 2026-08-05 backlog audit found.

This issue parks itself on the grounds that whichever of its neighbours is answered first probably decides the shape of it — meaning the AI-assist substrate and its review loop (#81), and annotation versioning (#127). Both of those were gated on a re-triage at the beta close-out (#70), and that close-out closed on 2026-07-31: the trigger fired untriaged, so for the past week the parking clause was pointing at two issues whose own exit condition already lay behind them.

Both now carry a live gate — re-triage at the 0.1.0 close-out — so the clause means something again. The body needs no change, because the gap it describes is unchanged at HEAD 47dc1f0: still no user model, still no assignee column on AnnotationJob, and still no move-an-asset-between-jobs operation in JobService.

[JArmandoAnaya]

Decision (Armando, 2026-08-06): milestoned into 0.1.0 so the "re-triaged at 0.1.0 close-out" gate has a list to appear on (cf. the 2026-08-06 close-out brief, D7). This is visibility, not scheduling — 0.1.0 remains open with no close-out date. — supersedes any prior direction