* chore(#3618): fold fallow-runner onto the canonical binary resolver Epic #3411 Phase 2. src/fallow-runner.cts was the fourth divergent implementation of Windows binary resolution the epic enumerated — candidateNames, isExecutableFile, findInPath, findInNodeModules, 40 lines. All four are deleted; resolveFallowBinary is one seam call. Two OPT-IN options were added to resolveExecutableBinary to make the fold behavior-preserving, both defaulting off so Phase 1's callers are byte-identical: prependPaths dirs searched before env.PATH, in order, through the identical per-directory candidate logic. This expresses node_modules/.bin-first precedence without env surgery — the rejected alternative re-introduced the spread-loses-the-proxy hazard the Windows lane caught in Phase 1, at every future call site instead of once. requireExecutable POSIX-only accessSync(X_OK); a no-op on win32 where mode bits do not mean execute. Opt-in rather than default because unconditional X_OK breaks #3445's suite, which stages candidates with plain writeFileSync and never sets an exec bit — the repo bans chmod in tests — so every one would resolve to null on POSIX. Deliberate behavior change on Windows: fallow's prior candidate list ended in a BARE fallow. The seam never tries a bare name there, so an extensionless file beside fallow.cmd is no longer resolved. That is the fix, not a regression — the extensionless file is npm's POSIX sh shim, which CreateProcess cannot run (#3275). Rows 7 and 8 of the design record it. Defect found while working, fixed inline: the resolution order was documented BACKWARDS as PATH-then-.bin in structural-pre-pass.md, docs/INVENTORY.md and four INVENTORY translations. The code has always been .bin first, and .bin first is correct — a project-local tool should beat a global one. The archived changeset is left alone as a historical record. fallow-runner had no test file at all. tests/fallow-runner.test.cjs is new (F1-F15) and the seam options are pinned by S1-S12 folded into the existing dispatch suite. RED proven by execution: with both source files stashed and build:lib re-run, 7 of 27 probe cases failed. Refs #3411 * chore(#3618): backfill changeset pr number 3633 * fix(#3618): assert both platform contracts in F4 instead of a POSIX-only premise Windows CI on #3633 failed F4. The test monkeypatched accessSync to throw and asserted resolveFallowBinary returned null — but that premise, that the X_OK check is consulted at all, is POSIX-only by design. requireExecutable is a deliberate no-op on win32 because Windows mode bits do not mean execute, so the staged fixture correctly resolved there. 40-design.md's negative-space section already states this carve-out verbatim. The test contradicted the design it was written from: fixtures were made platform-adaptive in the previous commit, and this assertion was left platform-blind. F4 now asserts BOTH contracts — null on POSIX, resolves on win32 — rather than skipping either. A t.skip on one lane would have been green and would have left the win32 carve-out unpinned by fallow's own entry point. Audited every other row for the same class. F1-F3, F5, F6, F11-F15 hold on both platforms; F7-F10 and S1-S12 inject platform explicitly and are unaffected. F4 was the only row with a single-platform premise. The local probe runs on one platform and structurally cannot catch this, which is why it was green — that limitation is now stated at the top of the probe so a green probe is not mistaken for platform coverage. The win32 branch was proven by injecting platform:'win32' with accessSync throwing and asserting it still resolves. Refs #3411 --------- 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를 구동하는 레시피