fix: show the number the batch verdict is based on, and stop miscolouring - #9
Merged
Conversation
…ring Two problems in the overall batch metrics block. **The deciding number was never printed.** Batch health prefers average additions over average total churn, but the table only showed `average_loc_changes`. The cause was a duplicated type: both formatters declared their own `metrics` object literal instead of referencing one source, and when `average_loc_additions` was added to the analyzer, the JSON formatter's copy got it while the table's copy did not. Both now reference `HealthMetrics['batch_size']`, so the next added field cannot go missing from one of them. **Every number wore the overall level's colour.** The overall level is the worst of several dimensions, so painting each figure with it implies that figure sits at that level. With additions 3,000 / deletions 6,000 against a 5,000 additions threshold, a green "平均 LOC 變更 9000" could appear next to a red health level — the screen contradicting itself. Only the health level is coloured now; the figures print plain, and `average_loc_changes` is labelled as additions-plus-deletions so it is not mistaken for the additions figure. The formatter cannot know which threshold drove the verdict — it receives metrics, not config — so it no longer implies one. Naming the triggering dimension is already the recommendation line's job. Tests force `chalk.level = 1`, since chalk is a no-op in the non-TTY test environment and the colouring behaviour would otherwise be unobservable. Mutation-tested three ways: not printing the additions figure fails two tests, re-colouring the figures fails one, and dropping the colour from the health level itself fails another — that last one guards against over- correcting by removing colour everywhere. Closes #3 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
變更說明
Closes #3。
判定依據的數字從未被印出
批量健康度優先以「平均新增行數」判定，但表格只印
average_loc_changes。成因是型別重複：兩個 formatter 各自宣告了一份metrics物件字面型別，average_loc_additions加進 analyzer 時只補到 JSON formatter 那一份，表格那份漏了。兩者現在都引用
HealthMetrics['batch_size']這個單一來源，所以下次加欄位不會再只補一半。每個數字都套用整體等級的顏色
整體等級是各維度取最差的結果，所以把它套到每個數字上，等於暗示那個數字落在該等級。新增 3,000 / 刪除 6,000 對上 5,000 的新增門檻時，畫面可能出現綠色的「平均 LOC 變更 9000」和紅色的健康度並存——畫面自己互相矛盾。
現在只有「健康度等級」上色，數字一律不上色，並把
average_loc_changes標明是「新增＋刪除」以免和新增行數混淆：一個刻意不做的決定
formatter 拿不到 thresholds（它收到的是 metrics，不是 config），所以無法知道究竟是
loc_additions還是loc_changes驅動了等級。與其猜，不如不暗示——指名觸發維度本來就是recommendation那行的職責（#1已經讓它會印「平均新增 N 行（門檻 > M）」）。安全性檢查清單
.env管理所有配置資訊./scripts/check-secrets.sh並通過檢查npm test測試計畫
新增
tests/unit/formatters/release-analysis-formatter-metrics.test.ts（6 個測試）。測試裡強制
chalk.level = 1：chalk 在非 TTY 的測試環境下 level = 0、顏色是 no-op，不強制開啟的話「有沒有上色」這件事完全觀察不到，斷言會空過。突變測試三個面向：
average_loc_additions（原 bug）第三條是防過度修正的守衛——確認我不是靠「把顏色全拿掉」來讓前兩條通過。
相關 Issue
Closes #3