 uncle6me-web
|
5d441aa7d3
|
fix(teardown): 中心側補上帳號白名單——原本 central-* 碰得到 leo21c
實測破口（2026-08-14，修補前）：
central-plan --account-id 51a01bfa…(leo21c)
→ 一路暢通，列出 deployed:51a01bfa…:leo21c
加 --yes 就會刪掉 leo 的安裝紀錄 ⇒ 他下次重裝撞 Arcrun#120 死結。
根因是兩個問題被當成同一個：
① 動的是「誰的」紀錄 → assertAccountAllowed（帳號側有，中心側沒有）
② 以「誰的身分」動手 → assertWranglerIsCentralAccount（D88 補的那道）
c543aba 的註解寫「這個不對稱現在補齊」，但只補了②。註解說補齊、程式補一半，
後來讀的人會相信註解——所以順手把那段註解改成實測講法。
另修 listAllScripts 沒翻頁（ops-facts 記過的同款坑）。在這支工具裡漏看一顆
worker 有兩層傷害：拆不乾淨，以及「共用資源保護」看不到那個 owner，
把還在用的資源判成沒人用而刪掉。
並補一條已知限制：資源清單是從 worker binding 反推、不掃帳號，
所以沒人綁的孤兒殘骸不會被列也不會被刪（這正是 drill-a/drill-b 不受影響的原因，
但代價是拆完重裝可能撞 Arcrun#123，要自己再列一次帳號）。
驗證（youlin，全唯讀，未執行 apply）：
- plan：6 顆 worker ＋ 10 個資源（8 顆 yuga3bse KV／yuga3bse-db／embed-m3），
drill-a、drill-b 不在清單
- leo21c 帳號側、中心側 兩條路徑皆 exit 1 拒絕
- youlin 中心側仍正常：staging 通道有 deployed:1129efd7…:youlin-hsieh-dev 一筆
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-14 19:51:31 +08:00 |
|
|
uncle6me-web
|
c543abaa8a
|
fix(teardown): central KV 操作前機械核對 wrangler 身分（D88，leo 審核裁示①，必修項）
leo 審核意見：「這條正好違反 D88——閘要長在機器上，不是長在誰的記性上。而且失敗模式
是最壞的那種：靜默打錯帳號的中心 KV，沒有任何東西會叫。帳號側有白名單擋、中心側完全
沒有——這個不對稱本身就是設計缺口。」
修法：assertWranglerIsCentralAccount() 在 planCentralCleanup()（central-plan／
central-apply 共用的入口）最前面跑 `wrangler whoami --json`，核對登入態的帳號清單裡
有 uncle6（58309bb90fd93ad6d0fe0aae99170e9d）才放行，沒有就丟錯拒絕整個操作。
已用模擬錯誤帳號 id 驗證比對邏輯正確拒絕；正常路徑（真的登入 uncle6）central-plan
照常運作，貼在同一次 commit 的測試輸出裡。
同時把 leo 裁示②（apply 的依賴序失敗不擋併、但要記實測輪數）補進「已知限制」段：
兩次實測收斂輪數分別是 2 輪（有外部依賴殘留時）與 3 輪（純內部 service binding 鏈時）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-14 14:29:03 +08:00 |
|
|
uncle6me-web
|
49248b18c5
|
docs(teardown): 記下兩層咬合的已知限制（跨 worker 依賴鏈，2026-08-14 實撞）
今天實跑撞到、也解掉的真事：kbdb-graph-plugin（不屬於這台實例，正確被排除不動）
身上有 service binding 指著 arcrun-kbdb（要刪的）→ CF 拒絕刪除，本工具只回報那次
DELETE 失敗，不會主動點出「有外部依賴卡住」。若選擇半殘留（清資源留殼），下一步
acr init/update 的 resource-rule fail-closed 保護會正確拒絕重裝——這是它該有的行為，
但代表本工具留下的半殘留會讓下一步卡住，不是「拆一半也沒關係」。
本工具目前無法自動偵測跨 worker 依賴鏈，寫進「已知限制」而不是假裝判準完備。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-14 14:20:56 +08:00 |
|
|
uncle6me-web
|
05e879faa7
|
fix(teardown): 拿掉 wrangler kv key delete 的 --force（這版 wrangler 沒這個 flag）
實跑撞到：這台裝的 wrangler 4.100.0 的 `kv key delete` 沒有 --force，帶了就直接
「Unknown argument: force」失敗。central-apply 兩個通道各撞一次才發現。
拿掉 --force 後在真實 youlin 帳號實測：central-apply 兩個通道（prod INSTALLER_KV
+ staging PEER_INSTALLER_KV）的 deployed:<accountId>: 紀錄都刪除成功，central-plan
複驗兩邊皆印「沒有殘留紀錄」。這是 Arcrun#120 死結修復鏈路的必要一步。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-14 14:13:39 +08:00 |
|
|
uncle6me-web
|
7498911856
|
WIP: 內部 uninstaller 工具（拆帳號側 + 中心 KV），尚未跑過 apply（Arcrun#119/#120/#122）
leo 交辦：先做出「拆乾淨→重裝」的內部工具，在 youlin 帳號上自己能用即可，
不是產品（對外版另計）。D82 三步驗收（全新安裝→更新→解除安裝）需要拆的能力才測得到，
沒有它就永遠測不到 #119/#120 這類「只有全新用戶才撞得到」的坑。
目前做到：
- scripts/teardown-instance.mjs：
- plan/apply 兩階段（預設唯讀只印清單，真要刪要 apply --yes）
- 帳號白名單（只認 youlin，明確擋 leo21c）
- 歸屬判準：worker 名字要出現在本 repo wrangler*.toml 或官方 bundle manifest.core[]
才算「已知」，不認得的一律列出不動（例如 kbdb-graph-plugin，不屬於這台實例）
- 共用資源保護：同一顆 KV/D1/Vectorize 若也被「保留中的 worker」綁著，排除不刪
- central-plan/central-apply：清中心 INSTALLER_KV／PEER_INSTALLER_KV 的
deployed:<accountId>: 紀錄（#120 死結的另一半，帳號側清了但這裡沒清會卡死重裝）
- 已用 `plan` 在 youlin 帳號實跑過（唯讀），清單看起來合理，貼在 issue/回報裡
還沒做：
- apply（真的刪）、central-apply、以及刪完後的重裝驗證，全部還沒跑
- 已知限制列在檔頭註解：判準是「repo 認不認得」不是「屬於哪一台實例」，
同帳號多台同名慣例實例分不出來（今天 youlin 上短暫同時有正式實例與
ship-stage-119 的 freshtest 測試實例，此時就是靠人工 --keep 排除）
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-14 13:25:39 +08:00 |
|