danielbodnar/sheds-store

Start here for any work on sheds.store, the shed marketplace at https://sheds.store (GitLab davidbodnar/sheds.store/sheds.store-new). Covers what the product is, which repo is live, the stack (Astro + Vue islands + Tailwind + Supabase on one Cloudflare Worker), the rules that get an MR rejected, and which sheds-store-* skill to load next. Use before writing any code, page, component, calculator, API route or migration for sheds.store, and when a request mentions sheds.store, Sheds Store, dealer lots, shed listings, or the dealer dashboard.

How to ship a change to sheds.store and the other davidbodnar GitLab repos - cloning with glab, branching from develop, conventional commit and MR titles, the checks to run before pushing, opening a merge request with glab, MR description contents, and per-repo conventions. Use when committing, pushing, opening or updating a merge request, picking a target branch, or preparing work for review in any gitlab.com/davidbodnar repo.

Data and money in sheds.store - the Supabase project, the three Supabase clients and when to use each, RLS, the session cookies, dealership access, migrations, the dealer signup lifecycle, inventory sources, plans and Authorize.Net billing. Use when reading or writing Supabase tables, adding a migration, touching auth or sessions, dealer signup or dashboard data, inventory sync, plans, prices, subscriptions, or anything that charges a card on sheds.store.

The sheds.store visual design system - brand colours, the fluid Oswald + Source Sans 3 type scale, buttons, header and footer, shed cards and tags, the auth frame, the dashboard (app-chrome) token set, city-page tokens, dark mode, and layout rules - with the Tailwind class or CSS variable for each. Use when styling any sheds.store page or component, choosing colours or type sizes, building a new widget that must look native to sheds.store, reviewing UI for consistency, or producing a design file, mockup or Claude Design system for sheds.store.

How to build UI in sheds.store-new - Astro pages, Vue single-file components mounted as islands, client directives, nanostores, path aliases, Tailwind classes, and how to port a React component to Vue. Use when adding or changing a page, component, form, calculator, configurator, chart, modal, or any interactive widget on sheds.store, or when handed React/JSX code that needs to go into sheds.store.

The integration contract between sheds.store and Maybach (maybachsystems.com, the dealer management system run by SystemAvo) - the inventory feed, the shed builder API proxy, Google reviews, phone verification, the dealer waitlist and Quick Setup onboarding and billing. Use when changing Maybach inventory sync, the shed builder, /api/maybach/* routes, PUBLIC_MAYBACH_URL, Quick Setup, or anything where a change on one side could break the other. Not for general Maybach work - see sheds-store-systemavo-reference.

How sheds.store runs on Cloudflare - one Worker serving several hostnames (apex, auth., dashboard., dealer subdomains, staging), middleware host routing and siteUrls, cache headers, environment variables versus runtime secrets, cron jobs, wrangler, and deploys. Use when adding a route or subdomain-aware page, touching middleware, caching, wrangler.jsonc, env vars or secrets, scheduled jobs, deploying, or debugging production on sheds.store.

How to get and handle secrets for sheds.store local development and deploys - where the values live (a 1Password Environment, Cloudflare Worker secrets), loading them with op run, public versus server variables, adding a new variable, and the rules for never leaking a value. Use when setting up a local .env, running sheds.store-new locally, adding a new environment variable or secret, rotating a key, or when a build or API call fails for a missing credential.

Orientation for the repos in gitlab.com/davidbodnar that are NOT sheds.store - Maybach (Laravel + Livewire), SystemAvo (CodeIgniter), and the PHP shed-brand marketing sites. Use when a task lands in a davidbodnar/cth repo, when deciding which repo owns a piece of behaviour, or to avoid applying sheds.store conventions where they don't belong.

Write, revise, and review project documentation for technical accuracy, useful structure, house style, and natural prose. Use when working on user documentation, guides, API reference pages, migration or upgrade guides, READMEs, contributor documentation, technical specifications, changelog entries, or release notes in any repository, and when asked to improve, audit, de-slop, or humanize existing documentation.