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>

system-dev/wiki/mistakes.md

@@ -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）