The comments and Agent Note blamed macOS resolving /var through
private/var. That is only how the mismatch surfaced in temp fixtures, since
mktemp hands back a /var path there.
The real condition is broader: Git always reports resolved paths, so
comparing one against an unresolved path disagrees whenever a symlink sits
anywhere above the checkout. A symlinked home directory alone triggers it —
reproduced with no /var involved — which is common wherever homes live
behind a symlink or on a network mount.
Naming the cause correctly keeps a reader from dismissing resolve_dir as
macOS-only defensiveness.
Review flagged the resolve_dir comment: it claimed `x=$(cmd) || fallback`
never fires "because the assignment succeeds even when the substitution
fails." That is wrong — command substitution propagates exit status and the
fallback does fire, confirmed in sh, bash, dash, and zsh.
Reproducing the original code shows the fallback also worked, so the second
"recurrence" the Agent Note described never existed. Both real defects were
the same one: comparing a resolved path against an unresolved one. The note
now says that instead of inventing a mechanism.
resolve_dir keeps its `|| printf` because it makes every caller a plain
assignment, so no site can compare against an empty path by forgetting its
own fallback — the reason is now stated accurately.
Also from review: REPO_COMMON is now resolved on both branches, matching
REPO_ROOT, and _repo_root notes why it is already physical without its own
resolve_dir call.
These skills resolve the layout from the PATH launcher and Git, so how the
checkout was installed never enters the procedure. Describing install
shapes, the installer script, and its variables added detail a reader must
hold and would go stale whenever the installer changes.
Both skills now describe the observable state they resolve. The cases that
mattered survive as properties of that state: the main clone may sit
anywhere on any branch, and a launcher may link straight at a worktree with
no `current`.
DSH_SOURCE is an install-time shell variable the installer never exports, so
a skill reading ${DSH_SOURCE} at runtime reads nothing. Verified unset in a
running dsh process.
Git resolves the main clone identically for every install, so the curl-vs-
adopted distinction was never a branch point in these workflows. Verified
one launcher-then-Git recipe against three shapes: a curl install cloning
into the container, an adopted clone nested far outside any container, and
a custom DSH_SOURCE container.
dsh-customize now states that single procedure and warns off the installer
variables. dsh-upgrade's Layout describes what the resolution finds rather
than a path convention, and no longer teaches install shapes as cases.
PR #1100 recorded the golden with the session-lineage navigation still in
the header; PR #1099 removed it. Master's snapshots job was skipped on the
combining merge, so the conflict first surfaced on the next PR's CI.
Both skills said to derive the main clone from the checkout without saying
how, and dsh-upgrade names dsh-customize as the owner of checkout discovery
— so the technique belonged there and was missing.
dsh-customize now gives it: `git rev-parse --git-common-dir` from the
checkout yields the shared git directory, whose parent is the main clone.
It also names the two ways to get this wrong — the answer is relative for a
plain clone, and paths must be compared physically, since macOS reaches
/var through a symlink to /private/var.
dsh-upgrade links to that procedure rather than restating it.
Verified against both shapes: an adopted clone outside the container, and a
curl-shaped install whose clone is at <source>/master.
"Master clone" named the repository after a branch it need not be on. An
adopted clone keeps whatever branch it had — verified: adopting a clone
checked out on a feature branch leaves it there — so the name was wrong for
every install that did not come from curl.
Renamed to "main clone" in dsh-upgrade and dsh-customize, describing its
actual role: the one real clone whose object store every worktree shares.
dsh-upgrade also now says not to assume the main clone sits on `master` or
that its `origin` is authoritative upstream, since an adopted clone may
point at a fork. The fetch itself was already correct: step 1 resolves
authoritative upstream separately, and step 4 fetches upstream `master`
from it rather than from the clone's own branch.
