@opengsd/gsd-path 1.4.0 → 1.6.0

package/README.md

@@ -9,21 +9,29 @@ milestone loop. While a milestone builds, the next one can be planned in
 parallel under `.project/next/` (lookahead); a building milestone can also be
 abandoned on an explicit ruling, archiving its partial work for a re-slice.
 
-**Supported hosts:** Codex, Claude Code, Grok, OpenCode, GitHub Copilot CLI,
-Qwen Code, Antigravity CLI, Cursor, Zed, Kiro, and Kimi Code.
-Support means the installer and dispatch contract exist. See the
-[host trust matrix](https://github.com/open-gsd/gsd-path/blob/main/docs/trust-validation/HOST-MATRIX.md) for live milestone
-proof and each host's guard tier.
+**Hosts with a passing full live milestone for release 1.6.0:** Codex, Claude
+Code, Grok, OpenCode, Antigravity CLI, Cursor, and Kimi Code.
+
+**Hosts with an installer and a dispatch contract, but no live milestone for
+release 1.6.0:** GitHub Copilot CLI (account quota exhausted), Qwen Code, Zed,
+and Kiro (API credits), and Muse Code (no live release evidence recorded yet).
+These hosts are excluded from the release evaluation. Exclusion is not a pass.
+
+With guard hooks installed, only Claude Code and Cursor get a fail-closed
+native guard; every other host relies on Git hooks. The installer also writes a
+native Codex hook, and it runs only after you trust it (see [HOOKS.md](HOOKS.md)).
+The [host trust matrix](https://github.com/open-gsd/gsd-path/blob/main/docs/trust-validation/HOST-MATRIX.md)
+is the source of truth for live milestone proof and each host's guard tier.
 
 <!-- release-docs -->
-**Latest npm release:** [@opengsd/gsd-path@1.4.0](https://www.npmjs.com/package/@opengsd/gsd-path/v/1.4.0) — [release notes](CHANGELOG.md#140---2026-09-30)
+**Latest npm release:** [@opengsd/gsd-path@1.6.0](https://www.npmjs.com/package/@opengsd/gsd-path/v/1.6.0) — [release notes](CHANGELOG.md#160---2026-10-12)
 
 **Recent highlights**
-- key verify ledger rows by repo and fail closed on member drift (S3d)
-- guard coders in member sidecars with coordinator host hooks (S3c3b2)
-- dispatch and land member tasks in build rounds (S3c3b1)
-- activate member tasks with a live copy in the member sidecar (S3c3a)
-- prove landed member tasks from record and member landing (S3c2b)
+- let a later task supersede an earlier task and retire its Verify
+- document the default branch record of a member
+- member paths read the default branch that MEMBERS.md records
+- record the default branch of a member in MEMBERS.md
+- add --uninstall to the skill installers
 
 <!-- /release-docs -->
 
@@ -40,37 +48,31 @@ proof and each host's guard tier.
 | [WORKFLOW.md](WORKFLOW.md) | Phase-by-phase agent SOP |
 | [HOOKS.md](HOOKS.md) | Optional archive/git guard hooks |
 | [Jev screening](skills/gsd-path/references/jev-review.md) | Optional evidence screening; disabled by default, no SDK required |
-| [daemon/README.md](daemon/README.md) | Dashboard, menu-bar app, and monitoring setup |
-| [CHANGELOG.md](CHANGELOG.md) | Published release notes |
+| [daemon/app/README.md](daemon/app/README.md) | Desktop app: develop, release, and updates |
+| [daemon/README.md](daemon/README.md) | Monitor daemon: routes, configuration, and manual setup |
+| [CHANGELOG.md](CHANGELOG.md) | npm package release notes |
+| [daemon/app/CHANGELOG.md](daemon/app/CHANGELOG.md) | Desktop app release notes |
 | [RELEASE.md](RELEASE.md) | Maintainer CI and npm release cycle |
 | [GUIDE.md](GUIDE.md) | Pointer to the guides above |
 
-## What's new — September 19, 2026
+## What's new — October 2, 2026
 
 These changes are merged into the source checkout; npm installs use the latest
 published release.
 
-- **Dashboard settings and history:** edit Path settings, browse project files
-  and Git versions, and load full recorded evidence. See the
-  [dashboard guide](daemon/README.md#project-history-and-files).
-- **Model and effort policy:** set user, project, host, and task choices through
-  one resolver. Recorded assignments stay pinned; unsupported explicit choices
-  stop the affected dispatch. See the
-  [model policy](skills/gsd-path/references/model-policy.md).
-- **External worktrees and pinned runtimes:** new parallel task, verification,
-  and integration worktrees live outside project checkouts. Projects pin runtime
-  versions by content digest, with explicit upgrade, restore, and legacy migration
-  commands. See
-  [worktree locations](DOCS.md#worktree-locations) and
-  [runtime versions](DOCS.md#project-runtime-versions).
-- **Clearer project updates:** the dashboard shows project runtime versions and
-  update results. After verified integration, ordinary branches can resume
-  product work while archived milestones remain protected. See
-  [update guidance](UPDATE.md#update-the-project-runtime-and-guard-hooks).
-- **Optional Jev screening:** reviewers can request advisory checks of selected
-  criteria and evidence. It is disabled by default and never replaces recorded
-  verification or review gates. See
-  [Jev screening](skills/gsd-path/references/jev-review.md).
+- **Desktop app (pre-release):** one app for macOS, Windows, and Linux shows
+  your projects, manages skills in each coding agent, and updates itself. See
+  [Desktop app](#desktop-app).
+- **Skills from the published release:** the monitor installs skills from the
+  npm release, checks the download against the registry's sha512, and refuses
+  one that does not match. A release picker lets you stay on an older version.
+- **Safer monitor writes:** a monitor started by the app accepts changes only
+  with the app's local token, so another web page cannot change your setup.
+- **Environment editor:** edit a project's `.env` files with values masked and
+  a diff before each save.
+- **Usage charts:** tokens and cost per day, time per phase, tasks per wave,
+  and verify history. Missing data shows as missing, never as zero.
+- **Muse Code** is a supported host.
 
 ## Install from npm
 
@@ -126,7 +128,13 @@ contain newer changes.
 
 1. Open your project folder in your coding-agent host. Existing repositories
    need Git; GitHub repository creation and pull-request operations also need
-   an authenticated GitHub CLI (`gh`).
+   an authenticated GitHub CLI (`gh`). The default branch of `origin` can have
+   any name: Path records it at initialization and ships onto it. This guide
+   calls it `main`; see [default branch](WORKFLOW.md#default-branch).
+   Pull-request
+   shipping supports GitHub.com only. On GitLab, Gitea, or GitHub Enterprise
+   Server, use the [`external-landing` mode](WORKFLOW.md#integration) when
+   the default branch accepts merge requests only.
 2. Start or reload the host session so it discovers the installed skills.
 3. Invoke `$path` in Codex, or `/path` on slash-command hosts. The router
    identifies the project and guides you through the required inputs and approvals.
@@ -157,65 +165,71 @@ project settings. Dashboard users can open **Settings → Path settings** for th
 same shipping, model/effort, and future review-panel controls. See
 [Path settings](skills/gsd-path/references/config.md) for precedence and locks.
 
-## Dashboard and menu-bar toolbar
-
-The optional **OpenGSD Path monitor** shows your projects without opening each
-project's `.project/` files. It watches the folders you choose and reads project
-state without advancing phase gates. Explicit Path settings saves use the
-validated configuration helper; background monitoring remains read-only.
-The monitor is a separate install from the npm skills package.
-
-### Dashboard
-
-The project board shows blocked, active, and shipped work, with milestone and
-phase progress, task counts, last activity, and available usage data. Use the
-[dashboard controls](daemon/README.md#dashboard) to filter or search projects,
-switch between Board and Milestones, refresh status, and manage settings.
-
-![OpenGSD Path project board showing sample projects, status filters, milestone progress, tasks, and usage](docs/images/dashboard-board.png)
-
-Click a project to see its milestone roadmap, tasks, success criteria, review
-results, verification history, and activity. Usage includes tokens and turns
-from supported host session logs; cost estimates require model prices in the
-daemon configuration.
-
-![Project dashboard showing the history viewer link, milestone progress, expandable evidence, and usage with sample data](docs/images/dashboard-project.png)
-
-*Dashboard screenshots captured on September 19, 2026, using the repository's
-sample projects; the current project folder layout may differ.*
-
-Open **History & files** to browse project files and archived milestones,
-preview Markdown, or read a file at a selected Git commit. Relative document
-links keep that selected version. **Records & sources → Load full records**
-loads recorded usage, verification, activity, and indexed host turns on demand,
-with coverage details that make missing or invalid data visible.
-
-Open **Settings → Path settings** to change user defaults or project overrides
-for shipping mode, model and effort choices, and future review panels. Each
-setting shows its source and any lock reason; changes are saved explicitly.
-
-The **Plugin** settings page shows each watched project's runtime version and
-provides an explicit **Update** action with progress and failure details.
-Updating global skills does not update a project's pinned runtime.
-
-### macOS menu bar
-
-Click the OpenGSD Path menu-bar icon for a compact project list with phase
-meters and task progress. Click a project to open its dashboard page. The
-bottom toolbar opens the dashboard, plugin settings, and watched folders;
-it also provides rescan, appearance, and quit controls. The daemon row shows
-its running state and provides restart and stop controls. Option-click the
-menu-bar icon to open the dashboard directly.
+### Uninstall
 
-<img src="docs/images/macos-menu-bar.png" alt="OpenGSD Path native macOS panel with sample projects and its bottom toolbar" width="400">
-
-*The native panel screenshot uses sample project data and was captured in its
-preview window; the current folder layout may differ.*
-
-### Install the monitor
+```bash
+npx @opengsd/gsd-path@latest --uninstall --all --dry-run
+npx @opengsd/gsd-path@latest --uninstall --all
+```
 
-The monitor requires Python 3.9+. From a source checkout, preview the setup,
-then install (macOS/Linux shell):
+`--uninstall` removes the installed GSD Path skills from the selected hosts.
+For Cursor it also removes the GSD Path subagent file. Use host flags instead
+of `--all` to select hosts. For project-local skills, run the command from
+your project directory and add `--local`. `--dry-run` shows each path and
+removes nothing.
+
+The command removes only GSD Path skills. It keeps other skills, host
+settings, and `disabled-gsd-skills` backups. It makes no backup: changes that
+you made in a GSD Path skill directory are lost. It does not remove project
+contracts or hooks (`.project/`, `.gsd-path/`, the `AGENTS.md` block, guard
+hooks). See [Uninstall skills](UPDATE.md#uninstall-skills).
+
+## Desktop app
+
+The **OpenGSD Path app** shows your projects without opening each project's
+`.project/` files, and manages the Path setup on your computer. It is a
+pre-release for testers.
+
+**Get it:** download the installer for your system from the newest `app-v`
+entry on the [releases page](https://github.com/open-gsd/gsd-path/releases):
+`.dmg` (macOS, Apple Silicon or Intel), `.msi` (Windows), `.deb` or AppImage
+(Linux). The app needs Python 3.9+ and Git; its first screen checks for both
+and shows the fix when one is missing.
+
+macOS builds are signed with a Developer ID and notarized by Apple from 0.1.1
+on, so they open without an approval in Privacy & Security. Windows builds have
+no code signature yet: SmartScreen shows a warning; choose **More info → Run
+anyway**.
+
+What the app does:
+
+- **Projects:** blocked, active, and shipped work with milestone and phase
+  progress, tasks, last activity, and usage. A project page shows its
+  roadmap, tasks, success criteria, reviews, verification history, files at
+  any Git version, and full recorded evidence.
+- **Skills:** which coding agents have Path skills, at which version, with
+  preview, install, update, and uninstall. Every write shows a preview or a
+  plan first.
+- **Project setup:** runtime version, guard hooks, health check, and, for a
+  multi-repo coordinator, member hooks and marker repair.
+- **Settings:** updates, Path settings (shipping mode, models, review panel),
+  watched folders, model prices, launch at login, and appearance.
+- **Stats** and the per-project **Environment** editor.
+- **Tray:** a compact project list, items that need attention, and controls
+  to start, restart, and quit.
+
+The app only watches and sets up. It never advances a phase; approvals and
+rulings stay in your agent. It updates itself: it checks a signed update file,
+asks before it installs, and refuses an update whose signature does not match.
+
+Background monitoring is read-only. The app starts a local monitor (the
+daemon) and stops it on quit. See the [app guide](daemon/app/README.md) and the
+[daemon guide](daemon/README.md).
+
+### Manual monitor (without the app)
+
+From a source checkout you can still run the monitor and its browser
+dashboard without the app. It requires Python 3.9+:
 
 ```bash
 git clone https://github.com/open-gsd/gsd-path.git
@@ -224,33 +238,20 @@ PYTHONPATH=daemon python3 -m gsd_daemon install --dry-run
 PYTHONPATH=daemon python3 -m gsd_daemon install
 ```
 
-On Windows, after cloning and entering `gsd-path`, use PowerShell:
+On Windows, use PowerShell in the `gsd-path` folder. The last command starts
+the monitor for this session; it starts by itself at later logins:
 
 ```powershell
 $env:PYTHONPATH = "daemon"
 python -m gsd_daemon install --dry-run
 python -m gsd_daemon install
-```
-
-On Windows, launch the installed shortcut for this session before opening the
-dashboard. It starts automatically at future logins:
-
-```powershell
 Start-Process "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\gsd-path-daemon.lnk"
 ```
 
-Open **http://127.0.0.1:8765**, then use **Settings → Watched folders** to add
-your project folders. The installer creates an isolated Python environment and
-configures autostart. On macOS it also builds and installs the native menu-bar
-app; this requires macOS 12+ and Xcode Command Line Tools (`swiftc`). On
-macOS, use `--no-tray` for the dashboard only. Linux autostart runs the
-dashboard; launch the optional tray separately with
-`~/.gsd-path/venv/bin/gsd-path-daemon tray`. Windows uses a tray-and-dashboard
-Startup shortcut; see the [daemon guide](daemon/README.md) for platform details.
-
-See the [daemon guide](daemon/README.md) for configuration, usage pricing,
-manual startup, and platform setup, or the [macOS guide](daemon/macos/README.md)
-for native menu-bar details.
+Then open **http://127.0.0.1:8765**. The first launch of the desktop app
+removes this older autostart entry so only one monitor runs. See the
+[daemon guide](daemon/README.md) for platform details, configuration, and
+usage pricing.
 
 ## Skills
 
@@ -390,12 +391,30 @@ partial remote/clone/worktree transaction; the default checkout stays clean.
 One project can change several repositories in the same milestone. The
 **coordinator** repo holds `.project/` and runs the pipeline; each other repo
 is a **member** listed in `.project/MEMBERS.md`. A member needs a GitHub.com
-`origin` whose default is `main`. See
+`origin`. Its default branch can have any name, and it can differ from the
+default branch of the coordinator and of the other members. See
 [ADR 0002](docs/adr/0002-multi-repo-coordinator.md) for the design.
 
+`MEMBERS.md` has one section per member, in ship order. `members.py` writes
+it; do not edit it by hand:
+
+```markdown
+## web
+Checkout: /absolute/path/to/web
+Remote: https://github.com/acme/web.git
+Integration: default
+Default branch: master
+```
+
+`Default branch` is the member's default branch on `origin`. `members.py add`
+records it one time, from the member's local `origin/HEAD`; run
+`git remote set-head origin --auto` in the member first. A section without
+the field means `main`. See [default branch](WORKFLOW.md#default-branch).
+
 - Add members at a milestone boundary: ask the router to add an existing repo
   (`members.py add`) or to create a new one (`members.py add --create`, after
-  you approve the exact owner, name, visibility, and checkout). For optional
+  you approve the exact owner, name, visibility, and checkout; a new
+  repository uses `main`). For optional
   guard hooks, install them in the member with
   `npx @opengsd/gsd-path@latest --member-of <coordinator> --project <member>`.
 - The planner gives each member task `repo: <member>`; one task changes one
@@ -470,11 +489,12 @@ node scripts/install.mjs --all --local
 node scripts/install.mjs --all --project /path/to/project
 node scripts/install.mjs --update
 node scripts/install.mjs --all --update --project /path/to/project   # refresh .gsd-path/; keeps contracts
+node scripts/install.mjs --uninstall --all --dry-run                 # preview; removes skills only
 ```
 
 | Flag | User skills root | Invoke |
 | --- | --- | --- |
-| `--codex`, `--zed` | `~/.agents/skills` | Codex: `$path` or `$gsd-path`; Zed: `/path` or `/gsd-path` |
+| `--codex`, `--zed`, `--muse` | `~/.agents/skills` | Codex: `$path` or `$gsd-path`; Zed, Muse: `/path` or `/gsd-path` |
 | `--claude` | `~/.claude/skills` | `/path` or `/gsd-path` |
 | `--cursor` | `~/.cursor/skills` (+ subagent) | `/path` or `/gsd-path` |
 | `--grok` | `~/.grok/skills` | `/path` or `/gsd-path` |
@@ -489,7 +509,7 @@ OpenCode stable: ask to load and use the `gsd-path` skill.
 `gsd-path` remains the canonical router name; `path` is its short menu alias.
 For a single phase, use `$gsd-path-plan` in Codex or `/gsd-path-plan` on slash hosts.
 
-`scripts/install.py` — Python install, including `--local` and `--update`.
+`scripts/install.py` — Python install, including `--local`, `--update`, and `--uninstall`.
 The Node CLI remains the interactive and npm entry point. See [FULL.md](FULL.md) and
 [UPDATE.md](UPDATE.md) for `--hooks`, `--hooks-refresh`, `--local`, and host notes.
 

package/RUNTIME.md

@@ -23,7 +23,7 @@ inputs, receipt handling, and entry conditions are owned by the
 | `gate-plan` | Git HEAD; optional lookahead project directory | Pending discussion, intent coverage, brief paths, and panel configuration checked in order. |
 | `approve-plan` | Owner approval and `--expected-head <reviewed full SHA>` | Plan gates followed by the existing journaled approval checkpoint. |
 | `lint-round` | Git HEAD; optional `--project-dir .project/next` | Task brief checks against HEAD, then plan handoff checks. |
-| `prepare-task` | `--expected-head <clean base> --task-id <id> --round-size <ready task count>` | Canonical task isolation; serial work also gets a verification sidecar before the primary becomes dirty. |
+| `prepare-task` | `--expected-head <clean base> --task-id <id> --round-size <ready task count>` | Canonical task isolation; serial work also gets a verification sidecar before the primary becomes dirty. A verification sidecar that an earlier `prepare-task` left for the task is retired first only when it is proven untouched: its branch did not move from its creation base on the bound branch, and it has no tracked change and no untracked or gitignored file. Any other sidecar stays, and the command stops with its path and what was found. |
 | `build-evidence` | `--expected-head <full SHA>` | Canonical landing proof written to `<project-dir>/build/evidence.json` (default: `.project/build/evidence.json`). |
 
 Plan approval recovery remains `pipeline_state.py resume-checkpoint`. Pre-Git
@@ -68,7 +68,7 @@ skeptic attempts under `skeptics/`.
 | `skeptics --repo <root> --wave <N> --cycle <C> --child-command '<cmd>' [--wait <s>] [--child-timeout <s>]` | Step 7 skeptic branch: one read-only skeptic per `skeptic_groups` locator in its own sidecar at the recorded review base, briefed with the criterion, every observation, and the cited tasks verbatim; validate with `review_findings.py`, collect, retire, then rerun the helper. `none` without skeptic groups; `escalate` for structural blockers or the cycle cap. The skeptic files stay uncommitted for the fix-task or ruling checkpoint. |
 | `fix-tasks --repo <root> --wave <N> --cycle <C>` | Step 7 batching: one fix task per `review_findings.py collect` batch with the failed criteria and observations verbatim, lint-checked; `escalate` for structural blockers, skeptic groups, cycle cap, or all-refuted. |
 | `complete --repo <root>` | Completion: clean primary at `build/active` (or a crash-left `build/done`), no unfinished wave, the archive-time review cycle check (`discussion_validate.review_cycle_counts`: contiguous cycles, passing last cycle, panel and skeptic artifacts present); `workflow_run.py build-evidence` at HEAD; `pipeline_state.py transition` to `ship/active` with event `build done; final review pending`; checkpoint `build: complete milestone`. |
-| `finish --repo <root> --task-id <id>` | Recover first; return a proven landing without repeating Verify, or verify, land, record, and retire one returned task. Without a dispatch record, or when the newest record is settled and its base differs from the task's current in-progress base (a native retry after a driver block), read the primary task's in-progress state; if it lacks a recorded base, use the parallel task isolate's state only if that worktree is authorized. A blocked record at the same base still refuses the retry. A deactivated isolate stays blocked. |
+| `finish --repo <root> --task-id <id>` | Recover first; return a proven landing without repeating Verify, or verify, land, record, and retire one returned task. Without a dispatch record, or when the newest record is settled and its base differs from the task's current in-progress base (a native retry after a driver block), read the primary task's in-progress state; if it lacks a recorded base, use the parallel task isolate's state only if that worktree is authorized. A blocked record at the same base still refuses the retry, except a host-dispatched record (no child command) while the task is still in progress at that base: `finish` may run again after a failed Verify. A deactivated isolate stays blocked. |
 | `answer --repo <root> --task-id <id> --answer '<text>'` | Append `Orchestrator answer:` to the isolate's task Log; the next `round` redispatches that isolate. |
 | `status --repo <root>` | Every task's newest dispatch record. |
 
@@ -91,10 +91,17 @@ argument slots defined in the dispatch model policy.
 calls. In `round`, an unfinished earlier wave blocks dispatch before the bookkeeping
 checkpoint. Child completion is recorded in `exit.json`; the parent alone
 writes `state.json`.
-For `review`, `panel`, and `skeptics`, when the child process is gone and `finished_at` is
+For `round`, `review`, `panel`, and `skeptics`, when the child process is gone and `finished_at` is
 unset, the driver rereads that attempt's state and exit receipt before
 collecting the result or blocking with
 `child wrapper exited without recording a result`.
+A landing is final when the removal of its isolate fails: the receipt reports
+the task as landed with a `cleanup_warning`, and the next `round` or `finish`
+checks the isolate again. When only a leftover of a landed task's isolate
+remains and it holds nothing that Git does not have, the driver stops with
+`task <id> is landed; remove its leftover isolate: <path>`, changes neither
+STATE nor HEAD, and never deletes the path itself. Every other isolate error
+keeps its recovery block.
 Review starts from a clean base. A same-cycle retry may dispatch a missing lens
 at that unchanged base while verified, already-collected review artifacts remain
 uncommitted. Altered artifacts or unrelated changes block recovery.
@@ -127,7 +134,15 @@ with `another dispatch_driver invocation holds the lock`; wait for the
 active call to return before retrying. Bookkeeping also blocks if an
 in-progress primary task has no open dispatch record.
 
-Verify output is saved in `verify.json`. A `verify-record` ledger entry is
+Verify output is saved in `verify.json`. `finish` also runs the Verify of each
+earlier-wave task that shares a file with the task, under the
+[wave loop](skills/gsd-path/references/build-native.md#wave-loop) rule; those
+runs are saved under `regressions` and a failure blocks the landing. A Verify
+that a `supersedes` field retires does not run; it is listed under `retired`. A fix
+task Verify that loses only the copy of a retired Verify has a `retired` entry with
+the key `part` (the superseded task) and the Log entry `orchestrator regression
+Verify of <fix task id>: part of <task id> retired: superseded by <task id>`. A task
+with a `Heavy: yes` regression Verify counts as heavy. A `verify-record` ledger entry is
 written only when the landing commit's parent equals the recorded task base;
 a later parallel landing can therefore have no ledger entry.
 
@@ -174,8 +189,11 @@ through its receipt only when the canonical file matches the saved hash.
 
 `fix-tasks` reconciles existing repair tasks and PLAN rows before linting and
 checkpointing. It creates missing batches in an appended repair wave and
-reports new tasks in `created`, reused tasks in `existing`, and batches already
-covered by other repair tasks in `carried`. Status `created` includes restored
+reports new tasks in `created`, reused tasks in `existing`, and batches that
+other repair tasks not yet `done` cover in the same repo in `carried`. A member
+batch and its task carry `repo`. A fix task for a finding that repeats after
+its fix landed also depends on that landed fix task, so
+`review_findings.py repair-evidence` can link the two. Status `created` includes restored
 PLAN rows or pending project bookkeeping; `exists` means nothing was written
 and no project changes needed a checkpoint. Status `none` means no batches
 need work; `escalate` leaves the named decisions with build step 7 and the user.

package/UPDATE.md

@@ -176,9 +176,10 @@ a global update does not update project runtimes. Use the project's **Update**
 button to refresh its runtime and existing guards. Install and update actions
 show progress, success or failure, and installer output.
 
-If the daemon's plugin source checkout has local changes, project Update uses
-that local build and says so in its result. It does not pull remote changes over
-local edits. Clean source checkouts still refresh before a project update.
+Project Update refreshes the daemon's plugin source first. With the
+[git source](daemon/README.md#plugin-lifecycle), a clone that has local changes
+is used as that local build, and the result says so. It does not pull remote
+changes over local edits.
 
 Older unstamped installs show **Unknown — version metadata unavailable**.
 This does not establish that their runtime is outdated or broken. **Update**
@@ -272,6 +273,41 @@ Unrecognized or foreign `.project/` state is never auto-migrated — the router
 
 ---
 
+## Uninstall skills
+
+```bash
+npx @opengsd/gsd-path@latest --uninstall --all --dry-run
+npx @opengsd/gsd-path@latest --uninstall --all
+```
+
+From a git clone, use `node scripts/install.mjs` with the same flags.
+
+- Select the hosts with host flags or `--all`. A selection is necessary.
+- Add `--local`, from the project directory, for project-local skills.
+- `--dry-run` lists each path and removes nothing. A real run lists each
+  removed path.
+- A host that has no GSD Path skills shows `nothing to remove`. This is not an
+  error. A second run removes nothing.
+
+**Removed:** skill directories that GSD Path owns, and Cursor's
+`agents/gsd-path.md`. A directory is owned when it has a GSD Path name
+(`gsd-path`, `gsd-path-*`, the legacy `ogsd` names, or the `path` alias) and
+contains a `VERSION` file or a `SKILL.md` that names `gsd-path`. The `path`
+alias must also pass the ownership rule in
+[What auto-updates](#what-auto-updates). A directory with a GSD Path name
+that is not owned shows as `kept` and stays in place.
+
+**Not removed:** other skills, host settings, `disabled-gsd-skills` backups,
+and all project files: `.project/`, `.gsd-path/`, the `AGENTS.md` block, and
+guard hooks. `--uninstall` with `--project`, `--update`, `--doctor`, or a hook
+or runtime flag stops with an error.
+
+Removal makes no backup. Changes that you made in a GSD Path skill directory
+are lost. Codex, Zed, and Muse use one skills root (with `--local`, also
+Antigravity): an uninstall for one of them removes the skills for all of them.
+
+---
+
 ## Troubleshooting
 
 | Symptom | Fix |

package/WORKFLOW.md

@@ -161,7 +161,8 @@ Owned state routes by STATE.md without rerunning the helper. Reserve `classify`
 for read-only inspection; do not re-derive a verdict from a directory listing.
 
 For a newly initialized existing Git repository, the state router returns
-`bind-initial` while `STATE.branch` is null. The router fetches `origin/main`,
+`bind-initial` while `STATE.branch` is null. The router fetches the recorded
+[default branch](#default-branch) (`origin/main` in this document),
 runs `pipeline_git.py bind-initial` with that exact SHA, and records the
 returned `gsd-path/M00N` binding through `pipeline_state.py transition` before
 entering inspect or define. Build consumes this binding and never creates or
@@ -223,6 +224,20 @@ vetoes and corrections verbatim. Unresolved items remain tagged `RESEARCH` or
 first and presented as settled coverage for correction; the interview covers
 only its gaps and contradictions.
 
+Once the success criteria are drafted, define runs the spec-reach probes
+([spec-probes.md](skills/gsd-path/references/spec-probes.md)). The edge probe
+walks each criterion through a closed edge taxonomy (boundary, adjacency,
+empty, encoding, ordering, precision, idempotency, concurrency) and records
+the user's ruling per applicable edge in INTENT.md `## Edge coverage`:
+`criterion SCn` (stated in a success criterion), `held-out` (a named test
+pins it), or `dismissed` with a reason. The prohibition probe asks what each
+criterion must never silently become and records kept items in
+`## Prohibitions` as `criterion SCn`, `judgment`, or `dismissed`. Define
+never rules on an edge itself. `scripts/check_handoffs.py intent` checks
+both tables before every approval question, and the `define/done` transition
+refuses an intent whose tables are incomplete. An INTENT.md without these
+sections predates the probes and is not rechecked.
+
 At approval define classifies the milestone lane in INTENT.md: `quick`
 when scope fits at most two deliverable-sized tasks in one wave with no open
 questions and no cross-wave risk; otherwise `standard`. Milestone mode — a
@@ -343,6 +358,9 @@ by — which that task must own, in the same wave as the capability behind it.
 `check_handoffs.py final` then requires each of those criteria to name its
 surface in FINAL.md with the walkthrough as its Check, so a surface criterion
 cannot be marked `met` on internal test output.
+Every `held-out` edge gets a PLAN.md `## Held-out checks` row naming the task
+and test file; that test is in the task's files, its Verify runs it, and its
+Acceptance criteria state the edge id and ruling.
 `scripts/check_handoffs.py plan` gates the table; `wave` and `final`
 require a verdict per owned SC id. Acceptance criteria,
 owned SCs, and Verify are the contract; the coder owns
@@ -417,7 +435,11 @@ surface walkthroughs, in its existing review. The runtime proves freshness and
 generates FINAL.md from that record. Dispatch an integration reviewer only when
 that proof is incomplete or stale; dispatch gap reviewers only for uncovered
 cross-wave risks through the shared capacity-aware contract. The integration reviewer marks each success
-criterion `met`, `not-met`, or `unverifiable` with checked evidence. Each gap
+criterion `met`, `not-met`, or `unverifiable` with checked evidence. A criterion
+tagged by a `held-out` edge or `judgment` prohibition is `met` only when its
+evidence cites every tag id; otherwise the reviewer records `unverifiable`
+(insufficient spec evidence) and `check_handoffs.py final` refuses a `met`
+that skips a tag. Each gap
 reviewer records `pass` or `blocked` for its assigned end-to-end or cross-wave
 risk. List only genuine
 risks that could plausibly fail; never pad the list. The runtime
@@ -519,6 +541,49 @@ the subject and field body defined by its canonical phase contract; task-land
 fields live only in the
 [build contract](skills/gsd-path-build/SKILL.md).
 
+### Default branch
+
+Path ships onto the default branch of `origin`. The name is not fixed.
+`detect_project.py initialize` reads the local `refs/remotes/origin/HEAD` one
+time and records the name in `STATE.md` as `default_branch`; an unset
+`origin/HEAD` records `main`. Run `git remote set-head origin --auto` before
+the first Path run so that the record is the default branch of the forge. A
+`STATE.md` without the field means `main`, so older projects do not change.
+
+This document writes `main` and `origin/main` for the recorded default branch.
+In a project that records `master`, read them as `master` and `origin/master`:
+the integration merge subject ends with `into master`, and the user's merge
+request in `external-landing` mode targets `master`.
+
+The record does not change after initialization. Bind, integrate, validate,
+promotion, and the git guard read it. When the forge default no longer agrees
+with the record, integration stops with `remote default must be <recorded>`.
+A lookahead `next/STATE.md` must carry the same `default_branch` as the active
+state, or promotion stops. Names in the reserved `gsd-path/`,
+`gsd-path-integrate/`, and `gsd-path-task/` namespaces, and names with `#` or
+a quote character, cannot be recorded.
+
+In a multi-repo project, each repository has its own record. The coordinator
+records its default branch in `STATE.md`, as above. `members.py add` reads the
+local `refs/remotes/origin/HEAD` of the member one time and records the name
+in the member's section of `.project/MEMBERS.md`, as `Default branch: <name>`;
+an unset `origin/HEAD` records `main`. Run `git remote set-head origin --auto`
+in the member before you add it. A section without the field means `main`, so
+an older `MEMBERS.md` does not change. The members of one project can have
+different default branches, and the coordinator default can differ from them.
+The same name rules apply.
+
+Build start, the task brief check, undo, the member pre-push guard, and member
+close read the member record. The member bound branch starts at
+`origin/<recorded>`, the member merge subject ends with `into <recorded>`, and
+a member pull request targets `<recorded>`. When the remote default of the
+member no longer agrees with the record, `members.py validate` and member
+close stop with `remote default must be <recorded>`.
+
+Not supported: a new repository that Path creates uses `main`. This includes
+`members.py add --create`, which stops when the new repository has another
+default branch.
+
 ### Integration
 
 After the postcommit validator passes, ship performs integration — the only
@@ -527,14 +592,15 @@ receives merges or back-merges, and the default checkout is never entered;
 the local default branch ref may lag origin, which is harmless because
 binding resolves remote SHAs. `STATE.integration_default` stores the project
 choice and `STATE.integration` stores the current milestone choice. Both are
-`direct` or `pull-request`; they may change only before build, and the current
+`direct`, `pull-request`, or `external-landing`; they may change only before build, and the current
 milestone resets to the project default at the next handoff. Older v2 state
 without these fields means `direct`. `STATE.integration_source` is `default` or
 `milestone` so an explicit override remains distinct when its value happens to
 match the project default.
 
 Ship fetches origin, refreshes `origin/HEAD`, mirrors published milestone tags,
-and requires the remote default to be `main`. It then follows the locked mode:
+and requires the remote default to be the recorded
+[default branch](#default-branch). It then follows the locked mode:
 
 - `direct` creates a temporary named worktree (`gsd-path-integrate/M00N`) at
   the fetched remote-default SHA and merges the ship commit with `--no-ff`
@@ -550,6 +616,16 @@ and requires the remote default to be `main`. It then follows the locked mode:
   never enables auto-merge or merges the PR. After validation, Path creates the
   annotated milestone tag. The [ship contract](skills/gsd-path-ship/SKILL.md)
   owns the candidate, provenance, topology, publication, and recovery rules.
+- `external-landing` is for an origin that is not GitHub.com, such as GitLab,
+  Gitea, or GitHub Enterprise Server, where a merge request is the only route
+  to `main`. It needs no forge CLI. Path publishes the bound branch at the
+  exact ship commit, does not push `main`, and returns `awaiting-merge` with
+  the required merge subject and body. You open the merge request in your
+  forge (for example with `glab`), let your pipeline run, and merge it with a
+  merge commit that has exactly that message. Do not squash, rebase, or
+  fast-forward. Your forge may delete the source branch after the merge. On
+  the next ship invocation, Path validates the two-parent merge on `main` and
+  creates the annotated milestone tag.
 
 Ship leaves the primary worktree and `STATE.branch` on the shipped local
 `gsd-path/M00N`; the router owns the later branch handoff. NNN always comes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@opengsd/gsd-path",
-  "version": "1.4.0",
+  "version": "1.6.0",
   "description": "Disk-backed AI agent pipeline. Docs: DOCS.md (start here), QUICK.md, FULL.md, UPDATE.md",
   "license": "MIT",
   "repository": {
@@ -77,7 +77,9 @@
     "skills/",
     "platforms/",
     "AGENTS.md",
-    "WORKFLOW.md"
+    "WORKFLOW.md",
+    "!**/__pycache__/**",
+    "!**/*.pyc"
   ],
   "engines": {
     "node": ">=18.17"
@@ -85,6 +87,7 @@
   "scripts": {
     "install:ci": "npm ci",
     "check:prereqs": "node scripts/dev/check-prereqs.mjs",
+    "check:locks": "node scripts/dev/py.mjs scripts/check_lock_usage.py",
     "test": "node tests/run-node-tests.mjs",
     "test:smoke": "npm test",
     "test:integration": "npm run test:python",