Expose tri-lane save shape family candidates

This commit is contained in:
Jan Petykiewicz 2026-04-19 09:54:59 -07:00
commit 52a55c0a0e
2 changed files with 119 additions and 0 deletions

View file

@ -3796,6 +3796,10 @@ pub struct SmpPeriodicCompanyServiceTraceReport {
pub near_city_acquisition_tri_lane_live_service_status: String,
pub near_city_acquisition_candidate_subtype_projection_status: String,
pub near_city_acquisition_backing_record_projection_status: String,
pub near_city_acquisition_tri_lane_save_shape_family_status: String,
#[serde(default)]
pub near_city_acquisition_tri_lane_save_shape_family_candidates:
Vec<SmpPeriodicTriLaneSaveShapeFamilyCandidateSummaryEntry>,
#[serde(default)]
pub near_city_acquisition_tri_lane_live_owner_families: Vec<String>,
#[serde(default)]
@ -3833,6 +3837,17 @@ pub struct SmpPeriodicCompanyServiceTraceReport {
pub notes: Vec<String>,
}
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct SmpPeriodicTriLaneSaveShapeFamilyCandidateSummaryEntry {
pub rank: usize,
pub shape_family_signature: String,
pub rows_offset_hex: String,
pub row_count: usize,
pub row_stride_hex: String,
#[serde(default)]
pub best_probable_density_lane_relative_offset_hex: Option<String>,
}
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub struct SmpRegionServiceTraceEntry {
pub name: String,
@ -4672,6 +4687,32 @@ fn summarize_peer_site_selector_candidate_saved_nonzero_companion_name_pairs(
summaries
}
fn summarize_near_city_acquisition_tri_lane_save_shape_family_candidates(
analysis: &SmpSaveCompanyChairmanAnalysisReport,
) -> Vec<SmpPeriodicTriLaneSaveShapeFamilyCandidateSummaryEntry> {
let Some(probe) = analysis.region_fixed_row_run_candidates.as_ref() else {
return Vec::new();
};
probe
.candidates
.iter()
.take(5)
.enumerate()
.map(
|(index, candidate)| SmpPeriodicTriLaneSaveShapeFamilyCandidateSummaryEntry {
rank: index + 1,
shape_family_signature: candidate.shape_family_signature.clone(),
rows_offset_hex: candidate.rows_offset_hex.clone(),
row_count: candidate.row_count,
row_stride_hex: candidate.row_stride_hex.clone(),
best_probable_density_lane_relative_offset_hex: candidate
.best_probable_density_lane_relative_offset_hex
.clone(),
},
)
.collect()
}
fn build_periodic_company_service_trace_report(
analysis: &SmpSaveCompanyChairmanAnalysisReport,
) -> SmpPeriodicCompanyServiceTraceReport {
@ -4860,6 +4901,14 @@ fn build_periodic_company_service_trace_report(
"cached_candidate_id_bridge_grounded_via_stream_load".to_string();
let near_city_acquisition_backing_record_projection_status =
"stream_load_callback_grounded_via_0x40ce60".to_string();
let near_city_acquisition_tri_lane_save_shape_family_candidates =
summarize_near_city_acquisition_tri_lane_save_shape_family_candidates(analysis);
let near_city_acquisition_tri_lane_save_shape_family_status =
if near_city_acquisition_tri_lane_save_shape_family_candidates.is_empty() {
"save_shape_family_probe_missing".to_string()
} else {
"save_shape_family_candidates_present_fixed_offset_ruled_down".to_string()
};
let near_city_acquisition_tri_lane_live_owner_families = vec![
"0x0040d450 owner-company-aware local scorer producing [site+0x310]".to_string(),
"0x00410b30..0x004118f4 broader candidate-processing loop producing [site+0x310/+0x338/+0x360]"
@ -5384,6 +5433,20 @@ fn build_periodic_company_service_trace_report(
"Cross-save compare now tightens the save-native side too: `compare_save_region_fixed_row_run_candidates` keys the pre-region-header fixed-row bands by lane-shape fingerprint because grounded saves do not keep one stable top rows_offset, but they do retain shared shape-family matches. The tri-lane-adjacent save seam should therefore be treated as a stable row-family problem, not a fixed-offset problem."
.to_string(),
);
if let Some(best_shape_family) =
near_city_acquisition_tri_lane_save_shape_family_candidates.first()
{
notes.push(format!(
"The periodic-company trace now also carries the current top tri-lane-adjacent save row family: rank {} shape-family {} at rows {} with stride {} and probable density lane {:?}. That keeps the persisted side on a concrete save-native candidate family while the live tri-lane writers stay grounded separately.",
best_shape_family.rank,
best_shape_family.shape_family_signature,
best_shape_family.rows_offset_hex,
best_shape_family.row_stride_hex,
best_shape_family
.best_probable_density_lane_relative_offset_hex
.as_deref()
));
}
notes.push(
"Direct local binary inspection now grounds the cached-candidate restore bridge too: the placed-structure stream-load owner 0x00413280 dispatches per-entry vtable slot +0x40 on the 0x005c8c50 specialization table, that slot resolves to 0x0040ce60, and 0x0040ce60 immediately re-enters 0x0040cd70 plus 0x0045c150. So the acquisition-side cached source/candidate bridge [site+0x3cc/+0x3d0] is no longer a generic restore mystery for stream-loaded rows; the remaining restored-row gaps are [site+0x276] and the deferred tri-lane.".to_string(),
);
@ -5513,6 +5576,8 @@ fn build_periodic_company_service_trace_report(
near_city_acquisition_tri_lane_live_service_status,
near_city_acquisition_candidate_subtype_projection_status,
near_city_acquisition_backing_record_projection_status,
near_city_acquisition_tri_lane_save_shape_family_status,
near_city_acquisition_tri_lane_save_shape_family_candidates,
near_city_acquisition_tri_lane_live_owner_families,
near_city_acquisition_tri_lane_candidate_gate_fields,
near_city_acquisition_tri_lane_runtime_writer_roles,
@ -30091,6 +30156,40 @@ mod tests {
],
evidence: Vec::new(),
});
analysis.region_fixed_row_run_candidates = Some(SmpSaveRegionFixedRowRunCandidateProbe {
profile_family: analysis.profile_family.clone(),
source_kind: "save-region-fixed-row-run-candidates".to_string(),
semantic_family: "scenario-save-region-fixed-row-run-candidates".to_string(),
target_row_count: 4,
target_row_stride: 0xbc,
target_row_stride_hex: "0xbc".to_string(),
scan_start_offset: 0,
scan_start_offset_hex: "0x0".to_string(),
scan_end_offset: 0x2000,
scan_end_offset_hex: "0x2000".to_string(),
candidates: vec![SmpSaveRegionFixedRowRunCandidate {
count_offset: 0x40,
count_offset_hex: "0x40".to_string(),
row_count: 4,
row_stride: 0xbc,
row_stride_hex: "0xbc".to_string(),
rows_offset: 0x5310,
rows_offset_hex: "0x5310".to_string(),
rows_end_offset: 0x5600,
rows_end_offset_hex: "0x5600".to_string(),
distance_to_region_metadata_tag: 0x80,
distance_to_region_metadata_tag_hex: "0x80".to_string(),
dword_lane_summaries: Vec::new(),
shape_signature: "shape-a".to_string(),
shape_family_signature: "family-a".to_string(),
trailing_byte_zero_count: 4,
trailing_byte_nonzero_count: 0,
trailing_byte_distinct_value_count: 1,
trailing_byte_sample_values_hex: vec!["0x00".to_string()],
best_probable_density_lane_relative_offset_hex: Some("0x24".to_string()),
}],
evidence: Vec::new(),
});
analysis
.company_entries
.push(SmpSaveCompanyRecordAnalysisEntry {
@ -30261,6 +30360,21 @@ mod tests {
trace.near_city_acquisition_site_cached_tri_lane_projection_status,
"live_writer_family_grounded_semantics_and_persisted_inputs_missing"
);
assert_eq!(
trace.near_city_acquisition_tri_lane_save_shape_family_status,
"save_shape_family_candidates_present_fixed_offset_ruled_down"
);
assert_eq!(
trace
.near_city_acquisition_tri_lane_save_shape_family_candidates
.len(),
1
);
assert_eq!(
trace.near_city_acquisition_tri_lane_save_shape_family_candidates[0]
.shape_family_signature,
"family-a"
);
assert_eq!(
trace.near_city_acquisition_tri_lane_live_service_status,
"candidate_gate_and_live_writer_family_grounded_exact_formula_and_persisted_inputs_missing"

View file

@ -95,6 +95,11 @@ Working rule:
`runtime compare-region-fixed-row-runs p.gms q.gms` shows shared shape-family matches even
though the best raw `rows_offset` drifts between saves, so the tri-lane-adjacent row family
should be treated as a stable shape-family seam rather than a fixed-offset seam
- the periodic-company trace now carries that save-native seam directly too:
it exposes the current top tri-lane-adjacent fixed-row shape-family candidates with row-count,
stride, rows-offset, and probable-density-lane hints, so the tri-lane frontier is now
structured as “save shape-family candidates present, fixed offset ruled down” instead of only
a prose note
- the `0x5dc1/0x5dc2` serializer bundle is tighter now too:
atlas-backed recovery bounds `0x0040c980 -> 0x0045b560` as emitting the derived payload over
`[site+0x23e/+0x242/+0x246/+0x24e/+0x252]`, so the remaining restore-owner question should