Tighten infrastructure chooser selector boundaries

This commit is contained in:
Jan Petykiewicz 2026-04-18 15:13:24 -07:00
commit bb91dc1611
3 changed files with 57 additions and 4 deletions

View file

@ -4259,6 +4259,13 @@ fn build_infrastructure_asset_trace_report(
.iter()
.filter(|summary| summary.primary_name.contains("TrackCap"))
.count();
let st_only_name_pair_corpus = !name_pair_summaries.is_empty()
&& name_pair_summaries
.iter()
.all(|summary| summary.primary_name.contains("ST"))
&& !name_pair_summaries
.iter()
.any(|summary| summary.primary_name.contains("DT"));
let atlas_candidate_consumers = vec![
"0x00493be0 infrastructure tagged side-buffer collection load owner".to_string(),
"0x004a2c80 infrastructure composition chooser owner (DT family)".to_string(),
@ -4300,8 +4307,8 @@ fn build_infrastructure_asset_trace_report(
"0x0048e140 / 0x0048e160 / 0x0048e180 route-entry resolver helpers".to_string(),
];
let next_owner_questions = vec![
"Inside the grounded upstream chooser siblings 0x004a2c80 (DT) and 0x004a34e0 (ST), which selector-byte combinations at [this+0x219]/[this+0x251] choose the decoded Bridge/Tunnel family tables before the grounded pure bridge-section class 0x0002/0xff reaches the two-child clone-path above 0x0048a1e0 and 0x0048dcf0, now that [this+0x252] is grounded as the suspension-cap radius/handedness selector in the special [this+0x219]==2 path?".to_string(),
"Inside those same 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(),
"Inside the grounded bridge branch ([this+0x226]==1) and tunnel branch ([this+0x226]==2) of the upstream chooser siblings 0x004a2c80 (DT) and 0x004a34e0 (ST), which selector-byte combinations at [this+0x219]/[this+0x251] choose the decoded family tables before the grounded pure bridge-section class 0x0002/0xff reaches the two-child clone-path above 0x0048a1e0 and 0x0048dcf0, now that [this+0x252] is grounded as the suspension-cap radius/handedness selector in the special [this+0x219]==2 bridge path?".to_string(),
"Inside the grounded overpass/ballast branch ([this+0x226]==3) of those same 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(),
];
@ -4335,6 +4342,7 @@ fn build_infrastructure_asset_trace_report(
"direct disassembly now shows 0x00493be0 opening tag family 0x38a5/0x38a6/0x38a7, reading one shared dword into the owner-local 0x90/0x94 lane, iterating each live collection entry, and dispatching every loaded infrastructure record through 0x0048dcf0 before the later follow-on owners run".to_string(),
"direct disassembly now also grounds paired upstream chooser siblings: 0x004a2c80 routes the DT family and 0x004a34e0 routes the ST family, with both repeatedly calling 0x0048a1e0 and branching on child type codes at [this+0x226], selector bytes at [this+0x219]/[this+0x251]/[this+0x252], bit 0x20 in [this+0x24c], and follow-on owners 0x0048a340/0x0048f4c0/0x00490200/0x00490960".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(),
"the [this+0x252] selector is partially grounded now too: when [this+0x219]==2, the chooser jump tables dispatch fixed BridgeDT/BridgeST suspension-cap literals for R10, L10, 12, 14, 16, and 18 variants instead of using the general Bridge* table families".to_string(),
side_buffer
.and_then(|probe| probe.first_record_child_count_after_owner_shared)
@ -4662,7 +4670,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 selector-byte combinations at [this+0x219]/[this+0x251] drive the now-decoded DT/ST chooser siblings (BridgeST, BridgeDT, TunnelST, TunnelDT, BallastCap, Overpass) onto the grounded 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 selector-byte combinations at [this+0x219]/[this+0x251] drive the now-decoded DT/ST chooser siblings inside the already-grounded bridge/tunnel/overpass-ballast branches onto the grounded 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 the first 0x38a6 record head is grounded as child_count=1, saved_primary_child_byte=0xff, first 0x55f1 at +0x3".to_string(),
"which restored child fields or grouped rows retain the 0x38a5 embedded name-pair semantics before route/local-runtime follow-ons take over".to_string(),
@ -4777,7 +4785,12 @@ 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, and the upstream chooser above the child attach path is now grounded as paired DT/ST siblings at 0x004a2c80 and 0x004a34e0 with decoded Bridge/Tunnel/BallastCap/Overpass families; the remaining unknown is the selector-byte-to-class mapping inside those chooser siblings.".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, and the upstream chooser above the child attach path is now grounded as paired DT/ST siblings at 0x004a2c80 and 0x004a34e0 with decoded Bridge/Tunnel/BallastCap/Overpass families and grounded top-level bridge/tunnel/overpass-ballast branch meaning; the remaining unknown is the selector-byte-to-class mapping inside those chooser siblings.".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 {
"The current save-side side-buffer corpus is not ST-only, so both chooser siblings or a DT-facing save-side class may be in play.".to_string()
},
];
SmpInfrastructureAssetTraceReport {
profile_family: analysis.profile_family.clone(),
@ -24396,6 +24409,15 @@ mod tests {
&& line.contains("BallastCapDT/ST")
&& line.contains("OverpassDT/ST"))
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
.iter()
.any(|line| line.contains("[this+0x226]==1 routes bridge families")
&& line.contains("[this+0x226]==2 routes tunnel families")
&& line.contains("[this+0x226]==3 routes overpass/ballast families")
&& line.contains("bit 0x20 in [this+0x24c]"))
);
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence
@ -24447,8 +24469,15 @@ mod tests {
assert!(trace.notes.iter().any(|line| {
line.contains("0x0002/0xff candidate class is grounded save-side")
&& line.contains("paired DT/ST siblings at 0x004a2c80 and 0x004a34e0")
&& line.contains("grounded top-level bridge/tunnel/overpass-ballast branch meaning")
&& line.contains("BallastCap/Overpass")
}));
assert!(trace
.notes
.iter()
.any(|line| line.contains("ST-only")
&& line.contains("ST chooser sibling")
&& line.contains("DT sibling remains grounded statically")));
assert!(
trace.candidate_consumer_hypotheses[0]
.evidence

View file

@ -3017,11 +3017,23 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
remaining infrastructure question is no longer table discovery; it is the selector-byte mapping
from `[this+0x219]/[this+0x251]/[this+0x252]` onto those decoded families and then onto the
grounded `0x38a5` prefix classes.
The top-level chooser meaning is grounded now too: within those paired DT/ST siblings,
`[this+0x226]==1` routes the bridge families, `[this+0x226]==2` routes the tunnel families, and
`[this+0x226]==3` routes the overpass/ballast family, while bit `0x20` in `[this+0x24c]`
selects the cap-oriented side over the section-oriented side. So the remaining infrastructure
selector problem is below that top-level split: the exact `[this+0x219]/[this+0x251]` values
that choose the decoded family entries and how those values surface in the save-side `0x38a5`
classes.
One selector byte is partly grounded now too: when `[this+0x219]==2`, the chooser jump tables
stop using the general bridge families and instead route `[this+0x252]` through fixed
`BridgeDT/BridgeST` suspension-cap literals for `R10`, `L10`, `12`, `14`, `16`, and `18`.
So the remaining infrastructure selector problem is mostly `[this+0x219]/[this+0x251]` family
choice plus the exact save-side class mapping for the BallastCap branch.
The current real-save corpus also narrows the active side further: grounded `q.gms`, `p.gms`,
`g.gms`, and `nom.gms` only expose `ST`-family side-buffer names, while classic `rt3/` saves in
this workspace currently expose no `0x38a5` side-buffer seam at all. So the save-driven part of
the next infrastructure slice should assume it is exercising the `ST` chooser sibling directly,
with `DT` still grounded statically but not yet exercised by the current save corpus.
The child loader family is explicit now too: local `.rdata` at `0x005cfd00` proves the
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining

View file

@ -168,11 +168,23 @@ Working rule:
remaining infrastructure question is no longer table discovery; it is the selector-byte mapping
from `[this+0x219]/[this+0x251]/[this+0x252]` onto those decoded families and then onto the
grounded `0x38a5` prefix classes.
- The top-level chooser meaning is grounded now too: within those paired DT/ST siblings,
`[this+0x226]==1` routes the bridge families, `[this+0x226]==2` routes the tunnel families, and
`[this+0x226]==3` routes the overpass/ballast family, while bit `0x20` in `[this+0x24c]`
selects the cap-oriented side over the section-oriented side. So the remaining infrastructure
selector problem is below that top-level split: the exact `[this+0x219]/[this+0x251]` values
that choose the decoded family entries and how those values surface in the save-side `0x38a5`
classes.
- One selector byte is partly grounded now too: when `[this+0x219]==2`, the chooser jump tables
stop using the general bridge families and instead route `[this+0x252]` through fixed
`BridgeDT/BridgeST` suspension-cap literals for `R10`, `L10`, `12`, `14`, `16`, and `18`.
So the remaining infrastructure selector problem is mostly `[this+0x219]/[this+0x251]` family
choice plus the exact save-side class mapping for the BallastCap branch.
- The current real-save corpus also narrows the active side further: grounded `q.gms`, `p.gms`,
`g.gms`, and `nom.gms` only expose `ST`-family side-buffer names, while classic `rt3/` saves in
this workspace currently expose no `0x38a5` side-buffer seam at all. So the save-driven part of
the next infrastructure slice should assume it is exercising the `ST` chooser sibling directly,
with `DT` still grounded statically but not yet exercised by the current save corpus.
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
`0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded