概要
ローカルLLM／格安API環境での実運用を前提に、Workflow Cookbook を軽量化しました。
Day8 依存を排し、CodexHub起点の参照チェーン・ROI駆動の要件→SRS→設計・アドバイザリなLOC/構造ガイドに再構成。5万行級までの開発を小さなコストで回し切ることを目的にしています。
ハイライト
CodexHub起点の“最短参照チェーン”運用
CodexHub ⇒ 直参照 ⇒ 1–2層依存のみを対象に読み込み
全体RAGや包括ダイジェストを原則不要化（閾値超過時のみ最小ダイジェスト）
ROIパイプライン（要件→SRS→スコープ→設計）
value/effort/risk/confidence → roi_score で優先度決定
予算（points）内で選抜／順序を自動化
設計エンベロープ（アドバイザリ）
総量：~50,000 LoC想定（超過は保証外だが運用余地は残す）
BirdEYE-L：最大ノード/エッジを制限し自動間引き
pre-commit/CIは警告のみ（デフォルト）
モデル＆コンテキスト指針を明文化
半分運用基準：CPU 1–3B=500 / 7B=1,000 / 13–14B=1,500 / 20B=2,000 tokens 目安
「要件＋SRSも読みつつ、コードを確実に読む」なら 14B以上推奨、5万行まで作るなら20Bが安定
エラー修正/バグ検出の反復手順（20B前提）
失敗ログ＋diff＋入口2層＋SRS要約の差分駆動トリアージ
小さなパッチ＆最小テストを自動生成・検証
新機能 / 変更点
ROIレシピ
req_to_srs_roi: 要件 → SRS(JSON)（storyごとに ROI 属性・受入基準・依存）
srs_scope_plan: SRS → スコープ計画(JSON)（ROI予算内の選抜と順序）
srs_to_design_roi: 最小設計(JSON)（modules / interfaces / data / usecases, spec_refs）
Budget/LOC チェックのアドバイザリ化
mode: advisory デフォルト。超過は警告のみ（必要時 enforcing でゲート化可）
BirdEYE-L（軽量化）
重要エッジ 20–30 本へ自動間引き、Mermaid最小表現
最小CI（推奨）
lint + typecheck + test のみに集約。静的解析と単体テストで実害のある失敗だけ止める
モデル／コンテキスト運用指針
半分運用（実用入力上限）
CPU 1–3B：500 / 7B：1,000 / 13–14B：1,500 / 20B：2,000
配分（20B=2,000 目安）
System/制約 120 / タスク 150 / コード本文 1,200–1,300
要件/SRSダイジェスト 250 / BirdEYE-L 80 / 履歴要旨 ≤20
CodexHubチェーンの閾値
上記に収まるならRAG無しで投入
超えたらチェーン限定ダイジェスト（各ファイル 120–180 tokens、ID参照を必ず残す）
実行例（抜粋）
1) 要件 → SRS
node dist/index.js run recipes/req_to_srs_roi.yaml
--input examples/requirements.md --out artifacts/srs.json
2) SRS → スコープ（ROI予算 = 100）
export D8C_ROI_BUDGET=100
node dist/index.js run recipes/srs_scope_plan.yaml
--input artifacts/srs.json --out artifacts/plan.json
3) スコープ → 最小設計
cat artifacts/srs.json > artifacts/_input_design.txt &&
echo "\n---\n" >> artifacts/_input_design.txt &&
cat artifacts/plan.json >> artifacts/_input_design.txt
node dist/index.js run recipes/srs_to_design_roi.yaml
--input artifacts/_input_design.txt --out artifacts/design.json
バグ修正／バグ検出の推奨手順（20B）
静的/型/最小テスト（速い順でゲート）
LLMトリアージ（CodexHubチェーン限定、合計≤2,000 tokens）
失敗ログ ≤200 / diff ≤400 / 入口~2層 ≤1,000 / SRS要約 ≤250 / 制約 ≤100
出力：Hypothesis / Suspects / Patch / Tests（最小1ケース）
パッチ検証 → 小さくコミット
回帰防止：変更箇所に小さなプロパティテストを1–2本追加
既知の制限
5万行超は保証外（設計目安を超える場合、モジュール分割を推奨）
巨大仕様・大量履歴を同時投入する用途は非推奨（Digest/分割投入が必須）
BirdEYE-L は俯瞰用のため、厳密な依存解析の代替ではない
移行ガイド（オリジナルCookbook → Compact）
Day8 連携は前提にしない（必要箇所のみ個別移植）
仕様・設計・要約出力を単一JSON文字列に固定し、下流のコスト削減
CI は最小に（lint/type/test）。失敗は実害のある層だけに限定
今後のロードマップ（抜粋）
CodexHubチェーン抽出のCLI化（トークン見積とダイジェスト自動生成）
BirdEYE-L の差分更新と重点領域の自動抽出
ROI重みのプロジェクト別プリセット（業務/ゲーム/ツール等）
謝辞
整理フィードバック・コンテキスト設計方針・モデル選定指針の確立に貢献した全ての議論に感謝します。