Automatically push every accepted Hop transition

Hop-State: A_06FN6FF8HFSFD9ANGK6BY4G
Hop-Proposal: R_06FN6FDTK9G17RXFFT82ZYR
Hop-Task: T_06FN6CFVXVVAP1KZAJ2X62R
Hop-Attempt: AT_06FN6CFVXTRZ8ZDG28QR5Z0

skills/hop/SKILL.md

@@ -71,7 +71,7 @@ variable or secret-manager name instead.
 - Use absolute paths beneath that workspace for file reads and edits.
 - Never edit the selected canonical project root.
 - Do not run `git commit`, `git checkout`, `git switch`, `git branch`,
-  `git rebase`, `git reset`, `git stash`, or `git worktree`.
+  `git rebase`, `git reset`, `git stash`, `git worktree`, or `git push`.
 - Do not stage files. Hop captures every nonignored workspace change.
 - Give a subagent project-changing work only after creating a distinct Hop
   prompt/attempt for that delegation.
@@ -130,7 +130,9 @@ hop status --json
 8. Report the accepted result, validation, and remaining risks. Keep internal
    state and evidence IDs out of the normal response unless they help explain a
    failure or the user asks for them. Confirm that `hop land` reported the
-   selected visible project root as synchronized.
+   selected visible project root as synchronized. When it reports an automatic
+   push warning, retry once with `hop push`; never force-push or ask the user to
+   perform routine source-control mechanics.
 
 For a read-only or informational turn, the prompt state is sufficient; do not
 invent a proposal when the workspace tree is unchanged.
@@ -147,6 +149,11 @@ to complete that task. Do not ask for separate landing permission and do not
 capture a second prompt merely to land. After checks pass and the proposal is
 frozen, run `hop land` as part of the same turn.
 
+An existing unambiguous Git upstream is standing project configuration for
+non-forced publication of accepted states. Hop pushes accepted commits
+automatically after landing; prompts, checkpoints, proposals, and `.hop/` state
+remain local. Do not run raw `git push`.
+
 Use the strongest relevant final validation command. If the task truly has no
 runnable validation, `hop land <proposal-state>` is allowed and the final
 response must say that acceptance was not validated by a command.

skills/hop/agents/openai.yaml

@@ -1,7 +1,7 @@
 interface:
   display_name: "Hop Version Control"
   short_description: "Capture every coding prompt before project effects"
-  default_prompt: "Use $hop to capture this prompt first, complete and validate the task in its isolated workspace, auto-land it, and automatically reconcile ordinary merge conflicts unless I explicitly request review first."
+  default_prompt: "Use $hop to capture this prompt first, complete and validate the task in its isolated workspace, auto-land and publish accepted work, and automatically reconcile ordinary merge conflicts unless I explicitly request review first."
 
 policy:
   allow_implicit_invocation: true

skills/hop/references/protocol.md

@@ -91,6 +91,7 @@ hop check "$HOP_STATE_ID" -- <command>
 hop propose --summary "<summary>" "$HOP_STATE_ID"
 hop land <proposal-state> -- <final validation command>
 hop refresh <proposal-state>
+hop push
 ```
 
 An adapter may set `HOP_AGENT=<runtime>` or pass `--agent <runtime>`. If it has
@@ -135,6 +136,12 @@ explicit form of the same preparation step.
 `hop sync` safely catches a stale accepted-ancestor root up to the current
 accepted state, including projects created with older Hop builds.
 
+After every successful `hop land` or `hop accept`, Hop automatically performs a
+non-forced push of the accepted commit when the active branch has an
+unambiguous upstream. No remote is a normal local-only mode. Push failure does
+not undo acceptance; `hop push` retries the current accepted commit. Agents
+must never replace a non-fast-forward rejection with a force-push.
+
 `hop begin` is the interactive-agent entry point. It initializes Hop when
 necessary and captures the current message before the agent performs project
 work. Runtime adapters identify themselves through `HOP_AGENT` or `--agent`
@@ -206,6 +213,7 @@ provide the same boundary inside compatible agent clients.
   product ambiguity, not ordinary textual overlap.
 - **Visible-root conflict:** preserve the proposal and the user's files. Do not substitute controller-only `hop accept`; resolve or capture the visible changes, then land again.
 - **Controller-accepted root is stale:** run `hop sync`; it succeeds only from an accepted ancestor and never overwrites divergence.
+- **Automatic push warning:** retry once with `hop push`; preserve a diverged remote and never force-push it.
 - **Ref inconsistency:** run `hop doctor`; use `hop doctor --repair` only outside final validation.
 - **Secrets:** Hop redacts high-confidence provider keys plus contextual tokens,
   passwords, private keys, authorization headers, and credential-bearing URLs