Client Preservation

Clients are part of the protocol and data contract. Preserving only a server repository usually leaves an unusable project.

Snapshot model

Every client snapshot must have a stable ID:

<game>-<region>-<language>-<version-or-build>-<acquired-date>

Example:

ffxiv-global-en-2012.09.19.0001-2026-07-16
wow-global-en-3.3.5a.12340-2026-07-16

Record the displayed version and the evidence used to determine it: executable version resource, version file, launcher metadata, package manifest, or trusted release documentation.

Required states

State	Treatment	Intended use
original/	Read-only exact acquisition; never launched in place.	Authenticity and future recovery.
normalized/	Lossless extraction or consistent layout; originals retained.	Inspection and deduplication.
working/	Generated copy containing configuration, patches, launchers, or compatibility shims.	Running and testing.

Changes must flow in one direction: original → normalized → working. Recreate a working copy instead of repairing it manually when drift is detected.

Intake checklist

• Assign a client snapshot ID.
• Record game, edition, region, language, architecture, and version/build.
• Record acquisition date, source, original filenames, and access classification.
• Hash every original file or the original archive with SHA-256 or stronger.
• Preserve installer/patcher and patch packages when available.
• Capture directory manifest, file sizes, timestamps, and executable version metadata.
• Record required runtimes, fonts, registry values, system libraries, and redistributables.
• Record launch arguments, configuration endpoints, and the launcher version.
• Identify anti-tamper, DRM, or online dependencies without bypassing controls unlawfully.
• Scan untrusted legacy binaries in an isolated environment; record the scanner/tool versions and result.
• Restrict access if redistribution is not authorized.

Manifest files

Each snapshot directory should include:

• artifact.yml — identity, provenance, classification, and relationships.
• SHA256SUMS — hashes of source artifacts.
• files.sha256 — recursive file manifest for the extracted tree.
• README.md — human context and restoration notes.
• runtime.yml — operating system, architecture, dependencies, and launch procedure.
• patches/series.yml — ordered patches or transformations used by a derived copy.
• verification/ — smoke-test log and expected result.

See Preservation Metadata for the schema.

Client/server compatibility matrix

Compatibility must be recorded as a tested relationship, not an assumption:

Client snapshot ID	Server artifact ID	Result	Verified on	Evidence
No verified pair yet	See Compatibility Matrix	evidence blocked	Not yet	#1

Safe handling

• Do not publish client binaries merely because a repository is public.
• Keep public metadata separate from restricted bytes.
• Never embed real account credentials, personal profiles, cache files, chat logs, screenshots, or save data in a clean snapshot.
• Use disposable accounts and isolated networks for legacy-client testing.
• Preserve the unmodified client even when the working copy needs binary patches.

Clean working copy criteria

A generated client working copy is clean when it has no personal data or secrets, all changes are declarative, endpoints are configurable, patches are traceable, and regenerating it from the preserved inputs produces the same file hashes except for explicitly variable files.