The bootstrap law

The compiler is written in Halis. That means it must be able to compile itself — and, crucially, it must land on exactly the same result every time. That is the bootstrap law.

snapshot/hlc.c ── cc ──► bin/hlc ── compiles ──► src/hlc.hls
(committed seed)          (native)                   │
      ▲                                                 │
      └────────── must re-derive byte for byte ─────────┘

How it is enforced

snapshot/hlc.c is the compiler’s own emission, committed in the tree and content-addressed by snapshot/MANIFEST.json. make bootstrap compiles that committed C snapshot with the system compiler, then requires the resulting Halis compiler to re-derive the snapshot byte for byte. A stale or hand-edited snapshot fails the build loudly — there is no way to “fix” it by editing the file, because the manifest pins the digest.

The current snapshot

Field	Value
Version	{bootstrap.version}
Lines	43,610
Bytes	3,075,424
SHA-256	{bootstrap.sha256}
Closure digest	{bootstrap.closureDigest}
Closure files	20

Two independent ignitions

make snapshot-chain goes further: it runs the whole bootstrap as two independent ignitions, byte-compares every hop — each round against the snapshot, round against round — and prints the chain digest.

CC2=clang proves that a different compiler in the first slot still lands on the same bytes. That is the real test: the fixed point does not depend on which C compiler happens to be installed.

No Python on the lifecycle path

The interpreter under tools/hlinterp/ is lab tooling for the differential suites. Nothing on a build, release or snapshot path reads it. That is a deliberate constraint, not an accident of implementation.