saasaloy 0.1.0

package/templates/base/_agents/skills/saasaloy-setup/SKILL.md

@@ -0,0 +1,273 @@
+---
+name: saasaloy-setup
+description: Interview the project owner about their product once, and write the answers to docs/product-brief.md — the shared context every other Saasaloy skill reads. Use at the start of a freshly scaffolded project, when the owner says "set up this project", "tell you about my product", "what is this project", when siteName is still the scaffold's directory name, when another skill needs product context and no brief exists yet, and when re-running to update the brief after something changed.
+---
+
+# saasaloy-setup — find out what this project is, once
+
+A scaffolded project knows nothing about the product it is going to become. Its name is a
+directory name, its language is English because nobody asked, and every skill that follows
+has to either interview the owner again or guess.
+
+So this skill asks once and writes the answers down. The deliverable is
+**`docs/product-brief.md`**, plus the two facts that are code rather than prose: `siteName`
+and the page's `lang` attribute.
+
+It writes no copy. `saasaloy-landing-copy` does that, from the brief this leaves behind.
+
+## The write surface
+
+| Path | What you change |
+|------|-----------------|
+| `docs/product-brief.md` | The whole file. Create `docs/` if it does not exist. |
+| `packages/ui/src/index.ts` | `siteName` — the brand constant, and nothing else in the file. |
+| `apps/web/src/layouts/Layout.astro` | The `lang` attribute only, and only when it differs from the brief's language code. |
+
+Nothing else. You are not here to write the landing page, add a dependency, or touch a
+block.
+
+## Step 0 — before you ask anything
+
+1. **Read `docs/product-brief.md`.** If it exists, someone has already been through this.
+   Read it fully and jump to [Re-running](#re-running).
+2. **Read `packages/ui/src/index.ts`** for the current `siteName`. `saasaloy init` sets it
+   to the directory name, so it is usually a slug like `my-saas` rather than a brand. It is
+   still the best opening guess you have, and it belongs in question 1's samples.
+3. **Look at git, and treat it as advice.** `git status --short` if there is a repo. A dirty
+   tree or no repo at all is worth one sentence — "your changes aren't committed, so you
+   can't undo this with git; every write here is previewed and confirmed anyway" — and then
+   you carry on. `saasaloy init` does not run `git init`, so a clean-tree requirement would
+   block exactly the person who just scaffolded. **Neither state is a reason to stop.**
+4. **Say how long this takes and what it is for**, in two lines, before question 1. Ten
+   questions is a real ask, and an owner who does not know why is an owner who answers
+   thinly.
+
+## Step 1 — the questions
+
+Ten of them. **Question 1 is the project's name, it goes first, and it goes on its own** —
+every sample answer after it is built out of the name and the answers before it, so asking
+it last (as an earlier version of this workflow did) means every other question gets asked
+with nothing to work from.
+
+After that, ask in batches of **two or three**. Number them so the owner can answer by
+number.
+
+| # | Dimension | What you are actually after |
+|---|-----------|----------------------------|
+| 1 | **Name** | What the product is called. Ask alone, first, before anything else. |
+| 2 | **Language** | The language the audience reads, as a name and a code (`en`, `bn`, `es`). Do not assume English. |
+| 3 | **Audience** | The specific person who pays. A job title, a team, a situation. |
+| 4 | **Problem** | What goes wrong for them today, in their words. |
+| 5 | **Current alternative** | What they use *instead* right now — usually a spreadsheet, a contractor, or nothing. This is the real competitor. |
+| 6 | **Differentiator** | What this does that the alternative cannot. One thing, not a list. |
+| 7 | **Proof** | Something the owner can stand behind today: a number, a named customer who agreed to be named, a benchmark they ran, a certificate. |
+| 8 | **Tone** | How the product should sound. Ask for an adjective *and* a site they think gets it right. |
+| 9 | **Pricing** | Per tier: name, who it is for, real monthly price, annual price if there is one. See [Pricing](#pricing-is-extracted-never-invented). |
+| 10 | **Where "sign up" goes** | The signup, waitlist or app URL the primary button should point at. See [The destination](#the-destination-question). |
+
+### Every question ships with sample answers
+
+Never ask a bare question. Each one carries **three sample answers the owner can take as
+written, edit, or ignore in favour of their own** — and say that all three routes are open,
+every time. Most owners answer a picker in seconds and a blank prompt in paragraphs, and
+the paragraph is usually vaguer.
+
+In Claude Code, ask with the question-picker tool so the samples render as choices with a
+free-text option beside them. Any other agent: number the samples `a` / `b` / `c` and add
+"or write your own".
+
+Four rules keep samples useful instead of leading:
+
+- **Derive them.** A sample is a hypothesis built from the name and the answers already
+  given, not a stock phrase. After "Ledgerly" and "bookkeepers", the problem samples talk
+  about month-end and client accounts. If your three samples would fit any product on the
+  internet, you have written filler, and the owner will pick one, and the page will say
+  nothing.
+- **Make them differ in substance, not wording.** Three ways to say "small businesses" is
+  one sample. Three genuinely different audiences is three.
+- **For questions 7, 9 and 10, offer shapes rather than values.** These three become facts
+  the page asserts. "Two named beta customers who agreed to be named" is a shape and is
+  safe to suggest. "300 students enrolled" is a number you invented, and if the owner picks
+  it the landing page now lies. Same for a price, and same for a URL: suggest
+  `https://<yourdomain>/waitlist`, never a domain you made up.
+- **Always include the honest empty answer** where one exists: "no proof yet", "no pricing
+  yet", "nothing to link to yet". An owner who cannot see that option supplies something
+  rather than admit to nothing, which is how invented proof gets in.
+
+A worked pair:
+
+> **1. What is this product called?**
+> a. `ledgerly` — the name the folder already has
+> b. Ledgerly — same word, capitalised the way you would write it on the page
+> c. Something else entirely, if the folder name was a placeholder
+> Or type it however you want it to appear on the page.
+
+> **4. What goes wrong for a bookkeeper today?** *(samples built from your answer to 3)*
+> a. Month-end close runs across four spreadsheets per client, and a broken formula only
+>    surfaces when the client queries the invoice.
+> b. Chasing clients for receipts eats the first week of every month.
+> c. Nothing is wrong exactly, it is just slow, and I want to say what instead.
+> Or describe it in your own words — your words are the ones that end up on the page.
+
+### Push back, at most twice
+
+An answer is **weak** when it names no audience, no number, no named alternative, or no
+proof the owner could point at. "Everyone" is not an audience. "It's faster" is not a
+differentiator. "Businesses struggle with productivity" is not a problem.
+
+Push back **at most twice per question**, and make each follow-up narrower than the last —
+carrying fresh samples, same as the first ask:
+
+> — Who is your audience?
+> — Small businesses.
+> — Which ones? Think of the last person who asked you for this. What was their job?
+> — Bookkeepers, mostly, at firms with 5–20 clients.
+
+If the second follow-up still comes back thin, **stop asking.** Record it in the brief
+verbatim, tagged `weak:`, and say what it will cost:
+
+> I've recorded "it's faster" as weak — no number behind it — so anything written from this
+> brief will describe what the product does rather than claim a speed advantage. Give me a
+> benchmark later and that changes.
+
+Two follow-ups is a ceiling, not a quota. A specific first answer needs none.
+
+### Pricing is extracted, never invented
+
+The scaffolded page ships three plausible-looking tiers at $0 / $29 / Custom. Shipping
+those as if they were real is the worst thing this workflow can do, so ask per tier: name,
+who it is for, real monthly price, annual price if there is one.
+
+Three acceptable outcomes, and no others:
+
+1. **Real prices.** Record them, with the date they were confirmed.
+2. **"Leave pricing as a placeholder."** Record that the shipped tiers are unconfirmed
+   placeholder copy, in those words.
+3. **"We don't have pricing yet."** Record that. The landing-copy skill will offer to drop
+   the pricing block, which is its call to make and its confirmation to take.
+
+Never round, convert currencies, or fill in a typical number. Record the currency if it is
+not USD.
+
+Annual pricing has two shapes and both are fine: a real discount (record the effective
+monthly cost when billed annually) or no discount at all (record that, so nobody writes
+"Save 20%" over two identical numbers).
+
+### The destination question
+
+Question 10 is the one owners are most surprised to be asked, and the one that most often
+leaves a page broken. A pre-launch product with a **Join the waitlist** button that reloads
+the homepage is worse off than one with a wrong icon.
+
+Ask where the primary call to action should go. Three answers to expect:
+
+- **A URL.** Record it. An external form, a waitlist provider, an app subdomain.
+- **A route this project will have later** (`/signup`). Record it, and note it does not
+  exist yet.
+- **Nothing yet.** Record it as `weak:`. The page keeps sending people to its own closing
+  section, which is honest but weak, and the labels have to stay modest to match.
+
+## Step 2 — write the brief
+
+`docs/product-brief.md` is the deliverable. It is human-editable, it is the source of truth
+on every re-run, and it is what every other skill reads instead of interviewing again.
+
+```md
+# Product brief
+
+Last updated: YYYY-MM-DD (saasaloy-setup)
+
+- **Name**: Ledgerly
+- **Language**: Bangla (`bn`)
+
+## Audience
+Bookkeepers at firms carrying 5–20 client accounts.
+
+## Problem
+Month-end close runs across four spreadsheets per client, and a broken formula is only
+found when a client queries the invoice.
+
+## Current alternative
+Excel plus a shared Dropbox folder.
+
+## Differentiator
+weak: "it's more organised" — asked twice, no mechanism named. Copy avoids this claim.
+
+## Proof
+Two named firms in beta (Rahman & Co, Hasan Associates), both agreed to be named.
+
+## Tone
+Plain, unexcited. Owner pointed at basecamp.com.
+
+## Pricing
+Confirmed 2026-08-08: Solo ৳900/mo, Firm ৳3,500/mo, no annual discount yet.
+
+## Where "sign up" goes
+https://ledgerly.com.bd/waitlist — a Tally form, live now.
+
+## Known gaps
+- The template loads no webfont, so a non-Latin script renders in whatever face the
+  visitor's device provides.
+```
+
+Two rules about this file:
+
+- **Keep every `weak:` tag verbatim.** It is the thread the next run picks up.
+- **Write it before you touch any code.** If the owner walks away after question 6, a brief
+  with six answers in it is worth having; six answers held in a conversation are not.
+
+## Step 3 — set the two facts that are code
+
+Show the change and confirm it, one file at a time.
+
+1. **`siteName`** in `packages/ui/src/index.ts`. This is the brand as it appears in the
+   header, the footer and the browser tab. It is not translated, and it is the only thing
+   in that file you may edit.
+2. **`lang`** in `apps/web/src/layouts/Layout.astro`. Set it to the brief's language code
+   whenever the attribute differs from it, including back to `en` on a re-run that returns
+   to English. It ships hardcoded as `en`. Getting this wrong tells screen readers to
+   pronounce Bangla with English phonetics.
+
+Then check it still builds, because both files are imported by the page:
+
+```sh
+pnpm --filter @repo/ui typecheck
+pnpm build
+```
+
+## Re-running
+
+A brief on disk means the interview already happened.
+
+1. **Summarise it back** in a few lines and ask what changed.
+2. **Ask only about what moved** — plus every `weak:` tag, which is exactly the thread a
+   second pass should pick up. "Last time 'it's faster' had no number behind it. Do you
+   have one now?" Carry samples on those questions too.
+3. **Update `Last updated`** and rewrite only the sections that changed.
+4. **If the brief was hand-edited**, that wins. Do not tidy someone's prose back into your
+   own phrasing.
+
+## What happens next
+
+Say so explicitly when you finish, because the brief on its own changes nothing the owner
+can see:
+
+> The brief is at `docs/product-brief.md` and `siteName` is set. Run
+> `/saasaloy-landing-copy` and it will write the landing page from this, as a markdown
+> draft you review before anything touches the site.
+
+## Boundaries to honor
+
+- **[The write surface](#the-write-surface) is the whole list of files you may touch.**
+- **Never write landing copy.** Not into `packages/ui/src/content/landing.ts`, not into a
+  block, not "just the headline while we're here". The brief is your output.
+- **Never edit a block or the design layer** — `packages/ui/src/blocks/*`,
+  `packages/ui/src/styles/globals.css`, `packages/ui/src/components/*`, `components.json`, or a Tailwind class
+  anywhere.
+- **Never invent pricing, proof, a customer name, or a URL.** Not in the brief, and not in
+  a sample answer.
+- **No dependencies, no i18n machinery, no webfonts.** Record the gap in the brief; do not
+  close it.
+- **A dirty tree, a missing repo, or a thin interview is not a blocker.** Warn, record less,
+  and say what you left out. (This is about those three conditions only — anything unsafe
+  or outside this skill's scope you decline as you normally would.)

package/templates/base/_gitignore

@@ -0,0 +1,32 @@
+# Dependencies & build output
+node_modules/
+dist/
+.astro/
+.wrangler/
+*.tsbuildinfo
+
+# Logs
+*.log
+npm-debug.log*
+pnpm-debug.log*
+
+# Environment & secrets
+.env
+.env.*
+!.env.example
+.dev.vars
+.dev.vars.*
+!.dev.vars.example
+*.pem
+
+# OS / editor
+.DS_Store
+.idea/
+.vscode-test
+
+# Claude Code skill links — regenerated per-machine by `saasaloy init` and `saasaloy add`.
+# The real skill files are committed under .agents/skills/.
+.claude/skills/
+
+# Turborepo task cache
+.turbo

package/templates/base/_husky/commit-msg

@@ -0,0 +1 @@
+pnpm exec commitlint --edit "$1"

package/templates/base/_husky/pre-commit

@@ -0,0 +1 @@
+pnpm exec lint-staged

package/templates/base/_prettierignore

@@ -0,0 +1,31 @@
+# Prettier does not read .gitignore, so anything git-ignored that Prettier would
+# otherwise walk has to be repeated here. oxlint needs none of this — it honours
+# .gitignore already.
+
+# Markdown is deliberately not formatted. Ultracite's Prettier config sets
+# `proseWrap: "never"`, which collapses every hand-wrapped paragraph — including the
+# AGENTS.md and CLAUDE.md your agents read — into one line each.
+**/*.md
+
+# Generated by pnpm, not hand-edited.
+pnpm-lock.yaml
+
+# Saasaloy's own state, written by the CLI. `JSON.stringify(…, 2)` always expands
+# arrays; Prettier would collapse the short ones and every `saasaloy add` would then
+# leave `pnpm lint` red until you reformatted files you do not edit by hand.
+saasaloy.json
+saasaloy-lock.json
+.saasaloy/
+
+# Wrangler configs are patched surgically by `saasaloy add` (jsonc-parser rewrites only
+# the touched region, so the comments Cloudflare configs rely on survive). Prettier
+# wants trailing commas and collapsed short arrays in the inserted region, which the
+# patcher does not emit — leaving `pnpm lint` red after every binding a module adds.
+**/wrangler.jsonc
+
+# Build output and dependencies.
+**/node_modules
+**/dist
+**/.turbo
+**/.astro
+**/.wrangler

package/templates/base/_saasaloy-base.json

@@ -0,0 +1,9 @@
+{
+  "seedFiles": [
+    "DESIGN.md",
+    "README.md",
+    "saasaloy.json",
+    "apps/web/src/pages/index.astro",
+    "packages/ui/src/content/landing.ts"
+  ]
+}

package/templates/base/apps/web/astro.config.mjs

@@ -0,0 +1,61 @@
+// @ts-check
+import { fileURLToPath } from "node:url";
+import cloudflare from "@astrojs/cloudflare";
+import react from "@astrojs/react";
+import tailwindcss from "@tailwindcss/vite";
+import { defineConfig } from "astro/config";
+
+// Static output — the marketing site is content-first, and every page here is
+// prerendered at build time. `output: "static"` is written out rather than left to the
+// default so the next person changing this file has to mean it.
+//
+// The Cloudflare adapter is registered anyway, and src/pages/500.astro is why. Astro
+// only treats a 500 page as an error handler when an adapter is present; without one it
+// is an ordinary page nothing ever routes to. The adapter also means the first page a
+// module drops in with `prerender = false` runs on demand with no config change and
+// inherits that same 500 screen.
+//
+// Registering it costs no Worker while everything is prerendered: the adapter builds in
+// assets-only mode, emits no server entry, and moves the site to dist/client. That move
+// is why wrangler.jsonc points `assets.directory` there — read its comment before you
+// change either file.
+//
+// The React integration ships in the base template itself (not per-feature) — every
+// downstream module (waitlist, admin, ui components) needs `.tsx` islands sooner or
+// later, so it's set up once here rather than patched in repeatedly.
+export default defineConfig({
+  site: "https://example.com",
+  output: "static",
+  // Sessions off. Left unset, the Cloudflare adapter reads this key, decides sessions are
+  // wanted, and writes a `SESSION` KV namespace binding with no id into the config it
+  // generates at dist/client/wrangler.json — which is the config `wrangler deploy` actually
+  // reads (see wrangler.jsonc). A prerendered marketing site stores no session, so that
+  // would be a namespace to provision for nothing. Note this is Astro's own `session`, not
+  // an adapter option; passing it to `cloudflare()` below does nothing.
+  session: false,
+  // `imageService: "compile"` optimises images during the build and serves the results
+  // as plain assets. The adapter's default would reach for Cloudflare's IMAGES binding
+  // at runtime, which needs a Worker this site does not have.
+  adapter: cloudflare({ imageService: "compile" }),
+  integrations: [react()],
+  // Fixed dev port. Every cross-origin consumer in this repo — the api Worker's CORS
+  // allowlist, auth's `trustedOrigins`, the waitlist form's `PUBLIC_API_URL` fallback —
+  // hardcodes the localhost dev origins, so the port cannot be allowed to drift.
+  // `strictPort` makes a busy port a loud failure instead of a silent +1 that turns
+  // into a mystery CORS rejection. web is 3000, api is 4000 (see apps/api).
+  server: { port: 3000 },
+  vite: {
+    // Tailwind 4 is a Vite plugin, not an Astro integration — `@astrojs/tailwind` is EOL
+    // and never supported v4. The theme itself (tokens, @source globs) lives in
+    // packages/ui/src/styles/globals.css, which Layout.astro imports via @repo/ui.
+    plugins: [tailwindcss()],
+    server: { strictPort: true },
+    resolve: {
+      // `@web` mirrors saasaloy.json's alias of the same name (apps/web/src) — that
+      // alias only drives the CLI's file-placement when a module's files[] target
+      // `@web/...`; this is what makes the dropped source's own `@web/...` imports
+      // (e.g. a dropped page importing @web/components/*) actually resolve.
+      alias: { "@web": fileURLToPath(new URL("src", import.meta.url)) },
+    },
+  },
+});

package/templates/base/apps/web/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "@repo/web",
+  "version": "0.0.0",
+  "private": true,
+  "type": "module",
+  "scripts": {
+    "dev": "astro dev",
+    "build": "astro build",
+    "clean": "rimraf dist .astro .wrangler",
+    "preview": "astro preview",
+    "deploy": "wrangler deploy"
+  },
+  "dependencies": {
+    "astro": "7.3.1",
+    "@astrojs/cloudflare": "14.3.0",
+    "@astrojs/react": "6.0.5",
+    "react": "19.2.8",
+    "react-dom": "19.2.8",
+    "@repo/ui": "workspace:*"
+  },
+  "devDependencies": {
+    "@tailwindcss/vite": "4.3.3",
+    "@types/node": "26.4.1",
+    "@types/react": "19.2.18",
+    "@types/react-dom": "19.2.5",
+    "rimraf": "6.1.3",
+    "tailwindcss": "4.3.3",
+    "wrangler": "4.129.0"
+  }
+}

package/templates/base/apps/web/public/favicon.svg

@@ -0,0 +1,4 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32" role="img" aria-label="{{PROJECT_NAME}}">
+  <rect width="32" height="32" rx="7" fill="#111827" />
+  <path d="M11 21.5c1.3 1 2.9 1.5 4.8 1.5 3.4 0 5.4-1.6 5.4-4 0-2.2-1.4-3.3-4.5-4-2.4-.5-3.1-1-3.1-1.9 0-1 .9-1.7 2.5-1.7 1.4 0 2.7.4 3.8 1.2l1.4-2.5C19.9 9.4 18.3 9 16.4 9c-3.2 0-5.2 1.7-5.2 4 0 2.3 1.5 3.4 4.6 4.1 2.3.5 3 1 3 1.9 0 1-1 1.6-2.6 1.6-1.6 0-3-.5-4.1-1.4z" fill="#f9fafb" />
+</svg>

package/templates/base/apps/web/src/layouts/Layout.astro

@@ -0,0 +1,52 @@
+---
+// The one document shell for every page. It owns <html>/<head>/<body> and the single
+// import of the shared theme, so a page is only ever its own content — no page may
+// duplicate the shell or import globals.css again.
+import "@repo/ui/globals.css";
+import { THEME_INIT_SCRIPT } from "@repo/ui/lib/theme";
+
+interface Props {
+  title: string;
+  description?: string;
+}
+
+const { title, description } = Astro.props;
+---
+
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>{title}</title>
+    {
+      /*
+      Explicit icon link, not the implicit /favicon.ico lookup. Without a link the
+      browser guesses /favicon.ico, and Chrome tags that guess `Sec-Fetch-Site:
+      cross-site`, which the Astro dev server blocks with a `[router]` warning
+      (astro/dist/vite-plugin-astro-server/sec-fetch.js). A declared same-origin
+      link never gets that treatment. Replace public/favicon.svg with the project mark.
+    */
+    }
+    <link rel="icon" href="/favicon.svg" type="image/svg+xml" />
+    {description && <meta name="description" content={description} />}
+    {
+      /*
+      Pre-paint theme resolution. This runs synchronously in <head>, BEFORE the browser
+      paints, so a dark-mode visitor never sees a white flash. `is:inline` keeps Astro
+      from bundling it into a deferred module, which would defeat the whole point —
+      `<script type="module">` is deferred by specification and always runs too late.
+      The script body is @repo/ui's THEME_INIT_SCRIPT, imported above and baked into
+      this HTML at build time, so the layout holds no copy of it: it reads the stored
+      choice, falls back to the OS preference, and also drives every
+      `[data-theme-toggle]` on the page through one delegated listener. That is why
+      @repo/ui/blocks/theme-toggle needs no client directive. Do not inline a second
+      resolver here, and do not turn this into an import.
+    */
+    }
+    <script is:inline set:html={THEME_INIT_SCRIPT} />
+  </head>
+  <body class="bg-background text-foreground min-h-dvh font-sans antialiased">
+    <slot />
+  </body>
+</html>

package/templates/base/apps/web/src/pages/404.astro

@@ -0,0 +1,24 @@
+---
+// The wrong-path page. Astro prerenders it to dist/client/404.html, and wrangler.jsonc's
+// `assets.not_found_handling: "404-page"` is what makes Cloudflare serve it (with a real
+// 404 status) for an address that matches no asset and no route.
+//
+// No markup of its own: every error screen in this repo is @repo/ui's ErrorState, and
+// every word is @repo/ui/content/errors. Change the copy there, not here.
+//
+// No `client:*` directive, deliberately. ErrorState is static, so this page ships zero
+// JavaScript for it.
+import { siteName } from "@repo/ui";
+import { ErrorState } from "@repo/ui/blocks/error-state";
+import { errors } from "@repo/ui/content/errors";
+import Layout from "../layouts/Layout.astro";
+---
+
+<Layout title={`${errors.notFound.title} — ${siteName}`}>
+  <ErrorState
+    code={errors.notFound.code}
+    title={errors.notFound.title}
+    description={errors.notFound.description}
+    primaryAction={{ label: errors.notFound.homeLabel, href: "/" }}
+  />
+</Layout>

package/templates/base/apps/web/src/pages/500.astro

@@ -0,0 +1,33 @@
+---
+// The server-failure page. Astro serves it when an on-demand page throws, which the
+// Cloudflare adapter registered in astro.config.mjs is what makes possible.
+//
+// Nothing in the base template renders on demand today, so nothing here can trigger it.
+// That is the point: the first page a module drops in with `prerender = false` inherits
+// this screen instead of a stack trace.
+//
+// Prerendered, and it reads nothing from the failed request — no `Astro.props.error`, no
+// status text, no path. A 500 page renders inside a request that already went wrong, so
+// anything it reports from that request is a leak waiting to happen, and the visitor can
+// do nothing with the detail anyway.
+//
+// That also rules out a retry control. A retry has to know which URL failed, and this
+// page is built once at build time with no request in hand — a "try again" that reloads
+// /500 would be a lie. The one action is the home page; the browser's own reload button
+// is the real retry.
+//
+// No `client:*` directive: ErrorState is static and ships no JavaScript.
+import { siteName } from "@repo/ui";
+import { ErrorState } from "@repo/ui/blocks/error-state";
+import { errors } from "@repo/ui/content/errors";
+import Layout from "../layouts/Layout.astro";
+---
+
+<Layout title={`${errors.serverFailure.title} — ${siteName}`}>
+  <ErrorState
+    code={errors.serverFailure.code}
+    title={errors.serverFailure.title}
+    description={errors.serverFailure.description}
+    primaryAction={{ label: errors.serverFailure.homeLabel, href: "/" }}
+  />
+</Layout>

package/templates/base/apps/web/src/pages/index.astro

@@ -0,0 +1,61 @@
+---
+import { siteName } from "@repo/ui";
+import { Cta } from "@repo/ui/blocks/cta";
+import { Faq } from "@repo/ui/blocks/faq";
+import { FeatureGrid } from "@repo/ui/blocks/feature-grid";
+import { Footer } from "@repo/ui/blocks/footer";
+import { Hero } from "@repo/ui/blocks/hero";
+import { Navbar } from "@repo/ui/blocks/navbar";
+import { PricingTable } from "@repo/ui/blocks/pricing-table";
+import { ThemeToggle } from "@repo/ui/blocks/theme-toggle";
+import { landing } from "@repo/ui/content/landing";
+import { interpolate } from "@repo/ui/lib/interpolate";
+import Layout from "../layouts/Layout.astro";
+
+// This page carries no copy of its own — the tab title and meta description come from
+// landing.meta.*, which spells the brand as a `{siteName}` token. Every block reads its
+// own words from the same file (packages/ui/src/content/landing.ts).
+
+// This page composes itself from explicit imports and nothing else. A module that ships
+// UI writes a block into packages/ui/src/blocks/ plus a small island under
+// src/components/ that feeds it, and then tells you to place it here; the module never
+// puts itself on the page. Read the module's own skill for the import line and where it
+// suggests the component goes, then decide the position yourself.
+---
+
+{
+  /*
+  The page is composed from @repo/ui/blocks/*, each reached by its own subpath export.
+  Blocks render to static HTML by default; only the three that need browser state carry
+  a client directive, and each one is deliberate:
+    - Navbar       client:idle    — mobile menu toggle, above the fold, so hydrate when
+                                    the browser goes idle rather than waiting for scroll.
+    - PricingTable client:visible — monthly/annual toggle, below the fold.
+    - Faq          client:visible — accordion, below the fold.
+  Hero, FeatureGrid, Cta and Footer take no directive and ship no JavaScript at all.
+  ThemeToggle is the interesting case: it is interactive yet takes no directive either,
+  because its behaviour comes from the pre-paint inline script Layout.astro emits, not
+  from React. Giving it a `client:*` would ship a hydration runtime for a button that
+  has no onClick. It sits here rather than inside Navbar so that navbar.tsx stays the
+  landing blocks' file alone, and it carries its own positioning: fixed to the corner,
+  clear of the sticky header's own controls at every width.
+  Never reach for a blanket `client:load` here — it would hydrate the whole page.
+*/
+}
+<Layout
+  title={interpolate(landing.meta.title, { siteName })}
+  description={interpolate(landing.meta.description, { siteName })}
+>
+  <Navbar client:idle siteName={siteName} />
+  <ThemeToggle
+    className="border-border/60 bg-background/80 fixed right-4 bottom-4 z-50 shadow-sm backdrop-blur"
+  />
+  <main>
+    <Hero siteName={siteName} />
+    <FeatureGrid />
+    <PricingTable client:visible />
+    <Faq client:visible />
+    <Cta siteName={siteName} />
+  </main>
+  <Footer siteName={siteName} />
+</Layout>

package/templates/base/apps/web/src/pages/privacy.astro

@@ -0,0 +1,15 @@
+---
+import { siteName } from "@repo/ui";
+import Layout from "../layouts/Layout.astro";
+---
+
+<Layout title={`Privacy Policy — ${siteName}`}>
+  <main class="mx-auto my-16 max-w-2xl px-6 leading-[1.6]">
+    <h1 class="mb-6 text-3xl font-bold tracking-tight">Privacy Policy</h1>
+    <p class="mb-4">
+      Placeholder privacy policy for {siteName}. Replace with your own before
+      launch.
+    </p>
+    <p><a href="/" class="hover:underline">← Home</a></p>
+  </main>
+</Layout>

package/templates/base/apps/web/src/pages/terms.astro

@@ -0,0 +1,14 @@
+---
+import { siteName } from "@repo/ui";
+import Layout from "../layouts/Layout.astro";
+---
+
+<Layout title={`Terms of Service — ${siteName}`}>
+  <main class="mx-auto my-16 max-w-2xl px-6 leading-[1.6]">
+    <h1 class="mb-6 text-3xl font-bold tracking-tight">Terms of Service</h1>
+    <p class="mb-4">
+      Placeholder terms for {siteName}. Replace with your own before launch.
+    </p>
+    <p><a href="/" class="hover:underline">← Home</a></p>
+  </main>
+</Layout>