GnosysLabs/Hop
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity

Resolve alpha4 integration while preserving accepted Hop behavior

Browse Source 
Hop-State: A_06FN4YF9MKR7SWE1Y7GZDJR
Hop-Proposal: R_06FN4YEJF4PMSYPMQ7T3SBG
Hop-Task: T_06FN3MBF98GWD4NA5PA1RWG
Hop-Attempt: AT_06FN4XMZP6EPRVNAAQWA8K8
This commit is contained in:
Hop
2026-07-11 11:39:09 -07:00
parent 4c0c504935
commit 23a4891099
12 changed files with 1304 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/hop/SKILL.md
+30 -6
View File
@@ -53,7 +53,9 @@ variable or secret-manager name instead.
- 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.
- Never silently merge overlapping proposals.
- Never discard either side of concurrent work. Let Hop perform its three-way
merge, then resolve only the genuine conflict hunks in the reconciliation
workspace it returns.
Verify the captured state before making changes:
@@ -79,14 +81,31 @@ hop status --json
hop propose --summary "<behavioral summary>" <HOP_STATE_ID>
```
6. Unless the user explicitly requested review-only mode, immediately accept
the proposal and validate the exact final tree:
6. Unless the user explicitly requested review-only mode, immediately land the
proposal and validate the exact final tree:
```bash
hop land <proposal-state> -- <final-test-command> [args...]
```
7. Report the accepted result, validation, and remaining risks. Keep internal
Same-file edits with compatible hunks merge automatically.
7. If `hop land` reports a prepared reconciliation prompt/workspace, continue
immediately in that returned workspace. Do not stop or ask the user to
coordinate an ordinary code conflict:
- adopt every returned `HOP_*` value and the fresh reconciliation workspace;
- inspect every conflict candidate plus both returned proposal/current
accepted states; compare their commits when a delete/rename, binary, mode,
symlink, or directory conflict has no text markers;
- resolve every conflict intelligently, preserving both compatible intents;
- remove all merge markers;
- run `hop check` with the returned prompt state (Hop requires checked
reconciliation evidence before it will accept a new proposal);
- create a new proposal and run `hop land` again; and
- repeat if accepted state raced forward again.
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.
@@ -114,11 +133,16 @@ Stop before acceptance only when:
- the user explicitly says `review first`, `proposal only`, `do not land`, or
otherwise asks to approve the result before it is accepted;
- validation fails;
- Hop reports overlap, a changed accepted head, or visible-root divergence; or
- Hop reports visible-root divergence; a conflict has genuine product ambiguity
that cannot be resolved from both recorded intents; or
- acceptance would require a destructive, external, or out-of-scope action not
authorized by the captured task.
On overlap or validation failure, preserve the proposal and report the block.
Ordinary textual overlap is not a reason to stop. Hop first performs a real
three-way content merge; genuine unresolved hunks enter the automatic
reconciliation loop above. Preserve and report a block only when the intents
are product-level incompatible, required validation cannot be repaired, or
safe continuation needs new user authority.
If visible-root synchronization is blocked, do not bypass it with `hop accept`,
force checkout, reset, or file copying. Preserve the proposal and identify the
user-owned paths that must be resolved. `hop accept` is reserved for an
skills/hop/agents/openai.yaml
+1 -1
View File
@@ -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 the task in its isolated workspace, validate it, and auto-accept the proposal 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 it, and automatically reconcile ordinary merge conflicts unless I explicitly request review first."
policy:
allow_implicit_invocation: true
skills/hop/references/protocol.md
+29 -5
View File
@@ -68,6 +68,7 @@ hop status --json
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 check` snapshots the attempt and runs the command in a detached worktree materialized from that exact checkpoint. Edits made concurrently in the live workspace do not change the tested tree.
@@ -77,10 +78,30 @@ hop land <proposal-state> -- <final validation command>
The initial task prompt authorizes the agent to run `hop land` after successful
validation; a second user approval is not required. Manual review is an opt-in
mode: stop at the proposal only when the user explicitly asks to review or
approve before acceptance. Validation failure, overlap, a stale accepted head,
or newly required destructive/external scope also stops automatic acceptance.
approve before acceptance. Validation failure, visible-root divergence,
unresolved product ambiguity, or newly required destructive/external scope
stops automatic acceptance. Path overlap and a stale accepted head do not:
Hop merges, retries, or prepares agent reconciliation.
`hop land` is the Desktop operation. It compares paths changed by the proposal with paths accepted since its base, validates and advances accepted state, then safely materializes that tree into the selected visible project root. The root must still match an accepted Hop ancestor, and ignored or untracked destination collisions block before acceptance. Materialization uses a disposable index and never moves HEAD, the active branch, or the user's real index.
`hop land` is the Desktop operation. It performs a real Git three-way content
merge, so compatible edits in the same file and identical changes compose
automatically. It validates and advances accepted state, then safely
materializes that tree into the selected visible project root. The root must
still match an accepted Hop ancestor, and ignored or untracked destination
collisions block before acceptance. Materialization uses a disposable index and
never moves HEAD, the active branch, or the user's real index.
When the three-way merge has genuine unresolved conflicts, `hop land` returns
exit `20` and automatically prepares a reconciliation prompt in the original
task but a fresh isolated attempt/workspace. Its JSON includes
`reconciliation.prompt`, `workspace`,
`conflicts`, and the proposal/current accepted states. The agent adopts that
prompt/workspace, resolves both intents, checks, proposes, and lands again.
Structural, binary, delete/rename, mode, and symlink conflicts may have no text
markers, so the agent must inspect both returned input states. Hop requires a
successful `hop check` on the resolved tree before reproposal. The user is not
asked to coordinate ordinary code conflicts. `hop refresh` is the idempotent
explicit form of the same preparation step.
`hop accept` is the controller/kernel operation. It advances SQLite and
`refs/hop/accepted` but intentionally leaves the visible root untouched.
@@ -105,7 +126,7 @@ command, summary, output, or source file.
| `0` | Success |
| `1` | Git, SQLite, filesystem, or internal error |
| `2` | Invalid CLI usage |
| `20` | Overlap or conservative conflict block |
| `20` | Genuine three-way merge conflict; reconciliation workspace prepared |
| `21` | Accepted or attempt head changed during compare-and-swap |
| `22` | Validation command failed |
| `23` | Visible project root diverged or contains an overwrite collision |
@@ -146,7 +167,10 @@ provide the same boundary inside compatible agent clients.
- **Check failure:** fix the live workspace, checkpoint/check again, then create a new proposal.
- **Review-only request:** preserve and report the proposal without landing it.
- **Frozen proposal needs changes:** record a follow-up prompt; never mutate the stored proposal.
- **Overlap on landing:** retain both lineages and reconcile through a new prompt against current accepted state.
- **Merge conflict on landing:** continue automatically in the returned
reconciliation prompt/workspace; inspect both inputs, resolve textual and
structural conflicts, validate, propose, and land again. Stop only for
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.
- **Ref inconsistency:** run `hop doctor`; use `hop doctor --repair` only outside final validation.