機能追加・バグ修正のワークフロー。類似プロダクト調査→要件整理→テスト→実装→確認を一貫して行う。 「実装して」「追加して」「修正して」「対応して」「機能を作って」「バグを直して」等、 コード変更を伴う指示で発動。
$ARGUMENTS を実装する。
調査 → 要件整理 → テスト → 実装 → 確認 の順で進める。 テストはリグレッション防止を目的とし、可能な限り高いレイヤーで書く。
バグ修正の場合、推測で修正するな。 コードレビューだけで原因を断定せず、ログで実際の動作を検証する。
log を使わない: リングバッファに溜めて UI スレッドで吐くか、一時的なデバッグ用途に限定特に CLAP プラグインの初期化処理（create → init → activate → start_processing）は、? や .ok() でエラーが握りつぶされて初期化自体が失敗しているケースがある。各ステップの成功を個別に検証する。
バグ修正ではない機能追加の場合はこのステップをスキップしてよい。
推測で実装するな。 まず正しい振る舞いを調査してから実装する。
以下のいずれかに該当する場合、/research-similar-impl スキルを呼び出して
類似プロダクト（clap-host, clack, nih-plug, Meadowlark 等）の実装を調査する:
| 該当条件 | 例 |
|---|---|
| 「○○みたいに」「○○と同じように」と参考プロダクトが指定されている | 「Renoise みたいにオートメーションを曲線で」 |
| CLAP 仕様に関わる機能 | プリセット読込、thread pool、latency、tail、tuning 拡張 |
| DAW として一般的な機能 | ピアノロール、ミキサー、バス、テンポオートメーション |
| 正しい振る舞いが MIDI / CLAP 仕様に依存する | ノートオフ、ピッチベンド、MPE、時刻順イベント |
調査で以下を明らかにする:
該当しない場合（内部リファクタリング、単純なバグ修正等）はスキップしてよい。
調査結果と既存コード（Read/Grep で確認）をもとに、要件を整理する。
| 観点 | 問いかけ |
|---|---|
| 正常系 | 基本入力に対して何を返す／何が起きるべきか？ |
| エッジケース | 空レーン、0 トラック、サンプルレート変更、バッファサイズ変更、idle 状態、プラグイン未ロード |
| RT 安全性 | 再生スレッドのホットパスで new / lock / I/O を増やしていないか？ |
| 既存機能との相互作用 | Undo、保存／復元、オートメーション、サイドチェインに影響しないか？ |
| 類似プロダクトとの一致 | 調査した振る舞いをカバーしているか？ |
要件一覧をユーザーに提示し、過不足がないか確認を取る。 ユーザーの承認を得てから次のステップに進む。
承認された要件をもとに、統合テストを書く。
以下のすべてに該当する場合、テスト作成をスキップして実装に進んでよい:
可能な限り高いレイヤーでテストする。上から順に検討し、最も高いレイヤーを選ぶ。
| レイヤー | 方法 | 例 |
|---|---|---|
| コマンド層 | command/* を直接呼び出して Song / SongState の変化を検証 | トラック追加、プラグインロード、song 保存/復元 |
| モデル操作 | Song / Track / Lane / LaneItem のメソッドを呼び状態を検証 | 区間のコピー/ペースト、undo/redo、イベント順序 |
| 純粋ロジック | 関数に入力を与え、出力を検証 | 式評価 (eval.rs)、DSP (dsp.rs)、ACP 変換、BPM/サンプル変換 |
テストが重い（CLAP プラグインのロードが絡む等）場合は、モックプラグインまたはテスト用の PluginRef 差し替えを検討。
assert_eq! で具体的な値を検証する（starts_with() や > 0 は使わない）TestSong 等）を積極的に作り、Arrange を簡潔に保つテスト対象の関数・構造体がまだ存在しない場合は、コンパイルが通る最小スタブを追加してよい。スタブはデフォルト値を返す空実装とする。
cargo test --workspace
テストが通るように実装する。
ガイドライン:
command/ / model/ / view/ の責務分離）? を安易に ok() にしないcargo test --workspace
新規テスト・既存テスト全てが通ることを確認する。 失敗するテストがあれば実装を修正する。
全テストが通った状態で、コードを整理する。
OK: リネーム、関数抽出、重複排除、clippy 警告修正、テストヘルパー整理
NG: 新機能追加（次のサイクルでやる）
リファクタリング後も全テストが通ることを確認する。
/review スキルを呼び出し、変更箇所のパフォーマンス・セキュリティ・RT 安全性をチェックする。
cargo test --workspace
cargo clippy --workspace -- -D warnings
git add <変更ファイル>
git commit -m "○○を実装"
実装中にテストの期待値が間違っていると判断した場合:
#[ignore] でテストをスキップしない