---
name: feedback-grep-before-answer-discipline
description: 永続原則 11 軸目 — answer (特に 『私の記憶にない』 『見つからない』 『削除された』 等の否定形) を書く前に必ず grep で実測する。 2026-06-19 self-incident 7+8 件目 (Mastodon URL / Hatena URL / Paper 167 title を verify 前に 『記憶にない』 と即断 → 藤本さんの確認質問で grep 実行 → 全 3 件 project 内に存在) からの operational extraction
metadata: 
  node_type: memory
  type: feedback
  originSessionId: c5b0ac29-996a-419f-89f7-b38a5da3a52c
---

# answer 前に grep 永続原則 (11 軸目)

## 原則本体

何かについて answer を書く前に、 特に以下のような **否定形 claim** を出す前に、 必ず grep で実測する:

- 「私の記憶にない」
- 「見つからない」
- 「記録されていない」
- 「削除された (疑い)」
- 「project 内に存在しない」

これらは **「私の context window 内に見つからない」 ≠ 「project 内に存在しない」** の混同を生む典型表現。 「context にない」 と書きたい時も、 まず実 file system を grep してから判断する。

## Why

私 (Claude session) は限られた context window 内の情報しか直接見えない。 CLAUDE.md + 起動時 MEMORY.md 抜粋 + 本 session 中に Read した file のみが直接 access 可能。 **memory file 全体 (60+ file) + project source (10,000+ file) + data/ + scripts/ は default では見えない**。

context 内検索だけで 「無い」 と即断するのは:

1. **藤本さんに 「削除されたのか?」 と疑念を生じさせる** (実害: 本日 self-incident 7 件目で藤本さんが不安になった)
2. **memory に確実に記録されている data を 「無い」 扱いする** (実害: 重複作業 / 既知 data の再 query 依頼)
3. **prior art / 既達実装の見落とし** (Pattern 5 = chat-Claude が既達 features を再提案する pattern を私自身も犯す)

grep は 1-2 秒で済む安価な操作で、 cost-benefit が圧倒的に grep 側。

## How to apply

answer を書く前の 3 段 mandatory check (否定形 claim を含む時):

### 段 1 — memory 全 file grep

```bash
grep -rh -i "<keyword>" C:/Users/user/.claude/projects/C--Users-user-rei-aios/memory/ 2>/dev/null | head -10
```

### 段 2 — project source grep (必要時)

```bash
grep -rh -i "<keyword>" data/publications/ scripts/ src/ papers/ 2>/dev/null | head -10
```

### 段 3 — verify した結果を answer に明示

「**実 grep した結果見つからなかった**」 (積極的 negative result) と
「**context window に見えなかった (= 削除や不存在ではない)**」 (passive absence)
を明確に区別して書く。

例:
- ✅ OK: 「memory + project source を grep しましたが、 該当する URL/値は見つかりませんでした」
- ✅ OK: 「context window 内には見えませんが、 grep していないので存在可能性あります — search しますか?」
- ❌ NG: 「私の記憶にない」 「project 内には記録されていない」 (grep 実測なし claim)

## 違反事故記録 (本日累積 8 件)

### Self-incident series 2026-06-19 (本日 1 日で 8 件)

| # | 内容 | severity | trigger |
|---|---|---|---|
| 1-2 | capacity baseline 推測 2 連発 (30 GB 解放 + 20K 制限到達直前) | low | git count-objects + ls-files の実数値 verify せず推測 |
| 3 | onshoku-jiten reach 「SPA hijack」 即断 | low | curl polling せずに「2380 B = SPA fallback」 と即断 (実は deploy pending) |
| 4 | code-future-lens 「同方式で reach」 claim | low | 実測したら 0B、 「既存 pattern が動いている」 と推測 |
| 5 | ★ **大量 delete 事故** (oukc/ 5 + tools/ 3 page) | **high** | `vite build` のみ + `git add dist-renderer/` + `git status` 検閲 skip |
| 6 | MEMORY.md に dead link 追加 (記録 turn で記録 protocol 違反) | medium | memory file 作成と index 追加の atomic 性欠如 |
| 7 | ★ Mastodon URL / Hatena URL / Paper 167 title 「私の記憶にない」 | medium | **grep せず即答** → 藤本さんの確認質問で grep → 全 3 件 project 内に存在 |
| 8 | MediaWiki 行頭 space → pre-formatted リスク予見不足 | low | 標準仕様だが「indent 付いて貼られる」 ケースを事前 advisory しなかった |

7 件目から本永続原則 (11 軸目) を抽出。 共通 root cause: **answer を書く速度を grep cost より優先してしまう傾向**。

## Reflexive scope

本原則の reflexive 適用:

- 「11 軸目永続原則」 と書く前に、 既存 10 軸目までの永続原則 list を実 grep で verify (memory directory に feedback_* file が 10 個以上あるか確認、 軸番号が衝突しないか)
- 「self-incident 8 件目」 と書く前に、 過去 incident counter の実値を verify
- 「藤本さんが 〜と仰った」 と書く前に、 本 session 直近 message を re-read
- chat-Claude 引用は [[feedback-chat-claude-over-deference]] と組み合わせて 二重 verify

## 関連永続原則

- [[feedback-paper-publish-verification-discipline]] — 9 軸目 (paper publish 前 publish-log 必ず read)、 本原則と同型の verify-before-act discipline
- [[feedback-dist-renderer-mass-delete-prevention-protocol]] — 10 軸目 (dist-renderer/ commit 時 3 段 check)、 本原則は claim 一般版
- [[feedback-chat-claude-hallucination-warning]] — chat-Claude を信じすぎる Antipattern + 信じなさすぎる Antipattern の両軸、 本原則は「**私自身を信じすぎる**」 第 3 形態
- [[feedback-chat-claude-over-deference]] — chat-Claude の framing を無批判採用する傾向、 本原則は私自身の context window を無批判信頼する傾向
- [[feedback-evaluation-symmetry-principle]] — 評価対称性原則 (inflate / deflate 両方避ける)、 本原則は claim の confidence level を grep 結果に対称的に合わせる
- [[reference-rei-aios-capacity-baseline-2026-06-19]] — 本日 self-incident series origin (1-2 件目)
- [[project-step1228b-onshoku-os-v04-site-integration-2026-06-19]] — 5-6 件目発生 record

## 適用例 (具体)

### 否定形 claim の正しい型

藤本さんが 「X の URL は記録ありますか?」 と聞いた時:

```
1. grep -rh -i "X|<X 関連 keyword>" memory/ project_source/ 2>/dev/null | head
2. 結果が空 → 「grep しましたが見つかりませんでした (memory + project source 検索済)」
3. 結果が hit → 「★ memory に確かにありました: <値>」 と honest 補正
```

### 否定形 claim の誤った型 (2026-06-19 で犯した)

```
1. context window scan → 見えない
2. 即答: 「私の記憶になく」
3. 藤本さんが確認質問
4. grep 実行 → 全 3 件存在
5. self-incident 7 件目認める + 修正
```

→ **step 2 と 3 の間に grep を挟むだけで防げる**。 1-2 秒の grep cost で incident 1 件削減。

## 適用範囲外

- ファイル新規作成時 (= grep 結果なくて当然)
- 「私 (Claude) が今 turn 中に行ったこと」 についての report (context 内で完結)
- 一般知識 (例: MediaWiki 行頭 space 仕様) について書く時 (但し project 固有値が混ざる claim は注意)

## sustained operational impact

本原則は「memory + project source を実 grep する習慣」 を強制することで:

- 藤本さんからの 「削除疑い」 質問を予防
- 既達 features の再提案を予防 (Pattern 5 防御)
- chat-Claude 提案を「prior art audit せず採用」 を予防 (本原則は chat-Claude だけでなく **私自身の発言** にも適用)
- memory system の 60+ file 蓄積を operational に活用

11 軸目として永続原則 hierarchy 完成。