create-ailk 0.8.0 → 0.9.0

package/templates/.claude/skills/setup-deploy/references/env-vars-template.md

@@ -46,21 +46,37 @@ CONTENT_BACKEND=mdx
 # With neither, /contact shows your contact email (content/_site.mdx
 # `contactEmail`) instead of the form in production.
 
+# ── API origin checks + checkout gate (apps/api) ─────────────────
+# Set both on the API project. Unset in production, the API logs a
+# startup warning for each and keeps running, but:
+# - without FRONTEND_URL, CORS and cookie origin checks are pinned to
+#   http://localhost:3000 and checkout answers 500 to a caller admitted
+#   without X-Internal-Auth;
+# - without OSS_API_INTERNAL_SECRET, the checkout route admits callers
+#   without the X-Internal-Auth header.
+# FRONTEND_URL is the site the browser loads (no trailing slash).
+# FRONTEND_URL=https://your-domain.com
+# Shared secret: the same value on the API and web projects.
+# Generate with: openssl rand -hex 32
+# OSS_API_INTERNAL_SECRET=
+
 # ── Auth — required env vars ─────────────────────────────────────
 # Set to "1" to require sign-in for protected routes; default is
 # auth-disabled / public.
 # AILK_AUTH_REQUIRED=1
 #
-# NextAuth secret — production must be set; generate with:
+# Better Auth secret — signs session cookies. REQUIRED in production:
+# apps/web/auth.ts throws in production without it. Generate with:
 #   openssl rand -base64 32
-# Local dev (next dev) auto-generates a session-only secret.
-# NEXTAUTH_SECRET=
+# Local dev (next dev) uses a development fallback.
+# BETTER_AUTH_SECRET=
 #
-# Production base URL for callback construction. Local dev defaults
-# to http://localhost:3000 if unset.
-# NEXTAUTH_URL=https://your-domain.com
+# The site's public origin — Better Auth builds OAuth callback URLs on
+# it and trusts only it. Set it in production; local dev can leave it
+# unset.
+# BETTER_AUTH_URL=https://your-domain.com
 
-# ── Auth — magic-link (Resend) ───────────────────────────────────
+# ── Auth — email sign-in (Resend) ────────────────────────────────
 # Activated when both AUTH_EMAIL_SERVER and AUTH_EMAIL_FROM are set.
 # Get a Resend API key at https://resend.com/api-keys.
 # AUTH_EMAIL_SERVER=smtp://resend:re_yourkeyhere@smtp.resend.com:465
@@ -116,7 +132,7 @@ CONTENT_BACKEND=mdx
 
 ## Categories the skill emits
 
-The template above groups vars into six categories. Every emitted
+The template above groups vars into seven categories. Every emitted
 `.env.example` should hit each category at least with its header
 comment, even if the consumer hasn't activated any vars in that
 category — the comment block tells future-them what's available.
@@ -126,9 +142,10 @@ Categories:
 1. Marketing / canonical domain
 2. Content backend
 3. Lead delivery (database or email)
-4. Auth — required + per-provider
-5. Stripe (sandbox-only)
-6. Analytics
+4. API origin checks + checkout gate
+5. Auth — required + per-provider
+6. Stripe (sandbox-only)
+7. Analytics
 
 ## What the skill never includes
 

package/templates/.claude/skills/update-page/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: update-page
+description: Rename a page on this AI Launch Kit site — change its URL (/meet to /schedule, /team to /people) and/or its title — safely, in one plan-then-confirm pass. Use this whenever the user wants to move, rename, re-slug or re-title an existing page, even if they don't say "rename" — "make /meet be /schedule", "the booking page should live at /book", "call the team page People", "I don't like this URL". It moves the content file(s), the page's own route folder if it has one, every exact internal link, the site-manifest row, and adds a permanent redirect from the old URL. It refuses pages whose URL is fixed by their type or shipped by the scaffold. Not for adding a page (add-page) or rewriting its words (fill-page).
+---
+
+# update-page
+
+Move a page from `/old` to `/new` (and optionally give it a new title) without
+leaving a dead link, a stale manifest row, or a broken inbound URL behind. A
+bundled helper computes the whole change as a plan; you show the plan, the user
+confirms once, and only then does anything get written.
+
+## The one rule
+
+**Never run `apply` before the user has seen the plan and confirmed it.** The
+helper enforces this mechanically — `apply` requires the hash the plan printed,
+and refuses any other — but the order is yours to keep:
+plan → show the file list → wait for confirmation → apply with the plan hash.
+
+## Step 1 — Plan
+
+From the site root:
+
+```bash
+pnpm exec tsx .claude/skills/update-page/scripts/update-page.ts plan --from /meet --to /schedule
+```
+
+Add `--name "Book a time"` to also change the page's title (the `title:` in its
+content file; it sets the English file only and reports other languages as
+"title left as translated").
+
+The helper prints:
+
+- every file it would touch, tagged `move`, `modify`, `create` or `delete`;
+- `note:` lines a reader should know about (see below);
+- `hash: <sha256>` — the plan's fingerprint.
+
+It writes nothing. If it prints `refused: …` and exits 3, stop there and tell
+the user why (the reasons are below). Don't work around a refusal by hand.
+
+## Step 2 — Show the plan and wait
+
+Show the user the file list and the notes as printed. If they want to see the
+new contents, `plan --json` prints every change with its full new content.
+Then wait for one confirmation. A "yes" to the summary is enough; you don't
+need per-file approval.
+
+## Step 3 — Apply
+
+```bash
+pnpm exec tsx .claude/skills/update-page/scripts/update-page.ts apply --from /meet --to /schedule --confirm <hash>
+```
+
+Pass the same `--from`, `--to` and `--name` as the plan. The helper re-plans
+and compares hashes: if anything changed in between (a file was edited, a
+different rename was planned), it exits 1 and writes nothing — run `plan` again
+and confirm the new hash.
+
+## Step 4 — Check and report
+
+Run `pnpm build` from the site root. Then tell the user:
+
+- the new URL (with the locale, e.g. `/en/schedule`), and that `/meet` now
+  answers with a permanent redirect (HTTP 308) to it;
+- any `note:` lines that need their attention (below);
+- that the nav label text lives in `apps/web/messages/<locale>.json` if they
+  also want the menu wording changed — this skill only re-points the link.
+
+## What the plan changes
+
+| Surface | What happens |
+|---|---|
+| `content/<locale>/<Type>/old.mdx` (every locale) | Renamed to `new.mdx`; its `slug:` updated; `title:` updated when `--name` is given |
+| The page's own route folder (only an `add-page`-created route has one) | Moved to the sibling folder `new/`; the `getPage("old")` literal inside becomes `getPage("new")` |
+| Exact links to `/old` in `content/**` and `apps/web/lib/nav-config.ts` | Rewritten to `/new`. Exact means the whole path: `/meet` is rewritten, `/meet/book-a-call` and `/meeting` are not |
+| `.ailk-site-manifest.json` | The one row whose `route` is `/old` now reads `/new`; no other byte changes |
+| `apps/web/next.config.mjs` `redirects()` | Gains a managed block (`ailk:page-renames`) with `{ from: "/old", to: "/new" }`. Locale-prefixed forms are added for every non-default locale. A second rename collapses chains: renaming `/schedule` to `/book` later re-points the `/meet` row straight to `/book` |
+
+Links to `/old` in code files (`apps/web/app`, `lib`, `components`) are
+reported, not rewritten — the redirect covers them, and code edits are the
+owner's call.
+
+## The notes, and what to say about them
+
+- **"…belongs to the `<module>` module's routes…"** — the old or new URL is a
+  route a paid module (scheduling, docs-blog, …) would install if the site
+  adds it later. Tell the user: if they add that module, the redirect (for the
+  old URL) or the module's folder (for the new URL) will take over, and the
+  note says what to remove or rename first.
+- **"add-module `<module>` will keep these edited placeholder files…"** — the
+  rename edited seed pages that a module would normally replace; the module
+  will now list them for review instead. Nothing is lost.
+- **"add-module will no longer regenerate the nav…"** — the nav is now a
+  hand-edited file; later module installs report the nav change they wanted
+  rather than applying it.
+- **"the pages under /old … keep their URLs"** — detail pages like
+  `/meet/book-a-call` are fixed by their type and stay where they are.
+
+## When the helper refuses (exit 3)
+
+| Reason | What it means | What to offer instead |
+|---|---|---|
+| `routes must be one lowercase segment` | Only a top-level page moves (`/meet`, not `/meet/book-a-call`) | Detail pages are fixed by their type |
+| `no page at /old` | Nothing on the site is served there | Check the URL; `add-page` adds a page |
+| `/old is a code route with no page content to move` | A route folder exists but no content page backs it | A code change, not a rename |
+| `a <Type> page's URL is fixed by its type` | About, Contact, a Service, a booking page — their URL comes from the page type | Explain that these can't move; the title can still change in the content file |
+| `/old is served by a route the scaffold ships` | The route folder came with the scaffold (e.g. `/pricing`) | Same as above |
+| `/new already exists: …` | A route folder, another page, or a content locale directory owns `/new` | Pick another route |
+| `redirects() has been edited` | Someone hand-edited `redirects()` in `next.config.mjs`, so the helper won't touch it | Add the redirect line the message gives, by hand, or restore the generated method |
+
+## What this skill does not do
+
+- Add a page (`add-page`) or rewrite its words (`fill-page`).
+- Change the menu label text in `apps/web/messages/*.json` (it re-points the
+  link and reports the label key).
+- Edit route literals in code, or anything in `apps/api` / `apps/mcp`.
+- Move detail pages, hubs, or any page whose URL is fixed by its type.