diff --git a/crates/rrt-runtime/src/smp.rs b/crates/rrt-runtime/src/smp.rs index e7d5fa9..94a46d9 100644 --- a/crates/rrt-runtime/src/smp.rs +++ b/crates/rrt-runtime/src/smp.rs @@ -9485,6 +9485,19 @@ fn parse_event_runtime_collection_summary_with_tag_width( .collect::>(); mutation_candidate_unknown_descriptor_ids.sort_unstable(); mutation_candidate_unknown_descriptor_ids.dedup(); + let mut dispatch_strip_unknown_condition_ids = records + .iter() + .filter(|record| { + record.grouped_effect_rows.iter().any(|row| { + opcode_reaches_world_apply_compact_runtime_effect_dispatch_strip(row.opcode) + }) + }) + .flat_map(|record| record.standalone_condition_rows.iter()) + .filter(|row| row.raw_condition_id >= 0 && row.metric.is_none()) + .map(|row| row.raw_condition_id) + .collect::>(); + dispatch_strip_unknown_condition_ids.sort_unstable(); + dispatch_strip_unknown_condition_ids.dedup(); let mut control_lane_notes = Vec::new(); if nondirect_compact_record_count != 0 && nondirect_compact_record_count == nondirect_compact_records_missing_trigger_kind @@ -9520,6 +9533,12 @@ fn parse_event_runtime_collection_summary_with_tag_width( mutation_candidate_unknown_descriptor_ids )); } + if !dispatch_strip_unknown_condition_ids.is_empty() { + control_lane_notes.push(format!( + "standalone condition ids still missing checked-in labels in the 0x00431b20 dispatch strip = {:?}", + dispatch_strip_unknown_condition_ids + )); + } if !opcode_0x08_record_indexes.is_empty() { control_lane_notes.push(format!( "records with opcode 0x08 in the 0x00431b20 dispatch strip = {:?}", diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index a7ef9d0..6f91c28 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -270,6 +270,24 @@ Working rule: `0x00426d60 company_deactivate_and_clear_chairman_share_links`, so the open question is whether grouped descriptor id `548` is the missing compact-event label for that destructive company-clear path or a neighboring unmapped id-space entry in the same branch family + - the broader installed-map sweep narrows that question further: + across all `41` bundled `.gmp` files in the current `rt3_105/maps` install, grouped descriptor + id `548` currently appears only once, in `Texas Tea.gmp` record `7`, with `opcode 8`, + `scalar 0`, standalone condition tuple `(7, subtype 0)`, and compact signature family + `nondirect-ge1e-h0001-0007-0000-6d00-0200-p0000-0000-0000-ffff` + - the same wider sweep also rules out the simplest alias theory: + the ordinary checked-in `Deactivate Company` descriptor `13` does appear in real map bundles, + but only on `opcode 1` with scalar `1` in `British Isles.gmp`, `Chicago to New York.gmp`, + `East Coast, USA.gmp`, `Japan Trembles.gmp`, and `State of Germany.gmp`; it does not appear on + the `opcode 8` deactivation branch, so grouped descriptor id `548` is not just the obvious + compact stand-in for ordinary descriptor `13` + - the frontier is now best treated as a small compact-only opcode-`8` cluster rather than a + one-id anomaly: + the installed-map sweep now shows unlabeled grouped descriptor ids `[521, 526, 528, 548, 563]` + in the `0x00431b20` dispatch strip, all currently on opcode `8`, with current sightings in + `Alternate USA.gmp`, `Rhodes Unfinished.gmp`, `Louisiana.gmp`, and `Texas Tea.gmp`; the next + static-analysis pass should treat that as one branch family above `0x00426d60`, not five + unrelated missing labels - the concrete owner strip above that bundle is grounded now too: `0x00433060` is the direct non-direct serializer loop that writes `0x4e99/0x4e9a/0x4e9b`, calls `0x00430d70` per live collection row, and sits beside the sibling `0x00433130` size/load