"""Night 13 housekeeping, part 2: comments + state changes on existing issues."""
import sys
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
import gitea

N13 = "Playtest night 13 (2026-08-06, build **4.11.817 (6fcff95+)**). "

# ---- #89 SPLASH: verified working, close -----------------------------------
gitea.close(89,
 N13 + "**VERIFIED WORKING -- closing.**\n\n"
 "SAURON: \"Splash damage looked good to me, **splash worked on mechs that died close**\". "
 "epilectrik: \"splash damage seems ok?\" -- no dissent from any tester.\n\n"
 "Oracle (original-pod player) also gave the era calibration that explains why splash reads as "
 "inconsistent rather than absent, and says our current behaviour matches it: \"sometimes you "
 "really catch it and sometimes not. It jogged my memory and I vividly recall that **being at "
 "different elevations on a hillside sometimes made a real hash of it** -- the effect could be much "
 "stronger or weaker\" ... \"it was **not** the mechwarrior 3/4 splash model\". SAURON: \"that seems "
 "correct to me\". So an unpredictable, elevation-sensitive splash is AUTHENTIC and should not be "
 "'fixed' into a clean radius falloff.\n\n"
 "One sub-case survives and is filed separately as **#144**: no splash on a panic/eject/suicide "
 "death (authenticity not yet established).")

# ---- #108 GHOST MECH: recurred ---------------------------------------------
gitea.comment(108,
 N13 + "**Still present, and it was the headline problem of the night.** epilectrik: \"**ghost mech "
 "biggest surprise**\" when reviewing regressions.\n\n"
 "No new detail beyond the existing repro in this issue -- recording the recurrence on 817 so the "
 "issue is not read as stale. Field logs for all four players (3 desktop + the pod cart) are staged "
 "in `scratchpad/night13/`, including the pod's matchlogs, which is the first time this issue has "
 "log coverage from a hardware seat as well. Analysis: `docs/GHOST_MECH_ANALYSIS.md`.")

# ---- #76 layout restore: superseded by #140 --------------------------------
gitea.comment(76,
 N13 + "**Overtaken by #140.** As of 817 the problem is no longer 'two windows fail to restore' -- "
 "`BT_GLASS_LAYOUT=save` now writes a `glass_layout.cfg` with the MFD and Secondary lines missing "
 "entirely (Plasma survives), so nothing restores at all. See #140 for the reports and the suspect "
 "commits.\n\n"
 "Fix #140 first; this issue may turn out to be a subset of it. Re-verify the two windows named "
 "here only once saving writes a complete file again.")

# ---- #123 searchlight / night visibility: era testimony --------------------
gitea.comment(123,
 N13 + "**Primary-source testimony on night visibility** from Oracle, who played the original pods "
 "at Lazer Park. This is directly about the deferred half of this issue (the fog swap), and it "
 "raises the priority of the fog over the beam:\n\n"
 "- \"some maps were not very dark, some were very dark\"\n"
 "- \"**the FOG was what really killed visibility**\"\n"
 "- \"I do recall basically stumbling into each other point blank at times and **having to use "
 "radar to navigate**\"\n"
 "- \"it could be very difficult to make a shot in those conditions\"\n"
 "- \"it was 90's tech there\"\n\n"
 "Takeaway for the implementation: the authentic night experience is driven by FOG DENSITY, not by "
 "ambient darkness, and it was severe enough that radar navigation was the norm. The "
 "`searchlightfog=` / `nosearchlightfog=` environment swap described above is therefore the "
 "high-value half of this work, not the projected beam.\n\n"
 "Operator note the same night: general night-visibility tuning is **deferred** until the correct "
 "behaviour is known -- epilectrik: \"the night time visibility I might defer for now since we "
 "don't really know the correct behavior ... I'll try to retrieve it from the binary again but "
 "might be a hardware side thing\". This comment is that missing calibration.")

# ---- #61 ThermalSight: point at the new visible-half issue -----------------
gitea.comment(61,
 N13 + "Cross-ref: the **visible** half of ThermalSight now has its own issue, **#145**, with "
 "primary-source description of what the IR mode actually looked like (a palette shift, explicitly "
 "NOT a heat image -- possibly a hardware test mode rather than a designed effect). Worth reading "
 "before anyone implements a presentation off the toggle this issue restored.")