- library/components/WARNING.md, library/dashboards/README.md and documentation/contributing/README.md taught "graduate into the library at the second consumer". They now teach the plugin-designer skill's rule (section 3): a component that could serve more than one map is built once in library/, driven by props, and landed through the build owner; one-off or experimental pieces stay in a map's folder; a new pattern is a pilot, then approved, then rolled out. The contributing guide's "full reasoning" link pointed to an index without it; it now points to the skill. - The app shell doxa-maps-spa is labelled Deep Research. Ten docs still called it the Research Gallery (15 mentions): DEPLOY.md, the desktop how-to, embeddability, develop-a-plugin, reference-universal-props, reference.md, the shell's EMBED.md, and the plugin-designer skill with two of its references. Identifiers (doxa-maps-spa, branch and route names) are unchanged; README.md is not touched. |
||
|---|---|---|
| .. | ||
| COLORS.md | ||
| README.md | ||
| staging-reference-design.html | ||
Contributing to doxa-maps
Welcome. You want to help build maps — edit colors, add a map, tune a legend — without
learning the whole architecture first. This folder is the contributor entry point; the
full guides live in the documentation/ set and are linked below, so nothing here goes stale by
being duplicated.
The one rule that keeps everything clean
Could serve more than one map → build it in the shared library, parameterized (
library/, alias@map). One-off or experimental → it lives in your app-profile folder (plugin-designs/<your-map>/).
Reusable by default. If a component could serve more than one map, build it once in the shared
library, driven by props, and land it through the build owner, so other maps adopt it instead of
copying it. A one-off or experimental piece stays in your map's folder. A new pattern starts as a pilot
on one plugin, is approved, and is then rolled out by each owner. The rule in full:
skills/plugin-designer, section 3.
Start here
| You want to… | Read |
|---|---|
| Understand the whole picture (one library, many bundles, no rebuild) | ../README.md · ../documentation/explanation.md |
| Learn step-by-step with no jargon (non-coders welcome) | ../documentation/tutorial.md |
| Do a task (add a map, embed, change colors, pick a CDN) | ../documentation/how-to.md |
| Look something up (file map, config fields, library index) | ../documentation/reference.md |
| Understand build-vs-dev + partner-site embedding | ../documentation/CONTRIBUTING.md |
| Edit or add colors (the two places a color can live) | COLORS.md |
Colors live here
COLORS.md is the beginner deep-dive on the two places a color strategy
can live — the shared library/colors/ set vs your bundle's private
plugin-designs/<bundle>/src/colors/ — and how the filename decides override-vs-add. The
strategy contract (the required export default shape) is in
../library/colors/README.md.