The v2.8.0 release adds RGXTimers, a frame-based countdown/progress bar module that replaces LibCandyBar-3.0 for consumer addons.

RGX-Framework publishes one product: the WoW addon framework. Node tooling, schemas, documentation, references, and future Studio code never belong in the World of Warcraft addon archive.

v2.8.0 publishes exactly two GitHub assets:

The v2.8.0 ZIP is expected to contain one RGX-Framework/ root and exactly 113 runtime files. Verify the asset and digest after publishing with GitHub CLI:

gh release view v2.8.0 --repo RGXMods/RGX-Framework --json assets \
  --jq '.assets[] | select(.name == "RGX-Framework-v2.8.0.zip") | .digest'

CurseForge is the currently configured addon service. Wago is configured with the suite connection X-Wago-ID: E6gz1DN10, carried in every flavor TOC so Wago can identify each per-flavor package; the existing connection and ID must be preserved exactly.

All flavor TOCs ship together and declare the same framework version:

The base TOC declares 120105, 16001, 11509 together (single-TOC style), so Forever loads without a _Mainline.toc that would double-load there.

Forever reports WOW_PROJECT_CAMELOT (WOW_PROJECT_ID 18) at Interface 16001 and is classed as mainline: RGX.wowVersion is "forever" while capability detection stays mainline-shaped. Identity consequences the framework owns centrally:

• UnitName("player") returns firstName, surname — the full name is unique across rulesets, so database character keys use it instead of "Name - Realm". Existing Forever char-scoped data re-keys on update.
• GetRealmName() is advisory (e.g. "Classic Beta PvP") and must not key durable data — never use it for identity on Forever.

The player archive has one top-level RGX-Framework/ directory and only:

RGX-Framework.toc
RGX-Framework_Vanilla.toc
RGX-Framework_TBC.toc
RGX-Framework_Wrath.toc
RGX-Framework_Cata.toc
RGX-Framework_Mists.toc
RGX-Framework.xml
LICENSE.txt
core/**/*.lua
game/**/*.lua
libraries/**/*.lua
media/*.tga
media/fonts/*.ttf
media/fonts/*.otf
media/fonts/README.md

It rejects JavaScript, TypeScript, JSON, Rust, Tauri, node_modules, tools/, schemas/, docs/, .reference/, and other non-runtime paths. Every Lua/XML load reference must exist in the inspected ZIP.

Extract the archive so the game sees:

World of Warcraft/<client>/Interface/AddOns/RGX-Framework/RGX-Framework.toc

Consumer addons declare ## RequiredDeps: RGX-Framework. Do not copy source repository folders such as tools/, schemas/, or docs/ into AddOns.

Schemas, documentation, reference tools, and the temporary MCP conformance fixture remain available only in the source repository. The public runtime Lua API ships inside the framework addon. Shared contract and authoring logic remain framework-owned; future Studio-specific services, adapters, and editor application distribution are separate from this player archive. MCP is optional tooling, not a runtime dependency. See RGX-MCP for the layer comparison.

The shared GitLab include explicitly selects addon:validate for merge-request pipelines as well as normal branch/tag pipelines. Contract and mirror jobs keep their mandatory validation dependency; mirror jobs never run for MRs. The source-rule regression check covers Framework and consuming-addon repositories: npm --prefix tools/ci run gitlab-ci-check. Actual MR pipeline/job success is also required; a valid branch pipeline or lint result alone is not MR evidence.

From a framework source checkout:

cd tools/ci
npm ci
npm run package-check
npm run package-build

Generated files are written to artifacts/:

RGX-Framework-X.Y.Z.zip
RGX-Framework-X.Y.Z.manifest.json
RGX-Framework-X.Y.Z.sha256

These are local/CI verification outputs, not GitHub release assets or a second product. The builder fixes ZIP timestamps, entry order, permissions, and compression settings. The manifest records every runtime source digest, source revision, and sourceDirty state. artifacts/ and .release/ are generated and ignored by Git.

GitHub is a distribution mirror, never a development source (issue #63). The shared mirror job copies exactly one allowlisted ref per pipeline:

• the protected default branch (main)
• protected release tags matching v*

Refs are pushed individually, without wildcard refspecs, without --prune, and without forcing, so development branches, draft refs, and refs that exist only downstream are never swept or overwritten. A moved tag or a branch that diverged from GitLab fails the mirror job visibly for operator review instead of rewriting GitHub history. Removing refs that earlier wildcard mirrors already pushed downstream is a separate, explicitly reviewed cleanup. Consuming addon repositories inherit the same routing through the shared include.

The versioned contract bundle pins the contract surface (schema, declarative API docs, derived declarative API catalog, module API catalog, conformance vectors) separately from the player archive so MCP, Studio, and other authoring tools can pin an exact revision without copying RGX semantics.

cd tools/ci
npm ci
npm run contract-bundle-check   # verify only
npm run contract-bundle-build   # verify + emit to artifacts/

Generated files:

RGX-Framework-X.Y.Z-contract.zip
RGX-Framework-X.Y.Z-contract.manifest.json
RGX-Framework-X.Y.Z-contract.sha256

Bundle metadata (format version, framework version, flavor, source revision, per-file SHA-256 digests) is generated from RGX-Framework.toc and git state, never hand-repeated. Rebuilding the same revision produces byte-identical outputs. Consumers must check formatVersion and reject unknown versions.

The contract:bundle CI job (.gitlab/ci/addon.yml) builds the bundle, verifies every manifest hash, and confirms a second build is byte-identical on the default branch, tags, and merge requests.

docs/curse_description.html is the CurseForge description source; docs/wago_description.md is the Wago description source. The release workflow packages and uploads the addon but does not update service-page HTML. Description changes must be applied to the configured service separately and verified against this file; the GitHub Wiki is generated automatically from the Markdown pages listed in tools/wiki/manifest.json. Service-page Markdown is explicitly listed as sourceOnly in that manifest so it remains maintained source without generating a duplicate Wiki page.