blencorp CMS.gov Design System
Build within the system's documented scope and delivery model.
Before editing
- Confirm the product owner and that this system is authorized for the target surface.
- Read references/implementation.md before installing or changing dependencies.
- Read references/sources.md when checking versions, provenance, license, or release state.
- Inspect the existing framework, package manager, asset pipeline, and accessibility tests. Preserve them unless the official integration requires a change.
Workflow
- Choose one documented delivery path; do not mix compiled, source, CDN, and framework-wrapper paths accidentally.
- Pin the dependency or downloaded asset version and keep upstream notices.
- Reuse official components, tokens, content guidance, and templates before adding custom UI.
- Extend through documented tokens, properties, slots, Sass settings, or composition. Do not edit vendored package files.
- Test semantic structure, keyboard operation, focus order and visibility, accessible names, error recovery, zoom/reflow, contrast, and target browsers.
- Report custom patterns, unsupported requirements, and upstream gaps explicitly.
Boundaries
- Scope: CMS.gov product surfaces. Other CMS applications may use CMS core or another documented child system.
- Release: active package in the CMS Design System monorepo.
- Delivery: Branded child-system package consuming CMS Design System core.
- Do not invent component APIs, tokens, package names, or compliance claims.
- Do not import another jurisdiction's branding to fill a gap.
- A passing component example does not prove the completed service conforms to WCAG, Section 508, the ADA, or local policy.
References
- Implementation — packages, setup, and integration decisions
- Sources — authoritative URLs, snapshot versions, ownership, and license notes