# 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.