open-wc/targets/roadmap/07-server-emulator-integration.md

SRV — TrinityCore and AzerothCore Integration

Цель

Поддержать server emulators как versioned backends: protocol-compatible runtime, безопасное редактирование данных и расширение mechanics через modules/scripts.

SRV-1. Environment model

• ServerEnvironment: family, core commit, DB revision, modules, config profile, endpoints и data artifact versions.
• Отдельные disposable, local-dev, shared-test, staging и production classes.
• Credentials/secrets вне Content Project.
• Capability discovery проверяет schema fingerprint и optional modules/tables/hooks.
• Unknown environment всегда read-only.

SRV-2. Database snapshots

• Read-only import world schema subsets с provenance/checksum.
• Auth/characters DB открываются только для нужных test/admin сценариев и никогда не становятся content source.
• Snapshot filters reproducible; personal/account data excluded.
• Canonical entities preserve supported fields and explicitly record unsupported/raw extras.
• Incremental snapshot возможен, но full consistency snapshot остаётся verification path.

SRV-3. Canonical mappings

• Creature/gameobject templates, models, spawns, addons, formations, movement, texts.
• Quests, relations, objectives, POI, conditions, gossip.
• Loot/reference loot, vendors, trainers, items, reputation.
• SmartAI, script names, waypoint/script tables.
• Instances, encounters, LFG, graveyards, teleports, game events, weather, transports.
• Каждая mapping имеет per-core capability table и round-trip tests.

SRV-4. Change sets and SQL

• Immutable change set: target fingerprint, preconditions, ordered operations, checksum.
• SQL generation соответствует conventions целевого core/profile.
• Custom SQL хранится в version control и compatible custom/module directory, не только применяется напрямую.
• Dry-run на disposable DB, targeted post-apply queries, core startup smoke.
• Idempotent migration или безопасное precondition failure.
• Rollback где возможен; destructive/irreversible operations требуют backup и явного подтверждения.

SRV-5. Scripts and modules

• DB/SmartAI для выразимых data-driven mechanics.
• C++ module/script skeleton для mechanics, требующих server hooks.
• AzerothCore modules namespaced config/SQL/hooks; core patch — только если hook принципиально отсутствует.
• TrinityCore adapter следует его текущим script/customization conventions отдельно.
• Build artifact включает source, config.dist, SQL, tests и compatibility manifest.
• Client extension capability договаривается явно; hidden custom opcode запрещён.

SRV-6. Server data artifacts

• DBC/maps/vmaps/mmaps versions связываются с ContentBundleManifest.
• Custom map требует согласованного client terrain, server maps/collision/pathfinding и DB Map/Area data.
• OpenWC navmesh не объявляется mmap до binary/query/live behavior compatibility.
• Asset/map IDs распределяются стабильно и проверяются на collision.
• Client/server package mismatch блокирует playtest с actionable diagnostic.

SRV-7. Protocol compatibility

• Baseline 3.3.5a build 12340 остаётся общим.
• Core-specific quirks описываются named capabilities и fixtures.
• Custom extensions используют versioned handshake/profile и fallback/rejection.
• Server authority одинаково соблюдается для обеих families.
• Compatibility matrix закрепляет tested commits, а не расплывчатое «поддерживает AzerothCore».

SRV-8. Test environments

• Docker/managed local environment для repeatable DB/core setup, где поддерживается.
• Seed accounts/characters synthetic и не содержат реальные credentials.
• Reset DB через assembler/base + project migrations.
• Logs world/auth/database/client собираются с correlation metadata.
• DB-only change test, module build test, startup smoke, scripted client scenario и cleanup.

SRV-9. Existing tools

• Keira3 — reference для field semantics, SQL generation и AzerothCore DB UX.
• AzerothCore wiki/schema/module template — primary backend documentation.
• TrinityCore source/schema/tools — primary для Trinity profile.
• Noggit/WoW modding tools — client-world authoring reference, но не server schema oracle.
• OpenWC Editor объединяет workflow, но сохраняет raw SQL preview и ссылки на upstream docs.

Gate

Одна canonical сущность проходит import → edit → diff → dry-run → apply → reimport на каждом supported profile без silent loss; module/content packages воспроизводимы; production write disabled by default; test environment очищается.