@getvitops/create 0.7.0 → 0.8.0-alpha.0

package/CHANGELOG.md

@@ -1,5 +1,148 @@
 # @getvitops/create
 
+## 0.8.0-alpha.0
+
+### Minor Changes
+
+- c3c1bcb: **New: the design-system editor, mounted inside the EmDash admin.** `vitopsEmdash({
+designSystemEditor: { config } })` (`config` is your `site.json`, e.g. `import config from
+'./site.json' with { type: 'json' }`) adds a `/design-system` admin page mounting
+  `<wc-theme-editor>` — the same live token editor `@getvitops/vite`'s dev server has always
+  offered, now usable by the client directly, no dev server required. An edit is visible
+  site-wide immediately (a runtime `:root` override, served via a new plugin API route and
+  `page:fragments`) and — once `site.deployment.repo`/`branch` and a `VITOPS_GITHUB_TOKEN`
+  secret are set (see the scaffold's `SETUP.html`) — auto-commits to your `dev` branch, so it
+  reaches the git-tracked `site.json` through your repo's normal review path rather than
+  becoming a second, unreviewed source of truth. Until that's configured, the live half still
+  works; only the auto-commit half is skipped (and says so in the admin page). The save route
+  runs the exact same accessibility (APCA contrast) gate `generate()` enforces at build time,
+  synchronously, before persisting — nothing non-compliant ever goes live even momentarily.
+
+  Requires `@astrojs/react` + `react` + `react-dom` (already scaffold dependencies, for
+  EmDash's own admin) and `@getvitops/core` (added as a new scaffold dependency this release).
+  Declares two new plugin capabilities when enabled: `network:request` (for the GitHub
+  auto-commit) and `hooks.page-fragments:register` (for the live override) — reviewed once at
+  plugin-install time.
+
+  **Breaking for `@getvitops/emdash`**: `vitopsEmdash()`'s `hooks.page-fragments:register`
+  capability is now also granted whenever `designSystemEditor` is set, independent of the
+  existing `scripts: 'fragments'` option (which governs something unrelated — web-component
+  script delivery). No change if you don't use `designSystemEditor`.
+
+  Also new, supporting the above:
+  - `@getvitops/generator`: `validateColorContract()` and `buildReverseIndex()` (both
+    `/tokens` subpath, Worker-safe) — the monotonicity/contrast gate and the
+    `design-manifest.json` reverse-index, each extracted from `generate()`'s `build()` into
+    standalone, non-throwing functions. `patchToOverrideCss()` turns a design-system patch
+    into the `:root` override `<style>` block. `designSystemPath`/`getAt`/`setAt`/
+    `mergePatch`/`formatConfig` moved from `@getvitops/vite` into `@getvitops/generator/config`
+    (re-exported from `@getvitops/vite` unchanged) — one "patch a config file's design-system
+    subtree" implementation shared by the dev endpoint and the new plugin route. New
+    `site.deployment.repo`/`branch` config fields.
+  - `@getvitops/utils`: new `/git` subpath — `commitFile()`, a Worker-safe (fetch-only)
+    wrapper over GitHub's Contents API.
+  - `@getvitops/core`: `<wc-theme-editor>` gains a `save-endpoint` attribute (default
+    unchanged — `/__vitops/design-system`) so the same element can target the new plugin
+    route instead of the dev-only Vite endpoint.
+
+### Patch Changes
+
+- 0574388: Add `vitops email setup|check` — connect `site.notifications.email.from` to whether its domain is
+  actually onboarded onto an outbound email provider.
+
+  Before this, nothing checked that. `EMAIL.send()` throws `E_SENDER_NOT_VERIFIED` at runtime with no
+  build or deploy-time warning — the failure mode is silent and production-only.
+
+  `vitops email setup [domain]` onboards a sending domain (currently Cloudflare Email Sending only)
+  and polls DNS until its SPF/DKIM/DMARC records resolve or a timeout is reached; `vitops email
+check` is the non-blocking deploy guard both `@getvitops/create` templates' `deploy`/`deploy:dev`
+  scripts now run first (`--strict` makes it a real gate; opt out per-site with
+  `site.notifications.email.verifySender: false`, or globally with `--skip` /
+  `VITOPS_SKIP_EMAIL_CHECK`).
+
+  Two things worth knowing before running it:
+  - **The onboarded entity is an exact name, and it is usually a subdomain**
+    (`send.yourdomain.com`), never the apex your `from` address names. When the exact domain isn't
+    onboarded but a sibling in the same zone already is, the command reports that as the fix — send
+    from the onboarded subdomain — rather than silently trying to onboard the apex, which rewrites
+    `_dmarc.<domain>` and can tighten DMARC policy on every other mail your domain sends.
+  - Candidates come from `site.notifications.email.from` (or its derived `noreply@<domains
+.canonical>` default) first; a best-effort scan of `--src` only supplements it, and never guesses
+    at a computed `from` value.
+
+  New `@getvitops/utils/email` subpath and `site.notifications.email.verifySender` config field.
+  Needs `CLOUDFLARE_API_TOKEN` with an Email Sending scope in addition to the `Zone:Read` other
+  commands already use.
+
+- 0574388: Bump `emdash`/`@emdash-cms/cloudflare` peers to `>=1.0.0 <2` and `vite-plus` to `^1.0.0`, following
+  both projects' GA releases.
+
+  **Breaking for `@getvitops/emdash` consumers on EmDash 0.x**: the peer range no longer admits
+  `emdash@0.31.x`/`@emdash-cms/cloudflare@0.31.x`. Upgrade `emdash` and `@emdash-cms/cloudflare` to
+  `^1.0.1` first — nothing in `@getvitops/emdash`'s own plugin surface (`admin.portableTextBlocks`,
+  the `hooks.page-fragments:register` capability, `definePlugin()`) changed against EmDash 1.0, so no
+  code here needed to change, only the declared range.
+
+  The `emdash` scaffold template (`vp create @getvitops:emdash`) picks up several fixes alongside
+  the version bump:
+  - `tailwindcss`/`@tailwindcss/vite` are now real dependencies — the template selected
+    `css.format: 'tailwind'` without installing either, which threw on build.
+  - `site.json` now sets `site.icons.sprite: true` plus the full `semantic` list the
+    `vitops.actionLink` block's icon picker offers — previously its sprite icons pointed at a file
+    the build never generated.
+  - `astro.config.mjs` sets `migrations: { runtime: 'check', dev: 'auto' }`, and
+    `site-deploy-emdash.yml` runs EmDash 1.0's documented `build → status → apply → deploy → check`
+    migration sequence explicitly, rather than relying solely on first-request auto-migration. This
+    needs a new GitHub Environment variable, `EMDASH_TARGET_FINGERPRINT` (one per environment),
+    which only a human can set — run `emdash migrate --status` against the real deployed database,
+    review the printed identity, then `gh variable set EMDASH_TARGET_FINGERPRINT --env <env> --body
+<value>`. Deploys fail clearly on the migration-apply step until it's set.
+  - `lint.options.typeAware`/`typeCheck` in the template's own `vite.config.ts` are commented out,
+    not deleted: vite-plus 1.0 only honours that option in a project's actual root config, and hard
+    errors on it in a nested one (which this file is, sitting inside the `design-system` monorepo).
+    Uncomment it once scaffolded into its own repo.
+
+  No config schema changes. `@getvitops/generator` also switches from the `zod/mini` subpath import
+  to the standalone `@zod/mini` package (zod 4.5+; same API) and fixes `validateConfig()` silently
+  losing the offending key name on an `unrecognized_keys` error (e.g. a typo'd `site.ads` platform
+  now names the bad key instead of reporting a bare "Invalid input").
+
+  Also fixed: `vp check`'s `tsconfig-error` for `packages/create/templates/emdash/tsconfig.json`
+  (`extends: "astro/tsconfigs/strict"`, unresolvable from inside this monorepo since the template
+  has no `node_modules` of its own — a pre-existing, structural gap, newly surfaced as a hard error
+  by oxlint 1.85's deeper config discovery, and blocking on every commit since this repo's pre-commit
+  hook runs `vp check --fix`). Fixed with a new `scripts/link-template-deps.mjs`, wired as the root
+  `postinstall` script: symlinks `astro`/`emdash`/`@emdash-cms/cloudflare` into the template's own
+  `node_modules/` (resolved fresh from sibling packages that already depend on them for real, not a
+  hardcoded `.pnpm` hash) and writes a minimal `astro:content` ambient shim at `.astro/types.d.ts`
+  (the same path `astro sync` would generate for real). Both are gitignored and only ever exist
+  inside this monorepo's copy of the template — a real scaffold installs its own real copies instead.
+  Considered and rejected first: inlining astro's strict preset (drift risk against astro's own
+  evolving default) and making the template a real pnpm workspace member (would change how its
+  `@getvitops/*: "latest"` deps resolve locally, which `templates.test.ts` exists to protect).
+
+  **Known gap, not fixed here**: `packages/astro/src/components/container.test.ts` (the
+  `AstroContainer`-based render tests) fails to even load under vite-plus 1.0's Vite 8 — direct
+  `.astro` imports in a Vitest file need the Astro Vite plugin registered, which nothing in this
+  repo's test config actually does (Astro's own docs call for `getViteConfig()`, which doesn't
+  compose with vite-plus's own `defineConfig`). A type-level shim
+  (`packages/astro/src/components/astro-modules.d.ts`) fixes `vp check`'s type-aware pass, but the
+  runtime `vp test` failure for this one file is still open.
+
+- 0f8c018: **New: `resolveOrganizationName(config, locale?)`**, exported from `@getvitops/astro/routes`
+  alongside `toNotifyContext`/`toCrmConfig` — the same `organization.name` → `legalName` →
+  `undefined` fallback chain `toNotifyContext` already used for its `organizationName` field,
+  now usable standalone anywhere a build-time-only display name is needed (favicon generation,
+  a scaffold's `astro.config.mjs`, a `Layout.astro` fallback). `toNotifyContext` is unchanged —
+  it now delegates to this helper internally.
+
+  The emdash scaffold uses it to remove a three-way duplicated `'My EmDash Site'` string:
+  `astro.config.mjs`'s favicon `name` and `Layout.astro`'s title fallback both previously
+  hardcoded it independently of `site.json`'s `organization.name`. EmDash's own
+  `getSiteSettings().title` (set in the admin) still wins at render time when it's set — it's a
+  runtime-only fact that can't be read at build time at all — this only replaces the two
+  hardcoded _fallback_ strings.
+
 ## 0.7.0
 
 ### Minor Changes
@@ -18,7 +161,6 @@
   `astro.config.mjs`. Not reachable by `vitops lint --fix` — this is the whole migration.
 
   Also new in both templates:
-
   - **`SETUP.html`** — a client-onboarding checklist (styled entirely with the framework's own
     classes, checkbox state in `localStorage`), generated a stylesheet for via the new
     `pnpm run sop` script.
@@ -266,15 +408,15 @@
   which `@getvitops/astro` re-exports wholesale. So from `astro.config.mjs`:
 
   ```js
-  import { generateIconInclude } from "@getvitops/astro";
-  import icon from "astro-icon";
+  import { generateIconInclude } from '@getvitops/astro';
+  import icon from 'astro-icon';
 
   integrations: [
     icon({
       include: generateIconInclude({
-        ui: "fa7-solid",
-        brand: "simple-icons",
-        semantic: ["menu", "close", "search", "github"],
+        ui: 'fa7-solid',
+        brand: 'simple-icons',
+        semantic: ['menu', 'close', 'search', 'github'],
       }),
     }),
   ];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@getvitops/create",
-  "version": "0.7.0",
+  "version": "0.8.0-alpha.0",
   "description": "Project templates for the Vitops design system — scaffold wired-up sites with `vp create @getvitops`.",
   "homepage": "https://docs.vitops.ca",
   "bugs": "https://github.com/getvitops/design-system/issues",
@@ -19,8 +19,7 @@
     "access": "public"
   },
   "devDependencies": {
-    "vitest": "4.1.9",
-    "@getvitops/generator": "8.1.0"
+    "@getvitops/generator": "8.2.0-alpha.0"
   },
   "engines": {
     "node": ">=24"

package/templates/emdash/.astro/types.d.ts

@@ -0,0 +1,3 @@
+declare module 'astro:content' {
+  export function defineLiveCollection(config: unknown): unknown;
+}

package/templates/emdash/.github/workflows/deploy-prod.yml

@@ -1,7 +1,7 @@
 # Deploys `main` to production.
 # `main` should be branch-protected — it then only advances via the Promote
 # workflow (promote.yml), so a push here always represents promoted code. The
-# `production` GitHub Environment (set up by `scripts/init-github.mjs`) has
+# `production` GitHub Environment (set up by `vitops setup repo`) has
 # required reviewers restricted to admins, so this PAUSES for approval before
 # deploying.
 #

package/templates/emdash/README.md

@@ -27,6 +27,11 @@ pnpm install
 pnpm dev
 ```
 
+Once this is its own repo (not sitting inside the `getvitops/design-system`
+monorepo), uncomment `lint.options` in `vite.config.ts` for type-aware
+`vp check`/`vp lint` — it ships commented out because vite-plus 1.0 only
+honours that option at a project's actual root, and errors on it otherwise.
+
 No Cloudflare account needed: `astro dev` runs the Worker locally with local
 D1/R2 emulation (state in `.wrangler/`). On first boot EmDash runs its
 migrations and applies the structure from `seed/seed.json` — a `pages`

package/templates/emdash/SETUP.html

@@ -159,6 +159,41 @@
                 this exists.
               </span>
             </label>
+            <label class="custom-check">
+              <input type="checkbox" data-sop="hosting.emdash-fingerprint" />
+              <span class="custom-check__box"
+                ><span class="custom-check__indicator custom-check__indicator--check"></span
+              ></span>
+              <span>
+                <strong>(EmDash template)</strong> After the first deploy to each environment, run
+                <code>npx emdash migrate --status</code> locally against that environment's real
+                database, review the printed account/database identity, and set the reviewed
+                fingerprint:
+                <code
+                  >gh variable set EMDASH_TARGET_FINGERPRINT --env dev --body &lt;value&gt;</code
+                >
+                and again with <code>--env production</code>. No command can do this for you — it's
+                the human review the fingerprint guard exists for. Deploys fail clearly on the
+                migration-apply step until it's set for that environment.
+              </span>
+            </label>
+            <label class="custom-check">
+              <input type="checkbox" data-sop="hosting.design-system-editor-token" />
+              <span class="custom-check__box"
+                ><span class="custom-check__indicator custom-check__indicator--check"></span
+              ></span>
+              <span>
+                <strong>(EmDash template, only if <code>designSystemEditor</code> is on)</strong>
+                Create a fine-grained GitHub PAT scoped to this one repository,
+                <code>Contents: Read and write</code> only — no <code>admin</code> scope, no access
+                to any other repo — then <code>gh secret set VITOPS_GITHUB_TOKEN</code>. Also set
+                <code>site.deployment.repo</code> (<code>"owner/name"</code>) and
+                <code>site.deployment.branch</code> (default <code>"dev"</code>) in
+                <code>site.json</code>. Without these the live design-system editor still works —
+                only the auto-commit-to-source half is skipped, and the admin page's response says
+                so.
+              </span>
+            </label>
           </div>
         </details>
 
@@ -326,6 +361,21 @@
                 <code>npx vitops setup ads</code>.
               </span>
             </label>
+            <label class="custom-check">
+              <input type="checkbox" data-sop="connections.email" />
+              <span class="custom-check__box"
+                ><span class="custom-check__indicator custom-check__indicator--check"></span
+              ></span>
+              <span>
+                If <code>site.notifications.email</code> sends mail, onboard its sender domain:
+                <code>npx vitops email setup --dry</code>, then <code>npx vitops email setup</code>.
+                Cloudflare onboards an exact name — usually a subdomain like
+                <code>send.&lt;domain&gt;</code>, not the apex — so a mismatch here is silent at
+                build time and only fails when a form is actually submitted in production. Both
+                templates' <code>deploy</code> script already runs
+                <code>vitops email check</code> first as a non-blocking warning.
+              </span>
+            </label>
             <label class="custom-check">
               <input type="checkbox" data-sop="connections.manual" />
               <span class="custom-check__box"

package/templates/emdash/astro.config.mjs

@@ -1,8 +1,17 @@
 import react from '@astrojs/react';
 import vitops from '@getvitops/astro';
+import { resolveOrganizationName } from '@getvitops/astro/routes';
 import { vitopsEmdash, vitopsHosting } from '@getvitops/emdash';
 import { defineConfig } from 'astro/config';
 import emdash from 'emdash/astro';
+import config from './site.json' with { type: 'json' };
+
+// site.json's organization.name is the one build-time-readable source for a
+// display name — EmDash's own getSiteSettings() only resolves inside a live
+// Worker request (AsyncLocalStorage + a DB binding), so it can't be read here
+// even though it's what Layout.astro shows on rendered pages. See AGENTS.md's
+// "EmDash plugin as the design-system editing surface".
+const organizationName = resolveOrganizationName(config) ?? 'My EmDash Site';
 
 // Hosting seam: adapter + EmDash database/storage for the configured target.
 // Default 'cloudflare' (Workers + D1 + R2 — see wrangler.jsonc / src/worker.ts).
@@ -30,12 +39,27 @@ export default defineConfig({
       // disclosure, carousel) in the editor slash menu. Default 'integration'
       // script delivery: Layout.astro renders <Head /> from @getvitops/astro,
       // which emits the web-component runtime tags.
-      plugins: [vitopsEmdash()],
+      //
+      // designSystemEditor mounts a live <wc-theme-editor> admin page at
+      // /design-system — edits are visible site-wide immediately (no
+      // rebuild) and auto-sync back to source once site.deployment.repo and
+      // a VITOPS_GITHUB_TOKEN secret are set (see SETUP.html) — see
+      // AGENTS.md's "EmDash plugin as the design-system editing surface".
+      // Until then the live half still works; only the sync half is skipped.
+      plugins: [vitopsEmdash({ designSystemEditor: { config } })],
+      // 1.0's runtime migration mode defaults to 'auto' (apply pending core
+      // migrations on first request) — fine for local dev, but a deploy
+      // should have already migrated before traffic arrives. 'check' 503s a
+      // request instead of migrating behind it if the explicit `emdash
+      // migrate` step in site-deploy-emdash.yml (see AGENTS.md's CI/CD
+      // section) was skipped or failed. `dev: 'auto'` keeps the convenient
+      // first-run behaviour for `pnpm dev`.
+      migrations: { runtime: 'check', dev: 'auto' },
     }),
     vitops({
       favicon: {
         source: 'src/assets/logo.svg',
-        name: 'My EmDash Site',
+        name: organizationName,
         themeColor: '#2e9b73',
         backgroundColor: '#ffffff',
       },

package/templates/emdash/package.json

@@ -7,8 +7,8 @@
     "dev": "astro dev",
     "build": "astro build",
     "preview": "astro preview",
-    "deploy": "astro build && wrangler deploy",
-    "deploy:dev": "astro build && node scripts/build-dev-wrangler.mjs && wrangler deploy --config dist/server/wrangler.dev.json",
+    "deploy": "vitops email check && astro build && emdash migrate --wrangler-config wrangler.jsonc && wrangler deploy",
+    "deploy:dev": "vitops email check && astro build && node scripts/build-dev-wrangler.mjs && emdash migrate --wrangler-config dist/server/wrangler.dev.json && wrangler deploy --config dist/server/wrangler.dev.json",
     "init:github": "vitops setup repo",
     "init:hosting": "vitops setup hosting",
     "setup": "vitops setup all",
@@ -21,13 +21,16 @@
   "dependencies": {
     "@astrojs/cloudflare": "^14.0.0",
     "@astrojs/react": "^6.0.0",
-    "@emdash-cms/cloudflare": "^0.31.0",
+    "@emdash-cms/cloudflare": "^1.0.1",
     "@getvitops/astro": "latest",
+    "@getvitops/core": "latest",
     "@getvitops/emdash": "latest",
+    "@tailwindcss/vite": "^4.3.3",
     "astro": "^7.1.2",
-    "emdash": "^0.31.0",
+    "emdash": "^1.0.1",
     "react": "^19.2.4",
-    "react-dom": "^19.2.4"
+    "react-dom": "^19.2.4",
+    "tailwindcss": "^4.3.3"
   },
   "devDependencies": {
     "@astrojs/check": "^0.9.7",

package/templates/emdash/site.json

@@ -223,6 +223,81 @@
         "url": "https://dev.my-emdash-site.example.com",
         "robots": "noindex,nofollow"
       }
+    },
+    "icons": {
+      "sprite": true,
+      "semantic": [
+        "menu",
+        "close",
+        "home",
+        "settings",
+        "search",
+        "add",
+        "remove",
+        "delete",
+        "edit",
+        "save",
+        "copy",
+        "paste",
+        "attach",
+        "upload",
+        "download",
+        "share",
+        "bookmark",
+        "favorite",
+        "star",
+        "login",
+        "logout",
+        "email",
+        "phone",
+        "location",
+        "globe",
+        "link",
+        "clock",
+        "calendar",
+        "schedule",
+        "person",
+        "group",
+        "file",
+        "folder",
+        "image",
+        "export",
+        "import",
+        "backup",
+        "compress",
+        "check",
+        "error",
+        "warning",
+        "info",
+        "help",
+        "cart",
+        "tag",
+        "receipt",
+        "leaf",
+        "tree",
+        "seedling",
+        "trowel",
+        "droplet",
+        "snowflake",
+        "sun",
+        "cloud",
+        "grid",
+        "list",
+        "filter",
+        "sort",
+        "fullscreen",
+        "collapse",
+        "building",
+        "video",
+        "lock",
+        "unlock",
+        "eye",
+        "print",
+        "code",
+        "palette",
+        "lightbulb",
+        "lightning"
+      ]
     }
   }
 }

package/templates/emdash/src/layouts/Layout.astro

@@ -1,8 +1,10 @@
 ---
 import VitopsHead from '@getvitops/astro/Head.astro';
+import { resolveOrganizationName } from '@getvitops/astro/routes';
 import { getMenu, getSiteSettings } from 'emdash';
 import { createPublicPageContext } from 'emdash/page';
 import { EmDashHead } from 'emdash/ui';
+import config from '../../site.json' with { type: 'json' };
 // Design-system CSS, layout-scoped (vitops css.inject: false): only pages
 // rendered through this layout get it — keeps it out of /_emdash/admin, while
 // EmDash previews (rendered through this layout) keep it.
@@ -19,7 +21,11 @@ interface Props {
 
 const { title, description, image } = Astro.props;
 const settings = await getSiteSettings();
-const siteTitle = settings?.title || 'My EmDash Site';
+// getSiteSettings().title is the editable, client-facing display name (set in
+// the EmDash admin) — it wins whenever it's set. resolveOrganizationName(config)
+// is the fallback rather than a second hardcoded string, so a fresh scaffold
+// shows organization.name (from site.json) before anyone's touched the admin.
+const siteTitle = settings?.title || resolveOrganizationName(config) || 'My EmDash Site';
 const fullTitle = title ? `${title} — ${siteTitle}` : siteTitle;
 const siteDescription = settings?.tagline || 'An EmDash website with the Vitops design system';
 

package/templates/emdash/src/pages/404.astro

@@ -1,5 +1,10 @@
 ---
 import Layout from '../layouts/Layout.astro';
+
+// No per-request data — safe to prerender per AGENTS.md's "Prerender by
+// default" rule. [...slug].astro reaches this via Astro.rewrite('/404'),
+// which resolves a prerendered destination the same as a server-rendered one.
+export const prerender = true;
 ---
 
 <Layout title="Page not found">

package/templates/emdash/src/pages/[...slug].astro

@@ -4,6 +4,13 @@ import { PortableText } from 'emdash/ui';
 import Layout from '../layouts/Layout.astro';
 
 // Catch-all: any entry in the `pages` collection renders at its slug.
+//
+// Deliberately NOT prerendered, unlike AGENTS.md's general "prerender by
+// default" rule — see index.astro's comment for why: a live EmDash publish
+// should reach visitors without a redeploy. A page that's known ahead of
+// time and doesn't need that (rarely edited, or fine to lag a build) can
+// move to its own prerendered route with `getStaticPaths()` over the
+// `pages` collection instead of relying on this catch-all.
 const { slug } = Astro.params;
 const { entry: page } = slug ? await getEmDashEntry('pages', slug) : { entry: null };
 

package/templates/emdash/src/pages/index.astro

@@ -6,6 +6,13 @@ import Layout from '../layouts/Layout.astro';
 // The seeded home page (seed/seed.json → pages/home). Edit it in the admin;
 // the Vitops blocks from @getvitops/emdash render automatically — EmDash
 // merges the plugin's block components into <PortableText>.
+//
+// Deliberately NOT prerendered, unlike AGENTS.md's general "prerender by
+// default" rule: this is the one route where the tradeoff that rule names
+// (prerendered = fast, but reflects the database as of the last build) is
+// unacceptable — the whole point of editing in EmDash is that a publish
+// shows up without a redeploy. Add `getStaticPaths()` + `prerender = true`
+// here only if this site's home page genuinely doesn't need that.
 const { entry: page } = await getEmDashEntry('pages', 'home');
 ---
 

package/templates/emdash/vite.config.ts

@@ -11,13 +11,27 @@ export default defineConfig({
       'vitops lint -i site.json -f tailwind --strict',
   },
   fmt: {
+    // Explicit, matching the monorepo root's style: unlike `lint`, a nested
+    // `fmt` config genuinely takes effect independently here rather than
+    // being root-only, so leaving these unset let this file (and anything
+    // else oxfmt formats under this directory, e.g. SETUP.html's embedded
+    // `<script>`) drift to a different default quote style each time
+    // `vp check --fix` ran, breaking `templates.test.ts`'s byte-identical
+    // mirror assertion.
+    semi: true,
+    singleQuote: true,
     ignorePatterns: ['dist/**', 'node_modules/**', 'src/styles/**', 'public/vitops/**'],
   },
   lint: {
     ignorePatterns: ['dist/**', 'node_modules/**', 'src/styles/**', 'public/vitops/**'],
-    options: {
-      typeAware: true,
-      typeCheck: true,
-    },
+    // `options.typeAware`/`typeCheck` commented out, not deleted: vite-plus 1.0
+    // only honours those at the root config, and while this file sits nested
+    // inside the getvitops/design-system monorepo (which has its own root
+    // vite.config.ts), setting them here is a hard error — "typeAware is only
+    // supported in the root config" — rather than the silent no-op it was
+    // pre-1.0. Once `vp create @getvitops:emdash` scaffolds this file out into
+    // its own project, it *becomes* that project's root config, and
+    // uncommenting this is the right move there.
+    // options: { typeAware: true, typeCheck: true },
   },
 });

package/templates/static/.github/workflows/deploy-prod.yml

@@ -1,7 +1,7 @@
 # Deploys `main` to production.
 # `main` should be branch-protected — it then only advances via the Promote
 # workflow (promote.yml), so a push here always represents promoted code. The
-# `production` GitHub Environment (set up by `scripts/init-github.mjs`) has
+# `production` GitHub Environment (set up by `vitops setup repo`) has
 # required reviewers restricted to admins, so this PAUSES for approval before
 # deploying.
 #

package/templates/static/SETUP.html

@@ -159,6 +159,41 @@
                 this exists.
               </span>
             </label>
+            <label class="custom-check">
+              <input type="checkbox" data-sop="hosting.emdash-fingerprint" />
+              <span class="custom-check__box"
+                ><span class="custom-check__indicator custom-check__indicator--check"></span
+              ></span>
+              <span>
+                <strong>(EmDash template)</strong> After the first deploy to each environment, run
+                <code>npx emdash migrate --status</code> locally against that environment's real
+                database, review the printed account/database identity, and set the reviewed
+                fingerprint:
+                <code
+                  >gh variable set EMDASH_TARGET_FINGERPRINT --env dev --body &lt;value&gt;</code
+                >
+                and again with <code>--env production</code>. No command can do this for you — it's
+                the human review the fingerprint guard exists for. Deploys fail clearly on the
+                migration-apply step until it's set for that environment.
+              </span>
+            </label>
+            <label class="custom-check">
+              <input type="checkbox" data-sop="hosting.design-system-editor-token" />
+              <span class="custom-check__box"
+                ><span class="custom-check__indicator custom-check__indicator--check"></span
+              ></span>
+              <span>
+                <strong>(EmDash template, only if <code>designSystemEditor</code> is on)</strong>
+                Create a fine-grained GitHub PAT scoped to this one repository,
+                <code>Contents: Read and write</code> only — no <code>admin</code> scope, no access
+                to any other repo — then <code>gh secret set VITOPS_GITHUB_TOKEN</code>. Also set
+                <code>site.deployment.repo</code> (<code>"owner/name"</code>) and
+                <code>site.deployment.branch</code> (default <code>"dev"</code>) in
+                <code>site.json</code>. Without these the live design-system editor still works —
+                only the auto-commit-to-source half is skipped, and the admin page's response says
+                so.
+              </span>
+            </label>
           </div>
         </details>
 
@@ -326,6 +361,21 @@
                 <code>npx vitops setup ads</code>.
               </span>
             </label>
+            <label class="custom-check">
+              <input type="checkbox" data-sop="connections.email" />
+              <span class="custom-check__box"
+                ><span class="custom-check__indicator custom-check__indicator--check"></span
+              ></span>
+              <span>
+                If <code>site.notifications.email</code> sends mail, onboard its sender domain:
+                <code>npx vitops email setup --dry</code>, then <code>npx vitops email setup</code>.
+                Cloudflare onboards an exact name — usually a subdomain like
+                <code>send.&lt;domain&gt;</code>, not the apex — so a mismatch here is silent at
+                build time and only fails when a form is actually submitted in production. Both
+                templates' <code>deploy</code> script already runs
+                <code>vitops email check</code> first as a non-blocking warning.
+              </span>
+            </label>
             <label class="custom-check">
               <input type="checkbox" data-sop="connections.manual" />
               <span class="custom-check__box"

package/templates/static/package.json

@@ -7,8 +7,8 @@
     "dev": "astro dev",
     "build": "astro build",
     "preview": "astro preview",
-    "deploy": "astro build && wrangler deploy",
-    "deploy:dev": "astro build && node scripts/dev-wrangler-config.mjs && wrangler deploy --config .wrangler.dev.json",
+    "deploy": "vitops email check && astro build && wrangler deploy",
+    "deploy:dev": "vitops email check && astro build && node scripts/dev-wrangler-config.mjs && wrangler deploy --config .wrangler.dev.json",
     "init:github": "vitops setup repo",
     "init:hosting": "vitops setup hosting --no-dev-resources",
     "setup": "vitops setup repo && vitops setup hosting --no-dev-resources",