§ Corrective
/fortify
Production readiness — states, accessibility, error handling.
What it does
The default state is polished; loading, empty, error, and disabled states are absent or stubbed. Focus rings are removed without replacement. ARIA is an afterthought. AI generates the happy path and leaves every other path undone — and a component isn’t done when its happy path looks right, it’s done when every path a user might encounter has been designed and built.
Like the other correctives, /fortify uses smart-default autonomy. Building loading skeletons that match content shape, three-part empty states (what / why / next action), error states with recovery affordances, focus rings, ARIA labels on icon-only buttons, contrast fixes — these get applied directly. Architectural decisions (error recovery patterns, onboarding flows that reveal missing product work) are surfaced for approval.
Interactive
Before /fortify
happy path only
Today’s practices
After /fortify
every state designed
Today’s practices
- Loading shows the shape of the content arriving. A skeleton matched to the list pattern reads as intent — the content is coming — rather than as a generic spinner.
- Empty states use the three-part pattern: what this space is, why it’s empty now, what to do about it. Null-check copy (“No items found”) is replaced by language that introduces the space.
- Error states describe the fix with a recovery affordance, not the failure. Beyond visible states, /fortify also addresses focus rings, ARIA on icon-only buttons, contrast minimums, and keyboard navigation — the parts that don’t show up on the page but matter to every user.
On Stillpoint
Stillpoint’s home doesn’t currently render a state-aware “Today’s practices” list — this demo illustrates /fortify’s principle on a related abstraction. /uxreview surfaced real state-coverage gaps on Stillpoint (signup form’s missing error/success/validation states; personalization banner’s missing fallback); their implementation sits in the corrective queue, outside this catalog narrative’s scope.
When to use it
- The happy path looks right but loading, empty, and error states are absent or stubbed.
- Empty states across the project use different structures — some null-check (“No items”), some elaborate, some missing entirely.
- Accessibility has been neglected — focus rings missing, ARIA absent, contrast failing on metadata or disabled text.
- Preparing to ship and want to address production readiness systematically before a final polish pass.
- A /survey or /uxreview has flagged state completeness or accessibility as significant issues.
How to use it
By default /fortify runs a full pass — state coverage (loading, empty, error, success, disabled), accessibility (focus, keyboard, ARIA, contrast), and reduced-motion handoff. Pass a scope to focus: 'states’ for state coverage only, 'accessibility’ for a11y only, or finer scopes like 'empty’ or 'errors’ for a single domain.
- /fortify states
- /fortify accessibility
Anti-patterns it addresses
- Components polished on the default path with every other state absent or stubbed. Empty arrays render nothing; failed requests produce silent failures; loading shows a flicker.
- Empty states using null-check copy — “No items found,” “No data” — language that describes the absence rather than introducing the space.
- Error states that announce the failure with no path forward. “Something went wrong” or a stack trace dropped into the UI.
- Loading states as a generic centered spinner regardless of content shape — instead of skeleton screens that match what’s arriving.
- `outline: none` on interactive elements without a replacement focus treatment, leaving keyboard users with nothing to anchor to.
- Icon-only buttons without `aria-label`, leaving screen reader users with “button, button, button” across the interface.
- Contrast sitting just above WCAG minimums on body and exactly at 3:1 on large text — the palette was sampled rather than tuned.