Repository navigation
Confirm on a real client that build-time UI Transforms render correctly #304
Description
Expected. A Package should describe small build-time edits to the Operator's own baseline FrameXML, GlueXML and TOC files, with overlapping or ambiguous edits failing loudly and no extracted Blizzard bytes ever committed to the repo.
Actual (at 87109e3c). Built and unit-tested. compose_ui_transforms (importer/src/pack_client.rs#L287) reads baseline files live out of the Operator's own client archives through open_ui_baseline_chain (importer/src/dbc.rs#L129), never writes them back into the repo, and the generated output records only the baseline and transform-source hashes (importer/src/ui_transform.rs#L214). Two disjoint edits compose deterministically; overlapping edits, ambiguous anchors, and a whole-file override mixed with a transform on the same path all fail and name the Packages and path involved. cargo test -p lyracore-importer passes (332 tests). What has not run is the generated FrameXML and GlueXML against a real, unmodified build 5875 client.
How to check. Author a Package with a UI Transform against a real client install, run lyracore client sync, and load the result in-game: confirm the transformed frame behaves and renders correctly, and that the rest of the stock UI is unaffected.
Done when. The client-side result is recorded here, with the client build and the commit.
Activity
Mathih13 commentedon Sep 1, 2026
Split decision (maintainer, 2026-09-01): the build-time transform engine and tracer are agent work — the existing brief above is the contract. Only the final FrameXML/GlueXML behavior check needs a human on a real 1.12.1 client, so this moves to ready-for-agent and the needs-live-eyeball label holds it open until that confirmation. One boundary from #303's settled decisions applies here: transform outputs are baseline-derived and therefore never enter a distributable artifact — they exist only in the operator's own client via
client sync, andclient packrefuses them by provenance.Mathih13 commentedon Sep 2, 2026
Verified the agent half against core PR #392 (
feat(packages): client pack artifact and UI Transforms, merged at f186f1b,importer/src/ui_transform.rsandimporter/src/pack_client.rs). This does not close the real-client check — see below.compose_ui_transformsreads the baseline live out of the operator's own client archives (dbc::open_ui_baseline_chain), never writes it back into the repo, and the generated header records only its hash. What is NOT verified here is running this against a real, unmodified 1.12.1 client — that needs the live-eyeball check below.ui_transform::tests::compose_two_disjoint_edits_are_order_independent.compose_refuses_overlapping_edits_naming_both_packages,compose_refuses_an_ambiguous_anchor_naming_package_and_path,compose_refuses_identical_anchors_as_an_overlap, andpack_client::tests::an_override_of_a_transformed_path_refuses_and_writes_nothing(whole-file override vs. transform, names both Packages and the path).ui_transform::record_headerwrites bothbaseline=<hash>andtransforms=<hash>into the generated file's own comment syntax. Proven byrecord_header_uses_each_files_own_comment_syntax,transforms_hash_changes_when_an_edit_changes,transforms_hash_is_independent_of_input_order.ui_transform.rsorpack_client.rstouches the client executable; the feature is a build-time text transform against archived Lua/XML/TOC only.Ran
cargo test -p lyracore-importerin the core checkout: 332 passed, 0 failed, 2 ignored (both live-client targets, unrelated to this issue).This closes out the agent-verifiable half: engine, conflict detection, hash recording, and the absence of executable patching. The
needs-live-eyeballlabel and the FrameXML/GlueXML-on-a-real-client box are exactly right to keep this open — leaving it open, not closing.Verified by Claude (model claude-sonnet-5) via Claude Code subagent.
[-]packages client: author native UI changes from baseline Lua and XML[/-][+]Confirm on a real client that build-time UI Transforms render correctly[/+]