# -*- coding: utf-8 -*-
"""Night 7 (2026-07-30) field-report housekeeping: closes + notes."""
import gitea

HDR = ("**Field report, playtest night 7 (2026-07-30, build 4.11.659 (e91d447))** -- "
       "SAURON, RajelAran, Oracle (new tester, original-pod experience).\n\n")

# ---------------------------------------------------------------- CLOSE #81
gitea.close(81, HDR +
 "**Closing: the respawn cycle was clean for the whole session on three machines.**\n\n"
 "Asked directly and answered repeatedly during play:\n"
 "- operator: \"how about death/respawn? clean so far?\" -- SAURON: \"yes clean so far\"\n"
 "- Oracle: \"death repsawn OK so far\"\n"
 "- No ghost/zombie respawn was reported by anyone across a ~2h session with many deaths "
 "and respawns, against the ~1-in-3 rate that produced this report.\n\n"
 "The fix that landed for this was the removal of the `deathPending` one-way latch and "
 "the respawn-record path rework (shipped in 4.11.659; bench-verified beforehand at 4 "
 "nodes / 56 overlapping death cycles with zero strands).\n\n"
 "**One wreck sighting DID occur tonight, but it is not this bug:** SAURON's Hellbringer "
 "rendered as wreckage on peers while alive and fighting, triggered by a mech-to-mech "
 "**collision** -- no death, no respawn. Filed as **#94**. If that turns out to share a "
 "root with this one, reopen.\n\n"
 "Related: #45 (the K/D replication half of the same work), #94 (collision-triggered "
 "wreck graphic).")

# ---------------------------------------------------------------- CLOSE #46
gitea.close(46, HDR +
 "**Closing: an unpurged ammo bay fire is now lethal.** Oracle, mid-session:\n"
 "> ammo bay fire and alarm seems OK\n"
 "> and I go boom when I failed to eject\n\n"
 "That is exactly the behaviour this issue said was missing -- Cyd and RajelAran each sat "
 "through two bay fires without dying on 4.11.524. A fresh tester now gets killed by one "
 "he failed to purge, and separately reports the bay-fire alarm firing.\n\n"
 "**Still open in the neighbourhood:** #47 -- the JAM annunciator. Oracle observed an "
 "ammo jam on the Avatar's AFC50 with no flashing red indicator (commented there). The "
 "bay-fire alarm half of #47 now looks satisfied; the jam half does not.\n\n"
 "Related: #28 (vital-subsystem-crit death path), #47 (jam annunciation).")

# ---------------------------------------------------------------- CLOSE #78
gitea.close(78,
 "**ANSWERED: yes -- Tesla 4.10 has a limping ('gimp') mech mode, and it is reconstructed "
 "and live as of build 4.11.659.**\n\n"
 "Settled from the binary rather than from argument, as this issue asked. The 4.10 code "
 "carries a complete gimp gait layer, not a hint of one:\n"
 "- A dedicated body-animation driver for the damaged gait (`AdvanceBodyAnimationGimp`) "
 "alongside the healthy one.\n"
 "- Dedicated animation states: the `gg` and `gs` gimp cycles (24/25 and 26/27) plus "
 "GimpToStand transitions (22/23) -- a whole state family that exists for nothing else.\n"
 "- Its own leg driver path, distinct from the healthy leg channel.\n\n"
 "**So both parties were partly right, along the lines this issue predicted.** A limp "
 "mode is authentically in 4.10 (VGL Lynx's videos are 4.x behaviour, not Firestorm). "
 "What SAURON is describing -- leg gone = mech gone -- is the destruction threshold, not "
 "evidence against a damaged-leg limp.\n\n"
 "**Field-confirmed 2026-07-30** on 4.11.659, from every viewpoint: Oracle -- \"gimp is "
 "OK\"; operator saw the limp from every mech's POV in a 4-node arena test. Peer-side "
 "correctness took two more fixes after the gait itself (#82).\n\n"
 "Full write-up: `context/locomotion.md` (gimp gait + the peer body-channel trn-lock).\n\n"
 "Related: #82 (peers saw the limper skating -- fixed), #75 (myomer damage -> speed, the "
 "other consumer of the same mover feed, still blocked on the WAVE 6 cutover).")

# ---------------------------------------------------------------- NOTE #82
gitea.comment(82, HDR +
 "**Field-confirmed fixed.** Oracle: \"gimp is OK\". The operator additionally confirmed "
 "the limp reads correctly from every mech's POV in a 4-node arena test before the build "
 "shipped.\n\n"
 "Note for anyone reading this later: a mech was seen **skating** tonight, but with a "
 "different trigger -- RajelAran's Sunder started skating immediately after being rammed "
 "and recovered when it stopped. That is the older #52 ski (gait desync), not this limp "
 "bug; commented there.")

# ---------------------------------------------------------------- NOTE #52
gitea.comment(52, HDR +
 "**Still live in 4.11.659 -- and tonight it came with a sharp, reproducible trigger: a "
 "mech-to-mech COLLISION.**\n\n"
 "Oracle's written notes (item 8):\n"
 "> When the two mechs initially collided, Sunder started skating and resumed normal "
 "animation after coming to a stop.\n\n"
 "RajelAran, live, immediately after the same event: \"I started skating right after "
 "that\".\n\n"
 "That matches this issue's original signature exactly -- slides without walking, "
 "self-heals when the subject stops and the gait state machine re-enters -- but the "
 "earlier reports had no known trigger. A collision gives us one to drive on a bench.\n\n"
 "**This is NOT #82.** #82 was the peer body-channel trn-lock (a limping mech shown "
 "gliding with turn-steps); that is fixed and confirmed tonight. This is the older ski, "
 "on an undamaged mech, caused by an impact.\n\n"
 "**Repro lead:** two nodes, drive one into the other under `BT_AUTODRIVE`, observe from "
 "the third. Build 659 changed collision handling (`9c83a46` self-damage / `14ff351` the "
 "collision divert), so check whether the impact path now interrupts the gait feed -- and "
 "whether the same impact is what put the OTHER mech into the wreck graphic (**#94**, "
 "same collision, same second).\n\n"
 "**RajelAran has video of this event** -- worth collecting before it ages out.")

# ---------------------------------------------------------------- NOTE #47
gitea.comment(47, HDR +
 "**Half of this looks satisfied, half does not -- narrowing it.**\n\n"
 "**Bay-fire alarm: appears OK now.** Oracle: \"ammo bay fire and alarm seems OK / and I "
 "go boom when I failed to eject\" (the lethality half closed #46).\n\n"
 "**Jam annunciation: still missing.** Oracle's written notes, item 10:\n"
 "> Possible, need to test further - Observed ammo jams on Avatar AFC50 but no flashing "
 "red indicator, weapon resumed working after clearing jam.\n\n"
 "So on a jam the ENG-page button still does not flash to draw the pilot's eye -- the "
 "original complaint from Cyd and RajelAran, unchanged.\n\n"
 "Two follow-ups for the next session:\n"
 "1. Confirm whether the **bay-fire icon** beside the ammo counter now appears (Oracle "
 "reported the alarm, not the icon).\n"
 "2. \"weapon resumed working after clearing jam\" is worth a look against #30 -- a jam is "
 "documented as mission-permanent per the binary (clears only on ResetToInitialState / "
 "respawn). Either the Avatar's AFC50 hit a different state than a true jam, or the jam "
 "clear is too lenient.")

# ---------------------------------------------------------------- NOTE #19
gitea.comment(19, HDR +
 "**Partial positive evidence -- seek select looks functional in 4.11.659, but not yet a "
 "clean confirm.**\n\n"
 "Oracle, describing the myomers: \"definitely not generating heat on myomers **I have "
 "them at seek 4**\" -- i.e. he set and held a seek level. He also reported the engineering "
 "side responding: \"loop prioritization is working too / I can see the response of the "
 "loops and the sub-systems\".\n\n"
 "**Not enough to close**, because this issue is specifically about **ADV control mode at "
 "expert experience**, and we do not know Oracle's control mode / experience for that "
 "round -- and #2 (the egg `experience` field is parsed but never applied, so everyone "
 "runs VETERAN) may still be masking the expert gate either way.\n\n"
 "**To close this:** one round at expert + ADV, step seek on BOTH myomers and a weapon "
 "emitter, and confirm the lamp/step moves. Ask Oracle -- he reads the eng page closely.\n\n"
 "Related: #85 (myomers produce no heat at seek 4 -- the seek setting is reaching the "
 "display but may not be reaching the heat model), #2.")

# ---------------------------------------------------------------- NOTE #30
gitea.comment(30, HDR +
 "**The enforcement half of this is now its own issue: #86.**\n\n"
 "All three testers confirmed that a **destroyed** weapon keeps firing and scoring -- limb "
 "visibly gone, X drawn on the MFD, launcher still launching, and peers see the phantom "
 "shots. Oracle: \"When limbs or weapons (missile launchers) are visibly destroyed the "
 "weapons continue to function and score damage (score increases)\"; RajelAran: "
 "\"destroyed weapons do seem to cycle still\".\n\n"
 "So the split is:\n"
 "- **this issue (#30)** -- the weaponAlarm level-5/7 *presentation* (a dead launcher "
 "looks identical to a healthy idle one)\n"
 "- **#86** -- the *enforcement* (level 7 / mount destroyed must veto fire, recharge and "
 "ammo draw)\n\n"
 "Worth fixing together: the level-7 state is evidently being reached (the X draws), so "
 "both halves are consumers of the same state.\n\n"
 "Also from tonight, relevant to the jam machinery here: an Avatar AFC50 jam **cleared "
 "mid-round** without a respawn (Oracle, notes item 10), which contradicts the "
 "mission-permanent jam documented above. See #47.")

# ---------------------------------------------------------------- NOTE #45
gitea.comment(45, HDR +
 "**Status check -- the fix shipped, but nobody explicitly re-verified tonight, so leaving "
 "this open.**\n\n"
 "The kill-attribution / death-tally replication work shipped in 4.11.659 alongside the "
 "#81 respawn fix (bench-verified: 4 nodes, 56 overlapping death cycles, DEATHS tallies "
 "matching across machines).\n\n"
 "From tonight's three-player session: **no K/D complaint from anyone**, against an "
 "original report where three players raised it independently within one night. The only "
 "score-related remark was Oracle noting his score DID increase when firing his "
 "(destroyed) weapons -- see #86.\n\n"
 "Silence is weak evidence. **To close:** one round where two players cross-check the "
 "KILLS/DEATHS rows against what actually happened, on both machines."
 )

# ---------------------------------------------------------------- NOTE #80
gitea.comment(80, HDR +
 "**Correction to a baseline assumption in this issue.**\n\n"
 "The body states, as the known-good baseline: \"the paper doll (Damage view) shows "
 "per-ZONE armor tint\", and builds the three-layer analysis on top of that being "
 "already-working.\n\n"
 "Three testers report otherwise tonight. SAURON: \"no damage displaying on enemy mech "
 "panels that have been damaged / looks 100% fresh on all panels\". Oracle: \"I'm not "
 "seeing darkening panels due to damage\" and \"also not seeing panels darken from damage "
 "/ even when red/flashing red\".\n\n"
 "Filed as **#87**. Verify which is true before relying on the armor-tint layer here -- if "
 "the doll is NOT tinting, then \"doll shows damage, crit panel shows nothing\" is not the "
 "expected state and part of this issue's framing needs rewriting.")

# ---------------------------------------------------------------- NOTE #75
gitea.comment(75, HDR +
 "Adjacent report from a new tester: **the myomers also produce no HEAT** -- \"definitely "
 "not generating heat on myomers I have them at seek 4 / they remain ice cold\" (Oracle, "
 "confirmed against the engineering panel). Filed as **#85**.\n\n"
 "Same class as this issue: the Myomers subsystem is wired to the display but not to the "
 "systems that should consume it. This one is speed (blocked on the WAVE 6 mover "
 "cutover); #85 is heat, which should NOT be blocked on WAVE 6 -- the heat generation term "
 "feeds the heat family, not the mover roster, so it can likely be fixed independently.")