Work Done
Reviewed the annotated Factory controller changes in virdx/mono without editing the application worktree. Checked the one-worker dispatch path, Argo workflow naming and retry behavior, shared API and CLI operations, Pydantic response models, dashboard response types, Hatch wheel metadata, and deleted test wiring. Found that overlapping but nonidentical concurrent batches can claim different workflow names while processing the same case, the new wheel-installed CLI has no declared runtime dependencies, and the dashboard still permits invalid combinations of case state, output, and worker URL.
Factory lint, typecheck, and distribution builds passed. The dashboard TypeScript check passed. The CLI ran in the Pixi environment, while the built controller wheel reproduced a missing-FastAPI failure in a clean Python 3.12 environment. Tests were intentionally not run because the requested change removes them.
Lessons Learned: Pitfalls
A deterministic workflow name only provides an atomic claim for the exact data included in that name. Hashing a full batch does not prevent two different batches from sharing cases. A console-script entry point can also appear correctly in a wheel while the wheel remains unusable because empty dependency metadata is not exercised by the Pixi environment.
Lessons Learned: Improvements
A durable Factory architecture page should state the desired idempotency unit: campaign, batch, or case. It should also distinguish Pixi image dependencies from dependencies promised by built Python distributions. API contract guidance should require discriminated case-state unions in both backend and frontend types.