commit-minelisted

You are landing this session's changes from a working tree that peer sessions also write to. Two failure modes have actually happened and this procedure exists to prevent both: (1) `git add <file>` swept a peer's unfinished hunks into a commit; (2) a *subtractive* hunk-split (dropping only the peer hunks you knew about) swept an **unknown** peer's hunks into main without their dependencies — dangling references that no test caught, because lazy imports and daemon threads don't fire under unittest. ## Step 0 — Inventory: mine vs theirs, per file - `git status --short` and `git log --oneline -5` (a peer may have just committed — re-derive, don't assume). - Build YOUR edit list from what you actually did this session (files you Edited/Wrote). For each modified file, decide: **wholly mine**, **wholly theirs** (touch nothing), or **mixed**. - For mixed files, `git diff origin/<base> -- <file>` and identify your hunks **positively** — by matching against edits you made — never by subtracting hunks you recognize as someone else's. A peer whose work you haven't seen is exactly the peer you can't subtract. ## Step 1 — Stage - Wholly-mine files: `git add <path>` (explicit paths, never `-A`/`-a`). - Mixed files: hand-write a minimal patch containing only your hunks (context lines + your additions; recount the `@@` headers, or split mechanically with `awk '/^@@/{h++} h!=N || /^diff|^index|^---|^\+\+\+/'`), then `git apply --cached <patch>`. The working tree (peers' edits) stays untouch