dogfood-worktreelisted

# Dogfooding Myco in a Git Worktree This is a **dogfood-only** concern — myco using myco to build myco. A regular user just has one `myco` installed; their own worktrees "just work" because everything resolves to that single binary. The complexity here exists only because we run a **dev** binary (`myco-dev`) alongside the **prod** binary (`myco`) and need capture to keep working while we change Myco itself. ## The core gotcha: a fresh worktree is not myco-dev aware Binary resolution (global launcher `~/.myco/launcher.cjs` and `bin/myco-run`) walks **up from the working directory** looking for `<dir>/.myco/runtime.command`, then the machine pin, then the vendored binary, then PATH `myco`. `.myco/runtime.command` is **gitignored** (`.myco/.gitignore`). `git worktree add` only materializes *tracked* files, so a new worktree starts with **no pin**. With no pin: - A worktree **nested** under the main checkout (e.g. `.worktrees/foo`) walks up and finds the *main checkout's* pin → runs **main's `myco-dev`** (stale vs. the worktree's changes). - A **sibling** worktree (e.g. `../myco-foo`) finds nothing → hooks fall through to PATH `myco` = the **production** binary. Capture then hits the prod daemon/vault. Unacceptable for dogfooding. Either way a fresh worktree never uses **its own** build until you pin it. ## Procedure 1. **Create the worktree** off the branch you're developing: ```bash git worktree add ../myco-<feature> <branch> cd ../myco-<feature> ```