同じ名前で並走していた 3 つの実装について、この日に 5 つの判断が決まり、うち 1 つは同日中に反転しました。① Desktop は「自分専用」から「小規模な experimental 配布」へ。v0.9.8-experimental が prerelease として公開され、v0.9.7 stable との 2 トラック体制になっています。以下はその記録と、判断に使った実測です。
当初この文書は「決めていただきたいこと 5 点」として書かれました。5 点とも答えが出たので、問いではなく記録として置き直します。
当初は「自分専用として凍結」でした。4 版合計 16 ダウンロード (最多の v0.9.5 = 12 件は手元の版) という実績が、現状の性格をそのまま示していたためです。
反転後 — 完全な配布物として育てるのではなく、stable を推奨したうえで experimental を prerelease として並置するという中間形。v0.9.8-experimental が公開され、README も 2 トラック化されました。「配布か自分専用か」の二択ではなく、責任範囲を明示した第三の形に落ちています。
5 か月分の依存が動くかは未知数でしたが、通りました。ただし成果は「build できる」という確認であって、機能ではありません。実際の起動確認は継続中です。
これ以上 Desktop の rebuild に投資しない、という判断。① は v0.9.7 の機能のまま置き、新しい実装は ② と ③ で進めます。再開する条件は下の「保留を解く条件」に。
ライセンス表示は当日中に修正。98 MB の exe を git 履歴から消す件と README の充実は、自分専用スタンスでは優先度が下がるため見送り。配布を決めた時点で実施します。
Rei-Automator Desktop (①) / Core (②) / rei-automator-mcp (③)。公開 README にライセンスの違いとあわせて明記されました。以後この 3 語で呼び分けます。
route B は「実行時に ② を呼ぶ」設計でした。実際に 8/21 に行われたのは「build 時に ② のソースを junction で取り込む」で、これは別の機構です。保留の理由がここにあります。
8/21 未明に rei-automator-new-2026-08-21\release\ で 3 本の exe がビルドされています。元の rei-automator-release\ と rei-automator\ には手を入れていません。
| ファイル | サイズ | 時刻 | 位置づけ |
|---|---|---|---|
| ReiAutomator-0.9.8- rei-aios-sync-…-portable.exe |
103,431,947 B | 01:41 | rei-aios 5 か月分を junction 経由で取り込んだ実験ビルド。起動時に anthropic-sdk 由来のエラー。 |
| ReiAutomator-0.9.7- portable.exe (新) |
121,532,637 B | 01:58 | 公開版と同名・別物。公開版は 101,216,687 B (sha256 0a81fc8c…) で、20 MB 違います。 |
| ReiAutomator-0.9.8-v2- with-21-deps-…-portable.exe |
121 MB | 同日 | v0.9.8-experimental として公開済 (prerelease)。sha256 a0d2204d…公開 |
「ReiAutomator-0.9.7-portable.exe」という名前のファイルが、中身違いで 2 つ存在します。公開済みのものと、8/21 01:58 に新フォルダで生まれたもの。取り違えると原因の分からない挙動差になります。照合はファイル名やサイズではなく sha256 で行うのが確実です。公開側は資産名が分かれた (…0.9.8-v2-with-21-deps…) ので曖昧さは解消しましたが、手元の作業フォルダには同名の別物が残っています。
「5 か月分の更新が入った」の中身を 3 層に分けると、どこが実質でどこが名目かがはっきりします。
| 層 | 変わったもの | 実質度 |
|---|---|---|
| Layer 1 Electron コード |
commit 1 本 (.gitignore 修正) のみ。UI に見える変更はありません。 |
ほぼゼロ |
| Layer 2 下位 API (junction 経由) |
Phase 1 audit chain (persistence 修復 / kill switch / dangerous patterns / dryRun / append-only JSONL + sha256 hash chain)、bridge のログ出力先 env var 3 段 fallback、workspace-automator.ts 21 KB → 30 KB、D-FUMT₈ 8 値化以降の rei-aios 進化。 |
実質 · 但し未検証 |
| Layer 3 runtime 依存 |
21 個追加 (Anthropic SDK / MCP SDK / mermaid / katex / react / decimal.js / brotli-wasm / nostr-tools ほか)。exe が 101 MB → 121 MB に。 | 確実 (+18 MB) |
これらは build の入力に入ったことまでが確認済みで、Electron の main が UI 経由で実際に呼ぶかは別の話です。「build 入力に見えた」は「GUI 上で見える機能」を意味しません。Layer 1 がほぼゼロである以上、UI からの導線が引かれていない可能性は十分にあります。ここが残る唯一の未検証項目で、v0.9.7 と v0.9.8-experimental を順に起動して目視比較すれば判明します。
stable を主に推奨し、experimental は prerelease として並置する 2 トラック体制です。prerelease フラグが立っているので、latest には出てきません。
2026-03-17 リリース、101 MB。2026-08-21 に起動確認済。迷ったらこちらです。
2026-08-21 公開、121 MB、sha256 a0d2204d…。リリースノートに 5 つの制約 (TS error 39 本の mask、rebuild がマシン依存、起動確認どまりの検証、電子署名なし、本番非推奨) が明示されています。
ソースを読んで挙げた懸念は、すべて確認され、対応または明示的な保留になりました。
| 指摘 | 結果 |
|---|---|
| version が上がっていない — ファイル名だけ 0.9.8 で package.json は 0.9.7 | 対応 0.9.8-experimental に bump |
| README と release/ の実態がずれている — 01:42 の README に 01:58 のビルドの記載なし | 対応 junction 制約と version 修正を追記 |
| 「dead code path が大半」は未検証 — TS error 39 本の性質は確かめられていない | 対応 「未検証」と書き換え |
|| cd . で型エラーを握りつぶしている — tsc … || cd . なので error があっても build 成功扱い |
保留 自分専用スタンスのため据え置き |
初版のこの文書は「rei-automator-release に LICENSE がない」という実測の直後に、「sougou-connectors を MIT で出したのと同じ判断をここにも通す必要があります」と書きました。MIT が必須ではない旨は括弧書きで添えていましたが、先に MIT を名指しした時点で、そちらへ引っ張る文章になっていました。実際には ① のソースには LICENSE があり、Proprietary が明示されています。正しくは「既存のライセンス表明を確認したうえで」と書くべきでした。
rei-automator-release に LICENSE ファイル (Proprietary) が追加され、README も差し替わっています。コンパイル済み exe の個人・学術利用は可、ソース閲覧・改変・再配布・リバースエンジニアリング・商用展開は書面許諾なしに不可。Desktop が 2026-03-23 で凍結されたことと、3 系統のライセンスの違い (Desktop = Proprietary / Core = Private / mcp = MIT) も明記されました。
GitHub の license API は spdx_id: "NOASSERTION" / name: "Other" / url: null を返します。ファイルの存在は検出されているが、SPDX で分類できないという状態で、独自プロプライエタリでは正常な挙動です。サイドバーのバッジ表示もありません。実質的な担保は raw で取得できる LICENSE (HTTP 200 / 3,009 bytes) と README のほうで、これで足りています。
補足 — この文書の初版は「API は license: null を返す」と書いていました。それは LICENSE 追加前のキャッシュされた応答を見ていたためで、追加後の正しい値は上記です。
配布の判断が動いたことで、3 件のうち 2 件が「部分的に解けた」状態になりました。完全には解けていないので、条件は残しておきます。
8/21 の rebuild が完走したことは、route B が実現できるかについて何も語りません。通ったのは build 時に junction でソースを取り込む経路であって、実行時に境界を越えて呼ぶ経路ではないからです。「rebuild が通った = B は行けそう」という推論は成り立たないので、B を解禁するときは feasibility を一から見る必要があります。
現在地 — 配布の判断は動きましたが、小規模な experimental 配布であれば junction snapshot のままで当面足ります。作り直しが要るのは、更新頻度が上がるか、藤本さん以外が rebuild する必要が出たときです。private repo 依存をどう扱うか (切り出す / 公開する / 複製する) が、その時の最初の判断になります。
現在地 — 同上。③ は PyPI で独立に版が進むので、本格的に育てる段になればこちらのほうが境界が疎です。Python 同梱をどうするか (embeddable Python か、利用者に入れてもらうか) が最大の設計判断になります。
現在地 — 「配布を決めたとき」は成立しましたが、「clone の重さが実害になったとき」はまだです。配布の実体が Releases 経由のバイナリなので、リポジトリを clone する人はほとんどいません。履歴が浅いいまのほうが作業は楽、という点だけは変わりません。
この記録は 3 種類の情報でできています。混ぜないように分けておきます。
release/ の exe 2 本のサイズと時刻src/ 配下が全て junction であることpackage.json の || cd . と UNLICENSED7caa624 (公開側で確認済)4c0077e — 破壊的操作前の退避8e2796353 — bridge revive (Core 側の compat shim)残っているのは Layer 2 の GUI 検証 ひとつです。v0.9.7 と v0.9.8-experimental を順に起動して目視で比べれば、audit chain や kill switch が UI から届いているのか、それとも build に入っただけなのかが分かります。Layer 1 がほぼゼロなので、後者である可能性は低くありません。
結果がどちらでも、これ以上 Desktop の rebuild には投資しません。動かなければ v0.9.7 stable に戻せば元通りです。