diff --git a/AGENTS.md b/AGENTS.md
index 42ad059..7715587 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -18,8 +18,9 @@ MCP service in one npm/Turborepo workspace.
 6. Keep shared package exports type-only and route them through `src/index.ts`.
 7. Do not commit secrets, generated evidence, local logs, or runtime state.
 8. Implement in a task-specific git worktree created from current `staging`,
-   not in the shared `staging` checkout. After the work is verified, merge the
-   completed task branch back into local `staging`.
+   not in the shared `staging` checkout. After the work is verified, commit the
+   scoped changes, merge the completed task branch back into local `staging`,
+   push `staging`, and prove local and remote commit parity.
 9. Before merging, identify every deployed app or service the change can affect
    and prove the relevant compatibility contracts still hold. Preserve deployed
    interfaces and supported client behavior; repository checks alone do not
@@ -46,8 +47,8 @@ MCP service in one npm/Turborepo workspace.
 
 ## Workflows
 
-- Implementation: create a task worktree from current `staging`; merge verified
-  work back to local `staging` when complete.
+- Implementation: create a task worktree from current `staging`; commit verified
+  work, merge it back to local `staging`, push `staging`, and verify remote parity.
 - Bootstrap: `npm ci`
 - Full local stack: `scripts/dev-local.sh up`
 - Fast checks: `npm run verify:fast`
diff --git a/docs/agents/routing.md b/docs/agents/routing.md
index 6778361..ff7d803 100644
--- a/docs/agents/routing.md
+++ b/docs/agents/routing.md
@@ -12,8 +12,16 @@ Implementation starts in a dedicated task worktree created from the current
 integration target. Complete the scoped change, review its diff, and run the
 required verification in the task worktree. Merge the task branch back into local
 `staging` only after that evidence passes; an unverified or partially complete
-branch does not belong in `staging`. Pushing or deploying `staging` remains a
-separate operation subject to the applicable release and production-safety rules.
+branch does not belong in `staging`.
+
+Completion includes publishing the work: commit only the scoped task changes,
+merge the verified commit into local `staging`, push `staging`, then fetch or read
+back the remote ref and prove `HEAD` equals `origin/staging`. Do not report an
+implementation complete while its commits exist only in a task worktree or the
+local integration checkout. A blocked or ambiguous push is a blocker, not a
+successful publish; preserve the commit, do not retry blindly, and report the
+exact remote state. Pushing and deployment remain subject to applicable branch
+protection, release, and production-safety rules.
 
 Before implementation, map the change to every deployed consumer it can affect,
 including supported mobile builds, web and admin clients, the API and worker, and