Artemis Free-Map Doesn't Reserve Capsule-Claimed Blocks

Date: 2026-07-10 Branch: lithosananke Status: Finding only. Not fixed. Reported per standing instruction (.claude/CLAUDE.md: "If you identify a bug, report it. Do not fix it unless the user says to."). Confirmed correct shape by Captain Bob. Author: Captain Bob / Claude Code

Surfaced while cross-checking HERMES-MESSAGE-BLOCK-STORAGE-DESIGN- 20260708.md against the retraction of CAPSULE-LOADER-DEFINITIONS-ONLY-DESIGN-20260709.md — not what either doc set out to find.

Confirmed context, not in question

Capsule loading writing every Block N header's content to the literal block N, unconditionally, every boot, is correct — confirmed directly by Captain Bob (see CAPSULE-BLOCK-PERSISTENCE-BOUNDARY-FINDING- 20260709.md, now closed as not-a-bug). The global block-number namespace across all capsules is deliberately coordinated, not accidental — artemis/init.4th Block 4122's own comment says so plainly: "NOTE: Hermes owns 4100-9,4114-21,4142+. Artemis resumes 4122." mkcapsule enforces this as a hard build gate (check_block_conflicts(), tools/mkcapsule.c:694-740) — a real collision fails the build. No duplicate LBN currently exists across the live capsule corpus (verified: grep over capsules/BLOCK_MAP.md for repeated LBNs found none).

The gap

Artemis's own free-map allocator has no knowledge that a sub-range of her own data pool is permanently owned by the kernel's capsule loader across every boot.

ART-HDR-WRITE (artemis/init.4th Block 4125) formats a blank disk by recording free = ART-DATA-BLKS — the full 22,998-block data region, no exclusions.
FM-FIND-FREE (Block 4122) does a linear scan from index 0 (LBN 3076) upward, returning the first bit that's unset.
Nowhere in ART-FORMAT / ART-INIT / ART-HDR-WRITE is FM-SET ever called to pre-mark the capsule-claimed sub-ranges (ACL.4th 4000–4007/4015, zuse.4th 4016–4018, lib.4th 4050, common:msg.4th 4055, doe-campaign.4th 4060–4065, hermes:init.4th 4100–4153, artemis:init.4th's own 4110–4141/4851–4852, and the init-1.4th through init-9.4th/L8-variant capsules) as allocated.

Consequence

Today this is silently harmless: LBN 3076–3999 (924 blocks) are unclaimed by any capsule, and FM-FIND-FREE's linear-from-zero scan exhausts that range first. But once real allocation — Artemis's own future data, or Hermes's eventual tier-3 message-overflow requests once HERMES-MESSAGE-BLOCK-STORAGE-DESIGN-20260708.md is implemented — pushes past roughly 924 live blocks, BLK-ALLOC will hand out an LBN inside the capsule-claimed range. The next boot's capsule-loading pass writes that LBN's capsule content unconditionally (per the confirmed-correct mechanism), silently overwriting whatever real data BLK-ALLOC had just placed there. No error, no warning — the real data is just gone on the next boot.

Scope

Applies to Artemis's live, already-implemented free-map (artemis/ init.4th, committed ed05db25 per ARTEMIS-BAM-ACCEPTANCE-20260703.md) — not the Future Material zone/BAM system, which is separately not build-authorized. This gap exists in code that already ships and already runs ART-SELF-TEST/ART-WRITE-TEST against the live disk image today.

Not fixed

No code changed. Awaiting direction. Candidate fix shape, not yet confirmed: reserve the capsule-claimed LBN range(s) in the free-map at ART-FORMAT time (FM-SET for each capsule-owned index before the "free" count is recorded in the header), so FM-FIND-FREE never considers them. Exact mechanism — whether the reservation is a fixed compile-time range, derived from capsules/BLOCK_MAP.md at build time, or something else — not designed here.

3.7 KiB Raw Permalink Blame History Unescape Escape