docs(wiki): 記錄 acr update 部署源綁 GitHub codeload 的框架級發現（mistakes #23）
雲端工人跑 Arcrun#3 控制台頁時發現：acr update 部署物永遠從 GitHub codeload tarball 抓，跟本地/Gitea checkout 脫鉤——D20 鎖死 GitHub 的雲端工人若照字面 指示部署會蓋掉自己的改動卻回報成功（假綠）。本次改手工複刻注入邏輯部署 單一 worker 繞過此坑，記錄供下次沿用；多 worker 場景正解留 leo 裁。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Claude
@@ -475,6 +475,43 @@ array-of-tables（`[[x]]`）不用 inline array。改 toml 後用 `wrangler --dr
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 23. `acr update` 部署源＝GitHub codeload，不是本地/Gitea checkout（2026-07-02，Arcrun#3 雲端壓測）
|
||||
|
||||
**背景**：雲端工人（cloud-worker，只能碰 Gitea，GitHub 受 D20 鎖死）在 Gitea 本地改完 `cypher-executor/src/routes/console.ts`
|
||||
後想照 issue 指示跑 `acr update` 部署，才發現 `cli/src/lib/deploy.ts downloadRepoTarball()` **永遠從
|
||||
`https://codeload.github.com/uncle6me-web/Arcrun/tar.gz/main` 抓部署物**，完全不讀本機/任何本地 checkout
|
||||
的 git 狀態——「改了 Gitea 的 code」和「acr update 部署的 code」是兩條互不相干的路徑。
|
||||
|
||||
**錯誤模式**：以為「本地改完 code → acr update」就會部署到新 code（跟一般 `git push && deploy` 直覺相反）。
|
||||
`acr update` 的心智模型其實是「拉官方 GitHub release」，不是「部署我剛編輯的目錄」。
|
||||
|
||||
**後果**：雲端工人若真的信了直覺跑 `acr update`，會部署**舊的 GitHub 版本**，蓋掉／忽略掉自己剛做的修改，
|
||||
卻因為 wrangler deploy 回報成功而誤判「已上線」——經典假綠（同 #19 精神，但根因在「部署源選錯」而非「端點死」）。
|
||||
|
||||
**正確做法（本次採用，避免碰 GitHub 又要讓本地改動生效）**：
|
||||
1. 手動複刻 `injectWranglerConfig` 的注入邏輯（KV id／WORKER_SUBDOMAIN／MULTI_TENANT／KBDB_BASE_URL／
|
||||
strip `[[routes]]`+`[[r2_buckets]]`+`[ai]`），`wrangler kv namespace list`／CF API 查真實 KV id 對齊。
|
||||
2. 直接在本地 worker 目錄（如 `cypher-executor/`）patch 一份 `wrangler.toml`（**先備份**），
|
||||
`wrangler deploy --dry-run` 核對 binding 與 CF API 讀到的既有線上設定一致，再真部署。
|
||||
3. 部署完**立刻 restore 備份**，確保 git 追蹤的 `wrangler.toml` 不留下帳號專屬 id（KV id 雖非機密，
|
||||
但不該混進 git 歷史）。
|
||||
4. 這條路只適合「單一 worker 的小改動」；牽動多 worker（tier1 component + tier2 全套）改動時，
|
||||
人工複刻的成本會接近重寫 deploy.ts，屆時應該讓 leo 決定要不要開一條「本地/Gitea 來源」的部署路徑
|
||||
（跨專案結構決策，四題命中，不該 CC 自己裁）。
|
||||
|
||||
**懸而未決（等 leo 裁，非本次阻塞項）**：`acr update` 硬綁 GitHub 這件事，跟 InkStoneCo D20「cloud-worker
|
||||
只碰 Gitea」的架構前提有結構性衝突——只要開發者在 Gitea 改 code，`acr update`／`acr init --self-hosted`
|
||||
就永遠部署不到最新版，除非有人（leo）把 Gitea main 同步回 GitHub 再切新 release，或改 `ARCRUN_REPO`/
|
||||
下載來源支援 Gitea tarball。這是「部署繞開 GitHub」鐵律 vs 「acr CLI 用 codeload.github.com 當唯一部署源」
|
||||
的真實矛盾，非本次任務能力範圍解決，留給 leo 裁後續方向。
|
||||
|
||||
**通用教訓**：CLI／routine 文件寫的操作步驟（如「跑 acr update」）背後可能藏著跟直覺不符的資料來源假設；
|
||||
碰到「部署完 curl 卻沒看到改動」先查「這個部署命令到底從哪裡抓 code」，別預設「本地改了=會生效」。
|
||||
|
||||
---
|
||||
|
||||
## 快速檢查清單（做新功能前）
|
||||
|
||||
- [ ] 這是工作流還是零件？問「有必要嗎？」
|
||||
@@ -493,3 +530,4 @@ array-of-tables（`[[x]]`）不用 inline array。改 toml 後用 `wrangler --dr
|
||||
- [ ] 改 wrangler.toml service binding？用 [[services]] 不用 inline services=[...]（[vars] 後會被吸走）；改完 wrangler --dry-run 驗 binding 真在（#21）
|
||||
- [ ] 退役/降級某零件？同步清「AI 搜尋零件的三個源」＝示例 yaml + parts.ts 硬編碼清單 + （validate 跳過是設計）；別只改一處宣布完成（#22）
|
||||
- [ ] 沒對應 recipe？誠實留 TODO + 發 issue 補 seed，別硬塞語意不符的 canonical_id 充數（假綠，#22）
|
||||
- [ ] 本地/Gitea 改完 code 想 `acr update` 部署？先確認：它抓的是 GitHub codeload tarball，不是你剛改的目錄（#23）
|
||||
|
||||
@@ -3,7 +3,7 @@ name: status
|
||||
description: 當前進度、進行中 Phase、已知問題、下一步（動態文件，每 session 更新）
|
||||
metadata:
|
||||
type: project
|
||||
last_updated: 2026-06-28
|
||||
last_updated: 2026-07-02
|
||||
---
|
||||
|
||||
# 當前進度（動態）
|
||||
@@ -15,7 +15,14 @@ metadata:
|
||||
|
||||
## 📍 當前位置
|
||||
|
||||
> **2026-06-28 本 session（issue #13 零件退役殘留收尾，步驟1+2 done）**：
|
||||
> **2026-07-02 本 session（雲端工人 T-loop1d，Arcrun#3 搜尋/控制台頁 v0，跨多 repo 第二次壓測）**：
|
||||
> - **實作**：`cypher-executor/src/routes/console.ts`（GET /console，單檔 HTML+原生 JS 薄殼）+ `index.ts` 掛載。三查詢區全打既有端點：`/kbdb/search`、`/workflows/search`（同源，X-Arcrun-API-Key）、components 打「同帳號」`arcrun-registry.<subdomain>.workers.dev`（WORKER_SUBDOMAIN 現算，不硬打官方 registry.arcrun.dev）、recipes 打 `/public-recipes`（公庫免 auth）。vectorize 狀態直接讀 KBDB search 回應的 `mode`/`capability_hint`，沒開新端點。tsc/vitest 綠（既有 1 個無關失敗，`不存在的零件回傳失敗` 測試，stash 驗證 pre-existing）。commit `981dc25` 已 push Gitea main。
|
||||
> - **框架級發現（mistakes #23）**：`acr update` 部署源永遠是 GitHub codeload tarball（`uncle6me-web/Arcrun` main），跟本地/Gitea checkout 完全脫鉤——雲端工人只能碰 Gitea（D20），照 issue 字面指示跑 `acr update` 會部署到蓋掉自己剛做的改動的舊版，回報成功卻是假綠。本次改用手工複刻 `injectWranglerConfig` 注入邏輯（CF API 查真實 KV id 對齊 dry-run）、直接 `wrangler deploy` 單一 worker（cypher-executor），避免碰 GitHub 又讓改動真的上線；部署後立刻 restore `wrangler.toml`，不留帳號 id 進 git。**此路只適合單 worker 小改動**；牽動多 worker 時的正解懸而未決，留 leo 裁（部署繞開 GitHub 鐵律 vs acr CLI 硬綁 codeload.github.com 的結構性衝突）。
|
||||
> - **端到端驗證（leo21c，curl 證據）**：`GET /console` 200；`GET /kbdb/search?mode=semantic` 200（誠實降級 keyword + capability_hint，該帳號 KBDB 目前 0 entries，真實狀態非 bug）；`GET /workflows/search` 200（0 筆，該帳號無 named workflow）；`GET /public-recipes?q=telegram` 200 真回 `telegram_send` 紀錄；`GET arcrun-registry.leo21c.workers.dev/components/search` 200。Playwright 瀏覽器點擊測試因沙盒 outbound proxy policy 擋 registry.arcrun.dev/workers.dev 連線未能跑通（環境限制，非部署問題），改以 curl 逐端點驗證 + 手動覆閱 JS 邏輯替代。
|
||||
> - **SDD 缺口**：issue 要求新 SDD 目錄 `docs/3-specs/arcrun/search-console/` + 改 pre-write-guard `KNOWN_SDDS` 白名單——但本 repo 整個 `docs/` 與 `.claude/` 都在 `.gitignore`（只存在 leo 本機），Gitea clone 拿不到，也無法確認 SDD 白名單機制實際路徑。未落地此步驟，回報 issue，等本機 CC 或 leo 補。
|
||||
> - Arcrun#3 issue comment 已回報（署名 `[cloud-worker]`），sprint 表 T-loop1d 已勾。
|
||||
|
||||
> **2026-06-28 上個 session（issue #13 零件退役殘留收尾，步驟1+2 done）**：
|
||||
> - **issue #13 步驟1（merge caa8e10）**：3 個示例 yaml 的 `component: telegram` → recipe canonical_id `telegram_send`（commit a234201）。
|
||||
> - **issue #13 步驟2（merge 764f657）**：清 `cli/src/commands/parts.ts` 降級零件殘留——telegram/gmail/sheets/line 改 recipe canonical_id、移除已刪的 ai_transform_compile/run（commit 225aa9f）。
|
||||
> - **關鍵發現①（gmail 假綠避免）**：gmail **讀取**（`fetch_unread` / `action: list`）**無對應 recipe**，硬塞 `gmail_send`（寄信）＝語意不符的假綠 → **留 TODO 待 seed 補 `gmail_list`**，不硬塞。
|
||||
|
||||
Reference in New Issue
Block a user