* test(#3034): failing-first coverage for opt-in parallel reviewer lanes Executes the real invoke_reviewers dispatch block from review.md against a stubbed gsd_run seam rather than pattern-matching the workflow text, so the two properties that actually carry risk are observable: that every lane is joined before aggregation, and that concurrent lanes cannot tear a line in gsd-review-lane-results.jsonl. Concurrency is proven by a barrier fixture, not by elapsed time -- each stub lane blocks until all lanes have checked in, which can only complete if they overlap. Red against the current sequential dispatch, by design. Refs #3034 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(#3034): add opt-in parallel reviewer lanes Reviewer lanes within one review pass inspect the same immutable plan snapshot and have no dependency on one another, but were dispatched strictly one at a time, so a multi-reviewer pass cost roughly the sum of its lanes. The serialization is a deliberate protection against provider rate limits, so it stays the default; review.parallel_lanes opts a project out of it. The loop body is hoisted into run_review_lane so the sequential and concurrent paths share one body -- two hand-synced dispatch bodies is the divergence class ADR-2782 spent a phase deleting. Each lane writes a slug-scoped result file, concatenated in selection order after the join: concurrent O_APPEND is atomic only below PIPE_BUF, and write_reviews parses that JSONL to render the models:/model_sources: frontmatter, so a torn line is a broken REVIEWS.md rather than a cosmetic log defect. Aggregating in selection order also keeps the artifact byte-identical between the two paths. The guard is strict equality on "true" and falls back to sequential when config-get fails -- the opposite polarity from the commit_docs guard, because failing open here fires the very requests the default prevents. Also corrects docs/COMMANDS.md and its four locale mirrors, which described --all as running every configured reviewer in parallel when dispatch was in fact sequential. Closes #3034 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(#3034): de-duplicate dispatch slugs and scope lane locals Review finding (Standards axis): a slug repeated in SELECTED_REVIEWERS would put two concurrent background jobs on the same > -truncated per-lane result file. The shared-append form this replaced could not corrupt itself that way, so de-duplicating is what keeps the concurrent path no worse than the sequential one. Selection de-dupes today -- the roster is a Set and review.default_reviewers normalizes lowercase-unique -- but reachability analysis is not a contract, which is the same reason the roster derivation itself is guarded. Splitting once into DISPATCH_SLUGS also removes the duplicated tr-split the same review flagged: the dispatch and aggregation loops now share one list, which is what guarantees they walk the same slugs in the same order. A plain string accumulator rather than an array, because zsh and bash disagree on array indexing and this block runs under both. Also scopes run_review_lane's locals. Not a live fix -- each dispatched call already forks its own subshell -- but it makes the isolation a property of the function rather than of the dispatch mechanism happening to fork. Refs #3034 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(#3034): acknowledge review.md growth, drop spent 2295 ack The differential attribution gate reported review.md growing 4173 bytes (30712 -> 34885) with no live acknowledgment. Adds the per-PR fragment it asks for, naming only the one path it reported. Deleting tests/emitted-drift-acks/2295-resolved-model.json is required, not opportunistic. That fragment declared review.md and nothing else, and its ripple is already absorbed into the base, so it is spent -- it can no longer clear anything, which is why the gate still reported review.md as unacknowledged. It could not simply be left alone either: two ack sources may never name the same path, so it blocked this PR's fragment outright. CONTRIBUTING is explicit that a fragment whose last entry is removed gets deleted with it, because an empty fragment signals nothing while its presence reads as a live alarm. Refs #3034 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(#3034): backfill changeset PR number Refs #3034 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: sim <sim@local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
GSD Core ドキュメント
ドキュメントは 4 つの象限で構成されています。チュートリアルは実践で学ぶ、ハウツーガイドは特定のタスクを解決する、リファレンスは信頼できる情報を示す、解説はコンセプトと設計上の決定を探求する。
言語バージョン: English · Português (pt-BR) · 日本語 · 简体中文 · 한국어
チュートリアル
- はじめてのプロジェクト — インストールから最初のフェーズ出荷まで、確実な一本道
- 既存コードベースのオンボーディング — ブラウンフィールドのリポジトリに GSD Core を導入する
How-to guides
- ランタイムへのインストール — サポートされる全 16 ランタイムのランタイム別インストール手順
- フェーズを議論する — 計画を始める前に実装上の決定事項を記録する
- フェーズを計画する — リサーチを実行し、作業を分解し、計画の品質を検証する
- フェーズを実行する — 新鮮なコンテキストのサブエージェントで並列ウェーブとして計画を実行する
- 検証と出荷 — 完成した作業を確認し、障害を診断し、PR を作成する
- フェーズを自律的に実行する — 無人フェーズ実行に自律モードを使用する
- クイックおよびファストタスクを処理する — フェーズループ外のアドホック作業に
/gsd-quickと/gsd-fastを使用する - モデルプロファイルを設定する — クオリティ・バランス・バジェットのモデルティア間を切り替える
- クロス AI レビューをセットアップする — プライマリエージェントが生成したコードをレビューする 2 番目の 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/ファイルとその役割
解説
- コンテキストエンジニアリング — コンテキストの腐敗がどのように形成され、GSD Core がどのように防ぐか
- フェーズループ — Discuss → Plan → Execute → Verify → Ship サイクルの設計理念
- マルチエージェントオーケストレーション — サブエージェントがどのように生成・スコープ設定・調整されるか
- セキュリティモデル — 信頼境界、パーミッション、安全な自動化
- アーキテクチャ — システムアーキテクチャ、エージェントモデル、データフロー
- ディスカスモード —
/gsd-discuss-phaseの assumptions モードと interview モード - コンテキストモニタリング — コンテキストウィンドウ監視フックのアーキテクチャ
- イシュー駆動オーケストレーション — 既存のプリミティブを使ってトラッカーイシューから GSD を動かすレシピ
Related
- ルート README — ランディングページ、クイックスタート、ドキュメント概要
- 変更履歴 — リリース履歴