@getvitops/create 0.1.0

package/README.md

@@ -0,0 +1,65 @@
+# @getvitops/create
+
+Project templates for the Vitops design system, consumed by
+[Vite+](https://viteplus.dev)'s `vp create` via the `createConfig.templates`
+manifest in this package's `package.json`.
+
+## Usage
+
+```bash
+# Interactive picker over this package's templates
+vp create @getvitops
+
+# Scaffold a specific template directly
+vp create @getvitops:emdash
+```
+
+`vp create` copies the template, initializes git, installs dependencies, and
+(optionally) writes agent/editor config — see `vp create --help`.
+
+## Templates
+
+### `emdash`
+
+An [EmDash CMS](https://docs.emdashcms.com) website on Cloudflare Workers,
+with every relevant `@getvitops/*` package pre-wired:
+
+- **`@getvitops/astro`** — the `getvitops()` integration: design-system CSS
+  generated from `design-system.json` (Tailwind v4 format, layout-scoped via
+  `css.inject: false`), favicons/PWA from `src/assets/logo.svg`, and the
+  web-component runtime copied into `public/vitops/`.
+- **`@getvitops/emdash`** — the EmDash native plugin: Vitops Portable Text
+  blocks (image compare, copy snippet, banner, disclosure, carousel) editors
+  insert from the admin slash menu, rendered with the design-system web
+  components (accessible no-JS fallbacks included).
+- **`@getvitops/cli`** — `vitops` on the scaffolded project's PATH for
+  `vitops validate`, `vitops agents`, and manual `vitops generate` runs.
+- **EmDash on Cloudflare** — D1 database + R2 media via
+  `@emdash-cms/cloudflare`, a Worker entry with the cron trigger for
+  scheduled publishing, and a seed (`seed/seed.json`): the `pages`
+  collection, `primary`/`footer` menus, and settings apply on first boot; the
+  starter pages (home, about, terms, privacy — plus a 404 route) publish when
+  the setup wizard's "include sample content" option is chosen.
+- **dev → main promotion flow** — GitHub Actions deploying `dev` to an
+  isolated `-dev` worker (`dev.<domain>` with a custom domain; own D1/R2 via
+  `scripts/build-dev-wrangler.mjs`, which hard-fails without `DEV_D1_ID`) and
+  `main` to prod, plus a manual `promote.yml` workflow and a matching
+  `promote` agent skill (`.agents/skills/promote/`) that opens the
+  `dev → main` PR with auto-merge.
+- **AI tooling baked in** — `.mcp.json` with the Astro + EmDash docs MCP
+  servers, and a Claude Code web SessionStart hook that installs Node 24
+  (matching `devEngines`) and the pinned pnpm in the remote container.
+
+The scaffolded README walks through local dev (`pnpm dev` — no Cloudflare
+account needed) and deploy (`wrangler login && pnpm deploy` — wrangler
+provisions the D1/R2 resources on first deploy).
+
+## Adding a template
+
+1. Add a directory under `templates/<name>/` (copied as-is; ship `_gitignore`
+   instead of `.gitignore` — `vp create` renames it).
+2. Add a `{ name, description, template: './templates/<name>' }` entry to
+   `createConfig.templates` in `package.json`.
+
+Template dependencies must use concrete npm ranges (no `workspace:*` /
+`catalog:` — the scaffolded project lives outside this monorepo).

package/package.json

@@ -0,0 +1,22 @@
+{
+  "name": "@getvitops/create",
+  "version": "0.1.0",
+  "description": "Project templates for the Vitops design system — scaffold wired-up sites with `vp create @getvitops`.",
+  "license": "MIT",
+  "files": [
+    "templates"
+  ],
+  "type": "module",
+  "publishConfig": {
+    "access": "public"
+  },
+  "createConfig": {
+    "templates": [
+      {
+        "name": "emdash",
+        "description": "EmDash CMS website on Cloudflare Workers (D1 + R2) with the Vitops design system pre-wired",
+        "template": "./templates/emdash"
+      }
+    ]
+  }
+}

package/templates/emdash/.agents/skills/promote/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: promote
+description: Promote dev → main to deploy the site to production. Use ONLY when the user explicitly asks to promote, ship, or release dev to prod (e.g. "/promote", "promote to prod", "ship dev to production"). This is a deliberate production deploy — never trigger it automatically from generic "deploy" talk or as a side effect of other work.
+---
+
+# Promote (dev → main → production)
+
+Promotion is the **manual** step that ships reviewed `dev` code to production.
+It dispatches the **"Promote dev → main"** GitHub Action
+(`.github/workflows/promote.yml`), which opens a PR from `dev` into the
+protected `main` branch and enables auto-merge. Merging `main` triggers
+**Deploy prod** (`deploy-prod.yml`), which ships the production worker.
+
+Deploys that are **already automatic** (do not use this skill for them):
+
+- **dev** auto-deploys on every push/merge to `dev` (`deploy-dev.yml` → the
+  `-dev` worker / `dev.<domain>`).
+- **prod** auto-deploys on every push to `main` (`deploy-prod.yml`).
+
+So this skill's only job is to kick off the `dev → main` promotion. It does
+**not** promote schema/content — see below.
+
+## Steps
+
+1. **Confirm intent.** This ships to production. Briefly state what will happen
+   ("This opens a PR from `dev` into `main`; merging deploys production.") and
+   proceed — the user invoking this skill is the confirmation. Only pause to
+   ask if they haven't clearly asked to go to prod.
+
+2. **Dispatch the workflow** with the `gh` CLI (works from any checkout of this
+   repo; `--ref main` picks which copy of the workflow file runs — the workflow
+   itself operates on `dev` and `main` regardless):
+
+   ```bash
+   gh workflow run promote.yml --ref main
+   ```
+
+3. **Find the run and report back.** Dispatch prints no run ID, so list the
+   runs to get the URL:
+
+   ```bash
+   gh run list --workflow=promote.yml --limit 1 --json databaseId,url,status,conclusion
+   ```
+
+   Give the user the run's `url`. If they want, watch it:
+   `gh run watch <databaseId>`, then report the conclusion and the promotion
+   PR: `gh pr view dev --base main --json url,state`.
+
+## What to tell the user after dispatch
+
+- The workflow opens (or reuses) a PR **dev → main** and enables auto-merge.
+- **`main` should be branch-protected.** Whether the merge completes hands-off
+  depends on the repo setup:
+  - With **required reviews** (default), the PR waits for a human to approve —
+    the default `GITHUB_TOKEN` can't approve its own PR. Point the user to the
+    PR to approve it; only then does prod deploy.
+  - If a `PROMOTE_TOKEN` secret (a PAT / GitHub App token allowed to bypass
+    protection) is set, auto-merge completes on its own and prod deploys with
+    no further action.
+- Once `main` advances, **Deploy prod** runs automatically.
+
+## Schema / content changes
+
+If this release changes the content model, code promotion is **not** enough —
+the schema lives in the EmDash database, not git. Apply the same schema change
+to the prod site separately (via its admin at `/_emdash/admin` or its MCP
+server at `/_emdash/api/mcp`). Ordering: additive changes (new collection /
+optional field) **before** the code deploy that uses them; removals **after**
+the code that stops using them. Mention this to the user only if the release
+plausibly touched the schema.

package/templates/emdash/.claude/hooks/session-start.sh

@@ -0,0 +1,40 @@
+#!/bin/bash
+#
+# SessionStart hook for Claude Code on the web.
+#
+# The web container ships Node 20/21/22, but this project pins Node 24 via
+# `devEngines` in package.json. This hook installs Node 24 (via the image's
+# nvm), makes it win over the baked-in Node on PATH for the whole session,
+# activates the pinned pnpm, and installs dependencies so `astro check`,
+# builds, and the EmDash CLI all run against the version the project expects.
+set -euo pipefail
+
+# Only relevant in the remote web container; local sessions manage their own Node.
+if [ "${CLAUDE_CODE_REMOTE:-}" != "true" ]; then
+	exit 0
+fi
+
+# --- Node 24 (matches package.json > devEngines.runtime) ---------------------
+export NVM_DIR="${NVM_DIR:-/opt/nvm}"
+# shellcheck disable=SC1091
+[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
+
+nvm install 24
+nvm alias default 24
+
+# The base image prepends its own node bin dir to PATH, ahead of nvm's shims,
+# so a plain `node` resolves to the baked-in version. Put Node 24's bin dir
+# first for this session and persist it to every subsequent tool call via
+# $CLAUDE_ENV_FILE.
+NODE24_BIN="$(dirname "$(nvm which 24)")"
+export PATH="$NODE24_BIN:$PATH"
+echo "export PATH=\"$NODE24_BIN:\$PATH\"" >> "$CLAUDE_ENV_FILE"
+
+# --- Dependencies (pnpm, pinned via package.json > packageManager) -----------
+cd "$CLAUDE_PROJECT_DIR"
+export COREPACK_ENABLE_DOWNLOAD_PROMPT=0
+corepack enable
+# `install` (not `--frozen-lockfile`) so the warmed container cache is reusable.
+pnpm install
+
+echo "Ready: Node $(node --version), pnpm $(pnpm --version)"

package/templates/emdash/.claude/settings.json

@@ -0,0 +1,14 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/session-start.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

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

@@ -0,0 +1,41 @@
+# Deploys the `dev` branch to the isolated dev worker (<name>-dev, and
+# dev.<domain> if a custom domain is configured in wrangler.jsonc).
+# `dev` is the integration branch — every push here refreshes the review site.
+# Promote to production with the "Promote dev → main" workflow (promote.yml).
+#
+# Required repo secrets:
+#   CLOUDFLARE_API_TOKEN   — token with Workers + D1 + R2 edit on this account
+#   CLOUDFLARE_ACCOUNT_ID  — the Cloudflare account id
+#   DEV_D1_ID              — id from `wrangler d1 create <name>-dev`
+#                            (without it the build script hard-fails, on purpose)
+name: Deploy dev
+
+on:
+  push:
+    branches: [dev]
+
+permissions:
+  contents: read
+
+concurrency:
+  group: deploy-dev
+  cancel-in-progress: true
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    environment: dev
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '24'
+          cache: pnpm
+      - run: pnpm install --frozen-lockfile
+      - name: Build + deploy dev worker
+        run: pnpm run deploy:dev
+        env:
+          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+          DEV_D1_ID: ${{ secrets.DEV_D1_ID }}

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

@@ -0,0 +1,36 @@
+# 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.
+#
+# Required repo secrets:
+#   CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID
+name: Deploy prod
+
+on:
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+concurrency:
+  group: deploy-prod
+  cancel-in-progress: false
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - uses: actions/checkout@v4
+      - uses: pnpm/action-setup@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '24'
+          cache: pnpm
+      - run: pnpm install --frozen-lockfile
+      - name: Build + deploy prod worker
+        run: pnpm run deploy
+        env:
+          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

package/templates/emdash/.github/workflows/promote.yml

@@ -0,0 +1,49 @@
+# Promote dev → main (code). Run manually after reviewing the dev site.
+# Opens a PR from dev into the protected `main` branch and enables auto-merge;
+# the merge triggers Deploy prod.
+#
+# Branch protection on `main` means the merge only completes when its rules are
+# satisfied. Choose ONE:
+#   (a) let a human approve the PR (required reviews) — safest, full audit trail;
+#   (b) set repo secret PROMOTE_TOKEN to a PAT / GitHub App token allowed to
+#       bypass protection, for hands-off promotion.
+# The default GITHUB_TOKEN cannot approve its own PR, so with required reviews
+# the PR waits for a human — which is usually what you want for a prod promotion.
+#
+# Schema/content promotion is deliberately NOT here — the content model lives in
+# the EmDash database, not git. Apply schema changes to prod via the admin or
+# the site's MCP server, additive changes before the code deploy that uses
+# them, removals after the code that stops using them.
+name: Promote dev → main
+
+on:
+  workflow_dispatch:
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  promote:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Open promotion PR and enable auto-merge
+        env:
+          GH_TOKEN: ${{ secrets.PROMOTE_TOKEN || github.token }}
+        run: |
+          set -euo pipefail
+          if gh pr view dev --base main --json number >/dev/null 2>&1; then
+            echo "Promotion PR already open; ensuring auto-merge is enabled."
+          else
+            # printf, not a multi-line string: an unindented continuation line
+            # would end this YAML block and break the whole workflow file.
+            gh pr create --base main --head dev \
+              --title "Promote dev → main" \
+              --body "$(printf '%s\n\n%s' \
+                "Automated code promotion from \`dev\`. Merging deploys to production." \
+                "Remember: schema/content changes live in the EmDash database, not git — promote them separately if this release changes the content model.")"
+          fi
+          gh pr merge dev --auto --merge

package/templates/emdash/.mcp.json

@@ -0,0 +1,12 @@
+{
+  "mcpServers": {
+    "astro-docs": {
+      "type": "http",
+      "url": "https://mcp.docs.astro.build/mcp"
+    },
+    "emdash-docs": {
+      "type": "http",
+      "url": "https://docs.emdashcms.com/mcp"
+    }
+  }
+}

package/templates/emdash/AGENTS.md

@@ -0,0 +1,50 @@
+This is an EmDash CMS website (Astro SSR on Cloudflare Workers, D1 + R2)
+styled by the Vitops design system.
+
+## Ground rules
+
+- `design-system.json` is the single source of truth for the design system
+  (colors, type, spacing, patterns, animations). Never edit
+  `src/styles/tailwind.css` — it is generated from the JSON by the
+  `getvitops()` integration on every dev/build and is gitignored.
+- Content lives in the EmDash database, not in the repo. Query it with
+  `getEmDashCollection` / `getEmDashEntry` from `emdash`; render Portable Text
+  with `<PortableText />` from `emdash/ui` (the Vitops blocks from
+  `@getvitops/emdash` are merged in automatically).
+- `seed/seed.json` only applies against an empty database: structure
+  (collections, menus, settings) on first boot; the `content` entries only
+  when the setup wizard's "include sample content" option is chosen. Changing
+  the seed does not migrate an existing site — use the admin
+  (`/_emdash/admin`) or the site's MCP server (`/_emdash/api/mcp`) to change
+  the content model of a running site.
+- Prefer framework CSS classes (utilities, patterns, type roles like
+  `font-heading`) over bespoke CSS. Run `npx vitops agents` to append the
+  full generated class-vocabulary reference to this file.
+- The Worker cron trigger in `wrangler.jsonc` drives scheduled publishing —
+  don't remove it.
+
+## Branch model
+
+- Work on **`dev`** (the integration branch). Every push auto-deploys the
+  isolated `-dev` worker (own D1/R2; `dev.<domain>` with a custom domain).
+- **`main`** is production and branch-protected — never push or merge to it
+  directly. Production ships only via the manual **promote** flow: the
+  `promote` skill (`.agents/skills/promote/SKILL.md`) dispatches
+  `.github/workflows/promote.yml`, which opens a `dev → main` PR with
+  auto-merge; merging deploys prod. Only run it when the user explicitly asks
+  to promote/ship to production.
+- Sample legal pages (`/terms`, `/privacy`) ship as seeded placeholder content
+  — remind the user to replace them before launch.
+
+## Docs MCP servers
+
+`.mcp.json` preconfigures the Astro docs and EmDash docs MCP servers — prefer
+searching them over pre-trained knowledge for Astro/EmDash questions.
+
+## Commands
+
+- `pnpm dev` — local dev with local D1/R2 emulation (no Cloudflare account)
+- `pnpm typecheck` — `astro check`
+- `pnpm deploy` — build + `wrangler deploy` prod (provisions D1/R2 on first run)
+- `pnpm deploy:dev` — build + deploy the isolated dev worker (needs `DEV_D1_ID`)
+- `npx vitops validate design-system.json` — schema-check the design config

package/templates/emdash/README.md

@@ -0,0 +1,136 @@
+# My EmDash Site
+
+An [EmDash CMS](https://docs.emdashcms.com) website on Cloudflare Workers,
+styled by the [Vitops design system](https://www.npmjs.com/org/getvitops).
+
+Scaffolded from `vp create @getvitops:emdash`.
+
+## Stack
+
+- **Astro** (SSR) on **Cloudflare Workers** — D1 database, R2 media storage
+- **EmDash** — the admin lives at `/_emdash/admin`; content is queried with
+  `getEmDashCollection` / `getEmDashEntry` (Astro live content collections)
+- **`@getvitops/astro`** — generates the design-system CSS from
+  `design-system.json` (Tailwind v4 format), generates favicons/PWA assets
+  from `src/assets/logo.svg`, and serves the web-component runtime
+- **`@getvitops/emdash`** — design-system Portable Text blocks in the editor
+  slash menu: image compare, copy snippet, banner, disclosure, carousel
+
+## Local development
+
+```bash
+pnpm install
+pnpm dev
+```
+
+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`
+collection, a `primary` menu, and the site settings.
+
+- Site: <http://localhost:4321>
+- Admin: <http://localhost:4321/_emdash/admin>
+
+Open the admin and complete the setup wizard — it creates your first account,
+and choosing to **include sample content** publishes the starter pages from
+the seed: home, about, terms (`/terms`), and privacy policy (`/privacy`).
+Until then the home route shows a friendly empty state. Unknown paths render
+`src/pages/404.astro`.
+
+## Deploy
+
+```bash
+npx wrangler login
+pnpm deploy
+```
+
+Wrangler provisions the D1 database and R2 bucket named in `wrangler.jsonc`
+on the first deploy; EmDash migrates + applies the seed structure on first
+boot (sample content again comes from the setup wizard). Later deploys leave
+existing content alone. The cron trigger in `wrangler.jsonc` drives
+scheduled publishing — don't remove it. For a custom domain, uncomment the
+`routes` block in `wrangler.jsonc` and set your apex.
+
+## Environments: dev → main promotion
+
+The repo ships a two-environment flow modeled on branch = environment:
+
+- **`dev`** is the integration branch. Every push auto-deploys the isolated
+  `-dev` worker (`.github/workflows/deploy-dev.yml`) — its own D1 database and
+  R2 bucket, served at `dev.<domain>` when a custom domain is configured (or
+  the worker's `workers.dev` URL otherwise).
+- **`main`** is production. Every push auto-deploys the prod worker
+  (`.github/workflows/deploy-prod.yml`).
+- **Promotion is manual**: run the **"Promote dev → main"** workflow
+  (`.github/workflows/promote.yml`) — or ask your AI agent to run the
+  `promote` skill (`.agents/skills/promote/`) — and it opens a PR from `dev`
+  into `main` with auto-merge enabled. With required reviews on `main`, a
+  human approves the PR; merging deploys prod.
+
+One-time setup:
+
+1. Create the branches: `git branch dev && git push -u origin main dev`, and
+   make `dev` the default working branch. Branch-protect `main` (require the
+   promotion PR + review).
+2. Create the isolated dev resources:
+   `wrangler d1 create my-emdash-site-dev` and
+   `wrangler r2 bucket create my-emdash-site-media-dev`.
+3. Add repo secrets: `CLOUDFLARE_API_TOKEN`, `CLOUDFLARE_ACCOUNT_ID`, and
+   `DEV_D1_ID` (the id printed by `d1 create`). Optionally `PROMOTE_TOKEN`
+   (a PAT allowed to bypass protection) for hands-off promotion.
+
+`pnpm deploy:dev` reproduces the dev deploy locally: it rewrites the
+adapter-generated wrangler config (`scripts/build-dev-wrangler.mjs`) so the
+dev worker never touches prod data — it hard-fails without `DEV_D1_ID`,
+on purpose. Schema/content changes live in the EmDash database, not git, so
+promote them separately (via the prod admin or its MCP server).
+
+## AI tooling
+
+- **MCP servers** (`.mcp.json`): the Astro docs (`mcp.docs.astro.build`) and
+  EmDash docs (`docs.emdashcms.com/mcp`) servers are preconfigured, so coding
+  agents answer from current documentation. Your running site also exposes its
+  own content MCP server at `/_emdash/api/mcp` (authenticated).
+- **Skills** (`.agents/skills/`): `promote` dispatches the dev → main
+  promotion workflow. Run `npx vitops agents` to also write the design-system
+  class reference into `AGENTS.md`.
+- **Claude Code on the web**: the SessionStart hook
+  (`.claude/hooks/session-start.sh`) installs Node 24 (matching
+  `devEngines`), activates the pinned pnpm, and installs dependencies in the
+  remote container automatically. Point the remote environment at the `dev`
+  branch so pushes land on the auto-deployed review site.
+
+## The design system
+
+`design-system.json` is the single source of truth for colors, type, spacing,
+shadows, patterns, and animations. The `getvitops()` integration regenerates
+`src/styles/tailwind.css` from it on dev/build (the file is gitignored — edit
+the JSON, not the CSS). `Layout.astro` imports the stylesheet so the admin
+routes stay unstyled by it.
+
+Useful commands (via `@getvitops/cli`):
+
+```bash
+npx vitops validate design-system.json   # check the config against the schema
+npx vitops agents                        # write the design-system reference into AGENTS.md
+pnpm build:css                           # regenerate the CSS manually
+```
+
+## Project map
+
+| Path                             | Purpose                                                           |
+| -------------------------------- | ----------------------------------------------------------------- |
+| `design-system.json`             | Design tokens + patterns → generated CSS                          |
+| `seed/seed.json`                 | First-boot content model + starter content                        |
+| `src/worker.ts`                  | Worker entry (fetch + EmDash scheduled handler)                   |
+| `src/live.config.ts`             | Astro live content collections wiring for EmDash                  |
+| `src/layouts/Layout.astro`       | Site chrome: EmDash + Vitops head tags, nav from the CMS menu     |
+| `src/pages/index.astro`          | Home — renders the `home` page entry                              |
+| `src/pages/[...slug].astro`      | Catch-all — renders any `pages` entry at its slug                 |
+| `src/pages/404.astro`            | Not-found page (the catch-all rewrites here)                      |
+| `wrangler.jsonc`                 | Cloudflare bindings (D1/R2) + cron trigger                        |
+| `scripts/build-dev-wrangler.mjs` | Rewrites the built wrangler config for the isolated dev worker    |
+| `.github/workflows/`             | deploy-dev (push to `dev`), deploy-prod (push to `main`), promote |
+| `.agents/skills/promote/`        | Agent skill: dispatch the dev → main promotion                    |
+| `.mcp.json`                      | Astro + EmDash docs MCP servers for coding agents                 |
+| `.claude/hooks/`                 | Claude Code web: Node 24 + pnpm setup on session start            |

package/templates/emdash/_gitignore

@@ -0,0 +1,25 @@
+# build output
+dist/
+
+# dependencies
+node_modules/
+
+# generated types
+.astro/
+emdash-env.d.ts
+worker-configuration.d.ts
+
+# wrangler local state (local D1/R2 data lives here during `astro dev`)
+.wrangler/
+
+# generated by the getvitops() integration on dev/build
+src/styles/
+public/vitops/
+
+# environment
+.env
+.env.*
+!.env.example
+
+# os / editor
+.DS_Store

package/templates/emdash/astro.config.mjs

@@ -0,0 +1,41 @@
+import cloudflare from '@astrojs/cloudflare';
+import react from '@astrojs/react';
+import { d1, r2 } from '@emdash-cms/cloudflare';
+import getvitops from '@getvitops/astro';
+import { vitopsEmdash } from '@getvitops/emdash';
+import { defineConfig } from 'astro/config';
+import emdash from 'emdash/astro';
+
+export default defineConfig({
+  output: 'server',
+  adapter: cloudflare(),
+  image: {
+    layout: 'constrained',
+    responsiveStyles: true,
+  },
+  integrations: [
+    // The EmDash admin UI (/_emdash/admin) is a React app.
+    react(),
+    emdash({
+      database: d1({ binding: 'DB', session: 'auto' }),
+      storage: r2({ binding: 'MEDIA' }),
+      // Vitops design-system blocks (image compare, copy snippet, banner,
+      // 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()],
+    }),
+    getvitops({
+      favicon: {
+        source: 'src/assets/logo.svg',
+        name: 'My EmDash Site',
+        themeColor: '#2e9b73',
+        backgroundColor: '#ffffff',
+      },
+      // inject: false — Layout.astro imports the generated stylesheet, so
+      // EmDash's /_emdash/admin routes don't inherit the design system while
+      // your pages (and EmDash previews rendered through the layout) do.
+      css: { format: 'tailwind', inject: false },
+    }),
+  ],
+});