Finishing a job leaves the workspace in stale edit mode — must flip to read-only in place

[JArmandoAnaya]

Decision (Armando, 2026-08-08): on Finish, the workspace transitions to
read-only immediately and in place — same window, no navigation away, no
reload — across every frame of the job, not only the last. In read-only:
the edit tool strip is removed entirely, the classes panel is removed, only
the objects panel remains; objects stay selectable for focus only; nothing
is editable — no vertex, bounding-box, or polygon manipulation of any kind;
and frame navigation stays fully functional — arrows, counter, and gallery
keep working. Only editing dies; moving between images does not.

Observed

Press Finish job on the last frame. The job completes — and the workspace stays in
edit mode: the tool strip, the classes panel, navigation and Save and next all
remain, on every frame. Editing still works on the canvas. Finish renders disabled
(Finished) on the last frame.

All the machinery for the correct end state already shipped (#431, the read-only mode).
What is missing is the bridge from the mutation's success to the mode flip.

Where the mode comes from

AnnotationPage derives it from the frame's own declaration —
readOnly = !declares(asset, ASSET_ACTION.annotate) — which is the capabilities
contract working as intended: the frontend renders what the wire declares and never
computes legality itself.

What HEAD does, measured

A TestClient walk over the real kernel — approve, start, annotate every asset, then
POST /jobs/{job_id}/complete — answers:

After POST /jobs/{job_id}/complete
batch.state	in_annotation
batch.allowed_actions	["complete", "repin", "delete"]
job.state	completed
job.allowed_actions	[]
every asset's allowed_actions	["annotate", "skip", "submit_for_review"]
a subsequent POST /jobs/{job_id}/annotations	201 Created

Three consequences:

1. Completing a job does not complete its batch. JobService.complete states it in
   its own docstring; BatchService derives batch completion from the jobs when asked,
   and the workspace never asks.
2. The declaration does not move. asset_actions gates on batch state and asset
   progress and never reads job state, so a completed job's assets keep declaring
   annotate.
3. The kernel still accepts the write. AnnotationService gates on
   require_open_batch plus WRITABLE_PROGRESS; job state is nowhere in the annotation
   write path. Labels written after Finish are stored, so Finished is not yet a
   statement about what may still be written.

The workspace is therefore showing a current answer, not a stale one.
useJobTransition's onSuccess already invalidates jobKeys.job(jobId), ["projects"]
and ["batches"] — and ["batches"] prefix-covers the workspace's own asset query key
(["batches", <batchId>, "assets", "job", <jobId>]). The refetch happens; the refetched
answer is identical.

The open question

The decision above is not in doubt. The layer that delivers it is.

Adding invalidation cannot deliver it, because nothing is stale. Computing the mode from
jobState inside the page would be the frontend deciding legality — the one pattern
ui-capabilities bans — and it would leave every other client (CLI, MCP, REST) still
writing into a finished job.

That leaves a wire-side ruling, which is a domain decision rather than an implementation
detail:

Is a completed job closed for writes?

If it is, then asset_actions takes job state (a completed job's assets declare
nothing), and AnnotationService refuses annotation writes through a completed job so
that the declaration and the refusal agree — and the mode then flips through the
invalidation that already exists. Two follow-on questions travel with it:

• JobService.mark is likewise ungated on job state, so an asset in a completed job can
  currently be un-skipped to unannotated, unsettling a job that says it is finished.
• JOB_TRANSITIONS has no completed → in_progress edge, so the freeze is one-way and
  correcting the work means a correction batch.

None of that is settled in the batch lifecycle model, so it is recorded here rather than
chosen inline.

Already true at HEAD

Three of the decision's surfaces are shipped and want assertion rather than
implementation:

• Tool strip removed entirely in read-only — since The annotator opens as a viewer when nothing can be written (F2, F23) #306, absent rather than disabled.
• Classes panel absent, objects panel at full height — feat(annotator): the read-only mode stops advertising edits — no classes region, no handles, no move cursor, and selection reflected in the panel #431.
• Frame navigation — the gallery button, ‹ › and the n/m counter are ungated by
  the mode.

The gap: the flow verbs (Skip, Save and next, Finish job) render
disabled-with-reason in read-only rather than absent.

cf. #431 (the read-only mode this transitions into), cf. #427 (the Finish tooltip — its
all-resolved, enabled state is the press this starts from).

[JArmandoAnaya]

Decision (Armando, 2026-08-08), answering the open question above: a completed job is closed for writes.

The gate is the kernel's. OPEN_JOB_STATES ({pending, in_progress}) joins WRITABLE_PROGRESS and SETTLED_PROGRESS in the domain, and both sides read it:

• asset_actions takes the job's state as a third dimension, so a completed job's frames declare nothing — in an open batch as much as in a closed one.
• JobService.require_open_job refuses the three annotation writes and mark with JobFinished (409 JOB_FINISHED), so the declaration and the refusal cannot disagree. Reads are untouched: a viewer over finished work has to be able to show it.
• Progress moves are frozen too, which settles the follow-on question in the body — an asset in a finished job can no longer be un-skipped back to unannotated.
• Nothing re-opens a job. JOB_TRANSITIONS gives completed no way back, so correcting finished work is a correction batch, the same forward-only route a completed batch offers.

The workspace then flips through the invalidation the Finish mutation already performs, with nothing in the browser computing legality. Removing deferred-needs-input.