no-mistakes(document): Sync onboarding documentation gaps
This commit is contained in:
Jeremy McSpadden
committed by
Codesmith
Codesmith
parent
1c992bf57d
commit
ddd8558873
@@ -620,7 +620,8 @@ Equivalent paths for other runtimes:
|
||||
│ ├── FEATURES.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ └── PITFALLS.md
|
||||
├── codebase/ # Brownfield mapping (from /gsd-map-codebase)
|
||||
├── codebase/ # Brownfield mapping (from /gsd-map-codebase or /gsd-onboard)
|
||||
├── onboarding/ # Brownfield onboarding summary (from /gsd-onboard)
|
||||
│ ├── STACK.md # YAML frontmatter carries `last_mapped_commit`
|
||||
│ ├── ARCHITECTURE.md # for the post-execute drift gate (#2003)
|
||||
│ ├── CONVENTIONS.md
|
||||
|
||||
@@ -447,10 +447,11 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
|
||||
## After install
|
||||
|
||||
Restart your runtime to pick up new commands and agents. Then start your first project:
|
||||
Restart your runtime to pick up new commands and agents. Then start a new project or onboard an existing repo:
|
||||
|
||||
```bash
|
||||
/gsd-new-project
|
||||
/gsd-new-project # greenfield project
|
||||
/gsd-onboard # existing codebase
|
||||
```
|
||||
|
||||
If the command is not found after restart, verify the install directory matches the runtime's expected config path. The prerelease-editions section above covers the most common mismatch.
|
||||
|
||||
@@ -474,7 +474,8 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
│ ├── FEATURES.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ └── PITFALLS.md
|
||||
├── codebase/ # ブラウンフィールドマッピング（/gsd-map-codebase から）
|
||||
├── codebase/ # ブラウンフィールドマッピング（/gsd-map-codebase または /gsd-onboard から）
|
||||
├── onboarding/ # ブラウンフィールドオンボーディング概要（/gsd-onboard から）
|
||||
│ ├── STACK.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ ├── CONVENTIONS.md
|
||||
|
||||
@@ -273,10 +273,11 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
|
||||
## インストール後の作業
|
||||
|
||||
新しいコマンドとエージェントを反映するためにランタイムを再起動してください。その後、最初のプロジェクトを開始します。
|
||||
新しいコマンドとエージェントを反映するためにランタイムを再起動してください。その後、新規プロジェクトを開始するか既存リポジトリをオンボーディングします。
|
||||
|
||||
```bash
|
||||
/gsd-new-project
|
||||
/gsd-new-project # グリーンフィールドプロジェクト
|
||||
/gsd-onboard # 既存コードベース
|
||||
```
|
||||
|
||||
再起動後もコマンドが見つからない場合は、インストールディレクトリがランタイムの期待する設定パスと一致しているか確認してください。最もよくある不一致については上記のプレリリースエディションのセクションを参照してください。
|
||||
|
||||
@@ -23,6 +23,8 @@
|
||||
│ ├── architecture.md
|
||||
│ ├── stack.md
|
||||
│ └── ...
|
||||
├── onboarding/ # ブラウンフィールドオンボーディング概要（オプション）
|
||||
│ └── SUMMARY.md
|
||||
├── intel/ # クエリ可能なシンボルインデックス（オプション、intel.enabled）
|
||||
│ └── API-SURFACE.md
|
||||
└── phases/
|
||||
@@ -48,7 +50,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プロジェクトの正規アイデンティティ: 概要、対象ユーザー、コアバリュー、要件、制約、主要な意思決定。プロダクトの進化に伴いプロジェクトライフサイクル全体を通じて更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成）; 意思決定が検証されると `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; 意思決定が検証されると `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | すべてのプランニングワークフロー; `gsd-phase-researcher`、`gsd-planner`（コンテキスト）; `discuss-phase`（過去の意思決定）; `gsd-plan-checker`（プロジェクト制約）。 |
|
||||
|
||||
### `ROADMAP.md`
|
||||
@@ -56,7 +58,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | マイルストーンおよびフェーズ一覧。ゴール、要件 ID、成功基準、フェーズごとの正規リファレンスを含みます。プロジェクトが何をどの順序で構築するかに関する唯一の信頼できる情報源です。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成）; `/gsd-phase --insert` および `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; `/gsd-phase --insert` および `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | `/gsd-discuss-phase`、`/gsd-plan-phase`、`/gsd-execute-phase`; フェーズ情報を必要とするすべてのオーケストレーションコマンド; `gsd-planner`、`gsd-plan-checker`、`gsd-phase-researcher`。 |
|
||||
|
||||
### `REQUIREMENTS.md`
|
||||
@@ -64,7 +66,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 番号付きのチェック可能な受け入れ基準。各要件はロードマップフェーズにマッピングされる ID（例: `AUTH-01`）を持ちます。フェーズが実行されると要件を完了済みとしてマークします。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成）; `execute-phase` によって要件が完了済みとしてマークされます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; `execute-phase` によって要件が完了済みとしてマークされます。 |
|
||||
| **参照先** | `gsd-planner`（プランはすべてのフェーズ要件 ID に対処しなければならない）; `gsd-plan-checker` ディメンション1（要件カバレッジ）; `discuss-phase`（過去の要件）。 |
|
||||
|
||||
### `STATE.md`
|
||||
@@ -72,7 +74,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 現在地を追跡するリビングドキュメント — 現在のフェーズとプラン、進捗指標、蓄積された意思決定、セッション継続性ノート。すべてのワークフロー実行の開始時に読み込まれます。重要なアクションのたびに更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成）; すべてのフェーズワークフロー、`/gsd-pause-work`、`/gsd-resume-work` によって継続的に更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; すべてのフェーズワークフロー、`/gsd-pause-work`、`/gsd-resume-work` によって継続的に更新されます。 |
|
||||
| **参照先** | すべてのオーケストレーションワークフロー; `/gsd-progress`; `/gsd-quick` 経由のアドホックタスク実行; `gsd-planner` および `gsd-phase-researcher`（プロジェクトの意思決定）。 |
|
||||
|
||||
完全なフィールドリファレンスは [STATE.md スキーマ](state-md.md) を参照してください。
|
||||
@@ -87,6 +89,14 @@
|
||||
|
||||
完全なスキーマは [CONFIGURATION](../../CONFIGURATION.md) を参照してください。
|
||||
|
||||
### `onboarding/SUMMARY.md`（オプション）
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | ブラウンフィールドオンボーディングの索引。アーティファクト状態、コードベースマッピングの完了状況、初回セットアップ後に推奨される次の GSD コマンドを記録します。 |
|
||||
| **生成元** | `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在した後の `/gsd-onboard`。 |
|
||||
| **参照先** | 初回セットアップを確認する人間、および既存オンボーディング状態を確認する今後の `/gsd-onboard` 実行。 |
|
||||
|
||||
### `MILESTONES.md`（オプション）
|
||||
|
||||
| | |
|
||||
|
||||
@@ -46,7 +46,7 @@ claude --dangerously-skip-permissions
|
||||
|
||||
## ステップ 3 — Brownfield オンボーディングの開始
|
||||
|
||||
プロジェクトを作成する前に、GSD Core に既存のコードを学習させてください。これがブラウンフィールドの計画を正確にするステップです。
|
||||
プロジェクトを作成する前に、GSD Core にリポジトリ状態を確認させ、安全な次のトップレベルコマンドを表示させます。これにより、コードベースコンテキストの取りこぼしや既存 planning ファイルの上書きを防げます。
|
||||
|
||||
```text
|
||||
/gsd-onboard
|
||||
@@ -84,7 +84,7 @@ Created .planning/codebase/:
|
||||
|
||||
---
|
||||
|
||||
## ステップ 4 — コンテキストをクリアしてプロジェクトを作成
|
||||
## ステップ 4 — オンボーディングを再実行してプロジェクトを初期化する
|
||||
|
||||
セッションウィンドウをクリアします:
|
||||
|
||||
@@ -92,12 +92,14 @@ Created .planning/codebase/:
|
||||
/clear
|
||||
```
|
||||
|
||||
プロジェクトを作成します。前のステップで GSD Core が既存のコードを見つけているため、これがブラウンフィールドプロジェクトであることをすでに把握しています。`/gsd-new-project` を実行すると、既存のものを再説明するのではなく、*追加する*内容に焦点を当てた質問がされます:
|
||||
`/gsd-onboard` をもう一度実行します。GSD Core が ADR、PRD、spec、RFC、またはルートレベルの要件ドキュメントを検出した場合は、先に推奨される `/gsd-ingest-docs` ハンドオフを実行し、その後 `/gsd-onboard` を再実行してください。コンテキストが整うと、オンボーディングはプロジェクト初期化のハンドオフを表示します:
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
```
|
||||
|
||||
前のステップで GSD Core が既存のコードを見つけているため、`/gsd-new-project` はこれがブラウンフィールドプロジェクトだと分かっています。質問は既存のものを再説明するのではなく、*追加する*内容に焦点を当てます:
|
||||
|
||||
GSD Core が何を作りたいかを尋ねます。コードベース全体の説明ではなく、追加する機能で答えてください:
|
||||
|
||||
```text
|
||||
@@ -124,6 +126,8 @@ Proposed Roadmap
|
||||
|
||||
ロードマップを承認してください。
|
||||
|
||||
プロジェクト設定が完了したら、もう一度 `/gsd-onboard` を実行します。`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在するため、オンボーディングは `.planning/onboarding/SUMMARY.md` を作成または確認します。
|
||||
|
||||
**`.planning/` に作成されるファイル:**
|
||||
|
||||
```text
|
||||
@@ -133,7 +137,7 @@ Proposed Roadmap
|
||||
ROADMAP.md ← フェーズ 1、ステータス: pending
|
||||
STATE.md ← セッションメモリ
|
||||
config.json ← ワークフロー設定
|
||||
onboarding/SUMMARY.md ← onboarding status and next command
|
||||
onboarding/SUMMARY.md ← オンボーディング状態と次のコマンド
|
||||
codebase/ ← ステップ 3 の7つのマップファイル
|
||||
```
|
||||
|
||||
@@ -213,6 +217,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
|
||||
|
||||
## 学んだこと
|
||||
|
||||
- `/gsd-onboard` が対話型コマンドをネストしたり既存 planning ファイルを上書きしたりせずに、ブラウンフィールド設定を安全に順序付ける仕組み。
|
||||
- `/gsd-map-codebase` が4つの並行エージェントを実行して `.planning/codebase/` に `STACK.md`、`ARCHITECTURE.md`、`CONVENTIONS.md`、`CONCERNS.md`、`STRUCTURE.md`、`TESTING.md`、`INTEGRATIONS.md` を生成する仕組み。
|
||||
- ブラウンフィールドリポジトリで `/gsd-new-project` を実行すると、*追加する*内容に焦点を当てた質問がされ、既存コードから Validated 要件が自動入力される仕組み。
|
||||
- コードベースマップが `/gsd-discuss-phase` のすべての質問を形成する方法 — ファイルパス、パターン、規約が実際のコードから導出される。
|
||||
|
||||
@@ -512,7 +512,8 @@ UI-SPEC.md (단계별) ───────────────────
|
||||
│ ├── FEATURES.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ └── PITFALLS.md
|
||||
├── codebase/ # 브라운필드 매핑 (/gsd-map-codebase에서)
|
||||
├── codebase/ # 브라운필드 매핑 (/gsd-map-codebase 또는 /gsd-onboard에서)
|
||||
├── onboarding/ # 브라운필드 온보딩 요약 (/gsd-onboard에서)
|
||||
│ ├── STACK.md # YAML 전문에 `last_mapped_commit` 포함
|
||||
│ ├── ARCHITECTURE.md # 실행 후 드리프트 게이트를 위한 (#2003)
|
||||
│ ├── CONVENTIONS.md
|
||||
|
||||
@@ -273,10 +273,11 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
|
||||
## 설치 후
|
||||
|
||||
새 명령과 에이전트를 적용하려면 런타임을 재시작하세요. 그런 다음 첫 번째 프로젝트를 시작합니다:
|
||||
새 명령과 에이전트를 적용하려면 런타임을 재시작하세요. 그런 다음 새 프로젝트를 시작하거나 기존 저장소를 온보딩합니다:
|
||||
|
||||
```bash
|
||||
/gsd-new-project
|
||||
/gsd-new-project # 그린필드 프로젝트
|
||||
/gsd-onboard # 기존 코드베이스
|
||||
```
|
||||
|
||||
재시작 후 명령을 찾을 수 없다면 설치 디렉터리가 런타임이 기대하는 설정 경로와 일치하는지 확인하세요. 위의 프리릴리스 에디션 섹션에서 가장 흔한 불일치 사례를 다룹니다.
|
||||
|
||||
@@ -23,6 +23,8 @@
|
||||
│ ├── architecture.md
|
||||
│ ├── stack.md
|
||||
│ └── ...
|
||||
├── onboarding/ # 브라운필드 온보딩 요약 (선택)
|
||||
│ └── SUMMARY.md
|
||||
├── intel/ # 쿼리 가능한 심볼 인덱스 (선택, intel.enabled)
|
||||
│ └── API-SURFACE.md
|
||||
└── phases/
|
||||
@@ -48,7 +50,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **목적** | 표준 프로젝트 아이덴티티: 무엇인지, 누구를 위한 것인지, 핵심 가치, 요구사항, 제약 사항, 주요 결정. 제품이 발전함에 따라 프로젝트 생명주기 전반에 걸쳐 업데이트됩니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성); 결정이 검증됨에 따라 `/gsd-complete-milestone`에 의해 업데이트됩니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); 결정이 검증됨에 따라 `/gsd-complete-milestone`에 의해 업데이트됩니다. |
|
||||
| **소비자** | 모든 플래닝 워크플로; `gsd-phase-researcher`, `gsd-planner` (컨텍스트); `discuss-phase` (이전 결정); `gsd-plan-checker` (프로젝트 제약 사항). |
|
||||
|
||||
### `ROADMAP.md`
|
||||
@@ -56,7 +58,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **목적** | 목표, 요구사항 ID, 성공 기준, 페이즈별 표준 참조가 있는 마일스톤 및 페이즈 목록. 프로젝트가 무엇을 빌드하고 어떤 순서로 하는지에 대한 단일 진실의 원천. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성); `/gsd-phase --insert`와 `/gsd-complete-milestone`에 의해 업데이트됩니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); `/gsd-phase --insert`와 `/gsd-complete-milestone`에 의해 업데이트됩니다. |
|
||||
| **소비자** | `/gsd-discuss-phase`, `/gsd-plan-phase`, `/gsd-execute-phase`; 페이즈 정보가 필요한 모든 오케스트레이션 명령; `gsd-planner`, `gsd-plan-checker`, `gsd-phase-researcher`. |
|
||||
|
||||
### `REQUIREMENTS.md`
|
||||
@@ -64,7 +66,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **목적** | 프로젝트의 번호가 매겨진 체크 가능한 인수 기준. 각 요구사항은 로드맵 페이즈에 매핑되는 ID(예: `AUTH-01`)를 가집니다. 페이즈가 실행됨에 따라 요구사항을 완료로 표시합니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성); `execute-phase`에 의해 요구사항이 완료로 표시됩니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); `execute-phase`에 의해 요구사항이 완료로 표시됩니다. |
|
||||
| **소비자** | `gsd-planner` (플랜은 모든 페이즈 요구사항 ID를 처리해야 함); `gsd-plan-checker` Dimension 1 (요구사항 커버리지); `discuss-phase` (이전 요구사항). |
|
||||
|
||||
### `STATE.md`
|
||||
@@ -72,7 +74,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **목적** | 살아있는 위치 추적기 — 현재 페이즈와 플랜, 진행 지표, 누적된 결정, 세션 연속성 노트. 모든 워크플로 실행 시작 시 읽힙니다. 중요한 작업 이후 업데이트됩니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성); 모든 페이즈 워크플로, `/gsd-pause-work`, `/gsd-resume-work`에 의해 지속적으로 업데이트됩니다. |
|
||||
| **생성자** | `/gsd-new-project` (최초 생성, `/gsd-onboard` handoff 포함); 모든 페이즈 워크플로, `/gsd-pause-work`, `/gsd-resume-work`에 의해 지속적으로 업데이트됩니다. |
|
||||
| **소비자** | 모든 오케스트레이션 워크플로; `/gsd-progress`; `/gsd-quick`을 통한 임시 태스크 실행; `gsd-planner` 및 `gsd-phase-researcher` (프로젝트 결정). |
|
||||
|
||||
전체 필드 참조는 [STATE.md 스키마](state-md.md)를 참조하세요.
|
||||
@@ -87,6 +89,14 @@
|
||||
|
||||
전체 스키마는 [CONFIGURATION](../../CONFIGURATION.md)을 참조하세요.
|
||||
|
||||
### `onboarding/SUMMARY.md` (선택)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **목적** | 브라운필드 온보딩 인덱스. 아티팩트 상태, 코드베이스 매핑 완료 여부, 초기 설정 후 권장되는 다음 GSD 명령을 기록합니다. |
|
||||
| **생성자** | `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 존재한 뒤 `/gsd-onboard`. |
|
||||
| **소비자** | 초기 설정을 검토하는 사람; 기존 온보딩 상태를 확인하는 향후 `/gsd-onboard` 실행. |
|
||||
|
||||
### `MILESTONES.md` (선택)
|
||||
|
||||
| | |
|
||||
|
||||
@@ -44,9 +44,9 @@ claude --dangerously-skip-permissions
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — 코드베이스 매핑
|
||||
## Step 3 — 브라운필드 온보딩 시작
|
||||
|
||||
프로젝트를 생성하기 전에 GSD Core가 이미 존재하는 것을 학습하도록 합니다. 이 단계가 브라운필드 계획의 정확도를 높이는 핵심입니다.
|
||||
프로젝트를 생성하기 전에 GSD Core가 저장소 상태를 검사하고 안전한 다음 top-level 명령을 알려주게 하세요. 이 단계는 코드베이스 컨텍스트를 건너뛰거나 기존 planning 파일을 덮어쓰는 일을 방지합니다.
|
||||
|
||||
```text
|
||||
/gsd-onboard
|
||||
@@ -84,7 +84,7 @@ Created .planning/codebase/:
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — 컨텍스트 초기화 후 프로젝트 생성
|
||||
## Step 4 — 온보딩 재실행 및 프로젝트 초기화
|
||||
|
||||
세션 창을 초기화합니다:
|
||||
|
||||
@@ -92,7 +92,7 @@ Created .planning/codebase/:
|
||||
/clear
|
||||
```
|
||||
|
||||
이제 프로젝트를 생성합니다. GSD Core가 이전 단계에서 기존 코드를 발견했으므로, 이미 이것이 브라운필드 프로젝트임을 알고 있습니다. `/gsd-new-project`를 실행하면 기존의 것을 재구성하는 것이 아니라 *추가하는* 것에 집중한 질문을 합니다:
|
||||
이제 `/gsd-onboard`를 다시 실행합니다. GSD Core가 ADR, PRD, spec, RFC 또는 루트 요구사항 문서를 감지하면 먼저 권장되는 `/gsd-ingest-docs` handoff를 실행하고 이후 `/gsd-onboard`를 다시 실행하세요. 컨텍스트가 준비되면 온보딩이 프로젝트 초기화 handoff를 출력합니다:
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
@@ -124,6 +124,8 @@ Proposed Roadmap
|
||||
|
||||
로드맵을 승인합니다.
|
||||
|
||||
프로젝트 설정이 끝난 뒤 `/gsd-onboard`를 한 번 더 실행합니다. 이제 `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`가 모두 있으므로 온보딩은 `.planning/onboarding/SUMMARY.md`를 생성하거나 확인합니다.
|
||||
|
||||
**`.planning/`에 생성되는 파일:**
|
||||
|
||||
```text
|
||||
@@ -133,7 +135,7 @@ Proposed Roadmap
|
||||
ROADMAP.md ← Phase 1, 상태: pending
|
||||
STATE.md ← 세션 메모리
|
||||
config.json ← 워크플로 설정
|
||||
onboarding/SUMMARY.md ← onboarding status and next command
|
||||
onboarding/SUMMARY.md ← 온보딩 상태와 다음 명령
|
||||
codebase/ ← Step 3에서 생성된 7개의 맵 파일
|
||||
```
|
||||
|
||||
@@ -213,6 +215,7 @@ GSD Core가 `CONVENTIONS.md`와 `ARCHITECTURE.md`를 읽었으므로, 질문들
|
||||
|
||||
## 배운 내용
|
||||
|
||||
- `/gsd-onboard`가 인터랙티브 명령을 중첩하거나 기존 planning 파일을 덮어쓰지 않고 브라운필드 설정을 안전하게 순서화하는 방법.
|
||||
- `/gsd-map-codebase`가 4개의 병렬 에이전트를 실행하여 `.planning/codebase/`에 `STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, `CONCERNS.md`, `STRUCTURE.md`, `TESTING.md`, `INTEGRATIONS.md`를 생성하는 방법.
|
||||
- 브라운필드 저장소에서 `/gsd-new-project`가 *추가하는* 것에 집중한 질문을 하고 기존 코드에서 Validated 요구사항을 채우는 방법.
|
||||
- 코드베이스 맵이 `/gsd-discuss-phase`의 모든 질문을 형성하는 방법 — 파일 경로, 패턴, 컨벤션이 실제 코드에서 옵니다.
|
||||
|
||||
@@ -527,7 +527,8 @@ Caminhos equivalentes para outros runtimes:
|
||||
│ ├── FEATURES.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ └── PITFALLS.md
|
||||
├── codebase/ # Mapeamento de brownfield (do /gsd-map-codebase)
|
||||
├── codebase/ # Mapeamento de brownfield (do /gsd-map-codebase ou /gsd-onboard)
|
||||
├── onboarding/ # Resumo de onboarding brownfield (do /gsd-onboard)
|
||||
│ ├── STACK.md # Frontmatter YAML carrega `last_mapped_commit`
|
||||
│ ├── ARCHITECTURE.md # para o portão de desvio pós-execução (#2003)
|
||||
│ ├── CONVENTIONS.md
|
||||
|
||||
@@ -273,10 +273,11 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
|
||||
## Após a instalação
|
||||
|
||||
Reinicie seu ambiente para carregar os novos comandos e agentes. Em seguida, inicie seu primeiro projeto:
|
||||
Reinicie seu ambiente para carregar os novos comandos e agentes. Em seguida, inicie um projeto novo ou faça onboarding de um repositório existente:
|
||||
|
||||
```bash
|
||||
/gsd-new-project
|
||||
/gsd-new-project # projeto greenfield
|
||||
/gsd-onboard # base de código existente
|
||||
```
|
||||
|
||||
Se o comando não for encontrado após o reinício, verifique se o diretório de instalação corresponde ao caminho de configuração esperado pelo ambiente. A seção de edições de pré-lançamento acima cobre a incompatibilidade mais comum.
|
||||
|
||||
@@ -23,6 +23,8 @@ O diretório `.planning/` é a memória compartilhada do GSD Core para um projet
|
||||
│ ├── architecture.md
|
||||
│ ├── stack.md
|
||||
│ └── ...
|
||||
├── onboarding/ # Resumo de onboarding brownfield (opcional)
|
||||
│ └── SUMMARY.md
|
||||
├── intel/ # Índice de símbolos consultável (opcional, intel.enabled)
|
||||
│ └── API-SURFACE.md
|
||||
└── phases/
|
||||
@@ -48,7 +50,7 @@ O diretório `.planning/` é a memória compartilhada do GSD Core para um projet
|
||||
| | |
|
||||
|---|---|
|
||||
| **Finalidade** | Identidade canônica do projeto: o que é, para quem é, valor central, requisitos, restrições e decisões-chave. Atualizado ao longo do ciclo de vida do projeto conforme o produto evolui. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial); atualizado por `/gsd-complete-milestone` à medida que as decisões são validadas. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial, incluindo handoff do `/gsd-onboard`); atualizado por `/gsd-complete-milestone` à medida que as decisões são validadas. |
|
||||
| **Consumido por** | Todos os fluxos de trabalho de planejamento; `gsd-phase-researcher`, `gsd-planner` (contexto); `discuss-phase` (decisões anteriores); `gsd-plan-checker` (restrições do projeto). |
|
||||
|
||||
### `ROADMAP.md`
|
||||
@@ -56,7 +58,7 @@ O diretório `.planning/` é a memória compartilhada do GSD Core para um projet
|
||||
| | |
|
||||
|---|---|
|
||||
| **Finalidade** | Listagem de marcos e fases com objetivos, IDs de requisitos, critérios de sucesso e referências canônicas por fase. A fonte única de verdade sobre o que o projeto está construindo e em que ordem. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial); atualizado por `/gsd-phase --insert` e `/gsd-complete-milestone`. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial, incluindo handoff do `/gsd-onboard`); atualizado por `/gsd-phase --insert` e `/gsd-complete-milestone`. |
|
||||
| **Consumido por** | `/gsd-discuss-phase`, `/gsd-plan-phase`, `/gsd-execute-phase`; todos os comandos de orquestração que precisam de informações de fase; `gsd-planner`, `gsd-plan-checker`, `gsd-phase-researcher`. |
|
||||
|
||||
### `REQUIREMENTS.md`
|
||||
@@ -64,7 +66,7 @@ O diretório `.planning/` é a memória compartilhada do GSD Core para um projet
|
||||
| | |
|
||||
|---|---|
|
||||
| **Finalidade** | Critérios de aceitação numerados e verificáveis para o projeto. Cada requisito possui um ID (ex.: `AUTH-01`) que mapeia para as fases do roadmap. Marca os requisitos como concluídos conforme as fases são executadas. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial); requisitos marcados como concluídos por `execute-phase`. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial, incluindo handoff do `/gsd-onboard`); requisitos marcados como concluídos por `execute-phase`. |
|
||||
| **Consumido por** | `gsd-planner` (os planos devem contemplar todos os IDs de requisitos da fase); `gsd-plan-checker` Dimensão 1 (cobertura de requisitos); `discuss-phase` (requisitos anteriores). |
|
||||
|
||||
### `STATE.md`
|
||||
@@ -72,7 +74,7 @@ O diretório `.planning/` é a memória compartilhada do GSD Core para um projet
|
||||
| | |
|
||||
|---|---|
|
||||
| **Finalidade** | Rastreador de posição em andamento — fase e plano atuais, métricas de progresso, decisões acumuladas, notas de continuidade de sessão. Lido no início de toda execução de fluxo de trabalho. Atualizado após cada ação significativa. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial); atualizado continuamente por todos os fluxos de fase, `/gsd-pause-work`, `/gsd-resume-work`. |
|
||||
| **Produzido por** | `/gsd-new-project` (criação inicial, incluindo handoff do `/gsd-onboard`); atualizado continuamente por todos os fluxos de fase, `/gsd-pause-work`, `/gsd-resume-work`. |
|
||||
| **Consumido por** | Todos os fluxos de orquestração; `/gsd-progress`; execução de tarefas avulsas via `/gsd-quick`; `gsd-planner` e `gsd-phase-researcher` (decisões do projeto). |
|
||||
|
||||
Consulte o [esquema de STATE.md](state-md.md) para a referência completa de campos.
|
||||
@@ -87,6 +89,14 @@ Consulte o [esquema de STATE.md](state-md.md) para a referência completa de cam
|
||||
|
||||
Consulte [CONFIGURATION](../CONFIGURATION.md) para o esquema completo.
|
||||
|
||||
### `onboarding/SUMMARY.md` (opcional)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Finalidade** | Índice de onboarding brownfield que registra status dos artefatos, se o mapeamento do código-base está completo e o próximo comando GSD recomendado após a configuração inicial. |
|
||||
| **Produzido por** | `/gsd-onboard` depois que `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md` e `STATE.md` existem. |
|
||||
| **Consumido por** | Humanos revisando a configuração inicial; futuras execuções de `/gsd-onboard` ao confirmar o estado de onboarding existente. |
|
||||
|
||||
### `MILESTONES.md` (opcional)
|
||||
|
||||
| | |
|
||||
|
||||
@@ -44,9 +44,9 @@ claude --dangerously-skip-permissions
|
||||
|
||||
---
|
||||
|
||||
## Passo 3 — Mapear a base de código
|
||||
## Passo 3 — Iniciar o onboarding brownfield
|
||||
|
||||
Antes de criar um projeto, deixe o GSD Core aprender o que já existe. Este é o passo que torna o planejamento brownfield preciso.
|
||||
Antes de criar um projeto, deixe o GSD Core inspecionar o estado do repositório e indicar o próximo comando de nível superior seguro. Este passo evita pular contexto de código ou sobrescrever arquivos de planning existentes.
|
||||
|
||||
```text
|
||||
/gsd-onboard
|
||||
@@ -84,7 +84,7 @@ Abra `.planning/codebase/CONCERNS.md`. Este é o arquivo mais útil para ler ant
|
||||
|
||||
---
|
||||
|
||||
## Passo 4 — Limpar o contexto e criar o projeto
|
||||
## Passo 4 — Reexecutar o onboarding e inicializar o projeto
|
||||
|
||||
Limpe a janela de sessão:
|
||||
|
||||
@@ -92,12 +92,14 @@ Limpe a janela de sessão:
|
||||
/clear
|
||||
```
|
||||
|
||||
Agora crie o projeto. Como o GSD Core encontrou código existente no passo anterior, já sabe que se trata de um projeto brownfield. Quando você executa `/gsd-new-project`, as perguntas focam no que você está *adicionando*, e não em reconstruir o que já existe:
|
||||
Agora execute `/gsd-onboard` novamente. Se o GSD Core detectar ADRs, PRDs, specs, RFCs ou requisitos de nível raiz, aceite o handoff recomendado para `/gsd-ingest-docs` primeiro e depois rode `/gsd-onboard` de novo. Quando o contexto estiver pronto, o onboarding imprimirá o handoff de inicialização:
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
```
|
||||
|
||||
Como o GSD Core encontrou código existente no passo anterior, `/gsd-new-project` sabe que é um projeto brownfield. As perguntas focam no que você está *adicionando*, não em reconstruir o que já existe:
|
||||
|
||||
O GSD Core pergunta o que você quer construir. Responda com o recurso que está adicionando, e não com uma descrição de toda a base de código:
|
||||
|
||||
```text
|
||||
@@ -124,6 +126,8 @@ Proposed Roadmap
|
||||
|
||||
Aprove o roteiro.
|
||||
|
||||
Execute `/gsd-onboard` mais uma vez depois que a configuração do projeto terminar. Agora que `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md` e `STATE.md` existem, o onboarding cria ou confirma `.planning/onboarding/SUMMARY.md`.
|
||||
|
||||
**O que é criado em `.planning/`:**
|
||||
|
||||
```text
|
||||
@@ -133,7 +137,7 @@ Aprove o roteiro.
|
||||
ROADMAP.md ← Fase 1, status: pending
|
||||
STATE.md ← memória de sessão
|
||||
config.json ← configurações do fluxo de trabalho
|
||||
onboarding/SUMMARY.md ← onboarding status and next command
|
||||
onboarding/SUMMARY.md ← status do onboarding e próximo comando
|
||||
codebase/ ← os sete arquivos de mapa do Passo 3
|
||||
```
|
||||
|
||||
@@ -213,6 +217,7 @@ Para cada recurso futuro, execute `/gsd-map-codebase` novamente sempre que a est
|
||||
|
||||
## O que você aprendeu
|
||||
|
||||
- Como `/gsd-onboard` sequencia com segurança o setup brownfield sem aninhar comandos interativos ou sobrescrever planning existente.
|
||||
- Como `/gsd-map-codebase` executa quatro agentes paralelos para produzir `STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, `CONCERNS.md`, `STRUCTURE.md`, `TESTING.md` e `INTEGRATIONS.md` em `.planning/codebase/`.
|
||||
- Como `/gsd-new-project` em um repositório brownfield concentra as perguntas no que você está *adicionando* e preenche os requisitos Validated a partir do código existente.
|
||||
- Como o mapa da base de código orienta cada pergunta em `/gsd-discuss-phase` — caminhos de arquivos, padrões e convenções vêm do seu código real.
|
||||
|
||||
@@ -512,7 +512,8 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
│ ├── FEATURES.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ └── PITFALLS.md
|
||||
├── codebase/ # Brownfield mapping (from /gsd-map-codebase)
|
||||
├── codebase/ # Brownfield mapping (from /gsd-map-codebase or /gsd-onboard)
|
||||
├── onboarding/ # Brownfield onboarding summary (from /gsd-onboard)
|
||||
│ ├── STACK.md # YAML frontmatter carries `last_mapped_commit`
|
||||
│ ├── ARCHITECTURE.md # for the post-execute drift gate (#2003)
|
||||
│ ├── CONVENTIONS.md
|
||||
|
||||
@@ -273,10 +273,11 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
|
||||
## 安装后
|
||||
|
||||
重启您的运行时以加载新命令和代理。然后启动您的第一个项目：
|
||||
重启您的运行时以加载新命令和代理。然后启动新项目或接入现有仓库：
|
||||
|
||||
```bash
|
||||
/gsd-new-project
|
||||
/gsd-new-project # 新建项目
|
||||
/gsd-onboard # 现有代码库
|
||||
```
|
||||
|
||||
如果重启后找不到该命令，请确认安装目录与运行时预期的配置路径匹配。上方的预发布版章节介绍了最常见的路径不匹配情况。
|
||||
|
||||
@@ -23,6 +23,8 @@
|
||||
│ ├── architecture.md
|
||||
│ ├── stack.md
|
||||
│ └── ...
|
||||
├── onboarding/ # Brownfield onboarding 摘要（可选）
|
||||
│ └── SUMMARY.md
|
||||
├── intel/ # 可查询的符号索引（可选，intel.enabled）
|
||||
│ └── API-SURFACE.md
|
||||
└── phases/
|
||||
@@ -48,7 +50,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 规范的项目标识：项目内容、目标用户、核心价值、需求、约束和关键决策。随项目演进持续更新。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建）；由 `/gsd-complete-milestone` 在决策验证后更新。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建，包含 `/gsd-onboard` 交接）；由 `/gsd-complete-milestone` 在决策验证后更新。 |
|
||||
| **消费者** | 所有规划工作流；`gsd-phase-researcher`、`gsd-planner`（上下文）；`discuss-phase`（历史决策）；`gsd-plan-checker`（项目约束）。 |
|
||||
|
||||
### `ROADMAP.md`
|
||||
@@ -56,7 +58,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 里程碑与阶段列表，含目标、需求 ID、成功标准以及每个阶段的规范参考。是项目构建内容和顺序的唯一可信来源。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建）；由 `/gsd-phase --insert` 和 `/gsd-complete-milestone` 更新。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建，包含 `/gsd-onboard` 交接）；由 `/gsd-phase --insert` 和 `/gsd-complete-milestone` 更新。 |
|
||||
| **消费者** | `/gsd-discuss-phase`、`/gsd-plan-phase`、`/gsd-execute-phase`；所有需要阶段信息的编排命令；`gsd-planner`、`gsd-plan-checker`、`gsd-phase-researcher`。 |
|
||||
|
||||
### `REQUIREMENTS.md`
|
||||
@@ -64,7 +66,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 编号化、可勾选的项目验收标准。每条需求带有 ID（如 `AUTH-01`），映射到路线图阶段。随着阶段执行，逐步标记需求为已完成。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建）；需求由 `execute-phase` 标记为已完成。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建，包含 `/gsd-onboard` 交接）；需求由 `execute-phase` 标记为已完成。 |
|
||||
| **消费者** | `gsd-planner`（计划必须覆盖所有阶段需求 ID）；`gsd-plan-checker` 维度 1（需求覆盖）；`discuss-phase`（历史需求）。 |
|
||||
|
||||
### `STATE.md`
|
||||
@@ -72,7 +74,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 实时进度跟踪器——当前阶段与计划、进度指标、积累的决策、会话连续性说明。每次工作流运行时首先读取，每次重要操作后更新。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建）；由所有阶段工作流、`/gsd-pause-work`、`/gsd-resume-work` 持续更新。 |
|
||||
| **生成者** | `/gsd-new-project`（初始创建，包含 `/gsd-onboard` 交接）；由所有阶段工作流、`/gsd-pause-work`、`/gsd-resume-work` 持续更新。 |
|
||||
| **消费者** | 所有编排工作流；`/gsd-progress`；通过 `/gsd-quick` 执行的临时任务；`gsd-planner` 和 `gsd-phase-researcher`（项目决策）。 |
|
||||
|
||||
完整字段参考请参见 [STATE.md 模式](state-md.md)。
|
||||
@@ -87,6 +89,14 @@
|
||||
|
||||
完整模式请参见 [CONFIGURATION](../CONFIGURATION.md)。
|
||||
|
||||
### `onboarding/SUMMARY.md`（可选）
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | Brownfield onboarding 索引，记录产物状态、代码库映射是否完整，以及初次设置后的下一个推荐 GSD 命令。 |
|
||||
| **生成者** | `/gsd-onboard`，在 `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md` 和 `STATE.md` 全部存在后生成。 |
|
||||
| **消费者** | 审查初次设置的人；以后确认现有 onboarding 状态的 `/gsd-onboard` 运行。 |
|
||||
|
||||
### `MILESTONES.md`（可选）
|
||||
|
||||
| | |
|
||||
|
||||
@@ -46,7 +46,7 @@ claude --dangerously-skip-permissions
|
||||
|
||||
## 第 3 步 — 开始 brownfield onboarding
|
||||
|
||||
在创建项目之前，先让 GSD Core 了解已有的内容。这是使棕地规划准确的关键步骤。
|
||||
在创建项目之前，让 GSD Core 检查仓库状态并告诉您安全的下一个顶层命令。这一步可避免跳过代码库上下文或覆盖现有 planning 文件。
|
||||
|
||||
```text
|
||||
/gsd-onboard
|
||||
@@ -84,7 +84,7 @@ Created .planning/codebase/:
|
||||
|
||||
---
|
||||
|
||||
## 第 4 步 — 清除上下文并创建项目
|
||||
## 第 4 步 — 重新运行 onboarding 并初始化项目
|
||||
|
||||
清除会话窗口：
|
||||
|
||||
@@ -92,12 +92,14 @@ Created .planning/codebase/:
|
||||
/clear
|
||||
```
|
||||
|
||||
现在创建项目。由于 GSD Core 在上一步中发现了现有代码，它已经知道这是一个棕地项目。当您运行 `/gsd-new-project` 时，问题将聚焦于您所*新增*的内容，而非重新描述已有的内容：
|
||||
现在再次运行 `/gsd-onboard`。如果 GSD Core 检测到 ADR、PRD、spec、RFC 或根级需求文档，请先接受推荐的 `/gsd-ingest-docs` 交接，然后再运行 `/gsd-onboard`。上下文准备好后，onboarding 会打印项目初始化交接命令：
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
```
|
||||
|
||||
由于 GSD Core 在上一步中发现了现有代码，`/gsd-new-project` 知道这是一个棕地项目。问题将聚焦于您所*新增*的内容，而非重新描述已有的内容：
|
||||
|
||||
GSD Core 会询问您想构建什么。请用您正在添加的功能来回答，而不是描述整个代码库：
|
||||
|
||||
```text
|
||||
@@ -124,6 +126,8 @@ Proposed Roadmap
|
||||
|
||||
批准路线图。
|
||||
|
||||
项目设置完成后，再运行一次 `/gsd-onboard`。现在 `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md` 和 `STATE.md` 都已存在，onboarding 会创建或确认 `.planning/onboarding/SUMMARY.md`。
|
||||
|
||||
**在 `.planning/` 中创建的内容：**
|
||||
|
||||
```text
|
||||
@@ -133,8 +137,8 @@ Proposed Roadmap
|
||||
ROADMAP.md ← Phase 1, status: pending
|
||||
STATE.md ← session memory
|
||||
config.json ← workflow settings
|
||||
onboarding/SUMMARY.md ← onboarding status and next command
|
||||
codebase/ ← the seven map files from Step 3
|
||||
onboarding/SUMMARY.md ← onboarding 状态和下一个命令
|
||||
codebase/ ← 第 3 步生成的七个映射文件
|
||||
```
|
||||
|
||||
注意 `.planning/codebase/` 已经从第 3 步存在。GSD Core 在编写 `PROJECT.md` 时读取了这些文件，这就是为什么它无需您描述即可填充已验证的需求。
|
||||
@@ -213,6 +217,7 @@ Proposed Roadmap
|
||||
|
||||
## 您学到了什么
|
||||
|
||||
- `/gsd-onboard` 如何安全编排 brownfield 设置，不嵌套交互式命令，也不覆盖现有 planning 文件。
|
||||
- `/gsd-map-codebase` 如何运行四个并行代理，在 `.planning/codebase/` 中生成 `STACK.md`、`ARCHITECTURE.md`、`CONVENTIONS.md`、`CONCERNS.md`、`STRUCTURE.md`、`TESTING.md` 和 `INTEGRATIONS.md`。
|
||||
- 在棕地仓库中运行 `/gsd-new-project` 如何将问题聚焦于您所*新增*的内容，并从现有代码中填充已验证的需求。
|
||||
- 代码库映射如何塑造 `/gsd-discuss-phase` 中的每个问题——文件路径、模式和规范均来自您的实际代码。
|
||||
|
||||
Reference in New Issue
Block a user