gabriel / muse public
fix fix/93-harmony-auto-apply-key-mismatch #1 / 1
AI Agent gabriel · 15 hours ago · Oct 21, 2026 · Diff

fix: harmony auto-apply reports success but silently discards the resolution

muse#93, documented as a known bug in docs/agent-guide.md's Harmony section since 2026-09-12 (musehub staging#93) -- data integrity, not cosmetic: `muse merge`'s harmony auto-apply path printed "auto-resolved" and bumped the resolution's applied_count, but the actual committed content (and the working tree) stayed "ours", discarding the recorded, human-verified resolution entirely.

Root cause: auto_apply() (muse/core/harmony/engine.py) returns a dict keyed by the *original conflict path*, which for the code domain is a symbol address ("calc.py::add"), not a plain file path -- this part was already correct and well-tested (tests/test_harmony_integration.py's TestAutoApplySymbolPaths covers it). The bug was one level up, in merge.py's `merged_files.update(harmony_resolved)`: merged_files is keyed by plain file paths, same as every other manifest in this function. Updating with the raw symbol-addressed keys inserted a bogus "calc.py::add" entry into a file-path-keyed dict while leaving the real "calc.py" entry untouched at its stale pre-harmony value. That stale value is what got written to the working tree (via a later apply_manifest call using this same manifest) and committed.

Existing tests didn't catch this because they test auto_apply() directly at the unit level -- correctly proving IT returns the right {symbol_path: outcome_blob} mapping -- never exercising the full `muse merge` CLI flow where that mapping gets folded into the file-path-keyed manifest that's actually committed.

Fix: re-key harmony_resolved to plain file paths (`p.split("::")[0]`) before merging into merged_files -- one line, matching the same path.split("::")[0] convention already used throughout this file and auto_apply itself for extracting the file portion of a symbol address.

Test: new tests/test_harmony_merge_commit_integrity.py, reproducing the exact scenario from the ticket end-to-end through the real CLI (not synthetic objects) -- two branches conflict on the same symbol, resolve manually to a THIRD value differing from both "ours" and "theirs", confirm harmony recorded it, reproduce the identical conflict pattern on a fresh branch pair, and assert the merge reports "merged" (not "conflict") with the working tree AND the actual committed object (read via `muse cat`, not just the working tree) matching the recorded resolution -- not either original side. Confirmed genuine RED against the unfixed code (working tree showed "+1" where "+101" was expected) before applying the fix.

Full harmony + merge regression suite (797 tests across every harmony and merge test file): zero regressions.

Verified against the real CLI (muse-dev) before writing the automated test: reproduced the bug live (committed object confirmed via `muse cat-object`/`muse cat` to contain "ours", not the recorded resolution), then confirmed the fix live the same way.

Audited (ticket's own ask #4) whether musehub's server-side merge path shares this bug -- separate report, see follow-up comment on the ticket.

sha256:aa1523d6dd71d33a7ad57b3c6430556bdfba58cefb95cc85b95a3904932d2749 sha
sha256:1f1fca3c6e64bf11f2bfded0e1f03ee4955e297af4d6b5138a2b1362e31f8187 parent
+12 ~1 symbols
2 changed · 1214 in snapshot files
sha256:f2f39bac92fb60b1bc223aa77ca9b56715244efc9a5fa7c1cb9ff553bb895a88 snapshot
+12
symbols added
~1
symbol modified
2
files changed
1214
files in snapshot
0
dead code introduced
Semantic Changes 13 symbols
~ tests/test_harmony_merge_commit_integrity.py .py 12 symbols added
+ _branch_from function function _branch_from L55–62
+ _commit_calc function function _commit_calc L47–52
+ _run function function _run L38–44
+ CliRunner import import CliRunner L33–33
+ InvokeResult import import InvokeResult L33–33
+ annotations import import annotations L25–25
+ json import import json L27–27
+ os import import os L28–28
+ pathlib import import pathlib L29–29
+ pytest import import pytest L31–31
+ runner variable variable runner L35–35
+ test_harmony_auto_apply_commits_the_recorded_resolution_not_ours function function test_harmony_auto_apply_commits_the_recorded_resolution_not_ours L65–142
~ muse/cli/commands/merge.py .py 1 symbol modified
~ _run_merge
Files Changed
+1 ~1
1214 in snapshot
+ tests/test_harmony_merge_commit_integrity.py .py
~ muse/cli/commands/merge.py .py
← Older Oldest on fix/93-harmony-auto-apply-key-mismatch
All commits
Newer → Latest on fix/93-harmony-auto-apply-key-mismatch

0 comments

No comments yet. Be the first to start the discussion.

To add a comment, use the Muse CLI: muse hub commit comment sha256:aa1523d6dd71d33a7ad57b3c6430556bdfba58cefb95cc85b95a3904932d2749 --body "your comment"