* test(#1854): failing-first coverage for user-files-backup restore Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(#1854): offer restore for user-added files backed up on update Adds a restore-custom-files gsd-tools verb and wires it into update.md as a restore_custom_files step: plan, compatibility-check against the newly installed release, then restore only on explicit opt-in. The backup is never deleted, a shipped path is never overwritten, and a single unwritable entry does not abort the rest. Also drops the jq pipe from update-context field extraction (#2589 class, missed by that sweep) and repairs a broken code fence in docs/CLI-TOOLS.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#1854): reject symlinked restore destinations and backup roots Self-review of the restore path found two write-through holes: copyFileSync follows a symlinked destination, so a link planted at the restore target wrote outside the config dir with every ancestor still a real directory; and statSync on the backup root followed a link, letting the walk read arbitrary files and present them as the user's own backup. Both now lstat. Also marks the report's path/detail strings as untrusted data in update.md so the rendered step cannot carry instructions into the runtime model. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(#1854): move the update-context jq guard into the #2589 sweep update.md joins the AUDITED list rather than carrying a duplicate assertion in the backup-restore suite, and the guard gains a negative-proof companion so 'no jq pipe' cannot pass by the fields simply no longer being read. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#1854): validate manifest files map shape before trusting it Security review flagged that Object.keys on a non-plain-object files field yields numeric-index keys matching nothing, so the managed-path check dies silently while manifest_found still reports true. Shape, not just type (ADR-227): an array or scalar files map is now an unusable manifest. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#1854): size the restore prompt by eligible_count Spec review found the prompt was driven by entries.length, so a backup holding only blocked entries asked "Restore 1 file(s)?" when accepting would restore zero. The question now reads eligible_count, and an all-blocked backup reports its reasons instead of offering a choice that cannot be honored. The decline path names the resolved backup_dir rather than the bare directory name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(#1854): use t.skip on hosts without symlink support A bare return in a node:test body registers as a PASS, so the four symlink guards silently reported green on unprivileged Windows instead of skipping. Adds the dangling-link destination case the security review called out, and moves outside-dir teardown to t.after so a failing assert cannot leak it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#1854): unfence restore hint, regen goldens, widen install timeout Three gate failures from the c99d612a5 run, all root-caused: 1. capability-registry (3): update.md's decline message put an instructional 'gsd-tools ...' line in an UNTAGGED fence, and the guard treats untagged fences as shell blocks. Retagged both display blocks as text and switched the hint to the resolved 'node <config-dir>/.../gsd-tools.cjs' form users can actually paste. 2. golden-install-parity (19): update.md and gsd-tools.cjs ship, so every runtime fixture moved. Regenerated; the diff is exactly those two hashes per fixture, no other drift. 3. install.test.cjs (5): one real failure, four cascades. The Cursor suite's before hook died on 'spawnSync ETIMEDOUT' at the 60s cap while the node22 lane passed the SAME commit in 12.7s. A full install measures 13-30s idle, so 60s was under 2x headroom and shrinks with every file added to the payload. Raised to 120s, matching the heavy case already in this file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(#1854): backfill changeset pr number to 2679 --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -568,12 +568,58 @@ node gsd-tools.cjs commit <message> [--files f1 f2] [--amend] [--no-verify] [--r
|
||||
> `--no-verify`: Skips pre-commit hooks. Used by parallel executor agents during wave-based execution to avoid build lock contention (e.g., cargo lock fights in Rust projects). The orchestrator runs hooks once after each wave completes. Do not use `--no-verify` during sequential execution — let hooks run normally.
|
||||
> `--files <paths>` **staging behaviour**: by default, `--files` runs `git add -- <path>` for each named file before committing. This overwrites any per-hunk staging set up via `git add -p`. Pass `--respect-staged` to skip the `git add` step and commit only what is already in the index within the requested pathspec. If nothing is staged within that scope, the command returns `{ committed: false, reason: 'nothing staged' }` without error. The trailing `-- <paths>` pathspec on the commit is applied under both modes, so files staged outside the `--files` scope are never included (#3061 invariant).
|
||||
|
||||
```bash
|
||||
# Web search (requires Brave API key)
|
||||
node gsd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Update Backup and Restore
|
||||
|
||||
The two halves of `/gsd:update`'s user-added-file protection. `detect-custom-files`
|
||||
lists files that exist inside GSD-managed directories but are absent from
|
||||
`gsd-file-manifest.json` — the update workflow copies those into
|
||||
`gsd-user-files-backup/` before the clean-install wipe. `restore-custom-files`
|
||||
puts them back afterwards.
|
||||
|
||||
```bash
|
||||
# List user-added files the installer would destroy (JSON)
|
||||
node gsd-tools.cjs detect-custom-files --config-dir <config-dir>
|
||||
|
||||
# Plan a restore — reports what would be restored, writes nothing
|
||||
node gsd-tools.cjs restore-custom-files --config-dir <config-dir>
|
||||
|
||||
# Restore the eligible entries
|
||||
node gsd-tools.cjs restore-custom-files --config-dir <config-dir> --apply
|
||||
```
|
||||
|
||||
`restore-custom-files` emits one entry per backed-up file:
|
||||
|
||||
| Field | Meaning |
|
||||
|---|---|
|
||||
| `path` | Path relative to the config dir — where the file came from and goes back to |
|
||||
| `outcome` | `eligible` (plan mode) · `restored` · `skipped_destination_managed` · `skipped_destination_exists` · `skipped_copy_failed` · `skipped_unsafe_path` |
|
||||
| `warnings` | Advisory `{code, detail}` findings from the compatibility pass; never blocks a restore |
|
||||
|
||||
Warning codes: `destination_managed`, `destination_exists`,
|
||||
`missing_referenced_path`, `missing_referenced_command`,
|
||||
`frontmatter_missing_field`, `write_failed`.
|
||||
|
||||
The compatibility pass runs against the **newly installed** release, so it
|
||||
catches a backed-up skill that `@`-references a workflow the new version
|
||||
retired, invokes a `/gsd:` command that no longer exists, or is missing the
|
||||
`name` / `description` frontmatter its runtime needs.
|
||||
|
||||
Three things the restore never does: it never deletes the backup, it never
|
||||
overwrites a path the new release ships (`skipped_destination_managed`), and it
|
||||
never overwrites a different file already on disk
|
||||
(`skipped_destination_exists`). Symlinked backup entries are skipped outright
|
||||
rather than followed (`skipped_unsafe_path`). A single unwritable entry is
|
||||
reported and the remaining entries still restore.
|
||||
|
||||
---
|
||||
|
||||
## Worktree Commands
|
||||
|
||||
Diagnose and configure the worktree fork base used by Claude Code's `isolation="worktree"` executor dispatch. These commands address the branch-divergence condition described in [Fix the worktree base-mismatch (exit 42) error](how-to/fix-worktree-base-mismatch.md).
|
||||
|
||||
@@ -1352,6 +1352,20 @@ Update GSD with changelog preview, and optionally sync skills or reapply local p
|
||||
/gsd-update --next # Install from the @next RC dist-tag
|
||||
```
|
||||
|
||||
**Recovering your own files.** The update protects two different buckets, and
|
||||
they recover differently:
|
||||
|
||||
| Bucket | What it holds | How it comes back |
|
||||
|---|---|---|
|
||||
| `gsd-local-patches/` | GSD-shipped files **you modified** | `/gsd-update --reapply` (three-way merge) |
|
||||
| `gsd-user-files-backup/` | Files **you added** inside GSD-managed directories | The update offers a restore before it finishes |
|
||||
|
||||
When the backup is non-empty, the update lists what it saved, flags anything
|
||||
that may no longer be compatible with the release just installed, and asks
|
||||
whether to restore. Declining leaves the backup untouched — it is never
|
||||
deleted — so you can restore later with
|
||||
`gsd-tools restore-custom-files --config-dir <config-dir> --apply`.
|
||||
|
||||
---
|
||||
|
||||
## Code Quality Commands
|
||||
|
||||
@@ -945,6 +945,9 @@ continues. Drift detection cannot fail verification.
|
||||
- REQ-UPDATE-04: System MUST back up locally modified files to `gsd-local-patches/`
|
||||
- REQ-UPDATE-05: `/gsd-update --reapply` MUST restore local modifications after update
|
||||
- REQ-UPDATE-06: `/gsd-update --next` (alias `--rc`) MUST target the `@next` RC dist-tag for version check and install; omitting the flag MUST keep `@latest` behavior unchanged (ADR #660)
|
||||
- REQ-UPDATE-07: System MUST back up user-added files found inside GSD-managed directories to `gsd-user-files-backup/` before the clean install
|
||||
- REQ-UPDATE-08: When that backup is non-empty, the update MUST offer an explicit restore choice before finishing, and MUST leave the backup intact whichever way the user answers
|
||||
- REQ-UPDATE-09: A restore MUST NOT overwrite a path the newly installed release ships, MUST NOT overwrite a different file already on disk, and MUST report best-effort compatibility warnings for restored files without blocking on them
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -853,7 +853,16 @@ Set `commit_docs: false` during `/gsd-new-project` or via `/gsd-settings`. Add `
|
||||
|
||||
### GSD Update Overwrote My Local Changes
|
||||
|
||||
Since v1.17, the installer backs up locally modified files to `gsd-local-patches/`. Run `/gsd-update --reapply` to merge your changes back.
|
||||
Which recovery you need depends on whether you *modified a GSD file* or *added your own*:
|
||||
|
||||
- **You edited a file GSD ships** (an agent prompt, a workflow). Since v1.17 the installer backs it up to `gsd-local-patches/`. Run `/gsd-update --reapply` to merge your changes back.
|
||||
- **You added your own file inside a GSD-managed directory** (a custom skill under `skills/`, an extra file in `commands/gsd/`). The installer saves it to `gsd-user-files-backup/`, and the update offers to restore it once the new version is installed. If you declined, or the backup is left over from an older update, restore it any time:
|
||||
|
||||
```bash
|
||||
node <config-dir>/gsd-core/bin/gsd-tools.cjs restore-custom-files --config-dir <config-dir> --apply
|
||||
```
|
||||
|
||||
Run it without `--apply` first to see what would be restored. The backup is never deleted, and the restore skips any file that would overwrite something the new release ships.
|
||||
|
||||
### Install or Refresh a Release Candidate
|
||||
|
||||
@@ -956,6 +965,7 @@ To disable parallel execution entirely: `/gsd-settings` → set `parallelization
|
||||
| Plan doesn't match your vision | `/gsd-discuss-phase [N]` then re-plan |
|
||||
| Costs running high | `/gsd-config --profile budget` and `/gsd-settings` to toggle agents off |
|
||||
| Update broke local changes | `/gsd-update --reapply` |
|
||||
| Custom file gone after an update | `gsd-tools restore-custom-files --config-dir <dir> --apply` |
|
||||
| Want session summary for stakeholder | `/gsd-pause-work --report` |
|
||||
| Don't know what step is next | `/gsd-progress --next` |
|
||||
| Parallel execution build errors | Update GSD or set `parallelization.enabled: false` |
|
||||
|
||||
@@ -23,7 +23,8 @@ GSD will:
|
||||
5. Back up any user-added files found inside GSD-managed directories to `gsd-user-files-backup/`.
|
||||
6. Run the installer (`npx @opengsd/gsd-core@latest --<runtime> --<scope>`).
|
||||
7. Clear the update-check cache so the statusline indicator resets.
|
||||
8. Report whether locally modified GSD files were backed up to `gsd-local-patches/`.
|
||||
8. Offer to restore the user-added files it backed up in step 5.
|
||||
9. Report whether locally modified GSD files were backed up to `gsd-local-patches/`.
|
||||
|
||||
Restart your runtime after the update to pick up new commands and agents.
|
||||
|
||||
@@ -89,7 +90,31 @@ If the changelog cannot be fetched (no network access, npm outage), the update s
|
||||
|
||||
### Files you added inside GSD-managed directories
|
||||
|
||||
If you placed custom files inside directories that GSD owns (for example, custom agents prefixed with `gsd-` or extra files in `commands/gsd/`), the installer will detect them and copy them to `gsd-user-files-backup/` before wiping those directories. After the update, restore them manually from that backup location.
|
||||
If you placed custom files inside directories that GSD owns (for example, custom agents prefixed with `gsd-` or extra files in `commands/gsd/`), the installer detects them and copies them to `gsd-user-files-backup/` before wiping those directories.
|
||||
|
||||
After the new version is installed, the update offers to put them back. You get a list of what was backed up, then a choice:
|
||||
|
||||
- **Restore them now** — each file is copied back to its original location and the update reports what it restored.
|
||||
- **Leave them in the backup** — nothing is copied; the backup stays exactly where it is.
|
||||
|
||||
Either way the backup is **never deleted**, so declining is not destructive and you can restore later.
|
||||
|
||||
Before copying anything back, the restore runs a compatibility pass against the version that was just installed and attaches a warning to any file that looks like it may no longer work — one that references a workflow or `/gsd:` command the new release retired, or a skill missing its `name` / `description` frontmatter. Warnings are advisory: the file is still restored, with the warning shown next to it, so you can decide whether to fix it.
|
||||
|
||||
Two cases are skipped rather than restored, because restoring would destroy something:
|
||||
|
||||
- The new release now ships a file at that exact path (your custom file would overwrite GSD's).
|
||||
- A different file is already sitting at that path (restoring would overwrite your current version).
|
||||
|
||||
Both stay in the backup and are reported with the reason.
|
||||
|
||||
To restore later — or after an update where you declined — run the same operation directly:
|
||||
|
||||
```bash
|
||||
node <config-dir>/gsd-core/bin/gsd-tools.cjs restore-custom-files --config-dir <config-dir> --apply
|
||||
```
|
||||
|
||||
Drop `--apply` to preview what would be restored without writing anything.
|
||||
|
||||
Files you placed outside GSD-managed directories — custom agents not prefixed with `gsd-`, custom commands outside `commands/gsd/`, your `CLAUDE.md` files, and custom hooks — are never touched by the installer.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user