---
name: kitsubito-remote-launch-traps
description: "Three traps when launching a battery on kitsubito over ssh — single-branch fetch refspec, non-login PATH missing ~/.local/bin (traceable-reqs), and a cd that must exit on failure"
metadata: 
  node_type: memory
  type: project
  originSessionId: 0f1cd318-0505-4e70-8849-c30b62254099
  modified: 2026-09-07T01:24:35.561Z
---

Launching a lane battery on kitsubito over `ssh reavus@kitsubito` (measured 2026-09-07, W1 #249):

1. `~/spt-w1` is a SINGLE-BRANCH clone: `git fetch origin <branch>` mints NO `origin/<branch>` ref
   (the configured refspec covers one branch). Fetch with the explicit refspec
   `git fetch origin +refs/heads/X:refs/remotes/origin/X` before `git worktree add ... origin/X`.
2. A non-login ssh shell (`bash -s`, even after `source ~/.cargo/env`) lacks `~/.local/bin`, which is
   where `traceable-reqs` lives → the driver's first leg exits 127. Run drivers under `bash -lc`.
3. A launch script must `cd <worktree> || exit`: mine fell through into the ROOT checkout and launched
   the driver there. Harmless only because that sha had no script; the shape was one `||` from a
   foreign-tree battery in the root pool.

**Why:** each trap reads like a lane red or a running battery. I told doyle the battery was running
before reading the launch output — [[never-send-a-claim-composed-before-its-check-ran]] again.

**How to apply:** one ssh, `bash -lc`, explicit refspec, `cd ... || exit N`, then `cat driver.log`
after a sleep and report only what that cat shows. Related: [[a-stopped-local-ssh-does-not-stop-its-remote-command]].

**2026-09-08 (hertz, measured):** `/home/reavus/projects/spt-core/spt-core` on kitsubito has `origin` pointing at a LOCAL PATH — `/home/reavus/actions-runner/_work/spt-bs-core/spt-bs-core`, the Actions runner's own working copy — not at GitHub. `git fetch origin <branch>` says "couldn't find remote ref" (the runner repo holds only refs CI checked out), its `origin/main` was 68e34ae5 while real main was fd296557, and fd296557 / 17443615 / 2f422990 were all ABSENT as objects. Fetch + checkout origin/main + build there SUCCEEDS against stale bytes: a green that belongs to another sha, with no error. Workaround that also keeps hands off the runner repo during a live golden: a thin `git bundle create lane.bundle ^<common-sha> <branch>` scp'd over and `git fetch /tmp/lane.bundle` into a local ref; verify the far-side sha before building. Always print `git remote -v` and `git rev-parse HEAD` in the launch log on that box.

**CR bytes (hertz, measured 2026-09-08):** a plain git checkout on kitsubito gives a rig script LF (census field `rig-script-CR-bytes = 0`), so a `set -u<CR>` death is a copy SHIPPED from Windows, never the checkout — normalize (`sed -i 's/\r$//'` or `git bundle` + checkout there) at the SHIP step only, and print the CR count in the launch census.
