@topy-ai/maggie 0.7.47 → 0.7.49

package/bundled-references/maggiedash-booking/HOST-ADAPTER.md

@@ -148,6 +148,11 @@ redirect cannot mark a payment paid. Use the existing outbox adapter for
 confirmation, cancellation, reschedule, and reminder email intents. The host
 stores customer token purpose explicitly: payment-return tokens are short-lived
 and the Resend worker uses a separate 30-day sealed `manage` token for links.
+After the payment-return token is verified, the response also supplies that
+manage token to the customer page. The page replaces the short token in its URL
+and uses the manage token for history, cancellation, and rescheduling. Public
+booking DTOs expose the allowlisted guest count and segment pricing fields;
+hosts must not add internal metadata or the raw suitability answer.
 
 For a deterministic end-to-end public journey, run:
 

package/bundled-references/maggiedash-booking/ORAWELLNESS-INTEGRATION-AUDIT.md

@@ -1,8 +1,8 @@
 # ORA Wellness Booking integration audit
 
-Date: 2026-09-21
+Initial audit: 2026-09-21 · Stripe status refreshed: 2026-09-28
 Project: `/home/balalior/Dev/clients/orawellness.uk`
-Source: MaggieDash Booking `0.2.8` plus ORA host adapter
+Source: MaggieDash Booking `0.2.10` plus ORA host adapter
 
 ## Short answer
 
@@ -12,22 +12,58 @@ tokens, Stripe payment boundary, Resend notification outbox, audit records,
 email/password login, and separate Booking roles.
 
 It is not production-ready yet. The remaining work is deployment evidence and
-provider operations, not another UI shell.
-
-The ORA `.env` currently contains a Stripe test secret under the existing
-`ST_SECRECT_KEY` compatibility name and a publishable test key under
-`ST_PUB_KEY`. The secret value is intentionally not recorded here. No
-`STRIPE_WEBHOOK_SECRET` is configured yet, so the account is not considered
-verified or connected for Booking.
-
-Current database gate: the existing ORA application schema check passes and the
-Booking migration dry-run passes transactionally, but the live Booking schema
-has not been applied. The 2026-09-21 read-only preflight confirmed that the
-core schema exists while `maggiedash_booking_allocations` and
-`maggiedash_booking_user_roles` are still absent. The worker therefore fails
-closed without touching production data. Do not enable the live dashboard or
-scheduler until the owner approves the migration, verifies the backup/restore
-path, creates the first owner, and captures runtime evidence.
+provider operations, not another UI shell. A 2026-09-28 read-only Chrome smoke
+found the live `/book` page advertising online booking; the direct customer
+page returned availability through 00:20, past the published closing time.
+No booking was submitted. The deployed version, payment readiness, and checkout
+outcome are unknown, so this is an active production exposure/schedule
+discrepancy to reconcile.
+
+The source audit found that the public availability adapter still used the
+generic duration-stepped query while customer hold creation used the host
+schedule planner. This explains why public starts could exceed venue hours or
+capacity constraints. The ORA working tree now routes both reads and holds
+through the same location/staff/resource-aware planner and requires the service
+to be enabled for online booking. Local adapter and rules regressions pass;
+a read-only staging API recheck returned assessment starts 17:45–20:15 local,
+ending by 20:50 before the 21:00 close. Production reconciliation remains open.
+
+BK-124 completed the follow-up audit of saved location closures. The shared
+planner now loads the requested tenant/location's closure intervals and applies
+them to both public availability and hold revalidation, including exact-edge
+boundary regressions. Local source/build checks pass; production remains
+unverified and unchanged.
+
+BK-125 also wires dated staff shifts into the same planner. Shifts constrain
+staff on the selected date in addition to recurring venue/staff hours, while a
+date without a shift retains the existing fallback behavior. Public slots and
+hold checks share this rule; production remains unverified and unchanged.
+
+The ORA `.env` contains a Stripe test secret under the existing
+`ST_SECRECT_KEY` compatibility name, a publishable test key under `ST_PUB_KEY`,
+and `STRIPE_WEBHOOK_SECRET`; no secret values are recorded here. The ai-cmo
+Booking setup checklist recognizes the legacy alias and reports the key pair
+as configured-pending-verification. A Stripe test-mode Checkout for £68 GBP
+was completed through the customer flow; Stripe readback showed a paid Checkout
+and succeeded PaymentIntent, and the staging Booking/customer history now agree
+on confirmed/paid. The configured sandbox identifies as APHRODITE FASHION
+LIMITED with charges disabled. Whether this is ORA's intended account and the
+authenticated Booking **Verify Stripe connection** check remain unconfirmed;
+test API availability is not account-identity or live-readiness evidence. A
+later approved direct test-mode probe also created/read/expired a £1 Checkout
+and confirmed a £1 `pm_card_visa` PaymentIntent. The account still reports
+`charges_enabled=false` and `payouts_enabled=false`, so online payment remains
+disabled.
+
+Current database gate: the explicitly targeted `orawellness-staging` database
+passes read-only core, Booking, and access schema checks. `DATABASE_URL` remains
+unclassified and is not release evidence; the approved production target has
+not been verified or migrated. The 2026-09-21 read-only preflight is historical:
+it found `maggiedash_booking_allocations` and
+`maggiedash_booking_user_roles` absent before the staging setup. Do not enable
+the production dashboard or scheduler until the owner confirms the production
+target, approves any migration, verifies backup/restore, creates the first
+owner, and captures authenticated runtime evidence.
 
 ## Verified in the codebase
 
@@ -124,6 +160,11 @@ password-reset links resolve to the Astro reset page.
 20. Closed the treatment catalogue UI parity gap: the manager can now manage
     every variant under a service, including duration, price, currency, and
     active state, while preserving the existing idempotent backend write.
+21. Aligned ORA public availability reads with the host schedule planner used
+    for customer holds. Public options now respect location hours, mapped staff
+    and resources, existing occupancy, and the online-booking service flag.
+    Local adapter, booking/rule, route-gate, contract, and build checks pass;
+    staging and browser re-verification are still required.
 
 ## Installer productization update
 
@@ -159,12 +200,14 @@ migration, backup/restore, alert routing, and authenticated runtime evidence.
 
 | Priority | Work | Why it matters | Owner |
 |---|---|---|---|
-| P0 | Apply `maggiedash-booking-install.sql` and host role migration on staging | Current ORA database check shows core MaggieDash tables exist, but Booking and Booking-role tables are not installed | ORA deployment |
+| P0 | Verify the approved production database target and Booking/access schema state | The explicitly targeted staging database has core, Booking, and access tables ready. `DATABASE_URL` is unclassified, and no production schema check or migration is accepted as release evidence. Confirm the production target and backup/restore plan; perform read-only verification first, and apply schema only after explicit approval | ORA deployment |
+| P0 | Reconcile the live public Booking exposure and out-of-hours availability | Chrome read-only inspection found `/book` advertises online booking and the public page returns starts past the published close. This conflicts with the prior release assumption; deployed version, payment account, and checkout outcome are unverified | ORA + release owner |
 | P0 | Release the current MaggieDash source used by the default installer | The public `9d99de7` source is a validated `0.2.8` baseline, but the current 47-route/no-show changes remain uncommitted in the working tree | MaggieDash release owner |
-| P0 | Configure the Stripe webhook secret and verify the existing test account; keep `BOOKING_TOKEN_SECRET` and Resend sender available | The test secret is present through `ST_SECRECT_KEY`, but signed webhook verification and connected readiness remain unavailable | ORA deployment |
+| P0 | Confirm the intended Stripe account and complete authenticated Booking connection verification | Direct test-mode Checkout and test-card PaymentIntent calls pass, but the configured sandbox reports charges/payouts disabled and is not confirmed as ORA's intended account. Keep `onlinePayment` disabled until the correct account is confirmed and the host verifies its capabilities | ORA + client |
 | P0 | Run worker every minute with alerting | Holds, payment projections, and Resend delivery otherwise remain pending; `maggie booking worker-schedule` now generates the reviewed systemd/cron artifact, but host enablement and alert routing remain pending | ORA operations |
+| P0 | Review Resend activity after the staging preview incident | Two pre-fix staging previews each reported one provider-accepted notification without persisting outbox state; a duplicate submission is possible. Review provider activity and assess any duplicate before a worker `--write` run | ORA operations |
 | P0 | Capture authenticated runtime/browser/ops evidence | Local build and reference fixtures cannot prove the real host | ORA + release owner |
-| P1 | Run Stripe test-mode scenarios | Confirm success, failure, delayed/duplicate webhook, and refund behavior against the actual account | ORA + Stripe |
+| P1 | Complete remaining Stripe test-mode scenarios | Checkout success and an expired unpaid Checkout are covered. Failure, delayed/duplicate webhook, refund, and the authenticated host connection still need evidence against the confirmed intended account | ORA + Stripe |
 | P1 | Capture Resend invitation/reset evidence | Booking notifications are wired; staff account invitation and password reset now use the same server-side Resend configuration | ORA + release owner |
 | P1 | Capture reminder delivery evidence | The worker now enqueues reminders; staging must prove scheduler timing, Resend acceptance, retry, and no duplicate send | ORA + release owner |
 | P1 | Verify customer-manage links in real Resend emails | Staging must prove the 30-day link opens the noindex customer page and reschedule/cancel remain token-bound | ORA + release owner |

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

@@ -96,6 +96,14 @@ The manager views a day or week calendar, filters by staff/location/status,
 opens a booking, records check-in and completion, takes an outstanding payment,
 reschedules, cancels, or starts a refund according to policy.
 
+All manager appointment dates and times use the booking location's IANA timezone:
+Calendar, Overview, booking lists/details, and waitlist preferred times display
+venue-local values even when the manager's device is in another zone. Manager
+booking creation, waitlist conversion, and reschedule `datetime-local` fields
+must convert wall times to UTC using that same location timezone. Spring DST-gap
+times are rejected before mutation, autumn repeated times expose earlier/later
+occurrence choices, and Calendar does not offer nonexistent wall-clock slots.
+
 ### Payment recovery
 
 If a gateway redirect is interrupted, the customer refreshes or returns later,
@@ -191,7 +199,7 @@ booking changes to `no_show`.
 | Security | No secret or payment credential in HTML, props, browser environment, logs, or audit payloads |
 | Privacy | Customer data is tenant-scoped, minimized, exportable, and deletable according to policy |
 | Accessibility | Keyboard navigation, focus management, labels, contrast, and reduced motion are tested |
-| Time | UTC instants in storage; venue timezone required for wall-clock input |
+| Time | UTC instants in storage; venue timezone required for wall-clock input and manager appointment display; DST gaps fail closed and repeated times are disambiguated |
 | Observability | Correlation ID through request, booking event, payment attempt, webhook, and notification |
 | Recovery | Failed webhooks, notifications, and provider reads are retryable without duplicate business effects |