feat(agent-harness): persist command intents and execution receipts - #5647
feat(agent-harness): persist command intents and execution receipts#5647iscekic wants to merge 1 commit into
Conversation
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| ...state, | ||
| executions: [...state.executions, execution], | ||
| }); | ||
| const changed = readiness(); |
There was a problem hiding this comment.
WARNING: Post-commit readiness throws leave a durable unstarted execution fence
After the execution intent commits, a second readiness() call that returns a wait reason releases the fence; a throw does not. Grant expiry and a non-finite clock throw access_revoked inside that helper, and malformed bridge readiness throws from BridgeReadinessSchema.parse. execute never runs, run() still reports outcome "unsent", and the journal keeps receipt: null.
Later recover/dispatch only call reconcileReceipt, which returns null → unknown. blocksUnrelatedDispatch then rejects unrelated tools as well. This live dispatch still knows execute was not called — the same proof the wait-release comment describes. Catch this throw, release the fence, and return access_revoked rather than unsent.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (4 files)
Fix these issues in Kilo Cloud Reviewed by grok-4.6 · Input: 187.3K · Output: 25.5K · Cached: 436K Review guidance: REVIEW.md from base branch |
1 participant
No new behavior — The apps do not use this recovery support yet.
Summary
HarnessClientadds serialized recovery throughClientOptionsandCommandTransport;ClientResultandClientProblemdistinguish accepted, rejected, waiting, unsent, and unknown outcomes. Recovery never repeats uncertain effects;stale_revisionmessage rejections require explicit review, while non-retryableaccess_revokedandretiredrejections permit unrelated dispatch. Scope changes invalidate the client, storage failures block normal operations, and only a live readiness recheck can release a proven unstarted intent.Files
packages/agent-harness/src/client.ts— Added, 371 lines. AddscreateHarnessClientand queuedsubmit,recover,dispatch, anddisposeoperations. Injects scope tracking, storage, the bridge, the clock, and argument hashing; transport adapters must authenticate the supplied scope and reject ambiguous transport failures. Persists canonical commands before transport, then commits acknowledgments before removing intents; matching retries reuse replies, while changed payloads returncommand_conflict. Recovery processes stored receipts before evidence queries, replays pending commands with their original identifiers, and returns stale rejections untilreviewedCommandIdrecords explicit review. New dispatch checks ownership, the argument digest, expiry, tool state, and identifier reservations; it checks readiness before and after persisting the intent. Readiness loss before execution atomically releases only the current dispatch's intent; a crash leaves the intent unresolved. Existing executions retain their original grants and inputs; persisted receipts from another host take precedence over late executor results. Completion requires a matching stored receipt; invalid snapshots, revision regressions, or failed compare-and-swap block normal operations until recovery reads valid storage.JournalScopeSchema,CommandIntentSchema,CommandReplySchema,ExecutionRequestSchema,ExecutionIntentSchema, andJournalSnapshotSchemadefine strict, scoped records for commands, grants, receipts, and recovery.HarnessJournalrequires atomic durable reads and compare-and-swap writes; missing or corrupt storage is an error, never an empty replacement. A fresh storage generation requires a fresh client identifier; storage loss suspends the old registration and prevents reuse of its grants.Files
packages/agent-harness/src/journal.ts— Added, 125 lines. Adds inferred types and an immutable scope for the owner, client, and storage generation. Validates canonical input, acknowledgment identifiers, grant-to-tool matching, uniqueness, ownership, and stale-review links. Uses conversation and tool-call identifiers for execution keys;completionCommandrequires a receipt and retains the reserved identifier and grant generation. Rejects completions without matching stored receipts and review links that do not reference a stale rejection in the same conversation. Requires a single durable transaction for scope and revision checks, explicit false for no write, rejection of uncertain commits, and no memory fallback.ClientBridgeseparates execution from evidence-only receipt reconciliation; an unknown receipt never permits execution or grant transfer.BridgeReadinessSchemaandBridgeReadinessdefine availability, foreground, connectivity, unlock, and gesture gates; unknown connectivity or unlock state blocks execution. Adapters must recheck the account, grant, and gates at the effect boundary, return only confirmed outcomes, and never retry effects internally.Files
packages/agent-harness/src/bridge.ts— Added, 28 lines. AddsbridgeWaitReason, with wait priorityunavailable,background,offline,locked, thengesture. Separatesreadiness,execute, andreconcileReceipt;nullfrom reconciliation means the outcome remains unknown.Tests: 1 test file added,
packages/agent-harness/src/client.test.ts(+970 lines). The handoff reports 155 passing client tests and five passing scoped checks.Generated: 0 files changed.
Verification
Visual Changes
Visual Changes: N/A
Reviewer Notes
Human steps
None before or after merge.
Notes
E2E: This level adds command and receipt recovery without deployed consumers. Full runtime verification runs on the completed stack tip.
Stacked PRs — merge bottom to top. Each level shows only its own diff.
Runtime verification (E2E, user advocacy, simplify) runs on the tip PR over every level.
Every level keeps its own checks, its own bot review, and its own threads; each one is answered on its own PR.
Each level is its own deliverable: it builds and passes its own checks alone.
A finding on a level is repaired on that level, then carried upward with stack.sh forward.
shared-agent-harness-3bb0— chore(agent-harness): register workspaces and enforce CI boundaries #5632shared-agent-harness-3bb0-s2— feat(agent-harness): define portable domain and snapshots #5637shared-agent-harness-3bb0-s3— feat(agent-harness): define commands tools and permission policy #5639shared-agent-harness-3bb0-s4— feat(agent-harness): share client state and cursor recovery #5643shared-agent-harness-3bb0-s5— feat(agent-harness): persist command intents and execution receipts #5647 ← this PRshared-agent-harness-3bb0-s6— feat(db): add harness ingress grants and retirement fences #5655shared-agent-harness-3bb0-s7— feat(agent-harness): deliver legacy history and project durable text #5659shared-agent-harness-3bb0-s8— feat(agent-harness): authorize durable grants and registered clients #5662shared-agent-harness-3bb0-s9— feat(agent-harness): fence retirement and retry payload cleanup #5667shared-agent-harness-3bb0-s10— feat(agent-harness): persist authoritative state in SQLite #5675shared-agent-harness-3bb0-s11— feat(agent-harness): admit durable runs and revisioned commands #5678shared-agent-harness-3bb0-s12— feat(agent-harness): recover queued runs and stream checkpointed steps #5688 (tip)