Spec M41 -- override, debloat and re-arch: <mc/core> becomes composable, and a recreated compiler is smaller than mc by what it omits

Owner's direction (2026-09-04, docs/specs/M40.md § Amendment, quoted): "the developer RECREATES the compiler -- without touching src/ -- with overrides of the core's remaining fixed decisions, new primitives, a new machine, and the REMOVAL of the primitives, writers and machines the target does not use; then builds the program with that compiler." And: "<mc/core> becomes composable (a minimal core -- lexer, parser, resolver, walker, hooks -- with the object writers, the two host machines, the driver, the bundle and the sysroot resolver as parts an entry file includes or omits), and primitives the target does not use can be removed (types and intrinsics unregistered; writers, machines and targets simply not registered). examples/avr is the first recreated, debloated compiler: no Mach-O, ELF64 or COFF writer, no arm64 or x86-64 machine, uptr of two bytes, the AVR machine and its ELF32 writer only."

Goal: five bundled parts, one core-provided mc_main(), three registries that make the optional parts self-registering, two removal mechanisms for core language primitives, and one machine-declared override (type_width(TY_UPTR)). Measured target: a compiler built from the minimal core plus one machine and one writer is about a third of build/mc1's size, and the full assembly still equals src/mc.mc byte for byte.

Sequencing: after M24 (type_new/type_width registry, walk_depth_type, slot_new(type_width), syntax_lit, intrinsic, machine_tab/machine_slot). M40 is the first consumer. Line references are to main at 73d1b97; all sizes were measured on this machine on 2026-09-04 with build/mc1 --dump-syms src/mc.mc.

What already exists #

• Partial include lists already work. src/astdump.mc:17-23 is a working compiler front end built from six of the core's files (arena, lz, macho, lex, ast, parse, hooks) and src/lexdump.mc:4-5 from two. src/m0.mc:19-20 is arena + macho alone. Nothing about src/core.mc is atomic today except the file itself.
• #include is once-only (src/lex.mc:663, lex_seen), so a part may include its own dependencies and an entry may name a part twice.
• Relative includes inside a bundled file resolve by last path component (src/lex.mc:640-647, src/bundle.mc bundle_find_base), which is what makes <mc/core>'s own #include "arena.mc" work. tools/bundle.mc refuses a manifest where two entries share a last component (docs/reference/bundle.md:165), so a new part file's basename is its bundle name.
• A wrong split fails loudly at compile time: a call into an omitted part is call to unknown function (src/gen_resolve.mc:389), not a silent link failure.
• The registries are all one shape -- linear table, registration order, last registration wins: pass (src/hooks.mc:53), backend (:61), syntax* (:227-278), type_alias (:321), machine (:378, MAXMACHINES 8 at :372), target (:434, MAXTARGETS 16 at :421).
• user_init() timing is already fixed and documented: after tok_init() (the ids K_U8..K_EXTERN are frozen at 256..269) and before the first token, src/main.mc:218. --machine= is applied after it (:220) and --backend= at :232.
• The bundle is data, not a dependency of teaching. mc build's [compiler] step generates #include <mc/host> + #include <mc/core> + the modules (src/driver.mc:350-376) and compiles it with the HOST's executable backend (:546-558). The blob that gets embedded is the building compiler's; whether the built compiler carries one is decided by its own include list.
• src/limits.mc is already a pure add-on: arena.mc owns the table registry (T_* at src/arena.mc:66-102), the seeds (:115) and lim_note (:141); limits.mc adds the planner and the report, and reaches the bundle only through the lexer's bopen_fn pointer, never through src/bundle.mc.
• Measured today (build/mc1, 600 032 bytes on disk): __text 282 168, __cstring 14 527, __data 293 864 of which the bundle blob is 285 102 (tools/bundle.list, 50 entries), __bss 33 957 168 (the 32 MiB static heap, src/arena.mc:157, not in the file).

Design #

1. Five parts, and src/core.mc is their sum #

Two file splits, five new part files, one rewritten core.mc.

src/core.mc becomes six #include lines. That is the design's load-bearing property: the full assembly is literally the parts, so there is no second list to drift.

Split 1 -- src/macho.mc -> src/objmodel.mc + src/macho.mc. The walker and the parser do not need a Mach-O writer, they need the object model: parse.mc:349 calls sec_new (via sec_make) and parse.mc:338-343 registers the R_* constants as internal defs; gen_walk.mc uses sec_at/sec_data/sec_zsize (:358-364), sym_new/sym_ref (:434, :559) and reloc_add (:375). objmodel.mc takes macho.mc:1-244 (the three record layouts, R_*, S_*, TEXT_FLAGS, sec_new, sym_new, sym_set_value, reloc_add) plus sym_class/sym_order/out_name16/ dump_syms (:258-324) -- sym_order because backend_elf.mc:292 and backend_coff.mc:315 need it and neither is Mach-O, dump_syms because it prints the model and is check-obj's oracle. macho.mc keeps the MH_*/LC_*/N_*/CPU_* defines (:246-256, also used by backend_exe.mc:553,634,763) and macho_write (:325-467). Measured: 6 592 bytes of model, 5 092 of writer. Function definition order across the two files is unchanged, so the split alone is byte-neutral.

Split 2 -- src/main.mc -> src/cli.mc + src/main.mc. See § 2.

Naming. mc/core_min, not mc/core-min: a bundle name is the file's basename (tools/bundle.list is NAME<TAB>PATH and the last-component fallback matches on the basename), and core_min.mc cannot be reached as core-min. core_* as the prefix keeps mc/driver (the module) distinct from mc/core_build (the part).

What an entry file says. Nothing new: it names the parts.

#include <mc/host>
#include <mc/core_min>
#include "machine_avr.mc"
#include "image_avr.mc"
i64 main(i64 argc, uptr argv, uptr envp) { host_init(envp); return mc_main(argc, argv, envp); }
void user_init() {
    machine_avr_init();
    backend("avr-image", &backend_avr);
    backend_default("avr-image");
}

For mc build: [compiler].core is a path today (src/driver.mc:362-364). One rule, ~4 lines: if the value starts with <, emit it verbatim instead of rewriting it with ../. A project then writes core = "<mc/core_min>" and its module includes whatever else it wants. examples/kernel and examples/lang, which already #include <mc/core> in their module, are unaffected.

2. The entry: mc_main() and three self-registering parts #

src/main.mc:129-242 does eight things a recreated compiler must not have to copy: host_init, the machine/backend/target/sysroot registrations, the bundle hook, the subcommand dispatch, lim_plan, the argv loop with -o/--backend=/--machine=/--include=/--dump-*/--host, user_init() at the one correct moment, and the parse -> passes -> fold -> dump/backend pipeline. Six of the eight are core-min's; two are the optional parts'.

src/cli.mc (core_min) gets opt_val, usage, dump_host, the M_* constants and i64 mc_main(i64 argc, uptr argv, uptr envp) -- everything from src/main.mc:158 on, unchanged, with four edits:

1. machine_use(host_machine()) becomes conditional (machine_find(...) >= 0), so a compiler with only an AVR machine does not die at startup. New: i64 machine_use_if(uptr name) in hooks.mc.
2. the default backend (main.mc:198-203) tries the target registry first and, if ntargets == 0, falls back to what backend_default(name) recorded; with neither, die("no backend: use --backend=NAME"). New: void backend_default(uptr name) (~8 lines). No "if exactly one backend is registered" magic -- the module says which one.
3. lim_plan(...) (:212) moves behind void on_plan(uptr fn) (~12 lines, the on_stmt shape), registered by limits.mc. Unregistered, nothing is pre-sized and the tables grow from the seeds in arena.mc:115 -- which is exactly what astdump does today.
4. the three str_eq(argv[1], "build"|"limits"|"sysroot") lines (:154-157) move behind void subcommand(uptr name, uptr fn, uptr usage) (~30 lines in hooks.mc), and usage() prints the core line plus each registered subcommand's usage string. core_build registers three, sysroot's string carrying its two lines, so mc with no arguments prints byte-identical text.

src/main.mc keeps backend_macho (it calls macho_write, so it moves into macho.mc), host_bundle_open (moves into bundle.mc beside bundle_open, and bundle.mc gains mc_bundle_init() = lex_set_bundle(&host_bundle_open)), and shrinks to a main() that calls host_init, then mc_machines_init(), mc_writers_init() (the six backend() and five target() calls of :132-146), sysroots_init(), mc_bundle_init(), mc_build_init() (the three subcommand() calls and the on_plan registration), then return mc_main(argc, argv, envp). Each *_init lives in its own part; main.mc is the only file that names all five, and it is the file a recreated compiler replaces.

3. Removal, honestly #

(a) Not including a part. Zero mechanism. This is what the owner's list actually asks for: no Mach-O/ELF64/COFF writer is core_writers omitted; no arm64/x86-64 machine is core_machines omitted; no mc build, no mc sysroot, no mc limits is core_build omitted; no bundle is core_bundle omitted. Measured saving: 141 392 bytes of __text and 285 102 of __data.

(b) Unregistering. Not needed, and recommended against. Once the registrations move into mc_machines_init / mc_writers_init, "not registered" is the default and backend_remove / machine_remove / target_remove have no caller -- the same reason M24's D8 refused type_set_width as a free-standing setter. The tables stay append-only.

(c) Core language primitives. Two mechanisms, both consulted before the core's own answer.

• void type_disable(i64 ty) (~10 lines: one i64 ty_off bitmask in hooks.mc, one test at the head of type_of_token, src/parse.mc:677-686). Diagnostic at the token: u32: removed by this compiler. It removes the word from the surface, not the type from the model -- ld8() still yields TY_U8 (src/gen_resolve.mc:300-304) and type_width still answers for it. Say so in hooks.md. Disabling i64, uptr or void is permitted and makes the language unusable (a literal is TY_I64, &f and every pointer is TY_UPTR, a function returns TY_VOID); no special case, one sentence of documentation.
• void intrinsic_disable(uptr name) (~14 lines: a name table in hooks.mc, one test in intrin_id, src/gen_resolve.mc:284-296, applied to M24's registry too so the rule is uniform). Diagnostic: ld64: removed by this compiler. This one has a real caller today -- M40 § 2B's mitigation is precisely "portable sources use ldw/stw instead of ld64/st64", and without removal the wide pair stays reachable and silently wrong on a 2-byte word.
• Directives and keywords: no. Removing #dylib, #embed or loop needs a table in the lexer and the parser's own grammar, and has no caller. Deferred, unpriced.

4. Overrides of the core's remaining fixed decisions #

4a. type_width(TY_UPTR), machine-declared. M40 § 1b's C1+C3+C4+C5, on top of M24's M1/M5, priced there at ~15 core lines and adopted here as the mechanism M40 consumes:

• C1 src/ast.mc:213-218 -- type_width reads the registry (M24's M1) and, for TY_UPTR alone, a machine-declared width. void type_set_width(i64 ty, i64 w) refuses every ty but TY_UPTR, which is the "machine-declared form, never a free-standing setter" of M40 D2 and reverses M24 D8 because the caller now exists.
• C3 src/gen_walk.mc:321-324 -- slot_new's (size + 7) & ~7 granule becomes the declared word (~3 lines). Byte-identical at width 8.
• C4 src/gen_walk.mc:360-361, :689, :892 -- the three roundings to 16 become a declared frame alignment (~3 lines).
• C5 src/gen_walk.mc:374-376 -- a string inside a uptr[] initializer writes buf_u64(b, 0) + R_UNSIGNED at length 3; on a 2-byte word it writes two bytes with a machine-declared pointer relocation kind (~5 lines).
• C2 (:693, :881) and C6 (:924-933) follow from M24's slot_new(type_width(ty)) and the existing buf_u16 branch at :381 for free.

Inert by construction: with nothing declared the width is 8, the granule 8, the alignment 16 and the initializer 8 bytes -- exactly today.

5. Measurement and the debloated bundle #

Per-file __text was measured by taking the offset of each file's first function out of build/mc1 --dump-syms src/mc.mc and differencing (the walker lays functions out in definition order). The acceptance harness re-measures the same way, so no new tool is needed.

About a third of mc. Of the ~395 KB saved, 285 KB is the bundle and ~141 KB is code.

Can a debloated compiler ship a smaller bundle? Yes, at zero core lines. tools/bundle.mc:22-25 is arena + lz + bundle_data + bundle, and all four are already bundled names, so a project writes the same four-line tool against <mc/arena>, <lz>, <mc/bundle_data>, <mc/bundle>, generates its own bundle_data.mc from its own manifest, and its compiler includes that file plus <mc/bundle> instead of <mc/core_bundle>. bundle.mc needs only BUNDLE_COUNT and the two arrays, which the generator emits. Worth a paragraph in docs/reference/bundle.md; no code.

What a debloated compiler gives up, stated plainly in the guide: without core_build it has no mc build, so it is a leaf -- it compiles programs, not compilers; without core_bundle it has no #include <name> at all, so its programs use relative includes, as examples/kernel/lib already does.

6. The seed, and how the manifest grows #

stage0 compiles src/mc.mc and cannot parse <name>: stage0/parse.c:799 requires a T_STR after #include. So every part is a file under src/ included relatively by src/core.mc, and separately bundled under an mc/... name for taught compilers -- which is already how mc/core works. Nesting goes from 4 (mc.mc -> core.mc -> arena.mc -> prelude.mc) to 5, against stage0/lex.c:9 MAXOPEN 16; file count goes from ~30 to ~37 against MAXINC 256; string literals stay at 840 against MAXSTRS 2048 (stage0/gen_arm64.c:28) and functions at ~1 100 against MAXFUNCS 2048. No stage0 change, no budget change.

tools/bundle.list grows from 50 to 57 entries: mc/cli, mc/core_build, mc/core_bundle, mc/core_machines, mc/core_min, mc/core_writers, mc/objmodel, each NAME<TAB>src/NAME.mc with a unique last component. scripts/check-bundle.sh:84 derives its expected index size from the manifest (entries * 4), so it needs no edit; src/bundle_data.mc is regenerated by make bundle and grows by roughly 4 KB (the part files are comments and includes; objmodel/cli are moves).

Out of scope #

• examples/avr itself, the AVR machine, the ELF32 writer and the .mmcu section -- M40.
• mc build resolving a module-registered [target] -- M39.5.
• Removing directives or core keywords (§ 3c).
• A per-part [compiler].parts = [...] TOML key. core = "<mc/core_min>" plus the module's own includes covers it; a second spelling of the same list is what this milestone exists to delete.
• Making HEAP_SIZE configurable.
• Any change to stage0/.
• Fine-grained parts (<mc/core/lex>, <mc/core/parse>). Five parts are the seams that exist; ten would be ten names to keep true.

Files and estimated deltas #

Net new src/ lines ~150; moved ~530.

Acceptance #

1. The parts are the core. An object built from #include <mc/host> + the five parts spelled out + <mc/main> + <user_default> is byte-identical (cmp) to one built from #include <mc/host> + <mc/core> + <user_default>. This is the anti-drift proof and it fails the moment core.mc and the part files disagree.
2. check-standalone unchanged and green: step 4 still compares <mc/host> + <mc/core> + <user_default> against build/mc2.o, byte for byte. The reference moves with the milestone; the invariant ("the core inside the bundle is the core in src/") does not.
3. Inertness, in M17 step A's protocol. src/mc.mc's own source order changes (three files move: the Mach-O writer, hooks, limits), so tests/golden/mc2.sha256 is rewritten once, and only after: a copy of build/mc1 taken before the change and the post-change build/mc1 produce byte-identical objects for all 32 tests/*.mc, for examples/api, examples/lang, examples/conc and examples/kernel; the --dump-asm diff between mc1 and mc2 is empty; cmp build/mc2.o build/mc3.o passes. check-obj 32/32 against the frozen C seed; check-lex/check-ast/check-asm/check-surface/test-exe/test-linux/test-linux-x86_64/ test-windows/check-kernel unchanged.
4. Debloat is measured, not asserted. scripts/check-parts.sh builds a core_min-only compiler (with a two-slot probe machine and a null writer registered from user_init) and prints the examples/minimal table for it: file size, __text, __cstring, __data. It asserts __data under 16 KB (no blob), and that --dump-syms of its own object contains no _macho_write, _elf_write, _coff_write, _bundle_open, _drv_build, _m_arm64. The ceiling is a number in the script, in check-minimal's style.
5. Removal is proved by refusal. The same source that build/mc1 compiles is refused by a compiler that called intrinsic_disable("ld64"), with ld64: removed by this compiler, and by one that called type_disable(TY_U32), with u32: removed by this compiler. Both compilers are built inside check-parts.sh from the bundle, in check-standalone's style.
6. The override is proved and inert. A probe module calling type_set_width(TY_UPTR, 2) shows a uptr local in a 2-byte slot and a uptr[] global at 2 bytes per element under --dump-asm / --dump-syms; type_set_width(TY_U64, 2) is refused; and with no call, every object in Acceptance 3 is unchanged. The real consumer is M40.
7. mc behaves identically. mc with no arguments prints byte-identical usage text (the subcommand strings reassemble drv_usage's four lines); mc build, mc limits, mc sysroot list and tests/golden/sysroot-list.txt are unchanged; check-build's four diagnostics and check-limits are unchanged.
8. The bundle is reproducible. make bundle twice gives identical bytes; check-bundle green at 57 entries with <mc/bundle_data> still one #embed node plus a 228-value index.
9. Docs. make check-docs green with every new symbol documented and the guide page compiled as a sample.
10. git diff --stat stage0/ lib/ tests/ is empty.

Risks #

1. The golden rewrite is the milestone's only irreversible step. It is a reorder, not a behaviour change, and Acceptance 3 is the M17 step A protocol that proved exactly this class before. Do not fold any other src/ change into the same commit.
2. core.mc and the parts drifting apart. The design makes core.mc be the parts, and Acceptance 1 cmps the two spellings anyway. If the owner prefers to keep core.mc's flat list for a zero-golden-rewrite landing (D2's alternative), this risk becomes the milestone's main one and Acceptance 1 becomes mandatory rather than belt-and-braces.
3. mc_main growing a flag that only an optional part understands. --dump-machine (M24), --sysroot-dir (core_build) and --config are the precedent. Rule to write down in cli.mc: a flag whose handler lives in a part is registered, not if-ed. --sysroot-dir moves into the sysroot subcommand's own parsing where it already is.
4. user_init timing regressing. mc_main must keep user_init() after tok_init() and before the first token (src/main.mc:218), and the part *_init calls must stay in main(), before mc_main, because they only touch the backend/target/machine tables and must not tok_add. A part that ever needs tok_add is a user_init client like everyone else.
5. A recreated compiler with no machine at all silently produces nothing until the first mach(...) call dereferences mach_tab == 0. mc_main should say no machine registered before gen_lower; three lines, in the same commit.
6. type_disable read as "the type is gone". It removes a word from the surface; ld8 still yields TY_U8 internally. Every documentation sentence about it has to say so, or the next milestone will file a bug.
7. Two more taught compilers to keep alive (check-parts's probes). They are leaves and they are the only things that exercise a partial core, which is the regression class M41 introduces.

Decisions (architect, 2026-09-04 -- every recommendation below is adopted) #

• D1 -- coarse parts or fine (<mc/core/lex>, <mc/core/parse>)? Recommend five coarse parts. The seams that exist are the ones the owner listed: writers, machines, driver, bundle. A per-file part list would be twelve names, every one of them a promise that the file is independently includable -- which parse.mc and gen_walk.mc are not.
• D2 -- is src/core.mc the sum of the parts, or a parallel flat list? Recommend the sum, and pay the one golden rewrite. The alternative (keep today's flat list, add the parts beside it) leaves the golden untouched but makes "the full assembly is the parts" a claim a script has to defend rather than a fact the source states. If the owner wants the golden untouched, take the alternative with Acceptance 1 as a required check.
• D3 -- split src/macho.mc? Recommend yes, into objmodel.mc + macho.mc. Without it the owner's "no Mach-O writer" is unreachable, since the walker's section/symbol model lives in the same file. The cut is a pure move that preserves definition order.
• D4 -- split src/main.mc? Recommend yes, into cli.mc (mc_main, core_min) + main.mc (the registrations). mc_main is the milestone's public API: examples/kernel and examples/avr write a five-line main instead of copying 200.
• D5 -- subcommand() table, or leave build/limits/sysroot in main? Recommend the table. It is the eighth registry of the same shape, it is what makes mc build a part rather than a core fact, and it keeps the usage text byte-identical by carrying one string per registration.
• D6 -- a removal API for backends, targets and machines? Recommend no. Once the registrations live in the parts, "not registered" is free and *_remove has no caller -- the reason M24 D8 refused type_set_width, applied to itself.
• D7 -- type_disable and intrinsic_disable: in, or deferred? Recommend both in, ~24 lines together. intrinsic_disable has a named caller (M40 § 2B's ldw/stw mitigation); type_disable is the smaller half of the same idea and the owner's sentence names types first. Document loudly that they remove words, not types.
• D8 -- directive and keyword removal? Recommend no, unpriced, no caller.
• D9 -- does type_set_width(TY_UPTR, w) land in M41 or M40? Recommend M41, with the probe test of Acceptance 6, so that M40 is a module and nothing else. This is M40's amended D1/D2 and reverses M24 D8 exactly as the amendment says.
• D10 -- HEAP_SIZE overridable from [limits]? Recommend no. It is bss, absent from the file, and dynamic since M23; a static array's size is not reachable from user_init.
• D11 -- [compiler].core = "<mc/core_min>"? Recommend yes, ~4 lines: a value starting with < is emitted verbatim. It is the only driver change the milestone needs, and without it a project cannot ask mc build for a partial core.
• D12 -- part naming. Recommend mc/core_min, mc/core_machines, mc/core_writers, mc/core_build, mc/core_bundle -- underscores, because a bundle name is the file's basename and the last-component fallback resolves on it; core_* because mc/driver already means the module.

Adopted, one line each: D1 five coarse parts; D2 core.mc is the sum and the golden is rewritten once under M17 step A's protocol; D3 objmodel.mc split; D4 cli.mc/mc_main split; D5 the subcommand table; D6 no removal API for the registries; D7 type_disable and intrinsic_disable both in, documented as word removal; D8 no directive removal; D9 the uptr width mechanism lands here and M40 consumes it; D10 HEAP_SIZE stays; D11 the <...> form of [compiler].core; D12 underscore names. The architect's additions: (a) Acceptance 1 (cmp of the two spellings) is a required check, whichever way D2 goes; (b) mc_main says no machine registered before gen_lower (risk 5), in the same commit; (c) docs/guide/98-recreating-the-compiler.md is written for the developer of M39's original question and states, in one table, what each omitted part costs in bytes and in capability.

Implementation notes (mc-dev, 2026-09-04): where the landed milestone deviates #

Ten places where what landed differs from § Design, each with the reason. Everything else is the spec as written, including D1..D12 and the architect's three additions.

1. backend_macho lives in src/core_writers.mc, not in src/macho.mc. § 1 puts it in the writer's file; it calls gen_lower/gen_encode_all, which are <mc/core_min>'s, so putting it there would make src/macho.mc unincludable on its own -- and src/m0.mc (the M6 driver that builds the object model by hand and writes it) includes exactly objmodel.mc + macho.mc. The part that REGISTERS a backend is the part that defines it.
2. host_bundle_open lives in src/core_bundle.mc, not in src/bundle.mc. It calls host_include(), and tools/bundle.mc includes src/bundle.mc with no host layer at all.
3. sysroots_init() is called from mc_build_init(), not from main() as § 2 sketches. A part owning its own initialisation is what makes main() a list of parts and nothing else.
4. intrinsic_disable is tested at the head of res_call, not inside intrin_id. Two reasons: the diagnostic gets a POSITION (prog.mc:4: ld64: removed by this compiler instead of a bare mc: line), and intrinsic()'s own guard, if (intrin_id(name)) die2("cannot shadow a core intrinsic", name), keeps working -- a dying intrin_id would have refused a module that disables ld64 and then registers its own.

5. subcommand, on_plan and the intrinsic_disable name table use fixed ceilings (16, 8,

   1. rather than M23's growable tables, by M23's own rule: none of the three scales with the program being compiled. Same reasoning as MAXMACHINES and MAXTARGETS.
6. Four names had to move for the parts to be parts, and § 1's file list does not mention them: tm_cat and tm_num_str from src/toml.mc to src/arena.mc, MODE_755 from src/backend_exe.mc to src/arena.mc, and R_X86_PC32/R_X86_PLT32 from src/machine_x86_64.mc to src/objmodel.mc. The full assembly hides a cross-part dependency completely; scripts/check-parts.sh case 1b (below) is what found all four.
7. glob_place's al = 16 for a global ARRAY is left alone. § 4a C4 names three roundings to 16 (the two zerofill lines, the local array, the frame) and this is a fourth, in the data section rather than the frame. It is wasteful on a two-byte word and harmless; changing it is M40's call, with a real target to measure against.
8. The probe modules are files in lib/ and are NOT bundled. § 5's acceptance says "built inside check-parts.sh from the bundle, in check-standalone's style"; the entry files do take their core from the bundle, but the five lib/user_*.mc fixtures are reached by relative #include from build/parts/. Adding them to tools/bundle.list would move the blob -- and the five goldens -- for something no compiler includes.
9. The goldens were rewritten once per commit, four times, not once for the milestone. Every commit that touches src/ regenerates src/bundle_data.mc, which is part of src/mc.mc, so build/mc2.o moves in each of them; make check runs check-bundle before bootstrap and a stale bundle is a hard failure, so the alternative was a red make check in three of the four commits. Risk 1's intent -- "do not fold any other src/ change into the same commit" -- is honoured: each rewrite follows an empty --dump-asm diff between mc1 and mc2 and a passing cmp build/mc2.o build/mc3.o, and scripts/check-inert.sh runs across each step.
10. scripts/check-parts.sh proves one thing more than § Acceptance asks: case 1b, that <mc/core_min> plus EACH optional part compiles on its own. That is the property the five names of deviation 6 were violating while the whole assembly stayed green, and it is the regression class this milestone introduces.

Edit this page