refactor(reborn): complete host-side gate reconstitution — resume input_ref, local-dev gate persistence, GateRef reconcile (§5.3 flip prep / Stage 0)

[ilblackdragon]

Stage 0 of the capability-result flip (docs/reborn/2026-07-17-architecture-simplification-dto-dyn-local.md, §5.2.9/§5.3): a no-flip host-reconstitution slice closing two verified correctness hazards ahead of the atomic flip. The loop-facing trait is UNCHANGED and CapabilityOutcome is untouched; only host-side plumbing moves. Base tip verified at/after PR-B (a0c497b2d ancestor); 2a-i ReplayPayloadStore present.

Fix 1 — resume-time input_ref reconstitution (hazard 3)

On a gate/auth resume, the effective input_ref used for the idempotency key and validation is now derived from the host-private ReplayPayload persisted at the fresh gate raise (loaded by the resume's invocation id) — not the advisory loop-supplied approval_resume.input_ref. A new resume_replay_payload helper centralizes the derivation so the invoke_capability seam and invoke_capability_dispatch compute the same byte-stable key.

The idempotency key is now derived lazily inside persist_gate_record_for_outcome (after dispatch, only once a gate record exists) so a missing/stale resume payload can never pre-empt dispatch's own resume identity/activity validation — a malformed resume still surfaces InvalidInvocation, a genuinely-missing payload still fails closed (the 2a-i missing-payload test stays green).

• Wiring: invoke_capability → invoke_capability_dispatch(request.clone()) → persist_gate_record_for_outcome(&request, &outcome); dispatch loads the payload once (after resume_mode validation) and reuses it for both the store-derived input_ref and {input, estimate}.
• Test (failed first): approval_resume_derives_input_ref_and_key_from_store_not_loop_supplied — a resume with a WRONG loop-supplied input_ref still reconstitutes the original input from the store, and a second resume differing ONLY in that advisory ref replays the cached outcome instead of re-dispatching. Verified red before the fix (resume_request_count == 2, re-dispatch), green after. Updated invoke_capability_checks_registered_activity_on_approval_resume_input_ref to seed the payload it now reconstitutes from.

Fix 2 — gate-record persistence for the local-dev synthetic approval producer (hazard 2)

OutboundDeliveryTargetSetHandler::request_approval raises its approval gate outside the loop-host persist seam (the synthetic-capability wrapper bypasses persist_gate_record_for_outcome), so it now persists a GateRecord::Approval itself at the raise via the wired GateRecordStore, keyed by the canonical GateRef::for_approval_request, in the run's resource-owner scope. Without it the §5.2.9 host-side gate rendering would have no record to read after the flip.

• Test (failed first): the existing local-dev approval journey now asserts the GateRecord persisted at the raise loads and round-trips. Red before the fix (load returned None).

Fix 3 — reconcile the two approval GateRef encodings

Canonical encoding chosen: GateRef::for_approval_request(id) = GateRef::from_uuid(id.as_uuid()) — a new ironclaw_host_api helper — as the GateRecordStore key. This is the ironclaw_host_api::GateRef (a uuid newtype, the record key), a different type from the loop-facing gate:approval-{id} routing ref (ironclaw_turns::GateRef). ironclaw_capabilities::host now uses the helper at both authorize sites.

Because the canonical is the uuid record-key GateRef and not the routing string, this touches no persisted wire format and does not break the is_approval_gate_ref (gate:approval- prefix) predicate.

• Test: a host-persisted approval gate ref resolves through the read model — the routing gate:approval-{id} ref recovers the id via approval_request_id_from_gate_ref, the canonical key re-derives, and the persisted GateRecord is found (asserted in the local-dev approval test); plus a host_api round-trip unit test.

Deviation note: the brief suggested canonicalizing on from_uuid — that is exactly what this does for the record-key GateRef. The RISKY direction (rewriting the gate:approval-{id} routing string to a bare uuid) was not taken: it would break is_approval_gate_ref prefix routing used across production routing/projection/channel-delivery, plus persisted adapter command strings ("approve gate:approval-X") and delivered-gate route records — the STOP-and-report condition in the brief.

Verification (all green)

• cargo test -p ironclaw_loop_host — 378 lib (incl. new + updated resume/seam/2a-i)
• cargo test -p ironclaw_capabilities -p ironclaw_product_workflow -p ironclaw_run_state -p ironclaw_host_api --all-features
• cargo test -p ironclaw_reborn_composition --lib --all-features — 1629 (env-clean; the only 6 failures are pre-existing llm_admin nearai env-var tests polluted by the machine's NEARAI_API_KEY/LLM_BACKEND, green with those unset, and touch none of this diff)
• Integration: reborn_integration_outbound_target (16), reborn_integration_auth_gate (18), reborn_integration_reopen_resume_through_gate (13), reborn_group_approvals (15)
• cargo test -p ironclaw_architecture green
• cargo clippy --all-targets --all-features -- -D warnings clean on all 6 touched crates
• scripts/pre-commit-safety.sh clean (exit 0)

Trait unchanged; CapabilityOutcome untouched; invoke_capability not flipped; executor Resolution consumers not touched.

🤖 Generated with Claude Code

[ironloopai]

🔎 IronLoop Review Status

Head: c250e47c7e0c605f7d145f3fe5b2467bb59125cf
Result: One or more review results were superseded by a newer PR head.
Next: Run @ironloopai review on the latest PR head.
Updated: 2026-07-19T09:30:21.173Z

Current reviewers:

Reviewer	State	Verdict	Findings	Last update
ironloop/common-reviewer (reviewer)	Superseded	N/A	N/A	2026-07-19T09:14:27.846Z

Reviewer summaries

Reviewer	Detail
ironloop/common-reviewer (reviewer)	Superseded by a newer PR head. New head: c8595fd. Previous verdict: Changes requested.

Recent activity

Time	Reviewer	State	Detail
2026-07-19T07:55:16.361Z	ironloop/common-reviewer (reviewer)	Queued	Accepted review request for head f1eaf2f.
2026-07-19T07:55:16.361Z	ironloop/common-reviewer (reviewer)	Queued	Waiting for this reviewer lane to become available.
2026-07-19T07:55:17.092Z	ironloop/common-reviewer (reviewer)	Started	Reviewer worker started.
2026-07-19T07:55:19.442Z	ironloop/common-reviewer (reviewer)	Workspace ready	Prepared isolated checkout (head_ref) at f1eaf2f.
2026-07-19T08:01:20.321Z	ironloop/common-reviewer (reviewer)	Result captured	Changes requested; 1 blocking finding.
2026-07-19T08:01:20.321Z	ironloop/common-reviewer (reviewer)	Completed	Review completed and terminal status was persisted.
2026-07-19T09:14:27.846Z	ironloop/common-reviewer (reviewer)	Superseded	A newer PR head replaced this review (c8595fd).

Available commands

• @ironloopai help
• @ironloopai agents
• @ironloopai review
• @ironloopai review --agent <agent>

Run metadata

Admission: webhook accepted the request and IronLoop persisted reviewer state before this projection.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (2)

• staging
• reborn-integration

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b9aa301e-8509-4ec4-84bd-b98d195b1d54

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request introduces a canonical GateRef::for_approval_request helper to derive gate references from approval request IDs. It updates the host-side resume reconstitution logic to derive the effective input_ref and idempotency key from the host-persisted replay payload rather than relying on the advisory loop-supplied resume.input_ref, ensuring byte-stable idempotency keys. Additionally, the local-dev synthetic approval producer now persists a durable GateRecord at the gate raise, and corresponding unit tests have been added. There are no review comments, so I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[ironloopai]

❌ IronLoop Review: reviewer

Review at a glance

Verdict	Blocking	Notes	Inline	Head
❌ Changes requested	1	0	1	f1eaf2fd4b6a

Head: f1eaf2fd4b6aa1282ea5107c46b286ed5b776788
Next: Fix the blocking findings, push the PR branch, then re-run this reviewer.

Run details

Status: Current
Needs human: no
Needs validation: no

Summary

Normal runtime approval gates still persist under a random GateRef, so the new canonical approval-record key cannot retrieve them after the flip.

Findings

Blocking: 1 / Notes: 0

Blocking findings

1. ❌ [MEDIUM] Use the canonical key when persisting normal approval gates

Location: crates/ironclaw_capabilities/src/host.rs:733
This derived ref is discarded by CapabilityHost::invoke_json, which returns only AuthorizationRequiresApproval; DefaultHostRuntime then rebuilds RuntimeApprovalGate from the approval request ID. When the loop-host persists that ordinary ApprovalRequired outcome, capability_outcome_to_resolution still mints GateRef::new(), so the GateRecord is stored under a random key. The approval read model instead derives GateRef::for_approval_request from gate:approval-{id}, and therefore cannot load records for normal runtime capability approvals. The new local-dev synthetic test covers only its separately keyed producer. Persist normal approval records under GateRef::for_approval_request (or make the reader follow a durable loop-to-host binding) and add an end-to-end normal-runtime approval lookup test.

Developer follow-up

After fixing this feedback:

1. Push the fix to this PR branch.
2. Re-run this reviewer with @ironloopai review --agent reviewer if you only changed this reviewer's findings.
3. Re-run all reviewers with @ironloopai review when the fix may affect multiple areas.

[ironloopai]

This ref does not become the normal runtime gate-record key: invoke_json discards AuthorizeResult, and loop-host persistence maps CapabilityOutcome::ApprovalRequired to a freshly minted GateRef::new(). The read model derives GateRef::for_approval_request from gate:approval-{id}, so it will not find ordinary runtime approval records. Please wire the canonical key through that persistence path (or durably follow the binding) and test the normal runtime case.

[ilblackdragon]

Accurate observation, and I verified it — but it describes the deferred atomic-flip work, not a defect in this additive slice. Two facts settle the disposition:

1. No live consumer. I grepped every GateRef::for_approval_request / GateRecordStore::load call site: the only read-model that re-derives for_approval_request is the local-dev synthetic path (local_dev/outbound_delivery.rs + its test), which this PR fully wires and tests. The normal runtime approval-resume path still flows end-to-end through CapabilityOutcome + the gate:approval-{id} loop string ref via approval_interaction/gate_ref.rs — nothing reads the host_api GateRecord the loop-host seam persists for runtime gates. So the fresh-GateRef runtime record is unconsumed prep, not an unfindable-live-record bug.

2. Correct wiring needs the flip, not a mapping hack. On a fresh raise the loop-host persist seam (persist_gate_record_for_outcome) has only the gate:approval-{id} string — the typed ApprovalRequestId is available solely via approval_resume, which is None on first raise. Deriving the canonical key there would mean string-parsing the approval-id convention into the pure ironclaw_turns→host_api mapping (a composition/product-layer convention leaking into a boundary mapper). The correct home is the flip's authorize→Resolution path, where the typed id is in hand — which is exactly why for_approval_request was introduced at authorize now (forward-looking, value-identical to the prior from_uuid), and why the runtime persist wasn't flipped (CapabilityOutcome untouched, executor Resolution consumers not touched — the PR's stated scope).

So: the write-side canonical key belongs with the flip that adds the read-side consumer; doing only the write half now (via a string-parse in the mapper) would be the misleading state. The local-dev path — which DOES have a consumer — is wired and tested here. Tracking the runtime canonical-key + consumer as the flip slice.

[ilblackdragon]

✅ Ready for merge — host-side gate reconstitution (§5.3 flip prep / Stage 0). CI green 19/19, MERGEABLE/CLEAN.

Rebased onto its base branch (refactor/reborn-resolution-model-visible) — the branch was CONFLICTING; I merged the base in and reconciled the resume-code semantic conflict:

1. capability_port.rs {input, estimate} reconstitution — kept this PR's design (consume the once-loaded resume_payload, which also derives effective_input_ref) over the base's lazy replay_payload_for_resume re-load, using the base's model-visible-updated None-branch body (carries the failure detail). No double-load, no orphaned local.
2. local_dev/outbound_delivery.rs — auto-merged cleanly; this PR's gate_record_store wiring coexists with the base's changes.
3. Formatting — one auto-merged test line rustfmt wanted collapsed.
4. Latent ironclaw_runner E0560 (×9) — the merge pulls ironclaw_runner into CI's change-scoped clippy set for the first time, surfacing three test helpers that still constructed the replay/input/estimate fields dropped in the Pending{Auth,Approval}Resume → ReplayPayloadStore migration (raw input/estimate no longer ride the checkpoint). Verified pre-existing (reproduces on the base tip too), removed the 9 write-only stale settings + the now-unused ResourceEstimate import. All 344+ runner tests pass.

Verification: loop_host + composition + runner tests pass; the exact CI command cargo clippy --all --tests --examples --all-features -- -D warnings is clean workspace-wide locally (exit 0); all three feature lanes (default / libsql-only / all-features) clean; cargo fmt --all --check clean.

Review comment: the IronLoop finding (canonical GateRef key on the runtime persist path) is already dispositioned by the author as deferred flip work — no live consumer re-derives for_approval_request on the runtime path; the local-dev synthetic path that does is wired and tested here. Nothing outstanding.

Note for the stack collapse: this sits on refactor/reborn-resolution-model-visible; once that branch lands, retarget/rebase onto main (should be clean, since this now contains the base).