エージェントハーネス設計 v7 — 記憶体系（貯めるではなく、読む・刈る）¶
状態: 人間ゲート通過（2026-09-15・akapen 4 問に回答・全体への赤ペンなし）・bd 起票済み（親 wl-2w3p）。
経路: eval-loop 1 周 86 点（閾値 80）→ 評価者が指摘しコーディネーターが独立に再現した事実誤り 1 件（§1-4 の「役割 4 ファイル」）と
派生 5 点を訂正 → akapen シート akapen/harness-v7-memory-01.html（試問 2 巡・問い 4）→ 回答を §7 と本文へ反映。
シート作成中に本書の数値の誤りをもう 1 件見つけて訂正した（§1-4 の索引の行長。文字数以外の単位で数えていた）。
訂正分と §7 は採点されていない（86 点は訂正前の版に対する点）。
前版: v6 — 分岐の根拠と評価の独立性。v6 の規律はすべて不変。
正典の優先順位は ユーザー指示 > AGENTS.md > 本設計 > プラグイン既定（v6 と同じ）。
0. 読めた範囲と読めていない範囲¶
素材は masa_wunder 氏の記事 1 本の公開部と、2026-09-14〜15 の開発記録（10 PR・レビュー 17 巡）である。 有料本文（¥24,800〜）は未読。以下は公開部の要約であり、非公開の実装を再現したものではない。 人間ゲート（§7 Q4）で購読して照合すると決まった（人間タスク wl-3iez → 照合 wl-yxen）。読めた時点で §3 と照合し、違いがあれば根拠付きで改訂する。それまで本書は公開部と Greco の実測だけで自立する。
| 記事 | 公開部で読めた主張（要約） | 読めていない範囲 |
|---|---|---|
| 第二の脳を作れ！記憶体系の重要 1 ピース『LLM-Wiki』（2026-09-14） | LLM が忘れるのは「覚えておく場所を与えていないから」。3 層＝生の資料（人が集め・LLM は読むだけ）/ Wiki（LLM が書く Markdown・継続更新）/ スキーマ（Wiki 構成のルール）。3 操作＝入れる / 聞く（良い答えを wiki に戻す）/ 点検する（矛盾・古い記述）。RAG は整理結果を使い捨てるが LLM Wiki は記録して再利用する | 本文の実装・ディレクトリ構成・プロンプト・運用例 |
§3 はこの 3 層 × 3 操作を手掛かりに、Greco の記録から導いた運用上の裁定である。 記事の提案そのもの、または効果が検証済みの手法とは認定しない。
この文書の数値そのものが、この文書の主張の実例である。 §1 は 2026-09-15 07:45〜07:55 の実測だが、 同日早朝に書いた草案からすでに 7 項目が動いていた（§1 冒頭の差分表）。 草案が「これから直す」と書いた提案が、書いている間に実行済みになっていた例が 2 件ある: §3-4（resume-state の分割）と、§3-3 が「最初の対象」に挙げた役割ファイルの統合（§1-4 の訂正）である。 後者は本書の eval-loop の評価者が見つけたもので、書き手（生成）も計画（コーディネーター）も見落とし、 「4 ファイルが別世代を語る」という既に偽になっていた記述を残したまま 1 周目を通した。 さらに report 件数は本セッション中の 9 分間に 757 → 760 へ動いた（§1-1 脚注）。 記録は古びる速度が速く、古びたことに気づく操作（§3-3）が無ければ、実測を売りにした文書ほど早く嘘になる。
1. 実測 — 3 層はすでに全部ある。壊れているのは 3 操作のほう¶
計測は 2026-09-15 07:45〜07:55、読み取り専用コマンドのみ（ls / wc / du / find / grep /
awk / comm / git ls-tree / bd show）。対象は
~/.claude/projects/-Users-kyoei-woo-Projects-waste-link-waste-link/memory/（memory）と
~/orca/workspaces/waste-link/*/（ワークツリー）と本ワークツリーの AGENTS.md。
再実測で草案から動いた項目（数字を黙って差し替えず、動いた事実のほうを残す）:
| 項目 | 草案（同日早朝） | 実測（07:45〜07:55） | 計測コマンド |
|---|---|---|---|
memory の .md 総数 |
116 | 115（索引 1 + 本体 114） | ls -1 *.md \| wc -l |
| memory 総量 | 796KB | 616KB | du -sk . |
| 8KB 超のファイル | 5 本 | 4 本（+ 索引自身） | find . -maxdepth 1 -name '*.md' -size +8k |
| 名前に日付を含むファイル | 2 本 | 1 本 | ls -1 *.md \| grep -E '20[0-9][0-9]-[0-9][0-9]' |
| 7 月以前から未更新 | 68 本 | 67 本（8 月以前は 86 本） | find . ! -newermt '2026-08-01' |
| verdict | 358 本 | 325 本 | find …/.worker-specs -name '*-verdict.md' \| wc -l |
| ワークツリー数 | 11 | 12（exec 6 / review 5 / coordinator 1） | ls -d …/waste-link/*/ |
差の大半は §3-4 の分割（171KB の 1 ファイルを memory の外へ出した）と、
草案が別ワークツリーのローカル値を数えていたことによる。verdict の 358 → 325 は「減った」のではなく、
草案の計測範囲が広すぎた（12 ワークツリーの .worker-specs に限定して再計測した値が 325）。
1-1. 層の対応表¶
| 記事の層 | Greco での実体 | 読者 | いつ context に入るか（記事の 3 分類・§8） | 実測（2026-09-15 07:45〜07:55） |
|---|---|---|---|---|
| 生の資料 | .worker-specs/*-report.md / *-verdict.md（12 ワークツリーに散在）、docs/superpowers/specs/**、JWNET 仕様書 PDF |
コーディネーター（verdict は投入前にコピーして読む） | 取りに行く（読むときに開く。context に常駐しない） | verdict 325 本・report 760 本。gitignore 対象だが develop に 27 本が追跡されている（git ls-tree -r --name-only origin/develop -- .worker-specs \| wc -l。wl-r010 起票時は 12 本・以後も増えた） |
| Wiki（コーディネーター用） | ~/.claude/projects/…/memory/*.md + 索引 MEMORY.md |
コーディネーターだけ（ワーカーには見えない・repo 外） | 索引は常に読ませる（毎セッション自動）・本文は取りに行く（grep → 開く）・指示書へ写した分は操作記憶（投入の直前に差し込む・§3-1） | 本体 114 ファイル / 合計 616KB。索引は 114 行・23,686 字・34,127 byte。索引⇄ファイルの対応は健全（索引 114 行 ⇄ 本体 114 本・欠落も孤児もゼロ） |
| Wiki（ワーカー用） | AGENTS.md の「不変条件ラチェット」節 |
全エージェント | 常に読ませる（314,661 byte 全部・上限超過で無視される・§1-5） | 314,661 byte（307.2 KiB）/ 79 節 / うち 64 節がラチェット。55 節が scripts/proofs/ へ接地＝歯つきの compiled knowledge。256,000 byte の読込上限を 58,661 byte 超過し、少なくとも 1 ツールで丸ごと無視（§1-5・wl-hgo7・P1） |
| スキーマ | memory: コーディネーターの system prompt 内（1 事実 1 ファイル・frontmatter・索引 1 行・[[link]]）。AGENTS: 冒頭の「唯一の正典」宣言と Routing 節。.beads/PRIME.md の分担表 |
memory の schema はコーディネーターの system prompt にしか無い（repo に無い・ワーカーは知らない） | 常に読ませる（system prompt） | type の内訳は feedback 41 / project 47 / reference 25 / feature 1（schema 違反・許容は user / feedback / project / reference） |
Wiki が 2 つあり、読者が違う。 コーディネーターは memory を読み、ワーカーは AGENTS.md を読む。 ワーカーへ届く知識は AGENTS.md に追記する以外に経路が無いため、ラチェットが 64 節まで積み上がって上限を超えた。 memory 側も同じで、追記が既定・削除と統合が無い。
report 760 本は本セッション中に動いた。 07:45 の計測では 757 本、07:54 の再計測で 760 本 （
find … -newermt '2026-09-15 07:45' \| wc -l= 5）。稼働中のワーカーが書き足している。 生の資料は「今いくつあるか」を固定できないので、§3-3 の検査対象にも §6 の見積の根拠にもしない。 固定できるのは wiki 側（memory・AGENTS.md）だけである。
1-2. 「忘れた」5 件のうち 4 件は記録済みだった（2026-09-14 実測）¶
| 事象 | 記録の所在 | 種別 |
|---|---|---|
| 仕様書の印刷ページ番号（2-15 等）を節番号と読んだ | memory jwnet-spec-pdfs-local-and-d31-layout が同じ罠を明記 |
取り出し失敗 |
接続テスト経路の照合手段に resolve_web_edi_submitting を書いた（jwnet_submissions 用で対象外） |
AGENTS.md JWNET 節「接続テスト経路が実際に使う RPC は next_jwnet_request_code のみ」 |
取り出し失敗 |
指示書に docs-manual-ratchet というファイル名を書いた（実在せず） |
memory docs-manual-ratchet-and-merge-gating — memory の名前をファイル名と取り違えた |
取り出しの型違い |
| 未リリース量を「165 commit」と書いた | memory release-pr-needs-release-branch-content-neutral-merge |
取り出し遅延（計算後に思い出した） |
message_type を 10 値と書いた（12） |
コードのみ | 記録なし |
5 件中 4 件は wiki にあった。 貯める規律（v3 の LEARN・v6 の決定台帳）はあるが、 行動の前に読む規律が無い。記事の「聞く」に当たる操作に発火点が無い。
1-3. 「入れる」が verdict から起きていない¶
2026-09-14 に verdict で確定し、プロジェクト横断で再発しうる知見:
toThrow(string)は部分一致。旧文言が新文言を含むと歯にならない（#805 R1）Set(...).sizeは出力文字列の個数を固定するだけで、トリガ⇄期待文言の対応は固定しない（#805 R2）- PostgREST は同一列の複数条件を AND する。
select=id,id,envは 200（#803 R2） is(null)の偽側は非 NULL の fixture 行が無いと一度も通らない（#803 R3）- nssm の停止猶予は各段階 1,500ms が既定。console 段階だけが SIGINT を運ぶ（#801 R3）
mergeable=MERGEABLEはテキスト衝突の有無だけ。意味的合流は交差の実測で（#801・#805）- 待受が armed の間に素の
checkを打つと delivery を横取りする（本セッション）
7 件のうち memory へ書いたのは 1 件（provider-billing-failure-is-silent-to-orchestration。
残りは resume-state の追記と chat のみ）。verdict は生の資料として 325 本たまっているが、
そこから wiki へ compile する操作がループに無い。
しかも、その 1 件は索引から溢れて読まれていなかった（§1-4）。 書く操作だけを直しても、索引の書式が壊れていれば読まれない。§3-2 と §3-3 は片方だけでは効かない。
1-4. 「点検する」が無い — 索引は容量ではなく書式で壊れる¶
索引の真因は総量ではなく 1 行の長さである。 ローダーは本セッションで次を逐語で警告した:
MEMORY.md is 24.5KB (limit: 24.4KB) — index entries are too long. Only part of it was loaded: 1 of 115 lines were cut off, starting at line 115Keep index entries to one line under ~200 chars; move detail into topic files.
ローダーは上限とあわせて書式の規約（1 行 200 字以下）を明示している。実測は次のとおり:
| 計測 | 値（文字数・2026-09-15 08:55 再計測） | コマンド |
|---|---|---|
| 索引の行数 | 114 | wc -l MEMORY.md |
| 200 字を超える行 | 66（＝ 58%） | python sum(len(l) > 200 for l in lines) |
| 最長の行 | 280 字 | python max(len(l) for l in lines) |
| 200 字以下の行 | 48 | 同上を反転 |
| 合計 | 23,685 字 | python len(text) |
訂正（akapen シート作成中に発見）: 草案は「112 行・最長 438」と書いていたが、これは awk の length() を
UTF-8 でない数え方（byte または表示幅）で走らせた値で、ローダーの規約「~200 chars」とは単位が違っていた。
文字数で数え直すと 66 行・280 字である。単位を書かない数値は、この文書が §5 で禁じている自己認定と同じ穴だった。
ローダーの「KB」は文字数 ÷ 1024 である（草案の §5 では再現できていなかった）。
警告時の索引は 25,082 字で 25,082 ÷ 1024 = 24.5、上限の 24.4KB は約 24,985 字（24.4 × 1024 = 24,985.6。表示は小数第 1 位への丸めなので、厳密な閾値は表示値からは確定できない）。
つまり警告は合計文字数が約 25,000 字を超えると出る。合計を押し上げているのが 1 行の長さで、
114 行がすべて 200 字以内なら合計は最大 22,800 字で上限に届かない。索引は
ローダーが明示した書式規約に 114 行中 66 行で違反しており、容量超過はその帰結である。
切り落とされた 1 行は provider-billing-failure-is-silent-to-orchestration
＝ §1-3 が「7 件中ただ 1 件 memory へ書けた」と誇っている当のエントリだった。
書いても索引から溢れて読まれない状態だった。索引は 07:43 に長い 14 行を短くして 115 行 → 114 行・23,685 字になり、
09-15 09:00 頃の再読込で警告が消え末尾行まで読み込まれたことを観測した。ただし 66 行が 200 字を超えたままなので、
数本足せばまた出る（I1 の是正対象）。
行が 1 本減った原因を §3-4 の分割に決め打ちしない: 分割は memory 内の改名 + 本文の移送で索引の行数を減らさず、
同じ 07:43 に coordinator-is-orchestrator-delegate-implementation の削除（下の訂正）も入っている。
どちらが減らしたかは未確認で、後者である可能性のほうが高い。
警告が消えたことは 09-15 の再読込で観測した（上記）。§3-3 の I1 は「ローダーの警告文を一次情報にする」
方針のまま、単位が分かったので自前閾値も同じ数え方（文字数）で置く。
容量を減らすのは対症療法で、行を短くしないと次の 1 件で再発する。
その他の症状:
| 症状 | 実測 |
|---|---|
| 8KB 超 | 4 本（opencode-muse-implementer-harness 14,882 / jwnet-pivot-webedi-to-standard-edi 13,030 / jwnet-webedi-avoids-gateway-and-connection-test 12,698 / notion-workspace-structure 10,145 byte）＋索引自身 34,127 byte |
| 同トピック複数ファイルの矛盾 | 草案は「誰が実装し誰がレビューするか」が 4 ファイルに分かれて別世代を語ると書いたが、再実測では既に解消されていた（下の訂正を見よ）。現存は 3 本で、implementation-codex-review-claude が索引 description で「役割と model routing の単一の現況 + 8 世代の遍歴」と名乗り、orca-worker-start-codex-harness-v5 は「モデルの現況は implementation-codex-revi…」と単一ソースへ委譲している。4 本目の coordinator-is-orchestrator-delegate-implementation は削除済み（ls で不在・索引にも 0 件） |
| 陳腐化の疑い | 本体 114 本のうち 67 本が 7 月以前から未更新（8 月以前まで広げると 86 本。frontmatter の modified が無いものは mtime で代用） |
| schema 違反 | type: feature が 1 件（許容は user / feedback / project / reference） |
[[link]] 切れ 15 件は 3 種類の混合だった。 素の \[\[[^]]*\]\] で拾って
ファイル名集合と comm -23 した結果を全部読むと、性質がまったく違うものが混ざっている:
| 種別 | 件数 | 実体 | 対処 |
|---|---|---|---|
| 迷子（参照先が存在しない） | 12 | codex-review-model-gpt-5-6-terra / coordinator-resume-state-2026-07-19 / coordinator-resume-state-2026-07-23 / eval-loop / external-partner-driver-mobile-visibility / jwnet-request-file-nominee-binding-gap / linear-project-naming-no-product-prefix / resource-weighing-optimization-design / roadmap-2026-07-10-walkin-release-and-3-features / roadmap-external-partner-then-release-then-jwnet-edi / secondary-transport-daiei-pl-request / weighing-business-extension-design |
張り替えるか削る（§3-3） |
| リンクでない記法（バッククォート内） | 2 | `[[kv_namespaces]]`（Cloudflare wrangler の TOML array-of-tables 記法・cloudflare-binding-deploy-real-wrangler.md:12）/ `functions/supabase/[[path]].ts`（CF Pages の catch-all ルートのファイル名・supabase-publishable-key-dlp-block-and-cf-pages-redeploy.md:43） |
検査から除外（永久に直らない偽陽性） |
| 書式が壊れたリンク | 1 | [[canactasdriver は AuthContext.tsx:58-60]]（散文をブラケットで囲んだもの・epd-attribution-canactasdriver-and-live-partner.md:12）。バッククォート外なので除外規則では落ちないが、参照先に空白と : を含むのでファイル名ではありえない |
別枠で列挙（§3-3 の I5） |
素の正規表現だけの検査は、15 件のうち 3 件を毎回ノイズとして出し続ける。 偽陽性が 2 割ある検査は読まれなくなり、点検そのものが死ぬ。 v6 が「検査に歯があるか（わざと壊して落ちるか）」を要求したのと同じ問題の裏側で、 検査に嘘の歯が無いかを同時に確かめる必要がある。
1-5. スキーマと Wiki の癒着（AGENTS.md）¶
AGENTS.md は「機械が守る不変条件」（スキーマ）と「機能ごとのラチェット履歴」（compiled knowledge）を 1 ファイルに持つ。後者が 64 節・うち 55 節は proof 接地で価値が高いが、スキーマまで一緒に読めなくなった。
wl-hgo7（P1・OPEN・2026-09-13 起票）が記録した Muse Code 1.2.1 / exec-rigel での観測は次の 2 本である:
(1)
rules file at .../AGENTS.md is 307753 bytes, over the 256000 byte load limit; it is skipped for this session(2)rules file at .../CLAUDE.md is ignored this session because AGENTS.md takes precedence in that directory
2 本目が効く。 AGENTS.md が上限超過で捨てられ、その巻き添えで CLAUDE.md も優先度規則により無視されるので、 そのセッションは正典を 1 文字も持たない。「大きすぎて読まれない」より一段重く、 分割しないかぎり回避策が無い（CLAUDE.md へ退避する手が塞がれている）。 現行の Claude / codex / OpenCode で同じ上限に当たるかは未実測＝ [仮説]。
分割は wl-hgo7（P1・設計スライス）の範囲であり、本書は分割後の置き場のルールだけを決める（§3-6）。
2. v6 のどこに穴があったか¶
v6 は「書く」規律を足した — 決定台帳（§3-1）・変異表（§3-4）・往復の記録（§3-6）。 書かれたものは増えたが、読む前提と刈る前提が無かった:
- 指示書テンプレートの「参照する仕様・証跡」は仕様と proof を指す欄で、memory を引く欄ではない。 コーディネーターが memory を読んだかどうかは指示書に痕跡が残らない
- verdict を読んだ後の処理は「APPROVE ならマージ・BLOCK なら R+1」の 2 分岐だけで、 知見を wiki へ戻す分岐が無い
- memory の schema はシステムプロンプトにしか無く、違反を検査するものが無い （索引の行長規約は、ローダーが警告を出すまで一度も見ていなかった）
3. 差分 — v7 で足す 6 点（すべて既存ループへの挿入・新しい器は作らない）¶
| 項 | 記事の操作 | 発火点（いつ・誰が・どこで） | 使う既存の器 | 禁則 |
|---|---|---|---|---|
| 3-1 | 聞く | 指示書を書く前・コーディネーター・docs/harness/templates/ の 2 本 |
指示書テンプレート（既存欄へ並置） | 索引の description だけで判断しない / memory 名をファイル名・コマンド名として書かない |
| 3-2 | 入れる | verdict 読了時（worker-release の前）・コーディネーター・memory |
ファイルメモリ | PR の要約を memory にしない / 2 件以上書きたくなったら昇格の兆候として bd へ |
| 3-3 | 点検する | セッション開始時（機械）+ 月次（人）・コーディネーター | scripts/ + memory |
読まずに古いから消さない / 偽陽性を放置しない |
| 3-4 | 点検する | 実施済み（2026-09-15 07:35〜07:43） | memory + session-log | 現況ポインタに「学び」を書かない |
| 3-5 | （層の宣言・操作ではない） | 常時・全員・.worker-specs/ |
.gitignore + bd wl-r010 |
生の資料を repo に入れない |
| 3-6 | （スキーマの宣言・操作ではない） | 1 回・コーディネーター・docs/harness/ |
文書 | ワーカーの memory 書込を解禁しない |
3-5 と 3-6 は記事の 3 操作に当たらない。層とスキーマをどこに置くかの宣言であり、 操作に無理に当てはめると「入れる」の一種に見えて 3-2 と混ざるので、そう明記して分けておく。
3-1. 「聞く」の発火点 — 指示書を書く前に wiki を引き、引いた名前を指示書に残す¶
コーディネーターは指示書（worker / review）を書く前に、対象の領域語で
memory の本文（rg -il '<語>' ~/.claude/projects/<slug>/memory/）と AGENTS.md の ## 節名を grep し、
検索した語と、該当した memory 名を指示書に書く。該当が無ければ「該当なし」と書く（検索した語は残す）。
索引 MEMORY.md は Claude Code が毎セッション読み込む器なので残すが、該当の判断には使わない
（§8: 記事の「索引を持たず毎回 grep」と、§1-4 で索引が実際に壊れた実例）。
人間ゲート Q1 = A: 毎回課す（領域を限らない）。検索した語まで残すのは、
「引いたが該当なし」と「引き忘れ」を後から区別するためで、§5 にあった計測手段の穴はこれで閉じる。
ワーカーは memory を読めないので、当たった記述はコーディネーターが指示書へ写す。
欄はその写し漏れの点検にも使う。
規約としては .beads/PRIME.md:103（分担表の「セッション横断の長期知見 = memory / ワーカーは使わない」）、
機構としては .opencode/opencode.json:3 の "instructions": ["AGENTS.md", ".beads/PRIME.md"]
（memory が入っていない）と memory が repo 外にあることの 2 つが根拠である。規約と機構の両方が閉じている。
新しい欄を作らない。 docs/harness/templates/worker-spec-template.md の
「対象・変更・所有範囲」節には既に 「参照する仕様・証跡 / 不変条件 / 触らない範囲」 の欄がある。
v7 はここに memory: 検索語 <語, …> / 参照 <名前, …>（該当なしなら memory: 検索語 <語, …> / 該当なし）を
並置するだけで、節も欄も増やさない（wl-6ysd）。
根拠: §1-2 の 4 件はすべて「grep すれば当たっていた」。 禁則: 索引の description だけで判断しない（本文を開く。description は §1-4 のとおり別世代を語ることがある）。 memory の名前をファイル名・コマンド名として書かない（§1-2 の 3 件目がこの取り違え）。
3-2. 「入れる」の発火点 — verdict 読了時に ≤1 件を wiki へ¶
settle ループ（check → verdict を読む → worker-release）に 1 手を足す:
verdict の所見から、プロジェクト横断で再発しうる一般知見を最大 1 件選び、memory に書く
（0 件も可・書かない理由は不要）。
判定基準（4 つとも満たす）: (a) この PR 固有でない（別領域でも起きる） (b) 実測または一次資料で確定している
(c) 既存 memory の更新で済まないか先に確認した (d) 判断・実測・文脈・失敗のどれかを含む
（読めば分かる事実だけの知見は書かない — 「repo にあることは書かない」と同じ線・§8）。
書くときは verdict の逐語 1〜2 行と出所（<ワークツリー>/.worker-specs/<verdict>.md:<行>）を添える。
生の資料の場所を持つのは記事の raw: と同じで、言い換えだけの記録にしない。
基準 (a) は新しい規則ではない。 .beads/PRIME.md:69 の
「issue 固有の学び=bd / プロジェクト横断・セッション横断の知見=ファイルメモリ」の写しであり、
v7 が足しているのは判定の基準ではなく判定する時点（verdict 読了時）だけである。
根拠: §1-3 の 7 件中 6 件がこの基準を満たし、いずれも 1 段落で書ける。 禁則: PR の要約を memory にしない（それは bd close の reason の仕事）。 1 verdict から 2 件以上書きたくなったら、それは指示書テンプレートか AGENTS.md のラチェットへ 昇格すべき兆候として bd へ（memory を厚くする方向へ逃がさない）。 書いたら §3-3 の I1 を必ず通す（§1-3 のとおり、書いても索引から溢れれば読まれない）。
3-3. 「点検する」の定義 — 機械検査 5 つ + 月次の矛盾点検¶
機械検査（スクリプト化・セッション開始時に走らせる） — 人間ゲート Q2 = A: SessionStart hook で自動
（コーディネーターのユーザー設定 ~/.claude/settings.json の hooks.SessionStart → repo の scripts/memory-inspect.mjs・wl-9jt1。.claude/ は .gitignore:50 で無視対象なので、hook の配線は memory と同じユーザー層に置き、repo には検査スクリプトだけを入れる）。
出力は 7 行（見出し + 5 検査 + 末尾の 1 行）で表示のみ・セッションを止めない・常に exit 0。
✗ が出たとき直すかどうかはコーディネーターが決める（月次点検は人が矛盾・古さを見る別の場）。
見本は akapen シートの問 2 に置いた。 書いた瞬間の検査（PostToolUse Write|Edit・--hook-stdin・同じくユーザー設定側）は wl-r7ym で追加（2026-09-15）。
| # | 検査 | 閾値 | 2026-09-15 の実測 |
|---|---|---|---|
| I1 | 索引 MEMORY.md の 1 行の長さ（文字数） |
200 字超の行が 1 本でもあれば件数と最長を出す（ローダーの規約そのもの）。補助として合計 22,800 字超でも警告（上限 ≈ 24,985 字 = 24.4KB × 1024 の手前） | 66 行 / 最長 280 字（要是正）・合計 23,685 字 |
| I2 | 1 ファイルの大きさ | 8KB 超で列挙 | 4 本（+ 索引自身） |
| I3 | ファイル名に日付 | 20\d\d-\d\d を含めば列挙 |
1 本 |
| I4 | frontmatter の type |
user / feedback / project / reference 以外を列挙 | 1 本（feature） |
| I5 | [[link]] 先の不在 |
バッククォートに囲まれた一致を除外したうえで、参照先に空白・: を含むものを「書式が壊れたリンク」、残りを「迷子」として別の見出しで列挙 |
迷子 12 / 書式 1（除外 2）= 15 種・延べ 24 箇所 |
I1 の第一の指標は容量ではなく行長である。 §1-4 のとおり容量超過は行長違反の帰結で、 容量だけを見ると「索引を削ったから直った」と誤認して同じ形で再発する。 閾値の単位は文字数である: ローダーの「24.5KB / 上限 24.4KB」は文字数 ÷ 1024（§1-4 で再現）。 それでも ローダーが出す警告文そのものを一次情報として扱い、I1 の自前閾値は早期警告に留める （ローダーの実装が変わっても検査が嘘をつかないように）。
I5 は偽陽性を構造的に落とす。 §1-4 の 3 種のうち 2 件はバッククォート内の TOML / ファイル名記法で、
直しようがないので除外する。1 件は参照先に空白と : を含むため、ファイル名ではありえないと機械判定できる。
迷子 12 件と混ぜて 15 件と報告すると 2 割が永久に残り、点検が読まれなくなる。
月次の矛盾点検（人＝コーディネーターが読む）: 同トピックで 2 本以上ある memory の description を並べ、
新しい 1 本に統合して古い方を削除する。作法の手本は役割 3 本（§1-4 の訂正）で、
単一の現況を名乗る 1 本 + 遍歴 + 他からの委譲という形が既に出来ている。これを他トピックへ広げる。
統合の作法: 残す 1 本に「遍歴」を 1 段落で書き、削除する側の [[name]] 参照を残す側へ張り替える
（削除だけすると I5 の迷子が増える）。初回は 2026-10（wl-v4tz・迷子 12 件の張り替えを含む）。
根拠: I1〜I5 は 2026-09-14〜15 にすべて手作業で見つけた。機械化しないと次も気づかない。 禁則: 点検を「読まずに古いから消す」に使わない。削除は統合の結果としてだけ起きる。 偽陽性を放置しない（出し続ける検査は無視される検査になる）。
3-4. 追記ログを wiki から出す — resume-state は「生の資料」¶
実施済み（2026-09-15 07:35〜07:43）。 草案は分割を提案していたが、本ターンの実測時点で完了していた:
| 分けた先 | 実測 | 役割 |
|---|---|---|
memory/coordinator-resume-state.md |
07:45 の計測で 2,556 byte、08:10 の再計測で 3,031 byte（並走セッションが更新中・≤3KB の自己申告を既に超えた）。名前に日付なし・frontmatter の description に「≤3KB・学びは書かない。過去のセッション記録は …/session-log/ に日付別」と自己申告 | 現況ポインタ（到達点 / open PR / 稼働 dispatch / 次の一手 / 一時措置の有無だけ） |
~/.claude/projects/…/session-log/coordinator-resume-log-2026-08-03-to-2026-09-15.md |
175,819 byte（memory の外） | セッション記録（生の資料）。本文をそのまま移した |
memory から [[session-log-…]] のように参照しない（生の資料は wiki からリンクしない・読むときは開く）。
実行して初めて分かったことが 2 つある。
- 改名は既存の壊れたリンクを直さない。
[[coordinator-resume-state-2026-07-19]]と[[coordinator-resume-state-2026-07-23]]は分割後も壊れたまま残っている（§1-4 の迷子 12 件に含まれる）。 発信元はsecondary-carryover-explicit-not-derived.md:22とjwnet-webedi-avoids-gateway-and-connection-test.md:30の 2 箇所である。 「日付を名前に入れない」はこれ以上増やさないための規則であって、既にあるものの修復ではない。 修復は別操作（張り替え）で、§3-3 の月次点検が担う。誰がいつやるかは §5。 - 日付は wiki では禁則、生の資料では必須。 移した先のファイル名は
…-2026-08-03-to-2026-09-15.mdで日付範囲を持つ。これは正しい。 禁則は「wiki の名前に日付を入れない」であって「日付入りの名前を禁止する」ではない。 生の資料は時系列で積むものなので、日付が無いほうが壊れる。I3 の検査対象は memory ディレクトリだけで、 session-log へ広げてはならない。
根拠: §1-4。171KB の 1 ファイルは「毎回全文を読む」前提を壊し、日付入りの名前がリンクを 2 件壊した。 禁則: 現況ポインタに「学び」を書かない（学びは §3-2 で個別 memory へ）。
3-5. 生の資料の置き場を宣言する — verdict は compile 対象・repo には入れない¶
.worker-specs/*-verdict.md/*-report.mdは生の資料。.gitignoreのまま。 develop に追跡されている 27 本（実測）は wl-r010 で撤去する （sweep-audit.mdは AGENTS.md が参照するので例外・既存の.gitignore注記どおり）- verdict の「所見」節と「独立変異」表が §3-2 の compile 対象。report の「未検査の象限」は PR 本文へ転記済みなので対象外
- ワークツリーの
.worker-specs/は削除しない（worker-readの transcript と同じ扱い・保存期間は未確定 §5） - 件数を目標にしない。 §1-1 の脚注のとおり report は稼働中に増え続ける（9 分で 3 本）。 「生の資料が何本あるか」は §3-3 の検査対象にしない
3-6. スキーマを repo に置く — memory の書き方を 1 ファイルで¶
memory の schema（1 事実 1 ファイル・frontmatter・索引 1 行 200 字以下・[[link]]・type の 4 値・
名前に日付を入れない・8KB 目安）を memory-schema.md に書く。
コーディネーターの system prompt と同じ内容をrepo で読める形にする。
人間ゲート Q3 = A: 写しを置き、2 条件を課す。正は system prompt、repo の文書は写し
（食い違ったら system prompt を正として写しを直す。冒頭にそう明記する・wl-6ysd）。
ワーカーが memory を書くことは解禁しない（PRIME.md:103 の分担どおり）。
目的は §3-3 の検査の根拠と、次のコーディネーターへの引き継ぎである。
AGENTS.md の分割（wl-hgo7）は本書の外。置き場（新しいディレクトリ名）を本書が決めることはしない — それは新しい器を作ることであり、§3 の前提に反する。本書が先に決めるのは分割の受入条件 2 つだけである:
- 分割後の
AGENTS.md本体が読込上限を下回ること（ツールの警告が消えたことを実測する。 §5 のとおり 09-13 の警告は 09-09 版のファイルを読んだ値で、数え方の違いではなく版の違いだった。それでも警告文を一次情報にする方針は変えない） - 退避先の
CLAUDE.mdが生きていること（§1-5 の 2 本目の警告。本体を縮めても優先度規則でCLAUDE.mdが無視されたままなら、そのセッションの正典はやはり欠ける）
「機械が守る不変条件＝スキーマ」と「機能ごとのラチェット履歴＝compiled knowledge」を別の器に分ける という区別だけは本書の言い分として残す。どのパスへ置くかは wl-hgo7 の設計スライスが決める。 2 条件は 2026-09-15 に wl-hgo7 の受入条件へ追記済み。
4. 変えないもの¶
| 変えないもの | 出典 | v7 がそれと矛盾しない理由 |
|---|---|---|
bd remember は原則使わない。長期知見はファイルメモリが正典 |
.beads/PRIME.md:72（裁定 #1）・:103 |
§3-2 の書き先は memory であって bd ではない。bd へ回すのは「昇格すべき兆候」＝ issue 化のときだけ |
| issue 固有の学び=bd / プロジェクト横断・セッション横断=ファイルメモリ | .beads/PRIME.md:69 |
§3-2 の判定基準 (a) はこの行の写しであり、新規の規則ではない。v7 が足したのは判定する時点だけ |
| 知見 → ファイルメモリ / 状態の二重更新はしない（進行状態の権威は bd） | .beads/PRIME.md:119-120 |
§3-4 の現況ポインタは「到達点 / open PR / 稼働 dispatch」を持つが、進行状態の権威は bd のまま。ポインタは再開時の索引であって更新対象ではない |
| eval-loop は文書系成果物のみ・fork 版既定・2 周上限。コードは機械ゲートが正典 | .beads/PRIME.md:121-123 |
本書は文書なので §6 の 1 番で eval-loop を通す。§3 の各項はコードの合否判定に一切関与しない |
| ワーカーは memory を読まない・書かない | 規約 .beads/PRIME.md:103 / 機構 .opencode/opencode.json:3（instructions に memory が無い）+ memory が repo 外 |
§3-1 は memory の名前を指示書へ転写する。ワーカーに memory への経路を与えない |
| AGENTS.md が唯一の正典。矛盾したら実コード → AGENTS → DESIGN → PRODUCT | AGENTS.md 冒頭・CLAUDE.md | §3-6 は AGENTS.md の置き場を決めるだけで、優先順位を変えない。分割は wl-hgo7 |
| 指示書の「分岐と裁定」と [実測] / [仕様] / [仮説] の印 | v6 §3-1（{ #decision-ledger }） |
§3-1 は同じ節（「対象・変更・所有範囲」）に 1 行並置するだけで、v6 の欄を削らない |
| question を dispatch 内で完結させる | v6 §3-2（{ #questions }） |
変更なし。§3 のどの項も worker_done の前後関係に触れない |
| 変異表を報告書の必須節にする（最低 3 本） | v6 §3-4（{ #mutation-evidence }） |
変更なし。§3-3 の「偽陽性を放置しない」は検査の質の話で、変異表の本数規定ではない |
| 未検査の象限の宣言 | v6 §3-5 | 変更なし。§3-5 のとおり report のこの節は compile 対象外（PR 本文へ転記済み） |
| 実装前の人間ゲート（akapen） | v6 §7（{ #akapen-gate }） |
本書は設計書なので §6 の 1 番で akapen を通す。§3 が akapen の発火条件を変えない |
docs/superpowers/plans / specs の位置づけ（設計意図つき成果物） |
AGENTS.md | §1-1 のとおり specs/** は生の資料側に数えるが、成果物としての位置づけは変えない（削除・移動しない） |
| Notion と bd の分担 | .beads/PRIME.md:119 |
変更なし。memory は第 3 の器として既に分担表にある（:103） |
5. 未確定¶
- 有料本文の実装・運用例と §3 の関係。購読して照合する（§7 Q4 = B）。人間タスク wl-3iez → 照合 wl-yxen。 読めた時点で比較し、違いがあれば根拠付きで改訂する
- ~~ローダーが言う「KB」の単位を再現できていない~~ → 解決（2026-09-15）。MEMORY.md の「KB」は文字数 ÷ 1024（§1-4）。
AGENTS.md の
307753 bytesは byte として正確で、ツールが読んでいたのは 2026-09-09 の版 （git show ddc948c6:AGENTS.md | wc -c= 307,753。exec-rigel の作業ツリーが develop より古かった）。 2 通りの数え方ではなく、2 つの版だった。ただし「警告文を一次情報にする」方針は変えない - ~~§3-3 の機械検査をどこで走らせるか~~ → 解決: SessionStart hook（§7 Q2 = A・wl-9jt1）。memory は repo 外なので CI には乗らない
- §3-2 の「≤1 件」が過少か過多か。開始値 1 で 1 か月の実測で判断する（v6 §3-6 の往復記録と同じ扱い）
- ~~既にある迷子リンク 12 件を誰がいつ張り替えるか~~ → 解決: 月次点検の初回 2026-10（wl-v4tz・コーディネーター）
- 生の資料（verdict / report）の保存期間。現状は無期限。§1-1 のとおり件数は稼働中に動くので、 「N 本を超えたら」の形の規則は置けない
- verdict 325 / report 760 はこのマシンの 12 ワークツリーのローカル値で、別環境では再現しない。 memory の件数・索引の行長も同じく 1 台のコーディネーター環境の値である。 他環境へ移すときは §1 の数値ではなく計測コマンドのほうを持っていく
- §3-3 の検査を「実行した」と言うときは、実行時刻と対象パスを出力に添える。
本書の 1 周目では生成側が「memory への書込 0 件」と自己申告したが、
実際には計測窓の外（07:56:26）に
coordinator-resume-state.mdが変更されていた （並走する main コーディネーターによる正規の更新と見られ、違反とは断定しない）。 時刻を書かない自己申告は、この文書が禁じている自己認定そのものである - ~~「聞く」が実際に起きたかの計測手段~~ → 解決: 欄に検索した語も書く（§3-1）。空欄 = 引き忘れ、検索語あり + 該当なし = 引いた
- ~~§3-6 の schema の二重管理（どちらが正か）~~ → 解決: 正は system prompt・repo は写し（§7 Q3 = A）
- §1-5 の [仮説]（Claude / codex / OpenCode の読込上限）。実測は wl-hgo7 の受入条件（2 条件を追記済み）
6. 導入の順序（提案）¶
親課題は wl-2w3p（epic）。2026-09-15 の人間ゲート通過後に起票した。
| 順 | 内容 | 器 | 課題 | 見積 |
|---|---|---|---|---|
| — | ~~本書を eval-loop → akapen~~ | — | 実施済み 2026-09-15（86 点・4 問回答） | — |
| — | ~~§3-4: resume-state を現況ポインタ + session-log へ分割~~ | — | 実施済み 2026-09-15 07:43 | — |
| 1 | 本書を docs/harness/ へ + §3-1 のテンプレート 2 本へ memory 行を並置 + §3-6 の memory-schema.md + akapen シート 2 枚を証跡として repo へ（v6 §7-4） |
文書のみ・1 PR | wl-6ysd | 小 |
| 2 | §3-3: 検査スクリプト I1〜I5（I1 は文字数の行長・I5 はバッククォート除外を含む）+ SessionStart hook（表示のみ） | scripts/memory-inspect.mjs + .claude/settings.json |
wl-9jt1 | 小 |
| 3 | §3-3 月次点検の初回: 迷子 12 件の張り替え・同トピック複数ファイルの統合 | コーディネーター（memory は repo 外） | wl-v4tz（2026-10） | 半日 |
| 4 | §3-5: wl-r010 の 27 本撤去 | 既存 bd | wl-r010 | 小 |
| 5 | §0: 有料本文の購読（人間）→ §3 との照合（コーディネーター） | repo 外 → 本書の付録 | wl-3iez → wl-yxen | 読んで半日 |
1 と 2 は並行できる（別ワークツリー・ファイル交差なし）。 2 を最初に置いた理由は §1-3（書く操作だけ先に直しても、索引が壊れていれば読まれない）で変わらないが、 1 の文書が無いと 2 の検査の根拠（schema）が repo に無いので、同時に出す。
7. 人間ゲート（akapen）の結果 — 2026-09-15¶
v6 §7 の手順どおり、標準モードのシート akapen/harness-v7-memory-01.html を作り、文脈ゼロの subagent で試問を 2 巡回してから
禹さんに出した。回答は akapen/harness-v7-memory-01.html.answer.txt（固定形・全体への赤ペンなし・赤ピンなし）。
| 問 | 論点 | 推奨 | 回答 | 反映先 |
|---|---|---|---|---|
| Q1 | 「聞く」— 指示書を書く前の memory・AGENTS.md の grep を毎回の義務にするか | A 毎回課す | A | §3-1（検索した語も欄に）・wl-6ysd（テンプレ） |
| Q2 | 「点検する」— 機械検査 5 つを SessionStart hook で自動か手動か | A hook で自動 | A | §3-3・wl-9jt1（表示のみ・止めない） |
| Q3 | 「スキーマ」— memory の書き方を repo に写し、AGENTS.md 分割に 2 条件を先に課すか | A 写す + 2 条件 | A | §3-6・wl-6ysd（memory-schema.md）・wl-hgo7（受入条件追記済み） |
| Q4 | 記事の有料本文（¥24,800〜）を購読して 6 点と照合するか | A 今は購読しない | B 購読して照合する | §0・§5・wl-3iez（人間）→ wl-yxen（照合） |
問いにしなかった 3 点（3-2 の上限 1 件は開始値として 1 か月の実測へ / 3-4 は実施済み / 迷子リンク 12 件は 2026-10 の月次初回）に 赤ピンは付かなかったので、そのまま確定した。
試問（preflight）で直ったもの: 1 巡目は問い 1（Q2 に出力の絵が無い）・問い 2（Q1・Q4 に file:line が無い）で落ち、
音読で 14 文・内輪語が約 40 語挙がった。Q2 に検査出力の見本 7 行と回答フォームの .thumb を足し、Q1 の 4 件に file:line、
Q4 に記事のタイトル・URL・v6 設計書の行番号を付け、用語欄を 12 語に広げた。2 巡目は問い 1〜3 全問通過・残りは表記 5 点で、
それも直してから出した。試問の過程で本書の数値の誤り（§1-4 の単位）を見つけたのは、文脈ゼロの読者に
「数字の出所」を問われて再計測したからで、v6 §7 が期待した効果がそのまま出た形である。
未回答だった場合の既定（推奨案で確定）は使わなかった。4 問とも回答があり、Q4 だけ推奨と違う案が選ばれた。
8. 有料本文との照合 — 2026-09-15（wl-yxen）¶
人間ゲート Q4 = B（購読して照合する）に従い、禹さんが購読した記事の有料本文（25,171 字・図 22 枚）を
コーディネーターが読んだ（wl-3iez・09:45・Orca の内蔵ブラウザからログイン済みのタブを読取）。
本文は repo・memory・指示書に写さない（著作物。原文は repo 外 ~/Documents/kyoei/ に保管）。
以下は自分の言葉での照合で、記事の逐語は 7 つの軸の名前と Karpathy の英語 1 文を除いて引かない。
8-1. 記事の有料部の主張（要約）¶
- 記憶が使われなかった原因は、保存先の機能不足ではなく記憶に何でもさせたこと。 いつ context に入るかで記憶を分け、行き先を agent に知らせるという 2 つが欠けていた。
- 記憶は 3 つに分かれる: 常に読ませる（CLAUDE.md 等）/ 操作記憶（hook が操作の直前に差し込む）/ 取りに行く（agent が必要と判断して引く = wiki）。wiki は 3 つ目で、常駐させるのは行き先の 1 行だけ。
- Karpathy の LLM wiki との違いは 7 つ。前提の 4（誰が書く・誰が読む・形式・数）と、 読み手が agent になることで逆転した 3: 更新は追記（訂正は新しい記録・判断の履歴が根拠になる）/ 索引を持たず毎回 grep（索引は壊れる中間データ）/ 入れないものの線引きを先に決める。
- 溜めるのは 判断・実測・文脈・失敗。読めば分かる事実だけの記録は、入れる前に呼ぶ側が外す。
言い換えだけの要約は入れず、原文の逐語と頼んだ人の言葉を残す。原文そのものは wiki の外（オブジェクトストレージ）に置き、
記録は場所（
raw:）だけ持つ。 - 部品: wiki repo の CLAUDE.md 1 枚 + skill 4 本（書き方の辞書 / 入れる / 聞く / 点検）+ hook 3 本 （起動時に件数一覧 / 書いた瞬間に書式検査 / 終了時に commit）+ コマンド 1 本。repo 専属の agent（司書）が読み書きし、 人は書かない（人も司書に頼む）。呼び手は別フォルダから 1 行で聞き、答えの文だけを受け取る。
- 1 分野 1 repo に分ける。代償として、聞く先・入れる先の間違いと複数 repo への同報が実際に起きており未解決。
- MCP は採らない（ツールの説明文が常駐して context を使う）。
8-2. 4 分類の照合¶
| 論点 | 記事 | Greco v7 | 分類 | 判断 |
|---|---|---|---|---|
| 3 層 | 生の資料 / wiki / スキーマ | verdict・報告書（repo 外）/ memory + AGENTS.md / system prompt + memory-schema.md |
一致 | — |
| 記憶の分け方 | いつ context に入るかで 3 つ | 常に読ませる = system prompt・索引 MEMORY.md・AGENTS.md ／ 操作記憶 = hook（PRIME 注入・guard）と指示書の memory 行（§3-1）／ 取りに行く = memory 本文 |
一致（v7 は無自覚だった） | §1-1 に列を足す（本 PR） |
| 聞く発火点 | agent の判断 + CLAUDE.md の行き先 1 行。聞き逃しは許容 | 指示書を書く前に必ず（Q1 = A） | Greco が強い | 変えない |
| 聞く対象 | 索引を持たず本文を毎回 grep | 索引 + AGENTS.md 節名の grep | 不一致 | 採る: §3-1 の grep を memory 本文（rg -il）へ。索引は Claude Code が常時読む器なので残すが該当の判断に使わない（本 PR） |
| 更新 | 追記。判断の履歴が根拠 | 上書き（単一の現況 + 遍歴の段落） | 不一致 | 採る（形を変えて）: memory ディレクトリを git 管理にして履歴を持ち、ファイルは単一の現況のまま（wl-mqze・2026-09-15 に承認・実施） |
| 線引き | 判断・実測・文脈・失敗を通す。読めば分かる事実は入れない | §3-2 の (a)(b)(c) + 「repo にあることは書かない」 | 一致 | (d) として「失敗」を明記（本 PR） |
| 逐語と出所 | 記録に原文の逐語と raw: の場所 |
verdict の所見を自分の言葉で | 不一致 | 採る: §3-2 の memory に verdict の逐語 1〜2 行と 出所: パス:行 を添える（本 PR） |
| 点検 | 起動時（件数・直近・過去の 1 枚を無作為に）/ 書いた瞬間の書式検査 / 終了時 commit / 点検 skill | 起動時（I1〜I5・7 行）/ 月次（人） | 一部一致 | 検討: 書いた瞬間の検査は wl-r7ym（P3）。無作為の 1 枚は採らない（今は） |
| 索引 | 持たない（壊れる中間データ） | MEMORY.md（§1-4 で実際に壊れた） |
記事が正しかった | 「聞く対象」で吸収 |
| 司書・別フォルダからの呼出し・1 分野 1 repo | 専属 agent・1 行で聞く・分野で分ける | コーディネーターが自分で読む。ワーカーには指示書へ写す | 記事にだけある | 採らない（コーディネーター 1 体・memory 114 本の規模では grep で足りる）。AGENTS.md の分割（wl-hgo7）には「常に読ませる / 取りに行く」の軸と、冒頭の行き先一覧を引き継ぐ（wl-hgo7 の notes に記録済み） |
| 人が書かない | 人も司書に頼む | 人は memory を編集しない（入力は bd / Notion / akapen） | 一致 | — |
| MCP を採らない | 説明文が常駐する | memory を MCP にしていない | 一致 | — |
| 日付 | 記録は日付付き（年/月のフォルダ）・名詞は日付なし | memory は日付なし・session-log は日付あり（§3-4） | 一致 | — |
| Greco にだけあるもの | — | 敵対レビュー → verdict → memory の経路（§3-2）、変異表、eval-loop、akapen、bd、prod-critical の人間ゲート | Greco にだけある | — |
8-3. 採る改訂（3 点 + 承認を得て実施した 1 点）¶
- §3-1 聞く対象: 索引ではなく memory 本文を grep する。索引は残すが判断に使わない。理由: 記事の #6 と §1-4 の実例（索引は書式で壊れ、壊れても気づかなかった）。
- §3-2 線引きと出所: 基準 (d)「判断・実測・文脈・失敗のどれかを含む」を足し、memory には verdict の逐語 1〜2 行と出所（パス:行）を添える。理由: 記事の言い分（言い換えだけの記録は原文の代わりにならない）。Greco の memory はすでに
file:lineの作法を持つので、verdict にも同じ作法を当てるだけ。 - §1-1 の列「いつ context に入るか」: v7 の 3 層が記事の 3 つの記憶にどう当たるかを表に書く。理由: 記事の主張の核で、v7 は同じ分け方を無自覚に持っていた。名前を与えると §3-1（操作記憶）と §3-3（常に読ませる索引の検査）の役割が説明できる。
- （wl-mqze・2026-09-15 に承認・実施）memory ディレクトリを git 管理にする: 記事の「追記」の狙い（判断の履歴を残す）を、ファイルを追記型に変えずに満たす。Greco の memory は上書きで単一の現況を保つ方針（§3-3 の統合）なので、履歴は git に持つのが最小の変更。repo 外・ローカルのみ・remote なし。commit はセッション終了時の hook が拾う（記事の終了時 hook と同じ）。新しい器を 1 つ足すので人間ゲートの外にあり、禹さんの一言で決める。
8-4. 採らないもの¶
- 司書と別フォルダからの呼出し: コーディネーター 1 体・memory 114 本の規模では、自分で
rgして開くほうが速く、往復の失敗（聞く先の間違い・同報）を持ち込まない。ワーカーへは指示書に写す（§3-1）。 - 1 分野 1 repo: 同上。ただし AGENTS.md の分割（wl-hgo7）には「常に読ませる / 取りに行く」の軸を引き継ぐ。
- 追記型のファイル: 単一の現況を 1 本で名乗る形（§3-3 の統合）を優先し、履歴は git に。
- 無作為の過去 1 枚を起動時に見せる: memory 114 本の陳腐化（67 本が 7 月以前）には効くかもしれないが、7 行の出力に足すと読まれなくなる。月次点検（wl-v4tz）で古いものを見る。
- ~~記事の hook 3 本のうち終了時 commit~~ → git 化（wl-mqze）と同時に 実施済み（コーディネーターのユーザー設定の Stop hook
memory-commit.shが memory の変更を commit する）。
8-5. 読んで分かった、v7 の書き方の誤り¶
- §0 で「記事の提案そのもの、または効果が検証済みの手法とは認定しない」と書いたが、記事の有料部は実走の記録（入れる・聞く・agent が自分で取りに行く）を持っており、少なくとも著者の環境では効果が観測されている。認定しないのは「Greco で効くか」であって「記事が検証していない」ではない。§0 の表現はそのまま残し、ここで訂正する。