spec_chunk_4_task_queue_assignment.md

Task Records and Assignment

Current boundary

Workstream is developing its first, unreleased v0.1. This specification covers the existing task-record and assignment foundation, including the bounded project-grant authorization replacement. CP08 delivers exact contribution-policy lineage through task, assignment and hidden Submission creation. ARCH-03C2 delivers exact assignment-invalidation publication and registered delivery. ARCH-03C4 delivers the three public task queues with exact project authority. ARCH-03C5 delivers distinct Contributor and Manager task detail and requirements. ARCH-03C6 exposes the three distinct locked-context reads with exact current grants. Public Submission cutover remains pending; the capability ledger identifies its owner.

Task responses and immutable command receipts contain no task-local payment amount, currency, payout type or guide-keyed payment-policy stamp. Compensation terms are governed by the locked ContributionPolicyVersion and resulting awards. TASK and Submission storage do not retain a parallel PaymentPolicy lineage.

Records and ownership

• ActorProfile and ActorIdentityLink are canonical actor and external identity records. Identity admission is not permission to work.
• AUTH owns ProjectRoleGrant, actor/link lifecycle and permission decisions. Submitter and reviewer are project roles, not separate worker profiles.
• WorkstreamTask stores the project, source and work description, state, assigned contributor and locked guide/policy references.
• TaskAssignment records the actual contributor and enforces one active assignment per task.
• Shared audit evidence records authorized transitions. Claim/start evidence identifies the canonical actor, assignment and exact authorization decision; it does not copy token roles or claim snapshots as authority.

Removing an obsolete endpoint does not delete retained rows. Remaining management/read and checker consumers must be traced before retiring shared identity, policy or submission storage.

Public task surfaces

Contributor commands and work context use canonical project authority:

Surface	Authority
GET /api/v1/projects/{project_id}/tasks/ready	Active same-project Submitter; active project; ready unassigned tasks
GET /api/v1/projects/{project_id}/tasks	Covering project or system Project Manager; management projection
GET /api/v1/operations/projects/{project_id}/tasks	System Operator; status-only operational projection
GET /api/v1/tasks/{task_id}	Active same-project Submitter; ready unassigned task or exact own active assignment
GET /api/v1/tasks/{task_id}/submission-requirements	Same exact Submitter authority; original locked policy requirements
GET /api/v1/projects/{project_id}/tasks/{task_id}	Covered Project Manager; exact project/task; all task states
GET /api/v1/projects/{project_id}/tasks/{task_id}/submission-requirements	Covered Project Manager; exact project/task and original locked policy
POST /api/v1/projects/{project_id}/tasks	Covered Project Manager; existing project; guide not required for draft
POST /api/v1/tasks/{task_id}/screen	Covered Project Manager; draft; approved active guide and complete policy lineage
POST /api/v1/tasks/{task_id}/release	Covered Project Manager; screening; frozen policy validation and nonblank decision reason
POST /api/v1/tasks/{task_id}/claim	Active same-project Submitter; ready, unassigned task
POST /api/v1/tasks/{task_id}/start	Active same-project Submitter; exact own active assignment
GET /api/v1/tasks/{task_id}/work-context	Active same-project Submitter; ready unassigned task or exact own assignment
GET /api/v1/tasks/{task_id}/guide/documents/{document_id}/content	Active exact own assignment and same-project Submitter; document must belong to task's locked snapshot; denied selectors concealed
GET /api/v1/projects/{project_id}/tasks/{task_id}/work-context	Covered Project Manager; exact route project and task
POST /api/v1/operations/tasks/{task_id}/start	System Operator; another contributor's active assignment and nonblank reason

ARCH-03C6 delivers the three distinct locked-context reads with exact current grants and removes their obsolete wrappers. ARCH-03C7 delivers bounded Audit Authority task history and removes the old unbounded task-only audit route.

There is no self-activation endpoint. A contributor cannot acquire permission by creating a worker profile, supplying skill tags, or presenting a token role. There is no public JSON-packet submission creation route. The existing GET /api/v1/tasks/{task_id}/submissions remains a read, not evidence that POST creation is usable. Admission-backed Submission creation stays hidden until its separate canonical public integration is complete.

Transitions and locked lineage

Stored task states use the canonical lowercase tokens:

draft -> screening -> ready -> claimed -> in_progress

• Screening requires the existing project/guide and task-content prerequisites and stamps locked policy references; release requires complete locks.
• Claim validates the task's locked context and creates one active assignment.
• Normal start cannot borrow another contributor's assignment.
• Operator start does not reassign ownership or create a contributor grant.
• Existing locked context remains tied to the attempt. A later guide or policy publication alone is not permission to rewrite that context.
• The guide's ContributionPolicyVersion is locked before work becomes claimable and copied through assignment and hidden Submission creation by CP08. Claim does not perform a fresh CON lookup.

For claim/start, the actor/action/idempotency-key receipt is reserved first; task and assignment are then locked, followed by canonical actor, identity link and applicable grant revalidation and locking. This matches hidden Submission creation's lock order. Authorization consumes the exact locked facts before writes. Product writes and their audit evidence commit or roll back together.

The receipt actor foreign key is checked at commit, after AUTH's actor lock; reservation must not take an earlier implicit actor lock that can deadlock parallel commands from the same actor. Referential integrity remains enforced.

Claim and start retries

POST /api/v1/tasks/{task_id}/claim, POST /api/v1/tasks/{task_id}/start, and POST /api/v1/operations/tasks/{task_id}/start require one UUID Idempotency-Key header. Retrying the same actor/action/key and semantic request returns the original typed success response only after fresh current authorization and exact task, active assignment and locked-context checks. Claim replay requires the task still be claimed; start replay requires it still be in progress. No duplicate assignment or lifecycle success event is created. A fresh AUTH decision records the replay's current authority check.

The key is not a permission. Revocation, suspension, a different assignment or an incompatible current task state yields the normal concealed denial. Only after authority succeeds may the caller receive 409 idempotency_mismatch for changed input or 409 task_replay_state_changed for inconsistent stored result/context. Keys are scoped by actor and operation, not by task: reusing a claim key for another task is a mismatch, not a second claim. The receipt and all business/audit writes commit or roll back together. Committed receipts cannot be modified, deleted or truncated through ordinary SQL.

Revocation immediately prevents subsequent contributor commands. Closing an existing assignment and returning a task to the ready queue through durable invalidation has a hidden ARCH-03B9 operation. ARCH-03C1 supplies real service authority; ARCH-03C2 supplies atomic producer wiring and registered delivery. A denied start is not proof that the Celery assignment-reconciliation handler has run.

Work-context hints

Hints describe the current supported contributor command, not permission tokens and not the full planned workflow:

• Ready and unassigned: claim.
• Claimed with the caller's exact active assignment: start.
• Otherwise: no contributor command hint.
• Management context does not advertise contributor commands.
• No submit or pre-submit execution hint is advertised by this surface while the canonical public submission integration remains hidden.

Pre-submission intake failures prevent Submission creation. Post-submission evaluation concerns the submitted work and supplies evidence for policy-governed routing; it does not own final acceptance.

ARCH-04E1A persists that successful evidence in one immutable route-neutral TASK source table and exposes detached source facts plus a source-neutral, accepted-effects Protocol. REV-04C supplies the hidden FinalAcceptance/TASK/CON participant and uses the bounded exact-source verifier, but no general routing publication writer/reader, handler, current pointer, routing authority or live TASK transition. ARCH-04E1B-B1 requires the existing CHECKERS coordinator to acquire TASK-owned Task/Assignment/latest Submission locks before reservation or current-result fences. Review admission INSERTs also take the project-qualified TASK lock before checker fences and foreign-key custody. Exact locked owner lineage is revalidated; terminal tasks permit only SELECT-only exact reservation replay, never a new generation or fence change. The adapter supplies this required guard without a reverse module dependency. No TASK status transition or execution authority is added. Before either true human admission or false automatic acceptance is published, the remaining ARCH-04E work must harden the same table with mandatory exact routing and owner-receipt custody and reject retained pre-authority rows.

Required verification

• Real exact-project grants permit the supported commands without a worker token role; missing, revoked, reviewer-only and foreign-project grants deny.
• Suspended/deactivated actors and revoked or substituted identity links deny.
• Non-owner starts, inconsistent assignments and invalid locked context deny.
• System Operator authority is distinct from Project Manager and token roles.
• Concurrent claims have one winner; revocation and commands serialize.
• Audit/storage failure rolls back task, assignment and authorization evidence.
• Work-context hints match current authority, state and assignment.
• Removed endpoints, activation schemas and runtime bridge have no consumers.
• Required intake, immutable lineage and retained-data regressions survive fixture migration; no helper fabricates public submission success.
• Boundary checks, applicable tests, hosted coverage and focused reviews pass before the implementation is declared ready.

Ready queue facts and public authority

ARCH-03B2 provides ReadyTaskQueuePort through TaskRepository: an internal data-owner read, not an HTTP route or authorization decision. It returns only ready tasks in one exact project with no assigned contributor and no active assignment. These predicates apply before (created_at, id) pagination and the bounded limit+1 query. Released assignment history does not hide eligible work.

The detached summary includes IDs, title, task type, difficulty, immutable skill tags, estimated minutes and creation time. It excludes source metadata, actor identity, policy bodies/hashes and artifact references. The project-bound cursor is a position, not a permission token. The read performs no flush, commit or row lock. Pages are live views, not reservations; claim rechecks authority and state.

ARCH-03C4 authorizes the exact project collection before calling this port or using a client cursor, with current-grant/revocation and concealment proof. No per-task AUTH handle or token role can substitute for that collection gate. ARCH-03B8 supplies bounded task audit evidence, exposed by ARCH-03C7. ARCH-03B9 supplies the hidden assignment-invalidation operation; ARCH-03C1 supplies its real authority. Producer wiring is delivered by ARCH-03C2; public evidence access by ARCH-03C7.

Management and operational queues

ARCH-03B3 extends the existing TaskRepository with ManagementTaskQueuePort and OperationalTaskQueuePort. Each reads all task states within one exact project, including draft, active work and post-submit states. These are internal owner facts; ARCH-03C4 supplies separate manager/operator permissions and public routes.

Management summaries contain task/project IDs, title, task type, difficulty, immutable skill tags, estimated minutes, status, deadline and creation/update timestamps. Operational summaries contain only task/project IDs, status and creation/update timestamps. Neither includes descriptions, acceptance/rejection text, source/import metadata, contributor identity, policy or artifact content. There is no token-role switch or caller-selected projection.

All three queues use the single TaskQueueRequest and TaskQueueCursor contract. Project/cursor filtering precedes bounded pagination; an extra row alone supplies continuation. The ready queue retains its independent eligibility filters. Cursors identify a live position, not authority, audience or membership. The owner reads do not flush, commit, roll back or take row locks. No counts, reservation or snapshot guarantee is supplied. The public composition validates live project authority before decoding a signed, audience-bound cursor, locks the actor, matched grant and project in the canonical order, and commits its authorization evidence atomically with response construction. Each page records the exact grant used; pagination never supplies authority.

Contributor and management task detail

ARCH-03B4 adds separate ContributorTaskDetailPort and ManagementTaskDetailPort reads to TaskRepository. Each requires exact project and task UUIDs. Contributor detail additionally requires a caller-bound contributor UUID and returns unassigned READY work or exact own-active-assignment work. Both task assignee and assignment contributor must match, with exact assignment task/project membership. Released history cannot confer access; it does not hide otherwise unassigned READY work. This is object visibility, not a permission decision. ARCH-03C5 establishes current exact authority before calling these owner reads and binds contributor identity from the request actor.

Both immutable detail values contain title, description, type, difficulty, tags, estimate, status, acceptance/rejection criteria, deadline and timestamps, with task/project identity. Manager detail additionally contains source type/ref/hash, import/external IDs and creator/assignee display facts. Contributor SELECTs never load those private columns. The ready summary and Contributor detail also expose one contributor-safe compensation block resolved from the task's exact locked_contribution_policy_version_id. Each accepted-submission and completed-review value is either unpaid or a list of instrument/unit/exact decimal-string quantity awards. No adapter binding, route key, binding status, policy lifecycle status, policy body, locked hash, artifact or retired payment field crosses the response. SQL filters project/task/visibility before returning a result; missing and invisible tasks both yield no result from TASK. CONTRIBUTIONS supplies the bounded detached terms through its public locked-version port. Reads do not flush, commit, roll back or lock the caller's work.

ARCH-03B5 reuses these ports in authorized work-context responses below. ARCH-03C5 also exposes their exact standalone Contributor and Manager reads, replacing the old broad detail wrapper. Command responses retain their existing contracts; no compatibility alias is added. ARCH-03B8 supplies the bounded audit evidence projection; ARCH-03C7 exposes it publicly under exact Audit Authority as described below.

Current contributor and manager work context

ARCH-03B5 replaces the response contracts of the existing authorized work-context routes. Their actions, actor binding, project authority and task/assignment/AUTH lock order stay the same. It does not activate other proposed ARCH-03C surfaces.

Both return task, project, guide, review_policy, revision_policy, and contribution_policy_version_id. Task uses the fixed 03B4 audience-specific facts (task_id, with no economic fields); guide owns version. The policy references reuse PROJECTS GuidePolicySelection: policy_id, generation, and policy_hash, taken from the validated historical activation receipt. The ContributionPolicy version is that same receipt's exact UUID, already checked against the task stamp. New guide activation does not replace an existing attempt's policy references. No CON lookup or economic rules are exposed.

Only contributor context has lifecycle, with assigned_to_current_actor and next_actions. Unassigned READY advertises claim; own CLAIMED advertises start; other own-active states have no action hint. Task status appears only in task.status. Hints never authorize execution. There is no can_submit flag or precheck capability; hidden submission creation is not advertised as usable. Contributor context also includes guide_documents: ordered document IDs, labels, media types, byte counts, SHA-256 and task-scoped authorized read references. It is empty for ready unassigned browsing and contains only exact locked originals for an active own assignment. It never includes task examples or provider keys. The document read uses distinct task.guide.read authority, not the broader ready-or-own work-context action. ART verifies complete original bytes before response exposure; provider/scratch cleanup is request-scoped. A newer guide activation leaves the task's current originals unchanged. Actual rebase behavior is owned by PILOT-08, not this read capability. Manager task facts include source/creator/assignee display fields, without contributor lifecycle or hints. The old shared work-context schemas and builders are removed, not aliased.

The read reuses complete frozen-policy validation and the existing AUTH decision inside its owner transaction. Successful reads persist their exact AUTH allow record, without changing TASK lifecycle/assignment/receipt state. Missing detail after authorization returns 404 resource_not_found and rolls that decision back; missing or invalid locked custody returns the existing 422 task_locked_context_invalid. Ordinary unassigned draft is not contributor work; a fully locked own-active draft remains visible under the existing authority rule.

Audit history authority is delivered by ARCH-03C7. ARCH-03C2 already delivers authority-loss assignment invalidation.

Task locked-context projections

ARCH-03B6 replaces the shared operator-labelled response with strict immutable ManagementTaskLockedContext, OperationalTaskLockedContext and AuditTaskLockedContext composites in TASK schemas. All contain task/project UUIDs and the exact historical guide version, source snapshot ID/hash, effective submission-policy ID/hash, pre-submit policy ID/bundle hash, post-submit policy ID/version/hash, review and revision ID/generation/hash and ContributionPolicy version UUID. Management alone adds the bounded post-submit summary (schema version, checker ID groups and blocking severities); its collections are immutable. Operational/audit results exclude bodies, work/source content, actor identities, artifacts, storage locations and economics.

ARCH-03C6 exposes these distinct GET routes (prefix /api/v1):

Route	Exact live authority
/projects/{project_id}/tasks/{task_id}/locked-context	Covering project/system Project Manager
/operations/projects/{project_id}/tasks/{task_id}/locked-context	System Operator
/audit/projects/{project_id}/tasks/{task_id}/locked-context	Covering project/system Audit Authority

The existing authorized command owner validates UUID selectors, filters project and task before acquiring a TASK row lock, then locks the active assignment, AUTH actor/link and exact role grant before historical PROJECTS custody. Its transaction contains PREP consumption, projection and response serialization; response or audit failure rolls back ALLOW. Read actions reject mutation/replay fields and do not impose a task-state allowlist. All nine persisted states require complete valid historical context, so an ordinary unlocked draft returns 422 task_locked_context_invalid. Missing, foreign-project and unauthorized reads conceal with the same 404. Nonhuman callers cannot reach TASK dependencies.

The shared historical validator checks exact activation receipts and stored policy bodies; a newer active guide never changes the result. Only Management receives the bounded checker summary. The old task-only route, role/creator wrapper and unused hidden locked-context wrappers are removed. Shared historical resolution remains for requirements. ARCH-03C7 delivers audit history authority.

Task submission requirements projections

ARCH-03B7 replaces the shared mutable response with strict frozen ContributorTaskSubmissionRequirements and ManagementTaskSubmissionRequirements in TASK schemas. Both contain the same safe task/project IDs, guide version, policy schema/merge identifiers, required packet/artifact/evidence fields, forbidden artifact rules, attestations, hashing/storage rules, size limits and packaging. Nested models are frozen and collections are tuples; JSON arrays remain arrays. Packaging exposes only package_required and optional allowed_package_formats, matching the effective-policy merge contract. No source metadata, actors, economics, storage object locations or complete policy bodies are exposed. A described format is not a claim of runtime support.

The management read reuses the existing historical context resolver. Contributor requirements first acquire the same exact project/task row lock, then reuse the existing detail visibility query, then resolve PROJECTS custody. A ready unassigned task with no active assignment is visible, including released assignment history; otherwise the task assignee and active assignment contributor must both match. Missing, foreign and invisible tasks conceal identically before policy reads. Invalid selectors reject before SQL. Both methods preserve caller transactions without implicit flush, commit, rollback or nested transaction, and keep original requirements after a successor guide activates. They grant no authority.

ARCH-03C5 exposes /tasks/{task_id}/submission-requirements only to exact Submitter authority, and /projects/{project_id}/tasks/{task_id}/submission-requirements to covering Manager authority. Both reuse the same safe historical requirement values, after locking TASK/assignment and consuming AUTH. The old role/creator wrapper is removed. There is no generic audience selector, compatibility alias or new compiler.

Bounded task audit evidence

ARCH-03B8 supplies AuditTaskEvidencePort through TaskRepository, delegating one fixed-column query to the shared audit owner. ARCH-03C7 exposes it through GET /api/v1/audit/projects/{project_id}/tasks/{task_id}/evidence, action audit.task.evidence.read, permission audit.read, restricted explicitly to a covering project/system Audit Authority grant. Other roles sharing that permission cannot read it. The old contributor/creator route and payload schema are removed. Submission and checker recovery retain their internal repository consumers.

The request binds exact project/task UUIDs and a 1..100 limit. Its cursor binds that same scope and (created_at, event_id). One TASK-left-join-AUDIT statement filters canonical project membership, lifecycle domain, task identity and cursor before limit+1. A missing or foreign task yields None; existing empty/exhausted history yields an empty page. Equal timestamps use event UUID ordering. This is one statement snapshot, not a durable export or current-at-return guarantee.

Items contain event ID/type, optional from/to status, stored actor attribution, creation time, and optional assignment/authorization-decision IDs. Canonical claim/start events require both references and exact nested project/task IDs; malformed evidence fails with a sanitized error. SQL selects reference scalars only for the typed audit writer and canonical claim/start event types; generic rows cannot acquire canonical provenance by copying their tokens. Other events gain no inferred references. SQL extracts only four named JSON scalar references and never loads raw claims, roles, external identity, reasons, arbitrary payloads or policy bodies. It does not export authority-decision history or claim forensic completeness.

The inner repository read is nonlocking and does not flush, commit or roll back. The public operation owns TASK -> active assignment -> AUTH actor/link -> exact grant locks and consumes PREP before the projection. Project membership is part of the task lock query, so wrong-project requests cannot wait on a foreign row. It validates and serializes the page before committing ALLOW evidence. Projection, reference or serialization failure rolls back that decision; failed audit writes prevent projection entry. No historical policy body is loaded, including for draft.

Public limit defaults to 50. Optional cursor is JSON encoding the returned next_cursor: exactly project_id, task_id, created_at, event_id, all strings. The parser caps raw input at 512 characters before decoding, rejects duplicate or extra keys, validates aware timestamps/UUIDs and requires exact route scope. It is an untrusted position, not authority; each page consumes fresh live authority. Absent anchor positions are valid. Invalid requests/evidence return sanitized 422; missing, foreign and denied requests conceal alike with 404. Later commands never rely on these read facts. There is no compatibility route or export subsystem.

Hidden exact-assignment authority invalidation

ARCH-03B9 supplies AssignmentInvalidationOperation and the transaction-owning TransactionalAssignmentInvalidationHandler. ARCH-03C1 supplies the canonical fixed-service AUTH/PREP implementation for the sole task.assignment.authority_reconcile action. ARCH-03C2 delivers atomic AUTH producer wiring and registers this sole production handler under enforced prefork delivery. ARCH-03C4 separately delivers the three public queues. ARCH-03C5 supplies detail and requirements authority; ARCH-03C6 supplies locked-context authority; ARCH-03C7 supplies bounded public Audit Authority history.

Each TaskAssignmentAuthorityInvalidationRequested event (protocol version 1) addresses one original project/task/assignment/contributor and one immutable AUTH invalidation event. AUDIT verifies the linked cause: Submitter grant revocation, profile suspension/deactivation or identity-link revocation. Reviewer/admin changes and reactivation are not assignment-release causes. Each cause must carry its canonical AUTH permission. The locked assignment must predate the invalidation's recorded mutation time. New claims and invalidations stamp their existing timestamps using PostgreSQL's clock after AUTH locks, so a transaction started earlier cannot make a replacement assignment appear eligible.

OUTBOX first independently verifies the complete committed invocation envelope. The effect transaction locks TASK, its exact assignment, feature authority, then OUTBOX event and attempt. The final owner fence checks a live lease and exact invoked generation after lock waits, retaining custody locks through commit. Validity is checked at fence acquisition; this does not freeze wall-clock time. No external I/O occurs after the fence. The dispatcher releases its own locks before calling the handler and never acquires TASK locks.

Only consistent active claimed/in-progress assignments without any Submission can become authority_revoked, with a release timestamp. TASK becomes ready and clears assigned_to; its policy locks and all prior work remain intact. Submitted/evaluation/review/revision work is unchanged. The existing manager release operation gains no additional transition or permission.

One deterministic TaskAssignmentAuthorityRevoked lifecycle event identifies the invalidation and original assignment and binds its exact authorization reference, bounded authority-facts snapshot and canonical resource digest. Both AUDIT and PostgreSQL recompute that digest and bind the exact assignment and invalidation references. AUDIT validates its immutable ALLOW decision, exact action/permission, actor, task/project and digest. The database additionally binds the immutable actor identity to the exact reconciler service. It commits with the effect and serves as the replay receipt. Historical replay does not recheck the service's current lifecycle status. An old event cannot select a replacement assignment; restoration does not restore closed work. The handler acknowledges only after its transaction commits. Malformed targets/causes and denied authority reject; uncertain effects remain shared OUTBOX UNKNOWN, without automatic reinvocation.

ARCH-03C2 publishes complete actor-wide/project fan-out in pages of 100, atomically with the AUTH mutation. It never backfills or dispatches retained invalidation rows: their transaction-start timestamps do not establish mutation chronology. Capture exact assignment IDs through a nonlocking TASK projection while authority locks serialize claim. Producers must not acquire TASK locks after AUTH locks. The registered handler uses dedicated workstream.outbox routing with enforced non-eager prefork execution. Real PostgreSQL tests prove originating publication, rollback and both claim/loss orderings; a real Redis and prefork drill exercises production delivery. Public queues are delivered separately by ARCH-03C4; timed contributor leases and voluntary skip remain deferred.

Manager readiness commands

Create, screen and release require exactly one UUID Idempotency-Key. Header validation precedes canonical actor resolution and product SQL; token verification and rate controls still apply first. Authority comes from a covering Project Manager grant, never token roles or task creation attribution.

Each command commits its task change, AUTH decision, shared lifecycle evidence and immutable replay receipt in one transaction. Create binds the project and full normalized payload; screen/release bind the task and reason. A retry rechecks live authority. An unchanged request returns its original result only while task state and locked context still match. Task advancement conflicts; activating a successor guide alone does not change the task's frozen policy selection. Separate actors and actions have separate replay namespaces. These receipts do not invent an assignment for manager work.

TaskCreated, TaskScreened and TaskReleased retain exact task/project/decision references without assignment. Creation retains source type; screen/release retain complete locked policy references. The bounded audit projection exposes its fixed scalar fields, including the decision reference, without private payloads.

A new command for an invalid task state is denied by AUTH with 403. A currently authorized replay whose task has advanced returns 409 instead of mutating it.

Exact detail and requirements authority

ARCH-03C5 replaces the broad task-detail response with the existing detached ContributorTaskDetail and ManagementTaskDetail contracts. The identifier is task_id, with no id alias; Contributor fields exclude source and actor facts. The separate Manager route retains management work instructions and source attribution without treating a Manager as a Submitter. Manager draft detail is available; requirements fail with task_locked_context_invalid if the task has no complete locked policy context.

Each read locks TASK and its active assignment before live AUTH actor/link and grant validation. Requirements then resolve historical PROJECTS policy custody. Current checker installation is not historical authority. Exact DTO validation and serialization occur before committing the authorization decision, which records the exact matched grant and a digest binding the locked TASK facts. Projection or response failure rolls back ALLOW evidence. A valid missing, foreign or denied selector has the same concealed 404; malformed UUID syntax returns 422. Nonhuman callers are rejected before TASK access. These reads do not authorize claim or submission, and no old role/creator wrapper remains for them. Retained submission reads now use the canonical history owner below; the obsolete TASK submission get/list/evidence-lock helpers are removed. The separate internal audit evidence reader remains for its recovery consumers.

The ready queue and standalone Contributor detail accept either active exact-project Submitter or Reviewer grant so both roles see both contribution types before work is claimed. Reviewer authority does not authorize claim, start, contributor work context, intake requirements or another contributor's claimed task. Revoked, missing and foreign-project grants retain the same concealed response.

Retained submission and checker history

Contributor path	Exact action
GET /tasks/{task_id}/submissions	task.submission.list
GET /submissions/{submission_id}	submission.read
GET /submissions/{submission_id}/checker-runs	submission.checker_run.list
GET /submissions/{submission_id}/checker-runs/{checker_run_id}	checker_run.read

Each has a separate manager path prefixed /projects/{project_id} and action prefixed project.. All paths use /api/v1. Contributor access requires current exact-project submission.read_own through a Submitter grant and immutable Submission ownership. Task history requires at least one owned Submission. Manager access requires project.task.manage through a covering Project Manager grant, including valid system scope; admin/token-role status is insufficient. Foreign/missing/denied resources share404. Services and agents are not admitted.

Owner-qualified target selection precedes the scoped TASK lock. AUTH then locks current actor/link, matched grant and Project. Detached fixed projections validate before caller-owned commit; query, validation or audit-write failure rolls back. No private artifacts or arbitrary metadata enter these DTOs. Lists return items and next_cursor, default25/max100. Submission order is (version,id); checker order is (created_at,id). Cursors bind actor/action/project/parent/limit and carry no authority. Every page reauthorizes.

The old manual checker POST and submission-finalize repair POST are removed, as are their queue/worker and token-role dependencies. This does not activate durable post-submit execution, routing or recovery. Existing assignment invalidation still refuses release after a Submission; retained-history tests do not introduce a new reclaim workflow.

TASK locked-context failures use the canonical error.code and error.details envelope; duplicate top-level code/details fields are removed.

Internal post-submit routing request reservation

ARCH-04E1B-A provides caller-owned request preparation for an exact current completed allow_review evaluation. TASK locks the project-qualified Task and its latest submitted Submission before CHECKERS locks its fence and run. The CHECKERS public coordination port verifies the supplied completion against retained result, event, phase receipts and material, returning closed verified completion facts with the stored Submission version and material custody. Neither completion values nor request facts grant authority.

task_post_submit_routing_requests reserves distinct generated routing-operation and future manifest UUIDv7 identities. Its canonical digest binds the exact owner, evaluation, result and completion selectors. Concurrent identical preparations recover the same IDs; replay repeats latest-submission/currentness verification. The caller owns commit and rollback. PostgreSQL independently validates custody, stamps creation time and forbids request update, deletion and truncation.

This is preparation only: no source manifest, current routing pointer, outbox publication, TASK transition, Review, FinalAcceptance or ContributionRecord is created by that preparation alone. ARCH-04E2-B now commits exact AUTH custody and complete governed outcomes through the hidden operation. Production delivery remains unavailable. Atomic publication binds the manifest to the reserved identity and verifies genuine immutable AUTH evidence.

ARCH-04E1B-B2 adds hidden exact source preparation. It requires the task's evaluation_pending state and active accepted assignment, resolves historical PROJECTS policy after TASK locks and before CHECKERS custody, and combines the verified completion with the existing reservation. A proposal contains semantic source facts only; the persisted manifest additionally requires its database creation time. No source INSERT or authority follows from constructing a proposal. B6 atomic Submission/dispatch sets evaluation_pending through the canonical operation. 04E2-B consumes that real lineage; production dispatch registration and public intake remain separate boundaries.

Checked packet custody at hidden creation

ARCH-04E1B-B4 forwards the canonical summary/attestation commitment from the actual Submission request to ART. Consumption rejects a different packet before binding or consumed replay. PostgreSQL also checks the final bound Submission against retained pre-submit evidence at commit, permitting the existing atomic insert-then-bind sequence. This does not activate dispatch or expose public intake.

Submission evaluation input facts

ARCH-04E1B-B5 extends the locked submission-context port with nullable acceptance criteria and the complete TaskPolicyLineage. TASK validates its retained post-policy body against its locked digest and uses the existing activation-stamp projection to reconcile every identity/hash/generation with historical PROJECTS facts. Missing criteria become empty checker text; no requirement is fabricated. The ART capacity check consumes these facts before durable admission. ARCH-04E1B-B6 reuses that bounded content with real record identities and fresh authorization in the existing hidden Submission command. Its caller-owned root transaction commits ART consumption, Submission, both exact AUTH decisions, the generation-one evaluation reservation, TASK evaluation_pending and one shared request event. Admission-scoped replay validates the original immutable owners under live authority without reserve or append calls; it cannot reset a later generation. Every new predecessor-linked Submission uses the same writer. Public intake and delivery activation remain deferred.

Hidden initial evaluation delivery

ARCH-04E1B-B7 recovers the exact immutable dispatch event and CHECKERS request. An independent committed-invocation read precedes execution. Each phase acquires TASK custody, fresh fixed-service AUTH, CHECKERS currentness, then the shared outbox invocation fence. Transactions close before ART provider/scratch work. Terminal replay validates retained execute/finalize receipts without reopening bytes. Uncertain execution does not renew an expired lease or request a retry; shared UNKNOWN handling preserves it for later authorized recovery.

The handler is unregistered. Completion routing, governed outcomes, remediation and public intake remain separate boundaries; this adds no Review or acceptance.

Hidden completion delivery

ARCH-04E1B-B8 connects the closed completion envelope to the existing TaskPostSubmitOutcome. The handler independently checks committed invocation, selects the server-owned lifecycle generation only for false policy, and invokes one root outcome transaction. TASK returns a strict immutable TaskRoutingOutcome; its exact scope and economic identities are revalidated before commit. ACK follows successful transaction exit, including deferred constraints. Malformed or closed invocations reject before owner entry; uncertain owner/commit failures remain shared OUTBOX UNKNOWN, never an automatic uncertain-effect retry. A still-current unfinalized invocation can replay the exact outcome with fresh authority. The true branch never observes REV generation or enters CON. Both request and completion handlers remain absent from production registration. Remediation and connected production readiness precede public intake.