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 (no start-point is passed) 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. ## Sync BEFORE you implement — not only before you land The drift above starts costing you the moment you START CODING on a stale branch, not at landing. A branch cut when the trunk was N commits back means you are editing yesterday's files: you rebuild helpers the trunk already added, "fix" footguns it already closed, and the diff you eventually land can silently revert the trunk's changes to the same lines — on top of the merge conflicts. So run **Procedure A** at the START of a session, before writing any code — whenever the trunk may have moved since the branch was cut (a resumed session, a long-lived one, or a fresh session whose branch was created off an old HEAD). It is cheap up front; the alternative is rediscovering already-landed work and untangling a conflicted land after the fact. "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 t