Implementation
Maintenance and release checklist
Update the reference and its evidence together when the source product changes.
On this page
Change discipline
- Identify the user need and existing component family before adding a variant.
- Document inputs, state transitions, content, theme and keyboard behavior before implementation.
- When tokens or fonts change, refresh foundations, contrast evidence and affected captures.
- When component callbacks or DTOs change, update contracts and workflow persistence boundaries.
- When providers become connected, replace fixture claims only after verification.
- Refresh system revision, audit and manifest together; preserve file hashes and original source provenance.
Release checks
| Check | Evidence |
|---|---|
| Content integrity | All source/asset/related references resolve; seven section structure preserved. |
| Capture integrity | No duplicates, 2× physical dimensions, native fonts, no detached menus or distorted controls. |
| Source safety | Audited hashes unchanged; temporary snapshot removed. |
| Site integration | Project tab, topic routes, sitemap, invalid-route 404, search and mobile contents. |
| Viewer | Theme/viewport filters, enlargement, actual pixels, original file and focus return. |
| Accessibility | Measured findings retained; no unsupported compliance claim. |
| Validation | Shared verifier, appropriate lint/TypeScript/build and browser review. |
Source references
| File | Responsibility |
|---|---|
| package.json | Source runtime/dependencies |
| app/layout.tsx | Font/theme baseline |
| lib/types.ts | Contract changes |
Reference downloads
Related topics
Source audit: 2026-10-08 · Revision 10f45d1377b5 · Documentation v1.0.0