Merge-conflict resolution discipline: per-file, intent-preserving, test-after-each-batch

[azalio]

Source loop: merge-conflict-resolver (loops.elorm.xyz)

What the loop does

Rebase/merge onto main, resolve conflicts one file at a time preserving original intent, run tests after each batch, iterate until the branch is current and tests pass. Discipline: minimal changes, no bulk "accept theirs/ours".

Why valuable for MAP

This is a concrete, recurring pain point in this very repo: the memory note branch-from-main-not-feature-branch documents that forking off a squash-merged parent produces CONFLICTING PRs where CI never runs. MAP has no rebase/conflict-resolution workflow or guardrail — yet autonomous agents hit conflicts constantly. The per-file, intent-preserving, test-after-each-batch pattern is exactly where bulk edits silently corrupt intent.

What MAP has today

• Nothing for git rebase/merge-conflict handling.
• Memory/CLAUDE.md guidance to branch from origin/main (prevention, not resolution).

Proposed scope

• A small guardrail (skill step or documented procedure) for conflict resolution: rebase onto origin/main, resolve file-by-file preserving both sides' intent, run the test gate after each resolved batch, never blanket-accept.
• Verify post-rebase: branch is current, no markers remain, tests green.
• Optionally surface as a map-* helper invoked when git status shows conflicts mid-workflow.

Notes

Reinforces the existing "branch from origin/main" prevention rule with a resolution path for when conflicts still occur.

---

Part of #251

[azalio]

Taking this one now. Plan: add a concrete MAP conflict-resolution guardrail/procedure that starts from origin/main, resolves conflicts file-by-file preserving both sides' intent, verifies no conflict markers remain, and requires the test gate after each resolved batch plus final branch-current verification.