* test(#4254): sequential executor root pin — failing-first regression + matrix The new suite executes the shipped supplied-root-pin guard against real git fixtures (drifted primary-checkout cwd halts before the write and the FATAL names both roots; matching cwd permits it; unexpanded/empty pins halt; normalization forms; submodule and sibling boundaries; metacharacter quoting; drive-letter form gate) and locks the dispatch contract across execute-phase.md, its sequential-root-pin step fragment, and worktree-path-safety.md. The #2772 per-plan serialization assertion retargets to the fragment that now carries those rules (ADR-857 Phase 6 ceiling), plus the host-step wiring. * fix(#4254): pin sequential executor to the orchestrator's validated root Sequential-mode dispatch told the executor to self-derive PROJECT_ROOT from its own cwd; every existing guard is worktree-mode-only or self-referential, so an executor spawned with a drifted cwd committed onto the wrong checkout silently. - worktree-path-safety.md step 0p: mode-agnostic supplied-root pin guard, composed by the orchestrator at build time with the literal $ORCHESTRATOR_WT (git-vs-git comparison on both sides — representation-safe on Windows, the #4296 lesson), fail-closed on empty/unexpanded pins, registered-submodule allowance, warn-and-proceed only when the dispatch carries no pin block. - execute-phase.md sequential branch: build-time embed of the bound <project_root_pin> via the new execute-phase/steps/sequential-root-pin.md fragment (ADR-857 Phase 6 frozen ceiling — the host step cannot grow; the wave serialization rules move with the fragment, verbatim in substance) plus the per-write/commit pin instruction in <sequential_execution>. Worktree-mode dispatch untouched (its self-derived toplevel IS correct there). - INVENTORY rows (5 locales) + INVENTORY-MANIFEST + install-tree goldens regenerated for the new fragment; changeset added. * chore(#4254): backfill changeset PR number * fix(#4254): accept backslash-separated Windows drive pins CI on windows-latest showed every permit-path test failing with "Actual root: <none>": pins composed from Node's path.join arrive in the backslash drive form (C:\Users\RUNNER~1\...), which the guard's absolute-form gate rejected before the cwd-side root was ever computed — a legitimate matching pin could never pass. The gate now accepts either separator ([A-Za-z]:[\\/]); git -C resolves both forms (and 8.3 short names) to the same canonical toplevel, so the git-vs-git comparison is unaffected. Form-gate tests cover the emitted (C:/…) and produced (C:\…) spellings plus short names. * fix(#4254): portable drive-form gate for MSYS bash The bracket class [\\/] that accepted backslash drive pins parses inconsistently on MSYS bash (the Windows CI leg still rejected C:\ pins — every permit-path test red with "Actual root: <none>"). Replace it with standard pattern escaping outside brackets: [A-Za-z]:/*|[A-Za-z]:\\* — the escape form is version- and build-portable. Verified across all forms: both drive spellings accepted; bare "C:", relative, empty, and unexpanded rejected. * fix(#4254): runtime-generated backslash comparator + self-describing FATAL The Windows CI legs failed every #4254 permit-path row with 'Actual root: <none>' across two prior pattern spellings ([\\/] and \\*). Stage misattribution: <none> appears whenever the FATAL fires BEFORE the cwd-side capture assigns ACTUAL_ROOT — the absolute-form gate was what fired. Mechanism: the test harness spawns bash -c <script> through the Windows command-line boundary; that round-trip applies one extra shell-quoting pass with double-quote semantics — a backslash written twice in the script text arrives halved, while a lone backslash survives (the pin displays intact; row 9's pure-bash gate independently showed the halved pattern rejecting C:\ while C:/ still passed its surviving arm). On windows-latest every pin carries backslashes (os.tmpdir() is the 8.3 short form C:\Users\RUNNER~1\...), so the gate ate every pin before the actual root was ever computed. Fix, robust by construction: - the drive-form gate generates its backslash comparator at RUNTIME (BS=$(printf '\134'); match [A-Za-z]:"$BS"*) — the shipped guard now contains no doubled backslash anywhere, enforced by a regression assertion on the extracted guard text; - the FATAL self-describes: Guard stage (pin-unbound / form-gate / actual-capture / pinned-capture / root-mismatch) plus a Diagnostic line carrying git's own stderr for capture failures and both compared values for mismatches — future platform failures name their stage in the log; - row 9's hand-rolled duplicate case gate (transit-fragile copy, #4296 Minor 1 duplication smell) is replaced by driving the SHIPPED guard and asserting the stage; rows 2/4 pin the new stage machinery. Validated on darwin across drift/match/relative/unbound/empty/bare-drive/ forward-and-backslash drive forms, each also re-run under a simulated Windows transit (every doubled backslash halved) with identical outcomes. * fix(#4254): close the empty-comparator fail-open seam in the drive-form gate Self-review of the runtime-generated backslash comparator: if printf's octal escape ever returned empty, the drive arm [A-Za-z]:"$BS"* would widen to drive-RELATIVE pins (C:foo) — the construction's one theoretical fail-open path. Fail closed with a self-describing diagnostic instead of trusting the shell's printf. --------- Co-authored-by: sim <sim@local>
GSD Core 문서
문서는 네 가지 유형으로 구성됩니다. 튜토리얼은 직접 해보며 배우고, how-to 가이드는 특정 작업을 해결하며, 레퍼런스는 권위 있는 사실을 제시하고, 설명은 개념과 설계 결정을 탐구합니다.
언어 버전: English · Português (pt-BR) · 日本語 · 简体中文 · 한국어
튜토리얼
- 첫 번째 프로젝트 — 설치부터 첫 단계 출시까지, 확실한 한 가지 경로
- 기존 코드베이스 온보딩 — 기존 저장소에 GSD Core 적용하기
How-to guides
- 런타임에 설치하기 — 지원하는 15개 런타임 각각의 설치 단계
- 단계 논의하기 — 기획 시작 전 구현 결정 사항 정리
- 단계 기획하기 — 리서치 실행, 작업 분해, 플랜 품질 검증
- 단계 실행하기 — 새 컨텍스트 서브에이전트로 병렬 웨이브 실행
- 검증 및 출시 — 완료된 작업 검토, 오류 진단, PR 생성
- 단계 자율 실행하기 — 무인 단계 실행을 위한 자율 모드 사용
- 빠른 임시 작업 처리 — 단계 루프 외 임시 작업에
/gsd-quick과/gsd-fast활용 - 모델 프로필 설정 — 고품질, 균형, 예산 모델 티어 전환
- 크로스 AI 리뷰 설정 — 주 에이전트가 생성한 코드를 두 번째 AI가 검토하도록 설정
- 워크스트림으로 병렬 작업 — 워크스트림을 사용해 독립적인 작업 라인 동시 실행
- 워크스페이스로 작업 격리 — 워크스페이스로 실험적이거나 위험한 변경 사항 샌드박스 처리
- 실패한 실행 디버깅 — 깨지거나 불완전한 단계 실행 진단 및 복구
- 스파이크와 스케치 — 플랜 확정 전 탐색 작업에
/gsd-spike와/gsd-sketch활용 - UI 단계 설계 — 프론트엔드 및 시각적 작업에 UI 단계 루프 활용
- 트래커 이슈로 GSD 구동 — GitHub, Linear, Jira 이슈에서 단계 시작
- GSD 2에서 마이그레이션 — 기존 GSD 2 프로젝트를 GSD Core로 업그레이드
- GSD 업데이트 — 설치 프로그램을 재실행해 최신 릴리스 적용
- 복구 및 문제 해결 — 일반적인 문제 해결, 컨텍스트 재구축, 제거
레퍼런스
- 명령어 — 플래그와 예제가 포함된 모든 명령어
- 설정 — 전체 설정 스키마, 모델 프로필, git 브랜칭 전략
- CLI 도구 — 워크플로우와 에이전트를 위한
gsd-tools.cjs프로그래밍 API - 기능 — 전체 기능 색인
- 인벤토리 — 설치된 스킬과 서피스 맵
- STATE.md 스키마 —
.planning/STATE.md필드별 레퍼런스 - CONTEXT.md 스키마 —
.planning/phases/<N>/CONTEXT.md필드별 레퍼런스 - PLAN.md 스키마 —
.planning/phases/<N>/PLAN.md필드별 레퍼런스 - 기획 아티팩트 — 모든
.planning/파일과 역할
설명
- 컨텍스트 엔지니어링 — 컨텍스트 rot가 형성되는 방식과 GSD Core의 방지 방법
- 단계 루프 — 논의 → 기획 → 실행 → 검증 → 출시 사이클의 설계 근거
- 멀티 에이전트 오케스트레이션 — 서브에이전트의 생성, 범위 지정, 조율 방식
- 보안 모델 — 신뢰 경계, 권한, 안전한 자동화
- 아키텍처 — 시스템 아키텍처, 에이전트 모델, 데이터 흐름
- 논의 모드 —
/gsd-discuss-phase의 가정 모드와 인터뷰 모드 - 컨텍스트 모니터링 — 컨텍스트 창 모니터링 훅 아키텍처
- 이슈 기반 오케스트레이션 — 기존 프리미티브를 사용해 트래커 이슈로 GSD를 구동하는 레시피