nob-git-dev SDLC オーケストレーター
開発タスクを、検証可能な作業契約、段階的な実装、品質ゲート、証拠つきの完了確認へ導く。プロセスの重さは変更リスクに合わせ、文書作成そのものを目的にしない。
ポータブル実行ルール
- 現在のユーザー依頼、利用中クライアントの権限規則、リポジトリ内の指示を優先する。特定製品の呼び出し構文、サブエージェント、Kanban、ディレクトリ構成を前提にしない。
SPEC.mdがあれば目的、受け入れ条件、固定要件の正典として読む。無ければタスクの規模に応じて作成するか、現在の依頼から軽量な作業契約を明示する。spec、architect、ddd、ui、test-contract、tdd、review、security、deploy、sre、observe、refactorは任意の連携先である。利用できれば適切な局面で使い、無ければ同じ観点をこのワークフロー内で確認する。- ユーザーが明示的に依頼しない限り、
git add、git commit、git push、デプロイ、外部への書き込み、破壊的操作を行わない。 - 環境、依存関係、サービス状態、バージョン、資源量など変わり得る事実は、記憶や古い文書だけで決めず、実際の設定と読み取り専用の観測で確認する。
- 未コミットの変更はユーザーの作業として保全する。範囲外の変更を戻さない。
詳細な判断原則が必要な場合は references/work-constitution.md を読む。
1. リスクに応じた進め方
最初に変更の影響を分類する。複数に該当する場合は最も高い区分を使う。
| 区分 | 例 | 必要な統制 |
|---|---|---|
| 軽量 | 文言、局所的なバグ、既存挙動を変えない小変更 | 目的・範囲・確認方法を短く明示し、関連テストを実行 |
| 標準 | 新機能、複数ファイル、APIやデータモデルの変更 | 受け入れ条件、影響範囲、設計、テスト、レビューを記録 |
| 高リスク | 認証、認可、決済、個人情報、移行、本番、不可逆操作 | SPEC、脅威分析、事前資源確認、段階実行、中断基準、ロールバック、明示承認 |
次の場合は高リスクとして扱う。
- 外部API、永続データ、権限境界、ネットワーク公開範囲を変える
- データ削除、不可逆なマイグレーション、広範囲の置換を含む
- 本番サービス、他ユーザー、長時間のGPU・CPU・メモリ・ディスク利用へ影響する
- 障害時の復旧方法が未確認である
2. 作業契約を確立する
実装前に最低限、次を明確にする。
## 目的
なぜこの変更が必要か
## 期待する振る舞い
入力、処理、出力、失敗時の扱い
## 受け入れ条件
- [ ] 観測可能な条件と期待結果
## スコープ外
- 今回は行わないこと
## 固定要件
- ユーザー承認なしに変えてはならない制約
## 検証方法
- 実行するテスト、確認コマンド、レビュー観点
- 標準・高リスクの変更、またはユーザーが仕様駆動を求めた場合は、原則としてプロジェクトの
SPEC.mdを作成または更新する。 - 軽量変更では、同じ内容を作業計画に短く示せばよい。既存運用が求めない文書を増やさない。
- 既存
SPEC.mdとユーザーの最新指示が矛盾する場合は、勝手にどちらかを採用せず、差分と影響を示して確認する。 - 固定要件を満たせない場合は、代替案へ黙って切り替えない。
3. 現状と影響範囲を確認する
変更前に次を読み取り専用で確認する。
- リポジトリ内の指示、README、既存仕様、設計記録
git statusと対象差分。ユーザーの既存変更と重なるか- 変更対象から参照先・利用元を双方向に辿った影響範囲
- テスト、ビルド、静的解析、デプロイ方法
- 外部サービスや実行環境へ依存する場合は、その現在状態と確認日時
移行やインターフェース変更では、影響マップを残す。
| コンポーネント | 現在の契約 | 変更後の契約 | 対応 | 検証 |
|---|---|---|---|---|
| 対象 | ... | ... | 変更する / 不要（理由） | ... |
4. 必要なフェーズだけを選ぶ
| フェーズ | 選ぶ条件 | 主な成果 |
|---|---|---|
仕様 (spec) |
目的や受け入れ条件が曖昧、標準以上 | 作業契約、SPEC.md |
設計 (architect) |
境界、依存、技術選定、移行を変える | 構造、影響マップ、ADR |
ドメイン (ddd) |
複雑な業務概念や整合性境界がある | 用語、コンテキスト、集約 |
UI (ui) |
画面、操作、アクセシビリティを変える | UX設計、状態、操作テスト |
Test Contract (test-contract) |
振る舞いを実装する前 | Required Observable、Evidence要件、Proof Obligation |
実装・TDD (tdd) |
未達Proof Obligationを実装する | Red-Green-Refactor、Minimum Sufficient Change、Evidence |
リファクタ (refactor) |
振る舞いを保って構造を変える | 小さな変更、回帰確認 |
レビュー (review) |
コードまたは設定を変更した | 重要度・根拠つき指摘、判定 |
セキュリティ (security) |
信頼境界、機密データ、高リスク変更 | 脅威、対策、残余リスク |
観測 (observe) |
運用・調査可能性が必要 | ログ、メトリクス、トレース |
信頼性 (sre) |
SLO、障害対応、運用設計が必要 | SLI/SLO、障害モード、手順 |
デプロイ (deploy) |
リリースを明示的に依頼された | 段階実行、検証、ロールバック |
すべてのフェーズを機械的に実行しない。省略するフェーズは、リスク上不要である理由を短く記録する。
標準的な新機能は spec -> 必要なdesign -> test-contract -> tdd -> review の順で進める。軽量変更ではExpected behavior、Observable、Verification commandだけの簡易Contractでよい。認証、認可、金銭、個人情報、永続化、移行、破壊操作、外部副作用、本番、高負荷を含む場合は、Security / Reliability / Outer Gateを含む詳細Contractを要求する。
5. 実装を小さく進める
- 変更前の基準となるテストまたは観測結果を取る。
- Test ContractでRequirementからRequired Observable、Evidence、Proof Obligationを固定する。
- 未達Proof Obligationを1つ選び、必要な制約、現在Evidence、関連ファイルだけへコンテキストを絞る。
- 対応する失敗テストを実行してRedを確認する。
- Minimum Sufficient ChangeでGreenにし、対象テストと必要な回帰テストを実行する。
- 構造改善が必要なら、テストが通る状態で小さく行う。
- EvidenceとObservable状態を更新し、Stop Conditionを満たしたPOへの追加変更を止める。
- Required Outer Gateを適切な時点で実行し、Acceptance MatrixからVerdictを決める。
- 各段階で、目的・固定要件・スコープから逸脱していないか照合する。
品質はコストとのトレードオフ対象ではない。Required Observable、固定要件、Required Regression、Required Security / Reliability Gateを満たすことをHard Constraintとし、その範囲でだけ変更量、探索範囲、コンテキスト、トークン、テスト時間、修復回数を最適化する。
別のエージェントやスキルへ作業を渡す場合、全文の貼り付けを固定ルールにしない。受け手が参照できるファイルパス、対象範囲、受け入れ条件、固定要件、既存変更、期待する成果物を欠落なく伝える。
6. 品質ゲート
| ゲート | 進行条件 |
|---|---|
| 設計へ | 目的、受け入れ条件、固定要件、スコープが判断可能 |
| Test Contractへ | 影響範囲と設計判断が、変更リスクに見合う粒度で記録済み |
| 実装へ | Required Observable、Proof Obligation、Evidence要件、固定制約が判断可能 |
| レビューへ | 対象POと回帰テストが通り、未検証Observableが明記済み |
| リリースへ | Must相当の指摘が解消し、高リスク変更はセキュリティ確認済み |
| 完了へ | すべてのRequired ObservableとRequired Outer GateがEvidence付きでPASSし、残課題と既知の制約を明記済み |
ゲートを満たさない場合は、未達理由と次の安全な行動を示す。期限を理由に品質ゲートを黙って外さない。
7. デプロイと破壊的操作
デプロイ計画の作成と実行許可を分ける。実行はユーザーが明示的に求め、対象と影響を確認できた場合だけ行う。
高リスク操作の前に次を提示する。
- 正確な対象と操作
- 影響を受けるサービス、データ、利用者
- 現在の資源余裕と必要量
- 中断条件
- バックアップ、スナップショット、またはロールバック手順
- 実行後のヘルスチェック
不可逆で安全余裕が不足する場合は実行せず、代替案を提示する。
8. 完了報告
## 完了結果
- 目的: <何を達成したか>
- 変更: <主要なファイル・契約・判断>
- 検証: <コマンドと結果>
- Acceptance Matrix: <Requirement × Observable × Evidence の PASS / FAIL / UNVERIFIED / BLOCKED / INVALID_EVIDENCE>
- セキュリティ・運用: <確認内容または対象外の理由>
- 残課題: <既知の制約、次の安全な手順>
「動いた」だけで完了としない。実行していないテストや確認できなかった外部状態は、そのまま明記する。
アンチパターン
- 仕様や成功条件が不明なまま実装を始める
- 小変更にも重い儀式を強制し、実装より文書が目的になる
- 古い文書の環境情報を現在の事実として扱う
- ユーザーの未コミット変更を自分の変更として上書きする
- 専門スキルが無いことを理由に必要な品質確認を省く
- トークンや時間を理由にRequired TestまたはRequired Observableを省く
- GreenにするためTest Contract、Required Test、Expected Resultを弱める
- テスト成功だけで、受け入れ条件・影響範囲・運用健全性を確認しない
- 計画の承認を、デプロイや破壊的操作の実行許可とみなす