狀態列與帳號用量的用量標示極性相反:一個標「已用」、一個標「剩餘」——統一到剩餘

[kiki830621]

Problem

Original text:
「然後下方標示 [截圖] 應賅跟帳號用量的標事宜樣。都是標記剩餘的吧」
— Source: user, live session 2026-08-03（/idd-issue invocation，附截圖）

同一份 plan-usage 資料在兩個介面用相反的極性呈現：狀態列（下方 HUD）標「已用」，帳號用量視窗標「剩餘」。使用者要求統一，並指定統一到「剩餘」那一側。

附件缺席（誠實記錄）：使用者這次貼的截圖在 /idd-issue 執行時已從 image-cache 被清掉（整個 session image-cache 目錄不存在），無法依 Step 1 的 immediate-persistence 規則 stage 起來上傳。這是 skill 有記錄的已知 failure mode（cache eviction），不是漏做。需要圖的話請重貼，會補上到 attachments release。

Type

bug

Expected

狀態列與帳號用量對同一個用量視窗給出同一個方向的讀數：都標「剩餘」。數字、進度條填充方向、顏色門檻三者一致——條在額度被消耗時變短，接近用完時轉紅。

Actual

兩邊極性相反，而且來源是同一個欄位（UsageWindow）：

介面	檔案	數字	進度條	顏色門檻
狀態列 plan 段	Sources/Logos/Views/StatusBar/PlanUsageStatusItem.swift:87-89	Int(window.utilization)％ = 已用	HUDProgressBar(fraction: window.utilization / 100) — 用越多越長	HUDUsageLevel：<0.70 綠 / 0.70–0.90 黃 / ≥0.90 紅（keyed on consumed）
帳號用量	Sources/LogosUsage/AccountRowView.swift:135-152	\(Int(percentRemaining))% 剩餘 = 剩餘	ProgressView(value: percentRemaining, total: 100) — 用越多越短	barColor：<10 紅 / <25 橘 / else 綠（keyed on remaining）

Sources/LogosUsage/UsageModels.swift:29 定義 percentRemaining = max(0, min(100, 100 - utilization)) —— 兩個畫面吃的是同一個 utilization，只是一邊取補數。

具體後果：某帳號 5h 視窗用掉 90% 時，狀態列寫「5h 90%」配一條幾乎填滿的紅條，帳號用量寫「10% 剩餘」配一條幾乎空掉的紅條。兩個畫面同時開著時，同一件事看起來像兩個相反的讀數。

同樣的極性問題也出現在狀態列的 context 段（ContextUsageStatusItem.swift:13-16, 23）：97k / 200k 是已用 / 上限，HUDProgressBar 同樣是 consumed fraction。

Impact

用量讀數存在的唯一理由是讓人一眼判斷「還能不能繼續」。同一個 app 內兩個畫面對同一個數字用相反方向呈現，就是把這個判斷變成需要先想一下「這條是滿代表好還是壞」。而且是在最需要快速判斷的時候（快撞 rate limit）才會同時看這兩個地方。

Scope 待決（留給 diagnose）

1. 範圍：只改狀態列的 plan 段（使用者原話明確指的是這個），還是連 context 段（97k / 200k）一起翻成剩餘？兩者現在都是 consumed-polarity，只改一個會製造新的不一致。
2. 顏色門檻要跟著翻：HUDUsageLevel 的註解明說 "keyed on the CONSUMED fraction … a higher value is always worse"。改成剩餘極性後，這個 enum 的語意必須一起翻（否則剩餘 95% 會被判成 critical）。HUDProgressBar 的 fraction 參數語意也要重新定義並更新註解與 tooltip / accessibility label（PlanUsageStatusItem 的 helpText、accessibilityLabel 目前都寫 "% used"）。
3. 兩邊的門檻本來就不同：帳號用量是 10/25（剩餘），狀態列是 70/90（已用，換算成剩餘是 30/10）。統一極性時要順便定一組共用門檻，否則同一個帳號在兩個畫面仍可能一綠一橘。
4. 是否抽共用元件：UsageBar（帳號用量）與 HUDProgressBar（狀態列）目前是兩套獨立實作，這正是極性會分岔的結構原因。要不要收斂成一個 source of truth（一個「剩餘」語意的 view + 一組門檻）由 diagnose 判。

Related

• 狀態列 context 分母卡在 200k:1M session 的 window 沒有任何可讀訊號（#95 的 settings.json 路徑為空） #113（狀態列 context 分母卡在 200k）—— 同一個 context 段；若兩案一起做，97k / 200k 的分母與極性最好一次處理完。
• 帳號用量:「使用中」chip 不隨帳號切換移動（追蹤的是全域 seed，不是視窗當下的帳號） #111（帳號用量「使用中」chip）、帳號用量:加排序控制 —— 帳號順序 vs weekly 重置緊迫度 #112（帳號用量排序）—— 同一批帳號用量 UI 回饋。

Clarity Surface(idd-clarify run 2026-08-03T07:59:54Z)

Type	Source	Suggested canonical	Status
ambiguity	"然後下方標示 [截圖] 應賅跟帳號用量的標事宜樣"	「下方標示」未指名是狀態列的哪一段。狀態列有兩段用量 HUD：plan 段（PlanUsageStatusItem，5h／7d／per-model 週視窗）與 context 段（ContextUsageStatusItem，97k / 200k）。本 issue 依前一則訊息的截圖脈絡假設指 plan 段，並把 context 段列入 Scope 待決 #1 —— 需確認是「只改 plan 段」還是「兩段都改」	resolved @ 2026-08-04T00:05:19Z (reason: 2026-08-04 裁定統一到「已用」，狀態列兩段皆不動，實作主體移至 #110 —— 本列已不影響方向)
ambiguity	"都是標記剩餘的吧"	「都」的範圍有兩種讀法：(a) 狀態列的兩個用量段都改標剩餘；(b) 狀態列與帳號用量兩個畫面都用剩餘（即帳號用量維持現狀、只有狀態列翻轉）。兩者對 Scope 待決 #1 給出不同答案	resolved @ 2026-08-04T00:05:19Z (reason: 同上裁定；收斂方向由 #110 的 Claude 官方慣例決定，非由「都」的範圍決定)
missing-context	"[截圖]"	能消解上面兩列歧義的輸入（使用者圈選的畫面區域）在本次 invocation 執行時已從 image-cache 被清除，無法納入 attachments release。原圖是唯一能確認「下方標示」指哪一段的證據 —— 需使用者重貼	dismissed @ 2026-08-04T00:05:19Z (reason: 裁定後狀態列不動，截圖已非決定依據；不再要求重貼)

terminology class：無命中。references/terminology-canonical.md 現有 6 個 row 全屬統計／ML 領域（K-means 特徵值、PCA、ANOVA、準確率、P 值、分群），與本 issue 的 SwiftUI UI 語意無交集。這是誠實的 no-hit，不是未掃描。

[kiki830621]

Decision — 極性方向裁定為「已用」，本 issue 的 Expected 反轉

Timestamp: 2026-08-04（/idd-all Phase 0 batch 排序時發現衝突，當場向使用者確認）

衝突

本 issue（#114）建立時記錄的使用者原話是：

「然後下方標示 [截圖] 應賅跟帳號用量的標事宜樣。都是標記剩餘的吧」

而 #110（2026-08-01，同一位回報者）記錄的原話方向相反：

「狀態條的設計要類似claude，從使用多少來看，現在狀態條的設計好像反了」

兩者都認定「兩套慣例並存是錯的」，但要往相反方向收斂：#114 要統一到剩餘、#110 要統一到已用。任選一邊實作，另一邊就會永久錯著。

裁定

使用者於 2026-08-04 /idd-all Phase 0 明確選擇：統一到「已用」（#110 方向）。

理由（使用者選項所載）：比照 claude.ai 官方 Plan usage limits 頁的「N% used」語意；資料層 UsageWindow.utilization 本來就是已用，percentRemaining 是 100 - utilization 加工出來的，往已用收斂改動最小；與官方頁對照時直覺一致。

對本 issue 的影響

• 本 issue body 的 ## Expected（「都標剩餘」）作廢 —— 以本 comment 為準：兩處統一為 填滿 = 已用、標籤「N% 已用」、顏色隨已用比例遞進。
• 實作主體移到 帳號用量 bar 語意與 Claude 官方相反：填滿量是剩餘而非已用，與 status bar HUD 兩套慣例並存 #110（該 issue 的 Expected 與修法候選已經是正確方向）：翻 Sources/LogosUsage/AccountRowView.swift 的 UsageBar，狀態列 HUDProgressBar / PlanUsageStatusItem 維持現狀。
• 本 issue 保留的殘餘價值（帳號用量 bar 語意與 Claude 官方相反：填滿量是剩餘而非已用，與 status bar HUD 兩套慣例並存 #110 未涵蓋、實作時一併處理）：
  1. 顏色門檻統一 —— 帳號用量現行 10/25（剩餘基準）、狀態列 70/90（已用基準）。翻轉後應共用 HUDUsageLevel 的 70/90 分帶，否則同一帳號在兩畫面仍可能一綠一橘。
  2. 狀態列 context 段（97k / 200k，ContextUsageStatusItem）已是已用極性，本次不動 —— 與 狀態列 context 分母卡在 200k:1M session 的 window 沒有任何可讀訊號（#95 的 settings.json 路徑為空） #113 的分母問題分開處理。
  3. 是否抽共用元件（UsageBar vs HUDProgressBar 兩套獨立實作正是極性會分岔的結構原因）留給 帳號用量 bar 語意與 Claude 官方相反：填滿量是剩餘而非已用，與 status bar HUD 兩套慣例並存 #110 的 diagnose 裁決。

Clarity Surface 連帶處理

body 的 3 列 surfaced rows 由本裁定一併消解 —— 「下方標示指哪一段」與「都的範圍」都不再影響實作方向（狀態列不動），截圖缺席也不再是 blocker。已於本次 /idd-clarify --status 標記。

[kiki830621]

Disposition：目標已達成，但方向與本 issue 指定的相反

本 issue 診斷的問題是真的，而且已經修好了 —— 只是統一到了與這裡指定的相反那一側。

發生了什麼

本 issue 要求「統一到剩餘」。#110 獨立描述同一個極性分岔，但要求「統一到已用」。兩者的 Expected 直接互斥，在實作前就被攤開讓使用者裁定。

使用者於 2026-08-04 裁定：統一到「已用」（比照 claude.ai 自己的 "N% used" 方案用量列）。

因此本 issue 的 Problem / Actual / Impact 三段全部成立且未被推翻 —— 被推翻的只有 Expected 指定的方向。

已落地（#110，6 個 commit，idd-110-verified）

本 issue 的 Actual 表格逐列對照現況：

本 issue 記載的 Actual	現況
帳號用量：\(Int(percentRemaining))% 剩餘	→ \(window.utilizationPercent)% 已用
帳號用量：ProgressView(value: percentRemaining, …)（用越多越短）	→ 吃 utilizationFraction，用越多越長
帳號用量：barColor（<10 紅 / <25 橘，keyed on remaining）	→ 刪除，改用共用的 UsageLevel（keyed on consumed）
狀態列 plan 段 HUDUsageLevel 住在 app 模組	→ 下移為 LogosUsage.UsageLevel，兩畫面共用同一組門檻

兩個畫面現在對同一個 UsageWindow 給出同方向讀數，顏色門檻共用一份定義。本 issue 開頭那個「5h 用掉 90% → 狀態列幾乎填滿的紅條、帳號用量幾乎空掉的紅條」的具體症狀不再存在。

兩個 Scope 待決問題的結論

1. context 段（97k / 200k）要不要跟著翻？ —— 不用。統一方向定為「已用」之後，context 段本來就是 已用 / 上限，已經一致，無需改動。（該段另有一個獨立缺陷：分母恆為 200k，屬 狀態列 context 分母卡在 200k:1M session 的 window 沒有任何可讀訊號（#95 的 settings.json 路徑為空） #113，與極性無關。）
2. 顏色門檻要跟著翻嗎？ —— 不用翻。既然統一到已用，UsageLevel 原本 keyed on consumed 的語意（「值越高越糟」）正確無誤，原封保留；反而是帳號用量那組 remaining-keyed 門檻被刪掉了。

附件

本 issue 記載的截圖 image-cache eviction 仍然成立（圖沒能 stage 起來）。#110 的修復不依賴該截圖 —— 極性分岔在兩個檔案裡是可直接讀出的事實。若日後要補圖，重貼即可。

建議處置

作為被 #110 取代關閉。本 issue 的價值已完全轉移：它記錄的分岔證據與影響分析是 #110 裁定的依據之一。

依 IDD 紀律不自動關閉 —— 留給你確認後親自關。