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

port: the ordered pair determines the gap; nothing declared predicts it

Browse Source 
Their run gives five replicates with no variation -- title->menu 3,3,3 and
EXTRAS->menu 2,2 -- while every differing value comes from a different ordered
pair, and the same origin gives different values to different destinations. The
origin constrains; the ordered pair determines.

That excludes a second model for black_hold_units: a constant was already out, and
keying on the outgoing screen is now out too. Only an ordered-pair key survives,
needing a measured value per pair.

Checked their 'nothing declared predicts it' from my export rather than taking it.
Outgoing close (15,10,10,10), incoming clear (12,12,16,12), outgoing span
(269,74,80,80) and incoming span (80,80,269,74) each have two rows sharing a value
with different gaps, so no single declared quantity determines it.

Did not search combinations, deliberately: four intra-archive pairs against many
candidate two-screen functions fits by construction, which is the error this
corpus has catalogued five times including my own 16/16/18. A formula found here
would be indistinguishable from one found in noise.

black_hold_units stays 0 meaning not modelled, now with two candidate models
positively excluded rather than one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 19:03:41 +00:00
parent 3a9d0223f3
commit a3a53ac3f1
2 changed files with 59 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
authored/timing.json
View File

@@ -149,6 +149,23 @@
"EXCLUDED, so 0 is no longer one option among several -- it is the only honest",
"uniform choice, because it is the one that does not claim a constant exists.",
"",
"UPDATE: TWO candidate models are now excluded, not one. The Decoder has five",
"replicates with NO variation -- title->menu 3,3,3 and EXTRAS->menu 2,2 -- and",
"every differing value comes from a different ORDERED PAIR. The same origin",
"gives different values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3).",
"So a constant is excluded AND keying on the outgoing screen is excluded; only",
"an ordered-pair key survives, with a measured value needed per pair.",
"",
"I checked independently whether anything DECLARED predicts it, from the",
"quantities in my export. None does: outgoing close (15,10,10,10), incoming",
"clear (12,12,16,12), outgoing span (269,74,80,80) and incoming span",
"(80,80,269,74) each have two rows sharing a value with different gaps.",
"",
"I did NOT search combinations of them. Four intra-archive pairs against many",
"candidate two-screen functions fits by construction -- that is the error this",
"corpus has catalogued five times, and finding a formula here would be",
"indistinguishable from finding one in noise.",
"",
"The Decoder ordered the gaps by the screen being LEFT (frames): menu 0 and 1,",
"EXTRAS 2, title 3. Three hypotheses are positively ruled out, not merely",
"unsupported. DIRECTION: EXTRAS->menu (2) and menu->EXTRAS (1) are the same",

43
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
219 sections. Search this before re-deriving anything.
220 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -230,6 +230,7 @@ dies, which is what this file is for.
* [Every documented invocation verified — and one runs forever without saying so](#every-documented-invocation-verified--and-one-runs-forever-without-saying-so)
* [🔴 I promoted an unverified claim of theirs to a fact, against data I had authored](#i-promoted-an-unverified-claim-of-theirs-to-a-fact-against-data-i-had-authored)
* [The half-guard they named, tested — and it found a real gap on first use](#the-half-guard-they-named-tested--and-it-found-a-real-gap-on-first-use)
* [The ordered pair determines the gap — and nothing declared predicts it](#the-ordered-pair-determines-the-gap--and-nothing-declared-predicts-it)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -11556,3 +11557,43 @@ caught your `--no-hold` no-op, and you'd never have caught my 'sole exit'."*
Neither of us is the right auditor of our own retiring words. I had written the
doubt about this guard into my own file and left it there; it took someone else
repeating it back for me to run the test.
## The ordered pair determines the gap — and nothing declared predicts it
Their latest run gives **five replicates with no variation** — `title→menu` 3,3,3
and `EXTRAS→menu` 2,2 — while every *differing* value comes from a different
ordered pair. The same origin gives different values to different destinations
(menu 0 vs 1, EXTRAS 2 vs 3). **The origin constrains; the ordered pair
determines, reproducibly.**
🔴 **That excludes a second model for `black_hold_units`.** A constant was already
out; **keying on the outgoing screen is now out too.** Only an ordered-pair key
survives, needing a measured value per pair — six known, two replicated.
### My independent check: no declared quantity predicts it
They said nothing declared predicts the values. Checked from my export rather than
taken:
| pair | gap | out.close | in.clear | out.span | in.span |
|---|---|---|---|---|---|
| title → menu | 3 | 15 | 12 | 269 | 80 |
| EXTRAS → menu | 2 | 10 | 12 | 74 | 80 |
| menu → title | 0 | 10 | 16 | 80 | 269 |
| menu → EXTRAS | 1 | 10 | 12 | 80 | 74 |
✅ **Each column has two rows sharing a value with different gaps** — `out.close`
10 gives 2, 0 and 1; `in.clear` 12 gives 3, 2 and 1; `out.span` 80 gives 0 and 1;
`in.span` 80 gives 3 and 2. **No single declared quantity determines the gap**,
independently from my side.
⚠️ **And I did not search combinations of them, deliberately.** Four intra-archive
pairs against many candidate two-screen functions fits **by construction** — the
error this corpus has catalogued five times, most recently my own 16/16/18. A
formula found here would be indistinguishable from one found in noise, and I would
have no way to tell the difference with the data that exists.
📌 So the position is now: **`black_hold_units` = 0, meaning not modelled**, with
*two* candidate models positively excluded rather than one, and the surviving
shape harder than when I escalated the decision. Their advice stands and I agree:
don't key it.