landing-to-mainlisted

# Landing harness task-branch work Harness tasks run on a `harness/<taskID>` branch created **once** from the repo's HEAD at task-creation (`runner/worktree.go` `Create`, no start-point) and **never re-synced** — resume just re-attaches the same branch. So the branch drifts from the trunk the longer it lives. **Landing is where that drift becomes divergence if you do it wrong.** This skill is about landing safely on any repo the harness manages. "Trunk" below = the repo's default branch (`main` or `master`). Detect once: ```bash TRUNK=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's#^origin/##') TRUNK=${TRUNK:-main} ``` ## Universal rules (every repo, every mode) 1. **Rebase the task branch onto the current trunk before landing** (Procedure A). A stale branch lands stale. 2. **NEVER cherry-pick task commits onto the remote trunk** (`git cherry-pick … && git push`, or `git push origin <branch>:<trunk>` of cherry-picked SHAs). Cherry-picking mints NEW SHAs on the remote for work that still exists under OLD SHAs on the task branch; nobody reconciles them, so later sessions see "same content, two SHAs" = **dup-SHA divergence** (`git rev-list` over-counts — "72 ahead" — the recurring "something's weird"). The fix is to never create them. 3. **`git push --force` is banned.** 4. **Verify with content, not commit messages.** Two same-message commits across branches are NOT necessarily the same code — use `git diff <a> <b>` / `git cherry`. ## Per-repo lan