# Rei-Automator 実装 inventory — chat-Claude Phase 0 「5層仕分け」 用 handoff

## Meta

- **作成**: 2026-08-16、 by session A (Claude Code + Nobuki Fujimoto)
- **目的**: chat-Claude 2026-08-16 `rei-automator-design.html` (「全部入りにするための設計書」) の **Phase 0 「棚卸しと線引き」** に 必要な 現状 code inventory を 提供
- **対象読者**: chat-Claude local-agent session (Rei-Automator 分担 継続)
- **前提**: STEP 1336 wrong-implementation wiring 修復済 (2026-08-15)、 rei-automator-mcp v0.2.0-alpha Phase 2 find_element release 済 (2026-08-15)
- **honest scope**: 本 handoff は **現状 snapshot + mapping のみ**、 Phase 0 決定 (どこを kernel / plugin にするか) は 藤本さん judgment (open questions 参照)

## 全体構造 (2 系統 並存 + auxiliary)

### 系統 A: rei-aios TypeScript (統合層 = 深い意味統合)
SEED_KERNEL / Peace Axiom #196 / EventBus / D-FUMT₈ semantic tagging の 深い統合を担う。 実 OS 触る コードは持たず、 自動化 が必要な 場面では **MCP client として 系統 B に stdio 長寿命 1 本で依頼** (2026-08-15 architecture decision)。

### 系統 B: rei-automator-mcp Python (実行層 = OS を触る唯一の実体)
OS を 触る コード の 唯一の 実体、 12 action kinds の 全 実装、 stdio MCP protocol 経由で **Claude Desktop / Cursor / Cline / VS Code MCP 拡張** から 直接 使える。 fc0web/rei-automator-mcp public GitHub。

### auxiliary
- `rei-sendinput.ps1` (7.3 KB): PowerShell SendInput 独立 process 化、 Base64 encoding boundary 回避
- `interfaces/*.html`: Web UI legacy 2 file

---

## 系統 A: rei-aios 内 TypeScript files (7 files)

### 1. WorkspaceAutomator (`src/workspace/rei-automator/workspace-automator.ts`, ~400 行)

- **役割**: 統合層 main class、 EventBus / Orchestrator / Notification 接続
- **action kinds** (14): `file_write`, `file_read`, `shell_command`, `note_export`, `proof_run`, `axiom_propose`, `report`, `screenshot`, `click`, `type`, `wait`, `search`, `open`, `excel_aggregate`
- **methods**: `propose`, `approve`, `cancel`, `execute`, `executeAll`, `parseNLCommand` (自然言語 → action)、 `getStatus`/`setStatus`, `getPending`, `getExecutedLog`, `_loadLog`, `_saveLog`
- **config**: `autoExecute` (default false), `allowedActions` whitelist, `maxConcurrent` 3, `notifyOnComplete`/`notifyOnError`, `logDir`
- **status**: STEP 1336 (2026-08-15) で `_loadLog`/`_saveLog` 追加 (wrong-implementation wiring 修復)、 wired via AutomatorRouter

### 2. AutomatorRouter (`src/aios/api/automator-api.ts`, 210 行)

- **役割**: REST API layer for WorkspaceAutomator
- **endpoints** (7): `GET /api/automator/status`, `GET /api/automator/actions`, `POST /api/automator/{propose,approve,execute,cancel,clear}`
- **allowedActions**: 10 kinds (`file_write`, `file_read`, `shell_command`, `note_export`, `proof_run`, `report`, `screenshot`, `open`, `search`, `excel_aggregate`) — `click`/`type`/`wait`/`axiom_propose` 未 whitelist
- **response format**: 全 `dfumtValue` D-FUMT₈ tag 付き (TRUE/FALSE/FLOWING/NEITHER/ZERO)

### 3. ReiAutomatorBridge (`src/aios/rei-automator-bridge.ts`, 234 行) — **DORMANT** ⚠️

- **役割**: theorem → action derivation (ReiTaskQueue + TheoremDeriver + ActionExecutor 統合)
- **action kinds** (7): `file_write`, `file_read`, `shell_command`, `note_export`, `proof_run`, `axiom_propose`, `report` (少ない)
- **methods**: `proposeFromTheorems(category)` (theorem system → action list)、 `_theoremToAction` (category-based dispatch)、 `approve`, `_enqueueExecution`, `_execute` (via ActionExecutor)
- **feedback loop**: RuntimeBus publish 済
- **status**: STEP 1336 grep で **全 repo 参照ゼロ** = 「wrong-implementation wiring pattern」 4 例目 の origin、 実装は 残るが production 未接続。 削除 / 復活 / retain-as-archive 判断保留

### 4. HypervisorAutomatorBridge (`src/aios/hypervisor/hypervisor-automator-bridge.ts`)

- **役割**: STEP 79、 ReiHypervisor × Rei-Automator 統合、 VM 上で 並列自動操作
- **flow**: AutomatorAction → DedicatedTask mapping → TaskDistributor → VM 選択 → Mock or Real 実行 → WorkspaceAutomator 反映
- **action kinds** (15): WorkspaceAutomator 14 + `key` 追加
- **Theory#196**: 全 操作に PeaceCheck 適用

### 5. Rei-Automator Daily (`src/axiom-os/rei-automator-daily.ts`)

- **役割**: 1-day / 1-problem attack pipeline、 unsolved math problem に MANDALA lens 適用
- **input**: `data/wikipedia-unsolved-problems/catalog-2026-04-13.md` (789 problems, round-robin by day)
- **pipeline**: (a) catalog 問題 pick → (b) D-FUMT₈ classify → (c) lens 適用 (E22 circuit / E23 photonic / E24 quantum + E25-E27 新規) → (d) Paper draft 生成 → (e) daily register log
- **honest scope**: 適用 lens なし の 場合 「honest position paper」 出力 (Paper 88-90 style)

### 6. Automator CLI (`src/workspace/rei-automator/automator-cli.ts`)

- **役割**: bash / Claude Code から 直接呼び出し
- **commands**: `run`, `propose`, `list`, `status`, `nl` (自然言語)、 `file-read`, `file-write`, `search`, `report`, `help`
- **Peace Axiom check**: `DANGEROUS_PATTERNS` (`rm -rf /`, `format c:`, `shutdown`, `mkfs`, `dd if=` 等 6+ patterns)

### 7. Web UI (`src/interfaces/automator-ui-v2.html` + `automator-ui.html`)

- legacy web interface 2 file

---

## 系統 B: rei-automator-mcp Python (independent public repo `fc0web/rei-automator-mcp`)

### rei_automator_mcp.py (32.6 KB)

- **7 MCP tools**: `propose_action`, `approve_action`, `execute_action`, `cancel_action`, `list_pending`, `list_executed`, `get_status`
- **class Automator**: `propose`, `approve`, `cancel`, `execute`, `_dispatch` (kind → impl)、 `_find_element_impl` (Phase 2 pywinauto uia backend)、 `_load_log`, `_save_log`, `get_status`
- **action kinds** (12): 系統 A の subset + Phase 2 `find_element`
- **selftest**: 30 assertions (22 → 30 in v0.2.0-alpha)
- **security fix**: STEP 1336 arc 内 commit `2348ba7` (allowlist bypass via auto_approve、 test-writer-check-test 誤成功 pattern の 修正)
- **persistence**: `~/.rei-automator-mcp/execution-log.json`

### 補助 files

- `rei-sendinput.ps1` (7.3 KB): PowerShell SendInput 独立 process、 Base64 encoding boundary 回避
- `README.md` (12.8 KB): 全 architecture 説明 + canonical layer clarification
- `docs/phase2-backend-design.md`: Phase 2 pywinauto 設計書 (259 行)
- `CONTRIBUTING.md`, `LICENSE` (MIT v0.x, v1.0+ AGPL 予告)

---

## 5-layer kernel 仕分け mapping (chat-Claude design 提案 への 現状 mapping)

### 認識層 (Perception)

- **現状 実装**: `screenshot` action kind、 `find_element` (Phase 2 pywinauto uia backend)、 `file_read` action kind
- **統合層 補助**: `parseCatalog` (rei-automator-daily.ts、 markdown parser)
- **★ 足りない**: DOM 認識、 event stream 統一化、 統一 normalization schema

### 実行層 (Execution) — 現状 最も 実装厚い

- **系統 A**: 14 action kinds (WorkspaceAutomator)
- **系統 B**: 12 action kinds (Python MCP、 find_element 実装済)
- **統合層 augment**: Hypervisor VM 並列、 CLI (bash) 、 Web UI
- **Peace Axiom**: `DANGEROUS_PATTERNS` filter (CLI 側)
- **★ 足りない**: マクロ 記録 / 再生 backend、 plugin sandbox

### 判断層 (Decision) — ★★ chat-Claude 「モデル抽象化 = 生命線」

- **現状 実装**: `parseNLCommand` (rule-based regex)、 `_theoremToAction` (theorem-based ReiAutomatorBridge)、 MCP client-side model bind
- **統合層 lens**: MANDALA lens integration (rei-automator-daily.ts E22-E27)
- **★★★ 足りない (chat-Claude 指摘 と 完全 一致)**: **Claude / GPT / Gemini / local model 差し替え可能 interface = 未実装**。 現状 MCP client 側 model bind のみ、 統合層に LLM 直接呼び出しなし = **Phase 1 最重要 gap**

### 記憶層 (Memory)

- **現状 実装**: `execution-log.json` 永続化 (系統 A + B 両方、 STEP 1336 pattern)、 Pending Map + Executed 配列 (in-memory)、 Daily register JSON (rei-automator-daily.ts)
- **★ 足りない**: 長期メモリ、 user 設定 永続化、 markdown 保持 (chat-Claude 提案 OpenClaw pattern)、 学習内容 の permanent store

### 安全層 (Safety) — ★★ chat-Claude 「後回し禁止」

- **現状 実装**: 3-stage lifecycle (propose → approve → execute)、 `autoExecute` default false、 `allowedActions` whitelist、 `maxConcurrent` 3、 `dryRun` default (ActionExecutor)、 `DANGEROUS_PATTERNS` filter、 Theory#196 PeaceCheck (hypervisor)
- **★ 足りない**: dryRun mode の 明示 API (現状 internal のみ)、 **緊急停止 (kill switch) 未実装**、 rate limit 精細化、 audit log の 独立 store、 承認ゲート の UI (現状 CLI + REST のみ)

### Integration / Ecosystem (Phase 4 candidate)

- 現状 統合先: EventBus (WorkspaceEventBus)、 Orchestrator (WorkspaceOrchestrator)、 RuntimeBus (getReiAIOSRuntime)、 ReiTaskQueue、 MCP protocol
- Phase 4 target: プラグイン registry + 共有 + license 設計 + 3 UI 層別 (一般 GUI ランチャー / 開発者 CLI + SDK / 法人 監査画面)

---

## Gap analysis (chat-Claude Phase 0 「棚卸しと線引き」 対象への differential)

### chat-Claude Phase 0 対象

1. **既存機能を カーネル / プラグイン に分類** → 上記 5-layer mapping 参照。 **現状 全部 統合層 or MCP tool の 単一 monolith、 プラグイン境界なし**。 分類 candidate:
   - **kernel 必須**: 3-stage lifecycle (propose/approve/execute)、 `allowedActions` whitelist、 `execution-log.json` 永続化、 D-FUMT₈ dfumtValue tagging
   - **plugin 候補**: 14+ action kinds の 個別 impl (`screenshot`/`click`/`type`/`excel_aggregate` は 明らか plugin)、 MANDALA lens、 hypervisor VM 並列、 daily attack pipeline
2. **バージョニング方針決定** → 系統 B rei-automator-mcp v0.2.0-alpha 現状 SemVer 適用済 + LICENSE trajectory notice、 系統 A (Rei-AIOS 統合層) は 未策定
3. **権限モデル草案** → 現状 3 層あり:
   - `allowedActions` whitelist (kind level)
   - `DANGEROUS_PATTERNS` filter (content level)
   - 3-stage lifecycle (interaction level)
   
   chat-Claude 指摘の 「Human-in-the-loop」 pattern 部分実装、 上記 3 層 の scope 明確化 + 権限 declaration DSL の 検討

### chat-Claude Phase 1 「カーネル切り出し」 target

1. **判断層 モデル差し替え interface**: ★★★ **未実装 = 最重要 gap**、 抽象 interface 設計 + Claude / GPT / Gemini / local (Ollama 等) の 4 provider minimum implementation
2. **安全層 dryRun / 承認ゲート / 緊急停止**: 3 のうち 2 (dryRun + 承認ゲート) 部分実装、 **緊急停止 未実装 = 追加必要**
3. **既存機能を新カーネル上に 移植 (機能増やさない)**: Phase 0 完了後に scope 明確化

### chat-Claude Week 1 checklist

1. ✓ 全機能を 5 層 分類 ← **本 handoff で 提供**
2. **candidate for check**: 2 層以上 またがっている機能
   - `parseNLCommand` (認識 + 判断 の混在)
   - `_theoremToAction` (判断 + 実行 の混在)
3. **✓ 洗い出し済**: LLM呼び出し箇所 = **統合層に LLM 直接呼び出しなし** (MCP client 側 bind、 個別 lens tool 経由 のみ)
4. **✓ 列挙**: 「取り返しのつかない操作」 = `file_write` (上書き)、 `shell_command` (実行)、 `excel_aggregate` (書き込み)、 `note_export` (外部 posting は 未実装)、 hypervisor VM 内 の 全 kind
5. **✓ 確認**: 承認ゲート = 3-stage lifecycle で 全 kinds cover
6. バージョニング方針 1 ページ ← rei-automator-mcp README 済、 系統 A は 未策定
7. **「やらない」 リスト 明文化** ← chat-Claude 提案 4 項目 (独自 LLM 開発 / API 全網羅 / Enterprise 権限 / モバイル) の Rei-Automator 側 採用 confirm 必要

---

## Open questions (藤本さん judgment 材料)

1. **系統 A ReiAutomatorBridge dormant を どうするか**: 削除 / 復活 / retain-as-archive の 3 択
2. **系統 A rei-automator-daily.ts の 位置付け**: 実行層 tool か 判断層 lens か
3. **プラグイン 境界**: 現状 hypervisor / EventBus / RuntimeBus / MCP protocol の 4 統合先 が モノリシック 混在、 どこを plugin API 境界にするか
4. **判断層 モデル抽象化 scope**: Anthropic Claude 依存 (現状 chat-Claude デフォルト) を どこまで generalize するか (OpenAI + Google + local Llama 等 4 プロバイダ minimum vs 全域)
5. **License 統一**: v1.0+ AGPL 予告 は 現状 系統 B のみ、 系統 A (rei-aios 内) は AGPL-3.0 + Commercial dual (Rei-AIOS root policy)、 統一 or 分離?
6. **配布 scope 明確化**: chat-Claude design 前提 「すでに配布中」 = 系統 B v0.2.0-alpha public GitHub、 系統 A は 藤本さん 個人使用のみ、 「破壊的変更 の 扱い」 は 系統別に 別 policy か 統一か

---

## Honest scope (handoff の 譲れない線 6 条)

1. **本 handoff は 現状 inventory + chat-Claude design への mapping のみ**、 実 Phase 0 決定 (どこを kernel / plugin にするか、 「やらない」 リスト 確定) は 藤本さん judgment
2. **数値は 2026-08-16 現在 snapshot**、 STEP 1336 (2026-08-15) 修復済み、 STEP 1337 Phase 2 find_element release 済み、 以降 変更未反映
3. **系統 A + 系統 B の 「12 vs 14 action kinds」 数値差** は semantic 互換 (系統 A に `click`/`type`/`wait`/`axiom_propose` 追加が 系統 B にない、 系統 B に `find_element` 追加が 系統 A にない)
4. **統合層 と 実行層 の 現状 architecture (2026-08-15 decision) と chat-Claude 5 層 は orthogonal**: 5 層は 単一 process 内 の 責務分離 (認識/実行/判断/記憶/安全)、 統合/実行層は プロセス境界 (rei-aios TS vs rei-automator-mcp Python)。 両者は 直交、 Phase 0 で 5 層 を **系統 A + 系統 B 両方 に 適用** する 必要
5. **chat-Claude design の 前提 「すでに配布中」** = 系統 B v0.2.0-alpha public GitHub、 系統 A は 藤本さん 個人使用のみ、 破壊的変更 の scope 系統別 判断必要
6. **chat-Claude 分担 pick up 準備**: 4 GitHub issue 既 open (`#1 click` / `#2 type` / `#3 screenshot` / `#4 excel_aggregate`)、 本 handoff は Phase 0 段階、 4 issue は Phase 2 プラグイン 実装 相当 の 位置付け

---

## References

- Design proposal: `C:\Users\user\Downloads\rei-automator-design.html` (chat-Claude 2026-08-16 作成)
- Rei-AIOS repo: `C:\Users\user\rei-aios` (系統 A + rei-automator-mcp installed dependency)
- rei-automator-mcp repo: `C:\Users\user\rei-automator-mcp` (系統 B、 GitHub public `fc0web/rei-automator-mcp`)
- STEP 1336 arc: 2026-08-15 wrong-implementation wiring 修復 + 系統 B security fix
- STEP 1337 arc: 2026-08-15 Phase 2 find_element release
- STEP 1338 arc: 2026-08-16 Antihydra Bridge (別方向 arc、 参考)
- STEP 1339 arc: 2026-08-16 Self-Loop-Space Hypothesis (chat-Claude Turn 9 proposal 骨格、 参考)