[pilyang]

Summary

Appearance follow-up to the on-screen mode indicator (PRD §7.7, roadmap Stage 4): the pills and borders can now be colored per mode. Settled in decisions 20260916_mode-indicator-per-mode-colors.md and 20260916_mode-indicator-insert-color.md.

• Three colors, alpha included. Normal, Insert and Visual (shared by VISUAL and V-LINE) each get a ColorPicker with opacity in the Settings Indicator tab, under a new "Colors" section, plus a Reset to system accent button. Insert has no persistent indicator, so its color only shows in the flash on a mode change. The whole section is disabled with the indicator toggle.
• Nothing changes by default. All three colors are unset unless the user picks one; unset means the dynamic system accent, exactly as before. Keys: onScreenModeIndicatorNormalColor / onScreenModeIndicatorInsertColor / onScreenModeIndicatorVisualColor, sRGB #RRGGBBAA strings (uppercase, defaults write-friendly); a missing or unreadable value folds to unset, and resetting removes the key.
• Color changes repaint without an accessibility re-read. The color is not part of Presentation (that would trip desired != current and cost an AX round trip for a purely visual change); normalColor/insertColor/visualColor persist in didSet and push the color straight into the live flash, badge and border panels. Presentation now carries the mode instead of the label (label is derived), so the controller knows which color a panel on screen needs. Because the self-pid path leaves current and the previous app's persistent panel alone, picking a color with Settings open recolors that badge or border in place.
• Text stays opaque and derives from the effective color through the existing luminance rule, alpha ignored, so a translucent background still carries a legible label (PRD NFR: never color alone).

New pure layer ModeIndicatorColor (hex parse/serialize with sRGB clamping — ColorPicker can hand back Display P3 colors whose sRGB components fall outside 0…1 — and the mode→color table). The picker binding ignores a value whose hex equals the current effective color, so merely opening the color panel does not freeze the accent into a stored snapshot.

Verification

• xcodebuild test -only-testing:VimActionTests: pass, re-run independently by the supervising session. New ModeIndicatorColorTests (16): hex round-trip, case normalization, RGBA order, eight malformed inputs, out-of-gamut Display P3 color, mode→color table for all four modes, per-key persistence for each of the three keys with the object(forKey:) != nil guard, reset removes all three keys, unreadable stored value, harmless without inputs, black text on a bright user color, alpha does not change the text verdict. xcodebuild build … CODE_SIGNING_ALLOWED=NO: 0 warnings.
• On-device, scripted (Developer ID Release build installed to /Applications, defaults write + relaunch, window capture + pixel sampling): default badge = accent (0,122,255); Normal #FF0000FF → badge (255,0,0) while the INSERT flash stays (0,122,255) when Insert is unset; Insert #8000FFFF → INSERT flash (128,0,255) with no persistent panel afterwards; Visual #00A000FF → VISUAL badge (0,160,0) and back to red on Esc; Normal #FF000080 → captured alpha 128; window-border and screen-border strokes and their corner labels red with white text; keys removed → accent again. Product defaults restored afterwards.
• Remaining hands-on checks (Settings UI, appearance): live recolor with Settings open, opening the color panel without picking leaves the keys unset, translucent and very light colors, Reset, dark/light switch with unset colors, the tab fitting 460×560.

Docs

mode-indicator-overlay.md (color flow, mode in Presentation, text-color rule, new pure layer, tests), profiles-and-config.md (three keys), app-shell.md (Colors section). Decisions recorded on main (the Insert color one partially supersedes the first, only the "Insert keeps the accent" clause).

🤖 Generated with Claude Code