merge-conflictlisted

Resolve conflicts by integrating the *intent* of both sides, never by blindly picking one or deleting code you don't understand. Work from the actual conflict, the operation that produced it, and the history behind each side. ## Hard rules: never break these - **Understand before you resolve.** Read what each side was trying to do (the commits, the surrounding code) before editing a single marker. A "resolved" conflict that drops one side's intent is a silent bug, not a fix. - **Never reflexively accept `--ours` or `--theirs`.** Whole-file side-picking is almost always wrong and discards real work. Resolve hunk by hunk. - **Know which side is which.** It flips by operation. In a `merge`, *ours* = the branch you're on, *theirs* = the branch being merged. In a `rebase`, it's **reversed**: *ours* = the branch you're replaying onto (upstream), *theirs* = your commits being replayed. Confirm before using either. - **Verify after resolving.** The merge succeeding means the markers are gone, not that the code is correct. Build, lint, and run tests before you consider it done. - **Don't commit a half-resolved or unverified state**, and confirm before finalizing (`commit` / `--continue`) or aborting. - **When in doubt, it's safe to bail.** Conflicts are recoverable: `git merge --abort` / `git rebase --abort` / `git cherry-pick --abort` returns you to where you started. Prefer that over guessing. ## Step 1: Identify the operation in progress The right "continue" and "abort" command