From b1eaab50d9624ce8456996c455aae1cb64687545 Mon Sep 17 00:00:00 2001 From: Erik Date: Thu, 3 Sep 2026 12:35:28 +0200 Subject: [PATCH] =?UTF-8?q?docs(issues):=20#458=20=E2=80=94=20not=20the=20?= =?UTF-8?q?degrade=20level;=20three=20divergences=20at=20the=20doorway=20(?= =?UTF-8?q?one=20far=20block,=20two=20pre-existing=20missing=20look-in=20f?= =?UTF-8?q?loods)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Fable 5.1 --- docs/ISSUES.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/ISSUES.md b/docs/ISSUES.md index 3ae572ae..eb8aa142 100644 --- a/docs/ISSUES.md +++ b/docs/ISSUES.md @@ -55,6 +55,19 @@ three kit poses (terrace-edge, cathedral-arrival, foundry-deep) reproduce exactl `WalkTraceConformanceTests.Oh_doorway_still_first_frame_diff` carries the row tagged `Status=KnownFailure` with the position documented. +**Lead experiment (2026-09-03):** with `DegradeMultiplier = 0f` (the FW0 sibling's +cdb-depressed value) the row diverges at the SAME token 165 — the degrade level is NOT the +cause. A token diff of the full frame shows THREE divergences, not one: (1) token 165: +acdream inserts `LC/SC a9c90001` (block `a9c9`, ring 21 straight north of the viewer's +`a9b4`; retail admits `a8c9` and `95c6` around it but not `a9c9` — a `draw_check_blocks` +block test difference, likely the block's MinZ/MaxZ clip heights against the exit-view +edge planes); (2) retail tokens 1093–1107: two look-in floods acdream never enters — +`DC:ov=0:a9b40103,a9b40100` (+EC/OC) and `DC:ov=0:a9b40100` (+EC/OC); (3) retail tokens +1112–1115: a third look-in `DC:ov=0:a9b40124` (+EC/OC). (2)/(3) are the PRE-EXISTING FW1 +'near-win' look-in gate state at this pose (`WalkLookInGateSweepTests` is still skipped; +the FW0 `Doorway_still_first_frame_diff` was a diff printer, never an exact pin), now +exposed by the eight-kind comparison. Signature lengths: retail 1185 tokens, acdream 1170. + **Degrade note (2026-09-03 review):** the FW0 sibling row for the SAME pose pins `RetailFrameWalk.DegradeMultiplier = 0f` because that capture ran under cdb load with `Render::deg_mul` depressed; the OH doorway capture also ran under cdb, so check the