feat: govern effective appearance defaults

This commit is contained in:
2026-08-20 07:03:28 +02:00
parent 6643c8fc1e
commit 8f642bd618
13 changed files with 429 additions and 61 deletions
+11 -10
View File
@@ -15,21 +15,22 @@ inherits the result through semantic tokens without module-specific CSS.
- Modules consume semantic tokens such as `--surface`, `--text`, `--line`, and
the status token families. They may define domain aliases whose values resolve
to shared tokens.
- User preference selects the mode and palette. Invalid stored palette values
fail safely to `default`; the profile API accepts only the supported preset
identifiers. Tenant and system policy may provide a future default, but must
not silently replace an explicit user choice.
- Palette defaults form a provenance chain: system, tenant, then an explicit
user choice. Invalid stored values are ignored. Reset means inheritance and
does not copy the current parent value into the child scope.
- A policy lock is separate from the default. A system lock wins over every
child scope; otherwise a tenant lock suppresses a personal override. The
authenticated profile reports the effective palette, source, inherited
palette, and lock state.
- Tenant branding is a separate policy surface and must preserve contrast and
status semantics in both modes.
## Palette safety and scope
The current slice is intentionally user-level. The Settings preview shows the
chosen accent in every applicable light/dark preview before Save, and Reset
palette returns the draft to the GovOPlaN default before persistence. Presets
are checked for WCAG AA contrast in the theme contract. Arbitrary token
overrides, tenant/system defaults, branding import/export, and policy locks are
not inferred from this preference and require their own governed follow-up.
The Settings preview shows the chosen or inherited accent in every applicable
light/dark preview before Save. Presets are checked for WCAG AA contrast in the
theme contract. Arbitrary token overrides and branding import/export are not
inferred from this preference and require their own governed follow-up.
Do not introduce fixed foreground/background colors in a module merely to make
one mode look correct. Add or reuse a semantic Core token, then define both