STEP 1569 — Design Imports Register

STEP 1569 · repo-discovery watch-list に importCategory field 追加 + Bluesky/Ophyd 起点で 5 ecosystem を 設計輸入元 として register · Rei-AIOS · 2026-08-30

目的

chat-Claude 2026-08-30 arc で以下が指摘された:

実験室制御には、MCP より 10 年以上先行した成熟エコシステムがある (EPICS / Tango Controls / Bluesky+Ophyd / QCoDeS / SiLA 2)。 これらは 179 件 scout catalog から 1 件も入っていなかった。 「導入候補」 ではなく 「設計の輸入元」 として、 中身を読んで考え方だけ持ち帰る対象。 承認ゲートの意味が濁らないよう、 点検表の同じ列に並べない方が良い。

本 STEP はこの指摘に対する rei-aios 側の operational 応答:

  1. Ophyd 読解 (chat-Claude 最終推奨、投資対効果最大) — Signal/Device/Component + protocol group + NotConnectedError 1st-class の設計原理を Rei stack に持ち帰る形で要約
  2. 点検表 schema の 2 section 化 — WatchedRepo.importCategory optional field 追加、default = 'adoption-candidate'、明示的な 'design-import' section を隔離
  3. 5 ecosystem 追加 — bluesky/ophyd-async / bluesky/bluesky / microsoft/Qcodes / epics-base/epics-base / tango-controls/cppTango / SiLA2/sila_base を design-import として登録

Schema 変更 (Step 3)

src/axiom-os/repo-discovery-crawler-engine.ts の WatchedRepo interface に optional field:

export interface WatchedRepo {
  // ... 既存 6 field
  importCategory?: 'adoption-candidate' | 'design-import';
}

Default (undefined) = 'adoption-candidate' 扱い。 crawler の star/push tracking は両者に同様に働く (schema-only distinction、logic 変更なし = backward compat)。

category意味意思決定
adoption-candidate MCP / ライブラリとして直接取り込みうる候補 承認ゲート必須 (MCP は接続時点で任意コード実行可)、中身を読んでから判断
design-import 中身を読んで 考え方だけ Rei に持ち帰る対象 直接接続は前提としない、輸入した pattern は Rei 側 STEP として実装
Honest scope: 本 field は rei-aios 内 watch-list.json にのみ適用。 別 tab で管理される rei-scout の 179 件 checklist は本 schema 変更を継承しない (別 repo/system)。 rei-scout 側が同等の distinction を採用するかは 藤本さん判断 (提案として 本 page を reference 可能)。

5 ecosystem — 設計輸入元 register (Step 2)

fullNamereiDomain持ち帰る観点
bluesky/ophyd-async ★ infrastructure Signal/Device/Component + Movable/Readable/Configurable protocol + NotConnectedError 1st-class = Rei NEITHER 同型。 asyncio + backend polymorphism + protocol typing の三点 rewrite が完成度別格
bluesky/bluesky infrastructure RunEngine + Msg indirection layer (plan は Msg を yield、hardware 直呼禁止) = STEP 1345 SafetyGate の完成形先例
microsoft/Qcodes simulation 量子計測ラボの標準 framework (Instrument/Parameter/Station 三層)。 parameter validators (bounded range + type check) は D-FUMT₈ verdict の入力 gate として輸入検討可
epics-base/epics-base infrastructure 加速器・大型実験施設の制御基盤 (数十年の実運用)。 Channel Access の分散命名 + record-based state model = Rei の tool 命名 (flat) を階層化する時の precedent
tango-controls/cppTango infrastructure Attribute quality (VALID/INVALID/ALARM/WARNING/CHANGING) の 5 値 quality flag = Rei 8 値の subset (INVALID ~ NEITHER / ALARM ~ BOTH / CHANGING ~ FLOWING)
SiLA2/sila_base infrastructure ラボ機器通信標準 (gRPC + Feature Definition Language)。 Feature 単位の interface declaration + observable command/property の型分類 = protocol drift を型で捕まえる pattern の実装例

Ophyd 設計原理 5 章 (Step 1)

A. 命名層 — Signal / Device / Component

Signal = 単一 PV wrapper (最下層 leaf、backend interchangeable)。 Device = Signal と子 Device の composite で、親子関係を dash 区切り階層名で持つ (self.child.name = parent + "-" + child)。 Component = v1 の declarative wiring 記述子。

hardware 側 (backend / connector) と論理側 (Device tree) が SignalBackend / DeviceConnector で切断されており、 EPICS CA / PV Access / Tango を 同じ Device 定義で差替え可能。

B. 状態表現 — Status object / connect / stage

Status object は 3 terminal state — set_finished() (成功) / set_exception(err) (失敗) / timeout — を持ち、コールバックで完了通知。 settle_time で hardware 安定化猶予を明示。

connect() は cache 済 (_connect_task)、未接続は NotConnectedError として 1st-class 例外、mock mode (_mock 属性) を real path と別 attribute で保持。

「値が取れていない」 は default 値でも None でもなく明示例外/未 connect 状態 = Rei の NEITHER と同型。

C. Movable / Readable / Configurable protocol

Protocol 名は Movable (set 可) / Readable (read/describe を持つ) / Configurable (configure/read_configuration) / Triggerable (trigger→Status 返却) / Stageable (stage/unstage lifecycle) / Subscribable (monitor 可) / Flyable (kickoff/complete)。

v1 は duck typing、 ophyd-async は type hints で fulfil — 同じ trait を control-system 別 connector が実装する。

D. v1 → async の rewrite 差分

  1. threading → asyncio で「2 PV 並列 put + 別 PV get」 の fly scan が単一 thread 決定的化 (locks/events 消滅)
  2. SignalBackend 抽象化 で EPICS CA 前提を排除、Tango / PV Access 同居可
  3. composition over inheritance — PandABox 等の customizable hardware で logic と interface を分離、v1 の deep class hierarchy 脆さを解消

これが chat-Claude 言う 「10 年先行」 の中身 = asyncio + backend polymorphism + protocol typing の三点 rewrite。

E. Rei stack 転用パターン

Bluesky 側は Msg 間接 (plan は yield Msg のみ、 hardware 直呼禁止) — RunEngine が set / stage / unstage / trigger / read / configure / wait / checkpoint / subscribe / monitor / open_run / close_run / pause / sleep を dispatch。 これは benchtop-mcp SafetyGate (STEP 1345) の完成形先例。

Rei に即持ち帰り可能 top 3

  1. NotConnectedError = NEITHER の型化: 全 benchtop probe と全 D-FUMT₈ verdict tool で 「未接続 / データ未取得」を ZERO no_data 単一 verdict に統一 (STEP 1567 pattern を全 tool 適用)
  2. Msg indirection layer: rei-aios MCP tool 群を 「plan は tool call を yield、実 hardware は SafetyGate dispatch」 の 2 層化 — 現状の直呼を廃し introspection / dry-run / 安全停止を得る
  3. Protocol 型で connector catalog を裏付け: STEP 1556 の shape 文字列 (puzzle-verifier 等) を Movable/Readable 相当の TS interface に昇格、drift auditor (STEP 1560) を 「型不一致 = build error」 に強化

Honest scope