STEP 1334 test 39/39 PASS 2 findings pending 1 defect pattern 確定

Research Log 2026-08-14 — STEP 1334 KnowledgeApi 配線 + 深部切断の発見

commit 4bbb1ae84 — 8 route の配線修復と、開通した計器が最初に映した「一度も書き込まれていない」 3 findings、欠陥クラスの 2 例確定と知識ストア dual state の設計判断待ち。

なぜこのページか

2026-08-06 藤本さん永久 protocol 「全研究 site 反映 default」適用。本 arc は backend engine の修復 STEP なので、 site page として反映して「memory 忘れ対策」 + 「gap 検知 entry point」の 2 目的を果たす。数学的新成果ではないが、 Rei-AIOS の稼働状態診断 record として意味を持つ。

本 page は STEP 1334 の実装成果 (commit 4bbb1ae84) + 開通後の発見 (次 STEP 候補 3 件) を集約。数値・commit hash は全 immutable。

Arc summary (本日単一 STEP)

STEP	Content	Commit	Test
1334	KnowledgeApi 8 route 配線漏れ修復 (STEP 151 retrofit)	4bbb1ae84	39/39 PASS

1. STEP 1334 修復内容

Root cause

KnowledgeApiHandler (STEP 151、 8 route 実装済) が src/aios/server/rei-server.ts の Router 連鎖に 一度も接続されていなかった。 repo 全体 grep で KnowledgeApiHandler の登場箇所は (a) 定義本体 + (b) test/step151-*-test.ts の 2 箇所のみ。 STEP 151 の単体 test は handler を直接 new して検証するため 緑のまま通り、 HTTP 層では 8 route 全てが 404。症状は Grok 発言を契機とした MCP 経由稼働点検で get_knowledge_stats + get_learning_log が NOT_FOUND を返して発覚。

Fix (2 file)

rei-server.ts: KnowledgeApiHandler + Cache type import、 ReiServerConfig に arxivCache?/knowledgeCache? optional 追加 (両方揃った時のみ配線 = 既存 caller 無変更)、 dispatchKnowledge() adapter で routes() を Map 展開、未一致は null で既存 fall-through 連鎖継続。挿入位置は exploreResult 直後 + 最終 router 直前 (既存優先順位不変)。
rei-bootstrap.ts: 既存 this.arxivCache + this.knowledgeCache を new ReiServer({...}) に受け渡し (新規生成なし)。

Test (39/39 PASS)

test/step1334-knowledge-api-wiring-test.ts (147 行、新規)。 ★ handler を直接 new しない方針 = 本欠陥は HTTP 層でしか捕まらないため、 4 part 構成:

Part 1 後方互換 (cache 省略時 404 + code=NOT_FOUND 維持)
Part 2 配線後 8 route 全 200 + body 存在 + NOT_FOUND 非返却 (24 assertion)
Part 3 response 構造 (summary.totalKnowledgePieces 数値 + meta.totalKnowledge 数値)
Part 4 既存 route 回帰なし (/api/health + /api/discovery/stats 200 維持 + 未定義 /api/knowledge/* は 404 のまま)

開通 endpoint 8 本

/api/knowledge/: stats + arxiv + sep + wikipedia + wikidata + oeis + log + all

2. 開通した計器が最初に映したもの (3 findings — 次 STEP 候補)

計器 (/api/knowledge/log 等 8 route) 開通直後、全 source ゼロ (arXiv 0 / Wikipedia 0 / OEIS 0 / Wikidata 0 / fetchLog 0) = 「取得したが少ない」ではなく 「このDBには一度も取得記録がない」 状態と判明。

Finding 1: 知識取得層は一度も書き込んでいない

rei-aios.db (75MB) 直接読取:

テーブル	件数
discoveries	46,791
occult_isomorphisms	8,754
structural_isomorphisms	1,123
daily_run_log	137
arxiv_papers	0
knowledge_cache	0
knowledge_fetch_log	0
wikipedia_articles	0
wikidata_persons	0
oeis_sequences	0
sep_topic_log	0

発見系は 46,791 件、知識取得系だけ例外なくゼロ。 grep で判明: save() / saveWikipedia() / saveOeis() / saveWikidataPerson() / saveKnowledgeArticle() の呼び出し元は test/step151-*-test.ts の 7 箇所のみ、プロダクション code からゼロ。 ArxivFetcher は ArxivCache を import すらしていない。

これは STEP 1334 と同じ欠陥クラスのもう一段深いところ: STEP 151 は writer + reader + test の 3 点セットで実装、両端 test は直接 new で緑、本番では両端とも接続されていなかった。 reader 側は STEP 1334 で修復、 writer 側は今も呼び出し元なし。

Finding 2: `rei-aios.db` は .gitignore で除外されているのに workflow は commit しようとしている

.github/workflows/rei-learning-cycle.yml:126:

git add rei-aios.db           || true

.gitignore:5 に *.db → gitignore 済み file は -f なしで add 不可 → エラーは || true に飲まれる。 git ls-files rei-aios.db は空、実際に未追跡。 workflow ヘッダーコメント「学習結果 (rei-aios.db / snapshots / learning-log) を自動 commit」 = 設計意図と実際の挙動がずれている。 CI 側 DB は毎回まっさら → 取得して捨てられローカルにも届かない。

Finding 3: 発見エンジンは同じ 340 件を 137 回書き込んでいる

discoveries 総数       : 46,791
distinct (a,b,演算子)  : 340
distinct title         : 340
daily_run_log          : 137回 (2026-03-27 〜 08-12)
実行結果のパターン数   : 2

137 日 × 340 unique = 46,791。起動ログ「15 理論を登録」 = エンジンは rei-bootstrap.ts にハードコードされた 15 理論を組み合わせ、 SEED_KERNEL 1,675 は使っていない。 15 理論 → 420 通り → 332 件 → 毎日同じ。 意図的な実行ログ記録の可能性もある (再導出 log と見なす設計) = 断定せず、藤本さん判断待ち。

bonus: arxiv radar 4 日停止

data/research-radar/arxiv-*.json 最新 = 2026-08-09。他 source (the-conversation / philsci-archive / kalai / n-cat-cafe / hal / doaj / gdelt) は 08-13 まで。 radar 側で個別に arxiv fetcher が失敗している可能性。別 STEP 切り出し候補。

3. 欠陥クラス (STEP 151 + STEP 1334 = 2 例確定)

端点だけを直接 new した test は中間の配線切断を検出できない — feedback memory 化。

2026-08-14 に 2 例確認:

例 1: STEP 1334 (reader 側、 2026-08-14 fix) = KnowledgeApiHandler unit test で new で全 green、 rei-server.ts の Router 連鎖には一度も接続されていなかった → HTTP 層 8 route 全 404
例 2: STEP 151 writer 側 (2026-08-14 発見、未修復) = ArxivCache.save() 等が unit test で直接呼び出しで green、 production 呼び出し元ゼロ → SQLite 知識テーブル 7 種 137 日間一度も書かれていない

How to apply: (1) 新規 handler / cache / persistent writer は unit test 単独では merge しない、 production 経路から辿る integration test 必須。 (2) 「STEP N で writer/reader 作りました、 test 全 PASS」主張は wiring gap risk 含む。 (3) 8 Router 全体で同型 audit 別 STEP 化推奨。 (4) 「test 緑 = 動作」の思い込み禁止 = 「0 sorry = floor」の姉妹原則。 (5) 「実装済 / 配線済 / 稼働中 / 観測済」の 4 段語彙で区別。

4. 知識ストア dual state (A / B / C 選択肢 — 藤本さん判断待ち)

Rei-AIOS には 知識ストアが 2 つ 存在し、片方だけが生きている:

ストア	状態
SQLite (STEP 151、 7 テーブル)	全 0 件、一度も書かれていない (Finding 1)
JSON (research-radar)	稼働中 (但し arxiv は 2026-08-09 以降 4 日停止)

案	内容	コスト	利点
A	SQLite を生かす (radar fetcher に save 追加、両ストア一本化)	中	SQL query 力、 STEP 151 investment 生きる
B	SQLite 廃用 (MCP tools を JSON 読みに変更、テーブル退役)	中	単一 pipeline、 STEP 1334 reader 不要
C (推奨)	JSON=SoT + SQLite=materialized view (rebuild script 経由)	小-中	radar が SoT 育っている現状追認、 STEP 1334 reader 生きる、 drift risk なし

私 (Claude Code) の推奨は C。藤本さん判断が要る点: (1) A/B/C どれを採るか (2) C 採用時、 rebuild script をいつ・誰が走らせるか (3) arxiv radar 4 日停止を同 STEP で扱うか。

Honest scope

本 STEP は 新機能ではなく配線の修復のみ、 KnowledgeApiHandler の実装内容は STEP 151 のまま immutable。
同型の配線漏れが他 Router に存在するかの全数 audit は未実施 (別 STEP candidate、 8 Router)。
Finding 1 (writer 未呼出) は検出のみ、修復は A/B/C 判断待ち。
Finding 2 (workflow 矛盾) は検出のみ、修復は A/B/C 判断後。
Finding 3 (340 件 137 回重複) は断定せず、設計意図の可能性を明示 (藤本さん判断待ち)。
arxiv radar 4 日停止は別 STEP 切り出し候補、本 STEP scope 外。
sandbox (Linux) は node_modules が Windows build (esbuild + better-sqlite3 native) で実行不可、 tsc --noEmit 型 check のみ sandbox 実施、実 test 実行は藤本さん Windows 環境。

なぜ このページか

Arc summary (本日 単一 STEP)