[PILOT-03] Create Submission and initial checker dispatch atomically #490

Outcome

After successful hidden preparation, one authorized operation consumes the ready ART admission, creates the immutable Submission and schedules its initial post-submit evaluation without any partially committed lifecycle effect.

Delivery and follow-up

The atomic composition was delivered by merged PR #504; this issue remains completed. The wording below reflects the newly agreed optional summary/attestation contract. Changing the request, validation and warning behavior is owned by PILOT-12 (#499), coordinated with the default checker in PILOT-04 (#491); it is not a claim that the optional-field change was delivered by PR #504.

Owners and dependencies

Preparation/evaluation input-capacity alignment is a prerequisite. Locate the ARCH-04E1B-B5 capacity-alignment change in the current ARCH plan and require its delivered capability, regardless of which implementation PR supplies it. Inspect backend/app/modules/tasks/submission_composition.py, tasks/post_submit_routing/, checkers/execution_coordination.py, ART public admission/binding contracts and AUTH receipt/outbox owners. Hidden packet custody is delivered; public submission creation/routing is not. Coordinate exact external execution contracts with PILOT-04 (#491), without waiting for the public upload surface in PILOT-12 (#499) or the closing drill in PILOT-09 (#496).

Implementation scope

• Compose Submission creation, consumption/binding of ready immutable ART admission, exact creation/binding/AUTH receipt custody, initial evaluation reservation, evaluation_pending transition and durable outbox dispatch in one caller-owned root transaction.
• Bind assignment, predecessor, optional summary and attestation, and complete locked context. Bind their exact supplied values or absence; omission must not fabricate values or weaken exact packet/replay custody. Build checker inputs from stored verified Submission lineage, not unchecked caller facts.
• Preserve TASK-before-CHECKERS custody, receipt identity and checked-input limits. Do not hold database locks while uploading, inspecting files, calling a model or executing a sandbox.
• Freshly authorize replay after creation and recover exact original IDs/binding/request; changed facts conflict. Outbox retry must dispatch the same request, not create another Submission/generation.

Leave alone

No public intake route, new artifact lifecycle, acceptance, guide activation, new policy semantics or fabricated checker result. No compatibility alias or independent commit inside participants.

Acceptance and how to check

• Real PostgreSQL/MinIO preparation leads to one correctly bound Submission, initial request and outbox event, with exact packet/policy identities.
• Inject failure at each participant boundary: all database effects roll back; admitted bytes remain under existing ART custody/recovery, never orphaned/unowned.
• Duplicate delivery/concurrent same-key calls create exactly one outcome; changed packet, foreign assignment/context and revoked replay have no effects.
• Crash after commit/before dispatch recovers from durable outbox; stale completion cannot mutate newer work.
• Intermediate lock-wait regressions preserve TASK-before-CHECKERS for result reads/admission as well as reservation.

Two-agent coordination

Agent 1 owns backend composition, database changes and the existing CHECKERS request/result contract. Publish the normalized contract with the backend slice of PILOT-04 (#491) before another lane depends on it; draft these contracts together if needed rather than letting initial dispatch and the external runtime invent different shapes. Real runtime delivery is a later hand-off.

Working and verification rules

Read AGENTS.md, CONTRIBUTING.md, docs/roadmap_status.md and the affected owner contracts before coding. The baseline inspected for this plan is main c0c4fe70f77e2e84347cec979e3de00e9d7f4295; recheck current main and open PRs before selecting a bounded implementation. Open/planned work is not delivered capability.

This is a planning issue and may require several bounded PRs. Record each PR's allowed files, prohibited changes, acceptance criteria and review scope using the repository's existing Commitrail process. Extend existing owner operations/typed public ports; do not add parallel legacy/new implementations or bypass authority. Preserve retained data, locked lineage, immutable evidence and caller-owned atomicity. A planning issue does not authorize deployment or merging a PR.

Run focused positive/negative tests and applicable repository checks. Use real PostgreSQL for database/locking claims and MinIO/S3 for storage claims. Add regressions that fail on the reproduced defect; do not skip failing tests or weaken CI. Run required full CI and affected independent review tracks before requesting human approval. Update affected current specs/ADRs, README/CLI contracts and roadmap in the same PR. Report exact tested head, commands, failure/cleanup evidence and remaining limitations; passing counts alone are insufficient.