Repository navigation
Phase 3 (audit) of #4000 — closing reconstruction-admission inventory for pkgs/id #4001
Description
Phase 3 (audit) of design #4000 — closing reconstruction-admission inventory (pkgs/id)
Parent design: #4000 ("reconstruction is admission, continued — carried state, checked succession, and every restore's guards"), the follow-on to #2898. Design doc: files/designs/code-id-restore-admission-followon.md in the keep-the-four-repos-healthy goal workspace. Audit baseline: origin/main 83709fac.
Gated on Phases 1, 2 and 3a of the design: Phase 1 = #3942 (checkpoint-carried handoff validation), Phase 2 = #3736 + #3961 (checked succession in restore), Phase 3a = #3911 (WaitingPool restore guards + explicit proof-park route). Do not start the inventory before all three land.
Scope
(a) Reconstruction-entry-point inventory for pkgs/id: enumerate every entry point that rebuilds state from durable or carried input — at minimum WorldCore::restore (every journal arm, and every field a Checkpoint carries: events, schedules, execution profile, caps ceiling, transfers, snapshot), WaitingPool::restore (id-core), the sandbox snapshot restore (sandbox.rs), world_store::restore_program, and the directory/petname persistence restores — and disposition each on the design issue as: validates with the live rules / fixed under this issue (only if a same-shape gap is confirmed and small) / filed as a named follow-up / deliberately different with the reason recorded. Where a surface is also in #2898 Phase 3's named scope (sandbox snapshot, restore_program, petname/directory), cite that phase's outcome rather than re-auditing it.
(b) Plain-arithmetic grep disposition: grep pkgs/id/src and pkgs/id/crates for plain arithmetic (+ 1, - 1 and compound forms) inside predicates that decide admission (restore, receipt, and live guards alike), record the pattern and site list on the design issue, and disposition each site with design #4000's decision 2 applied: succession predicates must be checked_add (saturation loses — MAX → MAX would pass an advance check); counters that may legitimately sit at a cap may stay saturating, with the reason recorded per site. At audit baseline the core.rs inventory is exactly two sites (core.rs:368, core.rs:476), both covered by Phase 2 — this audit is the crate-wide proof, not a re-fix of those two.
(c) Transfers-bound disposition: #3942 notes a checkpoint's transfers list is installed with no bound, and design #4000 deliberately records no cap value. Record on the design issue whether an existing journal limit (retained events, entry/size limits, the standalone path's practical bounds) already bounds the list in practice, or file a named follow-up proposing the bound — do not invent a cap inside this audit.
(d) Cross-note on #2898: post the note recording that #4000's follow-on phases have landed and that the two designs cite one rule, citing the landed phase PRs.
Acceptance criteria
- The inventory in (a) is posted on design Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 with a disposition and reason per entry point; any confirmed same-shape gap is either fixed here (small) or filed as a named follow-up issue — never left as a comment-only finding.
- The grep disposition in (b) is posted on Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 with its pattern and site list; no plain-arithmetic succession predicate in an admission path remains undispositioned.
- The disposition in (c) is recorded on Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000.
- The cross-note in (d) is posted on Design: reconstruction is admission — validate authority-bearing inputs where they are rebuilt (pkgs/id) #2898.
- No behaviour changes beyond the dispositions taken in (a)/(b); existing tests still pass (CI).
🤖 Filed by the design architect (pass 34, 2026-11-01) as Phase 3 (audit) of design #4000.
Activity
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed as Phase 3 (audit) of design #4000
249 remaining items
dezren39 commentedon Nov 3, 2026
🤖 Agent note · gate moved
origin/main(e425b6af52c35067a452c0c4526fef47f00c7f01) and is being closed with code/test evidence on 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.dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up (resume)
repo-worker-code, OpenChamber scheduled lanebf419306-c4ef-470f-a553-beabf93239derepo-health-code-pilot, triage; attempt 9)status/ready,queue/queued,task/fix). The Phase 3 closing audit is still gated.queue/5934-4001-id-restore-audit-triage,/home/user/git/fleet/5934; no files touched this claim.dezren39 commentedon Nov 3, 2026
🤖 Agent note · parked
repo-worker-code, OpenChamber scheduled lanebf419306-c4ef-470f-a553-beabf93239derepo-health-code-pilot, triage; attempt 9)issues_terminalresume condition for 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 and a seven-day backoff to stop repeated short-interval reclaims. No audit or implementation packet was started; no files changed.