帳號用量:「使用中」chip 不隨帳號切換移動（追蹤的是全域 seed，不是視窗當下的帳號）

[kiki830621]

Problem

Original text:
「帳號用量那邊使用中的標籤是有問題的，切換標籤之後使用中標籤不會切換。」
— Source: user, live session 2026-08-03

帳號用量（Window(id: "account-usage")）每一列右上的「使用中」chip 釘在同一個帳號上；切換帳號之後 chip 不會跟著移動，等於這個 chip 現在指的不是「真的正在用的帳號」。

讀法的不確定性（待 diagnose 確認）：原文的「切換標籤」有兩種讀法 —— (a) 切換帳號之後 chip 沒跟著換（本 issue 目前的假設）；(b) 切換 macOS 視窗分頁之後 chip 沒跟著換。兩者的 Expected 不同，diagnose 時請先向使用者確認。

Type

bug

Expected

「使用中」chip 標記的是當下真正在使用的帳號；在視窗內切換帳號之後，chip 隨即移到新帳號那一列。

Actual

Chip 停在切換前的帳號，不隨切換更新。

觀察（不是 diagnosis，只是把已知事實記下來）：

• Sources/Logos/Views/Usage/AccountUsageWindow.swift:55 以
  account.registryAccountId == accountManager.activeAccountId 判定 isActive。
• 依 feature: 每個視窗可綁不同帳號 — 多視窗多帳號並行 (additive) #42 的 window-local 決策，視窗內切換帳號寫的是
  WindowAccountSelection.accountId，且刻意不寫全域
  AccountManager.activeAccountId（見 AccountSwitcherSheet.selectAccount，
  「A window-local switch never writes the global default」）。全域那個 id 現在只是
  新開視窗的 seed。
• 也就是說 chip 追蹤的是一個「切換動作永遠不會改到」的值。

Impact

帳號用量是使用者判斷「我現在燒的是哪個帳號的額度」的地方。chip 指錯帳號會讓人把用量歸錯帳，尤其在多帳號輪替避開 rate limit 的情境下，誤判的成本是「以為還有額度、實際上沒有」。

Open question（留給 diagnose）

帳號用量是單一獨立視窗，但帳號是per-window（#42）。所以開了多個終端視窗時，「使用中」本身是語意未定的：

1. 反映最前景（key window）那個視窗的帳號？
2. 允許多個 chip —— 所有「有視窗正在用」的帳號都標？（可能還要顯示視窗數）
3. 保留現在的全域語意，但把字改成「預設 / 新視窗」，另外用別的樣式標真正在用的？

選哪一個會決定要不要把 per-window 選擇 aggregate 到一個 observable 上。

[kiki830621]

Diagnosis

Root Cause

Chip 綁在一個「切換動作在構造上碰不到」的欄位。

AccountUsageWindow.swift:55 以 account.registryAccountId == accountManager.activeAccountId 判定 isActive。而視窗內切換帳號走的是 AccountSwitcherSheet.selectAccount（:315-323）：

if let selection {
    selection.wrappedValue = id        // ← per-window WindowAccountSelection.accountId
} else {
    mgr.setActive(id)                  // ← 只有「沒有 window-local binding」時才走這條
}

在正常的視窗內切換路徑上，selection 恆存在（WindowRoot 持有 @State private var selection），所以 mgr.setActive 永不執行，全域 activeAccountId 永不改變 → chip 永不移動。

這不是任一元件寫錯，是 #42 重新定義了欄位語意之後，沒回頭改綁定：

• Integrate the system-default (main) account into the usage-tracking layer #55 C3 加 chip 時，activeAccountId 名符其實就是「當下使用中的帳號」
• feature: 每個視窗可綁不同帳號 — 多視窗多帳號並行 (additive) #42 之後把它降級為「新開視窗的 seed」（AccountManager.swift:68 的註解已明講：「per-account (WindowAccountSelection), so this is no longer "the" active account」）
• Chip 的綁定留在原地，於是它現在顯示的是一個與「使用中」無關的值

屬 stale-coupling，不是 logic error。

Impact

帳號用量是使用者判斷「我現在燒的是哪個帳號的額度」的地方。在多帳號輪替避開 rate limit 的情境下，chip 指錯帳號的代價是以為還有額度、實際上沒有。且因為錯誤是靜默的（chip 一直指著某個帳號，看起來很正常），使用者沒有察覺的線索。

已裁定的設計決策（解掉 issue body 的 Open Question）

「帳號用量是單一視窗、帳號卻是 per-window」造成的語意未定，使用者於 2026-08-04 裁定：

多 chip —— 所有「有視窗正在用」的帳號都標，並顯示視窗數。

理由與 Impact 段一致：多帳號輪替時要看的是「我同時在燒哪幾個帳號」，而不是單一會跳動的指標。單 chip 跟隨前景視窗在多視窗下反而更難判讀。

未採用的兩案（記錄供日後回溯）：

• 單 chip 跟隨 key window —— 語意單一，但多視窗時會隨滑鼠焦點跳動
• 正名為「預設 / 新視窗」 —— 改動最小且誠實，但不提供使用者要的資訊；可作過渡但非終局

Strategy

需要一個全域聚合「哪些帳號正被視窗使用」。目前不存在這個東西：WindowAccountSelection 是每個 WindowRoot 私有的 @State，彼此看不見。

（GatewayPool 有 per-account refcount、語意正是「兩個視窗共用一個 gateway」，但 system-default 帳號被排除在 pool 外，且它是 actor + 5 秒 linger，不是視窗佔用的可觀測來源 —— 不能直接借用，但證明「per-account 引用計數」在本專案已有先例。）

• 新增 Sources/Logos/App/AccountWindowCensus.swift —— @Observable @MainActor，維護 accountId → 視窗數
• WindowRoot 生命週期接線：onAppear 註冊、onChange(of: selection.accountId) 搬移、onDisappear 註銷
• 註銷的正確性後盾：沿用 WindowUsageModel has no deinit that stops its FileWatcher (latent leak / use-after-free) #91 既有 pattern（見下方 Risks）
• AccountUsageWindow 改讀 census，不再讀 accountManager.activeAccountId
• UsageAccountRow / AccountHeader 的 isActive: Bool 擴充為可帶視窗數（使用中 ×2）
• 單元測試：census 的註冊/搬移/註銷/重複註冊冪等
• 「預設」chip 維持現狀不動 —— 它讀 isDefault，與本 issue 無關

Conflict Class

C_shared_module_coord —— 與 #112（排序控制） 共同觸及 AccountUsageWindow.swift 與 UsageAccountRow，兩者相鄰處理、不交錯。

相對 #113（ClaudeUsageReader.swift / WindowUsageModel.swift）為 A_parallel_safe，檔案不相交。

Complexity

Plan —— 新增跨視窗共享抽象 + 生命週期正確性 + 概念散佈 ≥5 檔（新 census、WindowRoot、AccountUsageWindow、AccountRowView、測試），觸發 #129 硬閘。

Risks

1. 幽靈 chip（最高風險，但有現成前例） —— 視窗關閉時 onDisappear 不保證觸發，漏掉就會留下永遠標著「使用中」的死帳號。

   本專案已踩過並定案對策：WindowRoot.swift 的 .onDisappear 註解記載，feature: wire status-bar cost + token usage to real Claude Code data (currently placeholders / 'sub-plan D') #47 verify（Codex F3）發現同樣問題後，WindowUsageModel has no deinit that stops its FileWatcher (latent leak / use-after-free) #91 為 WindowUsageModel 與 FileWatcher 加了 isolated deinit backstop（Swift 6.1 SE-0371），使「漏掉的 onDisappear 不再洩漏 live FSEventStream」，而 explicit stop 保留為關窗時的即時路徑。

   → census 註銷沿用同一雙層 pattern：onDisappear 為即時路徑、isolated deinit 為正確性後盾。這條風險因此有前例可循，不是新開的坑。

2. 重複註冊 —— onAppear 在 macOS 上可能重入。註冊須以 per-window token 為 key 而非 accountId，使重複註冊冪等、註銷精確。

3. 計數與實際不符的可觀測性 —— 若計數錯了，UI 上看起來仍然「正常」。測試必須直接斷言 census 的計數，不能只測 UI。

Residue（不在本 issue 範圍）

• 排序控制 —— 屬 帳號用量:加排序控制 —— 帳號順序 vs weekly 重置緊迫度 #112
• 帳號用量視窗的 snapshot 覆蓋 —— 屬 帳號用量視窗零 snapshot 覆蓋:UsageBar 極性/門檻顏色無像素層防護 (sister concern from #110) #115（本次改動會動 AccountHeader 的 chip 區域，帳號用量視窗零 snapshot 覆蓋:UsageBar 極性/門檻顏色無像素層防護 (sister concern from #110) #115 落地後需重錄基準）
• 使用中 ×N 的 VoiceOver 讀法 —— 需要一句完整的無障礙標籤而非「使用中 乘 2」，實作時一併處理

[kiki830621]

Verify: #111（兩輪，合併報告）

Engine

pai-ensemble 2.20.0（canonical，#207）— 4 IDD lenses + Devil's Advocate + Codex 跨模型，model: opus / codex gpt-5.6-sol xhigh。兩輪各 6 agents，integrity 0（無 lens 失敗）。

輪	凍結點	findings	verdict
R1	53391ca	48	FINDINGS
R2	e48cd18	41	FINDINGS

Aggregate：FINDINGS（非 PASS） —— 兩輪都有實質發現，兩輪的阻擋項都已修並各自附測試；仍有兩項刻意留到後續（見下方 Deferred）。

兩輪各抓到什麼

R1 的兩個阻擋項（我逐條實地驗證後才接受）：

1. HIGH — ticket 無生命週期狀態。單一 bind() 同時當「appear 註冊」與「change 搬移」，所以 release() 之後到達的 change 會無條件復活已關閉的視窗，讓帳號永久掛著「使用中」。可達性不是理論：WindowRoot 有第二個 onChange(of: accountManager.accounts) 會改寫 selection.accountId（把視窗從被刪帳號上 reseed），串連觸發 selection 的 onChange —— 別的視窗刪一個帳號就足以觸發。
2. MEDIUM — 死依賴 + 事實錯誤的註解。AccountUsageWindow 的 @Environment(AccountManager) 已無人讀取（grep 只有宣告與註解兩處），而我寫的註解宣稱「account list / isDefault 仍來自它」。放著會把日後清理者導向刪錯邊（拿掉注入、留下宣告 = repo 自己標注的 開啟 Settings 視窗立即 crash（SwiftUI environment 未注入獨立 Settings scene） #20 當機）。

R2 抓到 R1 的修法「宣稱已修、實際未修」（五個 lens 獨立指出，完全正確）：

3. .pending 的自癒是不可達的。move(to:) 的 guard let census —— 而 census 只在 appear() 裡賦值。所以 .pending 時必為 nil，「先 move 也能註冊」結構上不可能發生。而我那個測試 moveBeforeAppearSelfHeals 第一行就 #expect(... == 0) —— 它斷言的正是「沒自癒」，名字卻叫 self-heals。已改為 move(to:in:) 自帶 census，測試改為斷言它宣稱的行為。
4. 註解捏造了一個不存在的 filing。我在 Settings scene 的註解寫 registryUsage 的缺口「filed separately」，但當時沒有任何這樣的 issue。已實際立案為 app-level environment 注入在 WindowGroup 與 Settings 兩份清單間漂移（registryUsage 已漏） #118，註解改成事實。這是我這兩輪最該檢討的一條 —— 自我證言式的假陳述，正是 security lens 提醒「code 內引述前輪 verdict 不可當獨立確認」的那類東西。

我推翻的 ensemble 主張（實測，非辯解）

• DA：「整個 Phase 機器都是死的，刪光 17/17 仍綠」——不成立。 我照做 mutation（刪 enum、刪欄位、拿掉兩處賦值與 guard），lateMoveAfterReleaseIsInert 紅燈。.released 那半是承重且有鑑別力的；只有 .pending 那半是死的（那部分五個 lens 說對了）。兩半現在各有獨立測試，未來的 mutation 不會被另一半遮住。
• requirements / logic / security 三個 lens 同向提議「給 appear() 加 .released guard」——不能照辦。 DA 正確反駁：onAppear 在 onDisappear 之後再次觸發，語意就是「視窗回來了」，必須重新計數；加上 guard 會讓每個 disappear→appear 循環變成永久少算且無物修正。已加 reAppearAfterReleaseReRegisters 把現行行為釘死，並把「released 只對 move terminal」寫進型別文件 —— 避免後續維護者「照 merged report 辦事」把文件瑕疵改成計數 bug。
• R1 codex HIGH「UsageAccountRow public API source-breaking」——實質嚴重性 LOW。 codex 只拿到 diff，看不到 Package.swift 的 products 不含 LogosUsage（非對外 product）、且 repo 內只有一個呼叫點且已同步更新。codex 自己在 R2 也修正為 INFO。

我自己證明的兩件事（不是宣稱）

• deinit backstop 測試是有意義的：把 isolated deinit body 清空 → deinitIsTheBackstop 紅燈（1 == 0）。R2 的 DA 獨立重跑確認屬實。
• Phase 的 released 半有鑑別力：見上方 mutation。

也一併採納的 R2 項目

• 使用中 ×1（原本 N==1 省略計數）。裁定原文是「並顯示視窗數」，無例外；更關鍵的是驗收路徑 —— 回報者是在單視窗情境下發現這個 bug 的，而 N==1 時舊版壞掉的 chip 與新版逐像素相同，他無法目視確認修好了。現在 使用中 ×1 讓修復自我舉證。
• 本地化（Text 而非 String）、VoiceOver 每個正數都唸出視窗數、activeAccountIds 死碼移除、三處誇大 SwiftUI/ARC 保證的註解更正 —— 均已落地（R2 的 codex 逐條確認修對）。

Deferred（刻意不在本 issue 修，已立案／已有票）

項目	去處
NSWindow.willCloseNotification 才是真正可靠的視窗生命週期訊號；@State ticket 的 deinit ≠ 關窗	待立案 —— 這是 correctness backstop 的架構問題，不該在本 issue 尾端塞進來
WindowRoot → census → chip 整條 wiring 零整合測試（刪掉 censusTicket.move 或把 count 寫死 0，單元測試仍全綠）	待立案（與上一項同一張票或相鄰）
Settings ↔ WindowGroup 兩份 environment 清單漂移（registryUsage 自 #90 起就漏）	#118（已立案）
帳號用量 rendering surface 的 snapshot 覆蓋	#115（已存在；DA 正確指出我在註解裡發明 filing 的同時，Residue 裡就躺著這張真票沒引用）
chip 語意是「視窗綁定」而非「配額消耗」—— 已結束的 terminal process 其視窗仍算使用中	記錄於此，供 ruling-holder 決定是否要收斂

成果

3 個 commit（f3669f2 / 53391ca → R1、e48cd18 → R1 findings、4e9d0ed → R2 findings），674 tests / 89 suites 全綠。

依 IDD 紀律不自動關閉。Aggregate 為 FINDINGS 而非 PASS，故未打 idd-111-verified tag —— 兩個 Deferred 項目立案後再判斷是否補跑第三輪。