ac1b6d679f
* 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>
Documentação do GSD Core
A documentação está organizada em quatro quadrantes: tutoriais ajudam você a aprender na prática, guias de instruções resolvem tarefas específicas, referência apresenta fatos autorizados, e explicação explora conceitos e decisões de design.
Versões por idioma: English · Português (pt-BR) · 日本語 · 简体中文
Tutorials
- Seu primeiro projeto — da instalação à primeira fase entregue, um caminho garantido
- Integrando uma base de código existente — leve o GSD Core a um repositório já existente
How-to guides
- Instalar no seu ambiente de execução — passos de instalação específicos para cada um dos 15 ambientes de execução suportados
- Discutir uma fase — registrar decisões de implementação antes do início do planejamento
- Planejar uma fase — executar pesquisa, decompor o trabalho e verificar a qualidade do plano
- Executar uma fase — rodar planos em ondas paralelas com subagentes com contexto renovado
- Verificar e entregar — revisar o trabalho concluído, diagnosticar falhas e criar o PR
- Rodar fases de forma autônoma — usar o modo autônomo para execução de fases sem supervisão
- Lidar com tarefas rápidas e ágeis — usar
/gsd-quicke/gsd-fastpara trabalho avulso fora do ciclo de fases - Configurar perfis de modelo — alternar entre níveis de modelo: qualidade, equilibrado e econômico
- Configurar revisão entre IAs — configurar uma segunda IA para revisar o código produzido pelo agente principal
- Trabalhar em paralelo com workstreams — executar linhas de trabalho independentes simultaneamente usando workstreams
- Isolar trabalho com workspaces — usar workspaces para isolar mudanças experimentais ou arriscadas
- Depurar uma execução com falha — diagnosticar e recuperar de execuções de fase quebradas ou incompletas
- Explorar e esboçar — usar
/gsd-spikee/gsd-sketchpara trabalho exploratório antes de comprometer com um plano - Projetar uma fase de UI — usar o ciclo de fase de UI para trabalho de frontend e visual
- Conduzir o GSD a partir de uma issue do rastreador — iniciar uma fase a partir de uma issue do GitHub, Linear ou Jira
- Migrar do GSD 2 — atualizar um projeto GSD 2 existente para o GSD Core
- Atualizar o GSD — executar novamente o instalador para obter a versão mais recente
- Recuperar e solucionar problemas — corrigir problemas comuns, reconstruir contexto e desinstalar
Referência
- Comandos — todos os comandos com flags e exemplos
- Configuração — schema completo de configuração, perfis de modelo, estratégias de branching git
- Ferramentas CLI — API programática
gsd-tools.cjspara workflows e agentes - Funcionalidades — índice completo de funcionalidades
- Inventário — skills instaladas e mapa de superfície
- Schema do STATE.md — referência campo a campo para
.planning/STATE.md - Schema do CONTEXT.md — referência campo a campo para
.planning/phases/<N>/CONTEXT.md - Schema do PLAN.md — referência campo a campo para
.planning/phases/<N>/PLAN.md - Artefatos de planejamento — todos os arquivos
.planning/e seus papéis
Explicação
- Engenharia de contexto — como a degradação de contexto se forma e como o GSD Core a previne
- O ciclo de fase — racional de design para o ciclo Discuss → Plan → Execute → Verify → Ship
- Orquestração multi-agente — como os subagentes são criados, delimitados e coordenados
- Modelo de segurança — limites de confiança, permissões e automação segura
- Arquitetura — arquitetura do sistema, modelo de agentes e fluxo de dados
- Modos de discussão — modo de suposições vs. modo de entrevista para
/gsd-discuss-phase - Monitoramento de contexto — arquitetura do hook de monitoramento da janela de contexto
- Orquestração orientada por issues — receita para conduzir o GSD a partir de uma issue do rastreador usando primitivos existentes
Relacionados
- README raiz — página inicial, início rápido e visão geral da documentação
- Changelog — histórico de versões