Machine manifest

Two JSON artifacts describe the kit for tools — generators, linters, IDE plugins, and agents that want structure rather than prose. Both are generated from the sources at build time, shipped in the npm package, and served by this site:

Artifact	On this site	In the package
Kit manifest	/api/manifest.json	@hypermedia-components/core/manifest.json
Custom Elements Manifest (macros)	/api/custom-elements.json	@hypermedia-components/core/custom-elements.json (also package.json#customElements)

For LLM context (prose, not structure) use /llms.txt — it links back here.

What the manifest contains

Key	Shape	Source of truth
version	The core package version.	package.json
components[]	block, parts[], dataAttributes[] (the attribute surface appearing in the block’s stylesheet), attributeValues{} (each value-carrying attribute → its enumerated values, e.g. data-variant → ["primary", …]), cssVars[] (every --hc-* custom property the stylesheet reads — the themable surface), containers[] (the parts whose element accepts arbitrary flow children in an editor; "" marks the block root — structured components list nothing), staticSafe (whether a scriptless render of the documented resting markup matches the initialized rest), tokensGroup (or null), behavior (or null), docsPath.	src/css/hc-*.css, component.tokens.json
utilities[]	Every hc-* utility class with container (whether its root accepts arbitrary flow children — the layout set: stack, cluster, grid, container, sidebar).	src/css/hc.utilities.css
behaviors[]	name, autoInit (installChart is the single opt-in).	src/js/index.js, src/js/behaviors.js
events[]	name + the source modules[]. Detail shapes live on the component pages.	src/js/*.js
recipes[]	name, purpose, needsBehavior (or null), files[], docsPath, contractPath.	recipes/*/ (+ each recipe’s machine-checked checks.json)
macros[]	tag + attributes[].	src/macros/*.js
i18nKeys[]	Every overridable message key.	DEFAULT_MESSAGES
exports[]	The package export-map paths.	package.json

Guarantees

• Generated, not hand-written. scripts/build-manifest.mjs extracts everything from the sources during the core build; the output is deterministic (sorted, no timestamps).
• CI-enforced completeness. The build fails if a new installXxx() export is not accounted for, and the unit suite asserts the manifest against reality: every stylesheet block present, the auto-init roster exact, recipes matching the directory, macro attributes matching the Custom Elements Manifest. New API surface cannot ship without the manifest learning about it.
• Versioned by npm. Each release’s manifest ships in its tarball — the version history is the registry.

Examples

# Every component block name:
curl -s https://ingcreators.com/hypermedia-components/api/manifest.json \
  | jq -r '.components[].block'

# Which recipes need a behavior, and which one:
curl -s https://ingcreators.com/hypermedia-components/api/manifest.json \
  | jq -r '.recipes[] | select(.needsBehavior) | "\(.name): \(.needsBehavior)"'

# The data-attribute surface of one component:
curl -s https://ingcreators.com/hypermedia-components/api/manifest.json \
  | jq '.components[] | select(.block == "hc-datagrid") | .dataAttributes'

# Enumerated variants/sizes — ready for a property inspector or generator:
curl -s https://ingcreators.com/hypermedia-components/api/manifest.json \
  | jq '.components[] | select(.block == "hc-button") | .attributeValues'

Related

• Behaviors — the human-readable version of behaviors[].
• Versioning — what counts as public API; the manifest is that surface, machine-readable.
• Custom elements — the macros the CEM describes.