helm-ai-enterprise
HELM Design System
This page maps the HELM AI Enterprise design system and UI package family to the public docs site. It covers tokens, primitives, accessibility, package adoption, and the handoff boundary between Console proof, operator,This page maps the HELM AI Enterprise design-system and UI package family to the public docs site. It covers tokens, primitives, accessibility, package adoption, and the handoff boundary between Console proof, operator, and product surfaces.
Audience
Use this page if you implement HELM UI, review accessibility or visual regressions, adopt the design-system packages, or need to understand how UI source material is documented publicly.
Outcome
You should know which package owns each design-system surface, which source docs back the public guidance, and how UI changes are validated before release.
Package Flow
flowchart TD
subgraph Ingestion["1. Ingestion & Context Plane"]
core["@mindburn/ui-core"]
helm["@mindburn/helm-ai-enterprise-design-system"]
apps["HELM Console"]
tests["visual, a11y, package tests"]
docs["Public docs and handoff"]
end
%% Operational Flow Edges
core --> helm
helm --> apps
apps --> tests
tests --> docs
%% Premium Styling RulesMermaid source
flowchart TD
subgraph Ingestion["1. Ingestion & Context Plane"]
core["@mindburn/ui-core"]
helm["@mindburn/helm-ai-enterprise-design-system"]
apps["HELM Console"]
tests["visual, a11y, package tests"]
docs["Public docs and handoff"]
end
%% Operational Flow Edges
core --> helm
helm --> apps
apps --> tests
tests --> docs
%% Premium Styling RulesSource Families
| Source family | Purpose | Public handling |
|---|---|---|
../helm-ai-kernel/packages/design-system-core/ |
Canonical OSS-safe tokens, shared components, forms, layout, data display, feedback, inspection, i18n, theme provider, and tests. | Covered by this page and helm-ai-kernel/docs/design-system/. |
packages/helm-ai-enterprise-design-system/ |
HELM-specific policy routes, components, state, handoff readiness, and styles. | Covered by this page and Console/product docs. |
packages/design-tokens/ |
Deprecated compatibility shim that imports core-owned token CSS for one migration window. | Inventory only; not a canonical source. |
docs/design-system-package/ |
Architecture, theming, accessibility, release, semver, CI gates, primitive coverage, adoption, and decisions. | Summarized here; source remains the detailed reference. |
docs/ui/ |
Product UI specifications, flows, evidence UX, operator guide, and IA. | Covered here and by Console/product pages. |
Active package names are @mindburn/ui-core and @mindburn/helm-ai-enterprise-design-system. @mindburn/helm-ai-enterprise-design-tokens is deprecated compatibility only; new code must not depend on it.
Validation
Run the relevant package and browser checks for UI changes:
corepack pnpm run docs:coverage
corepack pnpm run docs:truth
corepack pnpm run test
corepack pnpm run test:e2e
For docs-site changes, run npm run validate, npm run test:smoke, and
npm run test:a11y in docs-platform.
Source Truth
docs/design-system-package/README.mddocs/design-system-package/accessibility.mddocs/design-system-package/architecture.mddocs/design-system-package/ci-gates.mddocs/design-system-package/theming.mddocs/ui/README.md../helm-ai-kernel/packages/design-system-core/README.mdpackages/helm-ai-enterprise-design-system/README.mdpackages/design-tokens/README.md
Troubleshooting
| Symptom | Check |
|---|---|
| UI package behavior changed but docs did not | Update this page or the relevant package README and rerun docs truth. |
| Accessibility behavior regresses | Check package tests plus docs/design-system-package/accessibility.md. |
| Token output differs between apps | Verify @mindburn/ui-core token source files and package export paths before changing app CSS. |
| Console proof UI looks undocumented | Map the route through docs/ui/ and docs/console/ before adding public copy. |
Operational Readiness
Use this page as the public operating layer for HELM Design System. The source of truth is helm-ai-enterprise/docs/public/product/design-system.md; if this page and the implementation disagree, update the source-backed doc and rerun the validation command before publishing.
Before relying on this surface, confirm three things: the source path above still exists, the referenced commands or contracts are still present in the owning repo, and the docs-platform export surfaces still show this page in search, Markdown, llms-full.txt, and MCP without exposing protected routes.
Validation command: corepack pnpm run docs:coverage && corepack pnpm run docs:truth. For website parity, also run npm run exports:boundary and npm run thin-pages:check from docs-platform.
Expected Output
A reader should leave with a concrete next action, the source file or contract to inspect, the command that proves the claim, and a clear boundary for what is public versus protected. For reference pages, the expected output is a correctly scoped request, schema, command, or diagnostic path. For operations pages, the expected output is a reproducible readiness or failure signal that can be attached to an evaluation or support thread.
Failure Modes
If the validation command fails, do not patch this page in isolation. First identify whether the drift is in code, generated contracts, source-owner docs, or the docs manifest. If the public page needs a protected deep link, describe the protected document by name instead of exposing its route. Commercial operator details, tenant data, key ceremonies, and deployment-sensitive internals stay in protected customer or staff docs; this public page only exposes the safe developer contract.