[feat] Optional unit-level (serial) execution alongside batch-level progression

[Priya-Makkal]

Problem / motivation

Today, a Batch's steps progress as a single unit for the entire batch quantity — BatchStep.status (PENDING → READY → IN_PROGRESS → DONE) is one value covering the whole batch, and a step can't start until the previous step is DONE/SKIPPED for the batch as a whole. For a batch of, say, 15 pieces, all 15 must finish Step 1 before any of them can start Step 2.

For lines that build one piece at a time and want to pipeline it — piece 1 finishes Step 1 and moves on to Step 2 while piece 2 starts Step 1 behind it — this isn't possible today. There's no way for individual pieces within a batch to be at different steps simultaneously.

Separately: SerialUnit and UnitStepHistory already exist and model exactly this — a per-piece process history — but they're API-only (POST /api/v1/serial-units, POST /api/v1/serial-units/{unit}/steps), with no operator-facing UI to register a unit or generate a serial number, and recording a step against a SerialUnit has no effect on BatchStep.status today. The two systems are disconnected.

Proposed solution

Add unit-level execution as an opt-in mode alongside the existing batch-level flow — not a replacement. Batch-level execution and its existing traceability should keep working exactly as they do now for anyone who doesn't turn this on.

Suggested shape:

• A per-product (or per-process-template) switch — e.g. Execution mode: Batch | Unit — that controls how the operator queue drives step progression for that product's batches.
• In Unit mode, each piece progresses through steps independently (backed by SerialUnit + UnitStepHistory, actually wired into step state this time instead of being a side log).
• An operator-facing way to generate/enter a serial number at whichever step is designated to mint one — mirroring the existing LOT number UX on Create Batch (manual entry, or auto-generate via a configured sequence).
• Traceability/genealogy should reflect whichever mode a batch ran under.

Affected roles

• Operator
• Supervisor
• Admin

Alternatives considered

Replacing BatchStep's batch-wide status outright with per-unit tracking was considered and rejected — it would break the existing batch-level workflow and traceability for every line that doesn't need per-piece granularity. An additive, switchable mode preserves current behavior as the default.

Additional context

• Related but distinct: [feat] Operations with dependencies — sequential and parallel operation scheduling #15 (operation scheduling/dependencies — timing and predecessor rules between step types, not per-piece execution), [feat] "Components & serials used" product overview #78 and [feat] WO-time lot/serial picking (ERP-aligned) #84 (serial data exists in a read-only overview and for lot-based material consumption, but not for generating/progressing serials from the operator side).
• Checked against develop @ v0.22.0 — the gap described above is still present; the only adjacent recent addition is a batch_steps.passed_qty MQTT pulse counter, which counts throughput but doesn't gate or split per-unit progression.