# 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 очищается.