context-restore reports NO_CHECKPOINTS in non-git dirs: save/restore compute different project slugs #2163

Summary

/context-restore reports NO_CHECKPOINTS for a checkpoint that exists, when the working directory is a non-git directory (e.g. running straight from $HOME). Root cause: the project slug is computed two different ways between the save side and the restore side, so each reads/writes a different ~/.gstack/projects/<slug>/checkpoints folder.

This has bitten me three separate times from the same home-folder workflow. Work done inside real project dirs (with a git remote) is unaffected — those get a stable slug from the remote URL.

Environment

• gstack 1.58.5.0
• macOS (Darwin 25.5.0)
• Working dir: $HOME (/Users/<you>), not a git repo

Repro

1. From a non-git directory (e.g. your home folder), run a skill that saves a checkpoint (/context-save).
2. Later, from the same directory, run /context-restore.
3. Restore reports NO_CHECKPOINTS even though the checkpoint file exists on disk.

What actually happens

The checkpoint got written under a full-path slug:

~/.gstack/projects/-Users-<you>/checkpoints/20260703-095500-....md

but /context-restore computed a basename slug and looked in:

~/.gstack/projects/<you>/checkpoints/          # empty → NO_CHECKPOINTS

Same directory, two different slugs.

Root cause

bin/gstack-slug fallback order for a non-git dir with no cached slug is:

1. cached slug (~/.gstack/slug-cache/<key>)
2. git remote name — none here
3. basename "$PWD" → e.g. harry333414

So the current binary returns the basename for a non-git home dir. But the checkpoint on disk was saved under the full slugified path (-Users-<you>, slashes → dashes — the same scheme Claude Code uses for its own .claude/projects/ dirs). The two schemes don't agree, so save and restore never meet.

Making it sticky: after the save, a slug-cache entry got written pinning the dir to the basename slug:

~/.gstack/slug-cache/_Users_<you>   ->   <you>

so every subsequent restore is now permanently pointed at the empty basename folder, even though the data lives under the full-path folder. The mismatch is self-perpetuating once the cache is written.

Impact

• Silent data-appears-lost for any checkpoint/save workflow run from a non-git directory.
• NO_CHECKPOINTS is misleading — the file exists, restore is just looking in the wrong folder.
• Only affects non-git working dirs; git-repo projects slug off the remote and are stable.

Suggested fixes (pick one)

1. Make the slug scheme identical on both sides for non-git dirs. Whatever /context-save used to land in -Users-<you> and whatever gstack-slug now returns (<you>) must be the same function. One canonical slugifier, called everywhere.
2. Restore-side fallback: if the canonical slug folder is empty/missing, also probe the full-path slug (and vice-versa) before declaring NO_CHECKPOINTS.
3. One-time migration in gstack-upgrade/migrations/ that merges any -Users-* full-path project dirs into their basename equivalents and heals the slug-cache.

Happy to test a patch against this exact repro.