# Happy Tails Astro pilot

This repository is a static Astro pilot for `3031023.xyz`. The existing
Cloudflare Pages site remains the rollback target while this branch is tested.

The planned preview-only editing experiment is documented in the [Decap CMS
Gitea pilot](docs/decap-cms-pilot.md). It does not authorize CMS activation, a
production merge, or a domain change.

## Repository layout

- `sites/www/` is the primary-site content location; it serves `3031023.xyz`.
- `sites/blog/` is the separate `blog.3031023.xyz` sample site.
- `sites.json` is the operator-controlled manifest. It is not public intake.
- `src/` contains shared Astro presentation code.
- `schemas/` and `fixtures/` provide the Phase 1 JSON contract proof.

Blog posts and primary-site FAQs are now static Markdown collections with
validated frontmatter and draft filtering. Production CMS publishing, public
sign-up changes, n8n changes, and onboarding-worker changes remain out of
scope; the linked Decap plan is a preview-only editing experiment.

## Local checks

Use Node 22.12 or newer within the Node 22 release line.

```bash
npm ci
npm run verify:cms
SITE_KEY=www npm run build:site
SITE_KEY=www npm run verify:build
SITE_KEY=blog npm run build:site
SITE_KEY=blog npm run verify:build
```

Each selected site builds to `dist/<site-key>/`. The Worker configurations use
only static assets and a custom 404 page. They contain no custom domains,
routes, account IDs, or secrets.

`npm run verify:cms` checks the fixed Gitea branch/backend, the four Markdown
content contracts, the fixed page-image record, the bounded raster-media boundary, the pinned admin
shell, and the stable secret-free pull-request status context. The live steps
remain unapplied; see the [Gitea pilot settings](docs/decap-cms-gitea-setup.md)
for the exact review checklist.

## Preview deployment

The Gitea workflows upload scoped non-production preview versions of the
production Workers from every non-`main` branch. Cloudflare assigns each branch
a readable `workers.dev` preview alias without changing production traffic.
Relevant primary-site pushes to `main` deploy `3031023-xyz-www`, and relevant
blog pushes to `main` deploy `3031023-xyz-blog`, automatically. Both production
workflows deploy static assets only.
It uses the existing `CF_API_TOKEN` and `CF_ACCOUNT_ID`. The token retains the
Pages permissions needed for the `main` rollback target and now also permits
the non-production Worker preview deployment.
Routine jobs do not configure DNS or custom domains.

Production hostname attachment and the `www` redirect are manual,
operator-controlled cutover steps. See `docs/pilot-baseline.md` for the
rollback record.