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/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.