devskyy-dashboard-patterns
DevSkyy dashboard (devskyy.app) implementation patterns — Next.js 16 App Router, React 19, auth gating, admin pages, WP/WC data wiring. Use for any frontend/ work — pages, components, API routes, depl
SKILL.md.claude/skills/devskyy-dashboard-patterns/SKILL.md
GitHubDevSkyy Dashboard Patterns
devskyy.app = the agent-management hub (Next.js 16 + React 19 in frontend/). skyyrose.co = the WP storefront. Never cross-wire the two — dashboard consumes WP/WC via REST, never renders storefront UI.
Hard-won production rules
- cacheComponents (bug-161): with Next 16
cacheComponents, any page reading request-time data mustawait connection()(fromnext/server) before dynamic reads, or it silently serves stale prerender. Admin pages that read live catalog/WC data: always. - Auth gate is per-handler
withAuth()fromfrontend/lib/api-auth.ts(bug-162) — wrap every API route handler (export const GET = withAuth(getHandler)); public exceptions are listed infrontend/lib/api-public-routes.tsandfrontend/tests/api-auth-coverage.test.tsfails on any unwrapped, unlisted route. There is no edge gate:frontend/proxy.tswas removed 2026-07-28 — do not addmiddleware.tsauth or recreate a proxy, that is a second, conflicting gate. - Deploys: npm, never pnpm (ERR_INVALID_THIS on Node 22+ with Vercel).
cd frontend && npm run deploy. Vercel is current but retiring — devskyy.app returns 402DEPLOYMENT_DISABLED[live 2026-09-18]; the replacement host is undecided, so do not document one. - Env: Vercel project
skyyroseco/devskyy, linked atfrontend/.vercel. Production env synced viavercel env add <KEY> production; preview target must be added manually by founder (CLI add silently fails from agent sessions). - WP/WC data:
https://skyyrose.co/wp-json/wc/v3+ BasicAuth consumer key/secret from env (WC_CONSUMER_KEY/WC_CONSUMER_SECRET); app-password auth forwp/v2+skyyrose/v1. On WP.com Atomic,?rest_route=form 401s for wc/v3 — use/wp-json/path there.
Page conventions
- Admin surfaces live under
app/admin/*— existing:/admin/catalog(lossless CSV editor, SOT read-only),/admin/renders/review. Follow their structure for new admin pages: server component shell + client islands, Zod-validated API routes. - Validation: Zod at every API boundary (mirror backend Pydantic).
- Type-check + lint + build before done:
npm run type-check && npm run lint && npm run build— a PostToolUse hook also runstsc --noEmiton every edit; heed it. - State: server components + fetch by default; client state only for interactivity. No new global-state libs without cause.
Design language (dashboard ≠ storefront)
Dashboard is a TOOL: density allowed, dark-first, brand accents used sparingly (rose-gold #B76E79 for primary actions only). Tables > cards for operational data. Every list needs loading/empty/error states — no unhandled fetch states in delivered pages.
Verify
npm run buildexit 0 (Turbopack), no type errors.- New page reachable + auth-gated via proxy (curl logged-out → redirect/401, logged-in → 200).
- If page reads WC/WP: verify one real fetch against live creds from
.env(never hardcode).