anything-domain-map

Non-negotiable Rules

1. Public map is not a personal course: Do not trim the domain based on any individual learner, do not generate personal capability or progress content.
2. Completeness equals clear boundaries: Cover fundamentals, core content, major branches, typical applications, adjacent interfaces, and cutting-edge areas; do not pursue infinite details.
3. Structures must be evidence-based: Prioritize consuming domain mapping dossiers from

   anything-research

   ; all URLs included in formal outputs must be verified by actually accessing them.
4. Hierarchy follows knowledge cohesion: The structure is fixed as

   Module → [Topic] → [Chapter] → Knowledge Point

   . Modules and knowledge points are mandatory; topics/chapters only appear when they can aggregate at least two meaningful sub-items.
5. Single machine source of truth: Complete and validate

   domain-map.json

   first, then generate Markdown and HTML from it. Never create the three contents separately.
6. Typical order is not a personal path: You can provide objective dependencies and typical traversal orders, but must explicitly state that they are not targeted at any specific learner.
7. Product functions must be visible: Formal user entry points of software, platforms, or tools are first-class objects in the public map; do not use broad capability categories to cover specific configurable, callable, or observable functions.
8. Stable structure coexists with current status: The map should present both the long-term valid knowledge structure of the domain and the latest baseline as of a clear date, recent changes, and life cycle; new information should not overwrite stable dependencies, and old paths should not pretend to be the current default.

Input

/anything-domain-map <domain> [scope description]

Workflow

1. Obtain Evidence

• Prioritize finding valid domain mapping

  research.md

  for the same domain.
• If none is available, and

  anything-research

  is accessible, invoke it in "domain mapping mode, depth=deep", requiring two independent research tracks: one to deeply explore domain boundaries, stable knowledge structures, dependencies, and major branches; the other to deeply explore the current baseline as of the current date, latest changes, deprecation migrations, and ecosystem dynamics.
• If the existing dossier only has a stable structure, only one latest function scan, or its

  as_of

  no longer matches the domain's change speed, first let

  anything-research

  supplement or refresh Section 8 before mapping directly.
• Underlying networking tools are only data access routes used by the research layer, not research entry points for domain maps, and should not directly replace research dossiers; only report evidence progress from the research layer to users.
• If research is unavailable, complete equivalent research on your own and declare the downgrade in

  validation.md

  .
• Structure source priority: Official knowledge systems/standards → University training programs and course groups → Authoritative textbook catalogs → Professional organization knowledge bodies → Consensus from multiple high-quality course paths.

2. Define Boundaries

as_of

3. Modeling

domain-map.json

• Modules are divided by domain structure rather than study weeks;
• Knowledge points are the display leaves;
• Cross-module relationships are placed in

  relationships

  , not expressed through duplicate nodes;
• Each knowledge point records why it is important, what problem it solves, applications, and sources;
• Use stable IDs; changes in display names should not alter IDs;

• typical_traversal

  only represents one common browsing order.

• Cross-reference official READMEs, documentation navigation, CLI/API public entry points, release notes, and user entry points in the source code;
• Build independent knowledge points for functions that can be directly configured, called, observed for results, or troubleshooted;
• Retain dependencies between functions and between functions and underlying concepts;
• Do not use umbrella nodes like "automation", "integration", "advanced features" to replace specific functions;
• Record the verification date, uncovered experimental functions, and version differences in

  validation.md

  .

4. Validate Structured Source of Truth

python scripts/validate_domain_map.py <output-directory>/domain-map.json

validation.md

5. Generate Four Products

./<domain>-domain-map-<version>/

• domain-map.json

  : Machine source of truth.

• domain-map.md

  : Human-reviewable full-link outline generated according to references/domain-map-template.md.

• domain-map.html

  : Copy

  references/template.html

  , embed JSON using the script:

python scripts/render_domain_map.py <output-directory>/domain-map.json <output-directory>/domain-map.html

• validation.md

  : Record facts, sources, structures, coverage, rendering checks, and gaps according to references/validation-template.md.

6. Acceptance

• JSON validation passes;
• The number of modules, knowledge points, IDs, and sources in Markdown and HTML are consistent with JSON;
• All intermediate layers have at least two sub-items;
• All relationship endpoints and source references exist;
• HTML is a single file, zero CDN, keyboard-operable, supports narrow screens/print/

  prefers-reduced-motion

  ;
• Users can drill down from the overview to knowledge points layer by layer, and view cross-module relationships separately;

• validation.md

  openly states coverage boundaries, low-confidence structures, and information gaps.
• Product-type maps have cross-referenced official function surfaces, and all formal entry points affecting daily workflows, permissions, or result delivery are visible.

• validation.md

  specifies

  as_of

  and the latest information window; both the stable structure track and latest status track have multiple rounds of evidence, and the current baseline, recent changes, deprecation/migration, and unconfirmed claims have all been addressed.

anything-roadmap