How a change reaches the live site

The path of a change

Since 1 October 2026 (decision 0064) every change is seen on a private copy before guests see it.

1. Staging. A change is committed to the GitHub repository brarob100/amapas353.com and pushed to its staging branch. Workers Builds, Cloudflare’s builder connected to the repository, runs npm run build in site/ and deploys the result as the Worker amapas353-site-staging, at staging.amapas353.com.
   • Staging is behind Cloudflare Access on every page, not only admin, so only the owners can open it.
   • It has its own database and photo bucket.
   • Its emails go only to the owners, marked [STAGING].
   • It takes Stripe test cards only, and never writes to Lodgify.
2. Publish. When staging looks right, an owner opens Admin → Publish on the live admin.
   • The screen lists the changes staging has that the live site does not, and whether the automatic tests passed on them.
   • Publish to amapas353.com moves the main branch to staging’s exact commit, through GitHub, forward only, never forced.
   • Workers Builds then deploys main as the Worker amapas353-site.
3. Live. Within a couple of minutes the new build answers on amapas353.com. Its short commit id appears as build in /api/health; the Publish screen watches it and says Live ✓.

A failed build leaves the last good version live, so a mistake costs a red build, not a broken site. A version can also be rolled back in Cloudflare (RUNBOOK §4). The two mail Workers deploy from main, each from its own folder (site/mail, site/dmarc) with its own Workers Builds project.

Copy from the live site (staging’s Overview) brings the live words, settings, rates, FAQ, email wording and photo list into staging, so a change is seen with the real content. Bookings, guests and messages are never copied. Staging shows the live photographs by reading them from the live site.

How search engines hear of a change

Since 14 October 2026 (decision 0077) the site tells Bing which public page changed, instead of waiting for its next crawl.

1. The Worker’s scheduled handler, the one that already runs every minute, renders the seven pages in the sitemap in-process every ten minutes, exactly as a crawler would receive them.
2. It hands them to the site’s /api/cron/indexnow route, which hashes each page with Astro’s per-build asset names stripped, so a restyle does not count as a change to every page.
3. The hashes are compared with the ones kept in the settings table. Only the pages whose hash is new or changed, or which left the sitemap, are sent to Bing’s URL Submission API, with the owner’s Bing Webmaster Tools key (a secret on the live Worker). The IndexNow endpoints were the first design, but both answer “too many requests” to the shared addresses Cloudflare Workers send from; without the key they are still tried, and the admin card says the key is missing.
4. The hashes are remembered only once Bing accepted the send. So the first check announces every page, and a refused send is tried again at the next check, or an hour later after a “too many requests”.

The IndexNow key file at /<key>.txt stays served (it is public by design; IndexNow verifies a site by fetching it). Staging never sends, because its address is private. Admin → Publish → Search engines shows the sender, the key file, the switch, the last check, the last send with Bing’s answer, and Announce every page. Google takes no such message; its sitemap report in Search Console is the measure there.

What lives where in the repository

Folder or file	What it holds
site/src/pages/	Every page and /api route, one file each
site/src/lib/	The logic: pricing and quotes, Lodgify, Stripe, email, screening, the Launch Book
site/src/emails/	The email templates’ structure; their words live in D1
site/schema.sql	The database’s tables; the site creates them on first run
site/wrangler.jsonc	The Worker’s configuration: its addresses, the cron, plain values, database and storage bindings; env.staging is staging’s (0064)
site/src/lib/stage.ts	Everything staging may never do — email a guest, take a real card, write to Lodgify — and the copy from the live site
site/worker.mjs, site/www.mjs	The Worker’s entry: the cron handler and every 301 (http → https, www → the apex, the old Lodgify addresses)
site/tests/	The site’s automated tests
site/public/_spec/	The design book, read only inside admin at /admin/design-spec/ (decision 0061)
src/amapas_pricing/	The pricing agent (Python)
docs/decisions/	One numbered record per decision, with the alternatives rejected
docs/RUNBOOK.md	Every dashboard step, as walked, dated
docs/ARCHITECTURE.md	The shape of the system in one page
docs/guides-site/	The owners’ User Guide, shown inside admin
docs/guides-stack/	This guide

The checks before a push

A change is pushed only after these pass, run in site/:

1. npx vitest run — the automated tests (pricing, quotes, redirects, email, screening, Lodgify, Stripe and more).
2. npx astro check — types across every page.
3. npm run build — the same build Workers Builds will run.

A change a person would notice — a screen, a button, what an email says — updates the matching page of the User Guide in the same commit. A change to the stack — a service, an address, where data comes from — updates docs/ARCHITECTURE.md, the diagrams and a decision record in the same commit too (the repository’s CLAUDE.md, rule 8).

Settings that are not code

Most of what the owners change never needs a push: prices, seasons, fees, taxes, promo codes, the cancellation policy, email wording, photographs, the FAQ and reviews are rows in D1, edited on the admin screen that uses each one (there is no Settings screen, decision 0074) and recorded in the audit log. Dashboard settings — Access, DNS, Email Routing, the Worker’s secrets — are changed in Cloudflare, following the step recorded in docs/RUNBOOK.md.

Where the reasons are

Each decision that would be expensive to reverse has a record in docs/decisions/ — what was chosen, and why the obvious alternatives were not. They are append-only: a later change adds an addendum rather than rewriting history. docs/DEV_LIST.md holds the build order and the questions waiting on the owners.