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.
The timeout promise's executor runs synchronously while the race is
constructed, so the timer is always assigned; the undefined check was a
dead branch the per-file coverage gate rejected.
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.
The PTY capture does continue past the terminal-takeover bytes with the
fatal diagnostic; only the reset never follows. State that precisely in
both notes.
Document on FailLoudProcess.exit that callers treat it as the end of the
run, matching how the release path already relies on it.
Review of the previous commit found two defects in the release path, both
reproduced against the implementation:
- The timeout guarding a never-settling release was unref'ed. An
unhandledRejection listener suppresses Node's default fatal exit, so with
nothing else referenced the process reached an empty event loop and exited
0 on the very failure it was reporting. Keep the timer referenced and clear
it once the race settles.
- The handler uninstalled itself before awaiting the release. A second
concurrent rejection then became uncaught and killed the process
mid-teardown, stranding exactly the terminal state this restores. Replace
the uninstall with a latch: the first rejection is the reported one, and
later rejections (teardown's own included) fall through to the pending exit.
Add the PTY regression the fake-process tests cannot express: boot the shipped
tree over a fixture whose llm-pi-ai providers value is list-shaped, expect exit
1, and assert the captured bytes carry both the diagnostic and ESC[?2004l.
Against the pre-fix source the stream ends at ESC[?2004h ESC[>7u ESC[?u ESC[c
with no reset and the case fails, so it pins the actual bug.
Split the two-shape formatting test into one install per case; a latched
handler reports once by design.
A dsh launch whose config failed validation returned the user to a broken
shell: typing was invisible and the next command was mangled by a stray
Device Attributes reply (1;2;4cecho ...).
The Loader mounts entries concurrently, so ui-tui can already hold the
terminal (raw mode, bracketed paste, keyboard protocol, plus an in-flight
DA query) when a sibling entry rejects on its own config. installFailLoud
wrote its diagnostic and exited immediately, so nothing disposed the tree
and ProcessTerminal.stop() never ran.
Give installFailLoud an optional release teardown, awaited between the
diagnostic and the exit and bounded by FAIL_LOUD_RELEASE_TIMEOUT_MS. The
TUI launcher passes one that disposes the root context, reaching the same
shutdown() the /exit path already uses (drainInput() + ui.stop()). The
context is captured in boot()'s prepare hook because the rejection arrives
while boot() is still in flight.
Bins that pass no release keep the previous behavior exactly.
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.
