doxa-maps/library/colors
doxa-maps-88655c70 fac00c00bf Adopt the research map's region colours, and pin the one unit that wasn't px
THE DRIVER RULED ON THE PALETTE. He compared the two screens himself: "when i
look on teh color ffor th regiosn tab of the simpel research map i don tsee the
you using htes colors on the reigosn dashbarod hwen you shoudl". Two surfaces
disagreeing about what Africa's colour means is a defect whichever palette is
prettier, and he chose which one wins. library/colors/wagf-region.js now
carries doxa-research-map/src/colors/doxa-region.js's values.

The blast radius turned out to be nil, and my earlier escalation overstated it:
wagf-region.js is imported by exactly two files, both mine. I had reported it as
needing a cross-agent decision on the grounds that seven surfaces would be
repainted. They would not have been — nobody else imports it.

WHAT THE CHANGE COST, measured with the same validator and surface the previous
palette was stepped against:

    lightness band   FAIL   #1ee05f .793 · #FFEB3B .928 · #00e0bd .810 sit
                            above the .43–.77 band
    chroma floor     PASS   all 7 >= .1
    CVD separation   PASS   worst adjacent #FFEB3B/#1ee05f dE 8.7 protan
    normal vision    PASS   worst adjacent dE 21.0
    contrast         WARN   under 3:1 vs surface: #1ee05f 1.72 · #FFEB3B 1.19
                            · #00e0bd 1.65 · #ff7f11 2.47

The palette this replaced passed all five. The contrast warning is survivable
here for a reason and not by dismissal: it obligates relief through a secondary
encoding, and both surfaces already carry one — the chooser renders a legend of
labelled chips in these colours, the dashboard renders the same seven as a
table. Identity never rests on hue alone. The lightness failure has no such
relief: three of these read faintly as pins on a light basemap. Darkening those
three by about 10% L would enter the band with the hue still recognisable, and
that is the Driver's call, so it is asked rather than done quietly.

_chk-region-palette-agrees.mjs is what stops the two drifting apart again. It
compares them value by value and names both files on a disagreement. Ours is
imported; theirs is parsed, because doxa-region.js imports a Vite alias and node
refuses the module — so the parse asserts its own shape first, requiring the
eight entries that file declares, and fails rather than comparing against an
empty object if anyone refactors it to computed values. Negative-tested: flip
one hex and it names that region and both paths.

AND ONE UNIT IN THIS PORT WAS NOT PX. The chevron's gap was a literal 1rem,
ported from their `.with-icon .icon.right { margin-inline-start: 1rem }` — 10px
at their 10px root. `rem` resolves against the document root wherever the
element lives, which is the whole reason dxlife-tokens.js resolves their scale
to px, so ours rendered 16px on our own leaf and would render 10px by accident
on a host with the common 62.5% reset. Pinned to 10px. No diff caught it: the
list diff's link spec reads colour, decoration, weight, display and alignItems,
and never a margin. It reads the icon's margin now.
2026-09-24 20:48:27 +00:00
..
_registry.js Complete app-profiles->plugin-designs sweep across comments/docs; build green; layouts kept at root (load-bearing) 2026-09-17 18:18:19 +00:00
adoption.js Research tabs read at 15px; the status red is a step brighter 2026-09-17 02:38:38 -05:00
engagement.js Research tabs read at 15px; the status red is a step brighter 2026-09-17 02:38:38 -05:00
language-family.js Land the swarm's dashboard work: colour, rails, cascade, scroll 2026-09-22 18:57:39 +00:00
prayer-progress.js Research tabs read at 15px; the status red is a step brighter 2026-09-17 02:38:38 -05:00
README.md consolidate docs into documentation/ and deployment shells into deployment/ 2026-09-21 23:23:23 +00:00
religion.js doxa-maps — portable bundler for embeddable JAMstack maps 2026-09-10 01:53:07 +00:00
wagf-region.js Adopt the research map's region colours, and pin the one unit that wasn't px 2026-09-24 20:48:27 +00:00

library/colors/ — how pins get colored

Each file here is one color strategy — a way to color the map's pins (by language family, prayer progress, religion, …). Drop a <name>.js in and it's auto-discovered; no registration.

  library/colors/                        a map picks a mode
  ┌──────────────────────────┐           ┌───────────────────────┐
  │ language-family.js        │           │ getColorStrategy(      │
  │ prayer-progress.js        │──auto───► │   'language-family')    │──► colored pins
  │ religion.js   engagement.js│  glob     │                        │
  │ _registry.js (the scanner)│           └───────────────────────┘
  └──────────────────────────┘
        shared set                  a single map can add/override its own in
                                    plugin-designs/<map>/src/colors/ (that map only)
  • Shared here = reused by every map. Your map's own color → put it in your bundle's src/colors/ (it merges over the shared set, for your map only — never edit the library to recolor one map).
  • Filename = mode key (prayer-progress.js → prayerProgress). Files starting with _/. are skipped.

Writing or overriding a strategy? The full contract (required exports, legend wiring, checklist) is in ../../documentation/architecture/color-strategies.md.