強化層 Go/No-Go 判定書（Phase 5 Task 26・2026-09-09）
spec §強化層「Phase 5の実測データでGo/No-Go判断・現時点で実装約束なし」に基づく判定。 計測データ:
artifacts/harness/metrics.json（collect_harness_metrics.py 出力）+ Task 24 run1 stdout 記録。 サンプルサイズの明示: 実プロバイダ run n=3（run1-3）+ checkpoint n=3。spec 自身が適応閾値に「最小サンプル10」を定めており、多くの項目は「否定」でなく「データ不足」の No-Go である点を前提とする。
計測データ（2026-09-09 実測）
| 指標 | 値 | 出典 |
|---|---|---|
| 429頻度（代理=breaker OPEN） | 0 | metrics.json（全run CLOSED・opened_at null） |
| ブレーカ遷移 | 0回 | 同上 |
| ask応答時間 p95 | 未計測 | 計装未実装 |
| checkpoint失敗率 | 0/3 (0.0) | metrics.json |
| abort分布 | limits=2 / none=2 | 同上（limitsの1件はWeb UIスモーク） |
| トークン量/タスク | mean 44,066 / max 167,899 / min 50 | 同上・run1=426,045 はstate破壊で欠落（stdout証跡で保管） |
各強化層項目の判定
| # | 項目 | 判定 | 理由（実測紐付け） | 再評価条件（これが起きたらGo再考） |
|---|---|---|---|---|
| 1 | 3層トークン/レートソフトリミット | No-Go | トークン爆発（426k）の原因はLLM予算超過でなくタスク文のcwd欠落による探索迷走（絶対パス明記で426k→8.2k〔52x差〕を再現実測）。429=0件でレート層の発火事例がない | 実運用で429≥1 または run数≥10 到達時 |
| 2 | 適応閾値+最小サンプル10 | No-Go | n=4 < spec自身の最小サンプル10。abort limits は全て予算消費の期待動作（80% warn→90% abort が設計どおり作動・run1で実観測） | run n≥10 かつ固定閾値での過不足が観測された時 |
| 3 | TTL付きcapability | No-Go | capability不整合による事故0件。provider_insecure_default の deepseek がcapability登録済みで3run全て正常実行 | provider追加・capability誤判定の初事故時 |
| 4 | 動的resumeバジェット+resume回数上限3回 | No-Go | resume発動0回。ただし本日、resume state破壊の実害（Web UI汚染）を発見・修正済み（run_state_webui.json分離）— resume基盤そのものの防御は強化された | 中断→resumeの実戦発動が月1回超えた時 |
| 5 | トークンバケット適応制御 | No-Go | 実測の52x効率差は入力コンテキスト品質に由来しバケット制御では捕捉不能（下記Go-1が本質対策） | 同#1 |
| 6 | Chaos/Property-basedテスト | 条件付きNo-Go | fail-closed経路は単体+E2Eで実測済み（ask timeout→deny をrun1で本番観測・deny_patterns はTask 20テスト）。未知の破綻モードが溜まっていない | 並行運用開始・プロバイダ数増加時 |
| 7 | 通知3重化の完全版 | No-Go | 現行は人間付き添い運用（CLI JSON+監視cron）。abort検知の遅延実害が未発生 | harness を自己駆動ループへ投入（無人化）する時 |
| 8 | 並行実行時トークン予約 | No-Go | 並行harness実行は未実施（state分離〔本日〕で排他基盤の一部は準備済み） | 並行run運用開始時 |
Go 判定（実測根拠つき・plan外のMVP改修3点）
| # | 項目 | 判定 | 根拠 |
|---|---|---|---|
| G-1 | 実行コンテキスト初期注入（cwd/リポジトリパスをシステムプロンプトへ組込み） | Go（最優先） | run1→run2 の差分実測: タスク文への絶対パス明記だけで 426k/aborted → 167k/完遂（steps 22→8）。ハーネス側に組み込めば発注者に依存しない防御になる。aborted: limits の実害も同一原因 |
| G-2 | ask応答時間の計装（AskSession に着手〜応答の時間記録） | Go（S） | 計測6項目の1つが恒常的に欠落＝計測不能のまま判定書を書く構造が今回で実証済み |
| G-3 | ask実行標準手順のスクリプト化（script疑似TTY+継続yフィーダのラッパー） | Go（S） | パイプ一括投下は ask 初期消費で全滅（run1実測）→ 10s間隔フィーダで全承認成功（run2/3実測）。手順が文書化されず再現できない状態を解消 |
結論
- 強化層9項目: 全て現時点 No-Go（実害が未発生か、サンプル不足。いずれも再評価条件を明記・判定書の一部として保持）
- plan外 MVP 改修3点（G-1〜G-3）: Go — 実測根拠（52x効率差・計測欠落・再現不能手順）が直接の根拠で、強化層より先に着手する価値が実証された
- 次フェーズ計画: G-1〜G-3 を Task 27 クロージングの残課題として起票し、強化層は再評価条件発火まで凍結
判定の反証観測（この判定が誤りと分かる観測）
- 「426k爆発はcwd欠落でなくモデル/タスク固有」と主張するなら、cwd明記済みでも同規模爆発が再現する観測で反証される（本判定は52x差をパス明記のみで反転させた対照観測に立脚）
- 「強化層が先でも良かった」と主張するなら、強化層が防げるはずの事象（429・breaker OPEN・resume破壊の頻発）が実測で発生しかつ G-1〜G-3 で防げなかった観測が必要