2759f3e719
Their sharpening of my harness-note finding: a why in an authored file has a convention demanding a citation; a docstring has nothing, travels with the code, and reads as authoritative. Their instance was ring_row.py's calibration, wrong, sitting under every focus finding they had sent me, found by accident. Swept mine for numbers I had corrected in DECISIONS.md. Three live instances, each contradicting my own log. video.rs asserted '28 % of S00A's frames presented and 47 % of ADV's' as measured; boot.gd asserted that the same numbers 'refuted the claim outright'; dialog_rows.rs said 'by three routes'. All three were retracted days ago in the log and never in the code -- the percentages came from contended runs and the counter is an upper bound that goes vacuous once the engine outruns the stream, and three routes became two, one compound. verify-transcode-fidelity was the only one already correct. Third time this pattern has bitten me, and it is the one audio.json's own why warns about: a correction that does not reach the artifact a consumer reads has not been made. First was loop_why shipping a refuted story into manifest.json, second a BLOCKED row, this is code comments -- the worst of the three because they sit beside the thing they describe. So the class is now checked rather than swept: the retracted numbers are register rows carrying the propositions they asserted, and check-claims immediately failed on my own corrections quoting them unmarked. The next stale number of this kind fails a run instead of waiting for a sweep. What it does not cover is a docstring number that was never corrected anywhere. The register holds only what I have already retracted, so it catches propagation failures rather than wrong numbers -- their ring_row.py case would still have gone undetected here, because nothing had retracted that calibration. Their closing observation is the honest limit: the only thing that has actually caught these is one of us reading the other's sentence for its own sake, which is not a filter and does not scale. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
68 lines
3.8 KiB
Rust
68 lines
3.8 KiB
Rust
//! Independent check of "DIFFICULTY is a dialog: GP_DIALOG entries 2/3".
|
|
//!
|
|
//! The Decoder identified `DLG_SELECT_DIFFICULTY` as `GP_DIALOG.pak` entries 2/3
|
|
//! by TWO arguments, one of them compound — corrected from "three routes", which
|
|
//! was taking credit for the exclusion scan. The image leg names no entry, and
|
|
//! the disc and oracle legs are one argument, since the capture is compared
|
|
//! against the disc's rows. One of them is button count and geometry. That half is
|
|
//! readable from the disc with this port's own reader, so it is checked here
|
|
//! rather than taken on their word — the same form as re-deriving `ptbtn11`'s
|
|
//! row order from my export when they offered it.
|
|
//!
|
|
//! ⚠️ What this CANNOT check is their binding claim, and they flagged it first:
|
|
//! entries 2/3 are identified by button count and geometry, **not** by a binding
|
|
//! from the `DLG_` name to a pak entry. Another four-button dialog with the same
|
|
//! rows would be indistinguishable by this evidence. Reproducing the geometry
|
|
//! confirms the geometry; it does not name the screen.
|
|
use sylpheed_formats::{pak, ratc, ui_layout};
|
|
|
|
fn main() {
|
|
let root = std::env::var("SYLPHEED_DISC").unwrap_or_else(|_| "/disc".into());
|
|
// 🔴 WIDENED 2026-08-31 to every pak, to check the Decoder's rival search
|
|
// independently. They report zero four-button builds within 6 px of
|
|
// 259/329/399/469 anywhere on the disc, which turns "another dialog with
|
|
// these rows would be indistinguishable" from a standing reach into a
|
|
// bounded one. A disc-wide negative is exactly the claim worth re-running
|
|
// with a different reader, because its whole content is an absence.
|
|
const WANT: [i32; 4] = [259, 329, 399, 469];
|
|
const TOL: i32 = 6;
|
|
let mut paks: Vec<_> = std::fs::read_dir(format!("{root}/dat")).expect("dat/")
|
|
.flatten().map(|e| e.path())
|
|
.filter(|p| p.extension().and_then(|s| s.to_str()) == Some("pak")).collect();
|
|
paks.sort();
|
|
let (mut hits, mut scanned) = (0usize, 0usize);
|
|
for path in &paks {
|
|
let Ok(ar) = pak::PakArchive::open(path) else { continue };
|
|
let arch = path.file_name().unwrap().to_string_lossy().to_string();
|
|
for (i, e) in ar.entries().iter().enumerate() {
|
|
let Ok(by) = ar.read(e) else { continue };
|
|
if !ratc::is_ratc(&by) { continue }
|
|
let Some(b) = ui_layout::parse_build(&by) else { continue };
|
|
scanned += 1;
|
|
// Any button-shaped record, not just `pcbtn`: a rival need not share the
|
|
// naming convention, and restricting by name would answer a narrower
|
|
// question than the one asked.
|
|
let mut rows: Vec<(String, i32)> = b.elements.iter()
|
|
.filter(|el| el.name.contains("btn"))
|
|
.filter_map(|el| el.rest().map(|r| (el.name.clone(), r.y)))
|
|
.collect();
|
|
if rows.is_empty() { continue }
|
|
rows.sort_by(|a, b| a.1.cmp(&b.1));
|
|
let ys: Vec<i32> = rows.iter().map(|r| r.1).collect();
|
|
let gaps: Vec<i32> = ys.windows(2).map(|w| w[1] - w[0]).collect();
|
|
if rows.len() == 4 && ys.iter().zip(WANT.iter()).all(|(a, b)| (a - b).abs() <= TOL) {
|
|
hits += 1;
|
|
println!(" {arch} entry {i:>2} {} record(s): {}", rows.len(),
|
|
rows.iter().map(|r| r.0.as_str()).collect::<Vec<_>>().join(" "));
|
|
println!(" rows {ys:?} gaps {gaps:?}");
|
|
}
|
|
}
|
|
}
|
|
println!("\n {scanned} build(s) scanned across {} pak(s); {hits} match the",
|
|
paks.len());
|
|
println!(" DIFFICULTY row signature within +/-{TOL} px.");
|
|
println!(" Expected: exactly 2 -- the EN/JP pair. More means a RIVAL exists and");
|
|
println!(" the geometric identification is not unique; fewer means this reader");
|
|
println!(" cannot see the incumbents and its zero would mean nothing.");
|
|
}
|