Private development and GitCafe updates

You can keep developing in a private RS-SDK checkout and publish reviewed app changes here. The two directories are independent copies; they do not automatically sync. Keep one working source of truth for each change and port that change deliberately.

Repeatable update process

1. Develop/test in the private app directory. Keep personal runtime files there.

2. In this standalone repository, run:

   sh

   1	python3 scripts/source-drift.py --source-root /absolute/path/to/rs-sdk/apps/rs-palantir

   This is a read-only planner. It compares previously exported source hashes, prints file paths/statuses and never copies, stages, pushes or reads .env files. New files are not automatically included.

3. Review each changed file. candidate-review-required means it was originally identical; it still needs a privacy/security review. manual-sanitized-export means this copy deliberately differs: port the relevant diff while preserving standalone paths, generic identities and configuration. manual-public-edits means both copies may have changes. Never blanket-copy the app, use rsync --delete or copy private Git history.

4. Include new source/dependencies explicitly. Regenerate the lockfile in this standalone repo when dependencies change. Keep the maintained viewer patch and source together. Record reviewed source/export hashes in EXPORT-MANIFEST.json; do not rebaseline files merely to suppress drift.

5. Run pnpm run check, the Python tests, relevant browser checks, a tracked-file secret scan and dependency advisory check. Confirm no personal config/data, absolute developer paths, real account fixtures or private reports are staged.

6. Commit selected source files to a codex/ review branch and push to this repository's verified GitCafe origin. Update the existing PR for that branch. Main/release is a separate review decision.

For a source download, create an archive from the reviewed commit with git archive, not from a working directory that contains ignored credentials and databases.

Longer-term option

The simplest eventual arrangement is to develop the shared app directly in this standalone repository and set RS_SDK_ROOT to the private checkout for local identities. That removes most copying. Do not migrate the running private app's data or replace its directory until its runtime paths and preserved state have been checked. This guide does not perform that migration.

Contribution rules

• A fresh clone uses the contributor's own identities, accounts and agent providers.
• No default player roster or command authority.
• Keep app state/configuration separate from shared code; no absolute developer paths in tracked files.
• Keep public export changes and private integration adaptations visible in review.
• State which dependency, UI, provider and gameplay checks actually ran. A successful simulator/build is not proof of a connected account.

Public setup divergence

The public app uses local-project Settings, username-only discovery and the generic local operations adapter. Preserve those public implementations when reviewing changes from a private app with additional roster integrations. The removed external connector must not be resurrected by copying a private server entry point or friendly registry wholesale.