Implementation and maintenance
Readiness and known gaps
A usable reference also makes its incomplete or unverified contracts easy to find.
On this page
Readiness register
| Area | Current evidence | Next requirement |
|---|---|---|
| Visual foundations | Exact source roles and values; paired themes; observed sizing | Consolidate repeated typography/spacing/radius values if creating formal exported tokens |
| Contrast | Solid text-pair calculations in both themes | Resolve flagged light text roles; measure overlays, focus and status surfaces |
| Shared components | Source-specific families and real specimens | Define stable API and regression expectations for new variants |
| Planning screens | Actual components with isolated fictional props/API data | Verify real authorized persistence and failure paths in the app |
| Profile/preferences | Local save feedback inspected and captured | Wire/verify persistent settings before calling Changes saved a server result |
| Dialogs/menus | Source semantics, real open states, focus behavior inspection | Complete keyboard containment/traversal and manual screen-reader review |
| Agenda manipulation | Pointer snapping, minimum range, overlap guard | Equivalent nonpointer manipulation and async error recovery |
| Undo | Named status notification, seven-second state lifetime | Timing/reachability review and a durable recovery decision |
| Motion | Global CSS reduced-motion rule | Review imperative reorder/scroll animation behavior |
| Files and storage | Source inventory and request stages documented | Controlled upload/error/progress QA without touching live B2 |
| Design kit/package | Token/reference downloads available | Separate scope for a Figma library or distributable component package |
Why gaps are visible
A hiring reviewer should be able to distinguish thoughtful documentation from invented maturity. This register records the practical work needed for a team to rely on the system. It does not reduce those tasks to a badge or imply they were already resolved by creating this site.
Definition of a complete entry
- The source implementation and revision are identified.
- Purpose, anatomy, configuration, states, responsive behavior and accessibility expectations are documented.
- A meaningful real capture or applied reference exists where feasible.
- Proposed improvements are distinct from implemented behavior.
- Known gaps and verification scope are explicit.
- Related components and patterns show where the entry belongs in the product.
Reference downloads
Related topics
Source audit: 2026-10-07 · Revision 0103e2549959 · Documentation v0.1