fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the "sibling default" rules are a dedup artefact — WITHDRAWN

Browse Source 
The corpus recorded that some unit fields the disc leaves defaulted inherit
from a sibling: Size_Y from Size_X, FCSRange from RadarRange, DefencePoint
from AttackVesselPoint. Size_Y was marked the one to trust, on 9/9 support
across 7 independent ships, and it is restated in INDEX.md.

The premise is false. These fields are not defaulted -- they are on disc for
113-114 of 114 unit tables -- and Size_Y DIFFERS from Size_X in 90 of them.

The mechanism, cross-tabulating "legacy reader missed it" against "equal on
disc":

  pair                          seen+differ  seen+equal  miss+differ  miss+equal
  Size_Y / Size_X                    90          0            0           24
  FCSRange / RadarRange              54          0            1           58
  DefencePoint / AttackVesselPoint   51          0            1           61

seen+equal is 0 for all three: a value shared with a sibling is ALWAYS
invisible to the string-pool reader, because the pool stores each distinct
string once. And the reader almost never misses a value that differs. So
"the missing value equals the sibling's" was true BY CONSTRUCTION -- the rule
re-derived the very condition that made the field go missing. That is why the
support looked perfect: it could not fail on the cases it was fitted to.

The two miss+differ cells are its real wrong predictions, both named:
UN_e104_ADAN_Carrier DefencePoint is 0.2 (rule says 0.003), and
UN_e011_ADAN_Attacker_B_HF_Wayne FCSRange is 3000.0 (rule says 6000.0).

Retracted in unit-struct-runtime.md (original reasoning kept below the
correction), live-unit-definitions.md and INDEX.md. Pinned by a disc test
that asserts the seen+equal cells stay zero, so the mechanism itself is
guarded, not just the counts. Artifact: examples/sibling_rule_check.rs.

This one was found by my own check after the subagent assigned to it stalled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-25 23:38:55 +00:00
parent 61387d5ceb
commit 26bb0ec7a6
6 changed files with 266 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
docs/re/structures/unit-struct-runtime.md
View File

@@ -273,7 +273,57 @@ is no need to play it, and no need to survive it.
Stages captured so far: `Ttrl` (BASIC CONTROLS), Stage 02.
## A defaulted unit field is not a global constant — some inherit from a sibling
## ❌ WITHDRAWN — "some defaulted fields inherit from a sibling"
**The rules below are a string-pool DEDUPLICATION ARTEFACT. The fields were never
defaulted: they are on disc for 113–114 of 114 unit tables.** Measured
2026-08-25 against the [record table](idxd-container.md), which the old reader
could not see; artifact `examples/sibling_rule_check.rs`.
The premise was that these fields are absent from the disc. They are not:
| field | present on disc | **differs** from its claimed parent |
|---|---|---|
| `Size_Y` vs `Size_X` | **114 / 114** | **90** |
| `FCSRange` vs `RadarRange` | 113 / 113 | 55 |
| `DefencePoint` vs `AttackVesselPoint` | 113 / 113 | 52 |
So `Size_Y` does not "inherit" `Size_X` — it differs from it in 90 of 114 units.
### Why the rules nevertheless *worked*
The old reader infers a value from string-pool adjacency, and the pool stores
each distinct string **once**. So a field whose value equals a sibling's
contributes no token of its own and reads as absent. Cross-tabulating "reader
missed it" against "equal on disc" makes the mechanism exact:
| pair | seen + differ | seen + equal | **missed + differ** | missed + equal |
|---|---|---|---|---|
| `Size_Y` / `Size_X` | 90 | **0** | **0** | 24 |
| `FCSRange` / `RadarRange` | 54 | **0** | 1 | 58 |
| `DefencePoint` / `AttackVesselPoint` | 51 | **0** | 1 | 61 |
`seen + equal = 0` everywhere: a shared value is *always* invisible to the old
reader. And it almost never misses a field whose value differs. So "the missing
value equals the sibling's" was true **by construction** — the rule was
re-deriving the condition under which the field went missing in the first place.
That is why it looked so strong: 9/9, 4/4, 6/6 support. It could not have
failed on the cases it was fitted to.
### The two places it does fail
The `missed + differ` cells are the rule's wrong predictions, and both are real:
* `UN_e104_ADAN_Carrier` — `DefencePoint` is **0.2**; the rule predicts
`AttackVesselPoint` = 0.003.
* `UN_e011_ADAN_Attacker_B_HF_Wayne` — `FCSRange` is **3000.0**; the rule
predicts `RadarRange` = 6000.0.
**Use the record table.** The rules are unnecessary where they are right and
wrong where they are not.
### The original text, kept for the reasoning
**Confidence: 🟡 for `Size_Y`, ❔ for the rest. Analysis 2026-08-10, offline, from
[`captures/unit-runtime-fields.csv`](../captures/unit-runtime-fields.csv).**