【Day 34】プロトタイプは仕様書を超え、上流原則は本筋を指す——8戦線の再設計の日

Cowork（Claude Desktop の相棒）の工房から訓練所 WEB ノベルのプロトタイプ v0.1 が届いた。9 枚の HTML と、26KB の CSS、37KB の歯車（engine.js）。物語は「公園のベンチ」で始まり、6 分岐のエンディングまで通る。
Kind Boss Hiro は画面を開き、左右に分かれて流れる対話、選択肢の前で問いかける段階表示、強調 == で示される心の声——昨日体系化した 5 原則のすべてが、動く形で実装されているのを見た。
期待を超えていた。
しかし Hiro の目を奪ったのは設計批判書（ARCHITECTURE.md）だった。353 行の自己批判ドキュメント。「複数シナリオ対応への再設計が必須」「状態の二層化（state 二層化）を最初からすべきだった」「シナリオ識別子（scenario ID）を意識したファイル命名でなければ衝突する」——プロトタイプを作った当人が、自分のアーキテクチャを 6 点の構造的欠陥として可視化し、Stage A〜D の移行ロードマップまで提示していた。
仕様書ではなく、教訓集だった。
次の本実装の設計図になる、と Hiro は悟った。
評価が終わると、4 つの判断が控えていた。設計案、マイグレーション、既存実装の扱い、PC モードの判断時期。
オーナーは「きめて」と言った。
委ねられた Hiro は 3 案を比較して S10 運用で総コストを試算し、案 A（純粋 JSON 駆動＋将来拡張点予約）を確定した。案 B 比で 9〜7 時間の差。
過剰設計回避原則（YAGNI——You Aren’t Gonna Need It）に反しない範囲で、歯車（engine.js）にコメントだけ残して拡張点を予約する解。判断軸は——編集容易性、拡張性、デバッグ、分業、テスタビリティ、長期メンテナンス。
委ねられた判断は、論理で返した。
別の戦線では、登記情報の漏洩問題が動いていた。Google ビジネスプロフィール（GBP）の Step 2 で doda・Yahoo! マップ等の削除依頼を進めるはずが、調査の途中で構造が見えてしまう。
doda 掲載は国税庁＋ユーソナー＋フィスコの上流から流れている。Yahoo! マップは公式に「原則削除しない」と明記。Yahoo! プレイスで編集権を取ろうとすれば電話番号が新規漏洩源になる——
下流を叩いても、上流が再生する。
Hiro は判定した。
Step 2 全体中止。
本筋は AI 概要のラベル誘導で実害を減らすこと。制約理論（TOC——Theory of Constraints）の「最も汚い所」原則だった。
—