---
name: project-step1334-knowledge-api-wiring-and-deeper-disconnect-2026-08-14
description: STEP 1334 KnowledgeApi 配線漏れ修正 (STEP 151 retrofit) commit 4bbb1ae84 + 開通した計器が最初に映した 3 findings (writer 未呼出 / gitignore workflow 矛盾 / 340 重複) — deeper defect class 発見
metadata: 
  node_type: memory
  type: project
  originSessionId: d2082c05-0e81-4fc9-9613-331ad2f49b5b
  modified: 2026-08-14T14:42:10.495Z
---

# STEP 1334 KnowledgeApi 配線 + deeper disconnect (2026-08-14)

## 経緯

Grok 発言 (「Claude Code が使えたら 自律型 AI 科学者を作りたい」) を契機に Rei-AIOS 稼働状態を MCP 経由で点検 → `get_knowledge_stats` + `get_learning_log` が fetch failed → server 起動後も `NOT_FOUND`。

## STEP 1334 fix (commit 4bbb1ae84)

**Root cause**: `KnowledgeApiHandler` (STEP 151、 8 route 実装済) が `rei-server.ts` の Router 連鎖に **一度も接続されていなかった**。 repo 全体 grep で `KnowledgeApiHandler` の登場箇所は (a) 定義本体 + (b) `test/step151-*-test.ts` の 2 箇所のみ。 STEP 151 の 単体 test は handler を直接 `new` して検証するため **緑のまま通り**、 HTTP 層では 8 route 全てが 404。

**Fix**: rei-server.ts に config.arxivCache/knowledgeCache 経由の optional 配線 + dispatchKnowledge adapter 追加、 rei-bootstrap.ts で既存 cache を渡す。 test/step1334 39/39 PASS。 6 files / 201 insertions / 1 deletion (54 non-test + 147 test file 新規)。 push origin/main 完了。

## 開通した計器が最初に映した 3 findings (次 session 引継)

計器 (`/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 側は 今も呼び出し元なし。 詳細 → [[feedback-success-signal-decoupled-from-operational-state-2026-08-14]]

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

`.github/workflows/rei-learning-cycle.yml:126`:
```yaml
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 切り出し候補。

## Path A verify 手順 (前 session 起草分、 藤本さん確認済)

commit 前 verify: `git diff --cached --stat` で `5 files changed, 54 insertions(+), 1 deletion(-)` 期待 (新規 test file 147 行は untracked のため cached stat 対象外、 実際は 6 file / 201 / 1 で 一致)。 CRLF 混入時は数百行に見える → その場合 commit せず停止。 Windows `core.autocrlf=true` 環境では正常正規化されるため 本 session 環境 (Windows) では 問題発生せず。 push 後 verify: RECENT_UPDATES.md の STEP 1334 entry + CLAUDE.md + Actions 結果 は 藤本さん側で確認予定。

## A/B/C 判断待ち (別 memory)

SQLite 知識層 vs JSON research-radar dual state の 設計判断 → [[project-knowledge-store-dual-sqlite-json-2026-08-14]] 参照。 私の推奨は C (JSON=SoT + SQLite=derived view) だが 藤本さん決定待ち。

## 関連

- [[feedback-success-signal-decoupled-from-operational-state-2026-08-14]] — 欠陥 pattern (端点 test は中間切断を検出できない)
- [[project-knowledge-store-dual-sqlite-json-2026-08-14]] — A/B/C 設計選択肢
- STEP 151 (2026 初期、 KnowledgeApiHandler + 8 route 実装 origin、 writer は今も未呼出) + STEP 125 (ReiServer 本体)
- [[feedback-one-reproduction-over-ten-unverified]] (「計器を直す → 計器で読む」 順序原則、 本 STEP で operational 適用)
- [[feedback-zero-sorry-floor-not-ceiling]] (test 緑 = 動作 ではない、 floor discipline)
- [[feedback-all-research-site-reflection-default]] (2026-08-06 protocol、 site 反映 対応)

## commit hash

- 4bbb1ae84 = STEP 1334 KnowledgeApi 配線 (main branch push 済)
- 2d9d85db8 = site page + docs (memory + site 反映、 rebase 後の hash)

## 藤本さん follow-up 応答 追記 (2026-08-14 同日、 arc close 直前)

commit + push + memory + site 反映完了後の 藤本さん確認応答で **追加事項 4 件**:

1. **C 採用理由の追加 insight**: 「修正ではなく消滅」 = Finding 2 (gitignore + `|| true` workflow 矛盾) は C 実装で **修正対象が消える** (SQLite が JSON から derived な view なら gitignore が正しい、 workflow 126 行目は削除対象、 「75MB を git に載せるか」 の 問い自体が消える)。 詳細 → [[project-knowledge-store-dual-sqlite-json-2026-08-14]] 追記 section。

2. **OEIS / Wikidata / SEP の scope 問題**: 私 (Claude Code) が見落としていた。 JSON 側で日次生きているのは arXiv + Wikipedia 系のみ、 `data/oeis/` + `data/wikipedia-unsolved-problems/` 等は 単発 md file。 案 C 実装後も この 3 テーブルは 0 のまま。 選択肢: (a) 「投影元なし、 空 by design」 明示保持 or (b) schema ごと DROP。 「中途半端が最悪」 を ここにも適用するなら (b) 寄り = C 実装 STEP 内の judgment sub-question。

3. **Finding 3 の 外部露出 check が先**: 46,791 が公開数値 (site stats / Activity Log / cron auto commit message) に流れているかを grep で 確認 → 漏れていれば priority 上げ (公開数値 137 倍膨張)、 漏れていなければ 内部 DB 太り 優先度下げ。 判断は 実測後、 順序は grep が先。

4. **arxiv radar 4 日停止 は 欠陥 class 3 例目**: `rei-learning-cycle.yml` に `|| echo` / `|| true` が **38 箇所**、 `radar:scan` + `daily-radar.ts` 両方が `|| echo '... skipped (non-fatal)'` で終わる = arxiv fetch が 4 日前に死んでも CI 緑のまま。 STEP 1334 (test 緑+本番 404) + STEP 151 writer (test 緑+呼出元ゼロ) + これ (CI 緑+取得死) = **同型 3 例確定**。 詳細 → [[feedback-success-signal-decoupled-from-operational-state-2026-08-14]] 「3 例目発見」 section + arc close 状態 file [[project-session-2026-08-14-step1334-arc-close-state]]。

## 藤本さん recommendation 反映 順序 (次 session 引継)

私の当初順序 (C 実装 → 他) は **順序原則違反** (計器が壊れたことを知る手段が無いまま計器を直す) と 藤本さん指摘。 修正後:

| 段 | 内容 | 実行判断 |
|---|---|---|
| 0a | feedback memory rename + 3 例統合 (上位 pattern 昇格) | 次 session、 「記録が新鮮なうち」 に |
| 0b | Finding 3 外部露出 grep check | 次 session、 grep 1 回 |
| 1 | 「非致命的 skip」 38 箇所 audit STEP (categorize + heartbeat 設計) | 別 session |
| 2 | 案 C 実装 STEP (rebuild script + OEIS/Wikidata/SEP schema 判断) | 別 session |
| 3 | 8 Router API smoke test 新設 STEP (既存 smoke-test-routes.ts は CF Pages 静的 route only、 別 file 新設) | 別 session |
| 4 | arxiv radar 復活 (2 完了後 = 計器がある状態で調査) | 別 session |

**「急がずゆっくりと」 適用**: 今日は 2 commit (4bbb1ae84 + 2d9d85db8) + memory 3 file + site page 1 で 十分な進捗、 0a-4 は 別 session で順次 藤本さん judgment 後 実行。