📖 補強2+4採用と4セル検証+1週間試験運用 ― symlinkの想定外UNC解決との付き合い方

「WindowsからWSLのプロジェクトを触るとき、symlinkで繋いでおけば楽だろう」――そう考えた設計が、ある日牙を剥いた。設計ではWindows側とWSL側で同じリポジトリを編集できる前提だったが、検証してみたら4セル全部が想定外の挙動でFAIL。設計と現実の間に深い溝があった。

そもそも補強1〜3は「Windows ⇔ WSLのsymlinkを成立させ、共通ファイル編集の摩擦を下げる」目的で実行済みだった。補強4でReadOnly属性を足し、補強2で1週間の試験運用期間を設ける――という改訂案を3機（MiniMax・Gemini・OpenRouter）のレビューに掛けたところ、補強2+4の吟味保留という判断が返ってきた。「吟味保留」自体は珍しくはないが、3機一致で揃ったのは設計の前提そのものを疑うべき時だと判断の合図になる。

4セル検証で何が起きたか。設計が意図した「symlink経由でWindowsがWSLのclaude-configを編集する」経路は、実はcmd.exeが\\wsl.localhost\Ubuntu\...というUNC形式でリポジトリを解決し、obsidian-ssot側のファイルを触っていた。symlinkの向こう側に想定外のリポジトリが居座っていたのだ。設計は「同じリポジトリを扱う」と信じるが、現実のcmdは別の場所に迷い込む。4セル＝全FAILは、偶然ではなく構造的な問題の証拠だった。

補強2（1週間試験運用）と補強4（4セル縮小版実装）を採用し、ReadOnly属性で書き込みを制限し、30日後（2026-11-07）に再吟味するリマインダーをSSOTに仕込んだ。「設計が動く前提で試す」ではなく、**「設計が壊れる前提で安全装置を仕込む」**に振り直した。ReadOnlyは「触れないこと」ではなく「触る前に気づくこと」を目的とする。30日後に「邪魔だから外そう」となっても、運用の安全装置として残す判断は別に行える。

この話の教訓は、symlinkの「同じに見える」は信頼してはいけないこと。cmd・PowerShell・bashでsymlinkの解決結果が違うことを検証マトリクスで確かめ、想定外には安全装置で包むのが現実解。検証で全FAILが出るのは失敗ではなく、設計の盲点が早く見つかった幸運だ。

<details><summary>▶ 技術的にどうなってるか</summary>

• 補強1〜3の系譜: 2026-10-07実行分（Windows側claude-config-symlink補強1-3）で「WSL → Windows双方向のsymlink配線」を実装済み。本話の補強2+4はその後の追加策
• 4セル=全FAILの実測: 検証マトリクスは「cmd経由/PowerShell経由 × 読込/書込」の4通り。全FAIL＝設計前提のsymlinkが想定通り動かない証拠。obsidian-ssotリポジトリへの意図しない解決はUNCフォールバックで発生
• ReadOnly touch拒否のfail条件: ReadOnly設定の効力は試験運用で「アクセス拒否」を生むことで担保。効かなかったら設計の前提が間違っていたことになる
• 30日後リマインダー: durable one-shotで2026-11-07に「補強2+4再吟味」を自動発火。ReadOnlyが「邪魔」になって外されかけたタイミングを機械的に捕捉
• MLRの3機一致=強いシグナル: MiniMax・Gemini・OpenRouterの3機が独立に「吟味保留」を返したのは偶然ではない。3機一致は**「設計前提を疑え」**の合図

正典: 01_DECISIONS/claude-config/2026-10-08_補強2-4採用と4セル検証+1週間試験運用.md </details>