doxa-maps/documentation/contributing
Doxa Maps 70ea389db3 Docs: "reusable by default" in the library guides, and Deep Research by its name
- 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.
2026-10-01 08:27:04 +00:00
..
COLORS.md consolidate docs into documentation/ and deployment shells into deployment/ 2026-09-21 23:23:23 +00:00
README.md Docs: "reusable by default" in the library guides, and Deep Research by its name 2026-10-01 08:27:04 +00:00
staging-reference-design.html consolidate docs into documentation/ and deployment shells into deployment/ 2026-09-21 23:23:23 +00:00

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.