Maintenance and release process

Change checklist

• Identify a user need and check an existing component family before adding a new variant.
• Update the source contract, anatomy, states, keyboard behavior and persistence notes.
• Refresh audit hashes and revision after authorized source changes.
• Recapture affected themes, viewports, overlays and errors at native 2× density.
• Review typography, glyphs, layout, crop unions and data consistency.
• Regenerate exports/content and verify routes/references before publishing.

Version policy

This is documentation version 1.0.0 for the audited public-product source. A material behavior change needs a new documentation version and revised evidence. Stable capture IDs should persist for unchanged views; remove obsolete records and files together.

A documentation request does not authorize modifying source applications. Record recommendations in Readiness and gaps, then implement them only under a separate requested app change.

Source references