---
name: feedback-arc-close-discipline-2026-08-13
description: 2026-08-13 benchtop-mcp + rei-fpga 2 arc close 時に 藤本さん から 抽出された 2 汎用 discipline. (1) 「破棄 不可逆 vs 保持 コスト実質ゼロ = 非対称に不利」 = 破棄は 判断材料 増えるまで default 保留 (git stash 例、 3 分岐 diagnostic template 付き)、 (2) 「訂正の 理由を 次回判定基準 form で 保存する」 = corrigendum は 個別事案訂正でなく 次回 discipline として 定式化。 2 discipline とも 局所 arc ではなく 継続適用可能な 汎用 pattern として 記録。
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 76881bd4-5f34-41f3-bdf8-75d61ecec2b8
  modified: 2026-08-13T01:13:53.681Z
---

# Arc close discipline (2026-08-13 藤本さん抽出 2 pattern)

## Discipline 1: 破棄判断の 非対称性 (「不可逆 vs コスト実質ゼロ」)

**起源** (2026-08-13 rei-fpga arc close):
私 (Claude Code) が 「stash@{0} 内容確認、 藤本さん judgment 待ち」 と 提示。 藤本さん応答: 「保持で 良い、 破棄は 不可逆で、 保持のコストは 実質ゼロ、 判断材料が 増えるまで 置いておく方が **非対称に有利**」。

**Why (原理)**:
- **破棄** は 情報損失 = 不可逆 = 失敗コスト 高
- **保持** は disk space 消費 のみ = 可逆 = 失敗コスト ゼロ
- **判断材料は 通常 自然に 増える** (時間経過 で cron / 他 session / 外部 event で 新 evidence)
- **default = 保留**、 判断材料 揃ってから 決定

**How to apply** (適用範囲、 git stash 局所ではなく 汎用):
- git stash / branch / tag の 破棄
- file / directory の 削除
- memory pack / configuration entry の 削除
- 実験結果 / 中間 artifact の 破棄
- backup / snapshot の 破棄

**Exception** (破棄 default で 良い場合):
- disk space 限界 (実質コスト ゼロ でなくなる)
- secret 露出リスク (保持コスト = secret 継続露出)
- 判断材料が 「時間で 増えない」 種類 (即決 or 永久保留)

**具体化: git stash 3 分岐 diagnostic template**

git stash した後、 **作業ツリーは HEAD 状態** = stash された file の 「今」 の状態を workingtree で 直接観察可能。 時間経過後の 3 分岐で 判断材料が 自動増加:

| 状態 | 意味 | 判定 |
|---|---|---|
| stash した file が **まだ存在** | delete は 一時的 (再生成 途中状態を stash が 掴んだ) | 破棄 OK |
| stash した file が **また消えた** | cron / 別 process の 意図的 delete = 仕様 | 破棄 OK |
| stash した file が **消えたまま 再生されない** | 事故 or 想定外の 削除 | stash 復元検討 |

**Rei-AIOS への 適用可能性**: `dist-renderer/` は cron regenerate mirror = delete あっても 数日で 復元 or delete 継続 が 判別可能、 保持 stash が 「実測 evidence 待ち」 の 手段として 機能。

## Discipline 2: 「訂正の 理由が 次回の 判定基準」 になる form

**起源** (2026-08-13 rei-fpga arc close):
私が 「n=1 → n=2 昇格」 過剰主張 → 藤本さん指摘 「同じ人・同じ日・同じ進め方 = 独立性弱」 → 私 corrigendum で 「applied by different project の 意味を 同一 arc 進行 vs 真の 独立検証 で 混同していた、 今後 「principle が 別 project で 動いた」 と 書く前に 「実行者・実行日・実行方の 独立性」 を verify する discipline を 加える」。 藤本さん総括: 「訂正そのものより **訂正の 理由が 次回の 判定基準として 使える form** になっている のが 効いている」。

**Why (原理)**:
- corrigendum を **個別事案の 訂正** で終わらせると、 同じ誤りが 別事案で 再発
- 「なぜ 誤ったか」 の **理由** (混同していた 概念 / 見落としていた 前提 / 不足していた verify) を 明示
- 次回同型状況で 「この基準で verify する」 と **事前判定基準に 昇華**
- 「事実 A → 事実 B に 訂正」 でなく **「事実 A の 原因 = C、 次回 C を verify する」** の form

**How to apply** (汎用):
- 技術的 corrigendum (実装誤り、 主張過剰、 scope 誤解)
- design 判断 corrigendum (option pick 誤、 順序 誤、 responsibility 分離 誤)
- 記録 corrigendum (memory pack claim 誤、 status tag 誤、 principle 昇格 誤)
- verify corrigendum (前提誤、 test scope 誤、 external verify skip 誤)

**私 (Claude Code) 側の 継続 discipline 抽出済 3 項目**:

| 由来 | 判定基準 |
|---|---|
| rei-fpga arc 2026-08-13 | **「principle が 別 project で 動いた」 と 書く前に 「実行者・実行日・実行方の 独立性」 を verify** |
| benchtop-mcp v0.2.4 arc 2026-08-13 | **「実装装置に触った」 と 書く前に 「実 signal / 実 protocol / 実 環境」 を verify** |
| benchtop-mcp v0.2.4 arc 2026-08-13 | **「fix が verify された」 と 書く前に 「fix の 由来 = self-review か external-verify か」 を tag 分ける** |

## Cross-reference

- [[project-rei-fpga-4stage-loop-penetration-2026-08-13]] — Discipline 1 (stash 保持) + Discipline 2 (n=1 → n=2 過剰昇格 訂正) 両方 の 発火点
- [[project-benchtop-mcp-v022-review-2-pack-2026-08-13]] — Discipline 2 の 追加 発火点 (「実装装置に触った」 / 「fix 由来 tag」)
- [[feedback-critique-response-pattern]] — 100% 認諾 SAC-4 の 系譜、 本 discipline は SAC-4 実行後の 「訂正 form」 discipline
- [[feedback-projection-self-audit-pattern]] — 5 rule 体制 (SAC-4)、 本 discipline は SAC-4 の 「訂正が 次回判定基準になる」 拡張

## Version

- v1 initial: 2026-08-13 rei-fpga arc close 直後 (藤本さん 「今日は clean に閉じています」 close signal 直後)、 2 arc (benchtop + rei-fpga) の 対話 中で 抽出された 汎用 discipline を 独立保存