VEC-5 fix: match System Settings surface colors - #103
Merged
Merged
Conversation
Measured against the user's screenshots, System Settings paints a white content pane with slightly gray grouped boxes on macOS 26/27, while Utter painted a gray page with white cards — the off-system gray the user reported. - add SettingsSurface: page = windowBackgroundColor, card = underPageBackgroundColor, cardStroke = separatorColor - settings shell, page surfaces, history cards, and the onboarding and permissions grouped boxes use the shared seams - SettingsSurfaceTests render each seam and assert the pixel matches the intended semantic color, plus a page/card distinctness check Co-authored-by: multica-agent <github@multica.ai>
… evidence Independent review found the exact-head CI failing on testCardSurfaceRendersUnderPageBackgroundColor: the test compared an ImageRenderer pixel against the process-ambient semantic color, and a headless runner resolves that color through a different pipeline than a user session. - assert the seams in sRGB against the semantic colors instead of rendered pixels, and check each surface inside explicit light/dark appearances - add SettingsSurface.pageSRGB / cardSRGB as the resolved-value seam - record real-window light and dark captures from the running app and the CI failure analysis in the verification artifact Co-authored-by: multica-agent <github@multica.ai>
IchenDEV
changed the title
Review found the previous revision could not fail on a regression: it asserted against duplicated NSColor getters that the render path never uses, so swapping page and card still passed, and its light/dark case compared ambient-resolved colors because a dynamic NSColor re-resolves outside performAsCurrentDrawingAppearance. - rasterize the production SettingsSurface.page/card and the semantic references in an NSHostingView with an explicit appearance, so both sides share one pipeline and light/dark are deterministic - drop the test-only sRGB getters; expose pageSemanticColor / cardSemanticColor as the single source of truth for the roles - document the mutation counterexamples: swapping the roles or recoloring card both fail the suite; restoring the correct roles passes Co-authored-by: multica-agent <github@multica.ai>
…eal-window evidence Co-authored-by: multica-agent <github@multica.ai>
…list Co-authored-by: multica-agent <github@multica.ai>
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.
Problem
The user reported that the app's gray background "does not look like the system's mainstream palette" and asked for the System Settings colors.
Evidence
Sampling the user's screenshots with an sRGB reader:
| | Content/page | Grouped boxes |\n|---|---|---|\n| System Settings (light) |
#FFFFFF|#F7F7F7|\n| Utter (light) |#F6F6F6|#FFFFFF|On this machine
windowBackgroundColoris#FFFFFFlight /#1E1E1Edark andunderPageBackgroundColoris#F6F6F6light /#282828dark — so Utter had the two roles swapped: a gray page with white cards.Fix
Add
SettingsSurfaceas the single seam —page=windowBackgroundColor,card=underPageBackgroundColor,cardStroke=separatorColor— and route the settings shell, page surfaces, history cards, and the onboarding/permissions grouped boxes through it. Editing surfaces keeptextBackgroundColor. No fixed RGB, so light/dark/increased-contrast adapt automatically.Before (gray page, white cards) is left; after (white page, gray boxes) is right — matching the System Settings screenshot.
Verification
SettingsSurfaceTestsrasterizes productionSettingsSurface.page/cardseams and semantic references inNSHostingViewunder explicit.aquaand.darkAquaappearances, asserting pixel equality in sRGB (within tolerance) and page/card distinctness.SettingsSurfaceTests).page/cardroles triggers 4 test failures:testPageSurfaceRendersAsWindowBackgroundColor,testCardSurfaceRendersAsUnderPageBackgroundColor,testCardDoesNotRenderAsWindowBackgroundColor, andtestSurfaceIdentitiesAreTheTwoSemanticRoles.cardtosystemRedtriggers 2 failures:testCardSurfaceRendersAsUnderPageBackgroundColorandtestSurfaceIdentitiesAreTheTwoSemanticRoles.dist/Utter.appActivity tab verified in light (page#FFFFFF/ cards#F7F7F7, matching System Settings) and dark (page#252525/ cards#303030).bash scripts/ci-basic-checks.shandbash scripts/sdlc-checks.shpass.docs/sdlc/changes/2026-09-21-settings-surface-parity/.Scope of Acceptance & Remaining Gates
intent.md,spec.md,verification.mdremainpending approval).Fixes VEC-5