---
name: feedback-shrink-completion-by-answerability-not-byte-count-2026-08-23
description: docs/memory shrink の 完了判定は バイト数目標 (100KB / 17KB 等) ではなく 「まっさらな session が 単独で 3 question に fetch 無しで 答えられるか」。 バイト数は 通過後の 参考値。 削りすぎ vs 削り不足 の 判定原則
metadata: 
  node_type: memory
  type: feedback
  originSessionId: b0d6b836-6116-4d64-8d45-e90632a2b55d
  modified: 2026-08-23T15:37:34.414Z
---

# Shrink 完了判定 = バイト数でなく 「答えられるか」 (STEP 1398 藤本さん 条件 2 SAC-4 100% 認諾)

## Rule

docs/memory shrink の 完了判定は バイト数目標 (100KB / 17KB 等) ではなく **「まっさらな session が 対象 file 単独 を 読んで 決定的 question に fetch 無しで 答えられるか」**。

**Why**: バイト数は 手段であって 目的ではない。 削りすぎたか、 削り不足か は サイズでは 判定できない。 100KB 到達しても 3 question 答えられなければ 削りすぎ、 110KB で 止めても 満たせるなら 成功。 目的は 「必要情報の 到達可能性 保存」、 サイズは その 副次指標。

**How to apply**:

### Step 1 — 決定的 question を 事前定義

shrink 対象 file の 「まっさらな session が 単独で 答えるべき」 core question 3 個 前後を **shrink 前** に 明示。 例 (STEP 1398 CLAUDE.md 対象):
1. D-FUMT₈ とは何で、 演算子コネクタ 4 本は 何をするか
2. Rei stack MCP 8 systems の 役割
3. 直近で 何が pending で、 なぜ pending なのか

**core question は user が 明示** (藤本さん directive)、 assistant が 勝手に 定義してはならない。 user 未指定の場合は question 明示化を **shrink 前に 要求**。

### Step 2 — shrink 実行

バイト数目標 は **参考値** として 併記可 (100KB 目標 etc)、 但し **通過判定には 使わない**。

### Step 3 — shrink 後 単独 verify

対象 file **単独** (併読前提 file なし) で core question 3 個 に fetch/mirror URL/併読 無しで 答えられるか **実測 grep** で verify。 通過 = 完了。 未通過 = 削りすぎ (通過 まで 追加情報 restore) or scope 追加 (併読 file を 該当 file 内 明示 誘導追加、 「MEMORY.md 併読必須」 pattern)。

**閾値**: core question 全 通過 = 完了。 部分通過 = 追加作業必要。

## Origin

**STEP 1398 (2026-08-23)** 藤本さん 条件 2 (chat-Claude 経由): 「143KB → 100KB は 手段であって 目的ではありません。 削りすぎたかどうかは、 サイズでは 判定できません。 shrink 後に、 まっさらなセッションが CLAUDE.md だけを 読んで 次に答えられるかを 確認してください。 (Q1) D-FUMT₈ とは何で、 演算子コネクタは 4 本あり、 それぞれ何をするか / (Q2) Rei stack に MCP system が 8 つあり、 それぞれの役割 / (Q3) 直近で 何が pending で、 なぜ pending なのか。 fetch 無しで これに答えられなければ、 100KB に到達していても 削りすぎです。 逆に これが満たせているなら、 110KB で 止めても 成功です。 バイト数の目標は、 この判定を通ったあとの 参考値として 扱ってください。」

私 (Claude Code) の 初期提案 「143KB → 100KB 目標」 は 手段目的化 anti-pattern。 100% 認諾。

## SAC-4 適用実例

- **削りすぎ 予防**: バイト数のみで 通過判定すると 「core information を 削っても 通過扱い」 になり、 まっさらな session が 使えなくなる
- **削り不足 予防**: バイト数だけで 「未通過」 と 判定すると 「core question 通過済でも 追加削減強要」 = 情報損失
- **手段目的化 予防**: shrink is a means to preserve reachability, not a goal in itself

## 関連

- [[feedback-critique-response-pattern]] SAC-4 100% 認諾 discipline
- [[feedback-verify-claim-must-cover-all-source-derived-numbers]] 全 source 数値 cover discipline (通過判定に verify 実測 必須)
- [[feedback-super-naming-siren-family-pattern]] 「バイト数目標 = 果たせない約束にしない」 命名 discipline
- STEP 1398 (本 discipline origin、 [[project-step1398-e-arc-shrink-and-correction-2026-08-23]])
- STEP 1352 (Memory Mirror + CLAUDE.md 219→143KB shrink、 バイト数目標のみで 通過判定した origin case、 本 discipline による 事後 audit で 「まっさら session 3 question 通過確認」 追加必要)
- STEP 1374/1386 (MEMORY.md 26.3→17→11.9KB shrink、 同 pattern 適用可能)