pre-deploy

Run the full local verify and confirm the site is safe to push to Vercel. A push to main deploys the live site (SITE_URL in scripts/brand.mjs is the authority), so "safe to push" means safe to deploy — a green verify is the gate before that push.

When invoked

Use this skill when asked to check if changes are ready to push, deploy, or ship — phrases like "is this ready to push?", "run the build", "pre-deploy check", "check before I push".

Instructions

1. Run the full verify from the repo root:

   npm run verify

   This is the single source of truth for local checks and mirrors the CI jobs in .github/workflows/ci.yml, minus the CI-only checks CLAUDE.md's CI & Local Verify section records as deliberate exceptions (its list is authoritative) — so a green verify can still meet a red CI on news from outside, like a fresh advisory. It runs, in order: ESLint, the library type-check, the API compatibility gate (validate-api-compat.mjs: nothing the latest v* tag published may be removed or narrowed, so the next release stays a minor unless a break is deliberate), the publishable package build (build:lib — vite lib mode + d.ts into dist/), the story tests (every Storybook story rendered in headless Chromium, with axe asserting WCAG 2.1 AA on each one and any story play function asserting behavior — an accessibility violation or a failed interaction assertion fails the suite exactly like a render error) and the unit tests (the unit project in vite.config.ts, src/**/*.test.ts in Node), the Storybook build, the website lint, the website build, and then the checks that need the finished build rather than source — the tail of the verify entry in the root package.json is the authoritative list of these, same as the registry chain below. Some read the prerendered HTML (a space lost between JSX and render, say, or an href pointing at a route that no longer exists); the rest serve the build and load it in a real browser — hydration must succeed, every checked page must be visible with content, and it must stay visible when hydration is made to fail, because a build can be green while the rendered site is blank (the hydration smoke's doc block records the outage that proved it), every grip in scripts/gestures.json must survive a throttled pointer flood with no page error, no empty body and no runaway chain of React commits (the gesture check's doc block owns the budget and the drag that blanked the playground), and the served pages must pass axe in both themes at the same rule set Storybook enforces. That is why all of them follow the website build instead of riding the registry chain. (The library half gains one post-build check of its own: validate-package-publish.mjs, publint and arethetypeswrong over dist/ after build:lib.) The registry validators run via the builds' prebuild hooks, so a registry-drift failure surfaces before the compiles even start. The validate-registry entry in the root package.json is the authoritative list of what runs; read the failing script's own doc block for what it guards, because the failures do not share a family resemblance — one means an unregistered component, another that a prose edit removed a fact the chat eval depends on (validate-chat-coverage.mjs), another that the ambient background references a colour token that no longer exists (validate-shader-background.mjs). This list used to be enumerated here and went stale twice; a pointer cannot. The prebuild also regenerates the derived surfaces owned by the validate-registry chain (the generator scripts at the front of its entry in the root package.json are the authoritative list) — if any come out modified, commit them with the work that changed their source.

   Note: the repo is an npm workspace — one npm install at the root covers the website too, and the website resolves rift-ds through a symlink to the repo root. The website build is a plain next build; there is no separate install step inside website/.

2. Check the output of each step for:

   Lint failures:

   • Any ESLint error lines (warnings don't fail the run, but mention them)

   TypeScript errors:

   • Any error TS lines
   • Type mismatches, missing props, invalid imports

   Next.js-specific issues:

   • "use client" missing on components that use browser APIs (window, document, localStorage, useEffect, useState, etc.)
   • SSR-unsafe code running outside client guards — particularly watch website/src/app/layout.tsx (the inline themeScript)
   • Portal/modal components that reference document at module or render scope — these have caused past static-build failures (AlertDialog and Toast both needed fixes; watch for regressions if portal-based components change)
   • Pages that fail static generation (look for Error occurred prerendering page)

   General failures:

   • Any non-zero exit code
   • Build failed or Compiled with errors

3. Report result:

   If everything passes:

   Verify passed (lint + story tests + library, package, Storybook, and website builds, plus the API compatibility gate, the publish lint, the built-HTML validators, and the served-site checks). Safe to push.

   If the change touched component CSS (the chat widget's under src/chat/ included), src/tokens/, or .storybook/, also dispatch the Chromatic workflow (gh workflow run chromatic.yml) — once a Chromatic project is provisioned for this repo (none exists yet) — and check the diff before or right after pushing — visual regressions are the one thing verify cannot see, and Chromatic is deliberately not part of it because every run bills cloud snapshots against a monthly budget. Text-only, script-only, or website-prose changes don't need a run.

   If any step fails, show:

   • Which step failed (lint, component library, the API compatibility gate, story tests, Storybook, website lint, website build, or one of the checks that run after it — the built-HTML validators or the served-site checks; the tail of the verify entry in the root package.json is the authoritative list; a gesture failure is either a stale selector or setup, the drag that took nothing, or a real per-move render regression, the commit budget)
   • If story tests failed, say whether it was a render error, an a11y violation, a play-function assertion, or a unit assertion (a *.test.ts in the unit project, fixed in the pure module it tests, not in a story) — they surface identically but are fixed differently. An axe failure names the rule (e.g. button-name, nested-interactive) and the offending markup; contrast is deliberately excluded from the gate, so a contrast complaint means someone re-enabled color-contrast in .storybook/preview.ts. A play-function failure (e.g. expect(element).toHaveFocus()) means a behavior regression — for an overlay, look at the shared hooks in src/behaviors/ before the component itself
   • The exact error message(s)
   • File path and line number if available
   • A brief diagnosis of likely cause
4. Do not push — this skill only checks and reports. Pushing is the owner's decision.