7086dcbbc9
Tests only; no fix. These MUST fail. Found while draining the containment duplicates in Phase 3, not by looking for it: isPathConfined's docstring claims its callers are kept symlink-safe upstream, and checking that claim showed it does not hold for three of its four call sites. isPathConfined is lexical by design and structurally cannot see a symlink, so where the claim fails there is no defense at all. install-engine.cts:1608 mkdirSync(recursive) + writeFileSync under dest install-profiles.cts:880 the same shape under stageDir install-profiles.cts:755 statSync/readFileSync, and statSync FOLLOWS links SEVERITY, STATED HONESTLY, because the three are not equal and the first impression was wrong. :755 is the real one and needs no race. It reads <capDir>/skills/<stem>/SKILL.md. Nothing prunes that path and nothing randomizes it, so a symlink planted there is followed and its content is returned — and then written into the install tree as a skill body. :1608 and :880 are defense-in-depth against a local race, not plain write-through. _removeGsdEntries (install-engine.cts:851-854) rmSyncs every entry whose name starts with kind.prefix, and the skill names ARE prefix+stem — so a symlink planted before the call is unlinked before the write loop reaches it. :880's stageDir is a fresh mkdtempSync path, so its name cannot be guessed in advance either. Both require winning a window. That is also why the first two tests do not simply pre-plant a link and call the function: written that way they PASS today, against vulnerable code, for the wrong reason. They instead open the window deterministically by hooking a call the function is guaranteed to make — the technique CLAUDE.md section 4 prescribes for injecting filesystem conditions, and the one already used in tests/install-runtime-artifacts.test.cjs. No sleeps, no concurrency, no flakiness: the window is opened by a synchronous side effect, not raced for. Each test asserts the OUTCOME rather than the mechanism — the canary file outside the root is byte-identical afterwards, or the installed content does not contain it — so a fix is free to close the hole any way it likes. Symlink creation is guarded so the Windows lanes skip rather than fail, and no test uses chmod 0o000, which is vacuous on a bench running as root. Folded into tests/install-write-confinement.test.cjs, the owning suite, whose existing F2/M1 coverage coincidentally proves the gap: it tests the case where the destination DIRECTORY is a symlink, which is already defended, and never the per-entry case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GSD Core
Git. Ship. Done.
English · Português · 简体中文 · 日本語 · 한국어
A light-weight meta-prompting, context engineering, and spec-driven development system for Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more.
What is GSD Core
GSD Core is a context-engineering and spec-driven development framework that drives AI coding agents (Claude Code, Codex, Antigravity CLI, Kimi CLI, Copilot, Cursor, and more) through a disciplined phase loop. It solves context rot — the quality degradation that accumulates as an AI fills its context window — by running all heavy research, planning, and execution work in fresh-context subagents while keeping your main session lean.
How it works
Each milestone repeats the same five-step loop, one phase at a time:
- Discuss — capture implementation decisions before anything is planned
- Plan — research, decompose, and verify the plan fits a fresh context window
- Execute — run plans in parallel waves; each executor starts with a clean 200k-token context
- Verify — walk through what was built; diagnose and fix before declaring done
- Ship — create the PR, archive the phase, repeat for the next one
Quickstart
npx @opengsd/gsd-core@latest
The installer prompts for your runtime (Claude Code, OpenCode, Antigravity CLI, Kimi CLI, Kilo, Codex, Copilot, Cursor, Windsurf, and more) and whether to install globally or locally. The installer is required for cross-runtime compatibility — do not copy files from agents/ or commands/ directly.
On another runtime or without Node.js? See Install on your runtime.
Once installed, start a new project or onboard an existing repo:
/gsd-new-project # greenfield project
/gsd-onboard # existing codebase
New here? Follow Your first project for a guided walkthrough from install to first shipped phase, or Onboarding an existing codebase for brownfield setup.
Documentation
What's new in 1.7.0 → docs/whats-new-1.7.0.md
Tutorials — learning by doing:
How-to guides — task-focused recipes:
Reference — authoritative facts:
Explanation — concepts and design decisions:
Full index: docs/README.md. Other languages: 日本語 · 한국어 · Português · 简体中文.
Why it works
Most AI-coding setups fail at scale because context bloat silently degrades output quality, there is no shared memory between sessions, and nothing verifies that code actually works. GSD Core solves all three: heavy work runs in fresh subagents, structured artifacts like STATE.md and CONTEXT.md survive session boundaries, and the verify step walks through what was built and generates fix plans before a phase is declared done. See docs/explanation/context-engineering.md for the full reasoning.
Troubleshooting? See docs/how-to/recover-and-troubleshoot.md.
Community
| Project | Platform |
|---|---|
| gsd-opencode | Original OpenCode port |
| Discord | Community support |
Star History
License
MIT License. See LICENSE for details.
Claude Code is powerful. GSD Core makes it reliable.