Publish Change Safely
Perform only the publication actions the user authorized. Repository identity, transport identity, review state, merge, deployment, and live behavior are separate facts.
Workflow
- Restate the authorized action and stopping point: commit, push, PR, or another named boundary.
- Inspect working-tree status, current branch, remotes, upstream, and recent history.
- Verify the account or credential used by the publishing channel. Do not assume Git transport and hosting API identities match.
- Review the exact staged and unstaged scope. Preserve unrelated user changes. Never stage everything without first resolving new, deleted, secret-like, generated, or binary files.
- Run the relevant repository gates or report why they remain incomplete.
- Create a focused commit using the repository's real convention. Do not invent attribution or coauthor trailers.
- Re-read the remote before pushing when concurrent changes are plausible. Never force-push, rewrite shared history, change visibility, or alter branch protection without explicit authorization.
- Push only the intended branch and verify the resulting remote revision.
- If authorized, open or update a PR with evidence-bounded claims. Do not merge unless the user separately authorized merge.
- Report the verified result, exact commit, remote branch, PR/check state, requested actions left unfinished, and consequential lifecycle limits.
Stop conditions
Stop before mutation when identity, target repository, branch, staged scope, secret exposure, history divergence, or requested authority is unclear. A rejected push is not permission to rebase, merge, or force.
Continuity and evidence
Lead with the verified result at the authorized publication boundary. Preserve exact identity, revision, remote readback, failed checks, requested actions left unfinished, and consequential lifecycle limits. Do not list every unrelated action that was never requested.
Read the original acceptance example when checking this behavior.
1---2name: publish-change-safely3description: Publish an authorized repository change by verifying identity, remote, branch, diff scope, checks, commit, push, PR state, and repository visibility. Use only when the user explicitly asks to commit, push, publish, or open a pull request.4license: MIT5---67# Publish Change Safely89Perform only the publication actions the user authorized. Repository identity, transport identity, review state, merge, deployment, and live behavior are separate facts.1011## Workflow12131. Restate the authorized action and stopping point: commit, push, PR, or another named boundary.142. Inspect working-tree status, current branch, remotes, upstream, and recent history.153. Verify the account or credential used by the publishing channel. Do not assume Git transport and hosting API identities match.164. Review the exact staged and unstaged scope. Preserve unrelated user changes. Never stage everything without first resolving new, deleted, secret-like, generated, or binary files.175. Run the relevant repository gates or report why they remain incomplete.186. Create a focused commit using the repository's real convention. Do not invent attribution or coauthor trailers.197. Re-read the remote before pushing when concurrent changes are plausible. Never force-push, rewrite shared history, change visibility, or alter branch protection without explicit authorization.208. Push only the intended branch and verify the resulting remote revision.219. If authorized, open or update a PR with evidence-bounded claims. Do not merge unless the user separately authorized merge.2210. Report the verified result, exact commit, remote branch, PR/check state, requested actions left unfinished, and consequential lifecycle limits.2324## Stop conditions2526Stop before mutation when identity, target repository, branch, staged scope, secret exposure, history divergence, or requested authority is unclear. A rejected push is not permission to rebase, merge, or force.2728## Continuity and evidence2930Lead with the verified result at the authorized publication boundary. Preserve exact identity, revision, remote readback, failed checks, requested actions left unfinished, and consequential lifecycle limits. Do not list every unrelated action that was never requested.3132Read [the original acceptance example](references/continuity-example.md) when checking this behavior.
JovaniPink