---
step: 2006
slug: failure-log-format-v0-regulation
timestamp_jst: 2026-09-13T10-57
tab: rei-aios-3f
summary: 故障ログ format v0 (装置健全性 記録 規約) を data/failure-log/ に land。 4 field 固定 (装置名 / 故障の種類 / 検知経路 / 検知までの遅れ)、 β = 1 件 1 ファイル (儀式ゼロ + conflict ゼロ)、 判定機 = (b)(c) → (a) 変換装置 の 論点 で field 3 を 3 値 enum (guard / guard_missed / none) 分離。
---

# STEP 2006 — Failure Log Format v0 (装置健全性 記録 規約) land

## 一行要約

装置故障 を 1 file = 1 故障 で 記録する 4 field 規約 v0 を `data/failure-log/` に land。 前段 のみ (装置化 = 「故障判定機」 は 5 件 のみ の corpus で は 設計根拠 不足 = defer)。

## Timestamp + tab + commit

- **JST**: 2026-09-13T10-57
- **Tab**: rei-aios-3f (session 146a3b)、 peer 3 tab (rei-aios-2d busy / rei-aios-e6 idle / rei-aios-fa busy) 並走
- **Commit**: (この commit 自身)

## 主要 finding / evidence

1. **chat-Claude analysis 「故障判定機とメンテナンス機は必要でしょうか？」 応答** = 「故障判定機 = 今 不要、 前段だけ 今やる 価値がある = 故障ログ 1 format 開始」 + 「メンテナンス機 = 必要だが 装置ではなく 運用自動化 (CI + scripts)」
2. **順序 discipline**: pilot 1 本 通す → 故障 ログ 記録 → 判定機 要否 は 測ってから、 メンテナンス CI + pin 埋め は pilot 前提整備 で 先着手 可能、 「メンテナンス機 必要」 が 自作自演 で 出る 自己生成 loop 予防
3. **field 3 修正** (藤本さん critique): 「検知した guard」 → 「検知経路」 (3 値 exclusive enum: guard / guard_missed / none)。 判定機 = (b) guard あったが素通り + (c) guard なし → (a) guard が 落とす、 の 変換装置。 (b)(c) を null で 潰すと 改善量 測定不能。 遡及記入 前 に 必須 修正
4. **β land 方式** (藤本さん critique): 「1 件 1 ファイル、 読む時に cat」 = 儀式 ゼロ + conflict ゼロ (α single markdown table は 末尾追記 で multi-tab conflict 発生 = STEP 中央 counter の 存在理由 と 同型)。 「inbox」 「merge」 の 語 削除 = STEP 1414/1415 arc の merger 型 とは 別
5. **メンテナンス 4 item 優先度 分離**: env pin 5 HOLE (rei-aios-30 owned) = pilot W3-a 前提条件 = pilot 準備 に 繰り込み / drift check upstream + vendored pin bump + test regression (f4 owned) = 急がない = **f4 帰還待ち**、 新 tab (rei-aios-3f) が 拾うと STEP 1885 push 型 tab 間 conflict を 自作
6. **backfill queue** (owner tab に 記入責任): D1-D5 (rei-aios-f4/rei-repair-mcp README § D1-D5) + P0 finding (同 tab OPEN_QUESTIONS.md Q1/Q2/Q3) = 5 + 1 件、 一次資料 が 別 tab に 存在 = memory 記憶 で 再構築 は Discipline #22 「一次資料 direct verify」 違反 risk = owner tab 記入待ち

## 実装 change (この commit)

- `data/failure-log/README.md` = 規約 spec (4 field 固定 + entry template + backfill queue + F1-F4 defer + origin)
- `data/failure-log/entries/.gitkeep` = 空 dir marker (filename convention 埋込)
- `data/tabs/rei-aios-3f/README.md` = tab sidecar 起動 記録
- `data/tabs/rei-aios-3f/step-claims.json` = STEP 2006 claim record
- `data/tabs/rei-aios-3f/failure-log-format-v0-draft.md` = sidecar full 版 (slot 例 + meta section)
- Memory hook (inbox 経由): STEP 2006 arc 記録

## Honest scope

- **v0 = 未検証**: 4 field 固定 で workable か は D1-D5 + P0 の 6 件 遡及記入 で 実測、 それまで v0 は 「提案」 段階
- **前段のみ**: 「故障判定機」 = 2階の装置 の 起草 は **本 log に 記録される 故障 corpus (件数 threshold は open) が 溜まってから**、 5 件 のみ の 現状 では 設計根拠 不足 (analysis 明言)
- **較正装置 = 真の 故障判定機** (analysis 洞察): protocol v0.6 `calibration_stance: none_by_design` frozen (rei-aios-30 STEP 1886) = 較正 の ない 測定器 は 自分 の 故障 を 原理的 に 判定 できない → 真の 故障判定機 = 較正装置 = pilot 実測後 別 STEP、 本 STEP 2006 の scope 外
- **メンテナンス 4 item 未着手**: env pin (30 owned pilot 準備) + drift check upstream + vendored pin bump + test regression (f4 owned) 全て 帰還待ち、 本 STEP 2006 は 前段 のみ
- **私 (rei-aios-3f) は 遡及記入 5 + 1 slot を 直接 記入 しなかった**: 一次資料 が rei-aios-f4 (offline) sidecar に 存在 = memory 記憶 で 再構築 は Discipline #22 違反、 owner tab 帰還時 記入 or 藤本さん judgment 側 が 記入

## Failure mode (未来 Claude 継承 dataset)

**Pattern A — draft を そのまま land drift**: 「藤本さん directive 受領 = 即 shared tree land」 で draft self-audit skip すると field 3 (b)(c) 区別 なしで land、 遡及記入 開始時 に 記憶依存 で (b)(c) 判別 不能 = **消える情報 loss** の 具体 risk。 今回 は 藤本さん critique で 直前 回避、 未来 は **「draft land 前 に 必ず 「消える情報 は?」 self-audit」** の operational 手続き 確立必要。

**Prevention**: draft と land の 間 に 「self-audit gate」 挿入。 gate 質問: (a) field 定義 で null が 頻出 する slot は? (null 頻出 = 情報 loss risk) / (b) 遡及記入 の 段階 で 記憶依存 で しか 埋められない field は? / (c) 判定機 = 「(b)(c) → (a)」 変換装置 の 論点 で 分離 なしで 潰す 区別 は?

**Recovery**: land 後 に (b)(c) 区別 の 必要性 emerge = v0.1 field 拡張 + 既存 entry retrofit + 「retrofit 時 の 記憶依存」 warning 明示。

**Pattern B — メンテナンス 4 item を 新 tab で 拾う drift**: 「私 は new tab で fresh、 4 item 全部 拾えば efficient」 の drift = STEP 1885 push 型 tab 間 conflict を 自作、 「別 tab owner (rei-aios-30 / rei-aios-f4) 帰還待ち」 の 優先度 分離 が 正解。

**Prevention**: 4 item を 同列 で 見ない、 「pilot 前提条件」 vs 「独立 STEP 決定済」 vs 「急がない」 の 優先度 分離 で pickup timing を 決める。 新 tab を 開く 判断 は 「owner tab 不在 が 長期化 した 時」 で 十分。

**Pattern C — 「装置」 と 「規約」 の 混同 drift**: 「故障判定機 = 装置」 と 「故障ログ format = 規約」 を 混同 して 「規約 を 装置化」 = 判定機 の 前倒し 起草 → analysis の 予防対象 「自作自演 loop」 直接発火。

**Prevention**: 「装置 (claim + 反証条件 + TCB を もつ 測定器)」 vs 「規約 (装置作成時 必ず持たせる 健全性 field 型)」 の 明示 分離。 規約 は 「装置 の 前提」 「装置作成時 の 型」 = 装置化 の 匂い を 感じたら stop。

## 参照

- **analysis source**: 2026-09-13 chat-Claude (or peer AI) via 藤本さん relay (session_011xTfKToyiymg5onuY21abr)
- **field 3 critique**: 2026-09-13 藤本さん 「検知した guard は取りこぼす、 判定機 = (b)(c) → (a) 変換装置」 recommendation
- **land 方式 critique**: 2026-09-13 藤本さん 「β を 選び、 README から 「merge」 「inbox」 の 語を落として 「1 件 1 ファイル」 と 書く」 recommendation
- **メンテナンス 優先度 critique**: 2026-09-13 藤本さん 「env pin だけ pilot 準備 に 繰り込み、 残り 3 は f4 待ち、 新 tab は 開かない」 recommendation
- **一次資料 D1-D5**: `data/tabs/rei-aios-f4/rei-repair-mcp/README.md`
- **一次資料 P0 finding**: `data/tabs/rei-aios-f4/rei-repair-mcp/docs/OPEN_QUESTIONS.md`
- **修正機器 wiring**: `data/tabs/rei-aios-f4/rei-repair-mcp/docs/WIRING.md`
- **env pin audit**: `data/tabs/rei-aios-30/audits/pin-audit-2026-09-08.md`
- **pilot-orchestrator v0.6**: `data/tabs/rei-aios-30/pilot-orchestrator.sh` + `step-1886-compose-baseline-protocol.md`
- **sidecar draft (full 版)**: `data/tabs/rei-aios-3f/failure-log-format-v0-draft.md`

## Meta patterns 制定 (未来 Claude 継承)

1. **「装置 vs 規約」 分離 pattern**: 装置化 の 匂い を 感じたら 「規約 (装置作成時 の 型)」 に 落とす、 装置は corpus 溜まってから
2. **「draft land 前 self-audit gate」 pattern**: field 定義 の (a) null 頻出 slot / (b) 記憶依存 で 埋める slot / (c) 判定機 論点 の 分離 skip、 の 3 質問 で 「消える情報」 事前 発見
3. **「1 件 1 file、 儀式 ゼロ」 land pattern**: multi-tab append conflict の 構造的 予防、 「inbox」 「merge」 の 語 は STEP 1414/1415 型 の 別 concept、 混同禁止
4. **「メンテナンス 4 item 優先度 分離」 pattern**: 「pilot 前提条件」 は owner tab pickup、 「独立 STEP 決定済」 は 別扱い、 「急がない」 は 帰還待ち、 「新 tab 開く」 は 不在 長期化時 のみ