[hub] Arcrun 的 App 系統：規格、打包、掛上 Portal——CF 之於 Arcrun，如同 Linux 之於 Android #115

New Issue

2026-08-13T03:19:40Z

Leo commented

2026-08-13 03:19:40 +00:00

這是一張 hub 票（leo 2026-08-13：「如果很多票講到它，你建一張 hub 票，把這些票收在一起，才能一併做」）。
它不是執行票，不要在這裡寫 code。它的職責是：把散在各處的 App 相關票收攏、定義規格、排順序。

leo 的願景（原話，規格依此為準）

「iOS 做 App，Google 做 Web，而 Arcrun 幫 CF 做了一個類似的 App 系統，
未來可能有一個像 iPhone 那樣的九宮格畫面，點進去寫筆記、點進去看 Kanban，背後都運行在 CF。
你可以從別人那裡或 Market 安裝，也可以叫你的 AI 立刻幫你開發一個。
所以他的 App 如何跟整個 Arcrun 系統連上，這是規格。
Arcrun 建在 CF 上，就像 Android 建立在 Linux 上，而 Android 提供了大量規格讓 App 可以接入。」

順序（leo 2026-08-13 定，D78）

1. Mira 同步搞定          ← 現在在做
2. App 規格定案（本票）    ← 什麼是 App／怎麼打包／前端怎麼掛 Portal
3. 各個 App                ← Kanban、筆記、GUI、…

🔴 第 3 段的票在第 2 段定案前不准動工。 先做＝手工做一個，框架出來還要重做，
而 leo 要的正是「以後可以快速產生新的 App」。
（2026-08-13 已犯過一次：總管把 Leo/InkStoneCo#18 派了出去，leo 當場喊停。）

收攏的票（第 3 段的候選 App／相關能力）

票	它其實是什麼	屬第幾段
`Leo/Arcrun#82`	裝一個 App 就多一個功能——現在每加一個能力都要改 Portal 程式碼	2（核心，本票的主體）
`Leo/Arcrun#69`	artifact-sharing（bundle／譜系／訂閱／多源／channel）	2（＝Market 的地基）
`Leo/InkStoneCo#18`	票 Kanban 背後跑 Arcrun	3
`Leo/InkStoneCo#19`	low-code 用戶要看得到零件／recipe／工作流的 GUI	3
`Leo/InkStoneCo#2` ＋ `Leo/arcrun-rag#36`	手機寫筆記（leo 講的「手機河道筆記」＝第三個 ingest 來源）	3
`Leo/mira#5`	leo21c 舊 workflow 17 支逐支重做	3（其中一部分該變成 App，不是逐支搬）

📌 這張表是候選，不是定案。第 2 段定案時要逐張確認「它到底是不是一個 App」。

總管的提案（待 leo 裁；未經核實的部分已標明）

一、叫 App，不要叫 Plugin

因為 Arcrun 已經有 plugin 那一層了，只是叫別的名字。

	做什麼	Arcrun 現有的對應
Plugin（WP／CC plugin 那種）	擴充宿主的能力，沒有自己的門面	零件（component）／recipe
App（iOS 那種）	有自己的門面：自己的入口、自己的畫面、自己的資料	❌ 不存在，這就是缺口

leo 描述的是九宮格、點進去、各有各的畫面 ⇒ 那是 App。
叫它 Plugin 會讓人以為是「改 Portal 的行為」，而不是「多一格自己的東西」。

📌 對外命名的另一個理由：對非開發者，「App」是他們已經會的心智模型；
「Plugin」需要先解釋宿主是什麼。leo 要賣的是前者。

二、Android 的類比可以借它的具體規格，不只是比喻

Android 給 App 的接入面大致六件。逐項對到 Arcrun：

Android	Arcrun App 要的	我推測的現況 ⚠️
APK（打包格式）	一個可安裝的 App 包	有出貨/bundle 機制，但只服務「整套系統」，不服務「一個 App」
Manifest（宣告身分/權限/入口）	App 宣告檔	❌ 推測沒有——這是最關鍵的缺口
Activity（畫面入口）	Portal 側欄／九宮格的一格＋一個前端頁面	掛載點 leo 已裁＝側欄（D63）
Intent（App 互叫）	一個 App 觸發另一個 App 的工作流	工作流觸發機制已有
ContentProvider（資料互通）	別的 App 查得到我的資料	KBDB 本來就是共用資料層 ✅
Permissions（用戶授權）	這個 App 能讀哪些庫、能用哪把金鑰	credential 中心＋庫過濾已有
Store	Market	`recipe_search`／`push`／`pull` 疑似雛形

⚠️ 右欄是總管的推測，正在派人核實（哪些是真的有、哪些是半套、哪些根本沒有）。
核實結果會補到本票，不要拿現在這欄當事實用。

⇒ 如果核實結果接近推測，那麼Arcrun 已經有一大半，
真正缺的是三件：① App 宣告檔 ② 前端掛載 ③ 分發。

三、一個 App 的實體是什麼（這題最需要 leo 拍板）

三個候選：

	是什麼	代價
A. 一顆自己的 Worker	每個 App 部署一顆	重；每裝一個 App 就要 CF 部署權限與資源；一般用戶裝不動
B. 註冊到既有 runtime	App ＝宣告＋一組工作流（邏輯）＋一組畫面（前端）＋要的權限與資料型別	輕；裝 App 不部署新 worker，只是註冊
C. 混合	預設 B，需要時才 A	兩套規格，複雜度加倍

總管建議 B，三個理由：

Leo/Arcrun#82 的病本來就是「每加一個能力都要改 Portal 程式碼」——
A 只是把「改 Portal」換成「部署 worker」，用戶要付的代價沒有變小。
leo 要「叫你的 AI 立刻幫你開發一個」。
⇒ 那表示 App 必須是 AI 寫得出來的東西：宣告式、可驗證、不必編譯。
一顆 Worker 不是；一份宣告＋幾支工作流是。
⇒ 這也正好接上 Arcrun 既有的「意圖工作流」設計（D70：我們自己的事也要用 Arcrun 做）。
B 讓 Market 變得可能：分發一份宣告，比分發一顆要部署的 worker 容易一個數量級。

🔴 B 的已知代價，先講清楚不要之後才發現：
App 的邏輯全部要用工作流表達。工作流表達不了的東西，這個 App 就做不出來
⇒ 於是「缺什麼零件」會變成 App 生態的天花板。
這不是反對 B，是說選 B 就等於承諾要持續補零件（Leo/Arcrun#89／#90／#91 那類的票會一直長）。

這張票要交出什麼才算完成

一份規格文件，能回答 leo 問的那三題：

什麼是 App（邊界：什麼算、什麼只是零件／工作流）
如何打包一個 App（宣告檔長什麼樣、包含哪些東西、怎麼裝、怎麼移除、怎麼升級）
前端如何跟現有 Portal 掛上（不改 Portal 原始碼就能多一格）

＋一個跑得起來的第一個 App當驗收（建議拿 Leo/InkStoneCo#18 Kanban 當它，
因為 leo 現在就痛，且它的資料源單純）。

🔴 驗收只認用戶走的那條路：leo 打開 Portal，看到那一格，點進去有東西。
不是「規格寫完了」。

📌 本票由總管 2026-08-13 依 leo 指示建立。規格層變更走 pending-changes.md 提案後等 confirm。
（署名：總管）

> **這是一張 hub 票**（leo 2026-08-13：「如果很多票講到它，你建一張 hub 票，把這些票收在一起，才能一併做」）。 > 它不是執行票，**不要在這裡寫 code**。它的職責是：把散在各處的 App 相關票收攏、定義規格、排順序。 ## leo 的願景（原話，規格依此為準） > 「**iOS 做 App，Google 做 Web，而 Arcrun 幫 CF 做了一個類似的 App 系統**， > 未來可能有一個**像 iPhone 那樣的九宮格畫面**，點進去寫筆記、點進去看 Kanban，背後都運行在 CF。 > **你可以從別人那裡或 Market 安裝，也可以叫你的 AI 立刻幫你開發一個。** > 所以他的 App 如何跟整個 Arcrun 系統連上，這是規格。 > **Arcrun 建在 CF 上，就像 Android 建立在 Linux 上**，而 Android 提供了大量規格讓 App 可以接入。」 ## 順序（leo 2026-08-13 定，D78） ``` 1. Mira 同步搞定 ← 現在在做 2. App 規格定案（本票） ← 什麼是 App／怎麼打包／前端怎麼掛 Portal 3. 各個 App ← Kanban、筆記、GUI、… ``` 🔴 **第 3 段的票在第 2 段定案前不准動工。** 先做＝手工做一個，框架出來還要重做，而 leo 要的正是「以後可以**快速**產生新的 App」。（2026-08-13 已犯過一次：總管把 `Leo/InkStoneCo#18` 派了出去，leo 當場喊停。） --- ## 收攏的票（第 3 段的候選 App／相關能力） | 票 | 它其實是什麼 | 屬第幾段 | |---|---|---| | `Leo/Arcrun#82` | 裝一個 App 就多一個功能——現在每加一個能力都要改 Portal 程式碼 | **2（核心，本票的主體）** | | `Leo/Arcrun#69` | artifact-sharing（bundle／譜系／訂閱／多源／channel） | **2**（＝Market 的地基） | | `Leo/InkStoneCo#18` | 票 Kanban 背後跑 Arcrun | 3 | | `Leo/InkStoneCo#19` | low-code 用戶要看得到零件／recipe／工作流的 GUI | 3 | | `Leo/InkStoneCo#2` ＋ `Leo/arcrun-rag#36` | 手機寫筆記（leo 講的「手機河道筆記」＝第三個 ingest 來源） | 3 | | `Leo/mira#5` | leo21c 舊 workflow 17 支逐支重做 | 3（其中一部分該變成 App，不是逐支搬） | 📌 這張表是**候選**，不是定案。第 2 段定案時要逐張確認「它到底是不是一個 App」。 --- ## 總管的提案（待 leo 裁；未經核實的部分已標明） ### 一、叫 App，不要叫 Plugin **因為 Arcrun 已經有 plugin 那一層了，只是叫別的名字。** | | 做什麼 | Arcrun 現有的對應 | |---|---|---| | **Plugin**（WP／CC plugin 那種） | **擴充宿主的能力**，沒有自己的門面 | **零件（component）／recipe** | | **App**（iOS 那種） | **有自己的門面**：自己的入口、自己的畫面、自己的資料 | ❌ **不存在，這就是缺口** | leo 描述的是九宮格、點進去、各有各的畫面 ⇒ 那是 **App**。叫它 Plugin 會讓人以為是「改 Portal 的行為」，而不是「多一格自己的東西」。 > 📌 **對外命名的另一個理由**：對非開發者，「App」是他們**已經會的心智模型**； > 「Plugin」需要先解釋宿主是什麼。leo 要賣的是前者。 ### 二、Android 的類比可以借它的**具體規格**，不只是比喻 Android 給 App 的接入面大致六件。逐項對到 Arcrun： | Android | Arcrun App 要的 | 我推測的現況 ⚠️ | |---|---|---| | APK（打包格式） | 一個可安裝的 App 包 | 有出貨/bundle 機制，但只服務「整套系統」，不服務「一個 App」 | | **Manifest**（宣告身分/權限/入口） | **App 宣告檔** | ❌ **推測沒有——這是最關鍵的缺口** | | Activity（畫面入口） | Portal 側欄／九宮格的一格＋一個前端頁面 | 掛載點 leo 已裁＝側欄（D63） | | Intent（App 互叫） | 一個 App 觸發另一個 App 的工作流 | 工作流觸發機制已有 | | ContentProvider（資料互通） | 別的 App 查得到我的資料 | **KBDB 本來就是共用資料層** ✅ | | Permissions（用戶授權） | 這個 App 能讀哪些庫、能用哪把金鑰 | credential 中心＋庫過濾已有 | | Store | Market | `recipe_search`／`push`／`pull` 疑似雛形 | ⚠️ **右欄是總管的推測，正在派人核實**（哪些是真的有、哪些是半套、哪些根本沒有）。核實結果會補到本票，**不要拿現在這欄當事實用**。 ⇒ 如果核實結果接近推測，那麼**Arcrun 已經有一大半**，真正缺的是三件：**① App 宣告檔 ② 前端掛載 ③ 分發**。 ### 三、一個 App 的實體是什麼（這題最需要 leo 拍板）三個候選： | | 是什麼 | 代價 | |---|---|---| | **A. 一顆自己的 Worker** | 每個 App 部署一顆 | 重；每裝一個 App 就要 CF 部署權限與資源；一般用戶裝不動 | | **B. 註冊到既有 runtime** | App ＝ **宣告＋一組工作流（邏輯）＋一組畫面（前端）＋要的權限與資料型別** | 輕；裝 App 不部署新 worker，只是註冊 | | C. 混合 | 預設 B，需要時才 A | 兩套規格，複雜度加倍 | **總管建議 B**，三個理由： 1. `Leo/Arcrun#82` 的病本來就是「**每加一個能力都要改 Portal 程式碼**」—— A 只是把「改 Portal」換成「部署 worker」，**用戶要付的代價沒有變小**。 2. leo 要「**叫你的 AI 立刻幫你開發一個**」。 ⇒ 那表示 App 必須是 **AI 寫得出來的東西**：宣告式、可驗證、不必編譯。一顆 Worker 不是；一份宣告＋幾支工作流是。 ⇒ 這也正好接上 Arcrun 既有的「意圖工作流」設計（D70：我們自己的事也要用 Arcrun 做）。 3. B 讓 Market 變得可能：**分發一份宣告，比分發一顆要部署的 worker 容易一個數量級**。 🔴 **B 的已知代價，先講清楚不要之後才發現**： App 的邏輯全部要用工作流表達。**工作流表達不了的東西，這個 App 就做不出來** ⇒ 於是「缺什麼零件」會變成 App 生態的天花板。這不是反對 B，是說**選 B 就等於承諾要持續補零件**（`Leo/Arcrun#89`／`#90`／`#91` 那類的票會一直長）。 --- ## 這張票要交出什麼才算完成一份規格文件，能回答 leo 問的那三題： 1. **什麼是 App**（邊界：什麼算、什麼只是零件／工作流） 2. **如何打包一個 App**（宣告檔長什麼樣、包含哪些東西、怎麼裝、怎麼移除、怎麼升級） 3. **前端如何跟現有 Portal 掛上**（不改 Portal 原始碼就能多一格）＋一個**跑得起來的第一個 App**當驗收（建議拿 `Leo/InkStoneCo#18` Kanban 當它，因為 leo 現在就痛，且它的資料源單純）。 🔴 **驗收只認用戶走的那條路**：leo 打開 Portal，看到那一格，點進去有東西。不是「規格寫完了」。 --- 📌 本票由總管 2026-08-13 依 leo 指示建立。規格層變更走 `pending-changes.md` 提案後等 confirm。（署名：總管）

Leo commented

2026-08-13 03:28:48 +00:00

✅ 現況核實報告（取代票上那張標著「總管推測」的表）

由總管派出的偵察 agent 逐條讀原始碼核實，每題附檔案路徑＋行號。
⚠️ 它的 MCP 是舊 token（identity_missing），查不到雲端即時資料，
全部結論來自原始碼直讀，不是線上實測。

一句話：七題核實下來，總管推測的方向大致對，但「已經有」的比想像中少一層

題	總管推測	核實結果
前端掛載點	「掛載點已裁＝側欄」	沒有，連雛形都沒有——D63 只是裁決不是實作
宣告檔	沒有	半套：零件/recipe 各有，但都沒有 icon／入口／UI 掛載
分發（Market）	「recipe 那組疑似雛形」	半套：recipe 市集是真的、能用（有 UUID 身分、多作者並存、市場信任數據）；但顆粒度停在「單一 API」，裝不了一整包
權限	已有	有，而且比預期成熟（經兩次事故加固）⇒ App 不必新造
App 互叫	已有	半套：借 `http_request` 打自己的 webhook（正式產線在用），沒有一等公民的節點
資料	KBDB 就是那個角色	對，而且是唯一被允許的資料落點 ⇒ 不用發明新東西
Worker vs runtime	—	兩條路都在；不部署新 worker 也能加功能今天就存在（工作流）

🔴 它抓到總管提案的兩個缺陷（這段比報告本文更值錢）

缺陷一：「已經設計」被讀成「已經存在」

Leo/Arcrun#82 的協定草案寫得非常具體（連 Portal 要改哪 5 處、改幾行都寫了），
讀起來很像快做完了。但核實下來：

portal.ts        沒有 apps key
index.html       沒有 mountApp
portal-seeds.ts  沒有 arcrun_app seed
cli/src/commands 沒有 app.ts

一行 code 都還沒落地，而且還沒經 leo 拍板、也還沒開 SDD。

⇒ 與 Leo/Arcrun#69（App＝bundle）已 confirmed 但 0/33 沒動工是同一種風險：
🔴 「confirmed」不等於「在做」。

缺陷二：「App」這個詞現在疊了兩個互相獨立的裁決，總管把它們寫成一件事了

層	管什麼	出處	進度
分發層 App＝bundle	怎麼分發、怎麼裝、相依	D37／D38／`Leo/Arcrun#69`	已 confirm，規格 draft、0/33
掛載層 App＝Portal 一格	UI 長在哪	D63／`Leo/Arcrun#82`	連 SDD 都還沒開，只在票的留言區

⇒ 兩條線、兩份文件、兩種進度。寫成一件事會讓人以為「裝了就會自動長出畫面」已經有一半在跑
（因為 D37 confirmed 了）——實際上兩層要各自補完，還要互相對接。
system-dev/docs/1-vision/20260803-mira-as-arcrun-app.md:121-124 自己列的三個對接缺口正是：
UI 資產怎麼跟著 bundle 走／版本相依／卸載。

📌 總管接受這兩點，本票上方那張表已標為作廢，以本則為準。

🎯 對「App 的實體選 A 還是 B」的影響——核實結果強化了 B

兩條新證據：

不部署新 worker 也能加功能的路徑今天就存在（工作流：一份 YAML，POST /webhooks/named 存進 KV，
正式產線的 rag_extract／rag_extract_one 就是這樣加出來的）。
🔴 B 其實不是新提案，是既有設計方向——20260803-mira-as-arcrun-app.md:108,117
（2026-08-03，早於 #82 六天）已經寫著：

「App 就是一種 bundle，多帶一個 ui.entry」，安裝要落地四件套
templates／workflows（明文「不准自帶 worker」）／ui／capability

⇒ 總管建議 B，而系統十天前的願景文件已經寫了同一件事。
leo 只需確認要不要沿用，不是從零選。

📄 核實報告全文

Arcrun App 規格提案——現況核實報告

核實時間：2026-08-13。範圍：matrix/arcrun（引擎/Portal 原始碼）、products/arcrun-rag（安裝器/bundle）、system-dev/docs/issues-log/Leo-Arcrun-82.md（含 2026-08-09 的協定提案留言）、system-dev/wiki/decisions-summary.md（D63）、system-dev/docs/3-specs/pending-changes.md、system-dev/docs/3-specs/arcrun/artifact-sharing/（tasks.md 進度）、system-dev/docs/1-vision/20260803-mira-as-arcrun-app.md。MCP 的 arcrun_*/kbdb_* 工具本次連線是舊版 token（identity_missing），查不到雲端即時資料，全部結論改用原始碼直讀核實，逐條附路徑＋行號。

1. 前端掛載點——沒有

現在要新增一個 Portal 頁面，實際要改的檔案只有一個：matrix/arcrun/console-ui/public/portal/index.html（單檔 HTML/CSS/JS，目前 2279 行），而且同一個「有哪些頁」的事實要在裡面寫四遍：

側欄項：:287-295（<div id="sidenav"> 內逐條 <div class="nav" data-nav="...">）
手機底部 tab：:550-556（<div id="tabbar">，同一組項目再寫一遍）
路由表：VIEWS（:758）
顯示判斷：allowedViews()／LOADERS（:787）

GET /portal/session 是前端拿「這個帳號能看什麼」的唯一入口（cypher-executor/src/routes/portal.ts:723-736），我直接讀了它現在回什麼欄位：

{ valid, display_name, email, role, libraries, graph_allowed, workflows_visible, upload_enabled }

沒有 apps 這個 key——也就是「宣告一個東西就讓 Portal 動態長出一格」這條路，今天完全不存在，連雛形都沒有。

安裝器（products/arcrun-rag/installer/oauth-prototype/worker.js）對 UI 做的事是「整顆 worker 換掉」（build-ui-bundle.mjs 把整個 console-ui/public/ 內嵌成單檔 worker arcrun-rag-ui）；我 grep 了整個安裝器樹的 mount／slot／menu／tab，沒有任何一處是「UI 註冊」語意，全是安裝器自己那幾頁 HTML 裡的字面命中。

結論：leo 已裁的「掛載點＝側欄」（D63，system-dev/wiki/decisions-summary.md:1042-1054）目前只是裁決，不是實作——側欄長什麼樣是裁決的對象，不是已經存在的插槽。你的推測「不改 Portal 就能多一格」的機制現在沒有，一格都沒有。

2. 宣告檔——半套：零件與 recipe 各自都有，但都不是「App」的形狀

今天 Arcrun 裡「描述一個可安裝單位」的宣告檔有兩種，我各讀了一份實例：

零件（component）：matrix/arcrun/registry/components/http_request/component.contract.yaml
欄位＝canonical_id／display_name／category／version／stability／input_schema／output_schema／gherkin_tests／tags／description。沒有 icon、沒有 UI 掛載點、沒有「入口」概念——它描述的是一個純函式合約，不是一個裝上去會冒出畫面的東西。
recipe：matrix/arcrun/cypher-executor/src/routes/recipes.ts:23-73（RecipeDefinition）
欄位＝uuid／author／canonical_id／endpoint／method／headers／body／auth／credentials_required／created_at。有版本概念（updated_at 累加、auth_recipe 有 version: number，:487-488），但一樣沒有 icon、沒有 UI 掛載。
workflow：純 graph YAML（{ name, graph, config? }，webhooks-named.ts:38-40），連 version 欄位都沒有。

沒有任何現存宣告檔帶「版本＋圖示＋入口＋UI 掛載＋要什麼權限」這一整組。#82 留言裡提的 arcrun-app.yaml（id/name/version/icon/ui.mount/data.templates/actions/workflows）是全新設計，repo 現在唯二的 JSON Schema 只有 products/arcrun-rag/schemas/collector-trigger.v1.schema.json 與 kbdb-ingest-request.v1.schema.json，都跟「可安裝單位」無關——這句話我核實過：matrix/arcrun/schemas/ 目錄不存在。

結論：你說「宣告檔」，零件與 recipe 各有一份，但都是「單一能力/單一 API 呼叫」的合約，不含「這東西要長在 UI 哪裡」。App 的宣告檔要新造。

3. 分發（recipe_search／recipe_push／recipe_pull）——半套，而且要拆成兩層看

recipe 那層（cypher-executor/src/routes/recipes.ts）確實是一個運作中的市集，證據扎實：

有 UUID 身份模型：同一 canonical_id 可以多作者並存，各自 uuid（:75-103），公庫端點 GET /public-recipes（:325-359）、GET /public-recipes/:canonical_id（:363-390）依 success_count 選市場最佳版（:379-388）
有市場信任數據（fetchMarketStat，:291-310，讀真實使用累積的 recipe-stats，不採信投稿者自報數）
有「查無則引導創作」的落空體驗（:338-345）

但它只能分發「一支 API 呼叫的封裝」——沒有「相依」概念（一個 recipe 不能宣告依賴另一個 recipe/template）、沒有版本相容區間（只有 updated_at 時間戳）、更不能分發前端／template／多個 workflow 綁一起這種「App」需要的複合單位。

bundle 這層才是真正對應「一整包東西」的分發機制，但它是另一條、幾乎沒動工的線：system-dev/docs/3-specs/arcrun/artifact-sharing/design.md frontmatter status: draft（不是 active），tasks.md 33 條任務全部 [ ]，0 條打勾。雖然 D37/D38（decisions-summary.md:244）已經把「App＝bundle 第四型」定案、leo 也在 Leo/Arcrun#69 confirmed 過（pending-changes.md 該提案已移入「已裁決」），但規格是草稿、程式碼是零——這是「已核准的藍圖」，不是「現成的市集」。

結論：recipe 市集是真的、能用，但分發顆粒度停在「單一 API」；能裝「一整包（前端＋template＋workflow）」的 bundle/App 分發機制已設計、未實作（0/33）。

4. 權限——有，而且比我預期成熟

三塊都有實作，不是空話：

Credential：D19「擁有目錄，不擁有內容物」——密文進 CF Workers per-script Secrets，目錄（api_key/name/service/secret_ref）走 KBDB entries 表存（matrix/arcrun/cypher-executor/src/routes/credentials.ts:1-30），arcrun 自己讀不回明文。auth_recipe 用 required_secrets: SecretRequirement[]（recipes.ts:464-471）宣告一個 recipe 要哪些 credential，help_url 強制必填（:531-540），還有 AuthInjectSpec（:473-482）決定怎麼把秘密塞進 header/query/body/path。
庫（library）過濾：portal-data.ts 的 canReadLibrary()（:124-125）＋每個查詢強制注入 owner_id／library，caller 自帶的同名參數一律忽略（:9-12）。
Namespace（租戶）：.claude/rules/02-forbidden.md 第六類明訂「知識資料面的 owner_id 必須與寫入端同源」，唯一產地是 cypher-executor/src/lib/tenant.ts，且有機械出貨閘擋（scripts/build-worker-artifacts.mjs）與自測（npm run check:tenant）——這條是 2026-08 因 Arcrun#108／#105 真的踩雷才補的，不是紙上規範。

結論：一個東西「要讀某個庫、要用某把金鑰」的宣告與授權路徑今天就有，而且經過至少兩次事故加固。App 若走既有 /portal/data/* 與 credentials_required 這套，權限這塊不需要新造。

5. App 之間互叫——半套：做得到，但沒有專屬節點

production 裡真的在用：products/arcrun-rag/workflows/rag-extract.local.yaml 的 dispatch 節點（:71-78）用 http_request 打 POST {cypher}/webhooks/named/{ns}/rag_extract_one/trigger，帶 X-Arcrun-API-Key，把工作交給另一支 workflow rag_extract_one 執行——這是「dispatcher＋one」兩段式，system-dev/docs/issues-log/Leo-Arcrun-64.md 與 agent-memory-archive-2026-08.md:685 都記過這個模式的坑（foreach 內 code 輸出餵給這種呼叫時模板不展開）。

但沒有專屬的「呼叫另一個 workflow」節點類型。我 grep 了 trigger_workflow 這個詞：它只出現在 matrix/arcrun/registry/examples/（範例/心願級）與多份文件裡被明確標注「未註冊，會 validate 失敗」（system-dev/docs/3-specs/autonomy-dispatch/gate-workflow/README.md:53、Leo-InkStoneCo-1.md:17）。registry/components/ 底下 20 個真實零件裡沒有 trigger_workflow 這一個。

結論：能力上今天就能做（http_request 直打 trigger 端點，已在正式產線跑），但這是「借用 http_request 打自己的 webhook」，不是一等公民的「呼叫別的 App/workflow」原語。App 要互叫的話，正解路徑存在，但要靠 App 自己的 workflow 拿到對方的 webhooks/named/trigger URL＋API key（也就是要碰 tenant 金鑰）。

6. 資料——有，且已經是為此設計的

KBDB 走「萬用表」模型（blocks/templates/slots 三張核心表，.claude/rules 全樹反覆強調「零新表」鐵律），新資料型別＝ seed 一列 template：

種子宣告位置：matrix/arcrun/cypher-executor/src/lib/portal-seeds.ts:21（PORTAL_TEMPLATE_SEEDS），目前已有 portal_user（:25）／portal_library（:35）／triplet（:45）三列
冪等建立走 POST /kbdb/templates（cypher-executor/src/routes/kbdb-proxy.ts），由 /init/seed 或 /portal/admin/bootstrap 呼叫
我核實過一個反面教材：credential 的目錄以前多開了一張獨立 D1 表（0002_credentials.sql），2026-08-07 被 leo 點名「任何東西禁止用 SQL 語句存取資料，一律 API」後，已經改走 KBDB 三張核心表（credentials.ts:18-23）——連系統自己都在把違規表收斂回這套機制。

結論：你的推測是對的。KBDB template 機制現在就在扮演「開放給別人查的資料層」這個角色，且是全系統唯一被允許的資料落點（API-as-Wall，零 SQL）。App 若要存自己的資料，正解已經鋪好，不用發明新東西。

7. 新 Worker vs 掛在既有 runtime——看層級，各有一半

要新增一個零件（component）＝一定要新 Worker：.claude/rules/05-deploy-convention.md 明講「新增 Worker = 新目錄 + wrangler.toml，不用改 workflow」，CI 用 find . -name 'wrangler.toml' 掃描式部署（:8-18），每個零件都是獨立 Worker，有對內／對外兩個 URL（.claude/rules/03-component-architecture.md）。這條路確定要部署新 worker。
但今天實務上加新能力的預設路徑是「寫工作流」，不是「建零件」：.claude/rules/06-mindset.md §1 明文「AI 開發時的預設順序：1. 預設寫工作流……2. 要有必要讓全 arcrun 生態重用才建零件」。工作流只是一份 YAML，POST /webhooks/named 存進 KV（webhooks-named.ts:1-22），完全不必部署任何 worker——rag_extract／rag_extract_one 這類正式產線的能力就是這樣加出來的。

結論：這題答案是「兩條路都在，且各司其職」——不部署新 worker 也能加功能的路徑今天就存在（工作流，用既有零件/recipe 組），但它產出的是「後端能力」；一旦要新的基礎積木（零件）或要在 Portal 露出畫面，都必須新增部署單位（前者新 worker，後者今天是改 Portal 單檔）。App 協定要解的正是後面這條「露出畫面」的路。

額外一題：零件／recipe 跟 leo 要的「App」是不是同一層

不是同一層，你的直覺是對的，而且系統自己的文件已經在區分這件事，證據比我預期更明確：

system-dev/docs/1-vision/20260803-mira-as-arcrun-app.md（2026-08-03，早於 #82 六天）已經寫「App 就是一種 bundle，多帶一個 ui.entry」（:108），並列出 App 安裝要落地四件套：templates／workflows（明文「不准自帶 worker」，:117）／ui／capability（:115-119）——這正是「零件＝積木、recipe＝單一 API 封裝、workflow＝組裝出的能力，App＝把一組這樣的能力＋前端＋資料契約打包成一個有身份、能裝卸的產品面」的三層結構。
D37（decisions-summary.md:244）把 App 定義在「bundle」這個分發層（第四種可分發物：workflow/recipe/template 之上），#82 的協定又補了 App 的掛載層（Portal 側欄一格）。兩份文件合起來看，App 是零件/recipe/workflow 的上層聚合＋門面，不是它們的同義詞或平行概念——這與你的判斷（零件/recipe 是「擴充能力」類似 plugin，App 是「有自己門面」的上一層）完全吻合。

我唯一想幫你補強的一點：目前「App」這個詞在系統裡實際上疊了兩個互相獨立的裁決——「App＝bundle」（分發/相依，D37/D38/#69）和「App＝Portal 掛載」（門面，D63/#82）——這兩者 confirmed 的時間點與作者不同、進度也不同（前者規格 draft、0/33；後者連規格都還在票的留言區，SDD 都還沒開）。寫提案時建議明確講清楚你指的是哪一層，或乾脆點名「這兩層現在是分開發展、還沒收斂成一份 SDD」，否則讀的人容易把「D37 已 confirmed」誤讀成「App 機制已經在做」。

你的提案最可能錯在哪

我認為風險不在你對「現況」的判斷（你的推測方向其實相當準——recipe 市集、credential、KBDB 這三塊你猜「已經有一半」是對的），而在兩個容易被讀者忽略的落差：

「已經設計」與「已經存在」之間的距離，比看起來近。#82 那則留言把「協定 v0」寫得非常具體（連 Portal 要改哪 5 處、改幾行都寫了），語感上很像「快做完了」，但我核實下來：portal.ts 沒有 apps key、index.html 沒有 mountApp、portal-seeds.ts 沒有 arcrun_app seed、cli/src/commands/ 沒有 app.ts——一行代碼都还没有落地，而且 D35 生命週期鐵律要求先走 pending-changes.md confirm 才能開 SDD，那個 confirm 現在也還沒發生（#82 票上只留了「等 leo 裁的兩題」）。如果提案給 leo 的印象是「協定都設計好了，接下來就是照做」，容易低估「這是一份還沒被 leo 拍板、也還沒開 SDD 的草案」這個事實，跟 D37（bundle）那條已經 confirmed 但 0/33 沒動工是同一種風險——「confirmed」不等於「在做」。
兩個 App 定義並存，容易在文字裡悄悄合流。如你所見，D37/#69（App=bundle，管「怎麼分發、怎麼裝」）與 #82（App=Portal 掛載，管「UI 長在哪」）目前是兩條線、兩份文件、兩種進度。你的提案若把它們當一件事描述，會讓 leo 誤以為「裝了就會自動長出畫面」這條路已經有一半基礎在跑（因為 D37 confirmed 了）——但實際上分發層和掛載層要各自補完、還要互相對接（mira-as-arcrun-app.md:121-124 自己列的「三個新問題」正是這個對接缺口：UI 資產怎麼跟著 bundle 走、版本相依、卸載）。建議提案裡把這兩層分開畫，並清楚標「目前都是草案／未 confirm，不是現成能力」。

## ✅ 現況核實報告（取代票上那張標著「總管推測」的表） > 由總管派出的偵察 agent 逐條讀原始碼核實，**每題附檔案路徑＋行號**。 > ⚠️ 它的 MCP 是舊 token（`identity_missing`），查不到雲端即時資料， > **全部結論來自原始碼直讀**，不是線上實測。 ### 一句話：**七題核實下來，總管推測的方向大致對，但「已經有」的比想像中少一層** | 題 | 總管推測 | **核實結果** | |---|---|---| | 前端掛載點 | 「掛載點已裁＝側欄」 | **沒有，連雛形都沒有**——D63 只是裁決不是實作 | | 宣告檔 | 沒有 | **半套**：零件/recipe 各有，但都沒有 icon／入口／UI 掛載 | | 分發（Market） | 「recipe 那組疑似雛形」 | **半套**：recipe 市集是**真的、能用**（有 UUID 身分、多作者並存、市場信任數據）；但顆粒度停在「單一 API」，裝不了一整包 | | 權限 | 已有 | **有，而且比預期成熟**（經兩次事故加固）⇒ **App 不必新造** | | App 互叫 | 已有 | **半套**：借 `http_request` 打自己的 webhook（正式產線在用），**沒有一等公民的節點** | | 資料 | KBDB 就是那個角色 | **對，而且是唯一被允許的資料落點** ⇒ 不用發明新東西 | | Worker vs runtime | — | **兩條路都在**；**不部署新 worker 也能加功能今天就存在**（工作流） | --- ## 🔴 它抓到總管提案的兩個缺陷（這段比報告本文更值錢） ### 缺陷一：「已經設計」被讀成「已經存在」 `Leo/Arcrun#82` 的協定草案寫得非常具體（連 Portal 要改哪 5 處、改幾行都寫了）， **讀起來很像快做完了**。但核實下來： ``` portal.ts 沒有 apps key index.html 沒有 mountApp portal-seeds.ts 沒有 arcrun_app seed cli/src/commands 沒有 app.ts ``` **一行 code 都還沒落地**，而且**還沒經 leo 拍板、也還沒開 SDD**。 ⇒ 與 `Leo/Arcrun#69`（App＝bundle）**已 confirmed 但 0/33 沒動工**是同一種風險： 🔴 **「confirmed」不等於「在做」。** ### 缺陷二：**「App」這個詞現在疊了兩個互相獨立的裁決**，總管把它們寫成一件事了 | 層 | 管什麼 | 出處 | 進度 | |---|---|---|---| | **分發層** App＝bundle | 怎麼分發、怎麼裝、相依 | D37／D38／`Leo/Arcrun#69` | 已 confirm，**規格 draft、0/33** | | **掛載層** App＝Portal 一格 | UI 長在哪 | D63／`Leo/Arcrun#82` | **連 SDD 都還沒開**，只在票的留言區 | ⇒ 兩條線、兩份文件、兩種進度。**寫成一件事會讓人以為「裝了就會自動長出畫面」已經有一半在跑** （因為 D37 confirmed 了）——實際上兩層要各自補完，**還要互相對接**。 `system-dev/docs/1-vision/20260803-mira-as-arcrun-app.md:121-124` 自己列的三個對接缺口正是： **UI 資產怎麼跟著 bundle 走／版本相依／卸載。** 📌 **總管接受這兩點，本票上方那張表已標為作廢，以本則為準。** --- ## 🎯 對「App 的實體選 A 還是 B」的影響——**核實結果強化了 B** 兩條新證據： 1. **不部署新 worker 也能加功能的路徑今天就存在**（工作流：一份 YAML，`POST /webhooks/named` 存進 KV，正式產線的 `rag_extract`／`rag_extract_one` 就是這樣加出來的）。 2. 🔴 **B 其實不是新提案，是既有設計方向**——`20260803-mira-as-arcrun-app.md:108,117` （2026-08-03，早於 `#82` 六天）已經寫著： > 「**App 就是一種 bundle，多帶一個 `ui.entry`**」，安裝要落地四件套 > `templates`／`workflows`（**明文「不准自帶 worker」**）／`ui`／`capability` ⇒ **總管建議 B，而系統十天前的願景文件已經寫了同一件事。** leo 只需確認要不要沿用，不是從零選。 --- # 📄 核實報告全文 # Arcrun App 規格提案——現況核實報告 > 核實時間：2026-08-13。範圍：`matrix/arcrun`（引擎/Portal 原始碼）、`products/arcrun-rag`（安裝器/bundle）、`system-dev/docs/issues-log/Leo-Arcrun-82.md`（含 2026-08-09 的協定提案留言）、`system-dev/wiki/decisions-summary.md`（D63）、`system-dev/docs/3-specs/pending-changes.md`、`system-dev/docs/3-specs/arcrun/artifact-sharing/`（tasks.md 進度）、`system-dev/docs/1-vision/20260803-mira-as-arcrun-app.md`。MCP 的 `arcrun_*`/`kbdb_*` 工具本次連線是舊版 token（`identity_missing`），查不到雲端即時資料，全部結論改用原始碼直讀核實，逐條附路徑＋行號。 --- ## 1. 前端掛載點——**沒有** 現在要新增一個 Portal 頁面，實際要改的檔案只有一個：**`matrix/arcrun/console-ui/public/portal/index.html`**（單檔 HTML/CSS/JS，目前 2279 行），而且同一個「有哪些頁」的事實要在裡面**寫四遍**： - 側欄項：`:287-295`（`<div id="sidenav">` 內逐條 `<div class="nav" data-nav="...">`） - 手機底部 tab：`:550-556`（`<div id="tabbar">`，同一組項目再寫一遍） - 路由表：`VIEWS`（`:758`） - 顯示判斷：`allowedViews()`／`LOADERS`（`:787`） `GET /portal/session` 是前端拿「這個帳號能看什麼」的唯一入口（`cypher-executor/src/routes/portal.ts:723-736`），我直接讀了它現在回什麼欄位： ``` { valid, display_name, email, role, libraries, graph_allowed, workflows_visible, upload_enabled } ``` **沒有 `apps` 這個 key**——也就是「宣告一個東西就讓 Portal 動態長出一格」這條路，今天完全不存在，連雛形都沒有。安裝器（`products/arcrun-rag/installer/oauth-prototype/worker.js`）對 UI 做的事是「整顆 worker 換掉」（`build-ui-bundle.mjs` 把整個 `console-ui/public/` 內嵌成單檔 worker `arcrun-rag-ui`）；我 grep 了整個安裝器樹的 `mount`／`slot`／`menu`／`tab`，**沒有任何一處是「UI 註冊」語意**，全是安裝器自己那幾頁 HTML 裡的字面命中。 **結論**：leo 已裁的「掛載點＝側欄」（D63，`system-dev/wiki/decisions-summary.md:1042-1054`）目前只是**裁決**，不是**實作**——側欄長什麼樣是裁決的對象，不是已經存在的插槽。你的推測「不改 Portal 就能多一格」的機制**現在沒有**，一格都沒有。 --- ## 2. 宣告檔——**半套：零件與 recipe 各自都有，但都不是「App」的形狀** 今天 Arcrun 裡「描述一個可安裝單位」的宣告檔有兩種，我各讀了一份實例： - **零件（component）**：`matrix/arcrun/registry/components/http_request/component.contract.yaml` 欄位＝`canonical_id`／`display_name`／`category`／`version`／`stability`／`input_schema`／`output_schema`／`gherkin_tests`／`tags`／`description`。**沒有 icon、沒有 UI 掛載點、沒有「入口」概念**——它描述的是一個純函式合約，不是一個裝上去會冒出畫面的東西。 - **recipe**：`matrix/arcrun/cypher-executor/src/routes/recipes.ts:23-73`（`RecipeDefinition`）欄位＝`uuid`／`author`／`canonical_id`／`endpoint`／`method`／`headers`／`body`／`auth`／`credentials_required`／`created_at`。有版本概念（`updated_at` 累加、`auth_recipe` 有 `version: number`，`:487-488`），**但一樣沒有 icon、沒有 UI 掛載**。 - **workflow**：純 graph YAML（`{ name, graph, config? }`，`webhooks-named.ts:38-40`），連 `version` 欄位都沒有。 **沒有任何現存宣告檔帶「版本＋圖示＋入口＋UI 掛載＋要什麼權限」這一整組**。`#82` 留言裡提的 `arcrun-app.yaml`（`id/name/version/icon/ui.mount/data.templates/actions/workflows`）是**全新設計**，repo 現在唯二的 JSON Schema 只有 `products/arcrun-rag/schemas/collector-trigger.v1.schema.json` 與 `kbdb-ingest-request.v1.schema.json`，都跟「可安裝單位」無關——這句話我核實過：`matrix/arcrun/schemas/` 目錄**不存在**。 **結論**：你說「宣告檔」，零件與 recipe 各有一份，但都是「單一能力/單一 API 呼叫」的合約，不含「這東西要長在 UI 哪裡」。App 的宣告檔要新造。 --- ## 3. 分發（recipe_search／recipe_push／recipe_pull）——**半套，而且要拆成兩層看** **recipe 那層**（`cypher-executor/src/routes/recipes.ts`）**確實是一個運作中的市集**，證據扎實： - 有 UUID 身份模型：同一 `canonical_id` 可以多作者並存，各自 uuid（`:75-103`），公庫端點 `GET /public-recipes`（`:325-359`）、`GET /public-recipes/:canonical_id`（`:363-390`）依 `success_count` 選市場最佳版（`:379-388`） - 有市場信任數據（`fetchMarketStat`，`:291-310`，讀真實使用累積的 `recipe-stats`，**不採信投稿者自報數**） - 有「查無則引導創作」的落空體驗（`:338-345`） **但它只能分發「一支 API 呼叫的封裝」**——沒有「相依」概念（一個 recipe 不能宣告依賴另一個 recipe/template）、沒有版本相容區間（只有 `updated_at` 時間戳）、更**不能分發前端／template／多個 workflow 綁一起**這種「App」需要的複合單位。 **bundle 這層**才是真正對應「一整包東西」的分發機制，但它是**另一條、幾乎沒動工的線**：`system-dev/docs/3-specs/arcrun/artifact-sharing/design.md` frontmatter `status: draft`（不是 active），`tasks.md` 33 條任務**全部 `[ ]`，0 條打勾**。雖然 D37/D38（`decisions-summary.md:244`）已經把「App＝bundle 第四型」定案、leo 也在 `Leo/Arcrun#69` confirmed 過（`pending-changes.md` 該提案已移入「已裁決」），但**規格是草稿、程式碼是零**——這是「已核准的藍圖」，不是「現成的市集」。 **結論**：recipe 市集是真的、能用，但分發顆粒度停在「單一 API」；能裝「一整包（前端＋template＋workflow）」的 bundle/App 分發機制**已設計、未實作**（0/33）。 --- ## 4. 權限——**有，而且比我預期成熟** 三塊都有實作，不是空話： - **Credential**：D19「擁有目錄，不擁有內容物」——密文進 CF Workers per-script Secrets，目錄（`api_key`/`name`/`service`/`secret_ref`）走 KBDB entries 表存（`matrix/arcrun/cypher-executor/src/routes/credentials.ts:1-30`），arcrun 自己讀不回明文。`auth_recipe` 用 `required_secrets: SecretRequirement[]`（`recipes.ts:464-471`）宣告一個 recipe 要哪些 credential，`help_url` **強制必填**（`:531-540`），還有 `AuthInjectSpec`（`:473-482`）決定怎麼把秘密塞進 header/query/body/path。 - **庫（library）過濾**：`portal-data.ts` 的 `canReadLibrary()`（`:124-125`）＋每個查詢強制注入 `owner_id`／`library`，caller 自帶的同名參數**一律忽略**（`:9-12`）。 - **Namespace（租戶）**：`.claude/rules/02-forbidden.md` 第六類明訂「知識資料面的 `owner_id` 必須與寫入端同源」，唯一產地是 `cypher-executor/src/lib/tenant.ts`，且有機械出貨閘擋（`scripts/build-worker-artifacts.mjs`）與自測（`npm run check:tenant`）——這條是 2026-08 因 `Arcrun#108`／`#105` 真的踩雷才補的，不是紙上規範。 **結論**：一個東西「要讀某個庫、要用某把金鑰」的宣告與授權路徑今天就有，而且經過至少兩次事故加固。App 若走既有 `/portal/data/*` 與 `credentials_required` 這套，權限這塊**不需要新造**。 --- ## 5. App 之間互叫——**半套：做得到，但沒有專屬節點** **production 裡真的在用**：`products/arcrun-rag/workflows/rag-extract.local.yaml` 的 `dispatch` 節點（`:71-78`）用 `http_request` 打 `POST {cypher}/webhooks/named/{ns}/rag_extract_one/trigger`，帶 `X-Arcrun-API-Key`，把工作交給另一支 workflow `rag_extract_one` 執行——這是「dispatcher＋one」兩段式，`system-dev/docs/issues-log/Leo-Arcrun-64.md` 與 `agent-memory-archive-2026-08.md:685` 都記過這個模式的坑（foreach 內 code 輸出餵給這種呼叫時模板不展開）。 **但沒有專屬的「呼叫另一個 workflow」節點類型**。我 grep 了 `trigger_workflow` 這個詞：它只出現在 `matrix/arcrun/registry/examples/`（範例/心願級）與多份文件裡被**明確標注「未註冊，會 validate 失敗」**（`system-dev/docs/3-specs/autonomy-dispatch/gate-workflow/README.md:53`、`Leo-InkStoneCo-1.md:17`）。`registry/components/` 底下 20 個真實零件裡**沒有** `trigger_workflow` 這一個。 **結論**：能力上今天就能做（http_request 直打 trigger 端點，已在正式產線跑），但這是「借用 http_request 打自己的 webhook」，不是一等公民的「呼叫別的 App/workflow」原語。App 要互叫的話，正解路徑存在，但要靠 App 自己的 workflow 拿到對方的 `webhooks/named/trigger` URL＋API key（也就是要碰 tenant 金鑰）。 --- ## 6. 資料——**有，且已經是為此設計的** KBDB 走「萬用表」模型（blocks/templates/slots 三張核心表，`.claude/rules` 全樹反覆強調「零新表」鐵律），新資料型別＝ seed 一列 template： - 種子宣告位置：`matrix/arcrun/cypher-executor/src/lib/portal-seeds.ts:21`（`PORTAL_TEMPLATE_SEEDS`），目前已有 `portal_user`（`:25`）／`portal_library`（`:35`）／`triplet`（`:45`）三列 - 冪等建立走 `POST /kbdb/templates`（`cypher-executor/src/routes/kbdb-proxy.ts`），由 `/init/seed` 或 `/portal/admin/bootstrap` 呼叫 - 我核實過一個反面教材：credential 的目錄以前多開了一張獨立 D1 表（`0002_credentials.sql`），2026-08-07 被 leo 點名「任何東西禁止用 SQL 語句存取資料，一律 API」後，**已經改走 KBDB 三張核心表**（`credentials.ts:18-23`）——連系統自己都在把違規表收斂回這套機制。 **結論**：你的推測是對的。KBDB template 機制**現在就在扮演「開放給別人查的資料層」這個角色**，且是全系統唯一被允許的資料落點（API-as-Wall，零 SQL）。App 若要存自己的資料，正解已經鋪好，不用發明新東西。 --- ## 7. 新 Worker vs 掛在既有 runtime——**看層級，各有一半** - **要新增一個零件（component）＝一定要新 Worker**：`.claude/rules/05-deploy-convention.md` 明講「新增 Worker = 新目錄 + `wrangler.toml`，不用改 workflow」，CI 用 `find . -name 'wrangler.toml'` 掃描式部署（`:8-18`），每個零件都是獨立 Worker，有對內／對外兩個 URL（`.claude/rules/03-component-architecture.md`）。這條路**確定要部署新 worker**。 - **但今天實務上加新能力的預設路徑是「寫工作流」，不是「建零件」**：`.claude/rules/06-mindset.md` §1 明文「AI 開發時的預設順序：1. 預設寫工作流……2. 要有必要讓全 arcrun 生態重用才建零件」。工作流只是一份 YAML，`POST /webhooks/named` 存進 KV（`webhooks-named.ts:1-22`），**完全不必部署任何 worker**——`rag_extract`／`rag_extract_one` 這類正式產線的能力就是這樣加出來的。 **結論**：這題答案是「兩條路都在，且各司其職」——**不部署新 worker 也能加功能的路徑今天就存在**（工作流，用既有零件/recipe 組），但它產出的是「後端能力」；一旦要新的**基礎積木**（零件）或要**在 Portal 露出畫面**，都必須新增部署單位（前者新 worker，後者今天是改 Portal 單檔）。App 協定要解的正是後面這條「露出畫面」的路。 --- ## 額外一題：零件／recipe 跟 leo 要的「App」是不是同一層 **不是同一層，你的直覺是對的**，而且系統自己的文件已經在區分這件事，證據比我預期更明確： - `system-dev/docs/1-vision/20260803-mira-as-arcrun-app.md`（2026-08-03，早於 `#82` 六天）已經寫「**App 就是一種 bundle，多帶一個 `ui.entry`**」（`:108`），並列出 App 安裝要落地四件套：`templates`／`workflows`（**明文「不准自帶 worker」，`:117`**）／`ui`／`capability`（`:115-119`）——這正是「零件＝積木、recipe＝單一 API 封裝、workflow＝組裝出的能力，App＝把一組這樣的能力＋前端＋資料契約打包成一個有身份、能裝卸的產品面」的三層結構。 - D37（`decisions-summary.md:244`）把 App 定義在「bundle」這個**分發層**（第四種可分發物：workflow/recipe/template 之上），`#82` 的協定又補了 App 的**掛載層**（Portal 側欄一格）。兩份文件合起來看，**App 是零件/recipe/workflow 的上層聚合＋門面**，不是它們的同義詞或平行概念——這與你的判斷（零件/recipe 是「擴充能力」類似 plugin，App 是「有自己門面」的上一層）完全吻合。我唯一想幫你補強的一點：**目前「App」這個詞在系統裡實際上疊了兩個互相獨立的裁決**——「App＝bundle」（分發/相依，D37/D38/`#69`）和「App＝Portal 掛載」（門面，D63/`#82`）——這兩者 confirmed 的時間點與作者不同、進度也不同（前者規格 draft、0/33；後者連規格都還在票的留言區，SDD 都還沒開）。寫提案時建議明確講清楚你指的是哪一層，或乾脆點名「這兩層現在是分開發展、還沒收斂成一份 SDD」，否則讀的人容易把「D37 已 confirmed」誤讀成「App 機制已經在做」。 --- ## 你的提案最可能錯在哪我認為風險不在你對「現況」的判斷（你的推測方向其實相當準——recipe 市集、credential、KBDB 這三塊你猜「已經有一半」是對的），而在**兩個容易被讀者忽略的落差**： 1. **「已經設計」與「已經存在」之間的距離，比看起來近**。`#82` 那則留言把「協定 v0」寫得非常具體（連 Portal 要改哪 5 處、改幾行都寫了），語感上很像「快做完了」，但我核實下來：`portal.ts` 沒有 `apps` key、`index.html` 沒有 `mountApp`、`portal-seeds.ts` 沒有 `arcrun_app` seed、`cli/src/commands/` 沒有 `app.ts`——**一行代碼都还没有落地**，而且 D35 生命週期鐵律要求先走 `pending-changes.md` confirm 才能開 SDD，那個 confirm 現在也還沒發生（`#82` 票上只留了「等 leo 裁的兩題」）。如果提案給 leo 的印象是「協定都設計好了，接下來就是照做」，容易低估「這是一份**還沒被 leo 拍板、也還沒開 SDD** 的草案」這個事實，跟 D37（bundle）那條**已經 confirmed 但 0/33 沒動工**是同一種風險——「confirmed」不等於「在做」。 2. **兩個 App 定義並存，容易在文字裡悄悄合流**。如你所見，`D37/#69`（App=bundle，管「怎麼分發、怎麼裝」）與 `#82`（App=Portal 掛載，管「UI 長在哪」）目前是兩條線、兩份文件、兩種進度。你的提案若把它們當一件事描述，會讓 leo 誤以為「裝了就會自動長出畫面」這條路已經有一半基礎在跑（因為 D37 confirmed 了）——但實際上分發層和掛載層要各自補完、還要互相對接（`mira-as-arcrun-app.md:121-124` 自己列的「三個新問題」正是這個對接缺口：UI 資產怎麼跟著 bundle 走、版本相依、卸載）。建議提案裡把這兩層分開畫，並清楚標「目前都是草案／未 confirm，不是現成能力」。

Leo commented

2026-08-13 03:42:14 +00:00

🏛️ leo 2026-08-13：App 的分層架構——這是規格的主體，前面的提案要照這個改

leo 原話（分層與例子都照他的）：

一、AI 看到的（人一般不用懂）

零件（component）：「Arcrun 是讓你不用自己 coding，零件我提供，其他人透過 PR 提供，需要的不多，
這些零件就是負責運行的元件，數量不多。」
工作流／recipe／credential：「任何人可以用 Cypher 寫工作流或 recipe，對現有零件產生新功能，
例如讓 http request 打到原來沒有的網站。或建立新 credential，例如可以連上 Google service account。」

二、人看到的

Workflow：「可以執行一條工作，例如，每週一拉企業系統自動產生週報表寄到 Telegram。」
🔴 「考慮一律包裝成 App，像 Android 所有 App 不能沒有 icon，一定要可以視覺看到，
就算不需操作也可以直接刪除 icon 就是刪除 App。」
App：「可以做複雜工作，例如，筆記系統，可以寫筆記、打標籤、分 journal 及單獨筆記、
上傳圖片嵌入、產生 todo 可以追蹤⋯⋯背後是多條 Arcrun 工作流在處理。」

三、人想要產生新 App

「跟他的 AI 說，AI 用工作流組合產生，浮現在界面上一個新的 icon。
所以這是一個以 CF 為基礎的 Manus, Lovable。」

🔴 這段話直接解掉了本票的第一題「什麼是 App」

答案：凡是人看得到的，都是 App。 差別只有複雜度：

	是什麼	icon	例
簡單 App	一條工作流	有（一律要有）	每週一產週報寄 Telegram
複雜 App	多條工作流＋自己的畫面＋自己的資料	有	筆記系統
零件／recipe／credential	不是 App，AI 才看得到	無	`http_request`、Google service account

⇒ 邊界劃在「人看不看得到」，不是劃在「複雜不複雜」。

三個直接推論（都是可驗的規格，不是形容詞）：

沒有 icon 的東西不准出現在人的介面上（Android 規則）。
⇒ 現在 Portal 側欄那些寫死的頁，要嘛變成 App，要嘛不該在那裡。
刪 icon ＝卸載。⇒ 卸載必須是一等公民，不是事後補的功能
（20260803-mira-as-arcrun-app.md 自己列的三個對接缺口之一就是它）。
「一條工作流也要包成 App」意味著打包必須極輕——如果包一個 App 要填十個欄位，
沒有人會為了一條週報工作流去包。⇒ 宣告檔要小到 AI 一次寫得完，且大部分欄位可省略。

🎯 這也印證了實體選 B（總管建議、且系統十天前的願景文件已寫）

leo 要的是「跟 AI 說一句，介面就浮現一個新 icon」。

如果 App ＝一顆要部署的 Worker（A 案）⇒ AI 產生它要走 CF 部署、要權限、要等 ⇒ 做不到「立刻浮現」
如果 App ＝宣告＋工作流＋畫面，註冊到既有 runtime（B 案）⇒ 寫一份宣告就浮現，這才接得上

⇒ 🔴 A 案與 leo 描述的產品體驗互斥。 這不再是偏好問題，是可行性問題。

📌 「以 CF 為基礎的 Manus／Lovable」這句話是本票的驗收標準：
不是「App 協定做完了」，是leo 對他的 AI 說一句話，介面上多一個 icon，點進去能用。

（署名：總管）

## 🏛️ leo 2026-08-13：App 的分層架構——**這是規格的主體，前面的提案要照這個改** > leo 原話（分層與例子都照他的）： ### 一、AI 看到的（人一般不用懂） - **零件（component）**：「Arcrun 是讓你不用自己 coding，**零件我提供，其他人透過 PR 提供，需要的不多**，這些零件就是負責運行的元件，數量不多。」 - **工作流／recipe／credential**：「任何人可以用 Cypher 寫工作流或 recipe，**對現有零件產生新功能**，例如讓 http request 打到原來沒有的網站。或建立新 credential，例如可以連上 Google service account。」 ### 二、人看到的 - **Workflow**：「可以執行**一條**工作，例如，每週一拉企業系統自動產生週報表寄到 Telegram。」 🔴 **「考慮一律包裝成 App，像 Android 所有 App 不能沒有 icon，一定要可以視覺看到，就算不需操作也可以直接刪除 icon 就是刪除 App。」** - **App**：「可以做**複雜**工作，例如，筆記系統，可以寫筆記、打標籤、分 journal 及單獨筆記、上傳圖片嵌入、產生 todo 可以追蹤⋯⋯**背後是多條 Arcrun 工作流在處理**。」 ### 三、人想要產生新 App > 「跟他的 AI 說，**AI 用工作流組合產生，浮現在界面上一個新的 icon**。 > 所以這是一個**以 CF 為基礎的 Manus, Lovable**。」 --- ## 🔴 這段話直接解掉了本票的第一題「什麼是 App」 **答案：凡是人看得到的，都是 App。** 差別只有複雜度： | | 是什麼 | icon | 例 | |---|---|---|---| | **簡單 App** | 一條工作流 | **有**（一律要有） | 每週一產週報寄 Telegram | | **複雜 App** | 多條工作流＋自己的畫面＋自己的資料 | 有 | 筆記系統 | | 零件／recipe／credential | **不是 App**，AI 才看得到 | 無 | `http_request`、Google service account | ⇒ **邊界劃在「人看不看得到」，不是劃在「複雜不複雜」。** **三個直接推論（都是可驗的規格，不是形容詞）**： 1. **沒有 icon 的東西不准出現在人的介面上**（Android 規則）。 ⇒ 現在 Portal 側欄那些寫死的頁，要嘛變成 App，要嘛不該在那裡。 2. **刪 icon ＝卸載**。⇒ 卸載必須是一等公民，不是事後補的功能（`20260803-mira-as-arcrun-app.md` 自己列的三個對接缺口之一就是它）。 3. **「一條工作流也要包成 App」意味著打包必須極輕**——如果包一個 App 要填十個欄位，沒有人會為了一條週報工作流去包。⇒ **宣告檔要小到 AI 一次寫得完，且大部分欄位可省略。** --- ## 🎯 這也印證了實體選 B（總管建議、且系統十天前的願景文件已寫） leo 要的是「**跟 AI 說一句，介面就浮現一個新 icon**」。 - 如果 App ＝一顆要部署的 Worker（A 案）⇒ AI 產生它要走 CF 部署、要權限、要等 ⇒ **做不到「立刻浮現」** - 如果 App ＝宣告＋工作流＋畫面，註冊到既有 runtime（B 案）⇒ **寫一份宣告就浮現，這才接得上** ⇒ 🔴 **A 案與 leo 描述的產品體驗互斥。** 這不再是偏好問題，是可行性問題。 📌 **「以 CF 為基礎的 Manus／Lovable」這句話是本票的驗收標準**：不是「App 協定做完了」，是**leo 對他的 AI 說一句話，介面上多一個 icon，點進去能用**。（署名：總管）

Leo commented

2026-08-13 03:52:46 +00:00

❌ 撤回：我用「部署摩擦」否定 A 案——那個論證是錯的（leo 2026-08-13 糾正）

留言 1804 我寫：

「如果 App ＝一顆要部署的 Worker（A 案）⇒ AI 產生它要走 CF 部署、要權限、要等
⇒ 做不到「立刻浮現」」「🔴 A 案與 leo 描述的產品體驗互斥。」

leo：

「你有這個提案表示你沒搞清楚 Arcrun 在做什麼，你要進行提案前先閱讀整個 repo 及有關知識，
確知 Arcrun 的定位後再提案，不能在計劃階段就搞錯。」

為什麼那個論證錯

Arcrun 的定位就是「替用戶操作 CF」。 部署 worker 不是它的成本，是它的日常能力：

安裝器一次部署 23 顆 worker（2026-08-12 geek6688 更新實測輸出）
零件（component）本身就是 worker——.claude/rules/05-deploy-convention.md
「新增 Worker ＝新目錄＋ wrangler.toml」
Leo/Arcrun#90 正是「缺『部署一顆 Cloudflare Worker』的 recipe」
⇒ 部署 worker 本來就在計畫中要工作流化

⇒ 🔴 我把「一般 SaaS 的部署摩擦」套在一個專門消除那個摩擦的產品上。
用戶不必懂 CF，因為 Arcrun 幫他做——這正是它存在的理由。

所以 A 案的去留要重新論證

B 仍然是既有定案（D37 confirmed ＋ 20260803-mira-as-arcrun-app.md:117 明文「不准自帶 worker」）——
但支持它的理由不是我寫的那個。

真正的理由必須從既有裁決來，例如 D37 的複本式分發鐵律：
「pull ＝依賴全部落地本實例 KBDB，runtime 零外部依賴，斷源只斷更新不斷用」
⇒ App 裝完之後，原作者的實例消失了，你的 App 照跑。
一顆自帶的 worker 要怎麼滿足這條，是需要論證的——而我沒論證，我用了一個錯的捷徑。

📌 本則之前，本票上所有關於「A 案出局」的論述一律作廢，等重新閱讀後再提。

總管接下來要做的（leo 的指令）

先把 Arcrun 的定位讀清楚，再提案。 已派工做通盤閱讀，結論會貼回本票。
在那之前不再對 App 的實體形式下任何判斷。

（署名：總管）

## ❌ 撤回：我用「部署摩擦」否定 A 案——那個論證是錯的（leo 2026-08-13 糾正）留言 1804 我寫： > 「如果 App ＝一顆要部署的 Worker（A 案）⇒ AI 產生它要走 CF 部署、要權限、要等 > ⇒ **做不到「立刻浮現」**」「🔴 **A 案與 leo 描述的產品體驗互斥。**」 leo： > 「**你有這個提案表示你沒搞清楚 Arcrun 在做什麼**，你要進行提案前先閱讀整個 repo 及有關知識， > 確知 Arcrun 的定位後再提案，**不能在計劃階段就搞錯**。」 ### 為什麼那個論證錯 **Arcrun 的定位就是「替用戶操作 CF」。** 部署 worker 不是它的成本，是它的**日常能力**： - 安裝器一次部署 **23 顆 worker**（2026-08-12 geek6688 更新實測輸出） - **零件（component）本身就是 worker**——`.claude/rules/05-deploy-convention.md` 「新增 Worker ＝新目錄＋ `wrangler.toml`」 - `Leo/Arcrun#90` 正是「**缺『部署一顆 Cloudflare Worker』的 recipe**」 ⇒ 部署 worker **本來就在計畫中要工作流化** ⇒ 🔴 **我把「一般 SaaS 的部署摩擦」套在一個專門消除那個摩擦的產品上。** 用戶不必懂 CF，因為 Arcrun 幫他做——這正是它存在的理由。 ### 所以 A 案的去留要重新論證 **B 仍然是既有定案**（D37 confirmed ＋ `20260803-mira-as-arcrun-app.md:117` 明文「不准自帶 worker」）—— **但支持它的理由不是我寫的那個。** 真正的理由必須從既有裁決來，例如 D37 的**複本式分發鐵律**：「pull ＝依賴全部落地本實例 KBDB，runtime 零外部依賴，**斷源只斷更新不斷用**」 ⇒ App 裝完之後，原作者的實例消失了，你的 App 照跑。 **一顆自帶的 worker 要怎麼滿足這條，是需要論證的**——而我沒論證，我用了一個錯的捷徑。 📌 **本則之前，本票上所有關於「A 案出局」的論述一律作廢**，等重新閱讀後再提。 ### 總管接下來要做的（leo 的指令） **先把 Arcrun 的定位讀清楚，再提案。** 已派工做通盤閱讀，結論會貼回本票。在那之前**不再對 App 的實體形式下任何判斷**。（署名：總管）

Leo commented

2026-08-13 04:08:19 +00:00

✅ 定位讀本已完成並併入 main——本票先前對 A 案的論證，正確答案在這裡

📍 system-dev/docs/1-vision/20260813-arcrun-positioning.md（682 行，PR #26 已併）
寫任何 Arcrun 提案之前先讀它，尤其 §2 成本表與 §6 的 16 條自查清單。

一、總管那句話錯在哪（結論對，理由錯）

我寫的：「A 案要走 CF 部署、要權限、要等 ⇒ 做不到立刻浮現」

「App 不該自帶 worker」是對的，但理由不是部署有摩擦。
在 Arcrun 的世界裡，部署是「待自動化的一步」，不是「需要人等待的關卡」：

安裝器路：使用者不開終端機，三步驟裝完 6 顆 worker 在他自己的 CF 帳號上
（installer/scripts/bundle-components.mjs:46-102 實查）
CLI 路：acr update 一次處理 23 顆 component worker
Leo/Arcrun#90 正在把「部署一顆 Worker」做成 recipe

⇒ 🔴 拿「要部署、要權限、要等」當論據，等於否定了這個產品已經做到的事。

二、正確的理由（既有文件早就寫好，我沒去讀）

真正的理由	出處
門檻在「要求每個第三方 App 作者會部署與維運」——不是部署本身難，是把維運責任推給 App 作者	`docs/1-vision/20260803-mira-as-arcrun-app.md:307`
Portal 是「出貨物」不是「安裝物」——`build-ui-bundle.mjs` 把整個 `console-ui/public/` 內嵌成單檔 worker ⇒ 每裝一個 App 就要重新出貨整個產品	實查
複本式分發鐵律：pull ＝依賴全落地本實例，runtime 零外部依賴，斷源只斷更新不斷用	D37

三、🔴 這是同款錯的第二次，第一次也記在 D37 裡

2026-08-07：總管把「Worker 打不到 localhost」當成物理邊界，被 leo 當場更正。

兩次都是「把當前部署形態的性質，當成產品的限制」。
⇒ 判準：提案前先問「這個限制是 Arcrun 的，還是我從別的世界帶進來的？」

四、定位的核心判準比預期硬：競爭對手不是 n8n，是「AI 直接寫 Python」

leo 2026-07-21（matrix/arcrun/system-dev/wiki/principles.md:27）：
「AI 覺得 Arcrun 比 Python 還簡單，因此沒有寫 Python 的慾望。」

實測反例（同一份文件記著）：總管做「定期打 API 然後通知」，
Python 10 行；Arcrun 40 分鐘未完成。

⇒ 🔴 任何讓 AI 覺得「不如自己寫」的設計，都違反定位，不論架構多漂亮。

這條直接約束本票的 App 宣告檔：leo 要「一條工作流也包成 App」，
若包一個 App 要填十個欄位，AI 會選擇不包。宣告檔要小到 AI 一次寫得完。
（這點先前總管推論過，現在有了出處。）

五、順帶查到兩處使用者看得到的死記錄（未修，值得單獨處理）

products/arcrun-rag/installer/README.md 寫 24 顆
installer/oauth-prototype/worker.js:2297 寫「Workers script ×1」
實際是 6 顆 ⇒ 使用者在授權畫面看到的數字是錯的

六、報告自己標的三個未查

本票那張表的右欄未逐項核實（總管自己也標了「推測」）
語意搜尋這次零命中（藏書地圖 8/10 庫是空的）⇒ 全文只依賴檔案與 Gitea 票
ON_TRUE/ON_FALSE 支不支援有兩份互相矛盾的說法（skill vs MCP instructions），未實測
——這本身就是「同一件事兩個答案」那條軸的活例

（署名：總管）

## ✅ 定位讀本已完成並併入 main——**本票先前對 A 案的論證，正確答案在這裡** 📍 `system-dev/docs/1-vision/20260813-arcrun-positioning.md`（682 行，PR #26 已併） **寫任何 Arcrun 提案之前先讀它**，尤其 §2 成本表與 §6 的 16 條自查清單。 ### 一、總管那句話錯在哪（結論對，理由錯） > 我寫的：「A 案要走 CF 部署、要權限、要等 ⇒ 做不到立刻浮現」 **「App 不該自帶 worker」是對的，但理由不是部署有摩擦。** 在 Arcrun 的世界裡，**部署是「待自動化的一步」，不是「需要人等待的關卡」**： - 安裝器路：使用者**不開終端機**，三步驟裝完 **6 顆 worker** 在他自己的 CF 帳號上（`installer/scripts/bundle-components.mjs:46-102` 實查） - CLI 路：`acr update` 一次處理 **23 顆** component worker - `Leo/Arcrun#90` **正在把「部署一顆 Worker」做成 recipe** ⇒ 🔴 **拿「要部署、要權限、要等」當論據，等於否定了這個產品已經做到的事。** ### 二、正確的理由（既有文件早就寫好，我沒去讀） | 真正的理由 | 出處 | |---|---| | **門檻在「要求每個第三方 App 作者會部署與維運」**——不是部署本身難，是把維運責任推給 App 作者 | `docs/1-vision/20260803-mira-as-arcrun-app.md:307` | | **Portal 是「出貨物」不是「安裝物」**——`build-ui-bundle.mjs` 把整個 `console-ui/public/` 內嵌成單檔 worker ⇒ **每裝一個 App 就要重新出貨整個產品** | 實查 | | **複本式分發鐵律**：pull ＝依賴全落地本實例，runtime 零外部依賴，斷源只斷更新不斷用 | D37 | ### 三、🔴 這是同款錯的**第二次**，第一次也記在 D37 裡 > **2026-08-07：總管把「Worker 打不到 localhost」當成物理邊界，被 leo 當場更正。** **兩次都是「把當前部署形態的性質，當成產品的限制」。** ⇒ 判準：**提案前先問「這個限制是 Arcrun 的，還是我從別的世界帶進來的？」** ### 四、定位的核心判準比預期硬：**競爭對手不是 n8n，是「AI 直接寫 Python」** > leo 2026-07-21（`matrix/arcrun/system-dev/wiki/principles.md:27`）： > 「**AI 覺得 Arcrun 比 Python 還簡單，因此沒有寫 Python 的慾望。**」實測反例（同一份文件記著）：總管做「定期打 API 然後通知」， **Python 10 行；Arcrun 40 分鐘未完成。** ⇒ 🔴 **任何讓 AI 覺得「不如自己寫」的設計，都違反定位，不論架構多漂亮。** **這條直接約束本票的 App 宣告檔**：leo 要「一條工作流也包成 App」，若包一個 App 要填十個欄位，AI 會選擇不包。**宣告檔要小到 AI 一次寫得完。** （這點先前總管推論過，現在有了出處。） ### 五、順帶查到兩處使用者看得到的死記錄（未修，值得單獨處理） - `products/arcrun-rag/installer/README.md` 寫 **24 顆** - `installer/oauth-prototype/worker.js:2297` 寫「**Workers script ×1**」 - 實際是 **6 顆** ⇒ 使用者在授權畫面看到的數字是錯的 ### 六、報告自己標的三個未查 1. 本票那張表的右欄未逐項核實（總管自己也標了「推測」） 2. **語意搜尋這次零命中**（藏書地圖 8/10 庫是空的）⇒ 全文只依賴檔案與 Gitea 票 3. `ON_TRUE`/`ON_FALSE` 支不支援**有兩份互相矛盾的說法**（skill vs MCP instructions），未實測 ——**這本身就是「同一件事兩個答案」那條軸的活例** （署名：總管）

Leo commented

2026-08-13 04:23:14 +00:00

🔄 定位更新（leo 2026-08-13 稍晚）——本票先前引用的「跟 Python 比」那條判準作廢

我在留言 1809 引用了定位讀本的「競爭對手不是 n8n，是 AI 直接寫 Python」當判準。
leo 當天稍晚親自更新了定位，那條作廢。

「原本 arcrun 定位是『AI Friendly 的 n8n』，但AI 沒有用它的動力。
現在改成『Arcrun 是 CF 的 Android，可以 AI 快速自建 App』，
用戶有動力，就會 push AI 幫他做。

比較起 Python 做個輪詢，Arcrun 的目標是建一個 App⋯⋯環境有：
零件、credential、recipe、market、KBDB、RAG…，就像 Android 提供整套 API 和
手機感應器操作能力，就不會把 Android App 跟 Python 比。
在 Arcrun，AI 只是取用這些能力，就可以達成 App 建立，比 Android App 還簡單，
應該不會拿來跟 Python 比較，因為層不同。」

三件改變（每件都改變本票的推理）

① 動力來源從供給端換到需求端——這是核心

	舊	新
一句話	AI Friendly 的 n8n	CF 的 Android，AI 快速自建 App
誰有動力	AI 要覺得好用	用戶想要 App → 用戶 push AI 去做
死穴	🔴 AI 沒有用它的動力	用戶需求本來就存在

⇒ 舊定位把成敗押在「AI 願不願意用」，而那件事我們控制不了。

② 拿 Python 比是層級錯誤 ⇒ 我先前寫的「任何讓 AI 覺得『不如自己寫』的設計都違反定位」
——那條判準作廢。它比的是「寫一支輪詢腳本」，新定位比的是「建一個 App」。
🔴 這跟本票稍早那個錯（把當前部署形態當成產品限制）是同一種：拿錯層級的東西來衡量。

③ 新標竿是 Android App，不是 Python 腳本 ⇒ 提案要問的是
「這個設計讓 AI 建一個 App，是不是比建 Android App 更簡單」。

對本票的直接影響（好消息）

「一律包裝成 App、每個都有 icon、刪 icon＝卸載」這條，在新定位下更站得住。
Android 的心智模型現在不只是類比，它是定位本身。

⇒ 而「宣告檔要小到 AI 一次寫得完」的理由也換了、而且更強：
不是「不然 AI 覺得不如寫 Python」，是「用戶 push AI 做一個 App 時，AI 要當場做得出來」。

📍 定位讀本已同步更新：system-dev/docs/1-vision/20260813-arcrun-positioning.md 開頭新增更正段。
（署名：總管）

## 🔄 定位更新（leo 2026-08-13 稍晚）——**本票先前引用的「跟 Python 比」那條判準作廢** 我在留言 1809 引用了定位讀本的「**競爭對手不是 n8n，是 AI 直接寫 Python**」當判準。 **leo 當天稍晚親自更新了定位，那條作廢。** > 「原本 arcrun 定位是『**AI Friendly 的 n8n**』，但**AI 沒有用它的動力**。 > 現在改成『**Arcrun 是 CF 的 Android，可以 AI 快速自建 App**』， > **用戶有動力，就會 push AI 幫他做。** > > 比較起 Python 做個輪詢，Arcrun 的目標是**建一個 App**⋯⋯環境有： > **零件、credential、recipe、market、KBDB、RAG…**，就像 Android 提供整套 API 和 > 手機感應器操作能力，**就不會把 Android App 跟 Python 比**。 > 在 Arcrun，AI 只是**取用這些能力**，就可以達成 App 建立，**比 Android App 還簡單**， > **應該不會拿來跟 Python 比較，因為層不同。**」 ### 三件改變（每件都改變本票的推理） **① 動力來源從供給端換到需求端——這是核心** | | 舊 | **新** | |---|---|---| | 一句話 | AI Friendly 的 n8n | **CF 的 Android，AI 快速自建 App** | | 誰有動力 | AI 要覺得好用 | **用戶想要 App → 用戶 push AI 去做** | | 死穴 | 🔴 **AI 沒有用它的動力** | 用戶需求本來就存在 | ⇒ 舊定位把成敗押在「AI 願不願意用」，**而那件事我們控制不了**。 **② 拿 Python 比是層級錯誤** ⇒ 我先前寫的「任何讓 AI 覺得『不如自己寫』的設計都違反定位」 ——**那條判準作廢**。它比的是「寫一支輪詢腳本」，新定位比的是「**建一個 App**」。 🔴 **這跟本票稍早那個錯（把當前部署形態當成產品限制）是同一種：拿錯層級的東西來衡量。** **③ 新標竿是 Android App，不是 Python 腳本** ⇒ 提案要問的是「這個設計讓 AI 建一個 App，**是不是比建 Android App 更簡單**」。 ### 對本票的直接影響（好消息） **「一律包裝成 App、每個都有 icon、刪 icon＝卸載」這條，在新定位下更站得住。** Android 的心智模型現在不只是類比，**它是定位本身**。 ⇒ 而「宣告檔要小到 AI 一次寫得完」的理由也換了、而且更強：不是「不然 AI 覺得不如寫 Python」，是「**用戶 push AI 做一個 App 時，AI 要當場做得出來**」。 📍 定位讀本已同步更新：`system-dev/docs/1-vision/20260813-arcrun-positioning.md` 開頭新增更正段。（署名：總管）

Leo added the

s

stage

label 2026-08-13 05:12:27 +00:00

Leo added

and removed

labels 2026-08-13 05:14:48 +00:00

Leo commented

2026-08-13 05:14:49 +00:00

🟢 leo 2026-08-13 裁定：不是「要不要開」，是「去建」

「App 這是重大轉折，不是要不要，是你要建立 ADR，因為有個大的決定，
連到你建立的 Hub 卡，依照 Hub 卡去寫成 SDD，然後把 SDD push 後連結放在原票。」

⇒ pending-changes.md 那則提案的「等 confirm」狀態結束。本票標籤從 s/stage 改回 s/doing。

要交出三件，順序如他所講

ADR（system-dev/docs/2-architecture/decisions/）——記錄那個「大的決定」本身：
Arcrun 定位從「AI Friendly 的 n8n」轉成「CF 的 Android，AI 快速自建 App」，
以及它帶來的結構後果（App 是一層框架／凡人看得到的都是 App／動力來源從供給端換到需求端）
SDD（三件式）——依照本 hub 卡寫，把分發層（Leo/Arcrun#69）與掛載層（Leo/Arcrun#82）
收斂成一份，並依 SDD 鐵律④逐條處置 stage-environment 那三張未完成的票
（Leo/arcrun-rag#27／#28／#29）
push 後把 SDD 連結貼回本票

📌 本票已收攏的六張、核實報告（留言 1802）、定位更新（留言 1817）、
以及 system-dev/docs/1-vision/20260813-arcrun-positioning.md（682 行讀本）都是 SDD 的輸入。

（署名：總管）

## 🟢 leo 2026-08-13 裁定：**不是「要不要開」，是「去建」** > 「App 這是**重大轉折**，不是要不要，是**你要建立 ADR**，因為有個大的決定， > **連到你建立的 Hub 卡，依照 Hub 卡去寫成 SDD，然後把 SDD push 後連結放在原票**。」 ⇒ `pending-changes.md` 那則提案的「等 confirm」狀態**結束**。本票標籤從 `s/stage` 改回 `s/doing`。 ### 要交出三件，順序如他所講 1. **ADR**（`system-dev/docs/2-architecture/decisions/`）——記錄那個「大的決定」本身： Arcrun 定位從「AI Friendly 的 n8n」轉成「**CF 的 Android，AI 快速自建 App**」，以及它帶來的結構後果（App 是一層框架／凡人看得到的都是 App／動力來源從供給端換到需求端） 2. **SDD**（三件式）——**依照本 hub 卡寫**，把分發層（`Leo/Arcrun#69`）與掛載層（`Leo/Arcrun#82`）收斂成一份，並依 SDD 鐵律④逐條處置 `stage-environment` 那三張未完成的票（`Leo/arcrun-rag#27`／`#28`／`#29`） 3. **push 後把 SDD 連結貼回本票** 📌 本票已收攏的六張、核實報告（留言 1802）、定位更新（留言 1817）、以及 `system-dev/docs/1-vision/20260813-arcrun-positioning.md`（682 行讀本）**都是 SDD 的輸入**。（署名：總管）

Leo commented

2026-08-13 05:31:39 +00:00

✅ 三件已交：ADR ＋ SDD ＋連結（leo 2026-08-13 指令）

「你要建立 ADR⋯⋯連到你建立的 Hub 卡，依照 Hub 卡去寫成 SDD，然後把 SDD push 後連結放在原票。」

PR（含完整交件說明）：Leo/InkStoneCo#30

📄 連結

交付物	連結
① ADR D79	`D79-arcrun-as-cf-android.md`
② SDD — requirements	`arcrun-app-system/requirements.md`
② SDD — design	`arcrun-app-system/design.md`
② SDD — tasks	`arcrun-app-system/tasks.md`

不含任何實作程式碼（SDD 鐵律④a：任務搬移做完前不准寫 code）。

ADR 記的那個「大的決定」

定位從「AI Friendly 的 n8n」→「CF 的 Android，AI 快速自建 App」，
核心是動力來源從供給端換到需求端——舊定位的死穴正是「AI 沒有用它的動力」，而那件事我們控制不了。

六個結構後果、以及兩條作廢的判準（跟 Python 比／部署摩擦論——同一種錯：拿錯層級的東西來衡量）
逐條附出處，全文在 ADR。
✅「App 不准自帶 worker」結論不變，但理由換成正確的三條（第三方維運門檻／Portal 是出貨物／複本式分發）。

SDD 為什麼是一份不是兩份

三個對接缺口 ① UI 資產隨 bundle 走 ② 版本相依 ③ 卸載——design.md §一 有一張表
逐條說明每個缺口的哪一半屬分發層、哪一半屬掛載層。分開寫必然各寫一半。
三個缺口在 tasks.md Phase 2 各有獨立任務（2.1／2.2／2.3），各帶驗收。

設計上唯一新增的主張（其餘全部沿用既有裁決，沒有在旁邊開新路）：

必填 ≤ 3 個欄位，三行就是一個 App；icon 是必要的存在、不是必要的填寫（省略時系統自動給）
沒有前端的 App 必須合法，由系統預設畫面渲染——否則作者被迫寫前端，「一條工作流也要能包成 App」直接不成立

🔴 SDD 鐵律①怎麼處置的

stage-environment → paused（不是 closed：它沒有被取代，題目不同，填 superseded_by 會是假話）；
arcrun-app-system → active。機械驗證：sdd-active-check.sh exit=0，active 恰好 1 份。

鐵律④a 逐條搬移（實查 Gitea 票面，不是照抄舊記錄）：

票	票面狀態	處置
`Leo/arcrun-rag#27`	open	搬入新卷 §0.1
`Leo/arcrun-rag#28`	open	搬入新卷 §0.2
`Leo/arcrun-rag#29`	✅ closed（08-09）	已完成，不搬

📌 這裡更正了本票 pending-changes 那則提案的一句話：它寫「#27／#28／#29 都還沒完成」，
#29 其實早就 closed 了。

而且搬移不是純記帳：App 要出貨就必須走 stage → prod，#27／#28 沒解 ⇒
「leo 打開 Portal 看到那個 icon」這條驗收沒有安全的出貨路徑 ⇒ 它們是 Phase 0 前置。

⏸ 等 leo 回一個詞的三件

A：這批 App 短期內都是我們自己寫的，對嗎？（是 ⇒ 畫面跑在 Portal 裡；不是 ⇒ 第一天就得走沙箱。這是單向門）
→ 回「自己寫」或「要開放」
B：v0 只開側欄一個掛載點，夠不夠？→ 回「夠」或「不夠」
C：上面那張搬移／作廢清單的最終確認（鐵律④d。作廢清單是空的）

回完 A、B 我就能往 Phase 1 推；C 是流程要求的簽收。

（署名：Arcrun App 規格 subagent）

## ✅ 三件已交：ADR ＋ SDD ＋連結（leo 2026-08-13 指令） > 「你要建立 **ADR**⋯⋯連到你建立的 **Hub 卡**，依照 Hub 卡去寫成 **SDD**，然後把 **SDD push 後連結放在原票**。」 **PR（含完整交件說明）**：https://git.uncle6.me/Leo/InkStoneCo/pulls/30 ### 📄 連結 | 交付物 | 連結 | |---|---| | **① ADR D79** | [`D79-arcrun-as-cf-android.md`](https://git.uncle6.me/Leo/InkStoneCo/src/commit/fcf4905cfe090b17ebdf5c127c66f91c1439c382/system-dev/docs/2-architecture/decisions/D79-arcrun-as-cf-android.md) | | **② SDD — requirements** | [`arcrun-app-system/requirements.md`](https://git.uncle6.me/Leo/InkStoneCo/src/commit/fcf4905cfe090b17ebdf5c127c66f91c1439c382/system-dev/docs/3-specs/arcrun-app-system/requirements.md) | | **② SDD — design** | [`arcrun-app-system/design.md`](https://git.uncle6.me/Leo/InkStoneCo/src/commit/fcf4905cfe090b17ebdf5c127c66f91c1439c382/system-dev/docs/3-specs/arcrun-app-system/design.md) | | **② SDD — tasks** | [`arcrun-app-system/tasks.md`](https://git.uncle6.me/Leo/InkStoneCo/src/commit/fcf4905cfe090b17ebdf5c127c66f91c1439c382/system-dev/docs/3-specs/arcrun-app-system/tasks.md) | **不含任何實作程式碼**（SDD 鐵律④a：任務搬移做完前不准寫 code）。 --- ### ADR 記的那個「大的決定」 **定位從「AI Friendly 的 n8n」→「CF 的 Android，AI 快速自建 App」，核心是動力來源從供給端換到需求端**——舊定位的死穴正是「AI 沒有用它的動力」，而那件事我們控制不了。六個結構後果、以及**兩條作廢的判準**（跟 Python 比／部署摩擦論——同一種錯：拿錯層級的東西來衡量）逐條附出處，全文在 ADR。 ✅「App 不准自帶 worker」**結論不變**，但理由換成正確的三條（第三方維運門檻／Portal 是出貨物／複本式分發）。 ### SDD 為什麼是一份不是兩份三個對接缺口 **① UI 資產隨 bundle 走 ② 版本相依 ③ 卸載**——`design.md §一` 有一張表逐條說明**每個缺口的哪一半屬分發層、哪一半屬掛載層**。分開寫必然各寫一半。三個缺口在 `tasks.md` Phase 2 各有獨立任務（2.1／2.2／2.3），各帶驗收。 **設計上唯一新增的主張**（其餘全部沿用既有裁決，沒有在旁邊開新路）： - **必填 ≤ 3 個欄位，三行就是一個 App**；`icon` 是**必要的存在、不是必要的填寫**（省略時系統自動給） - **沒有前端的 App 必須合法**，由系統預設畫面渲染——否則作者被迫寫前端，**「一條工作流也要能包成 App」直接不成立** ### 🔴 SDD 鐵律①怎麼處置的 `stage-environment` → **`paused`**（不是 closed：它**沒有被取代**，題目不同，填 `superseded_by` 會是假話）； `arcrun-app-system` → **`active`**。**機械驗證：`sdd-active-check.sh` exit=0，active 恰好 1 份。** 鐵律④a 逐條搬移（**實查 Gitea 票面，不是照抄舊記錄**）： | 票 | 票面狀態 | 處置 | |---|---|---| | `Leo/arcrun-rag#27` | **open** | 搬入新卷 §0.1 | | `Leo/arcrun-rag#28` | **open** | 搬入新卷 §0.2 | | `Leo/arcrun-rag#29` | ✅ **closed（08-09）** | 已完成，不搬 | 📌 **這裡更正了本票 `pending-changes` 那則提案的一句話**：它寫「#27／#28／#29 **都還沒完成**」， **#29 其實早就 closed 了**。 **而且搬移不是純記帳**：App 要出貨就必須走 stage → prod，`#27`／`#28` 沒解 ⇒ **「leo 打開 Portal 看到那個 icon」這條驗收沒有安全的出貨路徑** ⇒ 它們是 **Phase 0 前置**。 --- ### ⏸ 等 leo 回一個詞的三件 1. **A**：這批 App 短期內**都是我們自己寫的，對嗎**？（是 ⇒ 畫面跑在 Portal 裡；不是 ⇒ 第一天就得走沙箱。**這是單向門**） → 回「**自己寫**」或「**要開放**」 2. **B**：v0 **只開側欄一個掛載點，夠不夠**？→ 回「**夠**」或「**不夠**」 3. **C**：上面那張**搬移／作廢清單**的最終確認（鐵律④d。作廢清單是空的）回完 A、B 我就能往 Phase 1 推；C 是流程要求的簽收。（署名：Arcrun App 規格 subagent）

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Leo/Arcrun#115

[hub] Arcrun 的 App 系統：規格、打包、掛上 Portal——CF 之於 Arcrun，如同 Linux 之於 Android #115

leo 的願景（原話，規格依此為準）

順序（leo 2026-08-13 定，D78）

收攏的票（第 3 段的候選 App／相關能力）

總管的提案（待 leo 裁；未經核實的部分已標明）

一、叫 App，不要叫 Plugin

二、Android 的類比可以借它的具體規格，不只是比喻

三、一個 App 的實體是什麼（這題最需要 leo 拍板）

這張票要交出什麼才算完成

✅ 現況核實報告（取代票上那張標著「總管推測」的表）

一句話：七題核實下來，總管推測的方向大致對，但「已經有」的比想像中少一層

🔴 它抓到總管提案的兩個缺陷（這段比報告本文更值錢）

缺陷一：「已經設計」被讀成「已經存在」

缺陷二：「App」這個詞現在疊了兩個互相獨立的裁決，總管把它們寫成一件事了

🎯 對「App 的實體選 A 還是 B」的影響——核實結果強化了 B

📄 核實報告全文

Arcrun App 規格提案——現況核實報告

1. 前端掛載點——沒有

2. 宣告檔——半套：零件與 recipe 各自都有，但都不是「App」的形狀

3. 分發（recipe_search／recipe_push／recipe_pull）——半套，而且要拆成兩層看

4. 權限——有，而且比我預期成熟

5. App 之間互叫——半套：做得到，但沒有專屬節點

6. 資料——有，且已經是為此設計的

7. 新 Worker vs 掛在既有 runtime——看層級，各有一半

額外一題：零件／recipe 跟 leo 要的「App」是不是同一層

你的提案最可能錯在哪

🏛️ leo 2026-08-13：App 的分層架構——這是規格的主體，前面的提案要照這個改

一、AI 看到的（人一般不用懂）

二、人看到的

三、人想要產生新 App

🔴 這段話直接解掉了本票的第一題「什麼是 App」

🎯 這也印證了實體選 B（總管建議、且系統十天前的願景文件已寫）

❌ 撤回：我用「部署摩擦」否定 A 案——那個論證是錯的（leo 2026-08-13 糾正）

為什麼那個論證錯

所以 A 案的去留要重新論證

總管接下來要做的（leo 的指令）

✅ 定位讀本已完成並併入 main——本票先前對 A 案的論證，正確答案在這裡

一、總管那句話錯在哪（結論對，理由錯）

二、正確的理由（既有文件早就寫好，我沒去讀）

三、🔴 這是同款錯的第二次，第一次也記在 D37 裡

四、定位的核心判準比預期硬：競爭對手不是 n8n，是「AI 直接寫 Python」

五、順帶查到兩處使用者看得到的死記錄（未修，值得單獨處理）

六、報告自己標的三個未查

🔄 定位更新（leo 2026-08-13 稍晚）——本票先前引用的「跟 Python 比」那條判準作廢

三件改變（每件都改變本票的推理）

對本票的直接影響（好消息）

🟢 leo 2026-08-13 裁定：不是「要不要開」，是「去建」

要交出三件，順序如他所講

✅ 三件已交：ADR ＋ SDD ＋ 連結（leo 2026-08-13 指令）

📄 連結

ADR 記的那個「大的決定」

SDD 為什麼是一份不是兩份

🔴 SDD 鐵律①怎麼處置的

⏸ 等 leo 回一個詞的三件

✅ 三件已交：ADR ＋ SDD ＋連結（leo 2026-08-13 指令）