Reproducible Baselines

A baseline is a declared, verifiable state of a server/client pair. It is the unit used for clean installations, regression tests, and future recovery.

The first concrete intake record is Baseline TC335-001. It deliberately remains P0/P1 until the restricted client, Linux toolchain, database, extracted data, and runtime evidence exist.

Baseline manifest

schema_version: 1
id: <server-id>-<server-revision>-<client-build>-v1
server:
  artifact: <artifact-id>
  git_commit: <full-commit-id>
  patches: []
client:
  artifact: <snapshot-id>
  derived_patchset: <patchset-id-or-null>
host:
  distribution: <name>
  version: <version>
  architecture: <arch>
database:
  engine: <engine>
  version: <version>
  schema_artifact: <artifact-id>
toolchain:
  lockfile: <path-or-artifact-id>
network:
  exposure: loopback
verification:
  procedure: <runbook-id>
  expected_milestone: <observable result>

Secrets, public IP addresses, and personal account data never belong in the baseline manifest.

Clean-state rules

• Begin from a documented operating-system image or container/VM definition.
• Use pinned server commits, toolchain versions, package snapshots, and database schemas.
• Generate configuration from templates; inject secrets at deployment time.
• Treat the database as state. Do not ship live user databases as a clean baseline.
• Generate working client/server trees from immutable inputs.
• Record every migration and patch in order.
• Store logs and test results outside the clean artifact.
• Make reset and uninstall behavior explicit.

Verification ladder

Stage	Expected proof
Integrity	All required artifacts match checksums.
Build/install	Process completes from a clean environment without undocumented steps.
Database	Schema initializes and required migrations complete.
Process	Expected server processes remain healthy for the observation window.
Network	Expected local ports listen; unrelated ports remain closed.
Authentication	Disposable test account can complete the intended login flow.
World/session	Client reaches the game-specific smoke-test milestone.
Restart	Controlled stop/start retains only intended state.
Restore	Backup restores into a second clean environment and repeats the milestone.

Game-specific milestone examples

• LandSandBoat: disposable account logs in, character reaches a zone, world/search/connect/map processes remain healthy.
• Project Meteor: 1.23b client reaches the configured lobby/world flow and required legacy assets load.
• Sapphire: client data version matches, lobby/API/server start, and the client reaches the agreed login/world milestone.
• TrinityCore: data extraction completes, auth/bnet and world processes start, disposable client reaches realm/character flow.
• Aura Kingdom: preserved release is prepared without modifying originals, PostgreSQL imports, and the isolated QEMU-driven process group reaches the recorded handshake milestone.

Milestones must be made more precise in each server profile as verification improves.

Drift detection

Rebuild working copies periodically and compare file manifests. Differences must be classified as expected variable state, approved derived changes, or unexplained drift. Unexplained drift invalidates the “clean” label until resolved.