Wu5 Dev Flow

Wu5 Dev Flow は何をしますか？

開始手順

1. プロジェクトルートから python <このスキルのディレクトリ>/scripts/wu5_flow.py status を実行します。
2. 初期化されていない場合は init を実行します。初期化後、spec/index.md、spec/status.md、および関連仕様を最初に読んでください。
3. spec/state.json の現在のフェーズに従ってください。チャットの記憶に頼ってプロジェクトの状態を代替しないでください。
4. 書き込み操作の前に SDD ワークフロー を読んでください。Python コードに関わる場合は、Python TDD と ハードコード禁止ポリシー も読んでください。コミット、プッシュ、または PR に関わる場合は Git ポリシー を、レビューに入る場合は レビューポリシー を読んでください。

基本制約

• 最初に仕様を確認し、次に計画を承認し、最後に実装します。ユーザーが明示的に「ベースライン承認」「仕様承認」「計画承認」「依存関係承認」「緊急修正承認」と言った場合のみ、対応する承認を記録できます。
• 完全な変更には厳格に 2 回の人間によるゲートが必要です。軽微な変更は、振る舞いを伴わない低リスクのドキュメント、コメント、フォーマット、設定の調整のみに限定されます。範囲が拡大した場合は直ちにアップグレードします。
• テスト可能なコードには RED-GREEN-REFACTOR を適用します。期待される失敗を観測する前にビジネスロジックを実装してはなりません。新鮮な検証証拠なしにコミットや完了宣言をしてはなりません。
• 同一リポジトリ内では、進行中の変更は 1 つだけ許容されます。ダーティワークスペースを検出した場合は分析のみ行い、自動的に stash、reset、上書き、削除は行いません。
• データベース構造や不可逆なデータマイグレーションは、このスキルの実装範囲外です。発見した場合は一時停止し、ユーザーに説明します。
• .env、秘密鍵、トークン、資格情報、実際の機密データを読み取り、記録、またはコミットしてはなりません。
• 不適切なハードコードは禁止です。秘密鍵、環境差分、パス、URL、ビジネス閾値、可変ポリシーを実装に直接ハードコードしてはなりません。ハードコードポリシーに従い、設定、名前付き定数、依存性注入を使用してください。
• 承認済みのローカルアトミックコミットは自動的に作成できます。プッシュ、PR 作成、マージ、ブランチ削除、および強制プッシュは、それぞれ明示的な承認が必要です。

状態機械

以下の順序で進行します:

uninitialized → baseline-review|ready → drafting-spec → drafting-plan → implementing → verifying → ready-to-archive → ready-to-push

• 既存プロジェクトは baseline-review で「ベースライン承認」を得る必要があります。
• approve spec は proposal.md、spec.md、design.md のコンテンツハッシュを記録します。
• approve plan は plan.md、test-plan.md のコンテンツハッシュを記録します。
• 承認済みファイルが変更された場合、その承認と下流の承認を無効にし、実装を停止します。
• タスクの進捗は state.json/status.md に書き込みます。承認済みの計画ドキュメントは変更しないでください。

ゲートスクリプトの使用方法

wu5_flow.py init
wu5_flow.py new <slug> --type <type> --mode <full|light|hotfix>
wu5_flow.py status
wu5_flow.py approve <baseline|spec|plan|dependency|hotfix>
wu5_flow.py check <implement|commit|push|archive>
wu5_flow.py verify <targeted|affected|full>
wu5_flow.py archive <slug>
wu5_flow.py doctor

コミットするファイルをステージングしてから check commit を実行してください。スクリプトはテンプレートの作成、公開状態の維持、プロジェクト設定の品質コマンドの実行、ゲートの検証のみを行います。仕様、設計、テスト、レビューの結論は人間と AI が共同で管理する必要があります。

完了基準

• 現在の要件はすべてテストにマッピングされ、pytest と pyright が通過していること。プロジェクトで ruff が有効な場合はそれも通過していること。
• 完全な変更は、仕様準拠性とコード品質の 2 回のレビューを完了していること。高リスクの変更は、レビューポリシーに従い独立したエージェントを呼び出すこと。
• 不適切なハードコードが導入されていないことをレビューおよび確認していること。合理的なプロトコル固有の定数は名前化、説明、テストされていること。
• verification.md には、コマンド、終了コード、時刻、コンテンツフィンガープリント、2 回のレビュー、および未解決の技術的負債が含まれていること。
• features/ が現在の有効な振る舞いに更新され、変更がアーカイブされ、最終的なドキュメントコミットが作成されていること。
• PR のサマリは仕様をリンクし、要件とテストのマッピング、検証証拠、リスク、負債をリストアップしていること。