Implement offline workload intake and record blocked owner dependencies

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1029c-c003-7283-acc9-930b434e6cae

docs/intake-dependency-requirements.md

@@ -0,0 +1,126 @@
+# Intake implementation and dependency acceptance — 2026-10-03
+
+Work record: INFD-WP-0005. These are requirements for owner implementation;
+this document grants no deployment or credential-custody change.
+
+Local implementation: `intake_service.IntakeService` is a separate WSGI app
+with only `POST /v1/memos`; `TokenReview` checks an injected Kubernetes response;
+`intake_approval.IntakeApprovalClient` sends create-only approval requests through
+a bounded transport. Store schema 3 migrates existing schema 1/2 databases and
+adds the submission ledger and integration outbox. Packet bytes, pinned memo,
+ready ledger and posed/notification jobs commit in one transaction. Terminal
+human dispositions queue hub resolution in their existing evidence transaction.
+`IntakeDeliveryWorker` dispatches injected audit, notification and hub transports
+with leases, stable ids, bounded retries and a disabled-by-default write-back.
+No listener is composed into the deployed runtime yet; shipped registries are
+empty, so no caller is admitted. No live deployment occurred.
+
+## railiance-platform — T05, T10
+
+Existing request: `cd811073-d6db-41cf-8a57-10df0b360eab`.
+
+Deliver a reviewed deployment change with:
+
+- ESO custody for `platform/workloads/informed-decision/sitting-requester`,
+  mounted read-only to the intake workload; exact-path read grant, sibling-path
+  refusal, safe secret metadata handling and no values in evidence.
+- Separate private intake port and Service, absent from public ingress;
+  NetworkPolicy admitting only registered submitter namespaces/service accounts.
+- TokenReview RBAC for the review workload, API-server CA verification and an
+  authenticated, bounded TokenReview transport. Project submitter tokens for
+  audience `informed-decision-intake`; do not reuse browser or audit tokens.
+- Project the reviewed JSON registries so removal is visible on the next request
+  without image rebuild. Review additions independently of the admitted submitter.
+- Workload OIDC client-credentials exchange yielding only `approval:create`,
+  subject `informed-decision`, platform tenant and service principal provenance.
+  Bind it to `IntakeApprovalClient`; no approve/read/consume scopes.
+
+Acceptance: wrong audience, unknown SA, removed grant and absent custody fail
+closed; one approved dev pose creates one human-control draft. Record immutable
+image/config references and founder approval before any live change.
+
+## access-engine — T06, T10
+
+Existing request: `306bcdd2-4fe4-4ccf-8aac-590c2abe51c4`.
+
+Deliver the §5.2 attribute admission branch, generated class/submitter data,
+drift check, exact-record compatibility branch and versioned request/response
+fixtures. Confirm field placement for review_group, memo_class, intake_submitter,
+approval_requester, approval_human_control, memo_version, approval_id and
+approval_binding_digest. Keep human authentication-derived identity, verified
+groups and act-time MFA freshness. No view_hash in PDP context. The approval
+fact must be read live and matched to the memo pin independently of an allow.
+
+Acceptance: unknown class/submitter, requester mismatch, false human_control,
+digest mismatch and stale MFA refuse; existing exact-record memos still work.
+Consumer changes must update both policy request construction and Store's strict
+policy-observation context comparison, with live engine reads before checks.
+Do not activate consumer attributes against the current exact-only pin. Signed
+PDP attribution remains the separately declared FLEX-WP-0024 gap.
+
+## approval-engine — T05 recovery and production close-down
+
+Existing request: `59c5ee82-c706-4432-bab4-24af64031d39`.
+
+Confirm native service creation response fields and optional requested_via.
+Provide idempotent creation or a lookup/recovery contract for lost create replies.
+Current local behavior reserves before POST: `creating` without a receipt returns
+`approval_create_unresolved` and never reposts. `created` with a persisted receipt
+can retry the atomic local load without creating another approval. An unresolved
+create needs owner-assisted receipt reconciliation; never manufacture a digest
+or infer approval state. Idempotent creation is a close-down requirement, not a
+condition on offline tests or initial dev rollout.
+
+## audit-core — T07
+
+Existing request: `23b670ac-809e-49bf-9233-e0b62cf0a039`.
+
+Register `informed-decision.memo.posed` for source informed-decision and tenant
+platform; accept the locally retained event envelope containing memo/approval
+ids, carried binding digest, authenticated forwarding submitter, memo class and
+submission digest. No packet, brief, or secret content. Confirm sender custody,
+Idempotency-Key receipts and heartbeat/reconciliation requirements for the new
+class. Provide positive/duplicate/refusal fixtures. Only then connect posed
+jobs to AuditCoreSink and include the class in runtime readiness/reconciliation.
+
+## state-hub — T07, T08
+
+Existing request: `e30dea31-90e3-4fc0-954a-ed8412b52aca`.
+
+Deliver forwarding with the projected intake-audience SA token, bounded envelope,
+stable idempotency key, durable retry and receipt retention. Identify the actual
+SA to review into the submitter registry. Forwarding proves the hub identity;
+drafted_by remains asserted and must be visibly described that way. Add a dev
+fixture for pose/replay/conflict and a deduplicated notification contract using
+our stable delivery id. Notifications carry only id/question/class/submitter;
+the signed-in overview is the authoritative review entry point.
+
+Confirm resolve semantics: terminal human accept/decline only; return/discuss
+and resolves: never do not resolve. A 409 must allow reading an existing
+resolution to correlate it. Delivery failure retains local evidence and retries;
+other-memo conflicts block for review. Bind the hub transports and schedule
+IntakeDeliveryWorker in the runtime after these contracts are accepted. Keep
+INFD_HUB_WRITEBACK unset until deployment approval and end-to-end evidence.
+
+## gate-house and founder — T09, T10
+
+Reply `4a290496-5aa7-4488-a01d-f8fde925a54b` answers the doctrine check: no
+human act is required when posing. GH-DEC-2026-023 is still proposed; this reply
+is not a ratified decision or live rollout approval. Spec now records C1–C6 and
+F1–F3. Production close-down additionally requires authenticated drafting
+identity, independent list review, signed claims/receipts, volume budgets and
+retirement of exact-record admission after its memos become terminal.
+
+T10 resumes after T05–T08 acceptance and founder approval for the concrete
+rollout. Record dev positive/negative traces first, then one live human answer
+with audit and write-back receipts. The provisioning sitting's human binding
+remains blocked in INFD-WP-ADHOC-2026-10-03-T02.
+
+## Verification
+
+`uv run --extra dev python -m pytest -q`: 437 passed, 67 skipped (optional
+component fixtures are not enabled in this run). After the final receipt-recovery
+concurrency guard and nonempty-entry response refusal, the affected intake,
+runtime migration, durable store and write-back suites: 63 passed, 1 skipped.
+`git diff --check` passed. State Hub consistency reconciled the blocked plan,
+completed T04/T09 and waiting T07; no registrar fallback was required.

docs/specs/FrictionlessDecisionIntake.md

@@ -137,8 +137,8 @@ idempotency_key})`. The ledger key is `(submitter_id, idempotency_key)`:
 - a memo id already in the store under another key → `409 memo_id_taken`.
 
 The ledger row is written **before** the approval-engine POST with state
-`creating`, and finished after. A crash between the two leaves a `creating`
-row that a retry resumes; see §4 for the orphan-draft gap.
+`creating`, and finished after. A crash before receipt retention leaves a `creating`
+row that refuses automatic retry; see §4 for recovery requirements.
 
 A new version of a memo is a new submission with a new memo id or an explicit
 `supersedes` relation in a later version of this contract; intake never
@@ -172,9 +172,10 @@ only through the attended reader lane. The change:
 What approval-engine would ideally add (requested, not blocking):
 
 1. An `Idempotency-Key` on `POST /v1/approvals`, so a retried create after a
-   crash returns the same draft instead of leaving an orphan. Until then intake
-   resumes `creating` rows by looking up its own receipt, and an orphan draft
-   is harmless (never bound, expires).
+   crash returns the same draft instead of leaving an orphan. Until then a `creating` row without a receipt requires explicit
+   owner-assisted reconciliation and never automatically repeats creation. A
+   `created` row with a durable receipt retries local loading only. An orphan
+   draft is never bound and expires.
 2. An optional, non-binding `requested_via` evidence field so the engine's
    own record names the original submitter.
 
@@ -337,3 +338,38 @@ satisfy the doctrine the exact-record list was serving.
 The operator scripts (`create_sitting_approvals.*`, `attach_compact_bindings.py`,
 `load_sitting_memos.py`) stay as the fallback until phase 3 is live, then
 retire.
+
+## 11. Doctrine response and local implementation — 2026-10-03
+
+Gate House reply `4a290496-5aa7-4488-a01d-f8fde925a54b` confirms no human act
+is required at posing time. Draft GH-DEC-2026-023 remains proposed and awaits
+the founder's ruling. The response imposes these requirements now:
+
+- C1: PDP allow is eligibility only. MUST read the approval live and compare
+  approval id and native digest with the memo pin; never obtain approval fact
+  from an allow.
+- C2: view_hash MUST NEVER enter PDP context. The binding digest MUST come from
+  the engine's live response and MUST NOT be recomputed here.
+- C3: every intake-created approval MUST have human_control true; no class may
+  override it. PDP MUST deny false. Principal identity stays authentication-derived.
+- C4: removing a submitter from runtime data MUST refuse the next pose without
+  a policy image rebuild, including attempts to replay previously accepted data.
+- C5: submitter/class additions MUST be reviewed commits by someone other than
+  the submitter being admitted. Local allow-list refusal grants no PDP permission.
+- C6: state-hub submitter proves authenticated forwarding only. drafted_by MUST
+  remain visibly asserted; loopback hub access does not authenticate the drafter.
+
+Findings F1–F3 remain open: PEP-asserted admission facts require independently
+verified signed claims/receipts at close-down; ungated posing can flood human
+attention; hub notifications can impersonate a review request. Intake now
+requires a configured positive per-submitter daily budget. At close-down the
+budget is mandatory, the authenticated overview is authoritative, notifications
+carry ids, and terminal exact-record memos lose the compatibility branch.
+R2/R5 re-arming includes authenticated drafting identity and independent grant
+review. The unsigned PDP attribution gap remains explicitly declared.
+
+The offline service and its durable integration worker are implemented; shipped
+registries are empty and transports are injected. Runtime composition and live
+acceptance remain blocked on the owner requirements in
+`docs/intake-dependency-requirements.md`. These requirements do not arm a live
+control or grant custody/deployment approval.