Skip to content

spec_chunk_4_task_queue_assignment.md

Latest commit

 

History

History
812 lines (688 loc) · 50.4 KB

spec_chunk_4_task_queue_assignment.md

File metadata and controls

812 lines (688 loc) · 50.4 KB
Raw

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 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. ARCH-02I-B exposes public ZIP preparation and admission-backed initial/checker-remediation Submission creation. The bounded local public API and Celery service drill has passed; the capability ledger tracks that proof.

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. Contributors upload one ZIP through the public submission-bundle preparation route, then the public POST /api/v1/tasks/{task_id}/submissions operation consumes a fresh ready admission through the canonical writer for initial work or exact checker remediation. The corresponding GET remains a history read, not creation authority.

Canonical Task-Import Sources

The published JSON schema defines workstream.task_import.v1: optional display metadata and 1..500 task rows. Each row has a required case-sensitive external_task_id (1..200 characters, no surrounding whitespace or control characters), nonblank title and description, and optional task_type, difficulty, skill_tags, estimated_time_minutes, acceptance_criteria and rejection_criteria. Text and collection bounds are part of the schema. Omitted or null task-local acceptance criteria remain optional through single and bulk SCREEN/RELEASE; the locked project guide supplies the governed requirements. Screening still requires nonblank title and description, active-guide custody and exact policy locks. Supplied criteria retain their schema type/length checks and exact text. External IDs must be unique inside the document; duplicate errors identify the zero-based row and the first duplicate's row. The parser accepts only strict UTF-8 JSON. It rejects a BOM, duplicate object members, non-finite numbers, NUL and unpaired surrogates. The source ceiling is 8 MiB.

Client conversions map category to task_type, languages/tools to skill_tags and the external source ID to external_task_id. ART retains the exact received JSON bytes and server-computed SHA-256/count, including formatting; a converted CSV is not claimed to be the original CSV. Callers cannot supply task state, locked guide/policy identities, creator identity or server provenance fields.

PILOT-02A supplies usable authorized declaration, upload, status and verified download through the ART source custody contract. These operations create no Tasks. Failed or abandoned declarations remain retained source records with no batch/task success claim. The separate atomic JSON-to-DRAFT import contract is below. Source custody alone still supplies no batch screen/release or CLI conversion.

Atomic JSON-to-DRAFT import contract

POST /api/v1/projects/{project_id}/task-import-batches accepts only a native source_id and the shared UUID Idempotency-Key. A covered Project Manager's first import reads and verifies actual provider bytes, parses the retained JSON, then creates one immutable native batch and every DRAFT Task in one root. Each row uses the normal authorized Task creation and TaskCreated evidence; a later row, audit, binding or uniqueness failure rolls back the complete batch. Case-sensitive project/external-ID uniqueness covers all non-NULL Task external IDs, including normal creation. Existing arbitrary import_batch_id strings remain metadata; only immutable native membership supplies batch custody.

The server stamps json_import, task-import-source:<source UUID>, the actual received-file SHA and the native batch UUID spelling. Normal manual TaskCreate cannot select json_import; row input cannot supply these labels or other provenance. Published difficulty values through 80 characters are preserved. The response retains original document order, optional display label and original Task creation facts; it does not transition or assign any Task.

After commit, same-key replay and a new key selecting the same actual project/ SHA/byte-count recover the original batch and Task IDs after fresh batch/source authority, even after Tasks advance. This recovery uses immutable native source/verification/acknowledgement receipts and performs no provider read or reparsing. A different source needs its own actual verified receipt; a claimed SHA alone cannot recover. Reusing the original key with a changed source selector conflicts even if both verified sources contain identical bytes.

GET /api/v1/projects/{project_id}/task-import-batches/{batch_id} returns original creation facts separately from current states selected by ordered native membership. Missing, foreign and revoked status access is concealed. The bounded implementation and required native proof are recorded in the atomic-import change record.

Explicit whole-batch screening and release contract

Separate POST /api/v1/projects/{project_id}/task-import-batches/{batch_id}/screen and /release accept a reason and exactly one UUID Idempotency-Key. SCREEN permits an omitted reason; RELEASE requires the normal nonblank decision reason. Both operate on the complete immutable native import membership, preserving original row order. Arbitrary Task.import_batch_id metadata cannot select members. Each actual Task consumes fresh covered-PM authority through the normal SCREEN/RELEASE owner, with all Task/assignment custody locked before authority and guide/policy evaluation. One caller transaction commits every member's normal transition, guide/policy locks, authority evidence and success receipt together; a late failure rolls back the complete successful effect set.

The compact response identifies project, native batch, operation and row count, then returns every ordered Task ID, row index, poststate, locked guide version, locked ContributionPolicyVersion ID and locked context hash. It repeats no Task instructions. SCREEN returns screening; RELEASE returns ready. The server records a separate aggregate retry namespace and retained canonical per-Task keys; callers cannot choose those row keys or attach old standalone successes.

Same-key replay reauthorizes every current member and recovers the exact recorded response only while all Tasks retain their corresponding poststate, unassigned custody and locked context. A partially advanced or assigned member refuses the whole operation, as does a changed reason, selector or member set. This differs from import replay, which recovers original DRAFT creation facts after Tasks advance. An uncertain client write requires manual replay of the unchanged project, batch, operation, reason and key; later authority or Task changes may prevent recovery. There are no automatic write retries or per-row commits.

The CLI keeps local CSV conversion, source declaration/upload/status, import, batch status, screening and release explicit. UTF-8 quoted CSV and semicolon skill fields produce validated canonical JSON; its exact bytes supply the uploaded SHA/count. The server retains those JSON bytes, with no claim to retaining the original CSV. Native aggregate DDL and the public 200/500-member journey are implemented in the bulk/CLI change record. Its historical native proofs name their exact sources; current-source verification and full hosted evidence are recorded separately in the PR. This contract does not claim deployment.

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 admission-backed 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 admission-backed 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 work-context surface; the separate public preparation and Submission operations perform their own fresh authorization.

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 shared FinalAcceptance/TASK/CON participant and bounded exact-source verifier. ARCH-04E2-B supplies exact routing authority and complete-effect custody; B8 supplies completion delivery, and the selected request/completion handlers are registered in production composition. No general public routing writer or reader is exposed. 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. True-policy success reaches review_pending; eligible false-policy success uses the shared acceptance operation only under a live REV generation. A typed pre-effect non-live refusal rolls back and uses bounded retry.

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; the public submission command performs its own fresh authority and admission checks. 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 routable 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. ARCH-04F2 admits the closed needs_revision recommendation alongside allow_review; no other recommendation is routable. 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 commits exact AUTH custody and complete governed success outcomes through the canonical operation; ARCH-04F2 extends that same operation with the exact contributor-remediation consequence. PILOT-04 registers selected production request/completion delivery. 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; selected dispatch registration and public intake are delivered by PILOT-04 and ARCH-02I-B respectively.

Checked packet custody at admission-backed 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. B4 established this owner boundary; PILOT-04 and ARCH-02I-B subsequently supplied selected dispatch and 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 canonical 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. ARCH-02I-B exposes public ZIP preparation and admission-backed Submission creation; PILOT-04 registers selected request and completion handlers. The bounded local public/worker drill starts from public guide inputs with recorded inference; hosted operation remains separate.

ARCH-04F3 names the supported predecessor-linked creation kind checker_remediation. TASK locks its task, assignment and latest Submission, selects the owner-qualified 04F2 manifest, and checks its exact completed current CHECKERS result and AUTH-backed consequence before ART reads replacement bytes. The same cause is rechecked at later preparation and consumption locks. The existing writer consumes only a ready admission carrying that cause and atomically creates the successor Submission, binding, exact AUTH decisions, generation-one reservation and request event. A replay under fresh authority returns the committed identities. Human-review revision has no uncaused runtime or replay path; its own exact Review source remains future work.

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.

PILOT-04 registers this request handler and the separate completion handler. B8 and 04F2 supply the governed success/remediation operation described below; ARCH-02I-B exposes public intake. Request delivery itself creates no Review or acceptance.

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 are registered by PILOT-04. ARCH-02I-B exposes initial and exact-cause checker-remediation intake over the 04F3 owner. New false/pass effects require a live REV generation; a typed pre-effect non-live refusal rolls back and uses bounded OUTBOX retry. The local public API and Celery service drill starts from public guide inputs with recorded inference; manager-visible setup-fault hold is separate safety work. ARCH-04F4 supplies separate hidden Operator retry of a known terminal infrastructure_failed checker run through the existing request handler. Fresh-authorized historical replay does not require the old run to remain current.

ARCH-04F2 extends this handler and the existing root outcome transaction for an exact current needs_revision checker recommendation. The manifest retains the recommendation and actual task.post_submit.route decision. When another revision remains, the effect is evaluation_pending -> needs_revision with the assignment active. On the final permitted failed attempt, PILOT-08 instead records exhaustion, closes the assignment and returns the task to ready; it creates no next preparation or timer. This branch is identical for locked human_review_required=true and false: it does not observe a REV generation, enter CON, or create a Review, FinalAcceptance, ContributionRecord or CompensationAward. Replay revalidates the stored source, receipt and complete outcome and returns their identities without repeating effects. Existing acceptance consumers admit only allow_review.

The operation adds no route or contributor response schema. Contributors use the existing bounded Submission/checker-history reads above. ARCH-04F3 supplies the exact-cause replacement Submission owner used by ARCH-02I-B public intake. PILOT-04 registers the request and completion handlers. The local public API/Celery drill starts from public guide inputs with recorded inference; manager-visible setup-fault hold remains separate work. The planned hold will retain the Submission and locked rules without contributor penalty; changing or re-screening submitted-task rules is deferred.