Files
msd-core/tests
Tom Boucher 8c1962200d fix(#2911): resolve surface re-stage destinations the way the installer does (#3049)
* fix(#2911): resolve surface re-stage destinations the way the installer does

Two writers computed the same destination differently. The installer honors a
skills-kind home override; the surface re-stage ignored it and always resolved
against configDir. For a global Codex install that override points at
$HOME/.agents, so every re-stage built a second GSD-managed skill tree under
$CODEX_HOME alongside the correct one, with nothing indicating which was live.

Honors the override as a fallback, never a replacement -- runtimes without one
still resolve against configDir, which is most of them.

The real deliverable is the parity test, not the one-expression fix: it walks
every runtime in the registry across both scopes, computes the installer and
surface destinations, and fails naming the runtime if they ever disagree. Today
only Codex global carries an override, so it discriminates on exactly one
runtime -- stating that plainly rather than implying broader coverage -- but it
is derived from the registry, so a newly-added runtime is covered without anyone
remembering to add it.

Two further defects fixed rather than deferred:

- The legacy dev-preferences migration carried the identical defect, which the
  issue flagged as a latent instance of the same shape.
- Fixing it exposed a symlink-escape guard confined against the wrong root: it
  checked the span between configDir and the skill dir, but a home override
  moves the skill dir outside configDir entirely, so the span was meaningless
  and threw a false-positive escape. Now confined against the install root the
  destination actually resolves under. The guard is unchanged in strength and
  still honors its opt-in; only the root it measures from is corrected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(#2911): honor the home override in the fourth destination writer too

Adversarial review found a writer the fix had missed: the opencode-family skills
installer resolved its destination and its symlink guard against targetDir,
never consulting the skills-kind home override, while its three siblings all
already honored it.

Pre-existing and currently dormant -- it is reachable only for the
combined-family runtimes, and none of them declares an override today, so no
user is affected right now. Fixed anyway rather than left as a latent instance
of the same shape, which is exactly what this issue asked for in the case of the
legacy migration.

Mirrors the shape used for the other three: a single installRoot local that both
the destination and the guard derive from, so the two cannot drift apart. The
guard's message now names the root it actually confined against.

Coverage extended to this writer and proven non-theatre: reverting the change in
a scratch build makes it fail for both combined-family runtimes.

Enumerated every remaining site that computes a destination from destSubpath or
calls the confinement helper -- install and uninstall paths, the surface module,
the read-side skills-root reporter. All honor the override or structurally
cannot express one. No fifth defect. The one adjacent shape, the flat command
directory, reads a different descriptor field that no kind declares an override
for in the current schema; noted rather than papered over with a fallback for a
field that cannot exist.

Verified no behavior change for the affected runtimes today: normalized
file-tree hashes before and after are identical.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(#2911): backfill changeset pr number

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-04 14:31:07 -04:00
..