WoW — TrinityCore master

Field	Value
Internal ID	wow-trinitycore-master
Upstream	TrinityCore/TrinityCore
Preserved mirror	MMO-Preservation/preservation-trinitycore, full history present; local recovery bundle pending
Branch	master — always pin a full commit
Observed revision	fd9c486839d862dbb0a64ae1c42fc98cf57988c7 on 2026-07-16; not a compatibility claim
Manager module	gsm-mod-trinitycore (Master)
Support status	Supported moving target
Required client	Retail client build matching the pinned server revision
Database	MariaDB; auth, characters, world, and hotfixes databases
Runtime	bnetserver and worldserver in tmux
Default source	/opt/gsm/servers/trinitycore-master/src
Default install	/opt/gsm/servers/trinitycore-master/server
Preservation level	P0 identified; no retained known-good client pair
Owner	Ryuu
Last documentation review	2026-07-16
Runtime verification	Not completed — #8

Preservation warning

master is a moving compatibility window, not a stable version. A preserved baseline must name a server commit, matching client build, database state, and extracted-data manifest. A note saying “current retail” is not recoverable.

Preserve together

• Complete upstream mirror and a dated bundle containing the pinned commit.
• Matching retail client snapshot metadata and patch/build evidence.
• Extracted maps/vmaps/mmaps/dbc or other required data with provenance.
• Auth, characters, world, and hotfixes database sources and migration state.
• Compiler/CMake/dependency versions, configuration, and any external modules.

Manager defaults

• CMake flags: -DTOOLS=1 -DSCRIPTS=dynamic
• Databases: tc_auth_master, tc_characters_master, tc_world_master, tc_hotfixes_master
• Tmux session: tc-master

Known constraints and risks

• Server/client compatibility can expire quickly as upstream and retail patch levels move.
• Client preservation and redistribution may have strict legal limits; keep metadata public and bytes restricted where required.
• Hotfixes and client-derived data are part of the compatibility contract.
• Rebuilding old commits may require toolchains or dependencies no longer packaged by modern distributions.
• Automatic updates must never replace the last known-good preserved baseline.

Baseline verification

1. Identify the exact retail build and server commit relationship from upstream evidence and a test.
2. Restore source, toolchain, database inputs, and client-derived data.
3. Build and initialize all four database schemas.
4. Start bnetserver and worldserver on an isolated network.
5. Use the exact matching client working copy to reach the agreed authentication/world milestone.
6. Record all version evidence, hashes, logs, and test result.

Open preservation work

• Create a time-series compatibility matrix of pinned commits and client builds.
• Preserve at least one complete known-good baseline before following newer retail versions.
• Capture toolchain and database update inputs for every retained baseline.
• Test rollback and offline restore.

Live tracking

• Known-good timeline and retained baseline: #8
• Mirror and bundle completion: #2