JonKazama-Hellion
8e38e3e805
Block D of v1.12.0. The line between the two is the whole job, and I got it wrong once on the way: six cache fields on Tab looked dead because nothing writes them, and nothing writes them because AutoTellTabTint and TabTintCache went out with the chat window incf4705e. Deleting the fields would have cemented a loss instead of recording a decision. So they are back, and the sidebar uses them again: an auto-tell tab is tinted and glyphed from its partner, twelve colours against seven icons. Four open tells are no longer four identical envelopes in one colour. Their own header promised the same partner keeps its colour "across sessions" while hashing with string.GetHashCode, which .NET salts per process -- every game start reshuffled every tab. FNV-1a now, with a lowbias32 finalizer that is not decoration: without it a probe over 144 similar keys reached six of the twelve colours, because the caller takes the low bits with a modulo and FNV leaves those correlated. Three pinned values guard it, which is also the only assertion that can catch a regression to a salted hash. The same question, asked of the three hide conditions this block had quietly orphaned: HideDuringCutscenes, HideInBattle, HideWhenNotLoggedIn all had readers in v1.5.6 and lost them in the same commit. Two of them are states rather than conditions -- a cutscene the user dismissed stays dismissed until it ends, and combat must not seize a chat that is already hidden for another reason -- so they come back as a small state machine with eight pinned transitions, and three toggles whose labels were already translated in all 25 languages. Actually deleted, with a reader search each time: - Six per-tab hide fields. Their reader was the pop-out window and it stopped consulting them incf4705e. Per-tab was the wrong unit anyway: "hide during cutscenes" is a statement about the screen. - Tab.ChatCodes, whose migration the v16 schema gate had already made unreachable. - InactivityHideTimeout and InactivityHideActiveDuringBattle, MaxLinesToRender which had stopped bounding anything, and the 155 lines of Configuration.UpdateFrom with no caller at all. Config version 25, at all three places that carry it. No migration step: the gate only refuses anything under 16 and Json.NET drops keys it does not know, so the deleted fields simply stop being written. One thing a review pass caught that matters more than any of the above: the clone parity guard had gone hollow. It compares collections by count, ChatCodes was the only collection the probe seeded, and removing it left the guard comparing zero against zero. Verified by making Tab.Clone discard both remaining collections and watching every assertion stay green. The probe seeds them now, and the same sabotage fails as it should.
HellionChat SelfTest Standard
These steps run in-game via /xlperf. They are HellionChat's real test layer:
Dalamud-coupled classes cannot be instantiated in an xUnit AppDomain, so the
honest verification path is the running plugin, not a headless harness.
The render-path rule (binding for every step)
A SelfTest exists to catch a broken runtime path. To do that it MUST:
- ENTRY = the real runtime entry the game calls per frame or on the real
action —
HonorificHeader.Draw,ChunkRenderer.DrawChunks,InputBar.TrySend,Sidebar.Draw,MessageList.Draw,Lender<PayloadHandler>.Borrow(). NEVER a helper only the test calls. - ASSERT observable state produced through that entry — a rendered or suppressed slot, a set flag, a held vs. sent message. Do NOT re-implement the helper's logic inside the test and assert against your own copy.
- Wire first. Where the real path does not yet call the correct helper, wiring it is part of the restoration work; the SelfTest verifies only after.
Reviewer trick (run before trusting any step)
For every helper a step calls:
grep -rn '<Helper>' HellionChat/ | grep -v SelfTests | grep -v Tests
Zero non-test callers = false-green suspect. The step is passing on dead code.
The hard gate
Green steps + clean build + clean csharpier are NOT sufficient. In-game smoke
(Linux/Wine, via /xlperf) is the true gate. Where headless cannot honestly
verify (scroll state, real send, atlas rebuild, warm object pools), mark the
step explicitly as smoke-only instead of faking a headless pass.
Anti-pattern of record
HonorificService.ShouldRenderSlot once had zero production callers and was
green only because the test called it directly — a test passing on a path the
game never runs. v1.8.7 retired it: the gate is now wired into the real
HonorificHeader.Draw and asserted through it via
HonorificHeader.LastTitleRendered (see HonorificHeaderRenderStep). Kept here
as the canonical example of the failure this standard prevents.
Step classification
The current real-path / helper-only / mixed classification of every registered
step (with false-green suspects flagged) lives in the Obsidian vault:
Projekte/FFXIV/Hellion Chat/Audits/HellionChat SelfTest-Klassifikation 2026-05-29.md.