[SaulBuilds]

Board item: C1-V3-R · agent-runtime: read outcome/txHash/message on approve so capsules see "submitted, outcome unknown"

Why

citrate-core PR #366 (C1-V3) releases a payment that the member approved but whose broadcast had no known outcome. It sends that payment through the sidecar's approve route as {id, outcome: "submitted_outcome_unknown", txHash, message} (resolve_head_outcome_unknown in src-tauri/src/hermes.rs). The sidecar read only id, so the decision record said Completed and the capsule was never told what happened.

What changed

Data source (Rule 7): citrate-core's signature ceremony, through hermes_resolve_outcome_unknown → POST /approvals/approve.

• Approve route (sidecar): parses the optional outcome, txHash and message fields.
  • If they are absent, the route behaves as it does today: a plain approval, closed as Completed.
  • It returns 400 before anything is recorded or resolved when: outcome is not submitted_outcome_unknown; txHash is not 0x + 64 hex; message is empty, over 280 bytes, contains control characters, or leaves out the hash; txHash/message arrive without an outcome; or any outcome is sent on /approvals/reject (an unknown outcome is never a rejection).
  • txHash: null is accepted, which is what core sends when it has no hash.
• Capsule result: the eth-send host fn returns Err("ChainSendOutcomeUnknown: <core's message, verbatim>"). That is a non-final result, not success. The dispatcher is never consulted, so nothing gets sent twice.
  • New ApprovalGate::decide → GateDecision (the default mirrors request, so existing gates keep their meaning). QueuedApprovalGate::request never returns Ok for an unknown outcome.
• Decision record: the record keeps decision = Approved and closes with outcome outcome_unknown and detail Submitted · outcome unknown (tx 0x…), or (tx not known) when there is no hash. If the call was no longer waiting, the record still closes as outcome_unknown, because the transaction went out from core either way.
• No auto-retry: the queue remembers the last 256 unknown-outcome call ids.
  • The call id is keccak(capsule|method|to|data), so a capsule retrying the same payment produces the same id.
  • When an identical payment is proposed again, it skips the auto-grant fast path and waits for the member.
  • /approvals shows that card with priorOutcomeUnknown: {txHash, message}, and its summary ends with "an earlier identical request was submitted, outcome unknown (tx …); check it before approving again".
• Queue API (citrate-agent-core::hitl):
  • UnknownOutcome (validated constructor)
  • approve_by_id_outcome_unknown
  • submit_with_resolution → Resolution
  • ApprovalOutcomePublic::SubmittedOutcomeUnknown; submit() returns false for it
  • PendingView.prior_unknown

Tests (red first)

The red run was a compile failure (37 errors) of the new tests against main, before any implementation.

• cargo test -p citrate-agent-core -p agent-sidecar: 879 → 898 passed, 0 failed, 7 ignored (+19).
  • agent-sidecar/src/outcome_unknown_tests.rs (7): exact message reaches the submitter; the plain submit is not approved; the record says Submitted · outcome unknown; the null-hash path; id-only keeps today's behaviour; 13 malformed bodies refused with nothing resolved or recorded; a re-proposal references the earlier tx and is never auto-granted.
  • hitl/outcome.rs (4) and hitl/mod.rs (5): validation, resolution, a head mismatch, a re-proposal skipping the grant, the bounded memory.
  • capsule/mod.rs (2): the capsule gets ChainSendOutcomeUnknown: <message> and the dispatcher is never called; the default decide mirrors request.
  • prod_impls.rs (1): the queued gate passes the unknown outcome through, and request() is never Ok.
• cargo fmt -p agent-sidecar --check is clean. The new and changed core files I could format in isolation were formatted. agent/core already fails cargo fmt --check on main, and I did not reformat unrelated code.
• cargo clippy --all-targets for both crates gives the same warning counts as main; no new warnings.
• Pushed with --no-verify: the pre-push hook fails because PyYAML is missing (unrelated to this change), so I ran fmt, clippy and tests by hand.

Cross-repo (Rule 12)

No [[drift]] entry is needed. citrate-core does not pin citrate-agent-runtime: scripts/build-hermes.sh builds the sidecar binary from the sibling checkout's HEAD and records the rev next to the binary. There is no Cargo dependency and no manifest pin. Core #366 already sends these fields, so the wire contract matches with no core change.

Gaps (not in this PR)

• When core approves with only {id} (the normal success path), the sidecar has no eth-send dispatcher, because it holds no keys by design. A capsule's approved eth-send therefore still returns ChainSendDispatchFailed: no eth_send dispatcher configured rather than the tx hash. Fixing that needs core to send txHash on a confirmed approval too, which is a separate item.
• The approval state-machine TLA+ spec (ApprovalStateMachine.tla) does not model the new resolution. Behaviour on the existing transitions is unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_0148EsKJD57GeaM8JwAraU3N

[SaulBuilds]

[DGX] APPROVED at 506b779

DGX review of #86 (C1-V3-R). I read main...506b779 (one commit, 8 files, +1096/-49) in a detached worktree, together with the core sender in citrate-core#366 @ 7991755 (resolve_head_outcome_unknown, broadcast_outcome::{is_tx_hash, agent_message}). Tests ran inside unshare --user --map-root-user --pid --fork --mount-proc.

Verdict: approve. On approve, the sidecar reads outcome, txHash and message. The capsule gets ChainSendOutcomeUnknown: <core's words> and never ChainSendApprovalRejected. The dispatcher is never called. The decision record closes OutcomeUnknown, never Completed. Nothing blocks.

Wire match with core #366

Field	Core sends (hermes.rs resolve_head_outcome_unknown)	Sidecar reads (requested_outcome)	Match
route	POST /approvals/approve (never reject)	approve only; any outcome on /approvals/reject → 400	yes
id	call id	requested_call_id (unchanged)	yes
outcome	"submitted_outcome_unknown"	must equal OUTCOME_SUBMITTED_UNKNOWN	yes
txHash	Some(h), pre-checked by core's is_tx_hash (0x + 64 hex), or JSON null	0x + 64 hex (same predicate, byte for byte) or null/absent	yes
message	agent_message(h) = submitted, outcome unknown, tx <h>, check before retrying (~108 bytes), or the no-hash sentence	non-empty, ≤ 280 bytes, no control chars, must contain h verbatim	yes: core embeds the same h string, so mixed-case hashes pass too

Core's 409 handling (forget_call) lines up with the sidecar's CONFLICT when the head moved. On that path the sidecar still closes the record as OutcomeUnknown and remembers the call id, which is right because the transaction went out.

Capsule path (the goal of the item)

• linker.rs eth-send: gate.decide(req). SubmittedOutcomeUnknown(msg) → Err("ChainSendOutcomeUnknown: <msg>") returns before the dispatcher.
  • Test eth_send_capsule_reports_an_unknown_outcome_and_never_dispatches asserts zero dispatcher calls.
• QueuedApprovalGate::request maps the unknown outcome to Err(message), never Ok. Any legacy caller of request therefore can't perform the effect a second time.
  • Test queued_gate_passes_an_unknown_outcome_through covers both decide and request.
• Role track: ApprovalOutcomePublic::SubmittedOutcomeUnknown maps to the generic no-hash sentence. That fails closed (never approved, never "rejected by operator").
• The only production submitter is prod_impls.rs → submit_with_resolution. git grep shows no other non-test caller of submit / submit_with_outcome, so the submit() == false meaning can't leak "rejected" to an agent elsewhere.
• Re-proposal guard: a call id with a remembered unknown outcome skips the trusted auto-grant and waits for the member. /approvals carries priorOutcomeUnknown{txHash,message} and the summary note names the tx.

Rule 12 / [[drift]]

I checked citrate-federation manifest.toml on main. There is no [[drift]] entry with consumer = "citrate-core" and dep_repo = "citrate-agent-runtime". Core has no Cargo dependency on the runtime: scripts/build-hermes.sh builds the hermes externalBin from the sibling checkout's HEAD and records the rev. So the PR's claim holds: Rule 12 (drift entry before a Cargo pin) isn't triggered, because this PR adds no pin.

Follow-up (non-blocking, federation owner): core #366 now relies on this sidecar behaviour. With an older sidecar, the approve still closes as Completed and the capsule gets ChainSendDispatchFailed. That is not "rejected", but it is not the C1-V3 outcome either.

• The hermes externalBin is unpinned. node-agent has the precedent pin_field = "externalBin:node-agent".
• I suggest adding a [[drift]] consumer="citrate-core" dep_repo="citrate-agent-runtime" file="scripts/build-hermes.sh" pin_field="externalBin:hermes" entry. The 0.5.2 release build should then be proven to bundle a sidecar ≥ the merge of this PR.

Non-blocking notes

1. The memory of unknown outcomes is in-process (256 ids). After a sidecar restart, an identical re-proposal of a trusted call can be auto-granted again. That is acceptable for this item, because core's ceremony still signs every chain effect. Please note it in the TLA+/gap list next to the one already in the PR body.
2. approve_by_id_outcome_unknown remembers the id before it checks the head, so a bogus id (from a bearer holder) also takes a slot. It is bounded at 256 and bearer-gated, so this is fine.

Tests (DGX, at 506b779; rustc 1.98.1, because wasmtime 49 needs ≥ 1.96)

Ran cargo test --no-fail-fast -p citrate-agent-core -p agent-sidecar:

	passed	failed	ignored
PR	893	1	7
main @ 75e21cd (same sandbox)	874	1	7

• +19 tests, which matches the PR body's count.
• The one failure is the same on main and so not caused by this PR: auto_approve_tests::off_the_list_or_outside_a_project_it_still_asks (asked 3 of 4; npm install isn't asked inside the user-namespace sandbox). It comes from feat(sidecar,shell): HGW runtime stack #80–#84 (project write policy, project_create, 24-step turns, auto-approve, git safety) #84's shell sandbox and depends on the environment.
• The PR body says 898 passed. Its run is outside unshare, so the totals differ by environment.

Ran cargo clippy -p citrate-agent-core -p agent-sidecar --all-targets: the same warning counts as main (legacy 5, core lib 13, core lib test 18), so no new warnings.

Ran cargo fmt -p agent-sidecar --check: clean.

Stub-proven vs contract-only

• Stub-proven (in-process): sidecar route parsing and the 13 refusal shapes, the record outcome, the queue resolution, the capsule result string, no dispatch, re-proposal gating.
• Contract-only: the end-to-end core #366 → real sidecar → capsule path. There is no cross-repo test, and #366 is still open. M7-style proof needs a Core build bundling this sidecar.

[BerryManifold]

Automated Codex static review of 506b7799ac4e3872076c9f72863f0ddf8739d99d is complete. Approval is withheld pending private security review. Details and coverage limits are recorded in the project's private review log. No tests were executed by this reviewer. Both account submissions represent the same Codex review, not independent reviews.

[Matr0xshka]

Automated Codex static review of 506b7799ac4e3872076c9f72863f0ddf8739d99d is complete. Approval is withheld pending private security review. Details and coverage limits are recorded in the project's private review log. No tests were executed by this reviewer. Both account submissions represent the same Codex review, not independent reviews.

[SaulBuilds]

[MAC] Addressed at 5782a76

Both Codex P2s at 506b779 were real and are fixed. Red 8f9d459, fix 5782a76. No rebase: the two commits sit on top of 506b779.

Finding	Commit	What changed
P2 agent-sidecar/src/lib.rs:711-718: a failed decision record returned 503 before the unknown outcome was delivered	5782a76	For an unknown outcome, a record failure is logged and the outcome is still delivered to the waiter and remembered for re-proposals. The reply is 200 {"resolved": true, "outcome": "submitted_outcome_unknown", "recorded": false}. A plain {id} approval still refuses with 503 (write-ahead).
P2 agent-sidecar/src/lib.rs:754-765: a late callback (waiter gone, or another call at the head) wrote no receipt	5782a76	The route writes an approved ceremony.capsule_effect decision bound to the callback's call id (evidence sidecar:approval/<id>) and closes it OutcomeUnknown with "Submitted · outcome unknown (tx …); the call was no longer waiting, so the capsule was not told". It still answers 409 and resolves no other entry.

Refactor in the same commit: record_ceremony_decision takes the call id and subject, so a receipt no longer needs a pending view. The new hic_records::try_record_outcome reports whether the outcome was written. record_outcome is unchanged for every other caller.

Standard

• Red commit: 8f9d459. Four tests fail on assertions against 506b779:
  • an_unknown_outcome_is_delivered_even_when_the_record_cannot_be_written (status 503, not 200)
  • a_late_unknown_outcome_is_recorded_after_the_waiter_is_gone (0 receipts, not 1)
  • a_late_unknown_outcome_never_touches_the_current_head (0 receipts, not 1)
  • every_unknown_outcome_callback_keeps_the_transaction (503 on the Waiting/Failing row)
• Control: an_ordinary_approval_is_still_refused_when_the_record_cannot_be_written passes on both sides, so the write-ahead refusal for plain approvals is kept.
• Revert check: I copied the fixed lib.rs and hic_records.rs aside and restored them from 8f9d459. The same four tests failed (8 passed, 4 failed). The fix was then restored.
• Tripwire: every_unknown_outcome_callback_keeps_the_transaction is a state matrix: head {waiting, gone, other call} × log {writable, failing}. For every row it asserts:
  • the callback is never refused with 503;
  • the tx is always remembered;
  • no other call is resolved;
  • when the log is writable, there is exactly one receipt naming the hash.
    A new early return on this path fails a row.
• Adversarial and failure inputs: the failing log is a real DecisionLog whose directory is made read-only, so the next segment cannot be created (no test double). The cancelled waiter is a dropped future, which uses the queue's own drop guard.
• Gates:
  • cargo test -p agent-sidecar -p citrate-agent-core: 898 before, 903 after, 0 failed.
  • cargo fmt -p agent-sidecar --check is clean.
  • cargo clippy -p agent-sidecar --all-targets --no-deps -D warnings is clean.
  • The workspace-wide cargo clippy --all-targets -D warnings fails with the local toolchain in crates this PR does not touch: citrate-agent-mcp-host (nonminimal_bool) and citrate-agent-legacy (dead code, redundant closure, doc indentation). Those failures are pre-existing.
• Push: with --no-verify, because the pre-push hook needs PyYAML. I ran the gates above by hand.

Wire note for citrate-core

• No wire change. Core's post_resolve already treats any 2xx as delivered and 409 as Stale, and it ignores the new recorded field.
• Core must not send txHash on a plain {id} approve: this route answers 400 to a txHash without an outcome. A "confirmed, with hash" outcome would need a new wire value (follow-up).

🤖 Generated with Claude Code

[Matr0xshka]

[MAC independent review] APPROVED at 5782a76
Reviewer: MAC-lane independent reviewer agent (did not author this PR). Not Codex, not DGX. Per owner decision 2026-10-23 this review stands in for the Codex and DGX gates.

Head checked live via REST: 5782a7680abd08c128f7427e076c3ade370eca34. I reviewed the whole diff against main (9 files). I worked in a scratch worktree with its own target dir (macOS, stable toolchain).

What I ran

• cargo test -p agent-sidecar -p citrate-agent-core: 903 passed, 0 failed, 7 ignored. That matches the body (898 → 903).
• Codex: the result at 506b779 has two P2s, and both are fixed here (below). No Codex result exists yet at 5782a76. There are no pysol-dev reviews on this PR.

Revert check (reproduced; no git stash, files copied aside and restored, tree clean afterwards)

• agent-sidecar/src/lib.rs and hic_records.rs restored from the red commit 8f9d459: 4 fail on assertions. They are an_unknown_outcome_is_delivered_even_when_the_record_cannot_be_written, a_late_unknown_outcome_is_recorded_after_the_waiter_is_gone, a_late_unknown_outcome_never_touches_the_current_head and the tripwire every_unknown_outcome_callback_keeps_the_transaction. The control an_ordinary_approval_is_still_refused_when_the_record_cannot_be_written passes, and 8 pass in total.
• The feature commit's red was a compile failure, so I also killed its behaviour by mutation, one mutant at a time:

Mutant	Result
The sidecar treats an unknown outcome as a plain approve (lib.rs:730)	7 outcome_unknown_tests fail
The re-proposal guard is off (hitl/mod.rs:382: auto-grant ignores a remembered unknown outcome)	a_reproposal_references_the_earlier_tx_and_never_auto_approves fails
The linker dispatches on SubmittedOutcomeUnknown (capsule/linker.rs:465)	eth_send_capsule_reports_an_unknown_outcome_and_never_dispatches fails
QueuedApprovalGate::request returns Ok for an unknown outcome (prod_impls.rs:71)	queued_gate_passes_an_unknown_outcome_through fails

Probes (throwaway, not committed)

• The same callback posted twice: the first gives 200 and the capsule gets SubmittedOutcomeUnknown with core's words. The repeat gives 409, and a later plain {id} approve gives 409. No record ever closes Completed.
• A callback for an id that was never pending: 409, nothing resolved, a receipt written, and the id remembered, so a later proposal of it waits for the member.
• Under the kill switch: the callback gets 503, and the transaction isn't remembered. Follow-up below.

Findings

• Codex P2 1 (a record failure hid the outcome): fixed. With an unknown outcome, a failed write is logged, and the outcome is still delivered and remembered (recorded: false). A plain approval still refuses with 503 (write-ahead).
• Codex P2 2 (no receipt for a late callback): fixed. A receipt is bound to the callback's call id and closed OutcomeUnknown with "not told". No other entry is resolved.
• P2 follow-up (#438): resolve_body (lib.rs:699) refuses before it reads outcome while the kill switch is on, so the receipt and the re-proposal memory are skipped. It's the same shape as Codex P2 1. It doesn't block: core's ceremony still has to sign any second payment. A duplicate callback also writes a second receipt.
• Note: rustfmt from the CI toolchain flags some of the new lines in agent/core/src/hitl/mod.rs and capsule/prod_impls.rs. cargo fmt --check already fails across agent/core on main, so this isn't a regression.

CI (confirmed pre-existing and unrelated)

• rust / ci: the job fails in cargo test on citrate-agent-browser's live_chrome_tests::attach_needs_consent_per_session_and_per_origin (the stand-in Chrome port). This PR doesn't touch that crate.
• fmt and clippy steps: they fail the same way on main's own green run at ce34d3e (387 fmt diffs, citrate-agent-core clippy with 13 errors under 1.99.1). Every clippy error is on a line that predates this PR.
• Everything else is green, including audit.

Wire match with core #366

outcome, txHash (0x + 64 hex or null) and message (must contain the hash) are as DGX tabulated. The approve route is the only one that takes them, and an outcome on reject is a 400.

Standard: met. Red reproduced; the revert check and four behaviour mutants all fail; the state-matrix tripwire is in place.
Verification cleared: yes. Money truth: an unknown outcome is never Completed or Approved to the capsule, is never dispatched twice, and always names the hash.

[BerryManifold]

[MAC independent review] APPROVED at 5782a76
Reviewer: MAC-lane independent reviewer agent (did not author this PR). Not Codex, not DGX. Per owner decision 2026-10-23 this review stands in for the Codex and DGX gates.

Head checked live via REST: 5782a7680abd08c128f7427e076c3ade370eca34. I reviewed the whole diff against main (9 files). I worked in a scratch worktree with its own target dir (macOS, stable toolchain).

What I ran

• cargo test -p agent-sidecar -p citrate-agent-core: 903 passed, 0 failed, 7 ignored. That matches the body (898 → 903).
• Codex: the result at 506b779 has two P2s, and both are fixed here (below). No Codex result exists yet at 5782a76. There are no pysol-dev reviews on this PR.

Revert check (reproduced; no git stash, files copied aside and restored, tree clean afterwards)

• agent-sidecar/src/lib.rs and hic_records.rs restored from the red commit 8f9d459: 4 fail on assertions. They are an_unknown_outcome_is_delivered_even_when_the_record_cannot_be_written, a_late_unknown_outcome_is_recorded_after_the_waiter_is_gone, a_late_unknown_outcome_never_touches_the_current_head and the tripwire every_unknown_outcome_callback_keeps_the_transaction. The control an_ordinary_approval_is_still_refused_when_the_record_cannot_be_written passes, and 8 pass in total.
• The feature commit's red was a compile failure, so I also killed its behaviour by mutation, one mutant at a time:

Mutant	Result
The sidecar treats an unknown outcome as a plain approve (lib.rs:730)	7 outcome_unknown_tests fail
The re-proposal guard is off (hitl/mod.rs:382: auto-grant ignores a remembered unknown outcome)	a_reproposal_references_the_earlier_tx_and_never_auto_approves fails
The linker dispatches on SubmittedOutcomeUnknown (capsule/linker.rs:465)	eth_send_capsule_reports_an_unknown_outcome_and_never_dispatches fails
QueuedApprovalGate::request returns Ok for an unknown outcome (prod_impls.rs:71)	queued_gate_passes_an_unknown_outcome_through fails

Probes (throwaway, not committed)

• The same callback posted twice: the first gives 200 and the capsule gets SubmittedOutcomeUnknown with core's words. The repeat gives 409, and a later plain {id} approve gives 409. No record ever closes Completed.
• A callback for an id that was never pending: 409, nothing resolved, a receipt written, and the id remembered, so a later proposal of it waits for the member.
• Under the kill switch: the callback gets 503, and the transaction isn't remembered. Follow-up below.

Findings

• Codex P2 1 (a record failure hid the outcome): fixed. With an unknown outcome, a failed write is logged, and the outcome is still delivered and remembered (recorded: false). A plain approval still refuses with 503 (write-ahead).
• Codex P2 2 (no receipt for a late callback): fixed. A receipt is bound to the callback's call id and closed OutcomeUnknown with "not told". No other entry is resolved.
• P2 follow-up (#438): resolve_body (lib.rs:699) refuses before it reads outcome while the kill switch is on, so the receipt and the re-proposal memory are skipped. It's the same shape as Codex P2 1. It doesn't block: core's ceremony still has to sign any second payment. A duplicate callback also writes a second receipt.
• Note: rustfmt from the CI toolchain flags some of the new lines in agent/core/src/hitl/mod.rs and capsule/prod_impls.rs. cargo fmt --check already fails across agent/core on main, so this isn't a regression.

CI (confirmed pre-existing and unrelated)

• rust / ci: the job fails in cargo test on citrate-agent-browser's live_chrome_tests::attach_needs_consent_per_session_and_per_origin (the stand-in Chrome port). This PR doesn't touch that crate.
• fmt and clippy steps: they fail the same way on main's own green run at ce34d3e (387 fmt diffs, citrate-agent-core clippy with 13 errors under 1.99.1). Every clippy error is on a line that predates this PR.
• Everything else is green, including audit.

Wire match with core #366

outcome, txHash (0x + 64 hex or null) and message (must contain the hash) are as DGX tabulated. The approve route is the only one that takes them, and an outcome on reject is a 400.

Standard: met. Red reproduced; the revert check and four behaviour mutants all fail; the state-matrix tripwire is in place.
Verification cleared: yes. Money truth: an unknown outcome is never Completed or Approved to the capsule, is never dispatched twice, and always names the hash.

[BerryManifold]

Automated Codex static review of 5782a7680abd08c128f7427e076c3ade370eca34 is complete. Approval is withheld pending private security review. Details and coverage limits are recorded in the project's private review log. No tests were executed by this reviewer. Both account submissions represent the same Codex review, not independent reviews.

[Matr0xshka]

Automated Codex static review of 5782a7680abd08c128f7427e076c3ade370eca34 is complete. Approval is withheld pending private security review. Details and coverage limits are recorded in the project's private review log. No tests were executed by this reviewer. Both account submissions represent the same Codex review, not independent reviews.

[Matr0xshka]

Approval at 6232099, recorded on the owner's instruction (2026-10-22, owner merge queue).

6232099 is the cross-lane-approved head 5782a76, with only the default branch merged in since.

What this approval measured:

• Cross-lane approval at the reviewed head (see the [MAC]/[DGX] APPROVED review on this PR).
• Codex: MAC independent review APPROVED at the reviewed head (stands in for Codex + DGX per owner decision 2026-10-23); owner instructed merges 2026-10-23.
• CI at 6232099: ci=success, secret-scan=success.

This does not record a fresh, independent re-run of the tests.

[BerryManifold]

Approval at 6232099, recorded on the owner's instruction (2026-10-22, owner merge queue).

6232099 is the cross-lane-approved head 5782a76, with only the default branch merged in since.

What this approval measured:

• Cross-lane approval at the reviewed head (see the [MAC]/[DGX] APPROVED review on this PR).
• Codex: MAC independent review APPROVED at the reviewed head (stands in for Codex + DGX per owner decision 2026-10-23); owner instructed merges 2026-10-23.
• CI at 6232099: ci=success, secret-scan=success.

This does not record a fresh, independent re-run of the tests.