Arcrun 沒有編譯後成品的統一發佈位置，每個 product 只好自己編一份 #80

New Issue

2026-08-09T11:15:52Z

Leo commented

2026-08-09 11:15:52 +00:00

我發現一個問題是：Arcrun 沒有一個「編譯後成品」的統一發佈位置，所以每個用 Arcrun 做的 product 只好自己編一份。

leo 2026-08-09 原話：

「Arcrun RAG 是用 Arcrun 製作的 product，用到 Arcrun 的時候當然是指向真相源，為什麼會自己編譯一組？這個最簡單的架構應該是 Arcrun 編譯好一組放在固定的位置，任何人要安裝只要指明安裝哪一個就去下載編譯後的檔。」
「所有人要下載都來拿 Arcrun 源碼編的統一來源。」

現在是什麼樣

這個 repo 裡放的是原始碼（cypher-executor/src/、kbdb/src/、registry/components/…），沒有對外的編譯成品發佈點
於是 Arcrun RAG 的安裝器自己跑了一套 esbuild（installer/scripts/build-bundles.mjs），從這個 repo 的原始碼路徑編出 worker
⇒ 編譯設定（compat_date／compat_flags／externals／懶載 strip）在 product 那邊獨立維護一份
另外 .component-builds/ 是編譯中間產物，而 .github-public/.component-builds/ 還有第二份拷貝

這已經咬過人（2026-08-09 實錄）

Arcrun RAG 的 stage 環境累積出 24 顆零件、prod 只有 5 顆，leo 裝一次就撞到
其中 19 顆是 1.4.17 時代由 product 那條編譯路徑編出來的舊世代版型，此後沒有任何路徑再編過它們，也沒有任何機制會汰換
更麻煩的是 manifest 的來源標示：source 是頂層單一欄位，單顆沒有自己的來源
⇒ 那 19 顆被標成「來自 Arcrun@19c82df」，實際不是。標籤說 A、實體來自 B，而且沒有地方記得 B 是什麼

要達成什麼

從 Arcrun 原始碼編譯一次，成品放在一個固定位置，所有人都來這裡拿
零件、app、workflow、recipe 四種東西同一套（leo 2026-08-09 指定）
每個成品要答得出「我是哪個版本的原始碼編出來的」——來源要能標到單顆，不是整包一個欄位

怎麼驗

任何 product 端的 repo 裡不存在 esbuild 呼叫——編譯只發生在這裡
同一個 Arcrun commit，任何人任何時候取得的成品逐位元相同
隨便挑一顆成品，能追到它的來源 commit（不是靠整包標籤推測）
全量編譯跑得過：現有所有零件（含那 19 顆的來源）今天都還編得起來
🔴 這一項是整件事的最大未知數——先跑它，結果決定後面工程量是「天」還是「週」

紅線

prod 現在有真人在用（封測者 Oscar、Evan），任何改動不得讓他們手上的東西壞掉
走這個 repo 既有的做法，不要另開一條新路

先解掉一個看起來擋路、其實不擋的東西（2026-08-09 查證）

system-dev/docs/3-specs/arcrun/artifact-sharing/requirements.md:31 寫著：

「零件（component/code）不在此範圍……唯一入口＝fork→PR→人審……永不傳輸/安裝零件程式」

這句話讀起來像是「零件不准從網路分發」，會直接擋掉「公庫＋清單式下載」。但它把 D29 講過頭了。

D29 原文（頂層 system-dev/wiki/decisions-summary.md:219，2026-07-07）：

結論是投稿整層搬進 Leo/arcrun-components，唯一入口＝該 repo 的 PR（merge＝人審閘）
廢除的是 arcrun_publish_component 這條 MCP 零人閘發布路徑
- 理由白紙黑字：「提交即 active/public，MCP 已上 claude.ai 全域＝供應鏈攻擊面」
而同一行接著寫：「merge 後維護者發布進 registry」

⇒ D29 管的是「誰能把新零件放進生態」（投稿），不是「已審過的零件能不能送到用戶那台」（分發）。
分發本來就在 D29 的設計裡，acr init／acr update 現在就在做這件事。

⇒ 本票與 Leo/arcrun-rag#37 的路徑不與 D29 衝突，可以照原設計推進。

要修的是那句措辭：把「永不傳輸/安裝零件程式」改成它真正的意思——
「不從網路安裝未經 PR 人審的零件」。現在的寫法會讓每個讀到的人（含 AI）以為分發被禁，
而這種「規則被讀成比原意更嚴」的誤讀，成本是整條路被誤判為死路。

順帶查到的兩件（另開票處理，記在這裡免得掉）

D29 撞號：decisions-summary.md:219（07-07 零件貢獻分離）與 :224（07-08 Arcrun-first）同一個編號。任何人引用「D29」都不知道指哪一個。
D29 沒有 ADR 檔：頂層 decisions/ 只有 D15/16/17/20/22/23/45，D29 只活在摘要的一行裡。

## 先解掉一個看起來擋路、其實不擋的東西（2026-08-09 查證） `system-dev/docs/3-specs/arcrun/artifact-sharing/requirements.md:31` 寫著： > 「零件（component/code）不在此範圍……唯一入口＝fork→PR→人審……**永不傳輸/安裝零件程式**」這句話讀起來像是「零件不准從網路分發」，會直接擋掉「公庫＋清單式下載」。**但它把 D29 講過頭了。** D29 原文（頂層 `system-dev/wiki/decisions-summary.md:219`，2026-07-07）： - 結論是**投稿**整層搬進 `Leo/arcrun-components`，**唯一入口＝該 repo 的 PR（merge＝人審閘）** - 廢除的是 `arcrun_publish_component` 這條 **MCP 零人閘發布路徑** - 理由白紙黑字：「提交即 active/public，MCP 已上 claude.ai 全域＝**供應鏈攻擊面**」 - 而同一行接著寫：「**merge 後維護者發布進 registry**」 ⇒ **D29 管的是「誰能把新零件放進生態」（投稿），不是「已審過的零件能不能送到用戶那台」（分發）。** 分發本來就在 D29 的設計裡，`acr init`／`acr update` 現在就在做這件事。 ⇒ 本票與 `Leo/arcrun-rag#37` 的路徑**不與 D29 衝突**，可以照原設計推進。 **要修的是那句措辭**：把「永不傳輸/安裝零件程式」改成它真正的意思—— 「不從網路安裝**未經 PR 人審**的零件」。現在的寫法會讓每個讀到的人（含 AI）以為分發被禁，而這種「規則被讀成比原意更嚴」的誤讀，成本是整條路被誤判為死路。 ## 順帶查到的兩件（另開票處理，記在這裡免得掉） - **D29 撞號**：`decisions-summary.md:219`（07-07 零件貢獻分離）與 `:224`（07-08 Arcrun-first）**同一個編號**。任何人引用「D29」都不知道指哪一個。 - **D29 沒有 ADR 檔**：頂層 `decisions/` 只有 D15/16/17/20/22/23/45，D29 只活在摘要的一行裡。

Leo commented

2026-08-09 11:39:48 +00:00

🔴 把這張票收斂成一句話（leo 2026-08-09，取代前面所有繞路）

「整個問題是沒有地方放編譯結果。」
「任何人用 Arcrun 都直接下載，如果有錯，就跟 Arcrun 反應，或 PR。
開源每個人可以編自己的，但我是官方不可以，控管出問題。」

這張票要的東西只有一個：一個放編譯結果的地方。

為什麼「官方不可以自己編」是鐵律，不是偏好

開源使用者各編各的沒問題——編壞了是他自己那台
官方一旦也自己編一份，就有兩個都自稱官方的產物，而它們必然漂移
⇒ 出事時答不出「用戶跑的到底是哪一份」⇒ 控管在這一刻就沒了

08-09 實錄就是這個病的完整發作：安裝器自己編一份 ⇒ stage 累積 19 顆沒人再編過的舊零件
⇒ manifest 卻把它們標成「來自 Arcrun@19c82df」⇒ 標籤說 A、實體來自 B，沒有地方記得 B 是什麼。

因此判準很簡單

官方通路上的每一顆，都出自同一次官方編譯，放在同一個地方
用戶直接下載那個地方的東西——不經過任何「某某產品自己編的」中間層
有錯就回報 Arcrun 或送 PR，修在源頭、重編一次、所有人一起換

前面那段 D29 考據與本票無關

（2026-08-09 總管自己繞出來的枝節，leo 當場拉回。留著只會讓下一個人以為這裡有個授權問題要先解——沒有。）

## 🔴 把這張票收斂成一句話（leo 2026-08-09，取代前面所有繞路） > 「整個問題是**沒有地方放編譯結果**。」 > 「任何人用 Arcrun 都直接下載，如果有錯，就跟 Arcrun 反應，或 PR。 > **開源每個人可以編自己的，但我是官方不可以，控管出問題。**」 **這張票要的東西只有一個：一個放編譯結果的地方。** ## 為什麼「官方不可以自己編」是鐵律，不是偏好 - 開源使用者各編各的沒問題——**編壞了是他自己那台** - 官方一旦也自己編一份，就有**兩個都自稱官方的產物**，而它們必然漂移 - ⇒ 出事時答不出「用戶跑的到底是哪一份」⇒ **控管在這一刻就沒了** 08-09 實錄就是這個病的完整發作：安裝器自己編一份 ⇒ stage 累積 19 顆沒人再編過的舊零件 ⇒ manifest 卻把它們標成「來自 `Arcrun@19c82df`」⇒ **標籤說 A、實體來自 B，沒有地方記得 B 是什麼**。 ## 因此判準很簡單 - 官方通路上的每一顆，都出自**同一次官方編譯**，放在**同一個地方** - 用戶直接下載那個地方的東西——**不經過任何「某某產品自己編的」中間層** - 有錯就回報 Arcrun 或送 PR，修在源頭、重編一次、所有人一起換 ## 前面那段 D29 考據與本票無關（2026-08-09 總管自己繞出來的枝節，leo 當場拉回。留著只會讓下一個人以為這裡有個授權問題要先解——沒有。）

Leo commented

2026-08-09 13:10:28 +00:00

[總管·票務複驗 2026-08-09 晚] 票面成立，但要講精確一點：不是「完全沒有」，是「有一半，而缺的正好是被拿去自己編的那一半」。

已經有統一發佈位置的那一半 —— tier1 零件（TinyGo → wasm）

$ ls .component-builds/ | wc -l
19        （array_ops／auth_oauth2／auth_static_key／claude_api …）

這些是刻意 commit 進版控的（.gitignore 用否定規則放行 !.component-builds/**/component.wasm），
理由白紙黑字寫在 .claude/rules/05-deploy-convention.md：就是為了讓 self-host 用戶直接從 repo 拿。

❌ 缺的那一半 —— tier2 worker（TS → 可部署的 JS）

$ ls cypher-executor/dist kbdb/dist
No such file or directory   （兩個都沒有）

⇒ Arcrun 這邊只有 src，沒有任何編好的 worker 成品。
⇒ 所以 arcrun-rag 的安裝器只好自己 esbuild（installer/scripts/build-bundles.mjs:139），
　而編譯設定（compat_date／compat_flags／externals／懶載 strip）就在安裝器那邊獨立維護了一份。

這正是本票與 arcrun-rag#39 的接縫：#39 說「安裝端不該自己編」，
本票要回答「那該去哪裡拿」——而現在那個地方對 tier2 來說不存在。

今天（08-09）的相關實證

arcrun-rag 出貨 1.4.29，manifest 的 source 是 Arcrun@19c82df，
但那五顆 core worker 的位元組是安裝器當場 esbuild 出來的，不是從 Arcrun 拿的成品。
⇒ 「同一個 Arcrun 版本，任何人任何時候組出來的 bundle 逐位元相同」這個目標目前無法成立。

順帶：現有那一半也有保鮮問題

tier1 的 wasm 對外靠 jsDelivr 服務公開鏡像，而公開鏡像是人手動 push 的（發佈鏡像那支腳本＋ D20 人閘）。
repo 裡已經有一支 publish-lag-check.sh 專門為這個病而存在。
⇒ 就算 tier2 補上編好的成品，只要發佈仍是手動，同一個病會在新的一半重演。
⇒ 建議本票的成功標準把「發佈這件事不靠人記得」一起寫進去。

[總管·票務複驗 2026-08-09 晚] 票面成立，但**要講精確一點：不是「完全沒有」，是「有一半，而缺的正好是被拿去自己編的那一半」。** ## 已經有統一發佈位置的那一半 —— tier1 零件（TinyGo → wasm） ``` $ ls .component-builds/ | wc -l 19 （array_ops／auth_oauth2／auth_static_key／claude_api …） ``` 這些是**刻意 commit 進版控**的（`.gitignore` 用否定規則放行 `!.component-builds/**/component.wasm`），理由白紙黑字寫在 `.claude/rules/05-deploy-convention.md`：就是為了讓 self-host 用戶直接從 repo 拿。 ## ❌ 缺的那一半 —— tier2 worker（TS → 可部署的 JS） ``` $ ls cypher-executor/dist kbdb/dist No such file or directory （兩個都沒有） ``` ⇒ **Arcrun 這邊只有 src，沒有任何編好的 worker 成品。** ⇒ 所以 `arcrun-rag` 的安裝器只好自己 `esbuild`（`installer/scripts/build-bundles.mjs:139`），　而編譯設定（compat_date／compat_flags／externals／懶載 strip）就在安裝器那邊獨立維護了一份。 **這正是本票與 `arcrun-rag#39` 的接縫**：#39 說「安裝端不該自己編」，本票要回答「那該去哪裡拿」——而現在那個地方對 tier2 來說**不存在**。 ## 今天（08-09）的相關實證 `arcrun-rag` 出貨 1.4.29，manifest 的 `source` 是 `Arcrun@19c82df`，但那五顆 core worker 的位元組**是安裝器當場 esbuild 出來的**，不是從 Arcrun 拿的成品。 ⇒ 「同一個 Arcrun 版本，任何人任何時候組出來的 bundle 逐位元相同」這個目標目前無法成立。 ## 順帶：現有那一半也有保鮮問題 tier1 的 wasm 對外靠 jsDelivr 服務公開鏡像，而公開鏡像是**人手動 push** 的（發佈鏡像那支腳本＋ D20 人閘）。 repo 裡已經有一支 `publish-lag-check.sh` 專門為這個病而存在。 ⇒ **就算 tier2 補上編好的成品，只要發佈仍是手動，同一個病會在新的一半重演。** ⇒ 建議本票的成功標準把「發佈這件事不靠人記得」一起寫進去。

Leo referenced this issue from a commit

2026-08-10 16:59:32 +00:00

feat(ship): 出貨報告左右對照表＋arm 前可確認會過（D65 二次補述，arcrun-rag#73）

Leo commented

2026-08-12 10:42:12 +00:00

🔴 leo 2026-08-12 深夜拍板：worker 就是零件，位置只有一個，arcrun-rag 不做零件

leo 原話（兩句，本票的收工標準以此為準）：

「如果 worker 是直接複製在一個地方，它也就是個零件，如果它列在安裝的幾顆裡面，
它就是 Arcrun 的事，cypher-executor 就是一顆大零件，做成 Worker 也是要放固定位置。
Arcrun RAG 不管做零件。」

「Arcrun RAG 是用 Arcrun 產生的產品，而它一直在重複做 Arcrun 的工作。」

這兩句解掉了本票與 `arcrun-rag#39` 的互指死結

本票 08-09 的複驗留言自己寫著：

這正是本票與 arcrun-rag#39 的接縫：#39 說「安裝端不該自己編」，
本票要回答「那該去哪裡拿」——而現在那個地方對 tier2 來說不存在。

⇒ 兩張票互相等對方當前置，所以三天一格都沒動（#39 08-09 複驗原文：「本票沒有人動工」）。
leo 這兩句把它變成一張票、一個owner：歸 Arcrun，本票就是那張。

tier1／tier2 這個分法本身要作廢

本票原本的框架是「tier1 零件有統一位置、tier2 worker 沒有」。
照 leo 的定義，那不是兩層，是同一層——worker 只是比較大的零件。

實查現況（2026-08-12 深夜，matrix/arcrun）：

.component-builds/      19 顆，其中 18 顆 component.wasm 在 git 版控裡   ← 已經做對的樣板
cypher-executor/dist    不存在
kbdb/dist               不存在

⇒ 要做的不是「發明 tier2 的發佈方式」，是把 worker 照 .component-builds/ 已經在用的那套辦。
樣板已經存在（.gitignore 否定規則放行＋ .claude/rules/05-deploy-convention.md），不必重新設計。

收工標準（改寫，取代舊的）

cypher-executor、kbdb（以及安裝清單裡的每一顆 worker）在 Arcrun 有編好的成品、
放在與零件同一套規則的固定位置、進版控
arcrun-rag 的 repo 裡沒有任何 esbuild 呼叫（那是 #39 的驗法，它要靠本票才過得了）
同一個 Arcrun 版本，任何人任何時候組出來的 bundle 逐位元相同（本票 08-09 自己列的目標）
🔴 發佈不靠人記得——本票 08-09 已經提醒過：現有那一半的 wasm 對外靠 jsDelivr 公開鏡像，
而鏡像是人手動 push 的（publish-lag-check.sh 就是為這個病而存在）。
tier2 補上成品但發佈仍手動 ⇒ 同一個病在新的一半重演。

為什麼這張票不能再排進「出貨線」那組

leo 08-12 把出貨降級成「沒出錯即可，先不要細修」。但本票不是出貨的細修，它是地基：

#89（寫回 Gitea repo）／#90（部署 Worker）／#91（算內容雜湊）三顆零件缺 ⇒
出貨線 9 站搬不上 Arcrun ⇒ arcrun-rag 只好自己寫 installer/scripts/ship.mjs（19 站手寫 Node）
那支腳本現在跑到 16/19 綠——夠好用了，所以沒有人會回頭去補零件
⇒ 每繞過一次，Arcrun 就少長一顆零件，arcrun-rag 就多一份複製品。
而 arcrun-rag 是 Arcrun 的第一個顧客，它自己解決了＝Arcrun 失去唯一的真實需求來源

📌 arcrun-rag#39 維持開著，但它的定位改成「移除那份違規實作」，明確 blocked by 本票——
先有地方可拿，才談得上不自己編。

—— [總管]

## 🔴 leo 2026-08-12 深夜拍板：**worker 就是零件，位置只有一個，arcrun-rag 不做零件** leo 原話（兩句，本票的收工標準以此為準）： > 「如果 worker 是直接複製在一個地方，**它也就是個零件**，如果它列在安裝的幾顆裡面， > **它就是 Arcrun 的事**，**cypher-executor 就是一顆大零件**，做成 Worker 也是要放固定位置。 > **Arcrun RAG 不管做零件。**」 > 「**Arcrun RAG 是用 Arcrun 產生的產品，而它一直在重複做 Arcrun 的工作。**」 ### 這兩句解掉了本票與 `arcrun-rag#39` 的互指死結本票 08-09 的複驗留言自己寫著： > 這正是本票與 `arcrun-rag#39` 的接縫：#39 說「安裝端不該自己編」， > 本票要回答「那該去哪裡拿」——而現在那個地方對 tier2 來說不存在。 ⇒ 兩張票**互相等對方當前置，所以三天一格都沒動**（#39 08-09 複驗原文：「本票沒有人動工」）。 leo 這兩句把它變成**一張票、一個owner**：**歸 Arcrun，本票就是那張。** ### tier1／tier2 這個分法本身要作廢本票原本的框架是「tier1 零件有統一位置、tier2 worker 沒有」。 **照 leo 的定義，那不是兩層，是同一層——worker 只是比較大的零件。** 實查現況（2026-08-12 深夜，`matrix/arcrun`）： ``` .component-builds/ 19 顆，其中 18 顆 component.wasm 在 git 版控裡 ← 已經做對的樣板 cypher-executor/dist 不存在 kbdb/dist 不存在 ``` ⇒ **要做的不是「發明 tier2 的發佈方式」，是把 worker 照 `.component-builds/` 已經在用的那套辦。** 樣板已經存在（`.gitignore` 否定規則放行＋ `.claude/rules/05-deploy-convention.md`），不必重新設計。 ### 收工標準（改寫，取代舊的） 1. `cypher-executor`、`kbdb`（以及安裝清單裡的每一顆 worker）在 Arcrun 有**編好的成品**、放在**與零件同一套規則**的固定位置、進版控 2. **`arcrun-rag` 的 repo 裡沒有任何 `esbuild` 呼叫**（那是 `#39` 的驗法，它要靠本票才過得了） 3. 同一個 Arcrun 版本，**任何人任何時候組出來的 bundle 逐位元相同**（本票 08-09 自己列的目標） 4. 🔴 **發佈不靠人記得**——本票 08-09 已經提醒過：現有那一半的 wasm 對外靠 jsDelivr 公開鏡像，而鏡像是**人手動 push** 的（`publish-lag-check.sh` 就是為這個病而存在）。 **tier2 補上成品但發佈仍手動 ⇒ 同一個病在新的一半重演。** ### 為什麼這張票不能再排進「出貨線」那組 leo 08-12 把出貨降級成「沒出錯即可，先不要細修」。**但本票不是出貨的細修，它是地基**： - `#89`（寫回 Gitea repo）／`#90`（部署 Worker）／`#91`（算內容雜湊）三顆零件缺 ⇒ 出貨線 9 站搬不上 Arcrun ⇒ arcrun-rag 只好自己寫 `installer/scripts/ship.mjs`（19 站手寫 Node） - 那支腳本現在跑到 16/19 綠——**夠好用了，所以沒有人會回頭去補零件** - ⇒ **每繞過一次，Arcrun 就少長一顆零件，arcrun-rag 就多一份複製品。** 而 arcrun-rag 是 Arcrun 的第一個顧客，**它自己解決了＝Arcrun 失去唯一的真實需求來源** 📌 `arcrun-rag#39` 維持開著，但它的定位改成「**移除那份違規實作**」，明確 **blocked by 本票**—— 先有地方可拿，才談得上不自己編。 —— [總管]

Leo commented

2026-08-12 12:12:57 +00:00

🔴 leo 2026-08-12 深夜再擴範圍：installer 也歸 Arcrun，因為 arcrun-rag 是木馬屠城

leo 原話（兩句，順序有意義）：

①「這個 installer 其實就是安裝 Arcrun ＋一些 RAG 的工作流，實際上也是應該歸屬在 Arcrun，
重點是 Arcrun 是框架，它把框架綁了一些應用，可以說大部分在 Arcrun，少部分在 Arcrun RAG。」

②「很早就判過了，Arcrun RAG 是個木馬屠城，因為大家要的是應用不是框架，
所以把框架包在應用中推廣。」

第 ② 句解釋了為什麼這個病治不好

先前本票（與 arcrun-rag#39）把問題描述成「arcrun-rag 又去自己編零件」，
彷彿那是紀律問題——只要它自律一點就會好。

不是。 照 ② 的定位，arcrun-rag 根本不是「一個用了 Arcrun 的產品」，
它是 Arcrun 的載具：把框架包進應用裡才推得動。

⇒ 那個 repo 會一直重複做 Arcrun 的工作，是結構性的必然，不是誰不守規矩。
⇒ 所以修法不是「叫它別做」，是「移交」：東西本來就該長在 Arcrun，
arcrun-rag 只留真正屬於 RAG 應用層的那薄薄一層。

具體邊界（照 ① 的分法）

東西	歸屬
安裝器本體（建資源、部署 worker、注入金鑰、種 credential、版本/更新流程）	Arcrun——它裝的就是框架
tier1 零件（wasm）＋ tier2 worker 成品的編譯與發佈	Arcrun（本票原有範圍；`scripts/build-worker-artifacts.mjs` 已存在）
出貨管線本身（`ship.mjs` 19 站）	Arcrun——它出的是框架的貨（缺件見 `#89`／`#90`／`#91`）
那幾支 RAG 專用工作流（ingest／萃取／問答）	arcrun-rag（＝「少部分」）

本票今晚已有的實質進展

✅ scripts/build-worker-artifacts.mjs 證實存在且可用——它就是本票要的
「tier2 唯一官方編譯點」，成品進 .worker-builds/、每顆自記 source_commit。
⇒ 本票的「有一半」那半，機制其實已經做出來了；缺的是 arcrun-rag 切過去用它（#39）
✅ 今晚實跑一次，5/5 重編成功，cypher／kbdb／mcp 三顆 source=10d150ac（＝#105），
並用 installer/scripts/artifact-freshness.mjs（#93 的閘）複驗 blocking = 0

順手記一個 fail-open（未修，待裁要不要開票）

checkArtifactFreshness({ repo, manifest, components }) 的 components || []
—— 呼叫端沒傳 components 就迭代空陣列、回 ok: true。
今晚總管第一次呼叫就拿到「檢查 0 顆卻通過」的假綠。
ship.mjs:472 有正確傳，所以不是活的 bug，但安全檢查的預設應該是 fail-closed。

—— [總管]

## 🔴 leo 2026-08-12 深夜再擴範圍：**installer 也歸 Arcrun，因為 arcrun-rag 是木馬屠城** leo 原話（兩句，順序有意義）： > ①「這個 installer 其實就是**安裝 Arcrun ＋一些 RAG 的工作流**，實際上**也是應該歸屬在 Arcrun**， > 重點是 **Arcrun 是框架，它把框架綁了一些應用**，可以說**大部分在 Arcrun，少部分在 Arcrun RAG**。」 > > ②「很早就判過了，**Arcrun RAG 是個木馬屠城**，因為**大家要的是應用不是框架， > 所以把框架包在應用中推廣**。」 ### 第 ② 句解釋了為什麼這個病治不好先前本票（與 `arcrun-rag#39`）把問題描述成「arcrun-rag 又去自己編零件」，彷彿那是紀律問題——**只要它自律一點就會好**。 **不是。** 照 ② 的定位，`arcrun-rag` 根本不是「一個用了 Arcrun 的產品」，它是 **Arcrun 的載具**：把框架包進應用裡才推得動。 ⇒ **那個 repo 會一直重複做 Arcrun 的工作，是結構性的必然，不是誰不守規矩。** ⇒ 所以修法**不是「叫它別做」，是「移交」**：東西本來就該長在 Arcrun， arcrun-rag 只留真正屬於 RAG 應用層的那薄薄一層。 ### 具體邊界（照 ① 的分法） | 東西 | 歸屬 | |---|---| | 安裝器本體（建資源、部署 worker、注入金鑰、種 credential、版本/更新流程） | **Arcrun**——它裝的就是框架 | | tier1 零件（wasm）＋ tier2 worker 成品的編譯與發佈 | **Arcrun**（本票原有範圍；`scripts/build-worker-artifacts.mjs` 已存在） | | 出貨管線本身（`ship.mjs` 19 站） | **Arcrun**——它出的是框架的貨（缺件見 `#89`／`#90`／`#91`） | | 那幾支 RAG 專用工作流（ingest／萃取／問答） | **arcrun-rag**（＝「少部分」） | ### 本票今晚已有的實質進展 - ✅ **`scripts/build-worker-artifacts.mjs` 證實存在且可用**——它就是本票要的「tier2 唯一官方編譯點」，成品進 `.worker-builds/`、每顆自記 `source_commit`。 ⇒ **本票的「有一半」那半，機制其實已經做出來了**；缺的是 **arcrun-rag 切過去用它**（`#39`） - ✅ 今晚實跑一次，5/5 重編成功，`cypher`／`kbdb`／`mcp` 三顆 `source=10d150ac`（＝`#105`），並用 `installer/scripts/artifact-freshness.mjs`（`#93` 的閘）複驗 `blocking = 0` ### 順手記一個 fail-open（未修，待裁要不要開票） `checkArtifactFreshness({ repo, manifest, components })` 的 `components || []` —— **呼叫端沒傳 `components` 就迭代空陣列、回 `ok: true`**。今晚總管第一次呼叫就拿到「檢查 0 顆卻通過」的假綠。 `ship.mjs:472` 有正確傳，所以不是活的 bug，但**安全檢查的預設應該是 fail-closed**。 —— [總管]

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Blocks

You do not have permission to read 1 dependency

Reference: Leo/Arcrun#80

Arcrun 沒有編譯後成品的統一發佈位置，每個 product 只好自己編一份 #80

現在是什麼樣

這已經咬過人（2026-08-09 實錄）

要達成什麼

怎麼驗

紅線

相關

先解掉一個看起來擋路、其實不擋的東西（2026-08-09 查證）

順帶查到的兩件（另開票處理，記在這裡免得掉）

🔴 把這張票收斂成一句話（leo 2026-08-09，取代前面所有繞路）

為什麼「官方不可以自己編」是鐵律，不是偏好

因此判準很簡單

前面那段 D29 考據與本票無關

已經有統一發佈位置的那一半 —— tier1 零件（TinyGo → wasm）

❌ 缺的那一半 —— tier2 worker（TS → 可部署的 JS）

今天（08-09）的相關實證

順帶：現有那一半也有保鮮問題

🔴 leo 2026-08-12 深夜拍板：worker 就是零件，位置只有一個，arcrun-rag 不做零件

這兩句解掉了本票與 arcrun-rag#39 的互指死結

tier1／tier2 這個分法本身要作廢

收工標準（改寫，取代舊的）

為什麼這張票不能再排進「出貨線」那組

🔴 leo 2026-08-12 深夜再擴範圍：installer 也歸 Arcrun，因為 arcrun-rag 是木馬屠城

第 ② 句解釋了為什麼這個病治不好

具體邊界（照 ① 的分法）

本票今晚已有的實質進展

順手記一個 fail-open（未修，待裁要不要開票）

這兩句解掉了本票與 `arcrun-rag#39` 的互指死結