id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries

Summary

WorldCore::restore (pkgs/id/src/world/core.rs) treats the journal as untrusted input and validates handoff state strictly when it arrives as standalone entries — but a JournalEntry::Checkpoint's transfers list is installed verbatim with none of those checks. A journal whose checkpoint carries duplicate handoff sides, a non-advancing import epoch, or a transfer event that claims a sequence/participant is restored successfully, while the identical facts as standalone entries are refused. The checkpoint path is exactly the path compaction produces, so this is the durable-state trust boundary for the region-seam handoff state added in #3870 phase 1 (PR #3922).

Evidence (current main `c1675d6`)

Standalone arms validate (core.rs restore):

EntityExported arm (core.rs:322-330): refuses when source_event.sequence != 0 || source_event.participant_id != 0 ("journal export event claims a sequence"), and refuses a second export with the same handoff_id ("journal exports handoff … twice").
EntityImported arm (core.rs:363-375): same event check, plus new_owner_epoch == prior_owner_epoch + 1 ("does not advance the owner epoch"), plus the duplicate-import refusal.

Checkpoint arm (core.rs:502-504):

// A checkpoint comes first in its journal, so its
// transfer list is the whole active-handoff state.
core.handoff_transfers = transfers.unwrap_or_default();

No duplicate check, no epoch check, no transfer-event check, no bound. (The same arm does validate the checkpoint's execution_profile, caps_ceiling, and schedule agreement — transfers are the unvalidated remainder.)

Verified this run with a laptop probe calling the real WorldCore::restore (transient integration test in the laptop clone ~/git/code at c1675d6, pkgs/id/tests/probe_ckpt_transfers.rs, since removed; log at ~/git/fleet/probe-2026-11-01-laneA-ckpttransfers/run.log; sandbox and laptop core.rs/mod.rs md5-identical):

CONTROL standalone duplicate export → Err "journal exports handoff "h1" twice"
CONTROL standalone import epoch 5 → 5 → Err "does not advance the owner epoch"
CONTROL standalone export event sequence 7 / participant 9 → Err "journal export event claims a sequence"
CONTROL standalone valid import 5 → 6 → Ok
CASE checkpoint, one valid export transfer → Ok
CASE checkpoint, duplicate export transfers (same handoff_id) → Ok (expected Err)
CASE checkpoint, import transfer epoch 5 → 5 → Ok (expected Err)
CASE checkpoint, export transfer event sequence 7 / participant 9 → Ok (expected Err)

Why it matters

Restore is the journal's trust boundary everywhere else in this function: forged Issued entries for participant 0 (#2972), duplicate issues, out-of-bounds delegation expiry, unknown caps, and schedule disagreement are all refused at restore, precisely so a corrupt or crafted journal cannot resurrect state the live writers would never produce. Checkpoint-carried handoff state is the exception. Duplicate export records break the dedupe invariant the coordinator phases of #3870 rely on (an exact retry returns the existing receipt; two export sides for one handoff_id make that ambiguous), a non-advancing import epoch defeats the epoch fencing the design (#2818 §3) uses to stop a stale source region from re-owning an entity, and a transfer event claiming a sequence/participant violates the host-event invariant replay assumes. Because compaction rewrites the journal behind a checkpoint, any bad transfer state that ever reaches a checkpoint is laundered into the canonical durable form.

Acceptance criteria

WorldCore::restore applies the same validation to checkpoint-carried transfers as to standalone EntityExported/EntityImported entries: no duplicate (handoff_id, direction) pair, import records advance the owner epoch (new_owner_epoch == prior_owner_epoch + 1), export records carry no new_owner_epoch, and each transfer's event has sequence == 0 and participant_id == 0.
Restore refuses (with a clear error naming the handoff) a checkpoint exhibiting any of: duplicate export side, duplicate import side, non-advancing import epoch, or a transfer event claiming a sequence/participant — matching the standalone-arm error style.
New world tests cover each refused checkpoint case plus a control: a checkpoint with valid export and import transfers restores, and the checkpoint/compaction round-trip test from PR feat(id): region-seam handoff journal foundation (#3900) #3922 still passes.
Existing world/journal tests still pass; no change to the journal wire format or to what checkpoint_entries writes for live (valid) state.

Dedup notes

Filed by new-issue-creator-code-a. Searched open + closed issues for checkpoint/handoff/restore validation: #3900/#3870 (the phase-1 implementation and its umbrella — this is a validation gap in that landed code, not one of the phase 2-5 implementation issues #3901-#3904), #3911 (WaitingPool::restore duplicate guards — different type), #3373 (journal restore under revoked parent — different invariant). None covers checkpoint-carried transfer validation.

🤖 Agent note · filed

Agent: new-issue-creator job (new-issue-creator-code-a)
Session / ID: cron job new-issue-creator-code-a, run 2026-11-01 13:05 CST
Found via: filed this run
Task: Make WorldCore::restore validate checkpoint-carried handoff transfers with the same rules as standalone EntityExported/EntityImported entries: refuse duplicate (handoff_id, direction) sides, non-advancing import epochs, and transfer events claiming a sequence/participant.
Expectation: effort/s — done when the acceptance criteria on this issue pass, including restore tests for each refused checkpoint case plus the valid-transfer control.
Links: evidence in the issue body; laptop probe at ~/git/fleet/probe-2026-11-01-laneA-ckpttransfers/ (real WorldCore::restore at main c1675d6: standalone controls all Err, all three checkpoint cases Ok).

🤖 Agent note · adopted as Phase 1 of design #4000

Agent: design architect (repo-design-architect-code), pass 34
Task: This issue is Phase 1 of design Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 (reconstruction is admission, continued; follow-on to Design: reconstruction is admission — validate authority-bearing inputs where they are rebuilt (pkgs/id) #2898). Triage: do NOT re-file, re-scope or split it; record the phase structure instead.
Decisions recorded on Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 that bind this phase: validate each element of a checkpoint's transfers list with the standalone arms' rules (no duplicate (handoff_id, direction); import new_owner_epoch is the checked successor of prior; export carries no new_owner_epoch; transfer event sequence==0 && participant_id==0), in list order, before installation; refusal aborts the whole restore. The carried-import epoch check uses Phase 2's (id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release #3736/id(world): restore's EntityImported epoch check uses plain + 1 — prior=u64::MAX wraps to an accepted epoch 0 in release and panics in debug/test #3961) checked_add form — whichever of Phase 1/Phase 2 lands second writes that predicate in its final shape exactly once. One shared per-transfer validation helper is preferred so the arms cannot drift again. Do NOT add a transfers-list bound in this phase — no cap value is recorded; design Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000's Phase 3 audit (Phase 3 (audit) of #4000 — closing reconstruction-admission inventory for pkgs/id #4001) dispositions it.
Outcome: Linked as a sub-issue of Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000; labelled source/design-architect. Existing queued triage packet stands.
Links: Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000, Design: reconstruction is admission — validate authority-bearing inputs where they are rebuilt (pkgs/id) #2898, Phase 3 (audit) of #4000 — closing reconstruction-admission inventory for pkgs/id #4001

🤖 Agent note · handed off

Agent: OpenCode claimant (opencode-claimant)
Session / ID: task 6271 · session ses_e5e624906f9ffe2XAsYRSZ0QTG
Found via: queue lane handoff
Task: task 6271 is bound to this OpenCode session for issue id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942.
Expectation: small_fix (design Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 Phase 1): shared per-transfer validation in WorldCore::restore + refused-case tests, no wire-format change, no cap.
Links: issue id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942 · OpenCode session ses_e5e624906f9ffe2XAsYRSZ0QTG

🤖 Agent note · escalated

Agent: fleet monitor
Session / ID: repo-fleet-monitor run 2026-11-02 20:12 CST
Found via: monitor reconciliation
Task: ESCALATION (Duty 3): this issue is effort/s (2h expectation) and has had NO activity since 2026-11-02T19:23Z (~7h, past 2x the deadline). Its queue fix task (task 6271) is DONE in the queue (completed 2026-11-02T19:32Z after a handed-off note bound it to an OpenCode session), yet the issue still carries queue/claimed + work/assigned + status/in-progress, and no PR for this issue can be found. Adding user/review. Recommendation: confirm whether the bound OpenCode session is still alive; if not, requeue — reset labels to queue/queued + status/needs-triage and enqueue a fresh packet resuming from task 6271's handoff.
Expectation: a fresh checkpoint from the holder, or a requeue decision.

agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 6824 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03

🤖 Agent note · picked up

Agent: repo-worker-code (OpenChamber scheduled lane, task 6824)
Task: Triage issue id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942 and confirm whether its prior fix route is live, merged, or needs a fresh follow-up.
Plan: verify the prior queue task and current main; confirm the checkpoint-transfer validation state; post evidence and record the resulting disposition.

🤖 Agent note · triage disposition

Agent: repo-worker-code (OpenChamber scheduled lane, task 6824)
Verdict: already fixed on current main; closing as resolved. No open competing PR is needed.
Verified: origin/main at e425b6af52c35067a452c0c4526fef47f00c7f01.
Evidence: pkgs/id/src/world/core.rs defines validate_handoff_transfer and uses it for standalone export/import entries and for each checkpoint-carried transfer (list-order validation before installation). It rejects duplicate (handoff_id, direction) pairs, non-successor import epochs using checked_add, export records carrying a new epoch, and transfer events with nonzero sequence/participant.
Landed coverage: checkpoint_handoff_transfers_validate_duplicates_epochs_and_events, checkpoint_accepts_valid_export_and_import_transfers, and handoff_transfers_survive_restore_and_checkpoint_compaction in pkgs/id/src/world/tests.rs.
Verification limit: inspected current-main code/tests; no tests were executed in this triage pass.

🤖 Agent note · done

Agent: repo-worker-code (OpenChamber scheduled lane, task 6824)
Outcome: already done on current main; issue closed with verified code and test evidence.
Queue: task 6824 completed as already_done; issue Phase 3 (audit) of #4000 — closing reconstruction-admission inventory for pkgs/id #4001 records the moved gate. Its parked task 5934 remains gated only on id(waiting): WaitingPool::restore ignores the arrived and ready-queue duplicate guards — an already-applied or ready event is held again and handed out a second time #3911.

Navigation Menu

Repository navigation

id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942

Summary

Evidence (current main `c1675d6`)

Why it matters

Acceptance criteria

Dedup notes

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942

Description

Summary

Evidence (current main c1675d6)

Why it matters

Acceptance criteria

Dedup notes

Activity

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

13 remaining items

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 3, 2026

developing-today commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Evidence (current main `c1675d6`)