@topy-ai/maggie 0.7.38 → 0.7.41

package/bundled-references/maggiedash-booking/PROGRESS.md

@@ -0,0 +1,2434 @@
+# MaggieDash Booking progress log
+
+Task board coverage: BK-017 through BK-103. Current board state is 84 passed
+and 3 `needs-evidence` tasks (BK-030, BK-031, BK-032). The MaggieDash release
+baseline is version `0.2.8` at commit `9d99de7` on `origin/main`; this working
+tree also contains the uncommitted BK-099/BK-100 extensions and the disabled-
+account reset hardening. The
+remaining tasks are real-host evidence gates plus explicitly documented
+monetization follow-ups, not missing local booking primitives.
+
+This is an append-only historical ledger. Counts such as 44 routes, 9 email
+events, or 32 runtime observations in older entries describe the contract at
+that point in time. The current contract is 47 manager endpoints, 11 public
+customer endpoints, 10 email events, and 15 browser routes; see
+[`CURRENT-STATE.md`](./CURRENT-STATE.md) for the authoritative snapshot.
+
+## 2026-09-21 — BK-103 consented Stripe no-show fee charging
+
+- Completed the no-show flow as two deliberate steps: marking a booking
+  `no_show` still produces a review-only settlement, while a separate manager
+  or finance action can charge the policy-derived fee only after explicit
+  confirmation, customer consent, a saved provider payment method, and a
+  verified Stripe off-session capability.
+- Ordinary customer payments now use `PaymentIntent` with
+  `setup_future_usage=off_session` when the customer agrees to save a payment
+  method. Stripe payment/setup webhooks persist the provider customer and
+  payment-method references for future use; SetupIntent remains reserved for
+  setup-only flows.
+- Successful charges persist an `adjustment` payment attempt and audit/event
+  evidence, with stable idempotency. The generic Astro host and ORA mirror
+  queue `payment.no_show_fee` through the existing Resend outbox only after a
+  successful charge; pending or failed provider results remain visible for
+  manual handling.
+- Added the versioned 47-route manager contract, reference-host coverage,
+  installed CLI contract parity, and the customer consent checkbox. ORA's
+  local `ST_SECRECT_KEY` alias is accepted for the existing test account while
+  `STRIPE_SECRET_KEY` remains the documented canonical name.
+- Evidence: central Stripe/route/reference-host validators and `npm test`,
+  ORA `contract:check` and Astro check/build (193 files, 0
+  errors/warnings/hints), and whitespace validation. No production database
+  migration or live charge was performed.
+
+## 2026-09-21 — Protected Booking redirect compatibility
+
+- Fixed the generic Astro host and ORA login pages so middleware-rewritten
+  `/maggie/*` paths are normalized back to the public `/_maggie/*` path after
+  sign-in. This preserves the original destination when an unauthenticated
+  user opens Booking directly and still rejects external redirect targets.
+- Disposable ORA runtime evidence now covers first-owner registration, password
+  login, direct protected-route redirect, authenticated Booking overview and
+  Staff screens, and zero application console errors. Responsive captures at
+  375, 768, and 1280 pixels were also generated.
+- The only remaining browser caveat is Astro's development-toolbar warning
+  inside the intentionally sandboxed email-template preview iframe; it is a
+  dev-only injected script warning and is absent from the production build.
+
+## 2026-09-21 — Fail-closed first-run setup state
+
+- Generic Astro and ORA registration/login pages now catch missing Booking
+  tables and render a clear `Finish Booking setup` screen with the exact
+  `maggie booking install --confirm --bootstrap` next step instead of exposing
+  a database 500 during an incomplete install.
+- The state is covered by the generic Astro bootstrap validator, and both
+  MaggieDash `npm test` and the ORA `astro check`/`astro build` pass.
+- The login preflight now checks the core, Booking, and access tables even when
+  the visitor has no session cookie. A fresh install therefore reaches the same
+  setup-required state instead of showing a login form that can only fail.
+- The generic Booking page now enforces the same access boundary as its APIs:
+  owner/admin accounts pass directly, while staff/finance/manager accounts
+  need an active Booking role; a `staff` account also needs its staff profile
+  link. Ordinary Maggie dashboard editors and unlinked staff accounts receive
+  a bounded 403 instead of an error-filled Booking shell.
+
+## 2026-09-21 — Stripe readiness hardening
+
+- Env-key presence no longer claims a Stripe account is connected. Bootstrap
+  reports `pending` when both Stripe secrets exist and requires the manager's
+  server-side verification action before preserving `connected`.
+- Stripe verification now requires explicit `charges_enabled === true` and
+  `payouts_enabled === true`; missing or false fields produce `degraded`.
+- Deployment-managed provider credentials remain in the secret store. The
+  optional dashboard-managed Stripe path accepts values only from an
+  owner/manager over HTTPS, verifies them before storage, and persists only
+  authenticated ciphertext; raw values are never returned or sent to the
+  public browser bundle.
+- Central and ORA host validators/build checks passed after the change.
+
+## 2026-09-21 — Dashboard-managed Stripe connection
+
+- Closed the first-run gap where a business owner could only configure Stripe
+  outside Booking. The Overview setup panel now accepts a secret key and
+  webhook secret for owner/manager sessions and clears both fields after the
+  request.
+- The generic Astro host and ORA mirror validate the pair with Stripe before
+  writing it. Dashboard values are AES-256-GCM ciphertext keyed from
+  `BOOKING_TOKEN_SECRET`; deployment `STRIPE_SECRET_KEY` remains authoritative,
+  and staff/finance sessions cannot submit provider credentials.
+- Additive schema columns, host bootstrap markers, CLI setup guidance, and
+  integration docs were synchronized. MaggieDash npm tests, host/schema gates,
+  ORA contract/build, ai-cmo Booking tests, packaged inspect/setup, and task
+  validation passed. Production migration, live API verification, and worker
+  enablement remain explicit host evidence gates.
+
+## 2026-09-21 — ORA production database preflight
+
+- Ran `npm run booking:schema -- --dry-run` against the configured ORA
+  PostgreSQL connection. All four schema files, including host extensions,
+  executed inside a transaction and rolled back successfully; no production
+  rows or tables were changed.
+- Ran `npm run booking:schema -- --check` and the read-only worker preview. The
+  current database has the core MaggieDash tables but not
+  `maggiedash_booking_allocations` or `maggiedash_booking_user_roles`; both
+  commands correctly report `needs-migration` and the worker refuses to run.
+- The next production action is owner-approved backup/restore evidence followed
+  by `node scripts/maggie-booking-schema.mjs --apply --confirm`. Until that
+  happens, first-owner registration, Stripe connection, live calendar data,
+  and Resend booking delivery remain intentionally unavailable.
+
+## 2026-09-21 — Published CLI parity audit
+
+- The local source CLI and regenerated bundled CLI pass
+  `maggie booking inspect --project /home/balalior/Dev/clients/orawellness.uk`.
+- The currently published npm `@topy-ai/maggie@0.7.38` was tested separately and
+  still reports contract drift against the current ORA/MaggieDash surface: it
+  expects the old seven Booking email events and nine public customer
+  endpoints. This is a release artifact gap, not an ORA runtime failure.
+- The next release must regenerate `bundled-contracts`, `bundled-tools`, and
+  bundled skills from this source tree, then run the published-package install
+  and inspect regression before npm publication. The repository now has
+  `node scripts/validate-cli-package.mjs` and a CI package smoke gate for this
+  exact tarball check. Until that release is
+  published, users must use the local CLI/source or will receive the stale
+  0.7.38 contract validator.
+- The source package is now prepared as the `0.7.39` release candidate; it
+  still requires npm publication and a registry-based install/inspect
+  regression before external users receive the current Booking contracts.
+
+## 2026-09-21 — Self-contained Booking npm bundle
+
+- The package assembler now ships the Booking runbook and sanitized runtime
+  fixture under bundled references/contracts and rewrites repository-only
+  links for installed users.
+- `python3 scripts/validate_skills.py` now passes all 20 skills and bundled
+  Markdown links; the exact `0.7.39` tarball also passes Booking contract,
+  access, Resend-template, task-board, and ORA inspect checks.
+
+## 2026-09-21 — Astro middleware install compatibility
+
+- The Booking installer now merges its rewrite block into both conventional
+  Astro middleware signatures: a full `context` parameter and the common
+  destructured `({ url, request }, next)` parameter.
+- Unsupported custom middleware remains preserved and fail-closed. A
+  disposable Astro install with the starter's existing middleware now returns
+  `booking inspect: passed` instead of requiring manual integration.
+- Added an installer regression test for the destructured form; the MaggieDash
+  install and Booking CLI test suites passed.
+
+## 2026-09-21 — Dashboard Stripe connection path
+
+- Added an owner/manager-only Booking Overview form for hosts that do not use
+  a deployment secret store for Stripe. Both the API secret and webhook secret
+  are verified with Stripe before persistence.
+- Dashboard-managed credentials are sealed with AES-256-GCM using a key derived
+  from `BOOKING_TOKEN_SECRET`; only fingerprints and redacted status reach the
+  browser. Deployment-managed `STRIPE_SECRET_KEY` remains authoritative.
+- Updated the generic Astro host, ORA host mirror, install schema, Booking UI,
+  and Stripe integration documentation. Production migration and live Stripe
+  verification remain release evidence tasks.
+
+## 2026-09-21 — Customer contract parity
+
+- Fixed the ai-cmo-skills compact and bundled customer contracts to include the
+  two public package checkout/payment-return endpoints introduced in the
+  MaggieDash customer surface. The canonical count is now 11 everywhere.
+- `maggie booking inspect --project /home/balalior/Dev/clients/orawellness.uk`
+  now passes with no contract drift errors; Python Booking tests and board
+  validation also pass.
+- `maggie booking setup` now reports a complete Stripe key pair as
+  `online-payments-pending-verification` and prints the next step to run
+  **Verify Stripe connection** after signing in; it does not equate env-key
+  presence with a live provider connection.
+
+## Current snapshot — 2026-09-21
+
+- MaggieDash `main` and `origin/main` point to `9d99de7` (`fix: make booking
+  catalog runtime-safe`). The package and distribution manifest
+  report `0.2.8`.
+- The current source contains the separate `booking/src` workspace, manager
+and public customer contracts, 47-route reference host, PostgreSQL core and
+  worker seams, injected payment boundary, runtime/ops contracts, browser
+  evidence workflow, priority/FIFO waitlist matching, 24-hour reminder enqueue job, payment policies with
+  deposit/balance projection, manager customer history, complete schedule-rule
+  management, editable service/treatment catalogue management, editable
+  staff/resource management, editable schedule-rule management, and
+  installation mappings, live-configuration manager booking creation, and
+  multi-treatment manager appointments with per-segment allocations, public
+  multi-treatment customer holds and checkout, tenant-scoped notification
+inspection/dead-letter replay, tenant-scoped treatment package catalogue
+management, customer package entitlements, balance reads, expiry enforcement,
+and atomic manager-booking redemption. Public package checkout, token-bound
+payment return, Stripe webhook/reconciliation fulfillment, manager purchase
+listing, guarded package refunds, and cancellation-safe package-credit
+restoration are now implemented locally; real-host
+payment and migration evidence remains pending.
+- Public customer package redemption is now implemented: a confirmed package
+  return links to the public booking page, the hold binds the opaque
+  entitlement to the customer's email record, and checkout locks the
+  entitlement, redeems every matching treatment in the same booking
+  transaction, and confirms a fully covered booking without starting a payment.
+- BK-099 adds cancellation-safe package credit restoration. Manager and eligible
+  customer cancellations lock active redemption rows, decrement the matching
+  `quantity_redeemed` values, mark the ledger rows `reversed`, restore an
+  exhausted entitlement to `active` when it has not expired, and append the
+  reversal result to the booking event. Completed and no-show visits remain
+  consumed. Central reference-host manager/customer regressions passed.
+- The installer now generates a reviewed single-flight worker schedule with
+  `maggie booking install --schedule systemd` or
+  `maggie booking worker-schedule --scheduler cron`; it writes deployment
+  artifacts only and never enables a service, edits crontab, starts a worker,
+  or exposes secrets.
+- Treatment preparation and cleanup buffers are now operational rules rather
+  than catalogue-only metadata. Availability, holds, manager bookings,
+  customer bookings, rescheduling, multi-treatment segment timing, and reference
+  hosts use expanded occupied ranges; new PostgreSQL allocations persist those
+  ranges and carry `buffer_version = 1`.
+- Cancellation/refund policy is normalized in catalogue configuration,
+  snapshotted on manager/customer/waitlist-created bookings, exposed in the
+  installed catalogue UI, and enforced at the customer cancellation cutoff.
+  Allowed cancellations now calculate a policy-safe refund settlement and call
+  the injected provider after the lifecycle write. Accepted or pending refunds
+  queue the existing Resend `payment.refunded` outbox notification; provider
+  outages return `manual_required` without claiming success. No-show fees are
+  calculated and now return a manager-facing `review_required` settlement;
+  automatic off-session charging remains a separate provider-consent task.
+- Calendar Day/Week now uses the requested venue-local range in the PostgreSQL
+  repository and reference host. Week is Monday–Sunday, day/week results keep
+  staff scoping, and the manager UI labels the actual period.
+- Booking team access is now a separately versioned install contract. The
+  MaggieDash distribution includes its administrator-only access route,
+  email/password and Resend invitation policy, granular role permissions,
+  schema, Team access UI, and a standalone CLI validator. This prevents a
+  fresh host install from silently omitting the staff-login management seam.
+- The deterministic reference host now exercises owner-only Team access CRUD,
+  safe Resend invitation intent, permission updates, audit records, revocation,
+  and staff-session denial. This closes the gap where the access UI was static
+  but the reference browser host did not implement its endpoint.
+- The Booking installer now supports explicit `--install-dependencies`. It
+  detects npm/pnpm/yarn/bun from the host lockfile and adds only missing React,
+  Phosphor, Tailwind, PostgreSQL, Stripe, and SSR adapter packages; a blank
+  Astro host receives a portable Node server config, while an existing
+  deployment adapter remains host-owned. `--dry-run` and `--diff` reject this
+  mutation before invoking a package manager.
+- Resend delivery is implemented as a secret-safe outbox with retry,
+  dead-letter, replay, invitations, and reminders. Tenant-editable Booking
+  email templates now have a versioned ten-event contract, including package
+  purchase confirmation/refund and no-show fee events, with allowlisted
+  renderer, sandboxed manager preview, audited draft/publish/rollback, and
+  published-template resolution in both generic and ORA Resend workers. The
+  template contract never returns provider credentials or recipient addresses.
+- The default GitHub source now declares the Astro `hostBootstrap`; a fresh
+  disposable Astro install from that public source copied 139 source artifacts
+  and 23 host files, then passed the installed host validator and
+  `maggie booking inspect`.
+- Current local evidence: MaggieDash `npm test`, the 47-endpoint reference-host
+  suite, Booking UI validators, TSX parse, disposable PostgreSQL schema/core/
+  worker integration, backup/restore rehearsal, and fresh install projection
+  all passed. The browser evidence
+  contract now covers all 15 manager routes at 390/768/1440 widths (45 screens);
+  a fresh authenticated host capture is still required. The earlier 33/33
+  browser smoke covered only the former 11-route surface and is not reused as
+  production evidence. This is local/reference-host evidence only.
+- BK-068 adds the public customer-manage history route. A valid 30-day manage
+  token now returns the current booking plus tenant/customer-scoped redacted
+  appointment summaries, and the optional customer page renders them without
+  identity fields. Central and ORA flow, reference-host, PostgreSQL adapter,
+  and UI validators passed; real Resend-link and staging evidence remain open.
+- BK-030's source-level PostgreSQL transaction/lock cycle, alert contract, and
+  backup/restore rehearsal now pass against disposable PostgreSQL; it still
+  needs host-owned connection, alert routing, backup/restore ownership, and
+  recovery evidence. BK-031
+  still needs an authenticated HTTPS host runtime and browser capture. BK-032
+  now correctly remains `needs-evidence` until those artifacts pass the final
+  fail-closed release gate.
+- ORA host preflight on 2026-09-21: `node scripts/schema-check.mjs` passed for
+  the existing site schema, and `node scripts/maggie-booking-schema.mjs
+  --dry-run` passed for all three Booking schema files without committing.
+The real worker was intentionally not allowed to write and correctly failed
+closed because `maggiedash_booking_allocations` is not yet present. Applying
+the Booking migration remains an explicit owner-approved production action;
+until then the dashboard is installed but cannot serve live Booking data.
+
+## 2026-09-21 — Worker scheduler artifact generation
+
+- Added `maggie booking install --schedule systemd` and the standalone
+  `maggie booking worker-schedule --scheduler systemd|cron` command.
+- Generated units/cron files run the installed host worker from the project
+  directory, preserve the single-flight lock, and load the host `.env` only on
+  the server. The CLI never edits crontab, enables systemd, starts a process,
+  or prints secrets.
+- Verification: Python Booking tests (24/24), packaged CLI systemd generation,
+  board validation, Python/Node syntax checks, and `git diff --check` passed.
+  Enabling the schedule remains a host deployment/evidence gate.
+
+## 2026-09-21 — BK-099 cancellation-safe package credit restoration
+
+- Added additive `status`, `reversed_at`, `reversal_reason`, and `reversed_by`
+  fields to `maggiedash_booking_package_redemptions`; the migration remains
+  idempotent and non-destructive.
+- A cancelled manager booking now restores active package redemptions inside
+  the same transaction as the lifecycle transition. The repository locks the
+  ledger and balance rows, refuses inconsistent balances, restores an
+  exhausted entitlement when valid, and never deletes the original ledger row.
+- The public customer cancellation path and deterministic reference host use
+  the same exactly-once semantics. No-show and completed bookings retain their
+  package debit by policy.
+- Central `npm test`, public/manager reference-host regressions, disposable
+  PostgreSQL core integration (including package-credit restoration), schema
+  validation, ORA mirror checks, and ai-cmo board validation passed. The real
+  ORA database migration and staging cancellation evidence remain host gates.
+
+## 2026-09-21 — BK-094 tenant-scoped treatment package catalogue
+
+- Added package catalogue tables for tenant-scoped prepaid treatment bundles:
+  package metadata, price/currency, optional expiry, active state, and included
+  service-variant quantities. Package items must reference active variants in
+  the same project.
+- Added idempotent/audited `GET/POST /api/maggie/booking/packages.json`
+  manager routes, PostgreSQL repository methods, reference-host fixtures, and
+  the central/ORA Packages manager screen.
+- Synchronized the detailed MaggieDash contract, compact ai-cmo-skills contract,
+  bundled npm contract, route/service/type validators, schema validator, and
+  installed ORA mirror. This is a catalogue foundation only; purchasing,
+  customer package balances, redemption at checkout, expiry enforcement, and
+  refund settlement remained the next package phase at that point.
+
+## 2026-09-21 — BK-096 customer package checkout and refund settlement
+
+- Added a separate package-purchase aggregate and refund ledger so prepaid
+  treatment packages do not reuse booking-bound payment attempts.
+- Added public package checkout/payment-return routes and customer UI, with
+  idempotent customer creation, provider action hand-off, and pending-state
+  recovery.
+- Added Stripe metadata/webhook/reconciliation linkage that updates purchase
+  state and transactionally creates the customer entitlement and balances.
+- Added manager package-purchase listing/refund routes and UI. Refunds are
+  blocked after a redeemed visit and remain provider-led until Stripe confirms
+  the result.
+- Synced MaggieDash, ai-cmo-skills contracts/bundles, ORA host wiring, UI
+  validators, reference-host regression, schema, and docs.
+- Local gates for this slice: central npm test, ai-cmo Python Booking tests,
+  ORA contract/build, and package checkout/reference-host regression. Production
+  DB migration, Stripe webhook evidence, and scheduled Resend evidence remain
+  host gates.
+
+## 2026-09-21 — BK-098 public customer package redemption
+
+- Added `package_entitlement_id` to the hold projection, with a safe additive
+  schema migration and tenant/customer binding.
+- Public customer hold and checkout now carry the entitlement from the package
+  payment return; the server validates active status, expiry, currency, and
+  remaining treatment credits without trusting the browser for customer
+  identity.
+- Redemption locks the entitlement/items, writes the booking metadata and
+  redemption ledger, updates the balance/exhausted status, and completes in
+  the same transaction as booking conversion.
+- Reference-host regression passed for a confirmed zero-price public booking,
+  balance decrement, ledger row, idempotent hold/checkout boundaries, and the
+  package-return “Book with this package” link.
+
+## 2026-09-21 — BK-097 package lifecycle Resend notifications
+
+- Added `package.purchase.confirmed` and `package.purchase.refunded` to the
+  allowlisted email-template contract and fallback renderer.
+- Package Stripe fulfillment and refund transitions now enqueue idempotent,
+  tenant-scoped notifications linked by `package_purchase_id`; the outbox keeps
+  recipient addresses out of stored notification records and exposes only a
+  hash.
+- Updated the generic and ORA Resend workers to resolve package recipient,
+  package name, amount, and expiry at delivery time without booking manage
+  links for package messages.
+- Synced the PostgreSQL schema, worker/core repositories, email contract,
+  validators, and installed ORA mirror. Local central tests pass; real Resend
+  delivery and staging webhook evidence remain host gates.
+- Gap assessment: public package redemption is covered for fully covered
+  treatment selections. Customer balance browsing, memberships, gift cards,
+  recurring appointments, and automatic no-show charging remain future slices.
+
+## 2026-09-21 — BK-095 customer package entitlements and redemption
+
+- Added tenant-scoped customer package entitlements, per-variant granted and
+  redeemed quantities, expiry/status projection, and a redemption ledger.
+- Added manager `GET/POST /api/maggie/booking/customer-packages.json` routes
+  for balance reads and audited manual grants. A customer package grant is
+  idempotent and cannot cross tenant or customer scope.
+- Manager-created bookings can now accept `packageEntitlementId`; the
+  PostgreSQL repository locks the entitlement and item rows in the booking
+  transaction, rejects expired/exhausted balances, zero-prices covered
+  segments, records redemptions, and marks fully consumed entitlements
+  exhausted. The reference host exercises the same flow.
+- Added a Customer package balances panel to the Packages screen and synced
+  the central workspace, ORA mirror, detailed/compact/bundled contracts,
+  validators, and install docs. Stripe package checkout and package refunds
+  remain intentionally separate because the current payment attempt ledger is
+  booking-bound.
+
+## 2026-09-21 — buffer-aware availability and allocation enforcement
+
+- `treatmentTiming` now separates customer-visible duration from occupied time:
+  the first treatment's preparation buffer, each internal cleanup plus next
+  preparation gap, and the last treatment's cleanup buffer are all accounted
+  for. Availability slots still expose the visible start/end times.
+- The PostgreSQL core now writes expanded allocation ranges for manager-created
+  bookings, customer holds, waitlist conversion, and reschedules. Adjacent
+  bookings that touch a preparation/cleanup buffer are rejected transactionally.
+- Central and ORA customer/reference hosts and customer UIs now expose and use
+  buffer fields for public availability and multi-treatment segment cursors.
+- Added `schema/maggie-booking-buffer-backfill.sql`, a fail-closed one-time
+  migration for legacy reserved allocations. It must be reviewed and applied
+  separately after backup/staging verification; no live ORA database was
+  changed.
+- Evidence passed: central and ORA runtime/reference/customer/UI validators,
+  syntax checks, disposable PostgreSQL core integrations, and a disposable
+  backfill migration test that moved `10:00–11:00` to `09:55–11:10` for a
+  `5/10` minute buffer.
+
+## 2026-09-21 — first-run bookability readiness
+
+- PostgreSQL and reference-host Overview responses now expose the same
+  configuration gates: active location, active catalogue variant, bookable
+  staff with location/service assignments, working hours, overall `bookable`,
+  and payment capability.
+- This makes the manager dashboard explain why a freshly installed tenant is
+  not yet bookable instead of showing only a generic catalogue/payment state.
+- Central and ORA PostgreSQL repository validators now assert the complete
+  readiness payload. A fresh disposable PostgreSQL schema/core integration also
+  passed the real readiness query. No database or production configuration was
+  changed.
+
+## 2026-09-21 — disposable ORA host runtime verification
+
+- Ran the ORA Astro host from an isolated copy against a disposable local
+  PostgreSQL database. The test applied the Booking schema only to that
+  temporary database and used non-production URLs/secrets.
+- Verified the actual HTTP path for first-owner email/password authentication,
+  authenticated overview, settings, manager catalogue, staff list, and public
+  catalogue. The first owner registration returned HTTP 201; subsequent
+  login returned HTTP 200; all tested Booking reads returned HTTP 200.
+- This runtime test found and fixed two host defects: the catalogue repository
+  ordered service variants by a column that is not in the schema
+  (`service_variants.created_at`), and the ORA catalogue bootstrap could
+  duplicate services after a partial retry. Variant ordering now uses stable
+  existing columns, and ORA seed-upsert logic reuses existing services and
+  resumes interrupted seeds safely.
+- Re-ran MaggieDash `npm test`, ORA `npm run contract:check`, ORA
+  `npm run booking:email-templates:test`, and ORA `npm run build`; all passed.
+  The ORA build still reports only the two pre-existing non-Booking hints.
+- This is disposable local-host evidence only. It does not close the ORA
+  production migration, real Stripe/Resend delivery, scheduler, or browser
+  evidence gates.
+
+## 2026-09-21 — multi-variant treatment catalogue parity
+
+- The PostgreSQL catalogue read now returns variant metadata, stable ordering,
+  and buffer fields already supported by the schema/write path.
+- The manager Catalogue screen now edits all treatment variants under one
+  service instead of silently reading and writing only the first variant. An
+  owner can add/remove variants, set each duration, price, currency, and active
+  state, then persist the complete variant set idempotently.
+- The central workspace and the ORA installed workspace were updated together.
+  The PostgreSQL integration fixture now persists two variants and verifies
+  their buffer fields survive a read; the core integration passed.
+- This closes the UI/data parity gap for multiple treatments. Buffer-aware
+  availability and allocation semantics are now enforced for new and
+  rescheduled allocations; legacy ORA allocation backfill remains an explicit
+  staging/production gate.
+
+## 2026-09-21 — disposable PostgreSQL evidence repair
+
+- Fixed the core repository integration fixture to create the staff/location,
+  staff/service, and service/resource assignments required by the production
+  bookability rules.
+- Updated the customer token assertion for the current payment-token plus
+  30-day manage-token model (four sealed tokens across the two recovery flows).
+- Re-ran the disposable PostgreSQL schema, core repository, worker repository,
+  and matching PostgreSQL 12 backup/restore integrations. All passed and both
+  temporary databases were removed afterwards. MaggieDash `npm test` also
+  passed. This strengthens BK-030 local evidence but does not replace the
+  required ORA host evidence.
+- The GitHub Actions Astro-starter failure in run `35437704491`, job
+  `105883076605`, was caused by a missing `PUBLIC_SITE_URL` in the older
+  workflow revision. ai-cmo-skills commit `b19ad64` already supplies the
+  non-secret CI value `https://example.test`; it is unrelated to Booking.
+
+## 2026-09-21 — fresh Astro SSR install and build parity
+
+- Added a portable `astro.config.mjs` to the generic Astro host scaffold. It
+  enables server output, the Node adapter, React integration, and Tailwind;
+  the installer skips it whenever the project already owns any
+  `astro.config.*`, so Cloudflare/Vercel/Netlify/Deno deployment choices remain
+  untouched.
+- Added adapter-aware dependency completion. A blank Astro project receives
+  the Astro 5-compatible `@astrojs/node` range; an existing adapter is not
+  replaced. Added a generic `isResponse` auth export required by the bundled
+  email-template route.
+- Evidence: the default public GitHub source at MaggieDash `db83854` installed
+  into a fresh disposable Astro project, `maggie booking inspect` passed, and
+  `PUBLIC_SITE_URL=https://example.test npx astro build` completed successfully.
+  The central host validator and full `npm test` also passed.
+
+## 2026-09-21 — Stripe connection verification
+
+- Added the administrator-authenticated `POST /api/maggie/booking/payment-health.json`
+  route to the MaggieDash and ORA host adapters. It calls Stripe server-side,
+  persists only non-secret account/capability status, records an audit event,
+  and replays safely by idempotency key.
+- Added the Overview “Verify Stripe connection” action. Deployment credentials
+  remain in the secret store; the optional dashboard path accepts a key pair
+  only for owner/manager sessions, verifies it server-side, and returns only a
+  redacted result.
+- Updated the detailed/compact ai-cmo-skills contract, fixtures, validators,
+  bundled npm contract, installed ORA mirror, and current route documentation
+  to 40 manager routes. Also aligned the MaggieDash manifest validator with
+  the released package version.
+- Verification passed: MaggieDash contract/reference-host validators, ai-cmo
+  Booking tests and contract CLI, ORA contract checks, ORA `npm run build`, and
+  `git diff --check`. ORA build retains only two pre-existing hints.
+- Fixed the install-time schema runner so a blank Astro host does not require
+  `host-extensions.sql`; when a host supplies it, it now runs after the core
+  Booking tables exist. This was caught by the ORA dry-run against the real
+  configured database, which previously failed on the missing notifications
+  relation.
+
+## 2026-09-21 — BK-092 tenant-scoped email template management
+
+- Added `booking-email-templates-v1` to MaggieDash and ai-cmo-skills. It freezes
+  seven Booking event keys, event-specific placeholders, owner/admin/manager
+  access, tenant scoping, idempotency, audit, 50,000-character HTML limits,
+  and server-only Resend/recipient handling.
+- Added versioned PostgreSQL template storage, generic Astro and ORA
+  `GET/PATCH /api/maggie/booking/email-templates.json` routes, manager UI with
+  sandboxed preview, draft/publish/rollback history, and staff denial.
+- Updated both Resend workers to resolve the latest published tenant template
+  by project and event, render only allowlisted escaped values, and use the
+  existing fallback when no override is published.
+- Persisted the bounded notification variable context in `variables_json` and
+  loaded it through the PostgreSQL worker repository, so event-specific values
+  such as cancellation reasons survive the outbox/worker boundary without
+  storing recipient addresses or customer tokens.
+- Verification passed: MaggieDash `npm test`, template/reference-host
+  validator, ORA `npm run contract:check`, ORA template validator, and ORA
+  `npm run build`. The build retains only the two pre-existing hints. Real
+  database migration, Resend delivery, scheduler, and authenticated host
+  evidence remain production gates.
+
+## 2026-09-21 — fresh-install contract parity
+
+- Fixed the Booking CLI inspectors to normalize both the compact installed
+  contracts and MaggieDash's JSON Schema distribution contracts (`properties`
+  plus `x-endpoints`/`endpoints`). The email-template contract now declares the
+  same four read/draft/publish/rollback endpoints, auth boundary, idempotency,
+  and privacy policy in both forms.
+- Added a regression test for both detailed contract shapes and updated the
+  MaggieDash email-template validator to read the normalized fields.
+- Verification passed: a disposable local-source Astro install copied 139
+  artifacts and 23 host files, then `maggie booking inspect` returned
+  `passed`; packaged access/email contract checks, 25 ai-cmo Booking tests,
+  MaggieDash `npm test`, ORA template/contract/build checks, and `git diff
+  --check` also pass. The public GitHub distribution still needs the pending
+  MaggieDash release before default remote installs can use this host
+  bootstrap.
+
+## 2026-09-21 — BK-084 browser evidence coverage parity
+
+- Updated the browser evidence contract, Playwright capture, validators, ORA
+  installed copy, and CLI release-gate route inventory from the former 11
+  manager screens to all 15 current screens: overview, calendar, bookings,
+  customers, waitlist, locations, catalogue, staff, resources, schedule,
+  payments, notifications, reports, settings, and audit.
+- The contract now requires 45 route/viewport records across mobile, tablet,
+  and desktop. UI regression markers also require the waitlist, notification,
+  and reporting screens to remain present in the installed workspace.
+- Verification passed: MaggieDash `npm test`, ORA `npm run contract:check`,
+  ORA `npm run build`, ai-cmo-skills Booking Python tests, packaged task-board
+  validation, and `git diff --check`. A real authenticated host capture is
+  still required before BK-031/BK-032 can close.
+
+## 2026-09-21 — first-owner registration hardening
+
+- Hardened the generic Astro host and ORA installation copy so first-owner
+  registration runs in one PostgreSQL transaction protected by a
+  project-scoped `pg_advisory_xact_lock`. The owner check, project bootstrap,
+  user/membership writes, and audit event now commit or roll back together.
+- An existing email account can become the first owner only after proving its
+  current password. Registration never overwrites an existing password or
+  re-enables a disabled account; a new account is the only path that hashes a
+  supplied password. This closes the concurrent-registration and account
+  takeover risks in the previous route.
+- Verification passed: MaggieDash Astro host bootstrap validator, full
+  `npm test`, ORA `npm run contract:check`, ORA `npm run build`, and
+  `git diff --check`. The build still reports only the two pre-existing hints.
+- This is local code hardening, not production activation. The ORA Booking
+  migration, real Stripe/Resend delivery, worker scheduling, and authenticated
+  browser evidence remain the BK-030/BK-031/BK-032 release gates.
+
+## 2026-09-21 — BK-082 Booking access defaults and disabled-account guard
+
+- Fixed the generic Astro host and ORA access endpoints so a newly invited
+  `staff` account receives the safe default capabilities for calendar and
+  booking lifecycle work, while `finance` receives payment/refund defaults.
+  Administrators can still replace those defaults with the explicit granular
+  permission set from the Team access panel.
+- Booking access creation now rejects an existing disabled email account and
+  no longer clears `disabled_at` as a side effect of granting access. This
+  prevents an invitation or staff-role assignment from reactivating a host
+  account outside the intended recovery flow.
+- Verification passed: MaggieDash host bootstrap validator and full
+  `npm test`, ORA `npm run contract:check`, ORA `npm run build`, and
+  `git diff --check`. The build still reports only the two pre-existing hints.
+- This closes the local staff-login/permission default gap; real database
+  migration, Resend delivery, worker scheduling, and authenticated host
+  evidence remain release gates.
+
+## 2026-09-21 — BK-083 worker migration preflight
+
+- Hardened both the generic Astro worker and the ORA worker entrypoint with a
+  read-only PostgreSQL table preflight before lock acquisition or repository
+  reads. Missing core, Booking, or access tables now produce a bounded JSON
+  `needs-migration` report with exit code 1 instead of a raw missing-relation
+  stack trace.
+- The preflight does not apply migrations or write business state. It points
+  operators to the existing dry-run/apply commands and keeps database/provider
+  secrets out of the report, so systemd/cron can alert on a clear reason.
+- Verification passed: `node --check` for both worker entrypoints, the Astro
+  bootstrap validator, ORA worker run against its current unmigrated database,
+  and `git diff --check`. The ORA worker now reports core=true, booking=false,
+  access=false and exits 1 as designed.
+
+## 2026-09-21 — BK-080 notification delivery management
+
+- Added a tenant-scoped manager Notifications screen that lists redacted
+  delivery state, including template, channel, status, attempts, timestamps,
+  provider reference, and sanitized last-error text without exposing recipient
+  email addresses or provider payloads.
+- Owner/manager sessions can replay only `dead_letter` notifications. Replay
+  requires a human reason and idempotency key, resets the delivery lease/error
+  state, and records both `notification.replayed` and `notification.replay`
+  event/audit evidence. Staff and finance sessions cannot access the surface.
+- Added `booking.notifications.read` and `booking.notification.replay` to the
+  central/ORA host contracts, reference host, PostgreSQL repository, service,
+  route handler, type contract, install docs, and package contract checks.
+- Central MaggieDash `npm test`, packaged CLI contract/task/Stripe/setup checks,
+  ai-cmo Python tests, all relevant ORA Booking validators, ORA host-contract
+  fixture parity, ORA `npm run build`, and `git diff --check` passed.
+  BK-080 is now passed. Real Resend delivery, schema, owner, scheduler, and
+  production browser/runtime evidence remain host release gates.
+
+## 2026-09-21 — BK-069 bootstrap secret provisioning
+
+- Updated the explicit `maggie booking install --confirm --bootstrap` path to
+  generate a cryptographically random `BOOKING_TOKEN_SECRET` in the host's
+  local `.env` when the implementation-only secret is absent. The value is
+  intentionally never printed or serialized into setup output.
+- Existing valid secrets are preserved byte-for-byte; a configured value under
+  32 characters fails closed rather than being silently replaced. Hosts using
+  an external secret manager remain responsible for provisioning the same key.
+- Verification: the Booking CLI suite passed 13 tests, including generation,
+  idempotent replay, short-secret rejection, and existing secret redaction;
+  `git diff --check` passed.
+
+## 2026-09-21 — BK-070 transactional schema dry-run
+
+- Added `--dry-run` to the installed Booking schema command. It executes the
+  core, host-extension, and Booking migrations inside one PostgreSQL
+  transaction, then rolls the transaction back; errors also rollback before
+  returning a bounded failure.
+- The ORA database preflight passed against PostgreSQL 18.6 and rolled back
+  cleanly. The live schema remains unchanged (`booking` and `access` tables are
+  still absent); `--apply --confirm` remains an explicit deployment action.
+- Verification: central and ORA Node syntax checks, live ORA dry-run, and
+  `git diff --check` passed. The installed worker still correctly fails until
+  the migration is approved and applied.
+
+## 2026-09-21 — BK-071 Resend sender-key compatibility
+
+- The generic Astro Booking host now resolves the sender as
+  `EMAIL_FROM || RESEND_FROM_EMAIL` for both account invitation/reset emails
+  and the Resend worker. This matches the existing ORA convention without
+  changing the generic host's secret ownership boundary.
+- ORA's Booking readiness summary now reports Resend as configured when the
+  existing `RESEND_FROM_EMAIL` key is used. No sender or API key is exposed in
+  a response.
+- Verification: Astro host bootstrap validator, ORA build, worker syntax, and
+  `git diff --check` passed.
+
+## 2026-09-21 — BK-072 Multi-treatment manager appointments
+
+- Manager booking creation now accepts up to 12 `segments`, each with its own
+  service variant, time range, price/currency, and staff/resource allocation.
+  The server enforces one location and currency, exact variant duration,
+  per-segment availability, same-resource/staff overlap rejection, and writes
+  the booking, segment rows, allocations, event, and audit record through the
+  existing idempotent transaction boundary.
+- The reference host and ORA mirror now exercise a two-treatment appointment;
+  the manager form exposes `Add treatment`/`Remove treatment` and submits the
+  segment array while preserving the single-treatment path.
+- Verification: central `npm test`, central and ORA reference-host validators,
+  ORA `npm run build`, and the UI source gate passed. Migration remains
+  unapplied on ORA pending an approved matching-version backup and explicit
+  deployment confirmation.
+
+## 2026-09-21 — BK-073 Public multi-treatment booking
+
+- The public customer flow now accepts up to 12 ordered treatment segments while
+  keeping the existing single-treatment request shape compatible. Public DTOs
+  expose only safe segment fields; customer identity, token, payment-provider,
+  and tenant-private fields remain redacted.
+- Public availability accepts `serviceVariantIds` and returns slots for the
+  combined duration. The customer page now supports adding/removing treatments,
+  shows the estimated total, and constructs contiguous segment intervals from
+  the selected start time.
+- PostgreSQL holds now persist `segments_json`, reserve one allocation per
+  segment, and convert into one booking with segment rows, summed price, and
+  token-bound checkout/manage controls. The reference host covers multi-segment
+  availability, hold, and checkout replay.
+- Verification: central `npm test`, central and ORA customer-flow/reference-host/
+  UI validators, ORA `npm run build`, schema static gate, and `git diff --check`
+  passed. The live ORA migration remains unapplied pending backup and explicit
+  deployment confirmation.
+
+## 2026-09-21 — BK-074 Multi-treatment rescheduling
+
+- Manager-created and customer-converted bookings now keep a stable
+  segment-to-allocation link. Legacy single-treatment rows remain supported.
+- Rescheduling now shifts each treatment segment and its matching staff/resource
+  allocation by the same delta, checks conflicts per target segment, preserves
+  the original total duration for multi-treatment bookings, and returns the
+  updated segment list.
+- The reference customer host applies the same segment-aware behavior to its
+  public token-bound reschedule path, including per-segment availability checks.
+- Verification: central PostgreSQL-core and customer-reference validators,
+  ORA validator mirrors, Node syntax checks, and `git diff --check` passed.
+  ORA build and the live database migration remain release gates.
+
+## 2026-09-21 — BK-075 Install-time live configuration IDs
+
+- Booking catalogue responses now include tenant-scoped locations, and schedule
+  responses include the locations visible to the current staff scope.
+- New manager booking, staff, resource, and schedule forms now derive defaults
+  from bootstrap data instead of posting `location-1` or `service-1`. Resource
+  writes now persist their service assignments, so a newly configured room or
+  device can actually participate in treatment availability.
+- Synced the validated central Booking UI, repository, reference host, and UI
+  regression validator into ORA's installed `_maggie/booking` workspace.
+- Verification: central UI, reference-host, PostgreSQL-core, and configuration
+  validators passed; central and ORA syntax checks passed; ORA `npm run build`
+  passed with zero errors and zero warnings (two pre-existing hints); and
+  `git diff --check` passed. Live Booking schema migration remains pending.
+
+## 2026-09-21 — BK-076 Install-time location management
+
+- Added a tenant-scoped Locations screen and `GET/POST /locations.json` manager
+  boundary. Owners/managers can create or edit the first venue with name,
+  slug, IANA timezone, locale, address, active state, and online-booking state.
+- Mirrored the configuration validator, service/repository method, route
+  permission, reference host, contract, and UI in ORA. This closes the blank
+  project setup gap: a host no longer needs a pre-seeded `location-1` before
+  services, staff, resources, or schedules can be configured.
+- Verification: central and ORA service-contract, route-handler,
+  configuration, reference-host, and UI validators passed; the central full
+  suite is being rerun after synchronizing the independent 39-route fixture;
+  ORA build and live migration remain host release gates.
+
+## 2026-09-21 — BK-077 Synchronize the install-time Booking contract
+
+- Updated ai-cmo-skills' public `contracts/maggiedash/booking-host-adapter-v1.json`
+  with the two location endpoints and `locationSetup` capability. The CLI's
+  detailed-contract gate now expects the same 39 manager routes as MaggieDash,
+  so a package-installed project cannot pass a stale 35-route contract.
+- Updated the Python regression expectation and made the detailed-contract
+  validator compare its endpoint inventory instead of relying only on a future
+  hardcoded route count. The source/runtime contract remains separate from
+  provider secrets and host database state.
+- Verification: `maggie booking contract`, Python Booking tests, MaggieDash
+  `booking:contract:validate`, task-board validation, and `git diff --check`
+  passed.
+
+## 2026-09-21 — BK-078 Verify the public MaggieDash install source
+
+- Pushed MaggieDash `0.2.7` commit `50f0c16`, including the Astro
+  `hostBootstrap`, 40-route Booking source, worker/schema artifacts, and the
+  blank-host-safe schema runner. The follow-up `0.2.8` release supersedes this
+  source for fresh installs.
+- Ran the default installer against a fresh disposable Astro project without
+  `--source`; it copied 139 source artifacts and 22 Astro host files from
+  `https://github.com/TOPY-AI-LTD/MaggieDash.git` before the subsequent SSR
+  adapter/config addition.
+- The installed host validator and `maggie booking inspect` both passed. This
+  closes BK-078; real database, scheduler, authenticated browser, and ops
+  evidence remain the separate BK-030/BK-031/BK-032 gates.
+
+## 2026-09-21 — BK-079 Fix npm CLI Booking contract paths
+
+- Rebuilt `packages/maggie-cli/bundled-contracts/maggiedash` from the current
+  source contract and added the execution board to the packaged contract set.
+- Updated the Booking CLI to resolve contracts and the board from either the
+  source checkout (`contracts/`, `docs/`) or the npm layout
+  (`bundled-contracts/`). The published CLI no longer looks for a nonexistent
+  `packages/maggie-cli/contracts` directory.
+- Verification: packaged `maggie booking contract`, `stripe-audit`,
+  `tasks validate`, and `setup` passed; package Node/Python syntax checks and
+  `git diff --check` passed.
+
+## 2026-09-21 — BK-067 automatic waitlist slot matching
+
+- Added `backend/booking/waitlist.mjs` with deterministic service, location,
+  staff, preferred-date/time, priority, and FIFO matching rules.
+- Added the `match-waitlist` worker job between availability refresh and
+  reminders. It queues one idempotent `booking.waitlist.available` notification
+  through the existing Resend outbox, persists `notified_at` plus the offered
+  interval, and deliberately does not auto-create or reserve a booking.
+- Extended the PostgreSQL worker repository and additive schema with
+  `offered_start_at` and `offered_end_at`. Astro workers accept explicit
+  `BOOKING_WAITLIST_*` scope values so ambiguous multi-service availability
+  cannot send an incorrect offer.
+- Verification: MaggieDash `npm test`, waitlist priority/FIFO/replay
+  regression, ORA worker/runtime/UI validators, and `git diff --check` passed.
+
+## 2026-09-20 — Detailed execution board
+
+- Added `EXECUTION-BOARD.json` with leaf tasks BK-017–BK-038. Each task now
+  declares dependencies, plan, implementation files, tests, documentation
+  updates, and acceptance evidence.
+- Added `TASK-RUNBOOK.md` to make the required task → plan → implement → test →
+  docs → progress loop explicit.
+- Added `maggie booking tasks validate|list|show` as a read-only task board
+  inspection surface. BK-017 passed after JSON, CLI, Python syntax, skill
+  links, and whitespace gates.
+
+## 2026-09-20 — BK-018 host contract reconciliation
+
+- Reconciled the host contract from 26 to 32 canonical endpoints, including
+  customer detail, configuration writes, payment health, and the documented
+  refund/payment-start routes.
+- Added an independent contract fixture, an installed route projection, and
+  `npm run booking:contract:validate` so contract IDs/routes cannot silently
+  drift from the host documentation.
+- Validation: `npm test` passed, including manifest, Booking, 32-endpoint
+  contract, Stripe, runtime, syntax, and whitespace gates.
+
+## 2026-09-20 — BK-019 deterministic reference host
+
+- Added the secret-free fixture state and in-memory host implementation at
+  `fixtures/booking-host-state.v1.json` and
+  `backend/booking/reference-host.mjs`.
+- Added `booking:reference-host:test`, `booking:reference-host`, and the
+  installed `run-booking-reference-host.mjs` server. The local server is
+  explicitly fixture-only; it is not a production database or payment adapter.
+- The validator exercises all 32 canonical endpoint IDs and required response
+  fields, plus missing-session rejection, project scope, owner/manager/staff/
+  finance role boundary, mutation idempotency, webhook authentication, and a
+  fixture secret/raw-payload scan.
+- Evidence: `npm test`; `npm run booking:reference-host -- --self-test`; local
+  HTTP GET to `/api/maggie/booking/overview.json` with the fixture session.
+- Result: BK-019 passed. The next executable task is BK-020, PostgreSQL
+  migration hardening and repeatable migration evidence.
+
+## 2026-09-20 — BK-020 PostgreSQL migration hardening
+
+- Expanded the additive migration with booking segments, payment transactions,
+  notification records, location/catalog/staff policy fields, hold ownership,
+  booking payment/source fields, allocation ownership, compatibility backfill,
+  and query indexes. `project_id` remains the physical tenant key mapped to
+  the existing MaggieDash project/session boundary.
+- Added `scripts/validate-booking-schema.mjs` and the stable
+  `npm run booking:schema:validate` command. It rejects destructive SQL and
+  checks the full table/constraint/index inventory.
+- Evidence command: `node scripts/validate-booking-schema.mjs
+  --database-url maggie_booking_validation_20260920_1 --confirm` against a
+  disposable PostgreSQL 14 database. The base schema was applied once, the
+  Booking migration twice, and the database check reported 26 tables, 3
+  required constraints, 3 required indexes, and `overlapCheck: passed`.
+- The overlap test ran inside a rolled-back transaction; the disposable
+  database was removed after verification. `npm test` and `git diff --check`
+  also pass.
+- Result: BK-020 passed. The next executable task is BK-021, timezone-aware
+  availability, holds, lifecycle commands, and transaction-safe domain rules.
+
+## 2026-09-20 — BK-021 timezone and booking domain commands
+
+- Added `backend/booking/time.mjs` for IANA timezone validation, local-to-UTC
+  conversion, explicit DST gap rejection, ambiguous fold selection, UTC/local
+  round-tripping, and interval normalization.
+- Added `backend/booking/commands.mjs` for idempotent hold creation/release/
+  conversion, lifecycle transitions, rescheduling, multi-segment allocation
+  conflict checks, project scope, and event/audit intent. The layer is pure
+  provider-neutral code and does not open a database or receive credentials.
+- Added `scripts/validate-booking-domain.mjs` and `npm run booking:domain:test`.
+  Fixtures cover Europe/London DST gap/fold, two-segment holds, overlap
+  rejection, idempotent replay, hold conversion, transition, and reschedule.
+- `npm test`, `npm run booking:domain:test`, and `git diff --check` pass.
+- Result: BK-021 passed. The next executable task is BK-022, safe host DTOs,
+  request validation, and transaction-aware service boundaries.
+
+## 2026-09-20 — BK-022 host service boundary and safe DTOs
+
+- Added `backend/booking/request.mjs` for JSON/content-type validation,
+  idempotency context, project scope, request IDs, and safe error mapping.
+- Added `backend/booking/dto.mjs` for canonical booking/customer/payment/list/
+  overview/settings DTOs with recursive secret, token, raw-payload, and card
+  field redaction.
+- Added `backend/booking/service.mjs` with repository and transaction injection;
+  it keeps SQL/provider SDKs outside the dashboard and returns canonical
+  response shapes.
+- Added `scripts/validate-booking-service.mjs` and
+  `npm run booking:service:test`. It verifies content type/idempotency failure,
+  safe errors, redaction, transaction invocation, and canonical responses.
+- `npm test`, `npm run booking:service:test`, and `git diff --check` pass.
+- Result: BK-022 passed. The next executable task is BK-023, validated
+  catalog/staff/resource/schedule/policy configuration CRUD.
+
+## 2026-09-20 — BK-023 configuration validation and CRUD intent
+
+- Added `backend/booking/configuration.mjs` and
+  `contracts/booking-configuration-v1.json`. The layer validates active
+  services/variants, integer minor-unit prices and ISO currencies, staff
+  location/service eligibility, resource capacity, schedule intervals and
+  working-hour times, then returns readiness and audit intent.
+- Integrated the normalized configuration validators into the reference host's
+  catalog/staff/resource/schedule mutation routes so they no longer echo
+  arbitrary UI input.
+- Added `scripts/validate-booking-configuration.mjs` and
+  `npm run booking:configuration:test`. Evidence covers invalid duration,
+  staff/resource scope, capacity, schedule ordering, idempotent draft updates,
+  audit events, and readiness.
+- `npm test`, `npm run booking:configuration:test`, and `git diff --check`
+  pass.
+- Result: BK-023 passed. The next executable task is BK-024, provider-neutral
+  payment orchestration and a fake gateway.
+
+## 2026-09-20 — BK-024 payment gateway and fake provider
+
+- Added `backend/booking/payment-gateway.mjs` with idempotent payment start,
+  provider reconciliation, refund upper-bound checks, currency/amount
+  validation, capability gating, and strict separation between payment and
+  booking state.
+- Added `backend/booking/fake-payment-gateway.mjs` and
+  `fixtures/payment-gateway.v1.json` for success, action-required, delayed,
+  failure, reconciliation, and refund scenarios. The fake provider exposes no
+  secret, card data, or raw payload.
+- Added `contracts/booking-payment-gateway-v1.json`,
+  `scripts/validate-booking-payment-gateway.mjs`, and
+  `npm run booking:payment:test`.
+- Evidence: fake modes all pass; payment redirect/action-required does not
+  change booking `paymentStatus`; duplicate starts replay; reconciliation is
+  queued; refund over captured amount and disabled capabilities fail safely.
+  `npm test` and `git diff --check` pass.
+- Result: BK-024 passed. The next executable task is BK-025, a host-owned
+  official Stripe adapter and sandbox conformance boundary.
+
+## 2026-09-20 — BK-025 injected Stripe adapter boundary
+
+- Added `backend/booking/stripe-adapter.mjs`. It uses an injected official SDK
+  factory, server-side secret provider, pinned API version, optional connected
+  account, and raw-body webhook secret. It covers PaymentIntents, Checkout
+  Sessions, SetupIntents, provider reads, Refunds, and normalized webhook
+  events without importing Stripe or reading environment variables.
+- Added `scripts/validate-stripe-adapter.mjs` and
+  `npm run booking:stripe-adapter:test` using an official-SDK-shaped test
+  double. Evidence confirms secret injection, action-required/client-safe
+  actions, account/API version options, webhook raw-body verification, refund
+  mapping, and safe missing-secret errors.
+- Updated the Stripe integration/payment gateway docs to distinguish the
+  implemented host seam from the still-required host sandbox/live conformance.
+  `npm test` and `git diff --check` pass.
+- Result: BK-025 passed. The next executable task is BK-026, transactional
+  notification/outbox delivery and recovery.
+
+## 2026-09-20 — BK-026 notification outbox and recovery
+
+- Added `backend/booking/notifications.mjs` and the type-only
+  `notification-adapter.d.ts`. Templates/channels are allowlisted, recipients
+  are stored as hashes, variables are bounded, and queueing creates a safe
+  outbox record.
+- Implemented lease/claim, adapter-injected delivery, exponential retry,
+  dead-letter after max attempts, and reasoned operator replay. Delivery
+  failure is post-commit and cannot roll back booking/payment truth.
+- Added `scripts/validate-booking-notifications.mjs` and
+  `npm run booking:notifications:test`. Evidence covers template rejection,
+  recipient redaction, outbox enqueue, idempotency, send, backoff, dead-letter,
+  and replay recovery.
+- Updated runtime operations and Astro host docs. `npm test` and
+  `git diff --check` pass.
+- Result: BK-026 passed. The next executable task is BK-027, completing the
+  Booking UI data loading, navigation, forms, and action feedback.
+
+## 2026-09-20 — Stripe integration audit
+
+- Audited the official Stripe API reference and event types for the Booking
+  scope: Customers, Checkout Sessions, PaymentIntents, SetupIntents, Refunds,
+  Events, discounts, Billing, Tax, Terminal, and Connect.
+- Added the installable `maggiedash-stripe-booking-capabilities.v1` contract,
+  a stale-audit CLI gate, and a provider-specific normalizer that does not
+  import the Stripe SDK or handle credentials.
+- Recorded that gift cards and referrals are not native Stripe API resources in
+  this scope. Gift Up and PartnerStack are candidate Stripe Apps; MaggieDash
+  still owns local attribution, redemption/reconciliation policy, and safety
+  decisions.
+- Validation: `npm test`, `npm run booking:stripe:validate`, and
+  `maggie booking stripe-audit --contract ...` must pass. A real host adapter,
+  sandbox upgrade, and production runtime evidence remain pending.
+
+## Baseline — 2026-09-20
+
+- Confirmed MaggieDash is clean at `8d6c158` and currently distributes only
+  `./_maggie/admin`.
+- Confirmed the existing dashboard uses the host's email/password session and
+  `/api/maggie/*` boundary; passkeys are not part of the contract.
+- Confirmed `maggie-service-booking` is a provider-backed catalogue/booking-link
+  skill, not a transactional Booking workspace.
+- Confirmed the Booking product documents define a provider-neutral domain,
+  PostgreSQL source of truth, idempotent commands, audit/outbox records and a
+  replaceable payment gateway.
+- Created the executable board in [`TASKS.md`](./TASKS.md).
+- User requested the remaining host-owned runtime to be made concrete, so BK-011
+  through BK-015 were added for domain services, workers, schedules, browser
+  evidence, and host operations.
+
+## Working loop
+
+1. Read the task's contract and acceptance gate.
+2. Implement in the owning repository.
+3. Run the smallest relevant validator immediately.
+4. Fix failures before moving to the next task.
+5. Update README/contracts/plan references and append the command/evidence
+   here.
+
+## Evidence log
+
+| Date | Tasks | Commands/evidence | Result |
+|---|---|---|---|
+| 2026-09-20 | BK-001 | Existing docs, MaggieDash manifest, adapter v2, package and dashboard source inspection | Contract baseline confirmed; docs task marked done |
+| 2026-09-20 | BK-002–BK-008 | `cd /home/balalior/Dev/MaggieDash && npm test` | Manifest, Booking workspace, endpoint contract, auth boundary, schema markers, and install mappings passed |
+| 2026-09-20 | BK-002, BK-006 | `python3 tools/clis/maggie_dash.py install --project <tmp> --source /home/balalior/Dev/MaggieDash --confirm` followed by `python3 tools/clis/maggie_booking.py inspect --project <tmp>` | Real local install copied admin and `_maggie/booking`; inspect passed with root contract/schema |
+| 2026-09-20 | BK-006 | `python3 tools/clis/maggie_booking.py contract`; `python3 tools/clis/maggie.py booking contract`; `python3 -m py_compile tools/clis/maggie.py tools/clis/maggie_booking.py` | Contract and top-level dispatch passed; invalid JSON evidence was rejected |
+| 2026-09-20 | BK-003, BK-009 | Temporary PostgreSQL database: apply `schema/maggiedash-install.sql`, apply `schema/maggie-booking-install.sql` twice, assert both exclusion constraints | Migration passed twice; `btree_gist` and 2 overlap constraints verified; temporary database removed |
+
+## 2026-09-20 — BK-027 Booking UI completion
+
+- Added URL-backed booking query/page state, keyboard-selectable rows, typed
+  booking records, idempotent mutation headers, pending/success/failure
+  feedback, accessible confirmation dialogs, and validated configuration forms.
+- Added `scripts/validate-booking-ui.mjs` and the stable
+  `npm run booking:ui:test` gate. esbuild compilation passed.
+- Ran the compiled React workspace in Chrome against the secret-free reference
+  host at 390x844, 768x1024, and 1440x1000. The initial smoke found an invalid
+  `/bookings/none.json` request and two mobile overflow defects; both were
+  fixed. The corrected smoke covered all 11 routes with no failed requests or
+  console errors. Tailwind CDN warnings came only from the temporary harness.
+- Result: BK-027 passed. Real authenticated host evidence remains a BK-031
+  requirement.
+
+## 2026-09-20 — BK-028 manager operations
+
+- Added calendar day/week modes and status filtering, the complete manager
+  lifecycle action map, rescheduling, payment start/reconcile/refund controls,
+  and explicit audit/payment status views.
+- Reference-host Chrome smoke confirmed the booking list, keyboard row
+  selection, confirmation dialog, Check in mutation, and Action saved state.
+- Result: BK-028 passed.
+
+## 2026-09-20 — BK-029 security and access boundaries
+
+- Added `scripts/validate-booking-security.mjs` and
+  `npm run booking:security:test`. It covers missing session, cross-project
+  scope, staff/finance role restrictions, unsigned webhooks, safe invalid JSON,
+  fixture secret redaction, and email/password-only auth.
+- Result: BK-029 passed. Production host session and location-membership
+  evidence remain part of BK-031.
+
+## 2026-09-20 — BK-030 worker adapter seam
+
+- Added `backend/booking/postgres-worker-adapter.mjs`, injected repository and
+  notification interfaces, tenant lock acquire/release, and the production
+  guard that rejects the JSON fixture store when `NODE_ENV=production`.
+- Added `scripts/validate-booking-worker-adapter.mjs` and
+  `npm run booking:worker-adapter:test`. The full `npm test` suite passed and
+  the production guard failed safely without `--adapter` as intended.
+- Result: BK-030 is `needs-evidence`: the host still must connect the seam to
+  PostgreSQL advisory/distributed locking, real transactions, and recovery
+  alerts.
+
+## 2026-09-20 — release gate and evidence boundary
+
+- Extended `maggie booking release-gate` with `--browser-evidence` and
+  `--require-browser`; it validates all 11 routes at 3 viewports, screenshot
+  path safety, ready state, empty console errors, and empty failed requests.
+- The supplied GitHub Actions run `35437704491` used pre-fix commit `bf3a54d`.
+  Its Astro build failed because `PUBLIC_SITE_URL` was absent. Main already
+  contains `b19ad64`, which sets `PUBLIC_SITE_URL=https://example.test` in the
+  workflow.
+- BK-031 remains `needs-evidence` until a real HTTPS host supplies the scoped
+  session state and sanitized browser/runtime artifacts. BK-032 remains
+  planned until BK-030/BK-031 are complete.
+| 2026-09-20 | BK-005, BK-009 | `npx --yes esbuild@0.25.0 booking/src/booking.tsx --bundle --external:react --external:@phosphor-icons/react`; `npm test`; `python3 scripts/validate_skills.py`; `git diff --check` | Booking TSX parsed; MaggieDash manifest/Booking gates, 20 skill/link checks, Python syntax, and whitespace checks passed. Schedule screen and contract-backed create form were added after review. |
+| 2026-09-20 | BK-011–BK-015 | `npm test`; `npm run booking:worker -- --job all`; `node backend/booking/run-booking-jobs.mjs --job all --write --write-fixture --confirm` on a temporary fixture; `node --check` for browser capture/validator; review of systemd/cron/GitHub workflows | Availability, hold expiry, payment webhook boundary/reconciliation, notification lease/retry, adapter runner, schedules, and browser evidence workflow are implemented. Production host wiring/evidence remains explicitly gated. |
+| 2026-09-20 | BK-012–BK-015 | Temporary install: `maggie dash install --source /home/balalior/Dev/MaggieDash --confirm`; `maggie booking inspect`; installed `validate-booking-runtime.mjs` and worker dry-run | Installed project contains `_maggie/booking`, runtime/browser contracts, worker, ops templates, and both workflows; inspect and installed runtime checks passed. |
+| 2026-09-20 | BK-017 | `python3 tools/clis/maggie_booking.py tasks validate`; `... tasks list`; `... tasks show BK-019`; `python3 scripts/validate_skills.py`; `git diff --check` | Execution board contains 16 dependency-linked leaf tasks with plan/implementation/test/docs/acceptance fields; task CLI and documentation gates passed. |
+
+## 2026-09-20 — BK-030 PostgreSQL repository and board gate
+
+- Added `backend/booking/postgres-worker-repository.mjs` in MaggieDash. It is a
+  host-injected, parameterized, tenant-scoped repository for worker state,
+  notifications, normalized payment-event acknowledgement, availability
+  snapshots, and session-bound PostgreSQL advisory locks. It intentionally has
+  no `pg` import, environment-variable reads, or provider credentials.
+- Added `scripts/validate-booking-postgres-worker-repository.mjs` and the stable
+  `npm run booking:postgres-repository:test` gate. The fake executor verifies
+  parameterized SQL, transaction writes, tenant scope, lock calls, event
+  acknowledgement, and snapshot persistence.
+- Extended the disposable schema gate. A fresh PostgreSQL database applied the
+  base and Booking migrations twice, confirmed 27 Booking tables, three
+  constraints, three indexes, four normalized payment-event columns, the
+  availability snapshot table, and an advisory-lock round trip; the database
+  was dropped after the test.
+- Added `--require-board`/`--board` to `maggie booking release-gate`. A final
+  release now fails closed while any execution-board task is not `passed`.
+- Result: BK-030 remains `needs-evidence`: repository and disposable database
+  checks pass, but the production host still must provide a session-bound
+  connection, real notification/alert wiring, backup/restore evidence, and
+  operational recovery evidence. BK-031 and BK-032 remain open.
+
+## 2026-09-20 — BK-030 operational health controls
+
+- Added a correlation ID to every worker report and propagated it to expired
+  hold events and the CLI `--correlation-id` option.
+- Added notification dead-letter handling after the configured retry limit;
+  dead-letter rows are no longer claimed again automatically.
+- Added `backend/booking/health.mjs` and
+  `npm run booking:health:test`. It emits the versioned sanitized health report
+  with stable alert codes for lock contention, failed/stale workers, stale
+  availability, payment reconciliation lag, notification retries, and dead
+  letters.
+- Added the health/repository gates to the MaggieDash package test and Booking
+  runtime CI, and updated the runtime contract, README, ops runbook, task board,
+  and QA guidance.
+- Result: BK-030 remains `needs-evidence`: the operational code and local gates
+  pass, while the host still must connect the report to real alert routing and
+  prove backup/restore and recovery behavior.
+
+## 2026-09-20 — BK-030 real PostgreSQL repository cycle
+
+- Added the optional stable command
+  `booking:postgres-repository:integration`. It requires an explicit
+  `--confirm`, creates one uniquely-prefixed test tenant, runs the actual
+  injected `pg` client through repository read/write/transaction/advisory-lock
+  paths, verifies payment acknowledgement plus notification/event/availability
+  persistence, and removes only that test tenant.
+- Ran it against a fresh local PostgreSQL database using `pg@8.16.3`; the
+  cycle passed and the database was removed after the run.
+- Result: BK-030 now has real local PostgreSQL evidence, but remains
+  `needs-evidence` for host-owned alert routing, backup/restore, and recovery
+  rehearsal. BK-031 still requires a real authenticated HTTPS host.
+
+## 2026-09-20 — BK-030 rollback write guard
+
+- Added the reference-host rollback invariant: when `settings.bookingEnabled`
+  is false, new booking and hold mutations return `capability_disabled`, while
+  existing reads remain available and prior history is not deleted.
+- Extended the reference-host validator and operations docs with the rollback
+  evidence requirement.
+- Result: the code-side rollback control is covered; production feature-flag
+  and recovery evidence remains host-owned, so BK-030 stays `needs-evidence`.
+
+## Open production gates
+
+The workspace UI and contracts can be delivered independently of a host's
+runtime. Before enabling real bookings, the host still needs a database
+migration run, availability/hold services, payment adapter/webhook
+reconciliation, notification delivery, browser evidence and a canary release.
+These are tracked in [`CURRENT-STATE.md`](./CURRENT-STATE.md), not hidden behind
+the UI installer.
+
+## 2026-09-20 — BK-031 runtime evidence capture boundary
+
+- Found and fixed a real local evidence regression: the sanitized runtime
+  fixture contained 27 observations while the canonical host contract declared
+  32 endpoints. `maggie booking runtime-validate` now passes the aligned
+  32-endpoint fixture.
+- Added `MaggieDash/scripts/capture-booking-runtime-evidence.mjs`. It requires
+  an HTTPS origin, an environment-owned email/password session cookie, an
+  explicit host test plan, and `--confirm` for mutation coverage. It writes
+  only endpoint IDs, canonical routes, status codes, and required-field
+  booleans.
+- Added the package-local
+  `scripts/validate-booking-runtime-evidence.mjs`, a 32-endpoint fixture, the
+  install manifest mappings, and the protected
+  `.github/workflows/booking-runtime-evidence.yml` workflow. The workflow uses
+  environment-scoped base URL/session/plan inputs and retains only sanitized
+  evidence.
+- Tests passed:
+  `npm run booking:runtime:evidence:test`, `npm test`, `git diff --check`,
+  `python3 tools/clis/maggie_booking.py tasks validate`, and
+  `python3 scripts/validate_skills.py`.
+- Result: BK-031 has a stable executable real-host evidence path but remains
+  `needs-evidence` because neither inspected host project currently exposes the
+  Booking route set, and no authenticated HTTPS host run has been supplied.
+  The fixture is explicitly not production evidence.
+
+## 2026-09-20 — runtime evidence validator hardening
+
+- Tightened `maggie booking runtime-validate` to fail closed on unsupported
+  evidence schema, non-HTTPS base URLs, duplicate observations, and method or
+  canonical-route mismatches against the host contract.
+- Re-ran the aligned 32-endpoint fixture, task-board validation, skill/link
+  validation, and whitespace checks; all passed.
+
+## 2026-09-20 — BK-030 operational evidence contract
+
+- Added `contracts/booking-ops-evidence-v1.json` plus matching MaggieDash
+  validator and fixture. `maggie booking ops-validate` now checks sanitized
+  proof for backup/restore, all seven stable health alert codes, and rollback /
+  worker-restart / outbox-replay recovery rehearsal.
+- The validator is deliberately read-only: it does not create backups, page an
+  operator, restart a worker, or replay an outbox. Those facts must still come
+  from the host environment.
+- `npm run booking:ops:evidence:test`, `maggie booking ops-validate`, board
+  validation, skill/link validation, and whitespace checks passed.
+- Result: BK-030 remains `needs-evidence` until a real host supplies these
+  proofs plus the PostgreSQL/alert connection; the fixture is not release
+  evidence.
+
+## 2026-09-20 — BK-022 reusable Booking route boundary
+
+- Added `backend/booking/route-handler.mjs` with a framework-neutral dispatcher
+  for all 32 Booking contract routes. It centralizes session lookup, default
+  role policy, project scope, JSON parsing, idempotency-key enforcement,
+  correlation headers, safe error mapping, and raw provider-webhook forwarding.
+- Extended `createBookingService` with calendar/availability, configuration,
+  health, audit/event, and payment reconciliation methods required by the
+  dispatcher. Added matching TypeScript host-boundary types and installer
+  mappings.
+- Added `npm run booking:route-handler:test`; it passes all 32 route mappings
+  plus unauthorized, staff mutation, missing-idempotency, cross-project,
+  invalid-JSON, not-found, and webhook-body tests.
+- Re-ran `npm test` and `git diff --check`; both passed. This closes the
+  reusable MaggieDash-side HTTP boundary, while real host repository/session
+  and HTTPS production evidence remain BK-030/BK-031 gates.
+
+## 2026-09-20 — installed-package projection verification
+
+- Installed the current MaggieDash source into a fresh temporary project with
+  `python3 tools/clis/maggie_dash.py install --project <tmp> --source
+  /home/balalior/Dev/MaggieDash --confirm`; 109 files were installed without
+  overwriting the host project.
+- Ran the installed route-handler validator and installed ops-evidence
+  validator. `maggie booking inspect --project <tmp>`, `release-gate --project
+  <tmp>`, and `stripe-audit --project <tmp>` all passed.
+- This confirms the published install projection contains `_maggie/booking`,
+  the 32-route dispatcher, contracts, runtime/browser workflows, worker,
+  schema, ops templates, and sanitized fixtures. BK-030/BK-031 remain
+  explicitly host-evidence gates; no fixture was promoted to production proof.
+
+## 2026-09-20 — BK-032 release gate includes operational evidence
+
+- Extended `maggie booking release-gate` with `--ops-evidence`,
+  `--ops-contract`, and `--require-ops`. The final gate can now require
+  runtime, browser, operational, and execution-board evidence in one
+  fail-closed decision.
+- Updated the Booking skill, task runbook, execution board, and final-gate
+  examples so backup/restore, seven-code alert routing, and recovery rehearsal
+  cannot be omitted from release review.
+- The gate remains read-only; it validates sanitized proof and never performs
+  backups, paging, migrations, payment capture, or deployment.
+
+## 2026-09-20 — BK-022 canonical list response hardening
+
+- Hardened `createBookingService` list methods to accept either a repository
+  array or a canonical `{ items, total, page, pageSize }` object. Payment list
+  responses now preserve the contract's `reconciliation` summary while still
+  applying DTO redaction.
+- Added a regression fixture for object-shaped payment results and secret
+  redaction in `validate-booking-service.mjs`; the service gate now covers
+  this host/repository boundary explicitly.
+- Verification: `npm run booking:service:test`, `npm test`, fresh
+  `maggie dash install` projection, installed route-handler validation,
+  installed `release-gate --require-ops`, task-board validation, skill/link
+  validation, and whitespace checks all passed.
+
+## 2026-09-20 — host discovery boundary for BK-031
+
+- Rechecked the available local host projects. The ASPA-DAY main application
+  has an independent `/api/booking/*` implementation with Firebase identity
+  and business-membership semantics; `bea.gift` has no matching native
+  Booking route set.
+- Neither project exposes MaggieDash's traditional email/password session,
+  `/api/maggie/booking/*` 32-endpoint contract, or the required host adapter
+  evidence boundary. They are therefore not used as BK-031 production proof,
+  and no unrelated host code was modified to manufacture evidence.
+
+## 2026-09-20 — BK-029 staff role boundary correction
+
+- Corrected the reusable authorization policy: staff can now perform only
+  approved `checked_in`, `in_progress`, `completed`, and `no_show` booking
+  transitions. Staff payment routes, payment-health, customer directories,
+  reschedule/configuration writes, and other mutations remain forbidden.
+- Reused the same policy in the fixture reference host instead of maintaining
+  a second divergent role matrix. The route-handler validator now covers the
+  allowed lifecycle path and denied finance/customer/unsafe-transition paths.
+
+## 2026-09-20 — booking security documentation synchronized
+
+- Updated the security/compliance and host-adapter guidance to document the
+  staff lifecycle-only mutation boundary, finance payment boundary, and the
+  host-owned location/assignment filtering requirement.
+- Verification after the policy and documentation change: full MaggieDash
+  `npm test`, route-handler validator, reference-host validator, fresh install
+  projection, installed runtime/ops evidence validators, task-board validation,
+  skill/link validation, and whitespace checks all passed.
+
+## 2026-09-20 — BK-030 real worker adapter cycle and tenant context fix
+
+- Extended the disposable PostgreSQL integration test to execute the complete
+  `PostgresWorkerAdapter -> runBookingJobs -> dispatcher -> transaction`
+  cycle, instead of testing repository reads/writes in isolation.
+- Fixed the repository/adapter context mismatch that could acknowledge webhook
+  events while silently skipping payment, notification, event, and availability
+  state writes. The PostgreSQL repository now accepts and validates the shared
+  `{ tenantScope, nextState }` context and rejects mismatched tenant scopes.
+- Removed a test-clock race by setting notification `available_at` explicitly
+  in the integration fixture. The bare database-name integration path now uses
+  `PGHOST` or the local PostgreSQL socket.
+- Evidence: disposable PostgreSQL schema migration applied twice, advisory
+  lock and overlap checks passed, and the real worker cycle persisted payment
+  acknowledgement, notification delivery, event, and availability snapshot.
+  BK-030 still requires host alert-routing, backup/restore, and recovery proof.
+
+## 2026-09-20 — BK-031 installed runtime workflow path fix
+
+- Fixed `.github/workflows/booking-runtime-evidence.yml` so it resolves either
+  the source checkout's `scripts/` directory or the installed host's
+  `maggiedash/scripts/` directory, matching the browser evidence workflow.
+- Added a manifest/runtime validator invariant for both capture and validation
+  commands. This prevents an installed Booking package from producing a broken
+  workflow that cannot capture its required 32-endpoint evidence.
+- Verification: source `npm test`, fresh 109-file install projection, installed
+  Booking inspect, and inspection of the installed workflow paths all passed.
+
+## 2026-09-20 — BK-031 browser layout evidence enforcement
+
+- Extended the browser evidence contract and validator with `layoutErrors`.
+  Capture now measures document/body width at every route and viewport and
+  fails evidence on horizontal overflow, alongside console and request errors.
+- This makes the existing QA acceptance criterion executable in the protected
+  Playwright workflow instead of relying only on the local UI smoke test.
+
+## 2026-09-20 — BK-032 release gate browser parity
+
+- Closed a release-gate parity gap: the Python `maggie booking release-gate`
+  browser validator now requires the same ISO timestamp, 390/768/1440 viewport
+  set, empty console/request errors, and empty `layoutErrors` as the installed
+  JavaScript evidence validator.
+- This prevents an old or incomplete browser artifact from passing the final
+  gate merely because it contains the expected route names.
+
+## 2026-09-20 — BK-032 runtime evidence parity
+
+- Hardened the Python runtime evidence validator used by `maggie booking
+  runtime-validate` and `release-gate`: it now requires ISO timestamps and a
+  dedicated tenant, exact endpoint cardinality, rejects unknown/duplicate
+  observations, and rejects sensitive evidence keys.
+- The Python gate now matches the JavaScript host validator's fail-closed
+  contract instead of accepting a weaker local representation.
+
+## 2026-09-20 — BK-031 runtime plan route regression
+
+- Fixed the runtime capture plan matcher so contract placeholders such as
+  `{id}` are converted to concrete path segments exactly once. The previous
+  matcher replaced placeholders before attempting to build its comparison
+  pattern, so valid concrete routes could be rejected before any host request.
+- Exported the plan validator and added
+  `scripts/validate-booking-runtime-plan.mjs`, covering concrete path
+  parameters, required query parameters, mutation bodies, and unknown-route
+  rejection without credentials.
+- Added the validator to the MaggieDash distribution manifest, `npm test`,
+  the task board, host README, and the installed-project docs.
+- Verification: runtime plan validator, manifest validation, full MaggieDash
+  test suite, fresh install projection, installed plan validator, ai-cmo task
+  validation, skill/link validation, and whitespace checks.
+
+## 2026-09-20 — BK-030 operational evidence gate hardening
+
+- Strengthened the Booking ops evidence contract and both validators to require
+  backup/restore timestamps, row-count verification, critical alert delivery,
+  and all rollback/restart/outbox-replay proof booleans.
+- Added `--require-host` to reject fixture, test, and local environments when
+  operational evidence is used for a release gate. The regular fixture command
+  remains available for local validator regression tests.
+- Added the protected
+  `.github/workflows/booking-ops-evidence.yml` workflow and installed manifest
+  entry. It accepts only a sanitized host-generated artifact and does not
+  pretend to execute host-specific backup, pager, restart, or replay actions.
+- The workflow also checks that the evidence `environment` matches the selected
+  GitHub deployment environment before validation, preventing a staging
+  artifact from being attached to a production run.
+- Added regression coverage for missing proof fields, false recovery claims,
+  and the host-only gate. BK-030 remains `needs-evidence` until a real host
+  supplies backup/restore, alert-routing, and recovery evidence.
+- Expanded the health gate to exercise all seven stable alert codes, including
+  worker failure and retrying-notification paths that were previously only
+  named in the ops contract.
+- Verification: source `npm test`, fixture and host-only ops validators,
+  `python3 -m unittest tools.tests.test_maggie_booking`, fresh install
+  projection, installed Booking inspect, task-board validation, Python syntax,
+  skill/link validation, and whitespace checks.
+
+## 2026-09-20 — BK-030 disposable backup/restore rehearsal
+
+- Ran a real local PostgreSQL rehearsal against an explicitly named disposable
+  database: applied the base and Booking migrations twice, inserted a sentinel
+  project row, created a custom-format `pg_dump`, restored into a separate
+  disposable database, and verified the sentinel row after restore.
+- Result: schema/constraint/advisory-lock checks passed and
+  `backup_restore status=passed restored_rows=1`; both temporary databases were
+  dropped after verification.
+- This is local database evidence only. It does not satisfy the remaining
+  production-host backup retention, alert destination, worker restart, and
+  outbox replay evidence required to move BK-030 to `passed`.
+## 2026-09-20 — BK-033 public customer boundary
+
+- Added the versioned `booking-customer-surface-v1` contract with six separate
+  public-noindex routes for catalogue, availability, holds, checkout start,
+  payment-return recovery, and customer cancellation.
+- Added `customer-flow.mjs` safe public DTOs, hold input validation, bounded
+  payment-return states, and allowlisted confirmation/cancellation/reschedule/
+  reminder notification intents. Added the framework-neutral customer route
+  handler with `no-store`/`noindex` headers, mutation idempotency, and
+  fail-closed tenant binding.
+- Added a secret-free fixture and `npm run booking:customer-flow:test`, then
+  included all customer artifacts in the MaggieDash distribution manifest.
+- Documentation updated in the MaggieDash root/backend/Astro adapter docs and
+  the Booking PRD, delivery plan, host adapter, task runbook, and board.
+- Verification: customer-flow validator, full MaggieDash `npm test`, manifest
+  validation, public DTO redaction, missing-tenant rejection, and route
+  noindex/idempotency checks all passed.
+- Remaining host work is explicit: bind a real tenant, apply public
+  origin/CSRF/rate-limit/bot controls, persist customer methods, wire provider
+  checkout and email/SMS delivery, then capture real runtime/browser evidence.
+
+## 2026-09-20 — BK-034 public customer booking page
+
+- Added `booking/src/customer.tsx` and the Astro route starter
+  `adapters/astro/customer-booking-page.astro` for the public
+  `/_maggie/booking/book` page. The page loads the public catalogue and
+  availability, creates an idempotent hold, starts checkout, and renders a
+  pending payment-return state without treating a redirect as confirmation.
+- Public browser requests use `credentials: omit`; write requests carry
+  `Idempotency-Key` and `X-Correlation-Id`. The Astro starter is noindex and
+  the installed projection includes both route templates.
+- Added `booking:customer-ui:test`, manifest requirements, task BK-034, and
+  synchronized the MaggieDash/AI CMO booking documentation.
+- Verification: customer UI/source and installed-projection validators,
+  customer-flow validator, manifest validation, MaggieDash `npm test`,
+  task-board validation, Python CLI tests, esbuild TSX bundle parse, and
+  installed projection inspection passed. A production host
+  still owns tenant binding, origin/CSRF/rate limits, provider checkout,
+  persistence, and real browser/runtime evidence.
+
+## 2026-09-20 — BK-035 public customer reference-host journey
+
+- Added `backend/booking/customer-reference-host.mjs`, a deterministic
+  public-customer wrapper around the existing secret-free manager reference
+  host. It exercises the public catalog, availability, hold, checkout,
+  payment-return, and token-bound cancellation boundary without using the
+  manager session for customer routes.
+- Added `scripts/validate-booking-customer-reference-host.mjs` and exposed it
+  through `booking:customer-reference-host:test`, the distribution manifest,
+  the installed-project inspector, and the full `npm test` gate.
+- Verification: public catalog and date-scoped availability, idempotent hold
+  replay, checkout-to-pending state, payment-return recovery, token-bound
+  cancellation, manager-session isolation, and notification-intent assertions
+  all passed.
+- This is deterministic contract/browser development evidence only. A host
+  still owns tenant persistence, origin/CSRF/rate limits, provider checkout,
+  opaque token storage, and production browser/runtime evidence.
+
+## 2026-09-20 — BK-036 customer input and mutation replay hardening
+
+- Hardened `customer-flow.mjs` so public holds reject malformed email
+  addresses and missing booking-update consent with structured
+  `validation_failed` fields, while preserving the existing empty-payload
+  validation order.
+- Added customer-scoped idempotency storage to the reference customer host for
+  checkout and cancellation. Replayed cancellation returns the original
+  response without a second event or notification intent.
+- Verification: invalid-email, missing-consent, stable-error-ordering,
+  customer-flow, cancel-replay, full MaggieDash `npm test`, and installed
+  projection checks passed.
+
+## 2026-09-20 — BK-037 idempotency payload mismatch regression
+
+- Added a customer-scoped normalized request hash to the deterministic public
+  reference host. The stored record contains only the hash and redacted
+  response, never the raw customer payload.
+- Same-key same-payload retries replay the original hold, checkout, or cancel
+  response. Reusing a key with a different payload now fails with a safe
+  `409 conflict` response instead of silently returning the wrong result.
+- Verification: hold, checkout, and cancellation mismatch fixtures,
+  customer reference-host validator, syntax checks, and the full MaggieDash
+  test suite passed. The compact ai-cmo-skills contract now validates the
+  declared input and replay policy through `maggie booking inspect`, with a
+  Python regression test for policy drift.
+
+## 2026-09-20 — BK-038 public customer CI coverage
+
+- Extended `.github/workflows/booking-runtime.yml` so source and installed
+  runtime gates execute the public customer flow, reference-host, and UI
+  validators, plus syntax checks for the customer backend modules.
+- Added static workflow markers to `scripts/validate-booking.mjs`, preventing
+  future workflow edits from silently dropping the public customer checks.
+- Verification: MaggieDash `npm test`, source/install customer validators,
+  workflow marker validation, and manifest/install inspection passed.
+
+## 2026-09-20 — BK-039 complete service adapter contract
+
+- Added `backend/booking-adapter-contract.d.ts` with the full transaction
+  repository method surface consumed by `createBookingService`, the complete
+  manager `BookingService` shape, and a separate six-method
+  `BookingCustomerService` shape.
+- Added explicit `serviceMethod` mappings to all 32 versioned manager endpoints.
+  This makes the route → service → repository seam inspectable before a host
+  wires PostgreSQL, while keeping SQL, sessions, secrets, and provider SDKs
+  host-owned.
+- Added `scripts/validate-booking-service-contract.mjs`, installed it through
+  `maggiedash.json`, and included it in the Booking manifest gate. It rejects
+  missing/duplicate endpoint mappings and missing repository, manager-service,
+  or public-customer method declarations.
+- Updated the host adapter documentation with the typed seam and command.
+- Verification: service-contract validator, MaggieDash `npm test`, manifest
+  validation, and fresh install projection checks passed. This is a contract
+  gate, not production host evidence; BK-030/BK-031 remain external-host work.
+
+## 2026-09-20 — BK-040 CLI service-contract enforcement
+
+- Mirrored the 32 manager `serviceMethods` mappings and six public customer
+  methods in the compact ai-cmo Booking contract.
+- Updated `maggie booking inspect` and `release-gate` to require the installed
+  `booking-adapter-contract.d.ts` and service-contract validator, so an
+  installed project cannot appear ready with only route/UI files.
+- Added Python regression coverage and documented the stable
+  `npm run booking:service-contract:test` command in the Booking CLI runbook.
+- Verification: Python unit tests, CLI contract validation, task-board
+  validation, syntax compilation, and installed-projection inspection passed.
+
+## 2026-09-20 — BK-041 customer cancellation UI
+
+- Added a token-bound cancellation action to the public payment-return page.
+  The page sends `credentials: omit`, an idempotency key, and the opaque
+  continuation token to `/api/maggie/booking/public/bookings/{id}/cancel.json`.
+- Added bounded pending, success, and error states without native dialogs, and
+  extended the customer UI validator to protect the cancellation route marker.
+- Updated the MaggieDash README and customer journey task record.
+- Verification: customer UI validator, source syntax checks, full MaggieDash
+  `npm test`, and installed customer UI validation passed. Production tenant
+  binding, cancellation policy, and real browser evidence remain host-owned.
+
+## 2026-09-20 — BK-042 PostgreSQL manager core repository
+
+- Added the additive `maggiedash_booking_settings` table and
+  `createPostgresBookingCoreRepository` in MaggieDash. It accepts only a host
+  query executor, same-client transaction callback, tenant scope, and clock;
+  it never imports `pg`, reads environment variables, or handles provider
+  secrets.
+- Implemented tenant-scoped parameterized reads for overview/calendar,
+  bookings, availability, customers, catalogue, settings, audit, events, and
+  runtime, plus transactional booking creation, hold creation/release,
+  rescheduling, and lifecycle transition writes. Writes persist idempotency,
+  event, audit, allocation, and overlap-protected records.
+- Added explicit PostgreSQL casts for every bound parameter in the new SQL
+  seam, including nullable text/date/timestamp values, to prevent the class of
+  ambiguous-parameter errors seen in host API handlers.
+- Added the typed core repository surface, install manifest entries, README
+  host wiring notes, and a fake-executor validator covering same-key replay,
+  tenant rejection, transaction client reuse, SQL parameter typing, and event/
+  audit persistence.
+- Updated `maggie booking inspect` and `release-gate` to require the installed
+  core repository artifact as well as its typed service contract and validator.
+- Verification: core repository validator, service/host/schema gates, full
+  MaggieDash `npm test`, fresh install projection, task-board validation, and
+  Python/skill/link checks passed. A real disposable PostgreSQL database also
+  passed migration, booking create/replay, transition, reschedule, readback,
+  event/audit/idempotency persistence, and cleanup. Payment provider orchestration,
+  public checkout persistence, and real host evidence remain explicit follow-up
+  work; configuration persistence is covered by BK-043.
+
+## 2026-09-20 — BK-043 PostgreSQL manager configuration and operational reads
+
+- Added the tenant-scoped PostgreSQL manager repository surface for catalogue,
+  staff, resources, schedules, closures, settings, payments reads, health,
+  payment health, audit, events, and lifecycle operations. Existing variants
+  referenced by bookings are deactivated rather than deleted during catalogue
+  updates.
+- Added the additive `maggiedash_booking_closures` table, expanded the typed
+  core adapter contract, and added the installed manager-method validator. The
+  core remains secret-free and deliberately leaves payment SDK operations and
+  webhook verification to injected host adapters.
+- Extended the real disposable PostgreSQL integration to exercise catalog,
+  staff, resource, schedule, closure, settings, health, event/audit, and
+  idempotency persistence. The cycle passed and removed its test tenant.
+- Evidence: `npm run booking:postgres-manager-methods:test`,
+  `npm run booking:postgres-core-repository:integration --
+  --database-url <disposable-db> --confirm`, `npm test`, and fresh install
+  projection checks.
+- Result: BK-043 passed. Remaining work is the host/provider payment and
+  webhook seam plus real host runtime/browser/ops evidence for BK-030/BK-031;
+  BK-032 remains the final release gate.
+
+## 2026-09-20 — BK-044 provider-injected PostgreSQL payment persistence
+
+- Added `backend/booking/postgres-payment-adapter.mjs` for normalized payment
+  start, server-side reconciliation, and refund persistence. The host injects
+  the fake or Stripe-shaped gateway; the adapter does not import provider SDKs,
+  read secrets, or accept raw provider payloads.
+- Payment provider calls happen before the adapter's short PostgreSQL
+  transaction. The transaction persists payment attempts, booking payment
+  status, refund/payment-transaction rows, idempotency, and event/audit records.
+  `createBookingService` now routes provider mutations through this boundary so
+  an external call is never held inside the manager repository transaction.
+- Added fake-gateway and real disposable PostgreSQL coverage for start,
+  same-key replay, reconciliation, refund, and persistence counts. The
+  service gate also verifies the provider-outside-transaction behavior.
+- Evidence: `npm run booking:postgres-payment-adapter:test`,
+  `npm run booking:service:test`, `npm test`, and the real core/payment
+  PostgreSQL integration cycle passed and cleaned up its tenant/database.
+- Result: BK-044 passed. Webhook signature verification, public checkout
+  persistence, and real host runtime/browser/ops evidence remain explicit host
+  boundaries; BK-030/BK-031 still require external evidence and BK-032 is the
+  final release gate.
+
+## 2026-09-20 — BK-045 public customer PostgreSQL persistence
+
+- Added `maggiedash_booking_customer_tokens` with a short-lived token hash and
+  host-sealed ciphertext. Raw bearer tokens are generated/used in memory only;
+  the host supplies `tokenCodec.seal/open` backed by its AEAD key.
+- Added `backend/booking/postgres-customer-adapter.mjs` composing the manager
+  core and payment persistence seams for public catalog, availability, holds,
+  checkout-to-pending, payment-return recovery, and token-bound cancellation.
+  It uses public DTOs and never exposes manager/customer/provider internals.
+  Customer hold, checkout, and cancellation mutations now require their own
+  namespaced idempotency records and use the manager transaction seam when
+  available.
+- Added a customer adapter validator and installed it through the manifest,
+  service contract, package scripts, and README/host adapter documentation.
+- Evidence: customer adapter gate, customer flow and reference-host gates,
+  real disposable PostgreSQL hold/checkout/payment-return/cancel replay,
+  full `npm test`, schema/install checks, and fresh projection validation
+  passed. Public origin/CSRF, abuse controls, notification delivery, token key,
+  and real host/browser evidence remain host-owned.
+- Result: BK-045 passed. BK-030/BK-031 still require external host evidence and
+  BK-032 remains the final release gate.
+
+## 2026-09-20 — BK-030 executable backup/restore rehearsal
+
+- Added `scripts/validate-booking-postgres-backup-restore.integration.mjs` and
+  the stable `booking:postgres-backup-restore:integration` command to turn the
+  backup requirement into a repeatable check. It requires explicitly named
+  source and empty restore databases, runs a custom-format `pg_dump`/
+  `pg_restore`, and compares row counts for the protected Booking tables.
+- Installed the command through `maggiedash.json`, documented it in the
+  MaggieDash/host/ops README files, and added it to the BK-030 execution gate.
+- Verification: a real local disposable source/restore database pair passed
+  row-count parity; the existing worker repository cycle and `pg_dump`/
+  `pg_restore` rehearsal also passed. The command never drops either database.
+- Result: local BK-030 implementation/evidence is stronger, but the task stays
+  `needs-evidence` until the host supplies alert routing, backup/recovery
+  ownership, and sanitized host ops evidence. BK-031/BK-032 remain open.
+
+## 2026-09-20 — BK-046 customer checkout provider-failure recovery
+
+- Reproduced the failure window where the manager conversion committed before
+  the payment provider call failed. A retry previously saw a converted hold
+  and returned a conflict, even though the booking was still recoverable.
+- Namespaced customer hold, checkout, and cancellation mutations when calling
+  the manager repository, keeping those manager keys distinct from the
+  customer idempotency records. Checkout now replays the conversion with the
+  stable customer key, reuses an unexpired sealed customer token, and sends the
+  same provider idempotency key on retry. A genuinely expired active hold still
+  fails closed.
+- Added a regression that fails the provider after conversion, retries the
+  same checkout, and verifies the pending booking is recovered without a
+  duplicate booking/token path.
+- Extended the disposable PostgreSQL integration with the same failure window:
+  the first provider call throws after conversion, the retry succeeds, the
+  replay returns the same booking, and the database contains one recovery
+  booking with two sealed customer tokens total.
+- Evidence: `npm run booking:postgres-customer-adapter:test`, disposable
+  PostgreSQL core/customer integration, `node --check
+  scripts/validate-booking-postgres-core-repository.integration.mjs`, and the
+  full MaggieDash `npm test` gate passed. BK-046 is passed; BK-030/BK-031
+  still require real host evidence and BK-032 remains the final release gate.
+
+## 2026-09-20 — BK-047 backup restore target fail-closed preflight
+
+- Audited the executable backup/restore rehearsal and found two unsafe or
+  misleading assumptions: the command previously trusted the caller's empty
+  target claim, and a row-empty schema still made full `pg_restore` fail on
+  `CREATE TABLE` conflicts.
+- Added a true empty-public-schema preflight before `pg_restore`. A target with
+  any public application table now fails before dump restore and leaves the
+  existing target unchanged; a bare empty database receives the full
+  custom-format restore and row-count parity.
+- Added `--pg-bin-dir` plus server/client major-version preflight. The command
+  now gives an actionable error when the default `PATH` selects an older
+  `pg_dump`/`pg_restore`, instead of exposing a late dump failure.
+- Evidence: a real PostgreSQL 14 source/bare-target pair passed with
+  `--pg-bin-dir /usr/lib/postgresql/14/bin`; a target containing the source
+  schema/project was rejected before restore; and the forced PostgreSQL 12
+  `PATH` produced the expected corrective `--pg-bin-dir` error. README, ops,
+  host adapter docs, task board, and this progress record now describe the
+  fail-closed target and client-selection behavior. BK-047 is passed;
+  BK-030/BK-031 and BK-032 remain the real-host release gates.
+
+## 2026-09-20 — BK-047 board and install projection verification
+
+- Reconciled the machine-readable BK-030 execution-board command with the
+  matching-client requirement introduced by BK-047.
+- Installed a fresh temporary project from the current MaggieDash worktree;
+  `maggie booking inspect --project <temporary-project>` passed all 30 install,
+  contract, validator, workflow, schema, customer, worker, and ops checks.
+- Ran the required release gate against that projection. With runtime, browser,
+  ops, and board requirements enabled, it correctly returned `blocked` with
+  explicit missing-evidence errors rather than treating local source or fixture
+  artifacts as production proof. BK-030/BK-031 remain external-host work and
+  BK-032 is now `needs-evidence` until those artifacts exist.
+
+## 2026-09-20 — BK-032 release-gate diagnostics
+
+- Hardened `maggie booking release-gate` so explicitly supplied but missing or
+  malformed runtime, browser, and ops artifacts produce a machine-readable
+  `blocked` result with the affected evidence status set to `failed`, instead
+  of terminating before the gate report is emitted.
+- Added a Python regression covering all three missing-artifact paths and
+  documented the CI/task-workflow behavior. The gate remains fail-closed and
+  still requires real host evidence when the corresponding `--require-*`
+  flags are used. BK-032 is now `needs-evidence`: its implementation and local
+  regression are complete, but release cannot pass until BK-030/BK-031 provide
+  host-bound runtime, browser, and operations evidence.
+
+## 2026-09-20 — local full-gate verification and CI diagnosis
+
+- Re-ran the MaggieDash Booking reference-host suite (32 endpoints), UI source
+  gate, full `npm test`, TSX/esbuild parse, disposable PostgreSQL backup/restore
+  rehearsal, and the fresh install projection. All local checks passed.
+- Re-ran the ai-cmo-skills task-board, Python Booking CLI regression suite,
+  skill/link validator, and whitespace check. All passed; the release gate
+  correctly emits structured `blocked` output when required host artifacts are
+  absent.
+- Inspected GitHub Actions run `35437704491` / job `105883076605`. The failure
+  was the Astro starter build loading `astro.config.mjs` without
+  `PUBLIC_SITE_URL`; commit `b19ad64` already adds the non-secret CI value
+  `https://example.test`. No Booking code caused that failure.
+- The remaining release blockers are unchanged and intentional: a real
+  authenticated HTTPS host run for BK-031, plus host-owned alert routing,
+  backup/recovery, and operational evidence for BK-030. Fixture/reference-host
+  output is not promoted as production proof.
+
+## 2026-09-20 — documentation synchronization against MaggieDash 0.2.6
+
+- Re-inspected MaggieDash after the Booking commit was pushed. `main` and
+  `origin/main` both resolve to `16afe3ba9e26ce952cc6ad32b7f813a6a1ea5bfc`;
+  `package.json` and `maggiedash.json` both report `0.2.6`.
+- Updated this progress log, the Booking README, delivery plan, CLI guide, and
+  docs index to point at the current 32-route manager contract,
+  six-route public customer contract, installed validators, and current
+  release-board counts. Historical entries were left intact and are not
+  rewritten as current status.
+- Verification: `npm test` in MaggieDash passed; `maggie booking tasks
+  validate`, the seven Python Booking regressions, `validate_skills.py`, and
+  `git diff --check` passed in ai-cmo-skills.
+- Result: docs now reflect the pushed `0.2.6` source. No local/reference-host
+  result was promoted to production evidence; BK-030/BK-031/BK-032 remain
+  `needs-evidence` until host-owned artifacts pass the final gate.
+
+## 2026-09-20 — ORA Wellness host integration audit
+
+- Audited `/home/balalior/Dev/clients/orawellness.uk` after installing the
+  Booking workspace. The host now has manager/customer routes, email/password
+  auth, Booking roles, Stripe injection, a Resend outbox worker, and the public
+  customer flow.
+- Fixed the production-path gaps found during the audit: real tenant location
+  selection, safe public 403/429 errors, Stripe payment-account projection,
+  webhook payload hashing, customer-cancel notification enqueueing, and worker
+  payment projection from `pending_payment` to `confirmed`/`cancelled`.
+- Added the host-specific audit and deployment guide:
+  `ORAWELLNESS-INTEGRATION-AUDIT.md` and the client
+  `docs/maggie-booking-integration.md`.
+- Evidence: ORA build passed, installed Booking inspection passed, central
+  MaggieDash `npm test` passed, and the read-only schema check reported
+  `core=true`, `booking=false`, `access=false`. No client database migration
+  was applied. Production Stripe, Resend scheduler, browser, and operations
+  evidence remain required before switching the public CTA.
+
+## 2026-09-20 — generic Booking host bootstrap
+
+- Productized the Booking setup path as `maggie booking install --project .
+  --confirm`. It delegates to the distribution installer and keeps the
+  `/_maggie/admin` and `/_maggie/booking` workspaces together.
+- Added an Astro host bootstrap that is safe for blank or existing projects:
+  email/password sessions, first-owner registration, manager/public Booking
+  routes, PostgreSQL/Stripe adapter wiring, middleware rewrite starter, schema
+  command, Resend outbox worker, and an environment-variable example are
+  copied only when the destination file is absent. Existing files are reported
+  as preserved; an existing `src/middleware.ts` requires a deliberate manual
+  merge of the generated rewrite block.
+- Included the installer path in the npm CLI bundle and added the
+  host-bootstrap validator. Evidence: MaggieDash `booking:host-bootstrap:test`,
+  full `npm test`, ai-cmo-skills Booking installer tests (14/14), package CLI
+  help smoke test, and a disposable Astro install projection all passed.
+- This is an install/bootstrap improvement, not production activation. It does
+  not apply SQL, create the first owner, install host dependencies, configure
+  Stripe/Resend credentials, merge existing middleware, or provide production
+  runtime/browser/operations evidence. Full Fresha parity (packages,
+  memberships, gift cards, deposits, reminders, reports, multi-location, and
+  customer history) remains outside the current v1 scope.
+
+## 2026-09-20 — Booking access and permission boundary
+
+- Found and fixed a fresh-install defect: the generic Astro adapter queried
+  `maggiedash_booking_user_roles`, but the standard Booking migration did not
+  create it. The table is now part of the provider-neutral migration with
+  `manager`, `staff`, and `finance` roles, optional staff-profile linkage,
+  explicit `permissions_json`, and an active flag. Existing host extensions
+  receive additive columns rather than destructive changes.
+- Added the generic Astro access API and Staff dashboard panel. Owners and
+  administrators can create email/password accounts, link staff profiles,
+  revoke access, reset passwords, and edit granular capabilities. The shared
+  route handler maps those capabilities to calendar, booking lifecycle,
+  customer, catalogue, staff, resource, schedule, payment, refund, settings,
+  and audit routes; authorization is enforced server-side.
+- Synchronized the ORA host adapter, access endpoint, schema extension, and
+  installed Booking UI with the same permission boundary. ORA's build passed
+  with 0 errors; MaggieDash host bootstrap, schema, UI, and full npm tests
+  passed, as did the ai-cmo-skills installer regressions.
+- This phase still uses an administrator-supplied temporary password rather
+  than a Resend invitation/reset flow. Resend remains the Booking notification
+  worker; invitation email, password reset, staff self-service profile, and
+  full Fresha feature parity remain follow-up work.
+
+## 2026-09-20 — Staff assignment scope and account email lifecycle
+
+- Found and fixed the repository-level assignment gap: route permissions alone
+  did not restrict a staff session's project-scoped booking queries. A linked
+  `staff_id` is now propagated through the host session context and enforced for
+  overview metrics, calendar, availability, bookings, customer summaries,
+  staff/resources, schedule rows, booking/hold reads, and lifecycle mutations.
+  Unlinked staff sessions fail closed; service variants are project-scoped.
+- Added server-side Resend account email helpers to the generic Astro host and
+  ORA: one-time expiring invitation/reset tokens, hashed token persistence,
+  password setup/reset, session revocation after reset, account-email API
+  routes, reset page, invitation resend action, and account audit events. The
+  Booking access panel no longer requires an administrator to share a temporary
+  password.
+- Verification: central core repository and route-handler validators passed;
+  generic Astro bootstrap validator now covers the account-email routes; ORA
+  Astro build, generic host bundle checks, the central npm suite, and the
+  Booking inspect gate passed.
+- Fixed the final account-email routing gap by adding the
+  `/_maggie/reset-password` middleware rewrite in both the generic Astro host
+  and ORA. ORA's Booking Staff panel can now create an account and send its
+  invitation directly, then link the staff profile and edit permissions.
+
+## 2026-09-20 — Reports slice
+
+- Added the tenant-scoped `booking.reports.read` endpoint and PostgreSQL
+  `readReports` repository method. It validates a maximum 366-day range and
+  returns totals, booked minutes, revenue, cancellations/no-shows, and
+  breakdowns by day, service, staff, and location.
+- Added the Reports navigation screen, date filters, accessible data tables,
+  reference-host coverage, route/contract validators, and the `reports.read`
+  permission name. Central MaggieDash `npm test` passes with 33 manager routes.
+- ORA still needs the copied installed adapter/contract projection refreshed and
+  real staging data verification before this report can be treated as a
+  production read model.
+- Remaining: apply the standard schema on staging, capture real Resend/Stripe
+  delivery and authenticated browser evidence, and implement the broader
+  Fresha roadmap (packages, memberships, gift cards, deposits, reporting,
+  multi-location policies, and customer self-service history).
+
+## 2026-09-20 — 24-hour reminder slice
+
+- Added `queueBookingReminders` to the provider-neutral notification module.
+  It selects future `confirmed` bookings within the next 24 hours, requires a
+  customer email, and derives a stable tenant-scoped idempotency key from the
+  booking ID.
+- Added `enqueue-reminders` to the runtime contract and default worker cycle.
+  The PostgreSQL worker now loads the customer email/location needed for the
+  server-side decision and upserts newly queued outbox rows in the same worker
+  transaction. The dispatcher still resolves the actual address at send time;
+  raw email is not stored in the notification record.
+- Synced the ORA host copy and confirmed the existing Resend dispatcher can
+  deliver the new `booking.reminder` template without a new provider secret.
+- Evidence: deterministic reminder queue/replay, central worker repository
+  validator, ORA health/syntax checks, and `git diff --check` pass. ORA
+  production scheduler/Resend acceptance evidence remains a host release gate.
+
+## 2026-09-20 — Payment policy and balance slice
+
+- Added provider-neutral service policies for `full`, `deposit`, `pay_later`,
+  and `no_payment`, including normalized deposit amount and initial due amount.
+- Payment attempts now carry a purpose (`deposit`, `balance`, `full`, or
+  `adjustment`). The runtime and PostgreSQL payment adapter aggregate captured
+  attempts and refunds into `paidMinor`, `balanceDueMinor`, and payment status;
+  they do not trust only the latest provider attempt.
+- The Booking manager catalogue form can configure the policy, the Payments
+  screen can start a deposit or balance payment, and the public checkout sends
+  only the amount due at that stage. Partial refunds project to the booking and
+  queue the allowlisted `payment.refunded` Resend notification.
+- Fixed idempotent payment replay to return the original result before current
+  balance validation, so a retry remains safe after the first capture.
+- Evidence: central `npm test`, runtime deposit projection, reference-host
+  endpoint suite, PostgreSQL payment adapter validator, and `git diff --check`
+  pass. ORA copies were synchronized and still require host migration, Stripe,
+  Resend, and staging evidence.
+
+## 2026-09-20 — Schedule rule and install safety slices
+
+- Fixed the Schedule screen's nested response handling and stopped its add-rule
+  form from replacing unrelated schedule rows. New working hours, staff shifts,
+  time-off records, and location closures now submit the full current snapshot
+  with bounded owner/time validation.
+- Added the four-rule Schedule form to MaggieDash and the installed ORA
+  projection. The UI validator now protects the preservation path and schedule
+  rule markers.
+- Improved Astro installation: when a project already has the conventional
+  `defineMiddleware((context, next) => {})` shape, `maggie booking install`
+  inserts an idempotent rewrite block for Booking/login/register/reset without
+  replacing host auth or redirects. Unsupported middleware is preserved and
+  reported in install state; `maggie booking inspect` treats the unresolved
+  integration as a failure.
+- Evidence: MaggieDash `npm test`, Booking UI validator, ORA Astro build,
+  installer regression suite, JSON/task-board validation, and whitespace checks
+  passed.
+
+## 2026-09-20 — Manager customer history slice
+
+- Replaced the manager Customers collection-only surface with a searchable
+  tenant-scoped directory and selected-customer detail panel.
+- The detail panel uses the existing safe customer-detail route to show contact
+  data, recorded service consent, and appointment history with loading, empty,
+  retry, and error states; it does not expose public bearer tokens or provider
+  internals.
+- Added `CustomersView`, selected-customer route coverage, and appointment/
+  consent markers to the UI regression validator. Synchronized the ORA host
+  projection and confirmed `maggie booking inspect --project .` plus the ORA
+  Astro build pass.
+- This is manager history, not a customer self-service history portal. The
+  latter remains a separate roadmap item.
+## 2026-09-20 — BK-054 editable service and treatment catalogue
+
+- Added a dedicated Catalogue view with service rows, variant details, search,
+  and an explicit Edit service action rather than routing catalogue data through
+  the generic read-only collection table.
+- The configuration form now keeps the existing service and variant IDs while
+  editing name, variant label, duration, price, currency, payment policy, and
+  active/inactive status. The existing audited, idempotent catalogue endpoint
+  remains the only write path.
+- Mirrored the UI in the ORA installed host and added a configuration regression
+  proving that edits preserve IDs and can deactivate both service and variant.
+- Evidence: MaggieDash `npm run booking:ui:test`, `npm test`, ORA Astro build,
+  task-board JSON validation, and `git diff --check` passed. Host staging data
+  verification remains part of the existing BK-030/BK-031/BK-032 release gates.
+
+## 2026-09-21 — BK-055 editable staff and resource management
+
+- Added dedicated Staff and Resources views with search, stable selection, edit
+  actions, and bounded loading/empty/error states instead of exposing only the
+  generic create form.
+- Staff edits preserve the profile ID while updating name, email, phone,
+  location/service assignments, active state, and bookable state. Resource edits
+  preserve the resource ID while updating name, type, location, capacity, and
+  active state.
+- Reused the existing audited, idempotent `staff.json` and `resources.json`
+  endpoints; no new persistence path was introduced. Mirrored the UI in ORA.
+- Evidence: MaggieDash `npm run booking:ui:test`,
+  `npm run booking:configuration:test`, `npm test`, ORA Astro build, task-board
+  validation, and `git diff --check` passed. Host staging verification remains
+  part of BK-030/BK-031/BK-032.
+
+## 2026-09-21 — BK-056 editable schedule-rule management
+
+- Replaced the schedule add-only surface with a searchable rule list covering
+  working hours, staff shifts, time off, and location closures.
+- Existing rules can be selected and edited with their stable IDs; changing a
+  rule writes the complete snapshot while removing only the selected row, so
+  unrelated availability rules remain intact.
+- Added bounded validation for ordered working hours, interval dates, and staff/
+  resource ownership inputs. Mirrored the schedule editor in ORA.
+- Evidence: MaggieDash `npm run booking:ui:test`, `npm test`, ORA Astro build,
+  task-board validation, and `git diff --check` passed. Host staging
+  verification remains part of BK-030/BK-031/BK-032.
+
+## 2026-09-21 — BK-057 live-configuration manager booking creation
+
+- Replaced manual service/location ID fields in the manager New booking form
+  with live catalogue, location, staff, and resource selectors.
+- The form now submits `staffId` or `resourceId`, matching the PostgreSQL
+  repository's allocation requirement, and returns bounded feedback when no
+  allocation is selected. Service selection also fills the configured price and
+  currency instead of asking managers to copy minor units manually.
+- Mirrored the form in ORA and expanded the reference-host create fixture to
+  include a staff allocation.
+- Evidence: MaggieDash UI/reference-host/full-suite validation, ORA Astro build,
+  task-board validation, and `git diff --check` passed. Host staging
+  verification remains part of BK-030/BK-031/BK-032.
+
+## 2026-09-21 — BK-058 first-run Booking setup checklist
+
+- Added `maggie booking setup --project .` as a read-only onboarding checklist.
+  It reports workspace/middleware installation, required environment-key
+  presence, optional Stripe payment configuration, and the pending schema,
+  first-owner, and Resend-worker steps without printing any secret values.
+- Fixed setup and `maggie booking inspect` to recognize the escaped path
+  markers emitted by Astro TypeScript regex literals, so an existing merged
+  middleware is not falsely reported as missing.
+- Evidence: `python3 -m unittest tools.tests.test_maggie_booking -v`, setup and
+  inspect against the ORA host, and `git diff --check` passed. Schema/owner/
+  worker and real Stripe delivery remain explicit host verification gates.
+
+## 2026-09-21 — BK-059 explicit one-command host bootstrap
+
+- Added `maggie booking install --project . --confirm --bootstrap` for a
+  reviewed new host. It installs the normal workspace/host scaffold, then
+  runs only the installed `scripts/maggie-booking-schema.mjs --apply --confirm`
+  with the host's existing environment.
+- The default install remains non-migrating; `--bootstrap` cannot be combined
+  with `--dry-run` or `--diff`, and it still does not create an owner, configure
+  Stripe, send email, or deploy.
+- Evidence: Booking Python CLI suite (10 tests), package prepack/entrypoint
+  smoke, task-board validation, and `git diff --check` passed. Owner setup,
+  Stripe webhook configuration, worker scheduling, and real host evidence
+  remain explicit next steps.
+
+## 2026-09-21 — BK-060 token-bound customer self-service rescheduling
+
+- Added `POST /api/maggie/booking/public/bookings/{id}/reschedule.json` to the
+  public customer contract. It validates the sealed booking token, future
+  timestamps, terminal booking states, tenant scope, allocation conflicts, and
+  idempotent replay before delegating to the same transactional manager
+  reschedule command.
+- Added safe `serviceVariantId` and `locationId` fields to the public booking
+  DTO so the payment-return page can load available times. The customer page
+  now lets a customer choose another date/time and queues the existing
+  `booking.rescheduled` Resend notification through both the generic Astro
+  adapter and ORA's host adapter.
+- Evidence: MaggieDash customer-flow, reference-host, PostgreSQL-adapter, UI,
+  and full-suite gates passed. ORA source/build synchronization and real host
+  token/email evidence remain deployment gates.
+
+## 2026-09-21 — BK-061 Resend customer-manage links
+
+- Split public customer tokens by purpose. Checkout now creates a short-lived
+  payment-return token plus a separately stored 30-day `manage` token; both
+  remain sealed at rest and only their hashes are searchable.
+- Updated the idempotent schema migration and schema validator with the token
+  purpose column and manage-token lookup index. The Astro and ORA Resend
+  workers reuse an existing manage token or create one for a manager-created
+  booking, then include only the safe manage URL in the email HTML.
+- Evidence: MaggieDash PostgreSQL customer-adapter validator, full `npm test`,
+  schema/static validators, worker syntax checks, ORA customer-adapter
+  validator, and the prior ORA Astro build passed. Real database migration and
+  Resend delivery remain BK-030/BK-031/BK-032 deployment evidence.
+
+## 2026-09-21 — BK-062 tenant-scoped waitlist
+
+- Added `maggiedash_booking_waitlist_entries` with tenant, service, location,
+  optional staff, preferred date/time, priority, status, idempotency, and
+  notification-expiry fields. Waitlist writes use the same PostgreSQL scope,
+  audit, event, and idempotency boundaries as bookings.
+- Added the public `POST /api/maggie/booking/public/waitlist.json` join route
+  and a manager queue with status filtering plus notify, convert, cancel, and
+  priority actions. Staff sessions remain limited to their linked staff scope.
+- Added the `booking.waitlist.available` notification intent, Astro/ORA host
+  wrappers, and worker dispatch through the existing Resend outbox. The email
+  points customers back to the booking page; it does not promise or reserve a
+  slot.
+- Evidence: MaggieDash full suite and customer-flow/schema/UI/route/contract
+  validators passed; ORA source validators and Astro build passed. A fresh
+  browser capture, real schema migration, scheduled worker run, and actual
+  Resend delivery remain host release evidence.
+
+## 2026-09-21 — BK-063 transactional waitlist conversion
+
+- Added an additive `converted_booking_id` column, foreign key, and index to
+  the waitlist schema. A conversion now locks the queue entry and creates its
+  booking, segment, allocation, payment-policy projection, event, and audit
+  record before marking the entry converted.
+- Added server-side validation for concrete times, staff/resource eligibility,
+  tenant scope, overlap conflicts, and idempotent replay. The manager Waitlist
+  screen now selects a live staff/resource allocation and creates the booking;
+  confirmed results use the normal host Resend confirmation path.
+- Evidence: MaggieDash `npm test`, core repository conversion replay test,
+  reference-host conversion assertion, ORA route/contract/schema/UI/host
+  validators, ORA Astro build, and whitespace checks passed. Real migration,
+  browser capture, scheduled worker, Stripe/payment-policy staging, and Resend
+  delivery remain host release evidence.
+
+## 2026-09-21 — BK-064 first-run payment readiness panel
+
+- Added a manager Overview setup checklist to the central Booking workspace and
+  ORA mirror. It reads the existing payment-health response, shows the Stripe
+  account status and test/live mode, and generates the current host webhook URL.
+- Added a browser-safe copy action and explicit guidance to configure
+  `STRIPE_SECRET_KEY` and `STRIPE_WEBHOOK_SECRET` in the deployment secret
+  store. No provider secret is persisted or rendered by the UI.
+- Evidence: MaggieDash `npm test`, Booking UI/customer UI/host validators, ORA
+  `npm run build`, and `git diff --check` passed. ORA's read-only schema check
+  still reports `needs-migration` with core present and Booking/access tables
+  absent; no migration was applied.
+
+## 2026-09-21 — BK-065 strict setup-secret validation
+
+- Updated `maggie booking setup` to validate the public token secret length in
+  memory and report a short value as `invalid`, rather than treating presence
+  as readiness. Stripe now reports `degraded` when only one of its two required
+  keys is configured.
+- Added regression coverage that confirms actionable next steps while keeping
+  database URLs, Resend keys, Stripe keys, and token values out of output.
+- Evidence: 11 Python CLI tests, task-board validation, and whitespace checks
+  passed.
+
+## 2026-09-21 — BK-066 installed workspace validator fix
+
+- Fixed the Booking UI validator in MaggieDash and the ORA installed mirror to
+  read `booking/src` from the source package and fall back to the installed
+  sibling `_maggie/booking` workspace on a host project.
+- Added an explicit bounded error when neither workspace exists. This removes
+  the misleading `ENOENT` path failure after installation.
+- Evidence: MaggieDash `npm test` and `booking:ui:test`, ORA UI/customer UI
+  validators, and `git diff --check` passed.
+
+## 2026-09-21 — BK-085 cancellation and refund policy boundary
+
+- Added a versioned, normalized catalogue policy with free, cutoff-window, and
+  non-refundable modes, plus refund outcome and no-show fee fields.
+- Copied the policy into manager-created, customer-created, and waitlist-
+  converted bookings so later catalogue edits do not rewrite historical
+  booking intent.
+- Enforced the configured cutoff in PostgreSQL and reference customer
+  cancellation flows. Rejections return the policy and a bounded reason for
+  the customer UI; provider refund execution remains an explicit Stripe/host
+  operation.
+- Added the installed manager controls and additive
+  `cancellation_policy_json` schema migration to MaggieDash and the ORA mirror.
+- Evidence: MaggieDash `npm test`, ORA `npm run contract:check`, ORA Astro
+  build, policy/customer/schema/UI validators, and `git diff --check` passed.
+  The ORA schema was not applied; its existing read-only preflight still
+  reports `needs-migration`.
+
+## 2026-09-21 — BK-086 calendar range correctness
+
+- Fixed the manager Calendar Week mode so it no longer executes the Day query.
+  PostgreSQL now uses a venue-timezone, half-open day/week range and keeps the
+  staff-session filter bound to the same query.
+- Updated the reference host to filter fixture bookings by the requested day
+  or Monday–Sunday week, including cross-day appointments at the boundaries.
+- Updated the installed calendar period label and week agenda rows so the UI
+  reflects the returned range instead of showing only the selected date.
+- Evidence: MaggieDash `npm test`, central and ORA reference-host/repository
+  validators, ORA `npm run contract:check`, ORA Astro build, and
+  `git diff --check` passed. Existing ORA build output retained two unrelated
+  hints and no errors or warnings.
+
+## 2026-09-21 — BK-087 cancellation settlement and refund execution
+
+- Added a provider-neutral cancellation settlement planner that allocates full
+  or deposit refunds across captured payment attempts after already-recorded
+  refunds, and reports a bounded no-show fee without charging it automatically.
+- Added the PostgreSQL settlement seam. The booking lifecycle is committed
+  first; provider refunds then run with per-booking/payment-attempt idempotency.
+  Provider errors return `manual_required`, so an outage cannot resurrect a
+  cancelled booking or produce a false success response.
+- Customer cancellation responses now include redacted settlement status. The
+  generic Astro host and ORA host queue `payment.refunded` through the existing
+  tenant-scoped Resend outbox only for accepted/pending refund items, followed
+  by the normal cancellation email.
+- Closed the generic-host Resend parity gap: the Astro worker now has a
+  dedicated `payment.refunded` subject and a 15-second fetch timeout, matching
+  the ORA worker. The Astro bootstrap validator locks both markers into the
+  installable source.
+- Evidence: MaggieDash `npm test`, cancellation allocation/customer-adapter
+  regressions, central and ORA syntax checks, and the installed host mirror
+  synchronization passed. ORA contract/build and `git diff --check` remain in
+  the final verification pass below; live Stripe/Resend delivery is still a
+  host release gate.
+
+## 2026-09-21 — BK-088 no-show fee review boundary
+
+- Extended the PostgreSQL cancellation settlement seam to return a redacted
+  `review_required` result for manager no-show transitions, including the
+  policy-derived `noShowFeeMinor`.
+- No-show transitions return zero refundable amount and zero refund items even
+  when the booking has captured payment; the injected refund provider is not
+  called and no Resend refund email is queued.
+- Added the reference-host regression and manager detail notice stating that
+  no automatic charge or refund was made. The source package and ORA mirror
+  carry the same behavior.
+- Evidence: MaggieDash `npm test`, central/ORA no-show and reference-host
+  validators, esbuild, ORA `contract:check`/build, Astro bootstrap validation,
+  and `git diff --check` passed. The ORA build retains two pre-existing hints.
+
+## 2026-09-21 — BK-089 Booking access install contract
+
+- Added `booking-access-v1.json` to the MaggieDash distribution and the
+  ai-cmo-skills bundled contracts. It freezes the administrator-only access
+  boundary, roles, granular permissions, password minimum, Resend invitation,
+  audit actions, and tenant/disabled-account policy.
+- Added the generic Astro access route, schema, Team access UI, and manifest
+  validator to the Booking install gate. Added `maggie booking
+  access-contract` so a host can validate this boundary without connecting to
+  PostgreSQL or a provider.
+- Evidence: `npm run booking:access:test`, MaggieDash `npm test`, packaged
+  contract checks, and `git diff --check` are the required gates. Real ORA
+  migration and authenticated staff-login evidence remain production gates.
+
+## 2026-09-21 — BK-090 reference-host Team access CRUD
+
+- Added an in-memory, secret-free Team access fixture to the reference host.
+  Owner sessions can read access, create an invited staff account, update
+  permissions, and revoke access; staff sessions receive 403.
+- Added idempotent access mutation handling and audit events while keeping the
+  fixture independent of PostgreSQL, Stripe, and Resend network calls.
+- Evidence: reference-host validator and full MaggieDash `npm test` passed.
+
+## 2026-09-21 — BK-091 dependency-complete Booking installation
+
+- Added `maggie booking install --confirm --install-dependencies` for fresh
+  Astro hosts. The mode preserves existing dependency versions, selects the
+  package manager already declared by the project, and installs only missing
+  Booking runtime packages.
+- Added failure-safe mutation guards so dependency installation cannot run from
+  `--dry-run` or `--diff`, and a no-op project does not invoke a package
+  manager.
+- Added adapter-aware dependency selection and a blank-host Node SSR config;
+  existing Astro deployment adapters remain untouched.
+- Evidence: 22 Python Booking CLI tests, a fresh public-source dependency
+  install, public-source `maggie booking inspect`, fresh `astro build`, central
+  host validator, MaggieDash `npm test`, packaged task validation, and
+  `git diff --check` passed.
+
+## 2026-09-21 — BK-093 complete Booking defaults in Settings
+
+- Extended the manager Settings screen in MaggieDash and the ORA installed
+  workspace to load and save the existing tenant `currency`,
+  `bookingEnabled`, and `capturePolicy` fields alongside venue timezone.
+- Added explicit controls for accepting new bookings and automatic/manual
+  payment capture policy. Disabling booking writes keeps history and reads
+  available while the existing host boundary rejects new holds/bookings.
+- Kept Stripe and Resend credentials outside the dashboard and browser bundle;
+  this change reuses the existing audited, idempotent settings endpoint.
+- Evidence: central/ORA Booking UI validators, central/ORA reference-host
+  settings regressions, MaggieDash `npm test`, ORA `npm run contract:check`,
+  ORA Astro build, and `git diff --check` passed.
+
+## 2026-09-21 — Reviewed one-command fresh-host setup
+
+- Added `maggie booking install --confirm --ready` as the explicit convenience
+  path for a new Astro host. It combines missing dependency installation,
+  `BOOKING_TOKEN_SECRET` provisioning, and the idempotent Booking schema apply.
+- Kept the safety boundary explicit: `--ready` still requires `--confirm`, is
+  incompatible with `--dry-run`/`--diff`, does not create the owner, configure
+  Stripe, send Resend mail, enable a scheduler, or deploy, and can only write a
+  reviewable scheduler artifact when paired with `--schedule`.
+- Added an offline regression covering the combined path and synchronized the
+  skill, repository README, package README, and Booking CLI documentation.
+- Updated the read-only `maggie booking setup` checklist to recommend
+  `--ready` for a fresh host with missing dependencies, while retaining the
+  narrower `--bootstrap` instruction for an already-installed host.
+- Evidence: 32 Booking/MaggieDash Python tests, contract/access/email-template
+  checks, `validate_skills.py`, packaged CLI validation against ORA, and
+  `git diff --check` passed.
+
+## 2026-09-21 — Disposable PostgreSQL worker and recovery evidence
+
+- Ran the real PostgreSQL core-repository integration against a uniquely named
+  disposable database. It passed booking creation/replay, lifecycle and
+  reschedule, catalogue/staff/resource/schedule/settings persistence, payment
+  adapter behavior, package-credit restoration, public customer checkout/cancel
+  recovery, token sealing, and cleanup.
+- Ran the real PostgreSQL worker integration against the same disposable
+  schema. It passed tenant advisory locking, transaction writes, payment event
+  acknowledgement, notification dispatch/persistence, event persistence, and
+  availability snapshot generation.
+- Ran the PostgreSQL 14 custom-format backup/restore rehearsal into a separate
+  empty disposable database; tool/server version matching, empty-target
+  preflight, restore, and row-count parity passed. Both temporary databases
+  were removed by the test trap.
+- This strengthens BK-030's disposable-database evidence but does not satisfy
+  the remaining ORA production requirements: approved migration, host alert
+  routing, production backup/recovery rehearsal, real runtime evidence, or
+  authenticated browser evidence.
+
+## 2026-09-21 — ORA worker deployment-secret parity
+
+- Updated the ORA Booking worker to merge the local `.env` fallback with
+  `process.env`, with deployment-injected values taking precedence. The
+  standalone Resend worker now behaves like the installable MaggieDash Astro
+  worker under systemd, VPS secret stores, and CI environments.
+- No secret values are logged or copied; the change only fixes configuration
+  resolution. ORA contract:check, Astro build, worker syntax, and whitespace
+  checks remain required evidence.
+
+## 2026-09-21 — Fail-closed first-owner registration
+
+- Added core/Booking/access table preflight to the generic Astro registration
+  page and registration API, matching the existing login guard.
+- ORA now shows setup-required when only the core schema exists, and the API
+  returns a bounded 503 before creating a project, user, membership, or owner
+  audit row. This prevents an incomplete migration from creating a misleading
+  first-owner account.
+- Added central host-bootstrap and ORA contract markers for the registration
+  guard. Runtime verification against the current unmigrated ORA dev database
+  returned HTTP 200 with the setup-required state and no owner form.
+- Posted a valid-format disposable registration request to the unmigrated ORA
+  runtime; the API returned HTTP 503 with the bounded setup-incomplete error,
+  confirming that the write guard also runs server-side before any owner or
+  project row can be created.
+- Evidence: MaggieDash npm test, Astro host validator, ORA
+  contract:check, ORA Astro build (193 files, 0 errors/warnings/hints),
+  runtime registration checks, and git diff --check passed.
+
+## 2026-09-21 — Remaining production release gates
+
+- Local implementation and disposable PostgreSQL evidence are complete for the
+  Booking core, worker repository, backup/restore rehearsal, access control,
+  Stripe contracts, Resend templates/outbox, and installed ORA host.
+- The release gate is intentionally still blocked by evidence rather than a
+  missing local feature: ORA production schema migration/rollback approval,
+  real worker operations and alert routing, authenticated runtime evidence,
+  authenticated Playwright browser evidence, and board tasks BK-030/BK-031/BK-032.
+- The gate itself is read-only and does not migrate the database, create a
+  booking, capture a payment, send email, or deploy. These production actions
+  require an explicit rollout window, backup, credentials, and operator
+  approval.
+- Release distribution is also still open: the local CLI candidate is
+  `@topy-ai/maggie` 0.7.39 while the npm registry is 0.7.38, and the current
+  MaggieDash Booking changes are uncommitted in the working tree. A fresh
+  public-source install therefore must not be described as consuming this
+  latest candidate until the MaggieDash source and npm package are released.
+
+## 2026-09-21 — Align ORA migration secret resolution
+
+- Updated the installed ORA schema command to use `.env` only as a local
+  fallback and let deployment-injected `process.env` values take precedence,
+  matching the Booking worker and generic MaggieDash Astro host.
+- Added an ORA contract check so a future install cannot silently regress to a
+  migration command that ignores systemd, CI, or secret-store credentials.
+- This is an install/deployment hardening change; it does not apply the ORA
+  production migration or expose any secret values.
+
+## 2026-09-21 — Connect the ORA public booking entry point
+
+- Kept the existing `/book` email-request flow as a safe fallback, but added a
+  schema-aware online-booking entry point once the Booking core, location, and
+  access tables are ready.
+- The new link preserves legacy `?service=` hints and the installed customer
+  UI now resolves those hints against tenant service/variant IDs, slugs, names,
+  and legacy IDs before selecting the first treatment fallback.
+- Evidence: MaggieDash manager/customer UI and full npm validators, ORA
+  `contract:check`, ORA Astro build (193 files, 0 errors/warnings/hints),
+  runtime check confirming the online link stays hidden on the current
+  unmigrated database, and `git diff --check` passed.
+
+## 2026-09-21 — Align public booking copy and privacy disclosure
+
+- Updated ORA `/book`, `llms.txt`, and Privacy copy so the legacy email request
+  path and the optional online Stripe/Resend path are described separately.
+- The copy now avoids claiming that the site never charges online once the
+  Booking schema is enabled, while explicitly stating that card numbers/CVC
+  remain outside the host database.
+- Evidence: ORA contract check, Astro build (193 files, 0 errors/warnings/hints),
+  and whitespace validation passed.
+
+## 2026-09-21 — Public multi-location booking selection
+
+- Closed a real multi-location gap: the Booking manager and PostgreSQL schema
+  already supported multiple locations, but the public customer flow silently
+  used only the first active location.
+- Public catalogue DTOs now expose only safe fields for every active,
+  online-bookable location, while retaining the legacy first `locationId` for
+  older hosts. The customer page renders a location selector and sends the
+  selected location to availability, waitlist, hold, checkout, and reschedule
+  flows.
+- PostgreSQL availability now validates the selected tenant location, uses its
+  timezone, and filters conflicts by location. Central MaggieDash and the ORA
+  installed mirror are synchronized.
+- Evidence: MaggieDash full `npm test`, central/ORA customer-flow and customer-
+  UI validators, ORA `contract:check`, ORA Astro check/build (193 files,
+  0 errors/warnings/hints), and `git diff --check` passed. No production
+  database was changed.
+
+## 2026-09-21 — BK-101 complete server-enforced Booking capability permissions
+
+- Found a real access-control drift: the route handler already mapped
+  `locations`, `waitlist`, and `notifications` capabilities, but the admin
+  permission registry and access contract did not expose them. Staff customer
+  and notification reads were also hard-blocked even when an administrator
+  explicitly granted the capability.
+- Added the complete registry to the generic Astro host, ORA mirror,
+  reference host, detailed/compact contracts, and CLI contract validation.
+  Missing `permissions_json` rows now receive safe role defaults instead of
+  implicitly receiving every read route. Explicit staff grants are honored by
+  the server, while staff lifecycle mutations remain limited to approved
+  check-in/in-progress/completed/no-show transitions.
+- Added regression coverage for scoped staff customer, location, waitlist,
+  and notification reads plus legacy default-denial behavior. Updated the
+  host adapter, ORA integration, execution board, and task docs.
+
+## 2026-09-21 — BK-102 persist provider customer identity for Stripe
+
+- Fixed a real payment-boundary defect: Booking customers use tenant-local
+  UUIDs, but the previous Stripe adapter could pass those values directly as
+  Stripe `cus_*` references. Real Checkout, PaymentIntent, package purchase,
+  and SetupIntent requests could therefore fail even after Stripe connection
+  verification succeeded.
+- Added the tenant-scoped `provider_customer_ref` column and partial unique
+  index. The Astro host now resolves the local customer, creates or reuses a
+  Stripe Customer with a stable idempotency key, persists only the provider
+  reference, and passes that provider ID to Stripe. Dashboard credentials and
+  provider references never enter public DTOs.
+- Synchronized the central MaggieDash adapter/schema and ORA mirror, and
+  extended both Stripe adapter validators to assert local-to-provider mapping.
+- Evidence passed: central Stripe adapter validator and full `npm test`, ORA
+  Stripe adapter validator, ORA `contract:check`, ORA Astro check/build (193
+  files, 0 errors/warnings/hints), and whitespace validation. No production
+  database migration was applied.