Map infrastructure child constructor mode families

This commit is contained in:
Jan Petykiewicz 2026-04-18 15:36:06 -07:00
commit 38546f781e
3 changed files with 61 additions and 8 deletions

View file

@ -4316,7 +4316,7 @@ fn build_infrastructure_asset_trace_report(
"0x0048e140 / 0x0048e160 / 0x0048e180 route-entry resolver helpers".to_string(),
];
let next_owner_questions = vec![
"With 0x00491c60, 0x0048a6c0, 0x00490960, 0x00455a40, and 0x004559d0 now grounded as the full child-construction and write-side dispatch chain for the `0x38a5/0x38a6/0x38a7` family, which chooser branches feed 0x00490960 its caller-supplied stem and selector arguments before they surface in the seeded lanes [this+0x206/+0x20a/+0x20e], the slot +0x4c serializer, and the trailing 0x52ec50 footer path?".to_string(),
"With 0x00491c60, 0x0048a6c0, 0x00490960, 0x00455a40, and 0x004559d0 now grounded as the full child-construction and write-side dispatch chain for the `0x38a5/0x38a6/0x38a7` family, which save-side compact-prefix/name-pair classes correspond to the now-grounded 0x00490960 mode families (0x0a BallastCap, 0x0b TrackCap, 0x03 Overpass, 0x02 Tunnel, 0x01 Bridge) before they surface in the seeded lanes [this+0x206/+0x20a/+0x20e], the slot +0x4c serializer, and the trailing 0x52ec50 footer path?".to_string(),
"Inside the grounded overpass/ballast branch ([this+0x226]==3) of the paired chooser siblings, when do the fixed BallastCap and Overpass literals (0x5cb138/0x5cb150 and 0x5cb168/0x5cb180) fire, and does the pure BallastCap class 0x0055/0x00 stay a boundary artifact or become a real outer prelude consumed by 0x0048dcf0?".to_string(),
"Which 0x38a5 embedded name-pair groups survive into the per-child vtable +0x40 payload callbacks dispatched through 0x00455a50?".to_string(),
"Is cached primary-child slot [this+0x248] the first owner-visible bridge from the restored child stream into route-entry rebuild once the bridge two-child class is isolated?".to_string(),
@ -4356,6 +4356,8 @@ fn build_infrastructure_asset_trace_report(
"direct disassembly now also shows 0x004559d0 writing 0x55f1, serializing the three string lanes [this+0x206/+0x20a/+0x20e], writing 0x55f2, dispatching slot +0x4c, re-entering 0x52ec50, and then writing the closing 0x55f3 tag".to_string(),
"direct disassembly now also shows the paired chooser siblings calling 0x00490960 directly on the child-construction side, alongside 0x0048a340, 0x0048f4c0, and 0x00490200".to_string(),
"direct disassembly now also shows 0x00490960 copying selector fields into the child object ([this+0x219], [this+0x251], bit 0x20 in [this+0x24c], and [this+0x226]), allocating a fresh 0x23a Infrastructure child, seeding it through 0x00455b70 with caller-supplied stem input plus fixed literal Infrastructure at 0x005cfd74, attaching it through 0x005395d0, seeding position lanes through 0x00539530/0x0053a5b0, and optionally caching it as primary child in [this+0x248]".to_string(),
"the currently grounded direct-constructor chooser branches are narrower now too: the repeated calls at 0x004a2eba/0x004a30f9/0x004a339c feed 0x00490960 with mode arg 0x0a and stem arg 0x005cb138 = BallastCapDT_Cap.3dp, so they bypass the selector-copy block at 0x004909e2 and go straight into fresh child allocation/seeding".to_string(),
"the wider direct-calls sweep now also grounds stable 0x00490960 mode families: mode 0x0b pairs with fixed TrackCapDT/ST_Cap literals at 0x0048ed01/0x0048ed20, mode 0x03 with OverpassST_section at 0x00495a44, mode 0x02 with the decoded TunnelST/TunnelDT tables and zero-stem fallbacks across 0x004a17eb/0x004a1995/0x004a1b44/0x004a1b7d/0x004a1b95, and mode 0x01 with the decoded BridgeDT/BridgeST tables plus bridge zero-stem fallbacks across 0x004a1dae/0x004a2043/0x004a2082/0x004a221e/0x004a22a5/0x004a23aa/0x004a23eb/0x004a2409/0x004a24f6".to_string(),
"direct disassembly now also shows 0x00490200 reading the seeded lanes [this+0x206/+0x20a/+0x20e] back through the live route collection at 0x006cfca8, classifying peer relationships with [this+0x216/+0x218/+0x201/+0x202], and therefore acting as a route/link comparator above the same child payload fields that 0x004559d0 later serializes".to_string(),
"the chooser tables now decode to concrete asset families too: 0x621a44/0x621a54 feed BridgeST caps/sections, 0x621a64 feeds TunnelST cap/section variants, 0x621a74/0x621a84 feed BridgeDT caps/sections, and 0x621a94 feeds TunnelDT variants; fixed literals 0x5cb138/0x5cb150 are BallastCapDT/ST and 0x5cb168/0x5cb180 are OverpassDT/ST".to_string(),
"the top-level chooser branches are grounded now too: [this+0x226]==1 routes bridge families, [this+0x226]==2 routes tunnel families, [this+0x226]==3 routes overpass/ballast families, and bit 0x20 in [this+0x24c] selects the cap-oriented side over the section-oriented side inside those DT/ST siblings".to_string(),
@ -4688,7 +4690,7 @@ fn build_infrastructure_asset_trace_report(
"the smaller attach primitive 0x00490a3c no longer looks like the semantic fork by itself: it just allocates one literal Infrastructure child, seeds it through 0x455b70 with caller-provided stem input, attaches it through 0x5395d0, seeds position lanes through 0x539530/0x53a5b0, and optionally caches it as primary child".to_string(),
],
blockers: vec![
"which exact chooser branches and caller-supplied stem arguments feed 0x00490960 before the exact setter 0x0048a340 values ([this+0x226]/[this+0x219]/[this+0x251]/bit 0x20) surface in the concrete 0x004559d0 child payload serializer through the seeded lanes [this+0x206/+0x20a/+0x20e], slot +0x4c, and the trailing 0x52ec50 footer path, and therefore in the save-side 0x38a5 compact-prefix and name-pair classes, especially the bridge-only 0x0002/0xff class and the BallastCap-only 0x0055/0x00 class, now that [this+0x252] is partly grounded as the suspension-cap radius/handedness selector".to_string(),
"which save-side compact-prefix/name-pair classes correspond to the now-grounded 0x00490960 mode families outside the already-mapped BallastCapDT_Cap mode-0x0a direct-constructor path, especially the mode-0x0b TrackCap, mode-0x03 Overpass, mode-0x02 Tunnel, and mode-0x01 Bridge branches, before the exact setter 0x0048a340 values ([this+0x226]/[this+0x219]/[this+0x251]/bit 0x20) surface in the concrete 0x004559d0 child payload serializer through the seeded lanes [this+0x206/+0x20a/+0x20e], slot +0x4c, and the trailing 0x52ec50 footer path, and therefore in the save-side 0x38a5 compact-prefix and name-pair classes, especially the bridge-only 0x0002/0xff class and the BallastCap-only 0x0055/0x00 class, now that [this+0x252] is partly grounded as the suspension-cap radius/handedness selector".to_string(),
"how the payload streams reached through 0x00518380 -> 0x00518140 align with the embedded 0x55f1 name-pair groups and compact-prefix regimes surfaced by the save-side probe".to_string(),
"how the observed 0x55f3-to-next-0x55f1 gaps partition between the two 0x52ebd0 flag bytes and the next-record prelude now that 0x0048a6c0 is grounded as the writer for the outer child-count / primary-child prelude".to_string(),
"which fields written through the grounded 0x00490960 -> 0x004559d0 -> slot +0x4c -> 0x52ec50 chain retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(),
@ -4803,7 +4805,7 @@ fn build_infrastructure_asset_trace_report(
),
];
let notes = vec![
"Infrastructure asset trace now makes the side-buffer-versus-triplet split explicit: owner seam identity is grounded, the pure bridge-only 0x0002/0xff candidate class is grounded save-side, the upstream chooser above the child attach path is grounded as paired DT/ST siblings at 0x004a2c80 and 0x004a34e0 with decoded Bridge/Tunnel/BallastCap/Overpass families, grounded top-level branch meaning, grounded bridge/tunnel material selector roles, and a concrete child-construction/write-side chain through 0x00490960, 0x00491c60, 0x0048a6c0, 0x00455a40, and 0x004559d0; the remaining unknown is which chooser branches and caller-supplied stem values feed that chain before the seeded lanes, slot +0x4c payload, and trailing footer path collapse into the save-side classes.".to_string(),
"Infrastructure asset trace now makes the side-buffer-versus-triplet split explicit: owner seam identity is grounded, the pure bridge-only 0x0002/0xff candidate class is grounded save-side, the upstream chooser above the child attach path is grounded as paired DT/ST siblings at 0x004a2c80 and 0x004a34e0 with decoded Bridge/Tunnel/BallastCap/Overpass families, grounded top-level branch meaning, grounded bridge/tunnel material selector roles, a concrete child-construction/write-side chain through 0x00490960, 0x00491c60, 0x0048a6c0, 0x00455a40, and 0x004559d0, and stable 0x00490960 mode families for BallastCap, TrackCap, Overpass, Tunnel, and Bridge branches. The remaining unknown is how those grounded mode families collapse into the save-side compact-prefix/name-pair classes before the seeded lanes, slot +0x4c payload, and trailing footer path reach the serialized stream.".to_string(),
if st_only_name_pair_corpus {
"The current save-side side-buffer corpus is ST-only, so this trace directly exercises the ST chooser sibling while the DT sibling remains grounded statically but unexercised in this save.".to_string()
} else {
@ -24536,16 +24538,19 @@ mod tests {
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("chooser siblings calling 0x00490960 directly")
.any(
|line| line.contains("chooser siblings calling 0x00490960 directly")
&& line.contains("0x0048a340")
&& line.contains("0x0048f4c0")
&& line.contains("0x00490200"))
&& line.contains("0x00490200")
)
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("0x00490960 copying selector fields into the child object")
.any(|line| line
.contains("0x00490960 copying selector fields into the child object")
&& line.contains("0x00455b70")
&& line.contains("0x005cfd74")
&& line.contains("[this+0x248]"))
@ -24558,6 +24563,25 @@ mod tests {
&& line.contains("0x006cfca8")
&& line.contains("[this+0x216/+0x218/+0x201/+0x202]"))
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("0x004a2eba/0x004a30f9/0x004a339c")
&& line.contains("0x005cb138 = BallastCapDT_Cap.3dp")
&& line.contains("0x004909e2"))
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("mode 0x0b")
&& line.contains("TrackCapDT/ST_Cap")
&& line.contains("mode 0x03")
&& line.contains("OverpassST_section")
&& line.contains("mode 0x02")
&& line.contains("mode 0x01"))
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence

View file

@ -3070,6 +3070,19 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
same child payload fields that `0x004559d0` later serializes. So the remaining infrastructure
problem is which chooser branches feed `0x00490960` which stem/selector tuples for each
grounded save-side class, not where the child payload lanes come from at all.
One direct branch is grounded now too: the repeated chooser calls at
`0x004a2eba/0x004a30f9/0x004a339c` all feed `0x00490960` with mode arg `0x0a` and stem arg
`0x005cb138 = BallastCapDT_Cap.3dp`, so they bypass the selector-copy block at `0x004909e2` and
go straight into fresh child allocation/seeding. That means the remaining source-side mapping
problem is no longer generic BallastCap coverage; it is the other constructor branches,
especially the ones with mode `< 4` that actually populate the selector-byte copy block.
The broader mode family is grounded now too: a wider static callsite sweep shows mode `0x0b`
with fixed `TrackCapDT_Cap.3dp` / `TrackCapST_Cap.3dp`, mode `0x03` with
`OverpassST_section.3dp`, mode `0x02` with decoded tunnel table stems plus zero-stem fallbacks,
and mode `0x01` with decoded bridge table stems plus zero-stem fallbacks. So the remaining
infrastructure problem is no longer “what does `0x00490960` build?” but “how do those grounded
mode families collapse into the save-side compact-prefix/name-pair classes, especially the
already-grounded bridge-only `0x0002/0xff` class and BallastCap `0x0055/0x00` class?”.
The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
`Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The

View file

@ -92,6 +92,22 @@ Working rule:
`0x00539530/0x0053a5b0`, and can cache it as primary child in `[this+0x248]`. The remaining
problem is no longer “where do the child payload lanes come from?” but “which chooser branches
feed `0x00490960` which caller stem and selector tuple for each grounded save-side class?”.
- One direct branch is grounded now too: the repeated chooser calls at
`0x004a2eba/0x004a30f9/0x004a339c` all feed `0x00490960` with mode arg `0x0a` and stem arg
`0x005cb138 = BallastCapDT_Cap.3dp`, which means they bypass the selector-copy block at
`0x004909e2` and go straight into fresh child allocation/seeding. So the remaining source-side
mapping problem is no longer generic BallastCap coverage; it is the other constructor branches,
especially the ones with mode `< 4` that actually populate the selector-byte copy block.
- The broader mode family is grounded now too. A wider static callsite sweep shows:
- mode `0x0b` with fixed `TrackCapDT_Cap.3dp` / `TrackCapST_Cap.3dp`
- mode `0x03` with `OverpassST_section.3dp`
- mode `0x02` with decoded tunnel table stems plus zero-stem fallbacks
- mode `0x01` with decoded bridge table stems plus zero-stem fallbacks
So the remaining infrastructure question is no longer “what does `0x00490960` build?” but “how
do those grounded mode families collapse into the save-side compact-prefix/name-pair classes,
especially the already-grounded bridge-only `0x0002/0xff` class and BallastCap `0x0055/0x00`
class?”.
- The sibling `0x00490200` is tighter now too: it reads the seeded lanes
`[this+0x206/+0x20a/+0x20e]` back through the live route collection at `0x006cfca8`, compares
them against the current owner using `[this+0x216/+0x218/+0x201/+0x202]`, and behaves like a