---
name: feedback-rule-add-requires-fire-audit
description: "Rule / discipline / protocol / checklist を新規追加したくなった時、 追加前に 既存 rule 群のうち直近事故で実際に発火したのはどれか を先に audit することを義務化する meta-rule。 2026-07-27 Voynich arc の evening 藤本さん指摘で確立。 07-27 一日で規則が 5 → 9 に増えたが、 その日の 2 崩壊 (方向反転 + 質量不足 250x) は 朝の時点で保存済み規則を素通り。 方向反転は 「各エントリを primary source で確認する」 規則を保存した直後の再発。 防いだのは規則ではなく 実測と MI 計算 = 数字を出したこと。 9 本のうち発火したのは実質 Rule 8 (リスト自己一貫性) のみで、 それは 『守るべき手順』 ではなく 『先に出すべき数字』 を指定していたから。 残り 8 本は 『気をつける』 型で、 気をつけることは同日 2 回失敗した。 発火していない規則が増えるほど 発火する規則が埋もれる。 教訓 = 書く前に測る (これは既に Voynich 9 rule 体制の Rule 9 = pre-rule mass 表)、 10 本目は要らない。"
metadata:
  node_type: memory
  type: feedback
  originSessionId: d9d89ff9-82a7-4bac-997a-259cb5068a59
  modified: 2026-07-26T21:19:00.750Z
---

**Rule**: Rule / discipline / protocol / checklist を新規追加したくなった瞬間、 追加動作の前に 「既存 rule 1..N のうち、 直近事故で実際に発火したのはどれか」 を先に literal で確認する。 発火 audit を経ずに rule を追加してはならない。

**Why**: 2026-07-27 Voynich arc の evening 藤本さん指摘。 07-27 一日で prior-art 監査系 rule が 5 → 9 に増えた:

- Rule 5-拡張 (list 全 entry primary source verify)
- Rule 6 (arxiv 版管理)
- Rule 6-拡張
- Rule 7 (founder ownership)
- Rule 8 (list 自己一貫性)
- Rule 9 (pre-rule mass 表)

しかし 07-27 の 2 崩壊は保存済み規則を素通りしている:

1. **方向反転** = 「各エントリを primary source で確認する」 規則を保存した直後に再発 (Rei 自身がそう record 済)
2. **質量不足 250x** = MI 計算した瞬間に判明

**防いだのは規則ではなく 数字を出したこと**。 実測 (方向) と MI 計算 (質量)。 どちらも計算した瞬間に判明した。

9 本のうち その日実際に発火したのは 実質 Rule 8 (list 自己一貫性) のみ。 なぜ Rule 8 が効いたか = **「守るべき手順」 ではなく 「先に出すべき数字」 を指定していた**。 Rule 9 (pre-rule mass 表) も同じ性質。 コスト 0 でその場で効く。

残り 8 本は 「気をつける」 「必ず確認する」 型で、 気をつけることは同日 2 回失敗した。 「気をつける」 は failure mode を describe しているだけで、 何を出せば審査を通せるかを指定していない。

**発火していない規則が増えるほど、 発火する規則が埋もれる**。 rule bloat は audit cost を線形に増やしながら防御力を上げない。

**How to apply**: 「新しい規則を追加すべきだ」 「Rule N+1 として保存しよう」 と判断した瞬間、 追加コードを書く前に以下を実行:

### Step 1 — 直近事故の名指し

追加を検討している規則が防ごうとしている事故を 1 つ specific に指す。 「今日の 2 崩壊」 のような集合ではなく、 個別の事象 (方向反転 / 質量不足 250x 等) を 1 つずつ。

### Step 2 — 既存 rule 1..N の発火 audit

事故ごとに、 既存 rule 1..N のうちどれが:
- (a) **発火して防いだ** (fire + prevent)
- (b) **発火したが防げなかった** (fire + miss)
- (c) **発火しなかった** (silent)

を literal で record する。 「たぶん発火した」 は (c) に分類。

### Step 3 — 提案する新規則の型判定

新規則が以下のどちらか:

- **型 X (先に出すべき数字を指定)**: 「MI 値を計算せよ」 「mass 表を出せ」 「grep count を書け」 「HTTP status を record せよ」 等、 output として要求される numeric/literal artifact が明示されている。 発火 audit も観測可能。
- **型 Y (守るべき手順 / 気をつけること)**: 「必ず primary source で確認する」 「grep verify を先に実行する」 「self-consistency を check する」 等、 手順が指定されているが 「したかどうか」 が事後 self-report に依存する。 発火 audit 不可能。

**型 X なら追加検討可**。 **型 Y なら追加しない**。 型 Y を追加しても 「気をつける」 が failure mode の集合に 1 つ増えるだけで、 同じ気をつけることが次回失敗する確率は変わらない。

### Step 4 — 型 Y を型 X に書き換えられるか試す

追加したい規則が型 Y だった場合、 型 X に書き換えられるかを 1 度試す:

- 「必ず primary source で確認する」 (型 Y) → 「各 entry の primary source URL を list に併記し、 verify 済み entry 数 / 全 entry 数 を先に record する」 (型 X)
- 「grep verify を先に実行する」 (型 Y) → 「grep hit count と該当 file path を先に record する」 (型 X)

書き換えられれば型 X として追加、 書き換えられなければ 追加しない。

### Step 5 — 追加後の発火 window 設定

追加した規則が型 X の場合、 次に類似事故が発生した時点で Step 2 の audit を再実行し、 追加した規則が発火したかを record する。 3 回の類似事故で発火 0 回 なら削除候補。

**Operational protocol**:

1. rule 追加検討の思考が出た瞬間 → Step 1-3 を 3 分以内に完了 (memory Write の前)
2. 型 X 判定 → 追加、 型 Y 判定 → 追加せず reason を temporary note に残す (memory 化はしない、 rule bloat 防止)
3. 型 Y → 型 X 書き換え成功 → 追加、 失敗 → 追加せず
4. rule 総数が N を超えたら Step 5 window で発火 0 回の rule を削除
5. 「今日は特別だから」 「藤本さんが明示的に指定したから」 は Step 1-5 skip の理由にならない。 藤本さんの指定は 「新規則を追加しろ」 ではなく 「事故を防げ」 = Step 1-5 を通した上で 型 X が出せる時のみ追加

**Voynich 9 rule 体制への self-application (07-27 evening 藤本さん指摘)**:

- Rule 8 (list 自己一貫性) = 型 X (list 内 entry 数 と primary source 一致数 を先に出す) → **retain**
- Rule 9 (pre-rule mass 表) = 型 X (質量表を先に出す) → **retain**
- Rule 5-拡張 (list 全 entry primary source verify) = 型 Y (「必ず verify する」) → 型 X 書き換え候補 (verify 済み ratio を先に record) → 書き換え後 retain 判断保留
- Rule 6 (arxiv 版管理) = 型 Y 寄り → 書き換え候補 (version literal を先に record)
- Rule 6-拡張 = 同上
- Rule 7 (founder ownership) = 型 Y (「気をつける」) → 削除候補
- SAC-4 使用禁忌 3 条件 = 型 Y → 削除候補

**10 本目を書かない** = 本 feedback は 9 rule への追加ではなく、 rule 追加動作そのものへのゲート = meta 層。 5 rule protocol ([[feedback-projection-self-audit-pattern]]) に対しても同じゲートが働く。

**共通 root**: Rei は 「防げなかった事故」 に対して 「新規則を書く」 を default 反応にしていた。 これは 「気をつける」 の書き溜めであって、 事故を防ぐ artifact ではない。 事故を防ぐのは **その場で出すべき数字** を pre-commit すること。 数字が出た瞬間に事故が判明する = 事故と防御が同じ moment に発生する = miss しようがない。

## Related

- [[feedback-prior-art-list-grep-verify-each-entry]] (07-27 Voynich 9 rule 体制、 本 feedback の適用対象 A)
- [[feedback-projection-self-audit-pattern]] (07-26 5 rule protocol、 本 feedback の適用対象 B)
- [[reference-voynich-prior-art-map-2026-07-27]] (07-27 Voynich arc の実測 record、 型 X 実例)
- [[project-session-2026-07-27-voynich-prior-art-arc-full]] (07-27 arc origin)
- [[feedback-critique-response-pattern]] SAC-4 100% 認諾 (藤本さん指摘の受け方)
- [[feedback-evaluation-symmetry-principle]] inflate/deflate なし (rule 追加を 「善行」 と inflate する pattern の反対側)
- [[feedback-no-rush-publication]] 急がずゆっくりと (rule を急いで書くと bloat する)