Start with a working baseline, not the advertised feature
This guide applies to a Git-managed C++ client/server project. Before adding a system, build the unmodified revision using its documented toolchain and prove login, map entry and logout on staging. Save the revision and build output. If the baseline fails, you cannot attribute the next failure to the new system.

1. Map the integration surface
List every required change: shared packet definitions, game handlers, db/cache structures, client network code, Python/UI files, locale keys, quest functions, SQL migrations and compile-time flags. Paths such as game/src, db/src or UserInterface are common examples, not guaranteed paths. Trace symbols in your own tree. Record the source and licence of the system and its intended base revision.

2. Create an isolated integration branch
From your repository, first inspect local changes. Commit the intended baseline through your normal process; uncommitted files will not appear in the new worktree. The branch name and sibling directory below must be unused:
git status --short
git rev-parse HEAD
git worktree add -b integration/system-review ../metin2-system-review HEAD
cd ../metin2-system-review

This leaves your current worktree available. Do not use a force/reset option to erase a branch that already exists.

3. Review the diff before applying it
Read the patch, including scripts and build steps. Place the reviewed patch at ../system.patch relative to the new worktree, or substitute its actual path:
git apply --stat ../system.patch
git apply --check ../system.patch
git apply ../system.patch
git diff --check
git diff --stat
git diff

Run apply only after the check succeeds. A failed check means context differs; inspect the target functions and dependencies. Do not force a patch into the nearest similarly named function. A successful check only proves textual applicability, not correct behaviour. diff --check helps spot whitespace errors, not protocol or security bugs.

4. Review cross-component changes
For each packet change, compare sender and receiver field widths, signedness, length handling and serialization. Do not assume sizeof on one compiler defines a portable wire format. If a feature flag changes packet layout, verify the relevant client and server components agree. For stored data, record the schema migration, default values and whether the old executable can still read the new data.

5. Build and test in controlled increments
Use the build command documented by this exact branch; there is no universal make command or dependency list for all Metin2 sources. Build affected shared libraries and consumers, preserve the first compiler/linker error and its command, and perform a clean build when changing shared layouts or flags. Deploy matched artifacts to staging. Test the new feature, its disabled path, reconnect, restart and an existing neighbouring feature.

6. Prepare rollback before deployment
Record hashes/revisions of game, db and client packages, configuration and schema. Keep the previous release and a tested database backup. A source revert cannot undo a destructive schema migration or newly written incompatible records. Define rollback for both code and data, including what recent player progress would be lost, before deciding to release.

Evidence and discussion
The Git command semantics were checked against git-worktree, git-apply and git-diff. No third-party system is claimed to compile merely because this workflow exists. Share the base revision, smallest relevant diff, first error and tested outcome; do not upload private source archives or credentials.