@topy-ai/maggie 0.7.46 → 0.7.48

package/bundled-contracts/maggiedash/stripe-booking-capabilities-v1.json

@@ -30,6 +30,7 @@
   ],
   "x-webhook-events": [
     { "eventType": "checkout.session.completed", "requiredFor": "hosted checkout completion", "officialDocs": ["https://docs.stripe.com/api/events/types"] },
+    { "eventType": "checkout.session.expired", "requiredFor": "release an unpaid pending booking when its hosted Checkout expires", "officialDocs": ["https://docs.stripe.com/api/events/types"] },
     { "eventType": "checkout.session.async_payment_succeeded", "requiredFor": "delayed payment completion", "officialDocs": ["https://docs.stripe.com/api/events/types"] },
     { "eventType": "checkout.session.async_payment_failed", "requiredFor": "delayed payment failure", "officialDocs": ["https://docs.stripe.com/api/events/types"] },
     { "eventType": "payment_intent.processing", "requiredFor": "payment pending", "officialDocs": ["https://docs.stripe.com/api/events/types"] },

package/bundled-marketplace/README.md

@@ -15,3 +15,20 @@ complete:
 
 - Template: `medical-spa-landing-001`
 - Region: United Kingdom
+
+## Package quality
+
+Every entry carries a neutral `displayName`/`displayDescription` for
+customer-facing pickers, measured `designTokens`, a `screenshotReview`, and a
+`generated-asset-manifest.json` that lists every file under `assets/` with its
+provenance. Run the read-only gate with:
+
+```bash
+python3 tools/clis/maggie_marketplace.py audit-package <template-id>
+```
+
+Current known gaps (2026-10-10): `medical-spa-landing-001` screenshots are
+corrupt (PNG CRC failures) and must be recaptured; captured source images in
+`reflexolog-spa-7-001`, `stillpoint2-001`, and `thai-massage-49-001` are listed
+as `captured-source` with `reuse: false` and must be replaced before
+publishing; no entry has a recorded generated-image text review yet.

package/bundled-marketplace/catalog.json

@@ -1,10 +1,12 @@
 {
   "version": "1.0",
-  "updatedAt": "2026-09-03T09:37:16.124426+00:00",
+  "updatedAt": "2026-10-10T01:45:35.149462+00:00",
   "templates": [
     {
       "id": "atma-wellness-15-001",
       "name": "Atma Wellness 15 001",
+      "displayName": "Sandstone Retreat",
+      "displayDescription": "A warm stone-toned wellness homepage with khaki accents and calm, airy sections.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -41,6 +43,8 @@
     {
       "id": "beauty-studio-20-001",
       "name": "Beauty Studio 20 001",
+      "displayName": "Olive Atelier",
+      "displayDescription": "A light editorial beauty homepage with Cormorant Garamond display type and olive accents.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -50,7 +54,11 @@
         "homepage",
         "landing-page"
       ],
-      "styleTags": [],
+      "styleTags": [
+        "light-canvas",
+        "serif-display",
+        "warm-neutral"
+      ],
       "source": {
         "provider": "internal",
         "templateUrl": "https://www.aura.build/templates/beauty-studio-20",
@@ -71,6 +79,8 @@
     {
       "id": "gold-pearl-resort-oyugis-k-001",
       "name": "Gold Pearl Resort Oyugis K 001",
+      "displayName": "Monochrome Resort",
+      "displayDescription": "A crisp black-and-white resort homepage with Playfair Display headings and photo-led sections.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -107,6 +117,8 @@
     {
       "id": "korean-head-spa-52-001",
       "name": "Korean Head Spa 52 001",
+      "displayName": "Cocoa Ivory",
+      "displayDescription": "A soft ivory spa homepage with deep cocoa text, a dark hero and generous whitespace.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -116,7 +128,11 @@
         "homepage",
         "landing-page"
       ],
-      "styleTags": [],
+      "styleTags": [
+        "light-canvas",
+        "sans-display",
+        "neutral"
+      ],
       "source": {
         "provider": "internal",
         "templateUrl": "https://www.aura.build/templates/korean-head-spa-52",
@@ -137,6 +153,8 @@
     {
       "id": "lillies-spa-beauty-salon-001",
       "name": "Maggie Studio Beauty Salon 001",
+      "displayName": "Midnight Slate",
+      "displayDescription": "A dark slate beauty homepage with Cinzel capitals and a deep blue hero.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -173,6 +191,8 @@
     {
       "id": "luxury-medspa-27-001",
       "name": "Luxury Medspa 27 001",
+      "displayName": "Teal Clinic",
+      "displayDescription": "A clean clinical spa homepage with IBM Plex Sans type and teal accents.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -209,6 +229,8 @@
     {
       "id": "maggie-card-restoration-001",
       "name": "Maggie Studio Card Restoration",
+      "displayName": "Gilded Workshop",
+      "displayDescription": "An ivory and charcoal service homepage with gold accents and before-and-after showcases.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -246,6 +268,8 @@
     {
       "id": "medical-spa-landing-001",
       "name": "Medical Spa Landing 001",
+      "displayName": "Champagne Clinic",
+      "displayDescription": "A bright clinical landing page with charcoal type and champagne-gold accents.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -266,7 +290,8 @@
         "provider": "internal",
         "region": "United Kingdom",
         "capturedAt": "2026-08-29T02:12:25.279793+00:00",
-        "captureInput": "local-export"
+        "captureInput": "local-export",
+        "captureFile": "Medical Aesthetics & Wellness Landing Page Template.html"
       },
       "supports": {
         "blog": true,
@@ -280,6 +305,8 @@
     {
       "id": "reflexolog-spa-7-001",
       "name": "Reflexolog Spa 7 001",
+      "displayName": "Pebble Serenity",
+      "displayDescription": "A pale stone spa homepage with Playfair Display body copy and quiet neutral tones.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -289,7 +316,11 @@
         "homepage",
         "landing-page"
       ],
-      "styleTags": [],
+      "styleTags": [
+        "light-canvas",
+        "sans-display",
+        "neutral"
+      ],
       "source": {
         "provider": "internal",
         "templateUrl": "https://www.aura.build/templates/reflexolog-spa-7",
@@ -310,6 +341,8 @@
     {
       "id": "spa-wellness-1227-001",
       "name": "Spa Wellness 1227 001",
+      "displayName": "Warm Sand Spa",
+      "displayDescription": "A sand-toned spa homepage with Montserrat headings and soft clay accents.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -346,6 +379,8 @@
     {
       "id": "stillpoint2-001",
       "name": "Stillpoint2 001",
+      "displayName": "Gallery White",
+      "displayDescription": "A minimal white homepage with black type and large photographic panels.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -382,6 +417,8 @@
     {
       "id": "thai-massage-49-001",
       "name": "Thai Massage 49 001",
+      "displayName": "Gold Leaf Massage",
+      "displayDescription": "A light massage homepage with Lato type, dark brown text and gold accents.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -391,7 +428,11 @@
         "homepage",
         "landing-page"
       ],
-      "styleTags": [],
+      "styleTags": [
+        "light-canvas",
+        "sans-display",
+        "neutral"
+      ],
       "source": {
         "provider": "internal",
         "templateUrl": "https://www.aura.build/templates/thai-massage-49",
@@ -412,6 +453,8 @@
     {
       "id": "wellness-booking-72-001",
       "name": "Wellness Booking 72 001",
+      "displayName": "Fern Directory",
+      "displayDescription": "A cream wellness booking homepage with a search-led hero and fern-green accents.",
       "status": "draft",
       "framework": "astro",
       "industry": [
@@ -422,7 +465,11 @@
         "homepage",
         "landing-page"
       ],
-      "styleTags": [],
+      "styleTags": [
+        "light-canvas",
+        "sans-display",
+        "warm-neutral"
+      ],
       "source": {
         "provider": "internal",
         "templateUrl": "https://www.aura.build/templates/wellness-booking-72",
@@ -443,6 +490,8 @@
     {
       "id": "wellness-float-11-001",
       "name": "Wellness Float 11 001",
+      "displayName": "Still Water",
+      "displayDescription": "A near-white minimal wellness homepage with charcoal type and restrained detail.",
       "status": "draft",
       "framework": "astro",
       "industry": [

package/bundled-references/browser-inspection.md

@@ -75,3 +75,28 @@ appearance. For every stateful component capture state A and state B and
 record the trigger and transition. Keep screenshots and extracted data under
 the target's namespaced research root so multiple URLs cannot overwrite one
 another.
+
+## Network interception and write safety
+
+Any skill that drives a browser against a running app (QA, clone, design
+review) must assume the app may talk to a real API. A local development build
+is often configured with the production API base URL, so a click in local QA
+can change live accounts.
+
+- Do not rely on page-level stubs such as overriding `window.fetch` from the
+  console or an injected script. Bundled API clients usually capture `fetch`
+  at module load, use `XMLHttpRequest`, or run in a service worker, so the
+  override never sees their requests.
+- Intercept at the network layer instead: Playwright `page.route()` /
+  `context.route()`, Puppeteer request interception, or CDP `Fetch.enable`.
+  Deny by default every non-GET request to a production origin and let only
+  explicitly listed reads through.
+- Verify the interception before any write flow: trigger one harmless request
+  and confirm in the browser's network log that it was intercepted, not sent.
+- Without network-layer interception, run write flows only against a
+  non-production API, or after the user gives explicit consent naming the
+  account and the data that will change. Record a backup or restore path first.
+
+`maggie qa start --api-base URL --production-api URL` records the API target.
+Scenarios marked `"mutates": true` are blocked against a production API unless
+`--allow-production-writes` is given. See the `maggie-qa-workflow` skill.

package/bundled-references/maggiedash-booking/CURRENT-STATE.md

@@ -1,6 +1,6 @@
 # MaggieDash Booking current state and gaps
 
-Status: current snapshot, 2026-09-21
+Status: current snapshot, 2026-09-29
 
 This is the canonical status document for the Booking implementation. The
 append-only [`PROGRESS.md`](./PROGRESS.md) keeps historical counts and decisions
@@ -11,14 +11,39 @@ current contract.
 
 | Surface | Current state | Authoritative evidence |
 |---|---|---|
-| MaggieDash source | Package `0.2.9`, with host capability, site-structure, and treatment-group contracts; the working tree contains the current Booking release changes | `/home/balalior/Dev/MaggieDash/package.json`, `maggiedash.json`, `git status` |
+| MaggieDash source | Package `0.2.11`, with the current Booking source, ten-event email-template contract, unknown-template outbox hold, and voucher lifecycle contract | `/home/balalior/Dev/MaggieDash/package.json`, `contracts/booking-email-templates-v1.json` |
 | Manager host contract | 47 endpoint IDs, email/password session, server-side role/capability checks | `MaggieDash/contracts/booking-host-adapter-v1.json` |
+| Manager appointment time handling | Calendar, overview, booking list/detail, waitlist, and dated schedule rules display in venue time. Booking create/reschedule/waitlist conversion and shift/time-off/closure datetime inputs convert in the selected location zone; DST gaps reject, repeated times expose fold choices, and dated schedule intervals are ordered by UTC instant. Local regressions, ORA build, and source parity pass. | BK-141 in [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), venue-time and UI validators, ORA build |
+| Manager Booking route hydration and draft form | Bookings query/page/new state renders deterministically during SSR and applies URL state after mount; a shared URL-state helper normalizes malformed pages to page 1 and has canonical/ORA tests against the same implementation. The New booking form's dirty state is declared and passed through the modal guard; local Chrome verified the direct `?new=1` route, venue-zone Calendar, pristine open/close, dirty-draft confirm/keep/discard behavior, and `?page=abc` without a visible error. Local HTTP is supplemental only; authenticated HTTPS host evidence remains missing. | MaggieDash `booking/src/booking-url-state.mjs`, `scripts/validate-booking-url-state.mjs`, `scripts/validate-booking-ui.mjs`; ORA `_maggie/booking/booking-url-state.mjs`, `maggiedash/scripts/validate-booking-url-state.mjs`, UI mirror validator, ORA `.maggie/qa-runs/bk031-local-bookings-followup-2026-09-29/summary.json`; BK-031 local Chrome follow-up in [`PROGRESS.md`](./PROGRESS.md) |
+| Local staging cleanup safety | Staging entrypoints reject production URL aliases by normalized PostgreSQL target; count-only audit confirms zero synthetic rows while retaining the seeded house and Stripe test configuration. | ORA `scripts/booking-staging-safety.mjs`, `scripts/booking-staging-audit.mjs`; BK-030 remains `needs-evidence` for host operations proof |
 | Public customer contract | 11 endpoint IDs, separate noindex/no-store boundary and token policy | `MaggieDash/contracts/booking-customer-surface-v1.json` |
 | Booking access contract | 4 administrator-only access endpoints, staff/manager/finance roles and granular permissions | `MaggieDash/contracts/booking-access-v1.json` |
 | Resend template contract | 10 tenant-scoped events, allowlisted variables, preview/publish/rollback and server-only recipient/provider data | `MaggieDash/contracts/booking-email-templates-v1.json` |
-| Browser evidence contract | 15 manager routes × 3 viewports = 45 screens | `MaggieDash/contracts/booking-browser-evidence-v1.json` |
-| Execution board | 87 tasks: 84 `passed`, 3 `needs-evidence` (`BK-030`, `BK-031`, `BK-032`) | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json) |
-| Local regression | AI-CMO Python suite: 364 tests passed; MaggieDash `npm test`, ORA contract checks, and ORA Astro build passed | recorded in the current verification output and [`PROGRESS.md`](./PROGRESS.md) |
+| Browser evidence contract | v2 covers 17 manager routes × 3 viewports = 51 screens; every screen reports its final pathname and expected primary heading. Capture records HTTP responses >= 400 and network request failures without URL paths/query strings or raw console/exception text. Runtime/browser CLI errors preserve only allowlisted target codes or a generic capture code. CI uploads only browser evidence JSON and screenshots, excluding protected browser storage state. | `MaggieDash/contracts/booking-browser-evidence-v2.json`, `MaggieDash/scripts/booking-browser-evidence.mjs`, evidence workflow regressions |
+| Execution board | 125 tasks: 122 `passed` and 3 `needs-evidence` (`BK-030`, `BK-031`, `BK-032`) | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json) |
+| Read-only release gate | All 16 static source/contract checks pass. Runtime, authenticated HTTPS browser, and ops evidence are still missing for BK-030/031/032, so the release gate remains `blocked`. No migration, booking, payment, or deployment operation was performed. | `maggie booking release-gate --project /home/balalior/Dev/clients/orawellness.uk --board docs/maggiedash-booking/EXECUTION-BOARD.json` |
+| Ops evidence validation | The canonical JavaScript validator and both Python CLI copies require valid UTC timestamps ending in `Z`, nonblank identity labels, host environment allowlist compliance, and chronological backup/restore/report times. Non-object roots are rejected by direct validators; the CLI input loader reports a bounded `BOOKING_CHECK_FAILED`, and `release-gate` returns structured `blocked` output. Host alert delivery and recovery evidence are still pending. | `tools/clis/maggie_booking.py`, ORA `tools/clis/maggie_booking.py`, `tools/tests/test_maggie_booking.py` |
+| Worker freshness reporting | Successful PostgreSQL writes return the committed last-success timestamp. Generic adapter, Astro, and ORA workers feed that value into the current health report; generic adapter dry-runs report stale stored time, successful writes clear stale alerts, and structured errors retain the prior timestamp. | `backend/booking/postgres-worker-repository.mjs`, `backend/booking/run-booking-jobs.mjs`, host worker scripts, `scripts/validate-booking-health.mjs` |
+| Customer mutation authorization | BK-138 requires a valid `manage` token scoped to the target booking for cancel/reschedule, and validates purpose, expiry, revocation, and booking association before any idempotency replay. BK-139 brings the MaggieDash reference host into parity: checkout separates the 60-minute payment token from the 30-day manage token, and mutation replay validates manage authorization first. BK-140 synchronized those fixtures into ORA's manifest-projected source. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), canonical and ORA PostgreSQL customer-adapter validators, reference-host journey |
+| Package payment-return expiry | BK-140 keeps reference-host behavior aligned with PostgreSQL: package-return tokens require a finite future expiry before purchase lookup. The canonical/ORA fixture journey covers valid, revoked, expired, malformed-expiry, and unknown tokens. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), canonical and ORA reference-host validators |
+| Closed-gate customer page | BK-137 removes the raw query-token page exception. While closed, the Astro page renders only for one validated, unexpired, unrevoked booking payment/manage token or package purchase token; malformed, ambiguous, and unknown tokens fail closed. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), adapter and host route validators |
+| Closed-gate reschedule availability | BK-136 removes the raw query-token exception. When public booking is closed, the host only permits availability continuation after validating a bearer manage token; the adapter checks purpose, expiry, revocation, booking association, and lifecycle. The customer UI sends the token in `Authorization`, not the URL. Canonical and ORA validators cover forged/missing/wrong-purpose/expired/revoked/terminal tokens. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), gate, adapter, and UI validators |
+| Paid package fulfillment | BK-134 preserves fulfillment after a successful Checkout even if new sales were disabled. BK-135 retries idempotent settlement on duplicate webhook deliveries, marks package events processed only after fulfillment, and propagates failures so Stripe can retry. Canonical and ORA runtime/host checks cover both behaviors. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), runtime and host validators |
+| Async Checkout webhook reference | BK-133 normalizes supported `checkout.session.*` events with the PaymentIntent reference when present, so immediate refund operations do not receive a Checkout Session ID as `payment_intent`; the Session ID remains the fallback. Canonical and ORA runtime validators cover async success/failure. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), runtime validators |
+| Checkout Session lifecycle | BK-132 creates Checkout Sessions with a 31-minute expiry and reconciles `cs_` IDs via the Checkout API: open remains pending, paid succeeds and upgrades to the PaymentIntent reference, and expired becomes cancelled. This matches ORA source behavior; local validator evidence only. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), Stripe adapter validator |
+| Hosted customer Checkout flow | BK-131 carries hosted intent from public booking checkout through the payment repository into Stripe, where it selects Checkout Session. Validators cover each seam and hosted/non-hosted intent is part of idempotency identity. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), customer/payment/Stripe validators |
+| Reconciliation provider-reference persistence | BK-130 persists a refreshed `providerPaymentRef` returned by payment reconciliation for both payment attempts and package purchases, preserving existing values when the provider omits one. The PostgreSQL payment-adapter regression verifies the returned attempt carries the refreshed reference. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), payment-adapter validator |
+| Package-purchase repository seam | BK-129 routes manager purchase listing through the composed payment repository, outside the PostgreSQL core-only transaction callback; a service regression asserts routing and DTO redaction. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), Booking service validator |
+| ORA availability follow-up | BK-124 closes a source gap: persisted manager location closures now feed the same planner used by public availability and customer holds. Pure and PostgreSQL-adapter regressions cover overlap, exact edges, tenant/location scope, and date bounds. Local source evidence only; production remains unreconciled. | ORA `docs/booking-v27-tasks.md` and `maggiedash/backend/booking/host-availability.mjs` |
+| Dated staff shift follow-up | BK-125 applies dated staff shifts in public availability and hold revalidation as additional constraints on recurring venue/staff hours. Dates without shifts preserve the existing fallback. Pure and customer-adapter regressions plus the ORA build pass; production remains unreconciled. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), ORA Booking runtime |
+| Manager booking schedule follow-up | BK-126 is implemented in ORA and canonical MaggieDash. Direct manager creation and waitlist conversion use the shared planner; canonical tests, a fresh local-source install, and the PostgreSQL 16 disposable integration confirm the implementation and pre-write schedule guards. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), MaggieDash source and installer projection |
+| Reschedule schedule follow-up | BK-127 is implemented in ORA and canonical MaggieDash. Proposed segments are checked against configured schedules while excluding the booking's prior allocations; canonical tests, install projection, and PostgreSQL 16 disposable integration pass. | [`EXECUTION-BOARD.json`](./EXECUTION-BOARD.json), MaggieDash source and installer projection |
+| Local regression | MaggieDash `npm test` and all 439 AI-CMO Python tests passed; fresh CLI source install/inspect and installed worker validators passed; ORA customer/core/worker PostgreSQL staging integrations, six-job non-dispatch worker preview with versioned health output and error redaction, 234-file Astro check/build, and BK-116 tests passed. BK-030's disposable PostgreSQL 16 worker cycle asserts the accepted Resend `providerRef` persists to `maggiedash_booking_notifications.provider_ref`; a new local-only backup/restore rehearsal restored a synthetic confirmed booking and its location/service dependencies into an empty PostgreSQL 16 target, with all six monitored table counts matching (evidence in ORA local evidence folder). BK-128's new disposable PostgreSQL 16 worker cycle also confirms `checkout.session.expired` cancels the unpaid attempt and booking, processes the webhook, and releases its reserved allocation. BK-135's canonical and ORA runtime regressions verify duplicate package webhooks retry settlement and propagate failures. BK-136 canonical/ORA gate, customer-adapter, UI, host contract, `npm test`, and Astro check/build regressions prove raw query tokens cannot bypass the public exposure gate and valid reschedule authorization uses a bearer header. BK-137 canonical/ORA page-continuation adapter, route, and contract checks prove the closed-gate customer page validates a single booking or package token before rendering. BK-138 canonical/ORA customer-adapter regressions verify manage-purpose, expiry, revocation, and booking binding before cancel/reschedule idempotency replays. BK-139 aligns the canonical fixture host with separate 60-minute payment and 30-day manage tokens and validates purpose, expiry, revocation, and booking scope before mutation replays; the full MaggieDash suite passes. BK-140 adds expiry checks to package-return tokens in both reference-host copies; canonical and ORA customer journeys reject expired and malformed expiries while preserving valid pending returns. Canonical and ORA runtime/Stripe/contract checks and the 124-task board validator pass. The BK-126/127 core integration also passed all 23 checks on disposable PostgreSQL 16, including schedule-eligible manager creation and pre-write rejection of shift/closure/waitlist/reschedule cases. BK-030 now persists the last successful write cycle per tenant and supplies it to `worker.stale`; canonical and staging PostgreSQL integrations passed with the status table. The additive schema is applied to ORA staging; a fresh six-job preview passed healthy with zero alerts/no dispatch, and the real staging integration proved last-success persistence in an isolated tenant then verified its cleanup. The approved cleanup then removed all synthetic staging customers/bookings/holds/payment attempts/notifications/events and the temporary owner; staging now has zero owners and zero customer/booking/payment rows, with first-owner registration open. Stripe test connection was refreshed in Chrome and remains degraded (`charges_enabled=false`, `payouts_enabled=false`); the prior £128 test payment was refunded and four unpaid sessions expired. Production migration and host evidence remain open. | [`PROGRESS.md`](./PROGRESS.md), ORA `.maggie/evidence/booking-v27/local-postgres-backup-restore-2026-09-29.json`, staging cleanup, worker preview/integration evidence |
+| ORA Stripe test account identity | Read-only Chrome dashboard confirms the configured API account is `APHRODITE FASHION LIMITED sandbox` in Test mode; Stripe API reports charges and payouts disabled. The client has not confirmed it as ORA's intended test account. | [`PROGRESS.md`](./PROGRESS.md); ORA client questions at `clients/orawellness.uk/docs/client-questions-v27.md` in the workspace |
+| ORA production worker schedule | Read-only VPS systemd inspection confirms the one-minute Booking worker timer is enabled and its service runs with `--write --confirm`; the last observed process exit was successful. Local source now acquires the tenant lock before state reads and treats contention as a skipped warning cycle; this is unreleased and does not establish deployed behavior. It may dispatch queued notifications. Provider activity, alerts, and booking backup/recovery have not been verified. | [`PROGRESS.md`](./PROGRESS.md), ORA `.maggie/evidence/booking-v27/production-worker-schedule-readonly-2026-09-28.json` |
+| ORA local responsive manager QA | Local Chrome v2 route/heading/layout checks now pass 51/51 screens across 17 manager routes and three viewport overrides, with zero captured console errors and no horizontal document overflow. The browser control surface did not expose failed request events; screenshot bitmap dimensions vary by route and do not form canonical release captures. The temporary owner is removed, staging has zero owners and booking/customer/payment rows, and first-owner registration is open. This local run does not satisfy the HTTPS real-host 47-endpoint BK-031 gate. | [`PROGRESS.md`](./PROGRESS.md), ORA `.maggie/qa-runs/bk031-local-v2-2026-09-29/summary.json` |
+| ORA local staging Checkout | Verified the Stripe test connection in the authenticated manager UI; API acceptance passed 9/9; Chrome completed a £128 hosted test payment and rendered the confirmed customer return. No worker was running and no email was sent. This used the public hold/Checkout API to create the test session; the public date picker was not verified end-to-end in that pass. The payment has since been fully refunded, four unpaid sessions expired, and the synthetic staging records and temporary owner were removed. | [`PROGRESS.md`](./PROGRESS.md), ORA `.maggie/evidence/booking-v27/staging-cleanup-and-owner-qa-2026-09-29.json` |
+| Production manager browser spot check | A prior read-only Chrome observation showed the production Booking manager dashboard. The current Chrome control has no open tabs; no cookies, customer details, or API payloads were inspected. This historical spot check does not satisfy BK-031's dedicated tenant, 47 endpoint, or current 51-screen evidence requirements. | [`PROGRESS.md`](./PROGRESS.md) |
 
 ## What is implemented locally
 
@@ -39,20 +64,113 @@ current contract.
 - PostgreSQL repository seams, schema/preflight tooling, worker scheduling
   artifacts, reference-host validators, runtime/browser/ops evidence contracts,
   and the ai-cmo-skills installer/inspect/release gates.
+- Customer payment-return reconciliation now projects terminal provider state
+  onto the booking itself and re-reads it before returning the public response.
+  The ORA and generic Astro hosts queue idempotent confirmation or cancellation
+  notifications only for matching terminal provider/booking state. Repeated
+  return reads remain idempotent; queued notifications do not imply that a mail
+  worker has delivered the message.
+- A verified payment return hands the customer page its long-lived manage token;
+  the page replaces the short-lived return token in the URL for history,
+  cancellation, and rescheduling. Public DTOs expose allowlisted guest and
+  segment-pricing details, while ORA holds store only the suitability-cleared
+  marker. BK-115 source, staging, install, and build evidence is in
+  [`PROGRESS.md`](./PROGRESS.md).
+- The generic PostgreSQL customer adapter enforces variant
+  `metadata.rules.firstVisitOnly` and `standaloneOnly` server-side when creating
+  a hold, and rechecks first-visit eligibility before checkout conversion.
+  The core repository repeats that check in the booking transaction and
+  serializes conversions by tenant plus normalized email. Cancelled and expired
+  booking history does not consume the first-visit offer.
+- Generic per-person pricing is now in the MaggieDash source candidate.
+  Variants can declare `metadata.pricing` with a mode and guest limits; the
+  public catalogue exposes only those safe fields, the customer page collects
+  party size and estimates totals, and PostgreSQL recalculates prices from
+  catalogue unit prices during hold creation and booking conversion. Booking
+  and segment metadata retain guest counts and unit prices. The current local
+  source manifest install passes byte parity; registry release parity remains
+  open.
+- Generic suitability gating is now in the MaggieDash source candidate.
+  Variants may require a yes/no answer and expose bounded question/contact
+  copy. The customer adapter and core hold/conversion path refuse a positive
+  answer and require a negative answer. Holds persist only a passed-check
+  marker, not the health answer. Full local validators and the isolated ORA
+  staging PostgreSQL integration passed; current local source install parity
+  passed, while registry release parity remains open.
+- The PostgreSQL core now auto-assigns public holds to a mapped free staff
+  member/resource when the request does not name one. Candidate selection
+  excludes overlapping reserved allocations plus variant buffers and locks
+  the chosen row inside the hold transaction. ORA staging integration with
+  two staff/resources verified fallback to the second free pair; current local
+  source install parity passed, while registry release parity remains open.
+- Public exposure now has a provider-neutral host policy module. A host supplies
+  location/catalogue/capacity/schedule/live-payment readiness, while the shared
+  gate handles test overrides, short caching, fail-closed behavior, and the
+  classification of new-booking routes versus customer continuations. The Astro
+  scaffold gates its customer page and public API boundary. The ai-cmo-skills
+  CLI installed the current checkout into a disposable Astro project with
+  byte-for-byte parity across all 202 manifest-projected admin, runtime,
+  workspace, and Astro host files; its installed gate validator passed. Gate
+  tests directly verify deny/allow behavior for new-booking routes, preserve
+  continuation access, and fail closed on readiness errors. Published release
+  and production-host parity remain pending.
+- ORA's local public availability adapter now uses the same host schedule
+  planner as customer holds, including location hours, staff/resource capacity,
+  and the online-booking service flag. Its focused adapter regression, ORA
+  availability/rules suites, public-route gate, contract check, and 233-file
+  build passed. A read-only staging API recheck returned assessment starts
+  17:45–20:15 local, ending by 20:50 before the 21:00 close. The production
+  browser finding remains unresolved on the live host; this host-specific
+  correction is not deployment evidence.
+- The manager Overview now shows the host-provided Stripe API, webhook, charges,
+  and payouts checks. When the account is reachable but `charges_enabled` is
+  false, the setup checklist explains that it cannot accept payments and keeps
+  the connection degraded. Check labels/status values are allowlisted and
+  provider secrets are never copied into the UI summary.
+- Stripe `onlinePayment` is now derived from a verified credential plus
+  `charges_enabled=true`; first-run bootstrap no longer treats credential
+  presence as payment readiness. Off-session charges follow the same gate, and
+  the generic Astro host and ORA mirror use the same tested helper.
+- The PostgreSQL manager repository also requires the stored capability to be
+  explicitly `true` before Overview or payment-health reports online payments
+  enabled. Missing settings and explicit `false` both remain disabled in
+  MaggieDash and ORA regression coverage.
+- Worker PostgreSQL state reads now run sequentially on the injected host
+  client, avoiding concurrent `client.query()` calls. Runtime preview mode
+  reports queued notifications as `previewed` and never calls the external
+  notification dispatcher; both behaviors have MaggieDash and ORA regressions.
+- The shared provider-neutral payment starter and reference host now follow the
+  same strict boolean rule. Missing values and truthy strings/numbers cannot
+  report payment readiness or start a payment.
+- The generic Stripe adapter defaults payment, refunds, off-session charges,
+  and webhook verification to disabled. The Astro host enables these gateway
+  flags only when the active secret fingerprint and configured account scope
+  match the verified payment-account record and its stored capability is true.
+  Missing verification data, secret rotation, and account mismatch fail closed.
+- The latest `maggiedash.json` source manifest was installed through the
+  canonical ai-cmo-skills CLI into a blank disposable Astro project. All 207
+  projected files matched byte-for-byte; CLI inspect and the installed payment
+  gateway, reference-host, and PostgreSQL core validators passed. This proves
+  local source install parity, not registry-published or production-host parity.
 
 “Implemented locally” means source, contract, fixture, and local/reference-host
 evidence exist. It does not mean a production tenant has been migrated or that
 provider delivery has been proven on the live host.
 
+The confirmed-booking template also allows the host-provided `arrivalNote`
+variable; the fallback renderer escapes it before inserting it into HTML.
+
 ## Open gaps
 
 | Priority | Gap | Current evidence | Exit evidence |
 |---|---|---|---|
-| P0 | ORA Booking schema and access tables are not installed in the configured database | Read-only schema check reported `needs-migration`; core exists, Booking/access tables do not | Owner-approved backup/restore rehearsal, then `node scripts/maggie-booking-schema.mjs --apply --confirm` and a post-migration check |
-| P0 | Stripe test account is not fully verified for Booking | ORA `.env` has the existing `ST_SECRECT_KEY` test secret alias and `ST_PUB_KEY`; `STRIPE_WEBHOOK_SECRET` is absent | Add webhook signing secret, run the authenticated **Verify Stripe connection** action, and capture signed success/failure/delayed/duplicate/refund/no-show test evidence |
-| P0 | Worker and alerting are not enabled on the real host | systemd/cron artifacts are generated, but no host schedule, lock, alert route, or recovery evidence has been supplied | Enable one scheduler, run a disposable/staging worker cycle, prove lock/retry/dead-letter/recovery alerts, and retain sanitized ops evidence |
-| P0 | Real-host runtime and browser conformance is missing | Reference-host, fixture, and local build evidence pass; no authenticated HTTPS runtime/browser artifact exists | Run all 47 manager endpoints and all 45 browser screens against a dedicated staging/test tenant, then pass `release-gate --require-runtime --require-browser --require-ops` |
-| P1 | Published npm package is behind the current Booking contracts | Local AI-CMO package source is `0.7.40`; publish and registry readback are the remaining release actions | Verify the installed public tarball, and rerun `maggie booking inspect` against ORA |
+| P0 | Production Booking schema and access tables are not verified | Explicit read-only check against `BOOKING_STAGING_DATABASE_URL` reports core, Booking, and access tables ready. `DATABASE_URL` is not clearly classified as staging or production, so that check is not treated as release evidence. | Confirm the approved production target and backup/restore plan, then run a target-bound check; apply schema only after explicit approval |
+| P0 | Reconcile live public Booking exposure and out-of-hours availability | Chrome still finds `/book` advertising online booking and Assessment starts 18:30–00:20, after the published 21:00 close. Read-only VPS inspection confirms the service is active but `src/lib/booking/online.ts` is absent; deployed route/adapter source hashes match committed `HEAD` while current working-tree hashes differ. The host has no `.git` or build-version marker, so the current revision remains unknown. The working tree now adds a SHA-256 build identity endpoint and deploy rollback check; production readback awaits an approved deploy. Current production-mode preview closes the updated source. No booking was submitted. | Reconcile the deployed source and production readiness, then close the exposure through the approved release process, verify `/api/build-info.json`, and recheck hours |
+| P0 | Review Resend activity after the staging worker preview incident | Two pre-fix staging previews each reported one provider-accepted notification without persisting outbox state; a duplicate submission is possible. The fixed preview now skips provider dispatch. | Review Resend activity and assess any duplicate before a worker `--write` run |
+| P0 | Stripe test-mode coverage and intended account confirmation remain open | Authenticated staging Booking setup retained API “reachable” and webhook “configured” after refresh, with charges and payouts disabled. Chrome completed a £128 Stripe test Checkout; Stripe readback recorded `livemode=false`, a succeeded £128 PaymentIntent, and a confirmed customer return. The test payment was fully refunded, four other unpaid sessions expired, and all synthetic app records were removed. This proves test-mode Checkout, not live payment readiness; the configured sandbox/account is still awaiting client confirmation. Signed webhook/reconciliation failure, duplicate, refund, and no-show cases are not complete host evidence. | Confirm that the sandbox is ORA’s intended test account; capture the remaining authenticated provider-event scenarios. Production remains disabled until the intended live account has verified live charges and passes the production readiness gate |
+| P0 | Production worker activity, alert routing, and recovery evidence need reconciliation | Read-only VPS inspection confirms a one-minute systemd timer is enabled and its service runs with `--write --confirm`; the last observed exit succeeded. Current local worker fixes are unreleased. Two earlier staging previews ran before the dry-run guard and each reported one provider-accepted notification without persisted outbox state, so a duplicate may exist. Alert delivery and backup/restore/recovery have not been verified. Sanitized summary: ORA `.maggie/evidence/booking-v27/worker-preview-side-effect-summary.json`. | Review Resend activity and assess any duplicate before changing or rerunning the worker; reconcile the deployed worker revision, then prove alert delivery, backup/restore, and recovery with sanitized host evidence |
+| P0 | Real-host runtime and browser conformance is missing | Local Chrome v2 checks cover all 51 paths/headings/layouts, but failed-request events were unavailable and screenshot dimensions vary; no authenticated HTTPS runtime or canonical v2 browser artifact exists. The ORA repository `.env` has no dedicated HTTPS staging base URL; its `PUBLIC_SITE_URL` is the production origin. Protected-workflow secrets were not inspected. Canonical MaggieDash and ORA root runtime/browser workflows now run the exact `BOOKING_TEST_HOST_ALLOWLIST` preflight before writing protected session/plan inputs and pass the allowlist into capture for a second check; direct capture commands enforce it independently. | Configure an exact test-host allowlist and provide a dedicated HTTPS test tenant, then run all 47 manager endpoints and all 51 route/viewport screens with route-specific path/headings and no console/request/layout/login-leak failures; pass `release-gate --require-runtime --require-browser --require-ops` |
+| P1 | Installed global CLI contains a stale Booking email-template contract | Source candidate `0.7.48` passes the exact-tarball ORA inspect gate; published/global `0.7.47` still reports nine events | Publish the reviewed candidate, verify registry/install contents, then rerun `maggie booking inspect` against ORA |
 | P1 | ORA staging data and legacy allocation backfill need approval | `maggie-booking-buffer-backfill.sql` is present but not applied; active locations/catalogue/staff/schedule/payment policy still need real data verification | Apply the reviewed additive/backfill migration in staging, seed a test location/catalogue/staff schedule, and prove readiness plus conflict behavior |
 | P1 | End-to-end Resend delivery is unproven | Outbox/worker code and validators pass, but invitation, reset, reminder, waitlist, package, refund, and no-show messages have not been observed in a staging mailbox | Capture redacted delivery, retry, dead-letter, replay, and duplicate-suppression evidence |
 | P1 | Release/canary ownership is incomplete | `BK-032` remains `needs-evidence`; no final release artifact or canary report is recorded | Produce the board-complete release report, rollback rehearsal, canary window, and feedback closure |