Promote Kurumajiku as a compiler-owned class TU

[andrewboudreau]

Promotes ov047/daObjKm3_Kurumajiku_c from five intake files into one production C++ translation unit. One mwccarm invocation now owns the D1/D0 pair, InitResources, CleanupResources, RickshawBs_Spawn, the resource descriptor, type-name string, SpawnInfo, and vtable storage. Per-symbol contributor credit is preserved through the prerequisite branch.

Validation after restacking onto current main and the refreshed #2001:

• all five functions independently VERIFIED with blind: 0 and retain ROM order
• independent ROM-gap control: 11,082/11,082 reproducing, 106/106 exact modules, Kurumajiku source-owned data removed
• production: 11,087/11,087 reproducing, 106/106 exact modules, 200 source-owned data bytes
• complete executable-module set SHA-256: f9852ffaf80ef19662ab5535df4b13b935188ac3087b5b1d4561c089e4dd802b
• control and production ROM SHA-256: d1506e90efae5e2d2cf119926a4ac2a291bd5ca78349d09d5024e1a918c478e8; production is bit-identical to the admitted same-worker stock control
• intact-TU gates: zero new symbol errors and zero storage-alias errors
• targeted emitted data: 8 VERIFIED (220 bytes), 7 PARTIAL (96 verified bytes), 0 DIFFERS, 0 UNNAMED
• 89/89 manifest TUs compile; 405/405 port references resolve
• eligibility: 11,095/11,210; 42 unresolved versus main's baseline 45; no new unresolved or dead references
• attribution against Add fail-closed compiler-owned C++ TU promotion #2001: 0 changed, 0 lost
• focused TU/ROM suite: 244 passed, 1 skipped

The class's own _ZTI21daObjKm3_Kurumajiku_c remains separately gap-owned because mwccarm emits it in a different section order than retail. That is the remaining metadata debt; no .init, .ctor, or .bss ownership changes are claimed.

Stacked on and dependent upon #2001. This remains draft/parked for the requested ctor/dtor migration pacing even after validation turns green; it is not being marked ready or merged automatically.

[tangos-validator]

✅ PR validation — Passed

Committed merge introduces no reconstruction or attribution regression.

Full merge validation

Check	Result
Committed test merge	yes
Byte-verified functions	10,994 / 11,347 (96.89%, -4)
Byte-verified code bytes	2,045,044 / 2,211,124 (92.49%, -204)
Claimed, not byte-verified	222 functions, 60,260 bytes (+4)
Perfect source moves	0 R100
Enrolled ranges (delinks complete)	11,058 functions, 2,052,772 bytes (92.84%, +0) -- differs from byte-verified by +64
Contributor credit	0 added, 0 changed, 0 lost
Relocation check	5 checked; 5 VERIFIED
Port reference check	405 checked; 0 stale
Module fidelity	106/106 exact; 100.000000% compared bytes
Code linked from verified source	11,087 functions, 2,066,772 bytes (93.47%)
Module bytes from source	2,066,772 / 3,049,600 (67.8%); 811,492 (26.6%) are data no delink entry reaches
ROM data reproduced from source	457 symbol(s) exact, 242 partial, 9 differ

Byte-verified means the range carries complete in a delinks.txt, so the ROM build compiled it and compared it to the cartridge. The 222 claimed functions have a src/ file named after the symbol with no NONMATCHING banner, and nothing compiles them -- dsd fills their addresses with the ROM's own bytes. Both together are the 11,216 this project calls matched.

Warnings: 5 address range(s) left the byte-verified set while enrolled totals held steady: ov047:0x021111a0-0x021111f0, ov047:0x021111f0-0x02111254, ov047:0x02111254-0x02111268, ov047:0x02111268-0x02111280, ov047:0x02111280-0x021112bc; 4 more function(s) now claim a match that nothing compiles; enroll them in a delinks.txt to have the ROM build check them.

Per-file link-check detail

All 1 changed file(s) compile to the ROM byte-for-byte with correct relocation targets.

File	Symbol	Result	Slots checked
src/actors/daObjKm3_Kurumajiku_c.cpp	_ZN21daObjKm3_Kurumajiku_cD1Ev + _ZN21daObjKm3_Kurumajiku_cD0Ev + _ZN21daObjKm3_Kurumajiku_c16CleanupResourcesEv + _ZN21daObjKm3_Kurumajiku_c13InitResourcesEv + RickshawBs_Spawn	✅ verified	5

_{The private worker commits a test merge, builds the stock ROM profile, compares every executable module, measures matched and source-built code, checks contributor lineage, and verifies affected relocations. The mod profile is opt-in and is not part of this merge gate.}

[andrewboudreau]

Review: KEEP AND FIX (the content is right; the base is not)

Reviewed at pr/2004 = 81d234855, merge-base with main d08ac657b. origin/main = f822d4908.

The delinks and symbols work is correct, and I verified it against the cartridge

Delinks collapse. The five per-function complete entries in config/arm9/overlays/ov047/delinks.txt are contiguous (0x211_11a0 -> 11f0 -> 1254 -> 1268 -> 1280 -> 12bc) and collapse into exactly one entry:

src/actors/daObjKm3_Kurumajiku_c.cpp:
    complete
    .text start:0x021111a0 end:0x021112bc
    .data start:0x02112258 end:0x02112320

One entry, marked complete, naming a path that exists and is git-tracked. The .data span is 0xC8 = 200 bytes, matching the PR body.

layout_check.py, run read-only against an export of this branch's tree:

[ok  ] L1 delinks names a path with no file there: 0
[ok  ] L2 two source files share a symbol: 0
[ok  ] L3 misfiled under src/unnamed/: 0
[ok  ] L4 one class split across two directories: 0
[info] L5 source file not enrolled in any delinks.txt: 104
layout-check: clean

So the failure mode this project cannot otherwise self-detect — a range losing complete, or naming a file that is not there, and dsd silently refilling it from retail bytes — is not present here. L1 is zero.

The data_ov047_02112298 removal is right, and the ROM says so. From extracted/dsd/arm9_overlays/ov047.bin (load base 0x021111a0):

0x02112298: 0x00000000     <- offset-to-top
0x0211229c: 0x0211224c     <- = &_ZTI21daObjKm3_Kurumajiku_c
0x021122a0: (the named vtable symbol, i.e. the ABI address point)

0x2112298 is the true start of the _ZTV object, eight bytes before the address point, exactly as the Itanium ABI lays it out. A separate symbol there was splitting one object in two, and removing it is correct.

_ZTI21daObjKm3_Kurumajiku_c (12 bytes at 0x0211224c) sits before the claimed .data range and stays gap-owned. That is a metadata debt, not a regression — no byte of it was source-owned before this PR either — and the PR body says so honestly.

This PR genuinely needs #2001. That is not just stacking convenience.

I did not expect to find this, so it is worth stating plainly. tools/rombuild_check.py on main parses a complete entry by overwriting sec on every section line, so it keeps only the last section. Feeding this branch's own ov047/delinks.txt to both parsers:

MAIN's rombuild_check   -> ('src/actors/daObjKm3_Kurumajiku_c.cpp', 0x2112258, 0x2112320)   200 bytes   <- the .data range
#2001's rombuild_check  -> ('src/actors/daObjKm3_Kurumajiku_c.cpp', 0x21111a0, 0x21112bc)   284 bytes   <- the .text range

Landed on main as-is, this entry's 200 bytes of data would be counted as source-linked code, and 284 bytes of real .text would silently drop out of the coverage metric. I scanned every delinks.txt on f822d4908: zero complete entries currently carry a non-text section, so this branch is the first thing in the tree to trip the bug. #2001's complete_entry_sections_text split is the fix.

Same story for the compile path: git grep -l intact-object -- config/tu_manifest.d returns 0 on main and 0 on #2001; this PR's ov047/daObjKm3_Kurumajiku_c.json is the only entry in the queue requesting production_mode: intact-object. #2001 is dormant machinery until this PR turns it on.

Why it cannot land as written

1. It is stacked on an orphan. git merge-base --is-ancestor pr/2001 pr/2004 -> NO. #2001 was force-rebased to 56a2611ac; this branch is still built on its pre-rebase head 732b0176c. Its merge-base with main is d08ac657b.

2. It conflicts with main.

git merge-tree --write-tree origin/main pr/2004
CONFLICT (content): config/converted-baseline.json
CONFLICT (content): notes/cpp-tu-current-state.md
CONFLICT (content): tools/tiers_ratchet.py

The baseline conflict is the dangerous one. This branch carries 1957 entries; main carries 2565. Resolving it whole-file toward this branch drops 608 banked entries — and a shrunken baseline is permissive, so nothing downstream would report it. Union by key, never --ours/--theirs.

3. Three # identities are banked with no exception rows. This branch's config/converted-baseline.json contains:

src/actors/daObjKm3_Kurumajiku_c.cpp#_ZN21daObjKm3_Kurumajiku_c13InitResourcesEv
src/actors/daObjKm3_Kurumajiku_c.cpp#_ZN21daObjKm3_Kurumajiku_c16CleanupResourcesEv
src/actors/daObjKm3_Kurumajiku_c.cpp#_ZN21daObjKm3_Kurumajiku_cD1Ev

These are the first # keys anywhere in the project (main has 2565 entries, 0 with #), and git diff <base> pr/2004 -- config/converted-backslide-exceptions.jsonl adds 0 lines. The identity-scheme migration is arriving as a side effect of an actor promotion, in a file that is already the queue's worst conflict chokepoint. It belongs in #2001 with its own --reason, not here.

4. Standalone landing is a different PR. Under main's tooling those three identities read as GONE -- not a tracked source file any more; tiers.score_member does not exist there. Landing this without #2001 would instead need the #2007 route: the three legacy paths become MOVED into src/actors/daObjKm3_Kurumajiku_c.cpp, which scores no_unk_field: False and no_mangled_refs: False under main's tiers.py (lines 56-59 declare _ZN7fBase_cnwEj, _ZN10dBgActor_cC2Ev, _ZTV17daObjKurumajiku_c, _ZTV21daObjKm3_Kurumajiku_c) — so a --update --reason plus three exception rows. Combined with finding (2) above, that would also mis-measure the coverage metric. So: no, this cannot land independently of #2001 as written.

What I did not verify

I did not build. rombuild.py and eligible.py were deliberately not run — build/ is shared across worktrees and a concurrent run produces fake failures. The PR body's 106/106 and its objisolate evidence are unchecked by me. Note also that since #1994 merged (2026-08-30), the validator runs the PR's own tools/, so this branch's numbers would come from #2001's rewritten rombuild.py, not main's.

Order of operations

1. Rebase onto Add fail-closed compiler-owned C++ TU promotion #2001's current head 56a2611ac, or onto main once Add fail-closed compiler-owned C++ TU promotion #2001 lands.
2. Move the three # baseline entries (and the tiers_ratchet.py delta) out of this PR and into Add fail-closed compiler-owned C++ TU promotion #2001.
3. Resolve config/converted-baseline.json by key union against main's 2565, and re-run tiers_ratchet.py --check.
4. Keep the delinks collapse, the data_ov047_02112298 removal, the manifest entry and the source rename exactly as they are — that part is correct and ROM-verified.

Read-only review against the main checkout; no worktree, no build.

[andrewboudreau]

Gatekeeper re-review — content clean, blocked only on #2001

I re-verified this branch independently rather than inheriting the earlier read. No changes are needed to the content. Everything blocking it is mechanical.

What I verified

• No erosion. Recomputed the enrolled-range union directly from every delinks.txt: 43243bfb gives .text 1,941,060 B + .init 125,712 B = 2,066,772 B across 11,025 complete entries — byte-identical to origin/main, and matching the validator's absolute row. This branch adds 200 B of .data.
• The delinks collapse is lossless. The five ranges 0x21111a0 -> 11f0 -> 1254 -> 1268 -> 1280 -> 12bc are contiguous and become one .text 0x021111a0..0x021112bc plus a new .data 0x02112258..0x02112320.
• The one symbols.txt deletion is correct, not erosion. data_ov047_02112298 sat 8 bytes before _ZTV21daObjKm3_Kurumajiku_c at 0x021122a0, and the manifest records emitted_storage_address: 0x02112298 with address_point_bias: 0x8. It was the Itanium vtable preamble splitting one object into two records. Removing it merges them; nothing is lost.
• No compiler_only_output at all on this entry — _ZTI21daObjKm3_Kurumajiku_c stays a canonical import, so the RTTI plain-deadstrip hazard Refuse an RTTI/vtable record banked as a plain deadstrip #2019 just landed a guard for does not apply here.
• No NONMATCHING in src/actors/daObjKm3_Kurumajiku_c.cpp; no raw address arithmetic.
• The converted-baseline edit (4 plain paths -> 4 #symbol identities) follows Add fail-closed compiler-owned C++ TU promotion #2001's own ActorBase_SceneNode precedent, and the attribution.json edit appends 5 keys and drops none.

One thing that will be misread

The live validator comment (updated 16:55, current head) still says "5 address range(s) left the byte-verified set", -4 functions / -204 bytes. Given the union table above and the unchanged absolute row, that is the documented consolidation bookkeeping artifact — the (+N) deltas drop on every TU consolidation while Code linked from verified source holds. Somebody will read it as a regression. Worth a line in the PR body pre-empting that.

Landing sequence — unchanged, and the order is forced

1. gh pr edit 2004 --base main before Add fail-closed compiler-owned C++ TU promotion #2001 merges.
2. Merge Add fail-closed compiler-owned C++ TU promotion #2001 with plain --merge. Not --delete-branch — GitHub closes a stacked child rather than retargeting it, and recovery is painful.
3. Push main into this branch and re-validate. That re-validation is the first time source-coverage.yml and converted-ratchet.yml will ever have seen this PR — both landed after it was cut and are path-filtered away from its current diff.
4. Merge this.
5. Delete tools/tu-control-policy-0830 by hand afterwards.

git merge-tree origin/main 43243bfb conflicts on attribution.json and notes/cpp-tu-current-state.md — expected for a stacked branch. Resolve attribution.json by key union, never --ours/--theirs; a whole-file take silently reverts unrelated auto-merged changes elsewhere in the file.

One unanswered ask, carried forward

This branch's complete claim on .data 0x02112258..0x02112320 was proven by the validator running the PR's own rewritten rombuild.py/rombuild_check.py — since #1994 the validator no longer restores tools/ from base. Reproducing 106/106 under main's tools before merge is still the right ask, and it is still unanswered. That is a #2001 obligation more than a #2004 one, but it gates this PR too.

Stays a draft until #2001 lands. Nothing for the author to do here except step 1.

[andrewboudreau]

Retargeted this PR from tools/tu-control-policy-0830 (#2001's head) to main.

Why, and why now: this repo auto-deletes head branches on merge. When #2001 merges,
GitHub deletes tools/tu-control-policy-0830 and closes any PR still based on it — it
does not retarget the child. That would have closed this PR with no warning, and the
recovery order after that happens is awkward. Doing it while both are still drafts costs
nothing.

What changed as a side effect: against main this now reads CONFLICTING/DIRTY and
its diff shows ~2,549 insertions across 30 files, because it currently carries #2001's
commits as well as its own. That is expected for a stack pointed at main and is not a
regression in this branch. Once #2001 lands, the diff collapses back to this PR's own work
and the inherited conflicts should go with it.

Nothing here needs action from the author yet. #2001 still has an open blocking review;
this one stays a draft behind it.

[andrewboudreau]

Separability from #2001: measured, and the answer is not separable

I wanted to know whether this PR could land ahead of #2001's Group B, since Group B has two required
reworks outstanding and #2004 is stacked behind it. So rather than reason about it, I cut the branch
and built it.

Same invocation both rows — python tools/rombuild.py -j 16, one worktree:

tree	result
unmodified origin/main (48ae82060)	106/106 exact, 100.000000% · ROM-build analysis: PASS
origin/main + this PR's promotion, no tools/ changes	FAILS at step [3/6] mwccarm

src/actors/daObjKm3_Kurumajiku_c.cpp: isolate: unlicensed content in text-only multi-symbol object:
section[5] .data size 0x8 defines ['_ZTI7fBase_c']; ... section[27] .data size 0x88 defines
['_ZTV21daObjKm3_Kurumajiku_c']

15 unlicensed .data sections. Main is green with the identical command and the failing file does not
exist there, so this is the promotion's own failure, not ambient breakage.

The coupling is one line of delinks, not the manifest

rombuild.py:_isolate() routes a multi-function source to objisolate.isolate_many(obj, selected)
where selected is the enrolled function list — there is no .data-keeping path, and the refusal
is objisolate.py:328. Main's own docstring states it outright: "admits no content the manifest has
not licensed — including the vtable a key function drags in."

This PR's delinks add .data start:0x02112258 end:0x02112320 — the TU now owns its vtable/RTTI —
and main's isolator cannot express that. #2001's objisolate.py (+104/−24) is exactly what lifts it,
via rebias_object_symbols' normalize_undefined and RELA/ABS32 addend rewriting for _ZTV
storage-start vs public-address-point. That is the same thing this PR's header edit documents
((its record sits at V-4) → (storage starts at 0x02112298)), and why data_ov047_02112298 drops
out of symbols.txt.

Three things I had flagged as blockers that are not

• The 769-line manifest shrink is not a reformat, and is still fine. It drops partitioned_link
  (724 lines) and partial_isolation (53), read only by tubuild.py/tu_production.py — dev tools,
  no gate. production_mode is read by nothing at main. externalized_output is byte-identical.
  Loaded with main's unmodified tu_manifest.py: status: promoted, and promoted_moves()
  resolves all five absorbed paths.
• The baseline arithmetic resolved itself. The path#symbol schema was Add fail-closed compiler-owned C++ TU promotion #2001's when I first
  raised it; converted ratchet: score a promoted TU per member, not per file #2052 landed it on main, so the +4/−4 member-identity swap here is now native.
  4 of the 5 deleted src/ files were banked; src/RickshawBs_Spawn.c (a .c file) was not — same
  shape as Promote daObjKinokoTag_c to a genuine C++ translation unit #2051.
• no_mangled_refs: false is correct and blessed. 4 code-only hits — _ZN7fBase_cnwEj and
  _ZN10dBgActor_cC2Ev, each declaration + call — both genuine extern "C" ABI seams.
  Correcting my own earlier premise: _code_only() strips comments, so // @symbol _ZN... lines
  do not trip the matcher. Main's classify_missing docstring predicts exactly this and calls it
  the correct outcome for a reconstructed TU, banked with a --reason.
• Delinks collapse is clean. 5 entries → 1; the ov047 .text chain is 16 rows with zero gaps and
  zero overlaps, endpoints 0x21111a0–0x21116dc identical to main; 20 file headers / 20 complete
  markers; the new .data range sits inside the overlay's 0x021119e0–0x021125e0.

What this means for ordering

Stay stacked on #2001's Group B. Do not retarget this to main — it will fail the ROM build, and
that failure is not visible in a diff review.

One alternative I did not test, so treat it as unverified: this could in principle be re-cut
text-only, licensing the 15 data sections through main's existing deadstrip-data disposition (their
homes lie outside the claimed text range, which main permits). That needs a 15-row
compiler_only_output policy with canonical addresses — and it forfeits the vtable ownership that is
this PR's entire point. I'd rather wait for Group B.

Also note this PR is currently DIRTY and needs a rebase regardless; when Group B lands squashed,
this must drop its duplicated copies of those commits.

No byte claim beyond the two rombuild runs above. Nothing here was pushed or modified.

[andrewboudreau]

You are unblocked. Measured against today's main — and I had the mechanism wrong.

Group B landed as #2054, squashed into main at 7b4eeabfb. I re-ran the same separability
experiment I ran when I told you to stay stacked, against today's main this time.

Two rows, identical invocation — python tools/rombuild.py -j 16 --no-rom, one worktree, sequential

	unmodified main 7b4eeabfb	main + this PR's build inputs only
verdict	ROM-build analysis: PASS	ROM-build analysis: PASS
module fidelity	106/106 exact, 100.000000%	106/106 exact, 100.000000%
source-built functions	11,088	11,088
reproducing / mismatching	11,088 / 0	11,088 / 0
source-owned data	0	200 bytes
source-owned data claims	(line absent — zero)	1 (reproducing 1, mismatching 0)

Previously this same promotion failed at step [3/6] with 15 unlicensed .data sections. It now
builds clean. Function count is unchanged at 11,088 — the five functions survive the merge into one TU
— and exactly 200 bytes (0xC8, matching your claimed .data 0x02112258..0x02112320) move out of
"no complete source entry reaches this" and into source-owned. intactTus = ["ov047/daObjKm3_Kurumajiku_c"], intactTuLinkVerification.ok = true.

Correcting myself: objisolate is not what lifted the refusal

In my earlier comment on this PR I wrote that objisolate.py's rebias_object_symbols was "exactly
what lifts" the objisolate.py:328 refusal. That was wrong, and I want it on the record here rather
than quietly superseded. The refusal is not lifted — it is never reached. Main's
rombuild.py:_isolate (line 344) now short-circuits before isolate_many ever runs:

intact = (intact_tus or {}).get(rel.replace("\\", "/"))
if intact is not None:
    prepared, _evidence = TP.prepare_intact_object(obj.read_bytes(), intact)
    obj.write_bytes(prepared); return None

rebias_object_symbols is necessary but not sufficient — it is called from inside
tu_production.prepare_intact_object. What actually admits your .data claim is the trio of the new
intact-object route in _isolate, prepare_intact_object, and the fail-closed
rombuild.intact_tu_policies() gate, which demands production_mode: intact-object, a promoted src/
path, both .text and non-text claims, a green scratch-data-verified proof, a matching ROM SHA-256,
and a symbol-error inventory identical to the baseline. Your manifest entry satisfies all of them
unchanged.

Your promotion is the first real exerciser of #2054's data-claim path

Worth knowing, because it retires a caveat I published on #2054. That PR's rework-2 diagnostics had to
ship with a synthetic fixture — measured across all 106 delinks.txt, source-owned non-.text was
0 bytes tree-wide, so the new loop had nothing real to iterate. Your PR is the first one that does:

sourceDataClaims          = 1
reproducingDataClaims     = 1
reproducingDataClaimBytes = 200
mismatchingDataClaims     = 0

What to drop on rebase

git diff origin/main..43243bfb currently touches 271 files / −14,289 lines — that is this branch
reverting main's newer work. Rebase, do not merge. Of your 25 commits (18 tools: + 2 metadata:

• 5 tu:), all 18 tools: commits are now dead weight. Line-level check of your added lines
  against main:

• Byte-identical to main, drop outright: objisolate.py, test_objisolate.py, tiers.py,
  tu_promote.py, test_tu_production.py, test_tu_promote.py
• Fully subsumed (0 added lines missing from main): rombuild.py (219), tiers_ratchet.py (157),
  test_tiers_ratchet.py (164), test_rombuild.py (111), rombuild_check.py (68),
  test_rombuild_check.py (30)
• Near-total: tubuild.py 203/208, tu_production.py 187/188, test_tubuild.py 133/147. The
  residue is only stale signature variants (rom_inputs=None, control_tools=None, config_root=...)
  that Group B of #2001, re-cut on current main: intact-TU production, with the two review regressions fixed #2054's re-cut rewrote — superseded, not missing.

So: drop every tools/** and .github/** change; drop config/converted-baseline.json and
attribution.json and regenerate them against main rather than carrying yours forward; keep only
the 5 tu: commits — manifest, delinks, symbols, header, the promoted source, and the five deletions.

The five files I brought across were verified to have zero drift on main since your merge-base
25cfc1363, so nothing you wrote has been overwritten:
config/arm9/overlays/ov047/{delinks,symbols}.txt,
config/tu_manifest.d/ov047/daObjKm3_Kurumajiku_c.json, include/daObjKm3_Kurumajiku_c.h,
src/actors/daObjKm3_Kurumajiku_c.cpp.

Not verified — do not read this as a merge approval

• Only rombuild.py -j 16 --no-rom was run. No eligible.py, no romdata_check.py, no
  tiers_ratchet.py --check, no premerge_check.py, no unit suites.
• I deliberately excluded config/converted-baseline.json, so whether your ratchet entries are
  still correct is unknown. Given that TU promotion now scores per-member (path#symbol) on main,
  they most likely need regenerating rather than rebasing.
• The mechanism claim above comes from reading main's _isolate, not from a negative experiment — I
  did not re-prove that the old isolator still refuses.
• Pre-existing tree state, not yours: the 8-step baseline control emits [7/8] dsd check symbols --fail with 9 errors (overlay_100, data_020ad524, func_01ff98f4, _deq, …). The intact-TU
  gate reported zero new symbol errors, so this is ambient and not a regression from your change.

Rebase, regenerate the metadata, take it out of draft, and I will run the full gate set on the merge
tree. Nothing was pushed to your branch and nothing here was merged.