Retained attempt request content

Offline Store foundation. This optional journal retains caller-supplied content for a previously committed target intent. Retaining bytes does not execute a provider task or certify that the request is complete, secret-free, eligible or suitable for publication.

Explicit extension

open_acquisition_attempt_request_store opens one supplied native handle with the existing identity and finite operator limits. Defaults remain owns_handle=False and initialize=False; handle is keyword-only. Existing input and intent factories, protocols and command fingerprints remain available. The new AcquisitionAttemptRequestStore extends the intent interface with retain_attempt_request and get_attempt_request.

Its trusted CurrentAcquisitionAttemptRequestGrants adapter adds authorize_attempt_request_write(intent: CommandIdentity) and authorize_attempt_request_read(intent: CommandIdentity). New admission and content reads also require current read_inputs for the original frozen run. The decisions must agree on principal, scope and current persisted authority generation. A namespace, digest or metadata receipt conveys no content access.

Exact content and identity

Value	Fields
RetainAttemptRequest	key, original intent receipt, body_json bytes
AttemptRequestRef	complete request command identity, original intent receipt
AttemptRequestReceipt	request reference, body_digest, body_length, charged_payload_bytes
AttemptRequestRecord	metadata receipt, original body_json bytes

The command key belongs to the same Store incarnation and scope as its intent and frozen run. Its sequence follows both. identify_command(request) computes the complete original fingerprint before persistence, including the body bytes. The kind is retain_attempt_request. The receipt's reference is also known before dispatch; recovery does not require learning an identifier afterward.

body_json must already contain one canonical UTF-8 JSON object. The Store validates the supplied bytes rather than normalizing them. Canonical encoding uses sorted keys, comma/colon separators, ensure_ascii=False and finite numbers. Duplicate keys, invalid UTF-8, unpaired surrogates, noncanonical numeric spelling, trailing data and scalar/array roots are refused. The parser bounds nesting, collection cardinality and numeric tokens before conversion. The technical raw-byte ceiling is 16 MiB; effective operator request, control and payload limits can be smaller. These are implementation bounds, not live trial policy defaults.

Atomic admission and recovery

New admission verifies the exact applied parent intent, original frozen target and requirements inside the same native transaction as current permissions and the write. A bounded scan validates the committed command history and rejects a second request body for the same intent. Missing, malformed or inconsistent committed history refuses safely; an unrelated corrupt later record cannot be ignored after finding an earlier duplicate.

The operation writes one immutable command record. Retrying the same key and complete fingerprint returns its original metadata receipt. A changed body or binding conflicts. Different request keys cannot attach a second body to the same intent. This is local journal uniqueness; it is not provider idempotency or proof that any remote task exists.

After an uncertain acknowledgement, recover the same original command identity. An observed absence does not establish that an outstanding original transaction cannot still commit. Recovery does not authorize allocating another key or submitting a provider task.

Operation	Current permission	Returned content
New retain_attempt_request	Explicit request write plus frozen-run read_inputs	Metadata receipt
Exact retain replay	Original command inspect	Original metadata receipt
recover_command	Exact original command inspect	Metadata or observed absence
get_attempt_request	Explicit request read plus frozen-run read_inputs	Verified original body and receipt

Inspect-only recovery exposes no body bytes. An unavailable or malformed new grant method refuses safely; a closed client or actual native persistence failure raises the existing fixed AcquisitionPersistenceError. Known access, conflict, capacity and retained-data corruption return fixed Refused results. Supplied invalid or over-limit input raises AcquisitionInputError; direct DTO construction may raise Pydantic validation errors. Native failures cannot be reported as known absence or successful content recovery.

Capacity and profiles

The single command record contains a private payload field. Its complete encoded record must fit max_record_control_bytes. The stored base64 payload also charges 4 * ceil(body_length / 3) bytes against the existing retained payload budget; reserved plus retained bytes must remain within that budget. Admission advances command count and sequence once. It introduces no table, index, migration, default quota, pending reservation, payload slot or TTL.

History work is bounded by the existing maximum 256 commands and by the smaller of 16 MiB or max_commands * max_record_control_bytes aggregate record bytes. Exact historical reads and replay do not rescan unrelated history. They and previously reserved staging cleanup remain available at full command capacity. There is no request retirement, automatic deletion, refund or key reuse policy.

All five existing acquisition profiles share this interface: explicit memory, SQLite, PostgreSQL, supported unsharded transaction-capable Mongo replica sets, and supported standalone Redis primary/no-replica/noeviction deployments. Profile checks do not qualify deployment durability; memory is process-local and Redis admission does not certify AOF persistence.

Trusted preparation supplies non-secret content; this byte-retention API does not certify secret freedom or provider completeness. No provider adapter, dispatch, remote IDs, outcomes, worker lease, factual verification, evidence policy, publication or live budget enforcement is added. Those remain open in the existing backlog.

The optional supplied-report journal retains immutable JSON claims against an exact request, with separate report permissions. Those claims confer no factual, evidence or execution authority.