[freeqaz-openai]

Summary

Retain runtime intent, allocation and an immutable initial gVisor Harness binding in State. An exact original operation can replay its retained receipt after intent advancement; a different operation cannot refresh or replace the binding.

New binding writes require the current running intent, expected generations and record version, exact target, and an unbound assignment. Binding and receipt share the original State transaction. Known failures, including caught authority failures, roll back both. A lost COMMIT acknowledgment remains an unknown outcome and requires exact original-operation readback and replay.

Caller integration

The current controller does not create or consume these records. The owning Agent/Token workflow and its integration proof remain required before landing this capability. Stored provider tuples do not authenticate observations, admit a runtime or establish successful token use. This component can be reviewed while that integration work proceeds.

Current main refresh

This update includes main at 14ad14c04deeeaa79f325b14d492ab13730adc7f, preserving Agent stop and the Go CLI. Runtime assignment and authority migrations follow the Agent stop migration; their SQL is unchanged, and the journal and fixture references match the new order.

• Focused memory and storage-contract suites: 18 passed, 0 failed, 0 skipped using the exact existing dependency graph.
• Project typecheck, workspace-boundary checks, documentation length, migration consistency, formatting of the resolution files, and diff whitespace checks passed.
• PostgreSQL migrations and database integration were not rerun locally for this head. Required hosted CI must assess this exact revision before merge.

Validation on the previously published head

CI run 35031071624 passed all seven jobs at head a8509edf670b018021957e25a9f8c8642913441d against main c7bbe7dc1ee0a2c3eec4f698391d891aaf6ae3ea. The tested merge has the same tree as the reviewed head.

• Memory and storage-contract suites: 18 passed.
• PostgreSQL assignment and authority suites: 6 and 18 passed, including limited-role constraints, independent-client races, rollback and real lost COMMIT acknowledgments.
• Native migration compatibility: 2 passed on the PostgreSQL 18.6 CI fixture.
• Typecheck, formatting, workspace, documentation, OpenAPI and the other required CI lanes passed.

These results establish source and storage behavior. Connected Agent/Token execution, installed runtime behavior and live-provider qualification remain separate acceptance work.

[kevinslin]

Currently, database mutations happen through APIs called by the OpenClaw control plane. Agent workload identities call neither the database nor those APIs directly. This runtime-assignment and authority model adds unnecessary complexity without a current consumer. If that interaction model changes, we can introduce the necessary architecture alongside it; adding it now is premature.

[kevinlin-openai]

Please consolidate the test organization and prune redundant coverage. The current five runnable files can become two test entrypoints plus shared support:

• tests/conformance/runtime-assignment.test.mjs: memory behavior, object validation, and SQL-schema consistency. Merge the three current fast entrypoints.
• tests/integration/postgres-runtime-assignment.test.mjs: both PostgreSQL suites, sharing setup while preserving named subtests and transaction isolation.
• One shared scenarios/seed module; inline the one-caller SQL-shape helper.

One runnable file would require a CI change or moving all fast checks into the database lane: scripts/ci/run-tests.mjs:269 rejects registering a file in both lanes.

Within that structure:

• Keep the shared authority race for memory, but use the stronger two-checked-out-client race as the sole PostgreSQL version.
• Check the PostgreSQL role/privilege prerequisites once, and combine fresh-pool historical readback with the real allocation COMMIT-loss case.
• Reduce the repeated changed-binding strings to one changed-instance case plus the unchanged-binding refresh case: an already-bound assignment is rejected before those strings are compared.
• Remove the tombstoned-Namespace/foreign-Agent scenario; it repeats wrong-owner rejection without establishing a reachable Agent-in-retired-Namespace lifecycle.

Preserve distinct scope isolation, immutable history, per-unit serialization, real database constraints, rollback, and both allocation-effect and authority-receipt recovery after lost COMMIT acknowledgments. Memory and PostgreSQL are separate implementations, so sharing scenarios is useful; dropping one implementation's behavior coverage is not equivalent consolidation.

Two concrete test issues are called out inline. This is a source-level audit of a8509edf670b018021957e25a9f8c8642913441d; the proposed consolidation has not been implemented or runtime-validated. The earlier concern about the capability lacking a regular production caller still stands.

[kevinlin-openai]

[P2] Remove coverage for the unused raw-JSON interface. These malformed-text cases only exercise parseRuntimeAuthorityJsonV1; the only call to that exported API is this test. The State repository uses parseRuntimeAuthorityV1 on objects (packages/occ/src/runtime-authority/repository.ts:202). Please defer/remove this test portion together with the unused raw decoder and scanner until an actual raw-JSON boundary needs them. Keep the used object-parser coverage and the PostgreSQL canonical-text tests, which exercise the real persisted-input boundary. The useful changed-version canonical identity assertion above can move into the shared replay case.

[kevinlin-openai]

[P2] Make this negative case reach the version constraint. The row gets a fresh operation_ref, but canonical_payload and receipt retain the original operation ID. The trigger rejects that identity mismatch at migrations/0017_runtime_authority.sql:247, before its version check at line 255, so this assertion still passes if version enforcement is broken. Build an internally consistent valid row on an unbound allocation, demonstrate that baseline succeeds, then change only the version invariant and assert the intended rejection. Normalize the adjacent foreign-owner case the same way: it also changes operation identity alongside the owner. Preserve the real SQL coverage; the problem is that the current fixture can fail for the wrong reason.

[kevinlin-openai]

Please add a new user-facing docs section called Audit and collect all audit-table information there, including the runtime records in this PR and the credential records introduced in #140. This should be the human-readable reference for what we retain, why we retain it, and how to interpret the entries.

Explain the purpose in plain English before introducing internal API names: these runtime tables retain requested Agent state, individual execution attempts, and the runtime initially associated with an attempt. The operation history also supports recovering the original result when a database commit succeeds but its acknowledgment is lost. Explain why the existing Agent state and audit records are insufficient.

The Audit section should:

• Describe each table, when entries are written, how the tables relate, which records are immutable versus updated, and what an operator can learn from them. Bring the audit-table reference material together here and link to it from the feature docs.
• Include a worked example showing the entries after an execution has been allocated and its runtime recorded. Show readable rows or JSON for occ.agent_runtime_intents, occ.agent_runtime_intent_heads, occ.runtime_assignment_allocations, and occ.runtime_authority_operations, with consistent IDs. Include corresponding credential-record examples for Retain credential records and exact claim bookkeeping #140, explaining what gets recorded without exposing credential values.
• Explain what happens on an exact retry after a lost commit acknowledgment, including which entries are reused rather than appended again.
• Distinguish implemented behavior from planned integration. The current controller neither produces nor consumes these runtime records, so label the example illustrative until it is backed by an owning workflow. Explain that storing the records does not itself start or stop a workload, authenticate a runtime, or grant access.

A reader should be able to understand the purpose and recognize the stored output without reading the implementation. The approval of #140 depends on these documentation changes being added in #138.

[kevinlin-openai]

Approved. Please add the Audit docs section and worked examples requested here: #138 (comment)