Зачем это нужно
GSD 2 полезен как пример того, как SDD tooling может сдвинуться от "набор prompts and commands" к более полноценной runtime-системе для agentic development.
Если GSD Core удобно объяснять через phase loop, то GSD 2 интересен другим:
Agent workflow начинает иметь собственное состояние,
memory architecture, database, runtime files и session commands.
Это важный шаг в развитии AI-agent tooling. Чем длиннее и сложнее задача, тем меньше хватает одного Markdown plan. Нужны state, memory, resume, autonomous mode and verification discipline.
Основная идея
GSD 2 можно воспринимать как AI coding agent/runtime, который управляет:
- planning;
- execution;
- verification;
- shipping;
- state;
- memory;
- provider routing;
- skills;
- session lifecycle.
Его mental model:
Не просто "agent читает файлы".
Agent работает внутри runtime, где есть authoritative state и workflow commands.
Ключевые термины
| Термин | Значение |
|---|---|
| Runtime state | Состояние workflow, которое хранится вне текущего chat context. |
gsd.db |
Database-backed state для hierarchy and completion. |
PROJECT.md |
Living description of what the project is now. |
REQUIREMENTS.md |
Project-level capability contract and out-of-scope list. |
DECISIONS.md |
Append-only register of architectural decisions. |
KNOWLEDGE.md |
Cross-session rules, patterns, lessons learned. |
RUNTIME.md |
Runtime context: APIs, env vars, services. |
STATE.md |
Quick-glance dashboard rendered from runtime state. |
| Autonomous mode | Режим, где agent research, plans, executes, commits and repeats with fewer prompts. |
Как это устроено
В такой модели artifacts and database становятся частью "операционной памяти" agent workflow. Это снижает зависимость от одного context window, но увеличивает complexity.
Требования и запуск
По docs GSD 2 требует:
- Node.js 22+;
- Git;
- LLM provider or subscription flow;
- project repository.
Он поддерживает множество providers через Pi SDK style layer: Anthropic, OpenAI, Gemini, OpenRouter, GitHub Copilot, Bedrock, Azure OpenAI, Vertex, Groq, Mistral and others.
Практический вывод:
Перед использованием GSD 2 проверьте requirements и installation docs.
Это не просто Markdown toolkit, а runtime с зависимостями.
Session commands
В docs GSD 2 выделяются commands вроде:
| Command | Назначение |
|---|---|
/gsd или /gsd next |
Step mode: выполнить одну единицу и остановиться. |
/gsd auto |
Autonomous mode: research, plan, execute, commit, repeat. |
/gsd quick |
Быстрая задача с GSD guarantees без полного planning overhead. |
/gsd stop |
Gracefully stop auto mode. |
/gsd pause |
Pause and preserve state. |
/gsd steer |
Hard-steer plan documents during execution. |
/gsd discuss |
Обсудить architecture and decisions alongside workflow. |
Для курса здесь важны два режима:
- step mode для контролируемого обучения;
- auto mode для long-running agent execution, когда specs and verification достаточно сильные.
Artifacts
GSD 2 manages context through artifacts:
gsd.db
PROJECT.md
REQUIREMENTS.md
DECISIONS.md
KNOWLEDGE.md
RUNTIME.md
STATE.md
M001-ROADMAP.md
M001-CONTEXT.md
research/*.md
Роль artifacts:
gsd.dbхранит authoritative runtime state;PROJECT.mdописывает текущую систему;REQUIREMENTS.mdфиксирует capabilities and exclusions;DECISIONS.mdзащищает architecture от silent drift;KNOWLEDGE.mdпереносит lessons между sessions;RUNTIME.mdпомогает agent понимать environment;STATE.mdдает dashboard;- roadmap/context files удерживают milestone structure.
Как пользоваться
На обзорном уровне:
- Проверить prerequisites.
- Установить GSD 2 по official README.
- Запустить в repository.
- Начать с step mode, а не сразу с auto mode.
- Дать agent сформировать project artifacts.
- Проверить requirements and decisions.
- Запускать
/gsd nextдля controlled progress. - Использовать
/gsd autoтолько когда test baseline and verification reliable.
Пример cautious workflow:
/gsd
Потом review generated state.
/gsd discuss
Потом steering:
/gsd steer
И только после этого:
/gsd auto
Пример: migration на новую notification subsystem
Задача:
Перенести notifications с синхронных calls на event-driven subsystem.
Почему GSD 2 может быть уместен:
- задача длинная;
- нужны decisions;
- нужны runtime details;
- нужна память между sessions;
- есть risk of partial migration;
- нужно много verification.
Prompt:
Use GSD 2 in controlled step mode.
Goal:
Migrate notifications to an event-driven subsystem.
First update project understanding:
- current notification flow
- event infrastructure
- database tables
- runtime services
- test commands
Do not enter auto mode until PROJECT, REQUIREMENTS, DECISIONS, and STATE are reviewed.
Когда GSD 2 полезен
GSD 2 хорошо подходит, когда:
- задача long-running;
- требуется runtime state;
- нужны resume and pause semantics;
- project memory должна жить между sessions;
- есть несколько model providers;
- нужно autonomous execution, но с tracked state;
- project has reliable tests and CI.
Когда не стоит брать
GSD 2 может быть лишним, если:
- нужна одна маленькая feature;
- команда не хочет runtime dependencies;
- project state проще держать в Markdown;
- нет стабильных verification commands;
- разработчики не готовы review runtime-generated artifacts;
- требуются very strict enterprise controls, которые tool не покрывает.
Риски
| Риск | Как проявляется | Что делать |
|---|---|---|
| Runtime complexity | Tool становится еще одной системой, которую надо понимать. | Начинать с step mode and small feature. |
| State/code mismatch | gsd.db или STATE.md не совпадает с repository reality. |
Регулярно revalidate and inspect artifacts. |
| Auto mode overreach | Agent продолжает работу после неверного assumption. | Использовать approval gates and stop conditions. |
| Provider variability | Разные models дают разные outcomes. | Закреплять model policy and verification. |
| Hidden drift | Decisions меняются без update DECISIONS.md. |
Требовать decision log updates. |
GSD 2 vs GSD Core
| Вопрос | GSD Core | GSD 2 |
|---|---|---|
| Основной фокус | Phase loop and context engineering | Runtime state, memory, autonomous agent execution |
| Complexity | Ниже | Выше |
| State | Markdown/process artifacts | Database plus Markdown artifacts |
| Best for | Teams wanting adaptable core workflow | Long-running autonomous workflows with state |
| Риск | Недостаточно governance | Слишком много runtime complexity |
Prompt patterns
Controlled start
Use GSD 2 in step mode.
Do not use auto mode yet.
First build project understanding and show the generated artifacts for review.
Auto mode guard
Before entering auto mode, confirm:
- tests are passing
- requirements are explicit
- decisions are logged
- runtime assumptions are documented
- stop conditions are clear
Decision update
This changes architecture.
Update DECISIONS.md with:
- decision
- alternatives considered
- rationale
- consequences
- verification required
Практика
Выберите long-running task и определите, нужен ли runtime-style tool:
Task:
Estimated phases:
Requires persistent state: yes/no
Requires decision log: yes/no
Requires runtime context: yes/no
Can be done with simple specs: yes/no
Recommended tool:
Why:
Критерии готовности
После урока студент должен уметь:
- объяснить GSD 2 как runtime-oriented SDD tool;
- назвать основные state artifacts;
- понять разницу между step mode and auto mode;
- объяснить риск autonomous execution без verification;
- выбрать между GSD Core and GSD 2.
Краткое резюме
GSD 2 показывает, что SDD tooling может стать полноценной runtime-системой. Это дает memory, state and autonomous execution, но требует большей дисциплины. Чем мощнее agent runtime, тем важнее approval gates, evidence and state validation.
Вопросы для самопроверки
- Зачем GSD 2 нужен
gsd.db? - Чем
DECISIONS.mdотличается отREQUIREMENTS.md? - Когда auto mode опасен?
- Почему step mode лучше для первого внедрения?
- Когда GSD Core будет лучше GSD 2?
Источники для актуализации
- GSD 2 repository: https://github.com/gsd-build/gsd-2
- GSD 2 user docs: https://github.com/gsd-build/gsd-2/tree/main/docs/user-docs
Что дальше
Следующий урок разберет Agent-OS / Ouroboros - подход, где agent workflow описывается почти как operating system: seed specs, ledger, runtime adapters and evaluation gates.