build-gate / build (push) Waiting to run

Details

consolidate docs into documentation/ and deployment shells into deployment/

Driver 2026-09-21: 'a folder called deployment which will store the capacitor
folder, wordpress folder and tauri folder', and 'a folder called documentation
to store the contributing folder so docs are in one place'.

docs/ + contributing/ + CONTRIBUTING.md -> documentation/ (three doc homes into
one). capacitor/ + wordpress/ + src-tauri/ -> deployment/.

The public/ -> dist/ rename the Driver asked about is NOT here: after seeing the
measured blast radius (855 tracked files, 54 source refs, and public/ is the
served web-root four consumers point at) the Driver withdrew it - 'keep the
public folder the same'.

Path references were rewritten mechanically (258 across 87 files), but three
classes needed hand fixes because a prefix regex cannot see them:
  - join(ROOT,'docs',...) in 10 internal scripts - a quoted SEGMENT, not a prefix
  - tauri frontendDist '../public' -> '../../public', since src-tauri is now one
    level deeper; check:tauri caught this exactly as the card predicted
  - the WordPress contract test's dirname(__DIR__,2) -> 3, same reason

Also reverted one over-reach: the rewrite renamed a FINDING-CATEGORY label
'docs' in public-hygiene-check.mjs, which is a rule name in its own header, not
a path.

Verified: full build ALL GUARDS PASS, SRI consistent; check:tauri, check:mobile
(cap sync + webDir OK), check:wp-embed, quoted-scripts, capability-citations,
capability-exemplars, library-index, public-hygiene, parse and drop all pass.

2026-09-21 23:23:23 +00:00

3.6 KiB

Raw Blame History

Editing map colors

Pins on a map are colored by a color strategy — one small file that says "for this color mode, paint each pin this color." There are two places a color strategy can live, and which one you pick follows the one rule:

Reused by more than one map → shared library. Only your map uses it → your profile.

Path A — tweak a color in the shared library

Use this when the color is genuinely shared (prayer-progress, engagement, adoption, religion, language-family — these are used by the shared map machinery across profiles).

Open library/colors/<name>.js (e.g. religion.js).
Edit the PALETTE — just change a hex value.
bun run dev → the change shows on every map that uses that mode, live (HMR).

The library auto-discovers every <name>.js in that folder (import.meta.glob), so there's no registration step — edit the palette and you're done. The full strategy contract (the required export default shape) is in library/colors/README.md; religion.js is the canonical worked example.

Be deliberate here — a change to a shared strategy affects every map that uses it. If you only want to change your map, use Path B instead.

Path B — a color private to YOUR map (override or add)

Use this when the color is specific to your map — you want a different shade than the shared one, or a brand-new coloring nobody else has. This keeps the shared library clean ("local by default").

In your bundle folder, create plugin-designs/<your-map>/src/colors/<name>.js. (No such folder yet? Just make it. template-bundle/src/colors/example-mode.js is a copy-me starting point.)
Follow the same contract as a library strategy (export default { name, propertyKey, getColor, applyColor }).
bun run dev → your map picks it up via HMR. No rebuild.

How override vs. add is decided (the filename)

Your bundle's index.js runs, at startup:

registerStrategies(import.meta.glob('./src/colors/*.js', { eager: true }))

(The glob is *.js, so a colors.json of plain values sitting in the same src/colors/ folder is ignored by the registry — values and strategies coexist.)

That merges your local files over the shared library set. The filename derives the mode key:

language-family.js → mode languageFamily / COLOR_MODES.LANGUAGE_FAMILY
example-mode.js → mode exampleMode / COLOR_MODES.EXAMPLE_MODE

Then:

Same mode key as a shared strategy → your file OVERRIDES it (for your map only).
A new mode key → your file ADDS a private strategy (only your map sees it).

It can't break other maps

Each bundle is built as its own self-contained IIFE, so it carries its own copy of the color registry. Registering a local strategy changes only your bundle — it can never leak into another map. Which is exactly why "local by default" is safe.

Which colors are shared vs. private (today)

The five strategies currently in library/colors/ are shared — the reusable map machinery (useMapLayers, useLegendData, the mobile legend, the data loader, the store) references them, so they correctly stay in the library:

adoption, engagement, language-family, prayer-progress, religion.

Three more are research-only and live in the research bundle's own folder, plugin-designs/doxa-research-map/src/colors/: affinity-block, doxa-region, resource.

If you want your map to color one of these differently, don't edit the library — drop a same-named file in your profile's src/colors/ (Path B) and it overrides the shared one for your map alone.

3.6 KiB Raw Blame History