fix(theme): make msn-shared.css canonical here and gate the copies by hash - #72
Merged
Merged
Conversation
… hash The four UI repos each kept a copy of the shared colour tokens and they had drifted into three different files with every repo green: seed and niac-go identical, stem carrying its own darker success green, trellis carrying an extra typography block. A per-repo check cannot see a fleet-wide divergence, which is how all four shipped a light-mode --color-surface-border at 1.45:1 against WCAG 1.4.11's 3:1 for a UI edge. - ui/theme/msn-shared.css is now the one copy. Light --color-surface-border #d9d2bd -> #8e7f52 (3.08-3.96:1 on every light surface) and --color-status-success #2f7d4f -> #2a7146 (5.06:1 on the running-row wash status pills sit on), which is the value stem had already reached alone. - The .dark block is the approved 2026-09-15 dark-palette proposal verbatim: dark is now the night version of the warm light theme (hue 43-51 deg) rather than the cold-steel palette that shared only the status hues. - ci-conformance compares each repo's ui/src/theme/msn-shared.css to it by sha256; a repo with no ui/src is out of scope. - The set C product hues are published in ui/theme/README.md. They stay in each repo's product-<name>.css: decision D6 stands. The four adoption PRs are separate rows (UI-SEED-7, UI-STEM-7, UI-NIAC-9, UI-TRL-8), so the check fails all four repos until they land. Fixes #69
krisarmstrong
force-pushed
the
fix/ui-fleet-1-canonical-theme
branch
from
September 16, 2026 13:01
b039670 to
74a80b2
Compare
krisarmstrong
enabled auto-merge (squash)
September 16, 2026 13:02
krisarmstrong
pushed a commit
to MustardSeedNetworks/seed
that referenced
this pull request
Sep 16, 2026
MustardSeedNetworks/.github#72 made ui/theme/msn-shared.css canonical and gated the product copies by sha256 at 13:03Z today, so every seed PR is red on ci-conformance until the copy is refreshed. This is the file verbatim (sha256 b073e5e15bab): the WCAG fixes to the light border and success green, and the warm dark palette the owner approved on 2026-09-15. No local edits — one would fail the hash by construction. Fixes #2647
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
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.
Summary
ui/src/theme/msn-shared.csshad drifted into three different files acrossthe four UI repos with every repo green throughout:
seedandniac-gobyte-identical,
stemcarrying its own darker success green,trelliscarrying an extra typography block. A per-repo check cannot see a fleet-wide
divergence — which is how all four shipped a light-mode
--color-surface-borderat 1.45:1, against WCAG 1.4.11's 3:1 for a UIedge.
This makes the file canonical here and gates the copies by sha256:
ui/theme/msn-shared.cssis the one copy. Light--color-surface-border#d9d2bd→#8e7f52and--color-status-success#2f7d4f→#2a7146(the valuestemhad already reached on its own)..darkblock is the approved 2026-09-15 dark-palette proposalverbatim — dark is now the night version of the warm light theme
(hue 43–51°) instead of the cold-steel palette that shared only the status
hues.
--color-accent-goldjoins the shared file (it was the same value inall four
product-*.css), so the dark lift is one decision;.kicker-accentconsumes it.
ci-conformancecheck 9 compares each repo's copy by sha256. A repo withno
ui/srcis out of scope; a missing copy in a UI repo is a finding.ui/theme/README.md. They stayin each repo's
product-<name>.css— decision D6 (no shared TS package)stands, and the brand anchor is the one thing the products do not share.
Two scope notes, both deliberate:
trellis's extra.heading-1/.body-small/.gap-*block is not inthe canonical file. The siblings define those in their own
index.css, soadopting the block here would duplicate three existing definitions. UI-TRL-8
moves trellis's copy into its
index.cssinstead.--color-text-disabledstays at 3.0:1. It is out of this row's acceptanceand raising it would erase the disabled affordance; the sites that use it for
real text are the adoption rows' problem, not the token's.
The four adoption PRs are separate rows (UI-SEED-7, UI-STEM-7, UI-NIAC-9,
UI-TRL-8), so the check fails all four repos until those land — see Risk.
Linked Issue
Fixes #69
Type of Change
Bug fix (accessibility) plus a new fleet gate. No product code.
Risk
Medium, and deliberately visible. The moment this merges,
ci-conformancefails in all four product repos, because none of them carries the canonical
file yet. That is the gate doing its job — the adoption rows (UI-SEED-7,
UI-STEM-7, UI-NIAC-9, UI-TRL-8) are queued behind it and each is a verbatim
copy. Verified, not assumed: all four repos pin this workflow at a SHA
(
ci-conformance.yml@048d173…in seed/stem/trellis,@1920efa…in niac-go),so a repo only sees the new check when it bumps that pin — the same change as
its adoption PR. Nothing goes red on merge.
Two consequences to expect rather than triage:
ci-conformance.ymldigest bump in each repo. That PRis born red until the repo's adoption row lands, so it is not a clean bot
PR to arm under rule 9b — land it with the adoption change.
ci-conformance-schedule.ymlruns the same script against all four reposfrom
.githubHEAD, so its next daily tick reports four theme findings onthe existing tracking issue until adoption. Correct, and expected.
The colour changes are confined to two light tokens and the
.darkblock. Thelight border is visibly darker than
#d9d2bd; that is the WCAG fix, not aregression.
Testing Evidence
RED first — the three new cases fail with the check stubbed out:
GREEN with the check in place (the full suite, i18n tests and compileall — the
three steps this repo's
pythonjob runs):The check run against the four real repos at their current
origin/main— allfour differ, as expected until adoption:
Contrast, measured with a WCAG relative-luminance script, not eyeballed:
Markdown gate on the files this PR changes:
README.md's MD013 findings are pre-existing onorigin/main(long tablerows) and this repo runs no markdownlint gate; the new file is clean.
Security and Release Checklist
uses:or unpinned tool install.read-only conformance check.
a finding, and a canonical edit that is not re-copied fails too.
.githubis not versioned by release-please.