---
name: project-rei-meta-mcp-phase1-arc-2026-08-19
description: rei-meta-mcp Phase 1 arc — コネクタ群の上に立つメタ層。同じ対象を指す複数 source の整合性を機械検査。今日の SEED_KERNEL 1677 vs 1675 事故を機械が即検出、 §4 「到達不能 ≠ 一致」 protocol operational
metadata: 
  node_type: memory
  type: project
  originSessionId: 5974a894-937f-4679-9ae2-0e15fd5244db
  modified: 2026-08-19T15:02:17.644Z
---

# rei-meta-mcp Phase 1 arc (2026-08-19)

## 動機 (この tool が存在する理由)

2026-08-19 [[project-rei-memory-mcp-phase1-arc-2026-08-19]] の実装過程で、 rei-aios remote deploy の SEED_KERNEL が **1,675 (2026-08-06 deploy)** vs ローカル HEAD **1,677** で 11 日間ずれたまま誰も気づかなかったことが判明。 気づけたのは藤本さんが両方の数字を偶然見比べたから。 Claude session もこの gap を認知しない = **機械の検出手段が無かった**。

このコネクタの第一の仕事は **これを機械が先に見つけること**。 chat-Claude 別 session で 「圏論的コネクタをトップに」 提案 → 私 (Claude Code) は 「圏論の計算ではなく、 コネクタ群の上に立つ圏」 として reframe → 実装 spec (別 Claude session 起草、 [Downloads/rei-meta-mcp_実装指示書_Phase1.md](file:///C:/Users/user/Downloads/rei-meta-mcp_%E5%AE%9F%E8%A3%85%E6%8C%87%E7%A4%BA%E6%9B%B8_Phase1.md)) → §11 調査 → Phase 1 実装 → live smoke で事故検出 → commit。

## §11 調査結果 (実装前潰し)

3 項目のうち 2 項目で spec 前提が事実誤認と判明:

| # | 質問 | spec 前提 | 実測 |
|---|---|---|---|
| 1 | remote rei-aios probe 可 | 不明 | **不可** (claude.ai remote-devices 経由 = Python 直接 probe 不可)、 但し `dist/mcp/start-mcp.js` を node subprocess で起動して MCP stdio protocol で probe = **代替経路成立** |
| 2 | benchtop データ path | 不明 | `~/.benchtop-mcp/*.json` (SQLite ではなく JSON per session、 spec の `kind: sqlite` は誤り、 Phase 1.5 で `json_dir` adapter 追加候補) |
| 3 | rei-aios ローカル build | 「存在しないという報告」 (spec 内 note) | **存在する** (`C:/Users/user/rei-aios/dist/mcp/start-mcp.js` 205B + `rei-mcp-server.js` 43KB, Aug 1 build) = spec 内 note は事実誤認、 第 3 の source として register 可能 |

**Why**: §11 を先にやらせてください と spec author (別 Claude session) が明示提案 = [[feedback-one-reproduction-over-ten-unverified]] 順序原則の適用実例。 事前 30 分の調査で 「Aug 1 build subprocess で今日の事故を実際に再現できる」 と判明 = 実装優先度が確定した。

**How to apply**: 実装指示書に 「調査を要する項目」 section があれば、 実装前に必ず先に潰す。 spec の前提が事実と異なる場合 (今回 2/3 で発生) を機械 audit する前段。

## 実装成果 (§10 完了条件 7/7 達成)

### 提供 tool 3 本

| tool | 役割 | verdict |
|---|---|---|
| `meta_list_sources(object_name?)` | 全 source 列挙 + reachability + git HEAD hash + 日時 (freshness) | — |
| `meta_check_coherence(object_name, detail?)` | 同一対象を指す source 群の指紋突合 | `coherent` \| `divergent` \| `unreachable` \| `single_source` |
| `meta_compose(from, to)` | Phase 1 = registry 内 `output_schema` / `input_schema` 文字列突合のみ | `composable: bool` |

### 3 adapter kind

- `sqlite`: full fingerprint (count + id_set_hash + content_hash + latest_timestamp)、 直 SQL 読み
- `mcp_stdio`: partial fingerprint (count + latest_id + categories_hash)、 subprocess `node dist/mcp/start-mcp.js` + MCP client SDK で `get_kernel_status` 呼出
- `unreachable_placeholder`: registry native 「常に unreachable」 = 「気づけない状態」 を毎回 loud に surface する枠 (rei-aios-remote 用)

### §4 protocol operational

「到達できなかった ≠ 一致していた」 4 verdict 分離が code 全域で厳守:

- `unreachable` = 到達可能 source ゼロ (`divergence: null`)
- `single_source` = 到達 1 つのみ、 warning に `"only 1 reachable source"` 明示
- `divergent` = 複数到達 + 不一致
- `coherent` = 複数到達 + 全一致
- 加えて `unreachable_placeholder` kind の source が居ると常に `UNCHECKED: {name} — 'not checked' is NOT 'coherent' (§4)` warning

### fingerprint 2 種の混合比較

full ⇔ partial mixed で `record_count` 差だけでも divergent 検出 = SQLite 1677 vs mcp_stdio 1675 の live smoke で成立。 partial 同士は `record_count` + `latest_id` + `categories_hash` で比較 (available field 同士のみ、 不在 field は silent → 「一致」 と主張しない discipline)。

### test 31/31 PASS (in 2.08s)

- test_registry (7 test): YAML parse + cross-ref validation + dup detection
- test_fingerprint (7 test): order-independent + change detection (count/id/body) + mixed full-partial
- test_coherence (11 test): 4 verdict 全 coverage + unreachable_placeholder + no_sources + detail=True only_in
- test_compose (4 test): 宣言 schema 文字列突合
- test_incident_2026_08_19 (2 test): **1677 vs 1675 再現 + 逆向き = tool が direction を持たないこと保証**

## Live smoke (今日の事故を機械が捉えた実測)

```
VERDICT: divergent
sources:
  rei-memory-local (sqlite full):    reachable=✅ count=1677 latest_id=dfumt-zero-pi
  rei-aios-local-mcp (mcp_stdio):    reachable=✅ count=1675 latest_id=resilient-knowledge-recovery
  rei-aios-remote (placeholder):     reachable=❌ error="deployed via claude.ai remote-devices"
divergence:
  count_diff: {rei-memory-local: 1677, rei-aios-local-mcp: 1675}
  disagreements: ["rei-memory-local vs rei-aios-local-mcp: record_count differs"]
warnings:
  - UNCHECKED: rei-aios-remote — 'not checked' is NOT 'coherent' (§4)
```

**実行時間 < 2 秒**。 藤本さんが 目視 で気づいた事故を、 機械が 2 秒未満で検出可能な形に固定した。

## 設計 discipline (spec author 3 点 + 実装 2 点)

### spec author 明示 3 点 (全 operational)

1. **§4 「到達不能と一致の区別」**: 4 verdict state 分離 code 全域 + `unreachable_placeholder` kind で毎回 loud surface
2. **自動修復を意図的に外す**: `meta_check_repair()` 相当 tool 存在せず、 divergent 検出後の判断は完全に人間側
3. **圏論の語彙を 5 つだけに絞る**: 対象 (objects) / 射 (sources) / 等化子 (coherence) / 合成 (compose) / 恒等射 (single_source verdict) のみ。 関手 / 随伴 / モナド / 極限 一切書かず

### 実装追加 2 点

4. **fingerprint 2 種 (full/partial) の混合比較**: MCP stdio adapter は full 取得不可 (get_kernel_status は totalTheories + latestTheoryId + categories のみ) だが、 count 差だけで divergent 判定成立、 partial 同士は available field で比較、 silent 一致 と 主張しない discipline
5. **registry native `unreachable_placeholder`**: probe 未実装の source を kind として register 可能 = 「見えていないもの」 を毎回明示的に表す枠 (Rei stack 内の他 tool 全般に応用可能な設計 pattern)

## Rei stack impact

### MCP systems 7 → 8

前: rei-aios + benchtop v0.4 + mcp-lens + rei-automator-mcp v0.2.0a3 + lab-notebook-mcp v0.1.0 + rei-verify 0.1.0a1 + rei-memory-mcp 0.1 = **7**
後: 上 + **rei-meta-mcp 0.1.0-alpha** = **8**

### 別 project OSS repo 4 → 5 (予定)

現時点 local commit のみ (commit `8df8ff3`)、 GitHub public 公開は判断待ち (α)。

### 位置付け: Rei stack 内部監査 tool

benchtop / rei-verify / mcp-lens は 外部 domain (計測 / 反証 / MCP lens) に対する tool だが、 **rei-meta-mcp は Rei stack 自体の 認知盲点 を機械 audit する tool** = 「Rei stack が Rei stack を audit する再帰構造」 の 第 1 段。 rei-verify が 「Rei が Rei の主張を反証」 の型 だったのに対し、 rei-meta-mcp は 「Rei が Rei stack の一貫性を検査」 = 対を成す。

## Honest scope

1. Phase 1 spike、 実 registered source 3 個 (対象 seed_kernel のみ)。 対象が増えるほど価値が上昇する構造だが、 3 個でも等化子検査は成立
2. 「圏論の計算」 は しない、 「コネクタ群の上に立つ圏」 として名前の負荷を最小化 (5 用語のみ)、 装飾を避けた
3. partial fingerprint 同士の 「一致」 は content-level 完全一致の証明ではない、 available field 上での 「不一致がない」 の確認まで
4. remote rei-aios 直接 probe は Phase 1 scope 外 (claude.ai remote-devices 経由 = Python 不可)、 `unreachable_placeholder` kind で毎回 loud に surface
5. 自動修復は永久 scope 外 (Phase 2/3 でも実装しない予定)、 判断を機械の外に出さない
6. 「世界唯一」 主張ゼロ ([[feedback-world-uniqueness-claim-controllable]])、 SQL 経由の diff tool + MCP proxy 監視 tool は既存市場に多数存在、 本 tool の novelty は 「Rei stack MCP 群に対する 4 verdict 分離 + registry native unreachable placeholder + full/partial 混合 fingerprint」 の 組合せのみ

## Phase 2 / Phase 3 candidate (defer)

- Phase 2: 検査履歴の永続化 + 定期実行 + アラート通知 (メタ層が第三の真実になるのを避けるため慎重に judge)
- Phase 2.5: benchtop `json_dir` adapter 追加 (measurements object の coherence check、 §11 で判明した spec 修正)
- Phase 3: スキーマ自動推論 + 圏論構成の一般化 (関手・極限 等、 荷重負う場面が出てきた時点で追加、 先に名前を置かない)
- 別 STEP: remote rei-aios 直接 probe 経路の調査 (claude.ai remote-devices API 経由の可能性)

## 関連

- [[project-rei-memory-mcp-phase1-arc-2026-08-19]] 事故発見 origin (前 arc)
- [[feedback-remote-mcp-deploy-lag-2026-08-19]] 事故 finding F3 origin
- [[feedback-one-reproduction-over-ten-unverified]] §11 順序原則 適用実例
- [[feedback-no-rush-publication]] pause 判断 (arc close 判断は明日以降)
- [[feedback-all-research-site-reflection-default]] 2026-08-06 protocol 適用 (site 反映 (β) 予定)
- [[feedback-world-uniqueness-claim-controllable]] Honest scope 6 適用
- [[feedback-ai-usable-tool-design-5-conditions-2026-08-18]] 5 条件 checklist (allowlist=verdict / 危険操作なし / 構造化 return / graceful degradation via unreachable / selftest 31/31)