Submit Aetherkiri Cross Repo PRs

Submit AetherKiri Cross-Repo PRs

Create minimal, reviewable public and private PRs while preserving the AetherInternal confidentiality boundary. Treat successful compilation and confidentiality as separate requirements.

Establish the trust boundary

Confirm all of the following before pushing:

• AetherKiri is public and packages/AetherInternal is a private git submodule.
• Private implementation, tests that disclose algorithms, reverse-engineering notes, and proprietary assets remain in AetherInternal.
• Public changes contain only generic interfaces, portable fallback behavior, package integration, non-sensitive tests, documentation, and the gitlink.
• The public branch is created inside AetherKiri/AetherKiri when combined CI requires repository secrets. Fork and Dependabot PRs do not receive AETHERSECRET and must build public fallbacks.
• The workflow uses pull_request, not pull_request_target, to execute PR code.

Do not equate a private checkout with zero disclosure. A public gitlink reveals the private commit SHA. Public Actions logs can reveal private paths, symbol names, warnings, or compiler error excerpts. Uploaded application artifacts contain compiled Internal code and can be reverse engineered. Never claim absolute secrecy when public CI builds private code.

Audit public workflow exposure

Before relying on combined CI, inspect .github/workflows on the PR base and branch:

1. Confirm trusted same-repository PRs enable Internal and supply only the read-only deploy key required for submodule checkout.
2. Confirm untrusted/fork PRs disable recursive private submodules and select public fallbacks.
3. Keep persist-credentials: false and repository permissions at contents: read unless a reviewed job requires more.
4. Confirm no step prints secrets, SSH configuration, private diffs, source contents, environment dumps, or generated compile databases.
5. Review every artifact upload. Public app artifacts include private compiled behavior even when source stays private. Upload them only when that distribution is intentional.
6. Keep caches from untrusted PRs read-only and never cache credentials or private source trees into a public artifact.

If private source confidentiality is stricter than public build-log exposure allows, run the full build in AetherInternal and report a status to public instead of compiling Internal in public Actions.

Create clean branches

Use independent worktrees based on the latest remote default branches. Do not open a PR from a long-lived branch containing removed, reverted, or previously private history.

1. Fetch both remotes and inspect open PRs.
2. Create the Internal branch from the latest AetherInternal/origin/main.
3. Create the public branch from the latest AetherKiri/origin/main.
4. Reapply only the commits required for the current fix. Preserve author identity.
5. Scan the public diff for game files, local paths, private class names, algorithms, proprietary SDK references, secrets, and unrelated historical commits.
6. Leave local launchers, logs, saves, builds, and game packages untracked.

Use $fix-aetherkiri-game-compatibility to determine public/private implementation ownership and validate the game behavior before submission.

Submit Internal first

1. Commit the private implementation in AetherInternal.
2. Rebase or merge the latest private origin/main before publishing.
3. Push the private branch.
4. Obtain the full commit ID from Git; never type or extrapolate it from a short prefix:

git rev-parse HEAD
git ls-remote origin refs/heads/BRANCH

Require both commands to report the same 40-character SHA.

5. Open the Internal PR against main and record its URL.
6. Keep the remote branch until the public PR has merged or its gitlink points to an Internal main commit.

An Internal commit does not need to be merged for trusted public CI to test it. It must be reachable from an advertised private remote ref and readable by the workflow deploy key.