muse resolve — manual merge resolution command

Problem

muse code add <path> stages a manually merged file but does not clear conflict_paths in MERGE_STATE. This leaves muse commit permanently blocked even when the merge is correct. The only escape hatch today is muse checkout --ours or --theirs, both of which force a side-pick and destroy the manual merge.

This was discovered during a three-way merge demo at ~/dev/foundations. Two orthogonal changes to hello.md::Hello World — one adding style="background: red;", one adding inner text — were manually combined correctly, but the commit guard kept firing because MERGE_STATE still listed the symbol as conflicted. The workaround required throwing away the manual work, running checkout --ours, then re-applying the merged content by hand.

The missing primitive is muse resolve — a command that marks a conflict resolved in MERGE_STATE without touching the working tree.

Proposed UX

# Edit file manually to combine both sides, then:
muse resolve hello.md

# ✅ hello.md::Hello World — marked resolved
# 0 conflicts remaining. Ready to commit.

Symbol-level variant for granular resolution in multi-symbol files:

muse resolve hello.md::Hello World

This mirrors git add <path> after a manual conflict resolution — staging is the signal. Muse's symbol-level conflict tracking is more granular than git's, so muse resolve should be equally ergonomic at both path and symbol granularity.

Full happy path after the fix:

# edit the file manually
muse resolve hello.md          # clears conflict, stages file
muse commit -m "merge: ..."   # succeeds

Implementation Plan

Phase 1 — MERGE_STATE mutation primitives

Scope: muse/core/merge_state.py (or equivalent)

Add two methods:

• resolve_path(path: str) -> list[str] — removes all conflict entries whose file portion matches path; returns list of symbol addresses cleared
• resolve_symbol(symbol_address: str) -> bool — removes exactly one entry from conflict_paths; returns whether it was present

Invariants:

• original_conflict_paths is never mutated — Harmony reads it at commit time to know what was learned
• conflict_paths becomes empty → merge_in_progress may remain true until commit clears it
• Both methods are idempotent — calling them on an already-resolved path is a no-op, not an error

Phase 2 — muse resolve command

Scope: muse/cli/commands/resolve.py + registration in CLI root

Behaviour:

1. Validate a merge is in progress — error clearly if not
2. Accept <path> or <path>::<symbol> as the argument
3. Validate the target is actually in conflict_paths — warn (not error) if already resolved
4. Call Phase 1 mutation
5. Stage the file (muse code add <path>) so the object store reflects the manual edit
6. Print per-symbol confirmation lines + remaining conflict count
7. If 0 conflicts remain, print "Ready to commit."

Flags:

• --all — resolve all symbols in all currently staged files that are in conflict_paths
• --json — machine-readable output: {resolved: [...], remaining: N}

Error cases:

• No merge in progress → ❌ Not in a merge. Nothing to resolve.
• Path not tracked → ❌ hello.md is not a tracked file.
• Path not conflicted → warn ⚠ hello.md has no unresolved conflicts. (exit 0)

Phase 3 — commit guard alignment

Scope: muse/cli/commands/commit.py (the conflict_paths guard)

Verify the existing guard reads conflict_paths (the mutable list, not original_conflict_paths). If it does, Phase 1 + 2 are sufficient and this phase is a no-op. If it reads the wrong field, fix it here.

Add a test: after muse resolve, muse commit must succeed.

Phase 4 — Harmony integration

Scope: muse/harmony/ — record_resolutions call site

muse resolve is the human-in-the-loop signal. When the subsequent commit fires, Harmony should record the resolution with confidence=1.0 and human_verified=True for each symbol that was resolved via muse resolve (as opposed to auto-applied).

Mechanism: store a manually_resolved set in MERGE_STATE (populated by Phase 2). The Harmony commit hook reads this set and upgrades confidence accordingly.

This makes muse resolve a first-class Harmony learning event — not just a UX fix, but a signal that raises the quality of future auto-resolutions.

Phase 5 — muse conflicts and muse status display

Scope: muse/cli/commands/conflicts.py, muse/cli/commands/status.py

Update muse conflicts --json output to distinguish:

• unresolved — in conflict_paths, not yet resolved
• resolved — in original_conflict_paths but cleared from conflict_paths

Update muse status --json to surface the same distinction so tooling and agents can see partial progress through a complex merge.

Acceptance Criteria

• muse resolve hello.md after a manual edit clears conflict_paths and stages the file
• muse resolve hello.md::Hello World resolves a single symbol, leaving others conflicted
• muse resolve --all resolves all staged conflicted files in one command
• muse commit succeeds immediately after muse resolve clears all conflicts
• original_conflict_paths is intact after resolution (Harmony still learns)
• Harmony records human_verified=True for manually resolved symbols
• muse conflicts --json distinguishes resolved vs unresolved symbols
• muse resolve on a non-conflicted path warns and exits 0 (no error)
• muse resolve outside a merge errors clearly
• --json flag works on muse resolve

Background

Discovered during three-way merge demo at ~/dev/foundations. The Harmony system already records resolutions correctly at commit time — muse resolve is the missing link that makes the human-in-the-loop path as ergonomic as the auto-resolved path. Without it, manual merges require a destructive workaround that throws away work.