staynest-ship-kit

Create, debug, and maintain StayNest's GitHub Actions CI pipeline — the lint, typecheck, build, and Playwright jobs in .github/workflows, plus the repository secrets they depend on. Use this whenever the user mentions CI, GitHub Actions, workflows, pipelines, a red or failing build, PR checks, "why did the build fail", adding a step to CI, caching, or repository/Actions secrets — and also when they ask to add a new npm script or check that ought to be enforced on pull requests, even if they don't say "CI" out loud.

Deploy StayNest's Supabase Edge Functions (create-checkout-session, stripe-webhook) and keep their server-side secrets in sync. Use this whenever the user mentions deploying, shipping, or releasing, edge functions, the Stripe webhook, STRIPE_SECRET_KEY or STRIPE_WEBHOOK_SECRET, supabase secrets, or reports that checkout works locally but not in production — and also after any edit to files under supabase/functions/, since those changes do not reach production until they are deployed by hand.

Write, extend, and debug StayNest's Playwright end-to-end tests in the e2e/ directory — browse, auth/wishlist, booking-through-Stripe, and RLS policy specs. Use this whenever the user mentions Playwright, e2e tests, a failing or flaky test, test traces, selectors or data-testid attributes, "add a test for X", or asks to verify a user flow works end to end — and also when they add a new page, route, or interactive component to src/, since those need testids and coverage before the flow can be tested at all.

Manage the shared test data the StayNest E2E suite depends on — the [email protected] demo account, its bookings and wishlist rows, the seeded listings, and Stripe test-mode cards. Use this whenever tests fail on a second run but passed on the first, when the user mentions flaky tests, leftover or duplicate test data, resetting or cleaning up test state, the demo account, seed listings, or test cards — and whenever writing a new test that creates data, since collision-safety has to be designed in rather than patched on.

Manage StayNest's Postgres schema as versioned migrations in supabase/migrations — bootstrapping the initial migration from the live project, then writing, applying, and reviewing every schema and RLS policy change after that. Use this whenever the user mentions the database schema, a migration, a table or column change, RLS or row level security, policies, indexes, or seeding — and also whenever a feature request implies new data (a new field on a listing, reviews, host accounts), since that change belongs in a migration before any application code is written.