` の内側**にあった。Spec 39 P3 でそのグリッドへ `v-show="view === 'village'"` を足したので、統計画面では `display: none` になる。**`position: fixed` は親の `display: none` に勝てない** — 祖先が描画されないなら、子孫は座標の基準ごと存在しない。 **押下自体は効いている**（`settingsOpen = true` は立つ）。効いていないのは描画だけで、村へ戻ると `display` が復活して「今開いた」ように見える。**状態と描画が別々に壊れると、利用者からは「効かないボタン」に見える。** **実害はダイアログの見え方に留まらない。** 同じ位置に居た `ConfirmHost` は「閉じる前の確認」（`askConfirm`）の描画先で、**統計画面では確認が出ず、 `askConfirm` の Promise が解決しないので窓が閉じられない**。CLAUDE.md の「閉じられなくなるほうが害が大きい」に真っ向から反する状態を、 1 つの `v-show` が作っていた。`ToastHost` も同様に沈黙する。 **処方**: 全画面の層（トースト・確認・各ダイアログ・初期化の覆い）を **グリッドの外**へ出す。あわせて利用者裁定で、統計画面の間はタイトルバーのダイアログ入口 6 つを `disabled` にした（**窓操作は塞がない**）。 **入口を塞ぐだけでは足りない** — `ToastHost` / `ConfirmHost` の入口はタイトルバーではないので、構造を直さないと沈黙したままになる。 **回帰**: `statsView.test.ts` が `v-show` のグリッドの範囲を `

` の深さで求め、その中に 9 つの層が**入っていない**ことを見る（インデントで判定すると整形で壊れる）。ミューテーション（`ConfirmHost` をグリッドの中へ戻す）で 1 本だけ赤になることを確認済み。 **一般化 1**: **`v-show` を足した瞬間、その要素の子孫すべてが新しい条件に従属する。** 新しい表示モードを足すときに数えるのは「隠したいもの」ではなく、 **「隠す範囲の中に何が入っているか」** — とくに `fixed` / `absolute` で「画面全体を覆うつもりの層」は、書いた場所と描かれる場所が違うので目視で漏れる。 **一般化 2**: **押下が状態にだけ効いて描画に効かないと、「効かないボタン」として現れ、利用者は二度押しする。** 状態と描画のどちらが壊れたかは画面から区別できない。 **処方が実機で効いたことの対照**（2026-08-16 06:02。Spec 39 の検収 1 の走行）: 統計画面を開いたまま個体を失敗させたら、**失敗のトーストが統計画面の上に出た** — 修正前は `ToastHost` がグリッドの中に居たので、この吹き出しは**原理的に見えなかった**。 **別の検収を踏む走行が、そのまま処方の実証になった。** **一般化 3（この修正の作業中に踏んだ）**: **`vue-tsc` と vitest はテンプレートのタグの対応を検証しない。** ブロックを移す編集で閉じタグを 1 つ落としたとき、型検査もテスト 391 本も緑のまま通り、**`bun run build` だけが落ちた** （`Element is missing end tag`）。**テンプレートを構造ごと動かす編集は、型検査とテストではなくビルドで確かめる。** ## #108 「秘密が揃っているか」を見る門が、必要な 5 つのうち 2 つしか数えていなかった **症状**: 発火する前に見つけたので実害は出ていない。**`APPLE_ID` の secret を登録した時点で、`APPLE_PASSWORD` が空のまま macOS の署名・公証経路が有効になる状態**になっていた。そのままタグを打てば、署名は通って公証が 401 で落ち、 macOS のジョブだけが失敗する。 **真因**: `build.yml` の門をこう書いていた。 ```yaml HAS_APPLE_SIGNING: ${{ secrets.APPLE_CERTIFICATE != '' && secrets.APPLE_ID != '' }} ``` **この門は、空文字で落ちる形を防ぐために自分で作ったものだった。** Tauri の `macos/sign.rs` は `var_os("APPLE_CERTIFICATE")` で見ており**空文字も `Some` を返す**ので、`env:` へ直に書くと未設定の secret（= 空文字）を「証明書が指定された」と読んで取り込みに行き、macOS だけが落ちる。だから「揃っているときだけ発火する」門を置いた。**その門が、揃っているかを部分的にしか数えていなかった。** 必要なのは 5 つで、依存は片方向ではない。Tauri の `ENVIRONMENT_VARIABLES.md` は **「`APPLE_ID` を指定するなら `APPLE_PASSWORD` と `APPLE_TEAM_ID` も設定しなければならない」**と明記している — **`APPLE_ID` を数えたことが、数えていない 2 つを必須にしていた。** **部分的な有効化に価値が無いことも、後から数えたら出た。** 署名だけ通って公証が無い `.app` は Gatekeeper が結局拒むので、**得るものはゼロで、リリースが割れる危険だけが増える。** **処方**: 5 つ全部を数える。 ```yaml HAS_APPLE_SIGNING: >- ${{ secrets.APPLE_CERTIFICATE != '' && secrets.APPLE_CERTIFICATE_PASSWORD != '' && secrets.APPLE_ID != '' && secrets.APPLE_PASSWORD != '' && secrets.APPLE_TEAM_ID != '' }} ``` **見つけた経路はテストでも CI でもない** — secret を 4 つ登録した時点で「いま門はどちらに倒れているか」を数え直したこと。**門の条件と、実際に登録されているものの一覧を並べて見るまで、両者が食い違っていることは分からなかった。** **一般化 1**: **「必要な入力が揃っているか」を検査する門を書いたら、その入力を実際に数える。** 標本では足りない。書いた本人は「代表的な 2 つを見れば十分」と思っており、**その 2 つを選んだ根拠は無かった**。 **一般化 2**: **依存は片方向とは限らない。** `APPLE_ID` は「あれば使う値」ではなく「あると別の 2 つを必須にする値」だった。**門に足す 1 つが、門に足すべきものを増やすことがある。** **一般化 3**: **部分的に有効化して得るものがあるかを数えると、門の粒度が決まる。** 今回は「署名だけ」に価値がゼロだったので、5 つを AND で束ねるのが正しい粒度だった。価値があるなら段階的な門にすべきで、そこは自明ではない。 ## #109 App 固有パスワードとアカウントのパスワードは、入れた後 20 分経つまで見分けがつかなかった **症状**（2026-08-16）: `v0.1.9` のタグで macOS のジョブが落ちた。証明書の取り込みも署名も完走したうえで、最後の公証だけが ```text failed to notarize app: HTTP status code: 401. Invalid credentials. Username or password is incorrect. Use the app-specific password generated at appleid.apple.com. ``` **真因**: `APPLE_PASSWORD` に**Apple ID のアカウントのパスワード**を入れていた。公証が要求するのは appleid.apple.com で別途発行する**App 固有パスワード** （`xxxx-xxxx-xxxx-xxxx` の形）。**どちらも「Apple ID のパスワード」と呼べてしまう。** **重いのは取り違えたことではなく、判定に 20 分かかったこと。** 資格情報の正誤を確かめる唯一の経路が「タグを打って 3 OS のビルドを回し、macOS の Tauri ビルドが終わってから公証の段に到達する」だった。**外すたびに 20 分**で、しかもタグを消費する。 **処方**: 資格情報だけを検証する手動 workflow （`.github/workflows/verify-notary.yml`）。`xcrun notarytool history` は **ビルドを 1 行も走らせずに認証だけを判定する**ので 1 分で真偽が出る。認証が通れば履歴（空でもよい）が返り、誤っていれば 401。 **そのうえで、値を出さずに形を検査する段を前に置いた。** ```text APPLE_ID : present (19 chars) APPLE_PASSWORD : present (15 chars) length = 15 -> WARNING: App 固有パスワードの想定 (19) と違う ``` **App 固有パスワードはハイフン込みで 19 文字**（ハイフンを外すと 16）。**15 はどちらでもない**ので、`notarytool` を呼ぶ前に誤りが確定する。空白の混入も同じ形で見る。**秘密を 1 文字も出さずに判定できている。** **初回の実行で元を取った。** 20 分のビルドを回さずに原因が確定し、直した後の再実行は `length = 19` → `No submission history.`（= 認証成功）で 1 分だった。 **一般化 1**: **秘密は中身を見なくても、形（長さ・区切り文字・空白の有無）で誤りの大半が捕まる。** 発行元が固定書式を定めている資格情報ほど効く。 **#71 の対になる形** — あちらは*計器がモデルの出力経由で秘密をログへ再放流した* 事故で、こちらは*秘密を出さずに検査する計器*。**計器に秘密を通すかどうかは設計で選べる。** **一般化 2**: **判定に 20 分かかる検査は、20 分かけて 1 つずつしか誤りを潰せない。** 資格情報のように「合っているか間違っているか」しかない入力は、**本番の経路から切り離して単独で叩ける口を作る**と桁が変わる。切り離せるかどうかは、その検査が副作用を持つかで決まる（`notarytool history` は読むだけ）。 **一般化 3**: **同じ語で呼ばれる 2 つの秘密は取り違える。** 「Apple ID のパスワード」はアカウントのものと App 固有のものの両方を指せた。**入力欄の名前（`APPLE_PASSWORD`）がどちらとも読めるとき、書式で区別できるなら書式で検査する。** ## #110 文字数を返す関数の戻り値を、バイト長で割った（他プロジェクトで独立に再発） **症状**: この村では**まだ本番で踏んでいない**。Spec 16 と Spec 17 の査読で添えられた参考実装に 2 回続けて現れ、どちらも実装前に潰した。 **3 例目を別のコードベースで観測した**ので、ここに残す。 **観測した実物**（`iOfficeAI/aionrs` の `crates/aion-compact/src/fold.rs`。 Apache-2.0。2026-08-17 時点）: ```rust fn common_prefix_len(a: &str, b: &str) -> usize { a.chars().zip(b.chars()).take_while(|(ca, cb)| ca == cb).count() // 文字数 } fn lines_are_similar(a: &str, b: &str) -> bool { let prefix = common_prefix_len(a, b); // 文字数 let min_len = a.len().min(b.len()); // バイト長 prefix as f64 / min_len as f64 >= MIN_PREFIX_RATIO // 0.5 } ``` **真因**: 分子が文字数、分母がバイト長。UTF-8 の ASCII では両者が一致するので **英語のテストでは一生出ない**。日本語は 1 文字 3 バイトなので比が約 1/3 になり、 **閾値 0.5 が実質 1.5 になって、どんなに似た行でも畳まれない。** この関数はツール出力の圧縮（似た行を `[... N identical lines]` へ畳む）に使われる。 **日本語の出力だけが圧縮されずに素通りする**が、**エラーにはならない**ので気づく契機が無い。 **この村での 2 例**（どちらも査読の参考実装。実装前に潰した）: - **Spec 16**（`grep` の `include` / `context`）— 文字数の枠を `len()` で数えていた - **Spec 17**（`sd` の batch preview）— 同じ形 **当時の一般化**: **`MAX_*_CHARS` という名前の定数を `len()` と突き合わせる差分は、日本語では枠の 1/3 で発火する。** テストが ASCII だけだと通ってしまう。 **処方**: 比を取る前に**分子と分母の単位を揃える**。文字数で比べるなら `a.chars().count().min(b.chars().count())`、バイトで比べるなら分子も `a.as_bytes().iter().zip(...)`。**どちらでもよいが、混ぜてはいけない。** 検査は**非 ASCII を含む入力を 1 本入れるだけで足りる** — ASCII だけのテストはこの誤りに対して**構造的に無力**で、何本足しても検出しない。 **一般化 1**: **`.len()` は「長さ」ではなく「バイト長」だ。** Rust の `str::len` がバイトを返すことは知られているが、**比や割合を組み立てるときに分子だけが `chars()` になっている形**は目視で残る。**同じ式の中で単位が変わる。** **一般化 2**: **同じ罠が別のコードベースで独立に踏まれていたら、その記録はこのプロジェクト固有ではない。** #33 の「単位を間違えた閾値は、境界付近ではなく全域で外れる」と同じ族で、**あちらは文字数 ÷ トークン数、こちらは文字数 ÷ バイト長**。 **単位の異なる 2 つの量で比を作る箇所を、実装の前に数える価値がある。** **一般化 3**: **英語圏で書かれたコードを日本語の入力で使うと、この族の誤りは「壊れる」ではなく「効かない」として現れる。** 例外も警告も出ず、最適化が黙って無効になる。**#33 も同じ形で数日気づけなかった**（キャッシュが一度も効いていなかったのに、累積トークンの表示は同じ数字を出していた）。 ## #111 `type="number"` の `v-model` は `.number` 無しでも数値を渡す — 文字列前提の setter が黙って死んでいた **症状**: モデル登録ダイアログの単価欄（Spec 41）に**手で数字を入れても保存されない**。「取得」ボタンで埋めた値は保存される。利用者の報告（2026-08-19。Perplexity は単価表に載っていないので手で入れようとして発覚）。 **真因**: 単価欄は `computed` の get / set で `draft` と繋ぎ、setter は `raw.trim()` と**文字列前提**で書かれていた。しかし `` に `v-model` を付けると、**`.number` 修飾子が無くても Vue が値を数値へ自動変換する** （`@vue/runtime-dom` の `vModelText`: `castToNumber = number || vnode.props.type === "number"`）。数字を打った瞬間に setter へ `number` が届き、`(3).trim()` が `TypeError` で落ちて **`draft` へ 1 度も書かれない**。コンソールにだけ出て画面は何も言わない。 **空欄だけが通っていた** — `""` は `looseToNumber` で数値化されず文字列のまま届く。だから「欄を空にする」と「取得で埋める」（`draft` を直接書く）は効き、**手入力だけが効かない**という、原因を読みにくい形になった。 **処方**: 変換を純関数 `parsePriceInput(raw: string | number)` へ寄せ、`String(raw).trim()` で**型に関わらず同じ結果**にした。単体で「初版の setter に数値を渡すと `TypeError`」を **再現の赤**として残し（`priceInput.test.ts`）、数値でも文字列でも同じ値になることを留めた。 **私が見落とした理由**: Spec 41 に「**`v-model.number` を使わない**（空文字を `0` にするので未設定が無料に化ける）」と自分で書いていたので、**修飾子を付けなければ文字列が来る**と思い込んだ。Vue は `type` 属性を見て同じ変換を掛ける。**修飾子の有無は変換の有無ではない。** **一般化 1**: `computed` の型注釈は setter に届く値の型を保証しない。テンプレートの `v-model` が何を渡すかは**要素の `type` 属性とフレームワークの規則**で決まり、型検査の外。 `` / `type="range"` に繋ぐ setter は `string | number` で受ける。 **一般化 2**: 「A を使わないから B が来る」と書いた注記は、**A 以外の経路で B が来ない** ことを確かめていない。避けたものの代替経路を 1 度数える（ここでは `type` 属性）。 **一般化 3**: 同じ入力が「空欄では効き、値を入れると効かない」とき、疑うのは保存経路より **入力の型の分岐** — 空欄だけが別の型で届く境界を探す。 **同じ経路で 2 つ目の穴**: Spec 41 D1 は「`pricing_as_of` は取得なら JSON の日付、 **手入力ならその日**で常に埋まる」と凍結していたが、実装は取得のときしか書いておらず、手入力した村の統計は「単価の時点は未記録」と出ていた（同じスクショで発覚）。 `todayIsoDate(now)` で手入力の setter がその日を書くようにした。**契約に「常に」と書いた欄は、埋める経路を 1 つずつ数える**（取得 / 手入力の 2 経路で片方だけ書いていた）。 ## #112 旧い版で村を開くと、`world.json` の未知の欄が黙って消える（`#[serde(default)]` は前方互換ではない） **症状**: 統計画面の `≈ $` が出なくなった。`world.json` を見ると**全テンプレートの単価 5 欄と `pricingAsOf` が `null`**。前夜 23:13 には `≈ $0.01` が実機で出ていた（2026-08-20）。 **真因**: `%LOCALAPPDATA%\fuseforks\fuseforks.exe`（**08-16 06:30** = 単価欄を知らない世代。単価は Spec 41 で 8/18 の `v0.1.10` タグの**後**に入った）で村を開いた。`ModelTemplate` に `deny_unknown_fields` が無いので、旧い版は `inputPerMtok` 等を**未知フィールドとして黙って捨て、書き戻しでファイルから消す**。警告は 1 行も出ない。 **コードの経路は全部無実だった**（先に疑って、実測で外した）— `draft.value` をそのまま IPC （`save` / `saveSecret` の 2 経路とも）→ `upsert_template` は `credential` だけ補正 → `to_persisted` は `self.templates.values().cloned()` → `from_persisted` は `insert(template)` → `reseedDraft` は `{ ...saved }`。**Spec 14 P1 型の「投影から組み直して欄が消える」穴は無い。** **契約が 2 つに割れていた。** `session_store` の凍結はこう書いてある —「旧い版で新しい村を開くのは**非サポート**（未知の kind で `records()` が落ちる）。**未知 kind を WARN で飛ばす読み取りは作らない** — 読めないレコードを黙って落とすと統計が『払っていない』側へ嘘をつく（#72 の形）」。**`world.json` はその逆で、黙って削る。** そして今回、**実際に統計が嘘をついた** （単価が消えて金額が出なくなった）。同じ危険に対して、同じリポジトリの 2 つの保存先が反対の側へ倒れていた。 **構造的に再発する。** CLAUDE.md の winget の節に自分で書いてある —「MSI と NSIS は **同じ端末に並んで入り、identifier が同じなので村のデータは共有する**」。そこに手元のビルドが加わって、**3 世代が 1 つの `world.json` を共有**している。 **処方（入れたのは 1 つ目だけ。2026-08-20）**: 1. **起動行に版と profile を出す**（`version: app=0.1.0 profile=release`）。**`CARGO_PKG_VERSION` は使えない** — CI がタグから書き換えるのは `tauri.conf.json` だけで、workspace の version はどのビルドでも `0.1.0`。**配布物と手元のビルドは分かれるが、手元のビルド同士は区別できない** （`profile` がその半分を埋める） 2. **着地（2026-09-14。Spec 不要と判断）**: `PersistedWorld` / `AgentSpec` / `ModelTemplate` / `AgentRole` / `AgentRoleDefaults` / `AgentGroup` が `#[serde(flatten)] unknown: UnknownFields` で未知の欄を保持して書き戻す。**効くのは今後足す欄だけ** — 既に配布済みの旧版（v0.2.3 以前）は直せない。 **読みで残すだけでは足りなかった** — 画面は自分の版が知っている欄だけで組み直して送る（`snapshotToSpec`）ので、`update_agent` / `upsert_template` / `upsert_role` / `upsert_group` が **既存の側から未知の欄を引き継がないと、最初の保存操作で消える**。赤は 2 本に割って 2 段とも確認した（`unknown_fields_survive_load_and_save` / `..._updates_from_the_ui`）。 **持ち込んだ穴を 1 つ同日に塞いだ** — 未知の欄を全部残すと、**この版が廃止した欄** （`apiKeyEnv` = #1 で実キーが入った欄 / `defaults.ragSources`）まで書き戻され続ける。既存の `apiKeyEnv` のテスト 2 本は「旧形式が読める」だけを見て書き戻しを見ていなかったので緑のままだった。処方は廃止した欄を**型に名前を残して読み捨てる**（`retired_*: ()` + `skip_serializing` + `discard_retired`）。履歴の走査で、`model.rs` / `world.rs` から消えた `pub` 欄は `api_key_env` の 1 つだけだった（`ragSources` は `AgentSpec` に残っているので差分に出ない — 走査の外にあった 2 つ目） 3. **採らない**: 旧版で起動を止める。「起動が止まる経路は作らない」（`from_persisted` の既存の判断）と衝突する **一般化 1**: **`#[serde(default)]` は前方互換ではない。** 保証するのは「欄が欠けても読める」ことだけで、「書き戻しで消さない」は保証しない。**読みと書きの両方を通る設定ファイル**では、 `default` を付けた時点で「古い版が新しい欄を削る」経路が同時に生まれる。 **一般化 2**: **互換の向きの扱いが、保存先ごとに割れていないか数える。** 片方に「黙って落とさない」と凍結を書いたら、もう片方の保存先も同じ問いに答えているかを見る。片方だけ厳しくしても、事故は緩いほうから入る。 **一般化 3**: **画面に出ている値が、ログにも要るかを画面を作ったときに問う。** 版番号はステータスバーに出ていたのにログには無く、**事後に「どの世代が触ったか」を読む手段が無かった**。診断の識別子は、事故が起きてから足しても**その事故自体は読めない**。 ## #113 有界ループの上限を「回数」で切ったら、速さに依存するテストになった（2026-08-25） **症状**: `v0.1.11` のリリースビルドで **macOS と Windows だけが赤**（Ubuntu は緑）。落ちたのは `budget::tests::join_set_abort_runs_drop_and_refunds` で、**返金の検査（テストの主題）ではなく、その手前の「予約が観測できたか」の assert**: ```text panicked at crates/fuseforks-core/src/budget.rs:621: 予約が残額から引かれる実装であること ``` **真因**: 予約の観測を待つループの上限が**回数**だった。 ```rust for _ in 0..10_000 { if pool.spent_effective() == 400 { reserved_seen = true; break; } tokio::task::yield_now().await; // ← 実時間で数ミリ秒しかない } ``` `yield_now()` 10,000 回は**実時間で数ミリ秒**で、`spawn` したタスクが別ワーカーで走り出すより短い。混んだ CI ランナーでは予約の前にループが尽きる。**Spec 38 が `v0.1.8` で入って以来在り、`v0.1.10` の CI では通っていた** — 新しい退行ではなく **フレーク**で、速さの違いが OS 差として現れた。 **この有界ループは #86 の処方だった。** 無限 `while` にすると、予約しない実装（ミューテーション = load 観測化）で**ハングになり赤と区別が付かない**ので上限を付けた。ハングは防げたが、**上限を回数で切ったことで今度は速さに依存した。** **処方**: 上限の単位を「回数」から「秒」へ移す（`sleep(5ms) × 1000` = 5 秒）。 **`sleep` にするのは待つためだけではない** — `yield_now` の密なループはワーカーを回し続けるので、**譲ったつもりで譲れていない**。 **ミューテーションで両方を確認した** — 予約しない実装で **15.66 秒で赤**（ハングせず、 assert が落ちる）。#86 の処方は保ったまま単位だけが変わった。 **一般化 1**: **「永久に返らない形にしない」ための上限は、実時間で切る。** 回数で切ると、待っている対象（別スレッドのスケジューリング・I/O・プロセス起動）が回数と無関係な単位で動くので、**速い機械でだけ通るテスト**になる。上限の単位は、**待っている対象の単位に合わせる**。 **一般化 2**: **同じテストが「主題の検査」と「前提の観測」を持つとき、落ちるのはたいてい前提の側。** ここでも主題（abort で Drop が走り返金される）は無傷で、その手前の観測が届かなかっただけだった。**assert のメッセージが主題と前提で別々に書かれていたから 1 行で切り分けられた** — 前提の assert に主題の文言を書いていたら、実装を疑って時間を溶かしていた。 **一般化 3**: **CI の OS 差は、OS の差とは限らない。** 今回 Ubuntu だけ通ったのは Linux が特別なのではなく、その回のランナーが速かったから。**「macOS で落ちる」と読むと OS 依存の実装を探しに行く** — 先に「どの assert か」を見る。 ## #114 進行役のための設定をワーカーが持つと、委譲の戻り口が「提案した」の一言で消費される（2026-09-02） **症状**: ザリが `plan` でジェミーとルナへ撒く → ルナは自分の `plan` でミュゼとイクスへ撒く → **ザリへは「提案した」の 105 字だけが戻り**、ザリはジェミーの調査だけで束ねる → 3 分後にルナがミュゼとイクスの結果を束ねて**利用者へ**報告する。利用者の問い —「ルナは報告が返ってからザリに報告すべきでは。そうしないのはなぜか」。 ```text 07:40:29 plan pending: agent=agent_8 to=[agent_3,agent_10] ← 窓が開く 07:40:32 reply: agent=agent_8 to=agent chars=105 ← 戻り口が消費される 07:40:39 plan dispatch: agent=agent_8 ← 人の承認 07:40:43 plan bundle: agent=agent ← ザリの束ねが閉じる 07:43:33 turn start: agent=agent_8 hop=0 from=system ← 新しい根（戻り口なし） 07:44:41 reply: agent=agent_8 to=user ← 利用者へ流れる ``` **真因**: ルナも `planReview` = true だった。Spec 43 の編集窓は「提示でターンを正常に終え、承認が新しい因果の根になる」二相（凍結 5）で、**委譲されたターンの戻り口（`reply_to`）を持ち越さない**。窓を開けた時点で、依頼主へ束ねが戻る経路は構造的に消える。`turn.rs` は `spec.plan_review` を個体の設定のまま `run_plan` へ渡しており、**転送に対しては #96 で入れた `!awaiting_reply` の門が、窓には無かった**。Spec 43 の Design は「窓が要るのは進行役だけ。ワーカーに plan は生えないことが多い」と書いていたが、`plan` は接続 2 体以上なら誰にでも生え、検収の対照はワーカーに窓を付ける形を 1 度も踏んでいない。 **処方**: `plan_review && !awaiting_reply`（`CallRunner::awaiting_reply` を足した）。委譲されたターンでは従来どおりターンの中で撒いて束ね、依頼主へ戻す。結合テスト 1 本を赤 → 緑で留め、赤のログが実機と同じ形（`plan pending` → 依頼主へ 7 字の返信）であることを確かめた。Spec 43 凍結 10・`data_contract` の `plan_edit_window` へ追従。 **一般化**: 1. **「誰かのため」の設定は、その誰かでない個体にも付けられる。** 設定の意味が役割（進行役）に依存するなら、役割は設定ではなく構造（このターンに戻り口があるか）で判定する。転送の門（#96）と同じ形で、**2 例目** 2. **二相の機構は、1 相目でターンを終える瞬間に「そのターンが誰かに答えを負っているか」を数える。** 戻り口はターンの寿命と一致しており、ターンを終える機構はすべてそれを消費する — 提示・要約・打ち切りの各出口で同じ問いが要る 3. **検収の対照を「設定 ON の個体 / OFF の個体」で取ると、ON の個体が別の役割で呼ばれる形が網の外に落ちる。** 検収は設定の値だけでなく、その個体が呼ばれる経路（人から / 委譲から / 予定から）でも数える ## #115 外部裏付け: 3 つの公開ハーネスで再現された欠陥が、この村が構造で塞いだ穴と同じ継ぎ目に落ちている（arXiv:2608.23953・2026-09-02 実読） **この項は村の失敗ではない。** 「The Empire, Long Divided, Must Unite」（Jiahong Dai・NTU・単著・2026-08-25・N=3）が deepagents（LangChain）/ pi（Earendil）/ dsh（DeepSeek）を commit 固定でソースレベルに読み、**再現した欠陥を 4 つの継ぎ目に分類した**。そのうち 3 つがこの台帳の既存項と同じ形なので、外部の実物として引けるように残す。 | 論文の継ぎ目 | 論文の実物（file:line は論文の記載） | この村の対応 | |---|---|---| | **S2 正規化の信頼の隙間** | deepagents `utils.py:691` — `os.path.normpath` が先頭の `//` を残すので `//secrets` が `/secrets` とパス要素では不一致、ファイルシステムでは同一。削除の deny 規則・承認の割り込み・バックエンドの振り分けの 3 検査が**素通り**（隣の wcmatch 系の検査は正規化しているので無傷） | `resolve_in_work_dir`（`tools/fs.rs`）が文字列検査ではなく **canonicalize 後の前方一致**を採った理由そのもの。Spec 15 が「パースで守る境界は必ず抜けられる」と 3 rev かけて退けた線 | | **S3 文字列一致で意味を決める** | pi `overflow.ts:60–142` — 約 25 本の正規表現でプロバイダのエラーを分類。Bedrock のスロットリングが素のオブジェクトで再送出され（`bedrock-converse-stream.ts:306`）JSON 化されて `{` で始まるため、それを弾くはずの先頭固定の否定正規表現（`:75`）を抜け、**一時的なレート制限が文脈溢れと誤読されて有料の破壊的圧縮へ**（`agent-session.ts:2079`。しかも retryable と印されない `retry.ts:26–44`） | Spec 08 の凍結「**分類は文言 parse でなく型で運ぶ**」。Spec 27 で却下した「`Error:` を含むなら ok を倒す」も同族。`refusal=` は文字列照合だが**観測だけ**で配送に触らない（#84 の規律） | | **S4 黙って続く対大声で止まる** | 上の全欠陥に共通 — 未知の形が既定値へ落ちて走り続ける（deepagents の設定層だけは「除外規則が何にも当たらなければ raise」する対照） | #72（握り潰した事実を数えない `_ => {}` は沈黙になる）/ 閉じた許容 / eigent の採点器 fail-open の反面教師。論文の規則「**境界では未知の形は既定値ではなく誤り**」は同文 | | S1 sync/async の乖離 | deepagents `async_subagents.py:445/:625` — 手書きの同期版と非同期版で guard の位置が違い、片方だけ未処理の KeyError | Rust の単一ループなので該当なし（論文自身が言語固有と断る） | **論文が「収束していない唯一の次元」と呼ぶもの = 外部検証可能性。** ランタイムを信用せずに第三者が改竄の有無を確かめられる記録は 3 つとも無い（dsh の「可視 ⇒ 記録済み」の実行時アサーションが最上位だが、運用上の再構成であって外部検証ではない）。**この村も同じ段に居る** — `fuseforks.log` と `sessions.redb` は村自身が書く記録で、改竄検知を持たない。論文が 6 段目に置く問い「**費用の天井が守られたことを証明できるか**」は、予算の CAS 予約と `turn:` 行が運用上は答えているが、外から確かめられる形では答えていない。評価基盤の「完遂」の軸の隣に置く候補として名前が付いた（起票はしない — 論文自身も「隙間を特定して止まる」）。 **一般化**: 1. **自分が構造で塞いだ穴は、他所では同じ継ぎ目で開いている。** 「正規化は 1 箇所で必ず canonical へ、下流は canonical しか受けない」「エラーは型で運び、正規表現は安全側へ倒す最後の手段」「未知の形は誤り」の 3 規則は、この台帳の #72 / Spec 08 / Spec 15 と論文が独立に同文へ着地した。**規律の外部裏付けは、失敗の項の隣に置くと引ける** 2. **取り返しのつかない継ぎ目に損害が集中する。** 論文の 4 標本のうち 3 つが不可逆（deny 規則をすり抜けた再帰削除 / 圧縮による履歴の上書き）。自動の破壊的操作（圧縮・退避・削除）は記録し、できれば可逆にする — この村が削除をごみ箱に限り、要約を手動にし、黒板を append で育てる判断と同じ向き 3. **「コーチングは薄く、耐久性は厚く」。** 極小主義の pi が積んだのはセッション記録・クラッシュ復旧・モデル癖のカタログで、モデルへの指示ではない。「ループの所有が構造的な差」（2026-08-17 の位置取り）の外部裏付け ## #116 URL の取得に失敗した後、モデルは 10 周・200K トークンを回して存在しないスレッドの内容を組み立てた（2026-09-04） **症状**: Gemini の URL context（Spec 48）を ON にしたジェミーへ、2 つのスレッドの ID を途中で合成した**存在しない** outcasts.jp の URL を貼って「内容を読んで」と頼んだ。取得は正しく失敗し（`gemini tools: url_context=0/1 statuses=URL_RETRIEVAL_STATUS_ERROR`）、ターンも落ちなかった。**そのあとモデルは `grep` / `rag` / `fd` / `file` ×5 / `manuale__search` / `memoria__recall_memory` と検索 16 語で 10 周を回し、 `stop=tool_limit`（12/12）・`turn: prompt=201603` を払って、1,224 字の筋の通った答えを返した** — 利用者の判定は「ハルシネーション」。前の周に読んだ**実在する** スレッドの本文が履歴に 2 通残っていた（`history_msgs=2/16`）ので、それと検索と手元のファイルから組み立てた形。 **真因**: 取得の失敗は API からモデルへ返っており（`toolResponse` の part に状態が載る）、モデルはそれを読んだうえで**「読めなかった」ではなく「他の手段で答える」を選んだ**。村の機構はどれも止めない — RepeatGuard は同じ呼び出しの 3 回目しか止めず（毎周違う道具を呼んでいる）、周回上限は 12 で止めたが**それは払い終わった後**、予算は 200K でまだ余裕がある。**#82 の「答えられないことに気づけない」の URL 版**で、違いは「気づく材料（ERROR）が渡っているのに使わなかった」こと。 **もう 1 つの副産物**: 取得に失敗しても `tool_use_prompt=10296` が課金側に載った（404 のページ = SPA の殻を取ってきて ERROR の印を付けた、と読むのが自然だが 1 対の観測）。**失敗は無料ではない。** **処方（2026-09-04 利用者裁定 —「ハルシネーションをしないように覚えさせれば解決できる。運用だね」）**: 表示も機構も足さない。条例 / `Memory.md` の文言で、その個体に「取得に失敗した URL の内容は語らない」を持たせる。黒板・手順書と同じ道 — 条例で運用を始め、機構は要るときに。**効いたかは観測でしか分からない**（#84 — 文言は保証ではない）。次に同じ形が出たら `gemini tools: url_context=0/N` の周の後の `reply:` を読む。 Spec 48 D3 の「取得失敗は画面に出さず、頻度を見てから」は据え置き。 **一般化**: 1. **失敗を名指しで返しても、受け手が LLM なら「止まる」保証にはならない。** #44 の「打ち切り文に次の手を書く」は、モデルが回復するための処方だった。**回復の道が開いていると、答えられない問いにも回復してしまう** — 失敗の名指しは必要条件で、十分条件ではない 2. **費用の歯止めはどれも「答えの正しさ」を見ていない。** RepeatGuard は同一性、周回上限は回数、予算は量。**違う道具を順に呼びながら間違った答えへ進む形**は 3 つ全部の外側 3. **履歴に残った「隣の実在」が捏造の材料になる。** 直前に実在するスレッドを読んだ個体は、存在しない ID にもその文体と構造を当てはめる。**対照は「その会話で初めて URL を貼る」形**で、続きの会話で貼ると材料が増える（検収を組むときの順序） ## #117 「同じ世代の欄は同じ門」は成り立たなかった — 2.5-lite は `thinkingLevel` を拒み `urlContext` を受けた（Spec 48 P0・2026-09-03） **症状**: Spec 48 rev2 で「URL context にも 2.5 系の門が要るか」を P0 (e) に置き、 **予測は 400**（`thinkingLevel` が 2.5-flash-lite で 400 だったので、同じ 3 系世代の欄は同じく拒む、と写した）。実測は **200**（`toolUsePromptTokenCount` 6,541）。門は要らなかった。 **真因**: `thinkingLevel` は Gemini 3 で入った欄、URL context は 2025 年の 2.5 世代の機能。 **「どの版で入った欄か」を確かめずに「3.8 の固有スキル」という括りで同じ門を予測した。** Spec 36 の carries 表を 20 マス全部撃ったのと同じ規律（欄ごと・モデルごとに撃つ）を、 2 欄目で省略した。 **処方**: 予測は外れたが P0 で撃っていたので実装には乗らなかった（門を書いていれば 2.5-lite の利用者から URL context を黙って奪っていた）。**Spec の P0 に「予測を先に書いてから撃つ」を置く形がここで効いた** — 外れたことが記録に残る。 **一般化**: **機能の門はモデルの世代ではなく、その欄がいつ入ったかで決まる。** 同じプロバイダの同じ世代でも欄ごとに導入時期が違い、「3.x の機能」という括りは門の単位として粗い。門を 1 つ書くごとに、その欄で 1 発撃つ。 ## #118 JSON の配列要素へ欄を「末尾に」足したら、diff が 1 要素あたり「1 行変更 + 1 行追加」になった（Spec 50 P0・2026-09-05） **症状**: `prices.json` の 1,493 要素へ `max_input_tokens` を足す生成スクリプトの 1 回目で、 `git diff --stat` が `2987 insertions / 1494 deletions`。削除の 1,493 本は `"output_per_mtok": 0.0` → `"output_per_mtok": 0.0,` — 値は 1 桁も動いていないのに、 **「単価が動いていない」を追加行だけで読む**という P0 の確認法が使えなくなった。 **真因**: JSON の要素で最後の欄にはカンマが付かない。**欄を末尾に足すと、それまで最後だった欄の行にカンマが付く**ので、その行が「変更」として diff に出る。シリアライザは正しく、 diff の読み方の前提（追加だけのはず）が置き場に依存していた。 **処方**: 欄を **`"key"` の直後**へ置く（`{"key": ..., "max_input_tokens": N, ...単価}`）。前の行は元からカンマ付きなので diff は純粋な 1 行追加になり、 `1494 insertions / 1 deletion`（窓 1,493 + `_notice` 1 対 `_notice` 1）で読めた。 Pages リポジトリの `tools/build_prices.py` はこの順で要素を組み直す。 **一般化**: **JSON に欄を加算するとき「追加行だけの diff」が成立するかは置き場で決まる。** 末尾は必ず前の行を巻き込む。加算の証明を diff で立てるなら、欄は先頭側へ置く。 ## #119 同じトグルを 2 通りに書いたら、ON でノブが消えた（Spec 51 P4・2026-09-05） **症状**: グループ見出しのスイッチ（全体 ▶ の門）を ON にすると、ノブ（黒い丸）が消えて青い錠剤だけになる（利用者のスクリーンショット）。カードの一括起動トグルは同じ画面で正しく出ている。 **真因**: カードのトグル（`AgentCard.vue`）はノブを `left-0.5` / `left-4.5` で**置いて**いる。見出しのスイッチは `translate-x-0.5` / `translate-x-3` で**動かして**いた。同じ部品を 2 通りに書き、片方だけが実機で壊れた。**Tailwind の class の組み合わせが効くかは、書いた側からは見えない**（型検査にも vitest にも掛からない）。 **処方**: カードと同じ書き方（`left-*`）へ揃えた。以後トグルはカードの書き方を写す。 **一般化**: **同じ見た目の部品を 2 箇所に書くなら、書き方も写す。** 「同じに見える」実装を別の CSS で組むと、片方だけが壊れたときに「なぜ片方だけか」の答えが書き方の差にしか無く、しかもそれは画面でしか出ない。`roleColorTokens.test.ts` がビルド成果物を走査したのと同じ種類の穴で、今回は 2 例目に達していないので網は張らず、書き方を揃えるに留める。 ## #120 実装の数を `grep | head` で数えて 10 と書いたら 57 だった（Spec 52 D4・2026-09-07） **症状**: Spec 52 rev2 の D4 に「`LlmBackend::chat` の署名に cancel を足す。実装は 10 箇所（`HttpLlmBackend` / `EchoBackend` / 結合テストの 8 バックエンド）。全部機械的変更」と書いた。 P2 で数え直したら `impl LlmBackend for` は **57 箇所**（結合テストだけで 55）。 **真因**: 起票時の grep を `| head` で切って読み、切れた先を「それで全部」と読んだ。 `head` は「最初の N 行」であって「全部で N 行」ではないが、出力が N 行ちょうどのとき両者は画面上で区別が付かない。数を書く grep に `head` を付けていた。 **処方**: 数は `grep -c` / `wc -l` で取り、`head` は中身を見るときだけに使う。 Spec 側は署名を変える案を捨て、**加算的な既定メソッド**（`chat_cancellable`。既定は token を読まず `chat` へ委ねる）にして上書きを `HttpLlmBackend` 1 つに閉じた — 57 箇所を機械的に書き換えても何も守らない。守るもの（sleep だけ切る・HTTP は切らない）は変えていない。 **一般化**: **「N 箇所」と書く前に、その N を出したコマンドに `head` が付いていないかを見る。** 出力が丁度 N 行で切れていると、切れたことは出力のどこにも現れない。同じ形は #94 （`tool:` 行を `name=` で grep して 0 件と読んだ）と同族で、あちらは「出ない構造」を数えた誤り、こちらは「切った出力」を数えた誤り。**数を主張する grep は切らない。** ## #121 打ち切りが待ちを 2 ms で切ったのに、ターンは「API エラー」で閉じた（Spec 52 P4・2026-09-08） **症状**: 60 秒の `Retry-After` 待ちに入っている個体で「■ 停止」を押すと、待ちは 2 ms で切れた（`interrupt requested` 01:21:13.190 → `turn:` 01:21:13.192）が、ターンは `stop=failed:LLM_API` で閉じ、会話ペインに「API エラー (status=429)」が出た。人が止めたのに失敗を名乗る。 **真因**: Spec 52 D4 は「待ちが切れたら**いま受けた失敗をそのまま返し**、ターンループが周回境界で `is_cancelled()` を見て `interrupted` へ落とす」と書いた。周回境界の検査は `Ok` の経路にしか無く、`turn.rs` の LLM 呼び出しの `Err` の腕は払いを清算してすぐ `Err` で抜ける。**cancel を先に読む順序（`token_budget.precedence`）は `Ok` の経路にしか敷かれていなかった**。結合テスト（`tests/retry_hint_log.rs`）は `HttpLlmBackend` の `select!` が切れることまでしか見ておらず、その戻り値をターンループがどう分類するかは網の外だった。 **処方**: `Err` の腕で払いの清算の直後に `turn.token.is_cancelled()` を見て `finish_interrupted` へ落とす（`finish_interrupted` は 1 実装のまま、呼ぶ場所が 2 つ）。 `tests/interrupt_during_retry_wait.rs` で赤 → 緑 → ミューテーションで赤を確認。 **一般化**: **「切れたら失敗をそのまま返す」と「失敗は即抜ける」を別々に書くと、両方が正しくても組み合わせで打ち切りが失敗に化ける。** 早期 return する腕は周回境界を通らないので、優先順位を周回境界にだけ敷いても、その手前で抜ける経路には効かない。処方は「戻り値に新しい variant を足す」ではなく、**抜ける腕の側で同じ順序を読む**こと（#96 の転送の門・#114 の編集窓と同じ「戻り口の手前に 1 行」の形）。**機構が効いたこと（2 ms）と分類が正しいこと（interrupted）は別の観測**で、片方だけ見ると合格に見える。 ## #122 グループを隠して 2 体だけにすると、Fit が左上へ寄った（Spec 51 追補・2026-09-08） **症状**: 3 グループのうち 2 つを隠して絆の地図に 2 体だけ出すと、Fit（手動も、作り直し時の自動も）が 2 体を**左上**へ寄せ、内容が小さく描かれる。ペインが**広いほど**ずれが大きく、 2 グループで 1 つ隠すだけなら目立たない（利用者の観察 3 つ: 「関係ない位置」「左上に来る」「ペインの幅によって変わる」）。 **真因（ライブラリ単体の再現ページで数字を取った）**: v-network-graph 0.9.23 の `fitToContents` は、内容が小さくペインが広いとき**上限を超える zoom** を計算し（幅 1,200 px で 2 体なら 4.88。`lib/index.js` の `Is` / `ro`）、**zoom だけを `maxZoomLevel`（この村は 2）へ丸め、pan は丸める前の値のまま当てる**（`ao` の pos は 4.88 用。zoom の setter だけが clamp = `:5706`）。実測: `matrix(2,0,0,2,354,138)` で内容の中心が (475, 170)、ペインの中心は (601, 201) — 左上へ寄る。幅 300 なら要求 zoom が 1.47 で上限の下に収まり、ずれない = 「幅で変わる」の正体。**隠した個体の数がそのまま効くのではなく、残った個体の広がりが小さいほど要求 zoom が上がる**。 **外した処方が 2 つ先にあった**（同日。どちらも真因ではなかった）: 1. 「Fit は `layouts` の全件で外接矩形を取るので、隠した個体の座標を `layouts` から落とす」（`visibleLayouts`）— `layouts` の広がりを読むのは `scalingObjects: false` の枝（`$s`）で、この村は `true`（`Is`）。**設定の枝を読まずに別の枝の処方を書いた**。`visibleLayouts` は幽霊の座標を渡さない衛生として残す 2. 「ライブラリの内部の写しが `Object.assign` で足すだけなので `:key` で作り直す」— 写しが merge なのは事実だが、Fit は描画の `getBBox()` を読むので写しは効いていなかった。 `:key` は「隠した直後に残った個体へ Fit し直す」目的で残すどちらも**実機を踏んでもらって「まだ出る」で外れが分かった**。3 回目は再現ページを作って数字で確かめてから直した。 **処方**: `lib/kizunaFit.ts` の `fitMargin` — 見えている座標の広がり（円の半径だけで **控えめに**見積もる）と、ペインの大きさ・上限 zoom から、**余るぶんを余白へ回す**。 `fitToContents({ margin })` は辺ごとの px を受けるので、ライブラリの計算する zoom が上限ちょうどになり clamp が起きず、pan もライブラリ自身の正しい値になる（再現ページで `matrix(2,0,0,2,480,170)`・内容の中心 = ペインの中心）。読み込み時の Fit もライブラリの `"fit-content"` をやめて同じ `fit()`（`view:load`）へ。広がりを控えめに見積もる向きが要点 — 大きく見積もると zoom が上限を超えて元の症状に戻る。単体 5 + 配線の走査。 **一般化 3 つ**: - **設定の分岐を読んでから処方を書く。** 同じ関数でも `scalingObjects` で通る枝が違い、片方の枝の読みは片方にしか当たらない（#117「同じ世代の欄は同じ門」と同じ形 — 括りが粗い） - **「まだ出る」が 2 回続いたら、実機を頼む前に再現を自分で作る。** 3 回目は再現ページで数字を取ってから直した。Browser ペインが `hidden` だと rAF が止まり svg-pan-zoom が transform を当てない — 隠れたペインでの測定は `requestAnimationFrame` をタイマーへ差し替えてから（それまでの測定は無効だった） - **上限を持つ機構は、上限を超える要求のときに他の量が整合するかを見る。** zoom だけ丸めて pan は丸めない、が今回の形。Spec 52 の `plan_wait` が「天井を超えたら止める」を選んだのと同じ場所で、ライブラリは「丸めて進む」を選び、進んだ先で pan がずれた ## #123 Vue の SFC を `indexOf("")` で切ったら、入力欄が検査の範囲から落ちた（初回の案内・2026-09-13） **症状**: 初回の案内の配線を留める走査テスト（`lib/chatZoomWiring.test.ts` の初版、後に `tourTargets.test.ts` と同じ形）が、`ChatPanel.vue` のテンプレート部分を `panel.slice(panel.indexOf(""))` で切り出し、「`chat-zoom` クラスが 2 要素に付いている」を検査したら **1 しか数えず赤になった**。実装は正しく 2 箇所に付いていた。 **真因**: `ChatPanel.vue` には `` が **6 個**ある — root のほかに `