Pine/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases 1 Wiki Activity

docs(skills): drop installer details from the git workflows

Browse Source 
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`.
This commit is contained in:
Turtle
2026-07-31 22:35:27 +08:00
parent 8d62467823
commit 6e913fe8bb
2 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/dsh-upgrade/SKILL.md
+2 -2
View File
@@ -9,9 +9,9 @@ Prepare and validate the upgrade in a fresh staging worktree of the main clone,
## Layout
Resolve the layout, never assume it. [`dsh-customize`](../dsh-customize/SKILL.md) owns the procedure: follow the PATH launcher to the staging worktree, then derive the main clone from that checkout with Git. It resolves every install the same way, so this workflow needs no special case for how DSH was installed and never reads the installer's variables, which exist only while the installer runs.
Resolve the layout, never assume it. [`dsh-customize`](../dsh-customize/SKILL.md) owns the procedure: follow the PATH launcher to the staging worktree, then derive the main clone from that checkout with Git. One resolution covers every checkout, so this workflow needs no special case and depends on no environment variable.
The resolved layout is one container directory `<source>` holding each staging checkout as a git worktree `<source>/staging-<timestamp>` on branch `dsh-staging/<timestamp>`, plus the stable symlink `<source>/current` pointing at the active one; the PATH launcher links to `<source>/current/bin/dsh`, so it resolves PATH -> `current` -> staging worktree. The main clone is the one real clone whose object store every worktree shares, and is never a launcher target. It may live inside `<source>` or anywhere else on disk, on any branch, with remotes that may point at a fork — so treat it strictly as the object store and worktree host, and take authoritative upstream from step 1 instead. Cutover repoints `current` alone; the PATH launcher is written once at install and never moves. The main clone's `.git/info/exclude` is inherited by every linked worktree, so one `.agents/merge.lock` entry there excludes the lock in all of them. An older install may link PATH straight at a worktree with no `current`; the same resolution finds it, and cutover then creates `current` and repoints PATH to `current/bin/dsh` as a one-time migration.
The resolved layout is one container directory `<source>` holding each staging checkout as a git worktree `<source>/staging-<timestamp>` on branch `dsh-staging/<timestamp>`, plus the stable symlink `<source>/current` pointing at the active one; the PATH launcher links to `<source>/current/bin/dsh`, so it resolves PATH -> `current` -> staging worktree. The main clone is the one real clone whose object store every worktree shares, and is never a launcher target. It may live inside `<source>` or anywhere else on disk, on any branch, with remotes that may point at a fork — so treat it strictly as the object store and worktree host, and take authoritative upstream from step 1 instead. Cutover repoints `current` alone, so the PATH launcher itself never moves. The main clone's `.git/info/exclude` is inherited by every linked worktree, so one `.agents/merge.lock` entry there excludes the lock in all of them. When the launcher links straight at a worktree with no `current` in the chain, the same resolution finds it, and cutover creates `current` and repoints PATH to `current/bin/dsh` as a one-time migration.
## Names