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.
Adoption installs the master wherever the adopted clone already is, so
dsh-upgrade and dsh-customize can no longer state <source>/master as fact.
Both skills already derive the master from the launcher, so the procedures
hold; only the layout description was wrong. dsh-upgrade now names
`git rev-parse --git-common-dir` as the way to resolve it.
The legacy-migration clauses stay: installs made before this change can
still link PATH straight at a worktree.
Nothing read it. The launcher, dsh-upgrade, and the installer's own re-run
all ignored the file, and the diagnostic it was meant to feed was never
built, so it was write-only state.
Git already owns the fact it recorded: a staging worktree's .git file names
the repository path, and `git worktree list` in that clone enumerates every
worktree depending on it. An installer-written copy only adds state that can
go stale while nothing validates it.
The containment caveat it documented is real and stays in the script header
and the Agent Note, now pointing at git's own records.
The fork button on a stopped assistant message was inert. Frozen
interrupted nodes carry a flow-ordering seq of turnEnd.seq - 0.9, and
session.fork takes a non-negative integer on the wire, so every such
request was rejected as invalid-params before reaching the host — where
an aborted turn's logged turn/end has always made it forkable.
SessionsService.fork floors atSeq at the wire boundary. Flooring stays
inside the anchor's own turn (every turn opens with turn/start), so the
host's first-turn/end-at-or-after cut still closes on that turn.
Retaining link-in-place behind a prompt and DSH_ADOPT kept the divergent
install shape that this change exists to remove, and cost a flag, a prompt,
a dirty-tree warning, a no-commit fallback, and a second linking path.
In-repo mode now adopts unconditionally. A dirty tree adopts silently:
`worktree add` from HEAD cannot carry uncommitted work, so a prompt only
adds a decision the user cannot act on differently.
The original reason for link-in-place — keeping the script testable against
local source — survives adoption, since the staging worktree branches from
the checkout's HEAD and runs the same code. DSH_SOURCE remains the escape
hatch for installing a separate tree.
Net 47 fewer lines in the installer.
Running scripts/install.sh from a checkout linked `dsh` straight at that
checkout, producing an install that `dsh-upgrade` cannot upgrade (there is
no `current` to repoint), that dangles if the checkout moves, and whose
launcher resolves to an arbitrary working branch.
In-repo mode still never clones and never touches the working tree, but it
now offers to adopt the checkout, and adoption is the default. The container
owns staging worktrees and `current`; the repository is discovered via
`git rev-parse --git-common-dir` rather than owned, so a clone anywhere on
disk converges on the same upgradable layout as a curl install and both
share one worktree/exclude/lock/link sequence.
Declining, or DSH_ADOPT=0, keeps the previous link-in-place behavior with a
warning naming what it costs, preserving the path that makes this script
testable against local source.
All path comparisons run on physical paths: macOS resolves /var through a
symlink to /private/var, and comparing a resolved path against an unresolved
one misclassified an existing managed install as a foreign clone.
Verified manually (no install.spec.ts, per request) with a harness driving
the real script under a stubbed pnpm across 33 assertions, plus both
interactive outcomes under tmux.
