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
docs/product-blueprint.md
+7 -2
View File
@@ -195,9 +195,14 @@ Hop should distinguish several kinds of interaction:
Non-overlapping files are not sufficient evidence of compatibility. Database migrations, API callers and implementations, dependency upgrades, generated outputs, and shared invariants often conflict across files.
“Semantic merge” should not initially mean that a model silently rewrites conflicting code. The safer operation is **refresh**:
“Semantic merge” should not mean blindly rewriting conflicting code. Hop first
uses deterministic Git three-way merging. When genuine hunks remain, the agent
automatically enters a provenance-linked **refresh** workspace:
> Give the original agent the newer accepted state, the intervening task summaries, the conflict packet, and its original intent; ask it to produce a new proposal.
> Give the original agent the newer accepted state, the intervening task
> summaries, the conflict-marker tree, and its original intent; require it to
> resolve, validate, repropose, and land without asking the human to coordinate
> an ordinary code merge.
For many agent tasks, replaying or regenerating against the latest state is cheaper and safer than preserving every old hunk.