Ka0s Party Frame Enhanced

tag 794a934984dd89f14193130f8689977340d755b6 1.0.1-release
Author:    Tushar Saxena <tushar.saxena@gmail.com>
Date:    Fri Sep 18 12:33:11 2026 +0530

commit ea72210ac51df3f6d3130d80ddbdd02184bc37d0
Author: Tushar Saxena <tushar.saxena@gmail.com>
Date:   Fri Sep 18 12:17:35 2026 +0530

    Party Frame Enhanced 1.0.1

    THE RELEASE GATE passed on a clean tree at e4d7f41 before anything was edited:
    docs/automated-tests/20260918-121606/ (--release 1.0.1) is green on all five
    conditions. Lint 0/0 over 70 files, 227/227 tests with none skipped, nine perf
    scenarios measured, lizard run, and max CCN 14. Nothing sits at the ceiling.

    It is the second 1.0.1 gate run. The first, on b6eb1dd, passed too, but it
    left tick and applyAttached at exactly 15. e4d7f41 split both before the
    release was committed, so the gate was taken again on the code that ships.
    The first bundle was never committed.

    THE VERSION moves 1.0.0 -> 1.0.1 in the TOC and NS.version, and in the three
    test assertions that pin the version string. The smoke steps that print it
    (7, 22), the example --release commands in testing.md and
    automated-tests/README.md, and the build-status and scope lines follow.

    THE README. A 1.0.1 Version History row for the fix: a party member who joins
    already targeting something no longer gets a blank red target frame.

    Not tagged.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01KHAvXxAQktWcUeGFGN2q5A

commit e4d7f41f4ca9a8f792ea281874a2820f3b531d12
Author: Tushar Saxena <tushar.saxena@gmail.com>
Date:   Fri Sep 18 12:16:03 2026 +0530

    The target ticker and the attached placement step back under CCN 15

    The 1.0.1 release run left two functions at exactly 15, the release ceiling,
    where one more branch in either would fail the gate.

    tick (modules/TargetFrames.lua) was taken there by the unresolved-target fix.
    One shown button's share of a pass now lives in tickButton: a pending button
    repainted whole, otherwise its health. It answers whether the button is still
    pending. tick keeps the loop and the decision to stop. 15 -> 11, plus
    tickButton at 5.

    applyAttached (modules/Anchor.lua) gets the split 20260918-110125's analysis
    described. placementOf returns the point, relative point, offsets and match
    width, with the shipped-default fallback, and the comment explaining that
    fallback moves with it. 15 -> 9, plus placementOf at 7.

    Behavior is unchanged: 227/227, lint 0/0, and the target ticker's perf
    scenarios hold their API and byte counts.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01KHAvXxAQktWcUeGFGN2q5A

commit b6eb1dddf9dd6c07ec3a8c7b9d13f7fd39bc10c2
Author: Tushar Saxena <tushar.saxena@gmail.com>
Date:   Fri Sep 18 12:08:05 2026 +0530

    A new member's target frame fills in instead of staying blank and red

    THE BUG. Someone joining the party while targeting a friendly NPC got a
    target frame with no name and a red bar, and it stayed that way until they
    changed target. The layout repaint lands before the client has streamed the
    new member's target: UnitName is nil and the unknown reaction reads as
    hostile. Nothing came along afterwards. UNIT_TARGET waits for the owner to
    change target, and the UNIT_NAME_UPDATE registration from the late-name fix
    never fires, because the client does not dispatch unit events for a
    compound token like party2target.

    THE FIX. paintAll marks a button pending when its name comes back as a plain
    nil. A secret name counts as resolved, and it is tested for secrecy before
    any comparison. The target ticker repaints a pending button whole on each
    tick until it resolves. It also keeps running for a pending button with
    Update health off, and stops once nothing is left to do.

    REMOVED: the UNIT_NAME_UPDATE registration and its two tests. The tests
    only passed because they fired the event by hand.

    Two new cases cover the fix: a frame that arrives unresolved and resolves on
    a tick, and the ticker running with health updates off only until the name
    arrives. Both are red against the old module.

    DOCS: ARCHITECTURE's event row, data-flow, settings-panel (Update health),
    module-map, midnight-quirks (the compound-token section) and a new smoke
    step 34a. README: the screenshot captions lose their em dashes.

    Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01KHAvXxAQktWcUeGFGN2q5A