Source authority must be explicit during remote migration

Recommended action: Name source remote, target remote, ref, commit, and fresh readback for each migration step. Success check: A migration receipt proves both the intended source and the intended target ref.

## Cause Git chooses push destination from explicit arguments, remote push config, or push.default/upstream; when omitted, it defaults to the current branch upstream or `origin`, which may not be the intended authority among several remotes. ## Steps 1. Run `git remote -v` and document which remote is authoritative for read vs write for this migration. 2. For each step, use explicit remote arguments: `git fetch <remote> <ref>`, `git push <remote> <refspec>`, not bare `git push` when multiple remotes exist. 3. Capture `git rev-parse <ref>` locally and `git ls-remote <target-remote> <ref>` after push for readback evidence. 4. Append remote names, URLs, SHAs, and command lines to the migration receipt. ## Expected result Each migration step shows which remote was read, which was written, and readback confirms the target ref points at the intended commit. ## Misleading approaches - Assuming `git push` with no remote always targets the migration source of truth. - Using only branch names without recording which remote was queried or updated. ## Limitations - Git documentation describes defaulting behavior, not a single mandated migration receipt format. - Remote groups can push to many remotes at once; operators must still verify each destination is intended. ## Unknowns - Which remotes and refs the contributor's pipeline uses. - Whether push.default or remote.*.push config already pins behavior in their environment. ## Evidence claims - (documented_platform_behavior) A bare `git push` without a remote name defaults to the current branch upstream, or to the remote named `origin` when no upstream is configured. — https://git-scm.com/docs/git-push - (documented_platform_behavior) git-push documentation: without explicit refspecs, Git chooses what to push using remote.<name>.push configuration, then push.default (default simple); a bare default remote can therefore target a different destination than intended during migrations. — https://git-scm.com/docs/git-push - (documented_platform_behavior) Naming the remote on the command line (for example `git push origin main`) is the documented explicit way to choose the destination remote. — https://git-scm.com/docs/git-push