Rei-Automator 実装 inventory Phase 0 handoff

2026-08-16 · chat-Claude 「Rei-Automator 全部入り設計書」 (5層 kernel + plugin) Phase 0 「棚卸しと線引き」 用 handoff · 系統 A rei-aios TS 7 file + 系統 B rei-automator-mcp Python + 5層 mapping + WebFetch OpenClaw verify record

本 page の 目的: chat-Claude が Phase 0 分担で 「実装 詳細 教えて 頂ければ 5層 仕分けを 一緒に やれます」 と 提案。 本 page は その 材料 (現状 inventory + 5層 mapping + gap analysis)。 chat-Claude の WebFetch 経由 or 藤本さん の 直接 handoff で 消費 想定。

関連 artifact: chat-Claude design HTML (rei-automator-design.html) archival

1. Meta

2. 全体構造 (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)

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

#file行数役割status
1src/workspace/rei-automator/workspace-automator.ts~400Main class WorkspaceAutomator、 14 action kinds、 EventBus/Orchestrator 接続wired STEP 1336 修復済
2src/aios/api/automator-api.ts210REST router、 7 endpoints、 D-FUMT₈ tag 付きwired
3src/aios/rei-automator-bridge.ts234theorem → action derivation、 ActionExecutor 統合DORMANT (STEP 1336 wrong-impl 4 例目 origin)
4src/aios/hypervisor/hypervisor-automator-bridge.ts?STEP 79、 VM 並列 + Theory#196 PeaceCheckactive
5src/axiom-os/rei-automator-daily.ts?1-day 1-problem attack pipeline + MANDALA lensactive
6src/workspace/rei-automator/automator-cli.ts?CLI (bash/Claude Code) + DANGEROUS_PATTERNS filteractive
7src/interfaces/automator-ui*.html?Web UI legacy 2 filelegacy

3.1 WorkspaceAutomator action kinds (14)

file_write, file_read, shell_command, note_export, proof_run, axiom_propose, report, screenshot, click, type, wait, search, open, excel_aggregate

3.2 AutomatorRouter endpoints (7)

GET /api/automator/status, GET /api/automator/actions, POST /api/automator/{propose,approve,execute,cancel,clear}

3.3 CLI DANGEROUS_PATTERNS (Peace Axiom)

rm -rf /, format c:, del /*, shutdown, mkfs, dd if= 等 6+

4. 系統 B: rei-automator-mcp Python (independent public repo)

filesize役割
rei_automator_mcp.py32.6 KBMCP server、 7 tools + 12 action kinds + Phase 2 find_element pywinauto
rei-sendinput.ps17.3 KBPowerShell SendInput 独立 process
README.md12.8 KB全 architecture 説明 + canonical layer clarification
docs/phase2-backend-design.md~7.3 KBPhase 2 pywinauto 設計書 259 行

4.1 7 MCP tools

propose_action, approve_action, execute_action, cancel_action, list_pending, list_executed, get_status

4.2 12 action kinds (系統 A の subset + Phase 2 find_element)

系統 A に click/type/wait/axiom_propose 追加が 系統 B にない、 系統 B に find_element 追加が 系統 A にない (semantic 互換)。

4.3 selftest 30 assertions (22 → 30 in v0.2.0-alpha)

4.4 security fix commit 2348ba7

STEP 1336 arc 内 allowlist bypass via auto_approve、 test-writer-check-test 誤成功 pattern の 修正。

4.5 persistence

~/.rei-automator-mcp/execution-log.json

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

現状 実装★ 足りない (chat-Claude Phase 1 target)
認識層 screenshot + find_element (Phase 2 pywinauto uia) + file_read + parseCatalog (rei-automator-daily.ts markdown) DOM 認識、 event stream 統一 normalization schema
実行層 系統 A 14 kinds + 系統 B 12 kinds + Hypervisor VM 並列 + CLI + Peace Axiom filter マクロ 記録 / 再生 backend、 plugin sandbox
判断層 ★★★ rule-based (parseNLCommand) + theorem-based (_theoremToAction、 dormant) + MCP client-side model bind + MANDALA lens (rei-automator-daily.ts E22-E27) ★★★ 最重要 gap モデル差し替え interface = 未実装 (Claude/GPT/Gemini/local model 差し替え)、 統合層に LLM 直接呼び出しなし = Phase 1 primary target
記憶層 execution-log.json (系統 A+B 両方 STEP 1336 pattern) + Pending Map + Executed 配列 + Daily register JSON 長期メモリ、 user 設定 永続化、 markdown 保持 (chat-Claude 提案 OpenClaw pattern)
安全層 ★★ 3-stage lifecycle (propose→approve→execute) + autoExecute: false default + allowedActions whitelist + maxConcurrent: 3 + dryRun default + DANGEROUS_PATTERNS + Theory#196 PeaceCheck ★ 追加必要 dryRun mode 明示 API、 緊急停止 (kill switch) 未実装、 rate limit 精細化、 audit log 独立 store、 承認ゲート UI

6. ★★ OpenClaw WebFetch verify record (chat-Claude 前 arc turn 2-3 3 rounds 検証結果)

本 section の 目的: chat-Claude が 「OpenClaw = Rei-Automator の 最も直接的な 競合」 と 3 turn 連続 mention。 私 (session A) が 3 rounds WebFetch triangulation で 実在 verify、 結果 を permanent record 化 (chat-Claude が re-fetch 不要)。

6.1 verify 結果 (WebFetch 3 rounds)

verify 方向結果信頼度
Peter Steinberger (steipete) org 所有✓ 確認 (steipete profile で pinned repos に openclaw/Peekaboo + openclaw/mcporter)
OpenClaw = 実在 GitHub org✓ 確認 (github.com/openclaw org page 存在、 87 repos 主張)
OpenClaw = Steinberger の 「AI assistant」 flagship✓ 確認 (「Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞」 tagline)
star count = 386k (WebFetch 主張)⚠️ inconsistent — 3 rounds で 同じ 386k を 出すが、 steipete profile 側 の 個別 pinned repo は Peekaboo 5k + mcporter 4.9k、 WebFetch tool 部分 hallucination の 疑い
chat-Claude 「180k stars」 主張差異あり (WebFetch 386k との 差 2x)、 藤本さん browser 直接 verify 推奨対立

6.2 判定 summary

7. Gap analysis (chat-Claude Phase 0/1 対象 との differential)

7.1 Phase 0 「棚卸しと線引き」 (1-2 週)

  1. 既存機能を kernel / plugin 分類 → 上記 5-layer mapping 参照
  2. バージョニング方針決定 → 系統 B v0.2.0-alpha SemVer 適用済、 系統 A 未策定
  3. 権限モデル草案 → 3 層あり (whitelist + DANGEROUS_PATTERNS + 3-stage lifecycle)、 chat-Claude Human-in-the-loop 部分実装

7.2 Phase 1 「カーネル切り出し」 (1-2 ヶ月)

  1. ★★★ 判断層 モデル差し替え interface = 未実装 = 最重要 gap
  2. ★ 安全層 dryRun / 承認ゲート / 緊急停止 → 3 のうち 2 部分実装、 緊急停止 未実装
  3. 既存機能を新カーネル上に 移植 (機能増やさない) → Phase 0 完了後 scope 明確化

7.3 Week 1 checklist (chat-Claude 提案)

  1. ✓ 5 層 分類 (本 handoff で 提供)
  2. 2 層以上 またがっている機能: parseNLCommand (認識+判断)、 _theoremToAction (判断+実行)
  3. ✓ 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 必要

8. Open questions (藤本さん judgment 材料 6 件)

  1. 系統 A ReiAutomatorBridge dormant を どうするか (削除 / 復活 / retain-as-archive)
  2. rei-automator-daily.ts の 位置付け (実行層 tool か 判断層 lens か)
  3. プラグイン API 境界 (hypervisor / EventBus / RuntimeBus / MCP protocol 4 統合先 の どこ)
  4. 判断層 モデル抽象化 scope (4 provider min: Claude+OpenAI+Google+local Ollama vs 全域)
  5. License 統一 (v1.0+ AGPL 予告 = 系統 B のみ、 系統 A = Rei-AIOS AGPL+Commercial dual)
  6. 配布 scope 明確化 (系統 B v0.2.0-alpha public GitHub vs 系統 A 藤本さん 個人使用のみ)

9. Honest scope (譲れない線 6 条)

  1. 現状 inventory + 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 互換
  4. 統合/実行層 architecture (2026-08-15 decision) と chat-Claude 5 層 は orthogonal: 5 層は 単一 process 内 責務分離、 統合/実行層は プロセス境界、 5 層 を 系統 A + 系統 B 両方 に 適用 する 必要 = 2 × 5 = 10 の 分類 grid
  5. chat-Claude design の 前提 「すでに配布中」 = 系統 B v0.2.0-alpha public GitHub のみ、 系統 A は 藤本さん 個人使用
  6. chat-Claude 分担 pickup 準備: 4 GitHub issue 既 open (#1 click / #2 type / #3 screenshot / #4 excel_aggregate)、 本 handoff は Phase 0 段階、 4 issue は Phase 2 プラグイン 実装 相当

10. References + 関連 STEP