Booking subsystem production-readiness audit — master tracker

[teetangh]

Booking Subsystem Production-Readiness Audit — Master Tracker

Scope: this is a single canonical tracker for the booking subsystem end-to-end (Prisma schema booking models, docs/booking/* 17 files, runtime code under app/api/**, lib/payments, lib/waitlist, utils/slotAllocation, utils/appointmentlock, jobs/appointments). It cross-links existing issues rather than duplicating them, and surfaces new findings from a fresh audit wave on 2026-04-17.

---

TL;DR

• Current readiness: ~75% (baseline from ChatGPT-5.4 Codex: Checkpoint 1 audit snapshot for saturation, correctness, and remaining risk #613 booking = 78% correctness / 88 saturation, discounted for 5 unaddressed P1 schema CHECK constraints surfaced here).
• 5 new P1 data-integrity gaps in prisma/schema.prisma are the fastest lever to move to 85% — no open issue yet, and they're single-migration fixes.
• One new P1 refund-flow bug (B1 below): two-phase commit can orphan a PENDING row with a placeholder refundId that the webhook cannot reconcile.
• Timezone/DST, cron locking, reschedule UX/audit, DB overlap exclusion are already tracked in Harden date/timezone handling — 7 high-risk areas (Option C) #503, [RESILIENCE] Distributed locking for cron jobs #476, Reschedule Flow: Missing notifications, no audit trail, staff/admin blind spots, and UX gaps #448, Add DB-level exclusion constraint for consultant slot overlap prevention #440 — this tracker surfaces status, not new work.
• Documentation drift in docs/booking/* (C1–C8 below) is fixable in one PR; concrete before/after patches included.

---

Method

Phase 1: three parallel Explore agents read (a) all 17 booking docs, (b) the 3 057-line Prisma schema + 3 recent migrations, (c) booking-adjacent runtime code and crons.

Phase 2: spot-verification of load-bearing claims against actual source. Five code-agent claims were disproved (listed under "Verification corrections" below) and excluded from the findings. Docs-agent and schema-agent findings held up.

Phase 3: cross-reference against existing open issues so we don't restate known work.

---

Production-readiness scorecard (booking subsystem)

Dimension	Score	Blocker to higher
Functional correctness	80%	concurrency edges on reschedule + cancel, refund two-phase orphan (B1)
Data integrity (schema constraints)	65%	5 P1 CHECK constraints missing (A1–A4); no DB overlap exclusion (#440)
Concurrency / locking	75%	cron distributed lock missing (#476); optimistic versioning absent (A11)
Timezone / DST	70%	#503 (7 items) unresolved
Observability / audit trail	70%	no CancellationAuditLog / RescheduleLog (#448, B4); doc C4/C6 gaps
Documentation accuracy	85%	small drift (C1–C8), mostly accurate
Test coverage for booking flow	65%	no race-condition CI gate (see #545 referenced by #613)
Overall	~75%

Target trajectory

After	Score
Phase 1 (schema + refund)	~82%
Phase 2 (concurrency + timezone)	~89%
Phase 3 (observability + UX)	~94%
Phase 4 (polish + docs)	~98%
Phase 5 (verification)	100%

---

Findings

P0 — none new

All true showstoppers (camera/microphone Permissions-Policy, config blockers, SSO veto) are already filed in #480 and #673. Nothing new at P0 surfaced.

---

P1 — New findings (not yet tracked)

A1. SlotOfAppointment missing CHECK (endsAt > startsAt)

File: prisma/schema.prisma:1978-1979
Impact: a misbehaving client (or a later refactor) can insert a slot with endsAt <= startsAt; every downstream duration/availability calculation silently breaks.
Fix: raw SQL migration

ALTER TABLE "SlotOfAppointment"
  ADD CONSTRAINT slot_time_order CHECK ("endsAt" > "startsAt");

A2. Payment.amount / originalAmount allow zero or negative

File: prisma/schema.prisma:2125-2126
Impact: a Payment with amount = 0 or negative bypasses revenue accounting, corrupts earnings, and will be silently rejected by some gateways but accepted by others.
Fix:

ALTER TABLE "Payment"
  ADD CONSTRAINT payment_amount_positive
  CHECK ("amount" > 0 AND "originalAmount" > 0);

Allow 0 only if a free/mock-payment path is ever needed — currently isMockPayment flag exists (line 2136) but amount is still expected to be >= 1. Confirm before narrowing.

A3. Plan prices can be negative

Files: prisma/schema.prisma:1336 (ConsultationPlan.price), 1401 (SubscriptionPlan.price). Check WebinarPlan.price and ClassPlan.price in the same migration.
Fix:

ALTER TABLE "ConsultationPlan" ADD CONSTRAINT consultation_plan_price_nonneg CHECK ("price" >= 0);
ALTER TABLE "SubscriptionPlan" ADD CONSTRAINT subscription_plan_price_nonneg CHECK ("price" >= 0);
-- repeat for WebinarPlan, ClassPlan

A4. maxParticipants can be 0 or negative

Files: prisma/schema.prisma:1598 (WebinarPlan), 1668 (ClassPlan).
Impact: capacity semantics break; waitlist promotion logic divides by maxParticipants in places.
Fix:

ALTER TABLE "WebinarPlan" ADD CONSTRAINT webinar_plan_max_participants_min CHECK ("maxParticipants" >= 1);
ALTER TABLE "ClassPlan"   ADD CONSTRAINT class_plan_max_participants_min   CHECK ("maxParticipants" >= 1);

B1. Refund two-phase commit can orphan PENDING rows

Files:

• app/api/payments/refunds/route.ts:163-282 (create → gateway → status-update)
• app/api/webhooks/razorpay/route.ts:231-292 + handleRefundCreated

Flow today:

1. Phase 1 (in tx, lines 163-176): create Refund { status: PENDING, refundId: "pending_${uuid}" }. This placeholder is chosen to reserve the amount and prevent double-refunds via the totalRefundedOrPending check (line 147-149).
2. Phase 2 (outside tx, lines 248-268): call Razorpay. On gateway error → mark FAILED (OK).
3. Phase 3 (line 275-282): update the row with the real Razorpay refund ID + SUCCEEDED.

Gap: if Phase 3 fails (DB blip, connection drop after gateway success), the row stays PENDING with the placeholder refundId. The webhook (refund.created → handleRefundCreated) keys on the Razorpay refund ID and can't find the row, so it creates a second row or no-ops — leaving the orphan PENDING forever. The next refund attempt sees the PENDING in totalRefundedOrPending (line 147-149) and is blocked.

Fix (sketch):

• Add Refund.clientRefundId or reuse metadata.clientUuid so the webhook can reconcile by our own UUID.
• On webhook, if a Razorpay refund ID doesn't match, look up by metadata.clientUuid before inserting a new row.
• Add a reconciliation cron (alongside reconcile-refunds) that, for any PENDING row older than N minutes with a pending_* refundId, queries Razorpay refunds list and either marks succeeded or failed.

Keep the amount-reservation property (PENDING blocks retries) — only the ID reconciliation is broken.

---

P1 — Already tracked (status check only)

Topic	Issue	Status
Consultant slot overlap (DB-level exclusion constraint with btree_gist)	#440	Open, deferred (needs Supabase migration + consultantProfileId denormalization)
Timezone / DST (7 high-risk areas: offset heuristic, overnight triple-representation, overlap-detection tests, custom midnight crossing, month overflow, DST weekly processing, reschedule window)	#503	Open, 3-5d estimate
Distributed locking for cron jobs	#476	Open; wraps 28+ app/api/cleanup/*/route.ts
Reschedule UX / notifications / audit trail / staff visibility / toast copy (7 sub-issues)	#448	Open
CI gate on booking concurrency + payment-failure lifecycle	#545	Open (referenced by #613)
Production readiness umbrella (showstoppers, config, security, DNS, scaling)	#480	Open
Audit scorecard baseline	#613	Open, snapshot dated 2026-03-31

---

P2 — New findings

A6. Payment.expiresAt uses bare DateTime, not @db.Timestamptz

File: prisma/schema.prisma:2135
Impact: PostgreSQL TIMESTAMP stores without zone; multi-region deployments or dev-vs-prod TZ mismatches can drift.
Fix: change to expiresAt DateTime? @db.Timestamptz. Same migration should sweep any other bare DateTime fields.

A7. Refund.createdAt / updatedAt bare DateTime

File: prisma/schema.prisma:2220-2221
Fix: @db.Timestamptz on both.

A8. Audit-field strings not FKs

Files: Consultation.cancelledBy (prisma/schema.prisma:1381), AppointmentDocument.reviewedBy (1901)
Impact: orphan user IDs possible; joins awkward; audit reports unreliable.
Fix: convert to proper User? relations (cancelledByUser, reviewedByUser) with onDelete: SetNull.

A9. SlotOfAppointment.user[] is an implicit many-many

File: prisma/schema.prisma:1976
Impact: can't track per-attendee metadata (confirmed-at, status, added-by). For webinars/classes this limits RSVP tracking.
Fix: introduce explicit SlotOfAppointmentAttendee { slotId, userId, confirmedAt, status } join model.

A10. No soft-delete on financial records

Affects: Appointment, SlotOfAppointment, Payment, Refund
Impact: cascade-delete path wipes audit history. Compliance risk for a financial SaaS.
Fix: add deletedAt DateTime? @db.Timestamptz + @@index([deletedAt]); migrate delete paths to soft-delete.

A11. No row-version on SlotOfAppointment for optimistic concurrency

File: prisma/schema.prisma:1973
Impact: concurrent reschedule/allocate operations race; Redis lock + updatedAt is the only guard. Once lock TTL misfires (during long txns), silent overwrite is possible.
Fix: add version Int @default(0); increment on every write; include in where for updates.

B2. Webhook idempotency fallback key is non-deterministic

File: app/api/webhooks/razorpay/route.ts:131-138

const entityId =
  event.payload?.payment?.entity?.id ||
  event.payload?.order?.entity?.id ||
  // ...
  `noid_${Date.now()}_${Math.random().toString(36).slice(2, 8)}`;
eventId = `${eventType}:${entityId}`;

Impact: for payloads where no entity ID is resolvable (malformed / new event types), the fallback generates a new random key on every replay → logWebhookEvent returns isNew: true → handler runs twice.
Fix: replace the random fallback with a SHA-256 of the raw body: ```ts
crypto.createHash("sha256").update(body).digest("hex").slice(0, 32)

#### B3. Refund rounding direction not documented
**File:** `app/api/payments/refunds/route.ts:155`
`refundAmount = amount || payment.amount - totalRefundedOrPending` — partial refunds in paise may produce fractions when applied via percentage policy. No explicit rounding.
**Fix:** document and enforce "round **down**" (toward zero) so the platform never over-refunds; add an inline comment + a helper `floorToPaise(n)`.

#### B4. No `CancellationAuditLog`
**Files:** `prisma/schema.prisma` (Consultation/Subscription have `cancelledAt`/`cancelledBy`/`cancellationReason` on the event itself)
**Impact:** once the event is soft-cancelled, the cancellation metadata is mutable; no immutable "who did what, when" record. Complements the `RescheduleLog` proposal in #448.
**Fix:** add
```prisma
model CancellationAuditLog {
  id                String             @id @default(uuid())
  appointmentId     String
  cancelledByUserId String
  cancelledAt       DateTime           @default(now()) @db.Timestamptz
  reason            CancellationReason
  notes             String?            @db.Text
  eventSnapshot     Json               // appointmentType + relevant ids at cancel time
  @@index([appointmentId])
  @@index([cancelledByUserId])
  @@index([cancelledAt])
}

---

Documentation drift — docs/booking/*

Each item below has a concrete before/after patch.

C1. 01-architecture.md — wrong tentative-slot TTL

Gap: Tentative Appointment Lifecycle diagram says "30 min cleanup". Actual cron TTL is 7 days (TENTATIVE_EXPIRATION_DAYS = 7 in app/api/cleanup/tentative-slots/route.ts; documented in 13-cron-jobs-and-background-tasks.md).
Patch:

- Tentative → CleanedUp: Abandoned (30 min)
+ Tentative → CleanedUp: cron sweep after 7 days
+   (see 13-cron-jobs-and-background-tasks.md §cleanup-tentative-slots)

C2. 07-rescheduling-flow.md — stale "Phase 1" roadmap

Gap: Known Issues #2 ("status always PENDING on partial reschedule") and #5 ("toast shows slot count") marked "Phase 1" with no PR reference. #448 now tracks the broader reschedule UX work.
Patch: either (a) remove the in-doc roadmap and link to #448, or (b) add PR references once #448's sub-issues land.

C3. 09-trial-sessions.md — rejection path under-specified

Gap: PENDING → REJECTED transition shown but (i) who rejects — consultant only? admin? and (ii) which Novu template fires.
Patch: add under "Status Lifecycle":

• PENDING → REJECTED: initiated by the consultant from their Trials tab. Fires Novu workflow trial-rejected (consultee channel: email + in-app).

C4. 11-waitlist-system.md — cron catch-up not stated

Gap: hourly cron expires notified-but-unresponded entries — doesn't state behaviour when a cron hour is skipped (infra outage).
Patch: add a line:

Expiration is idempotent by expiresAt: the next cron run processes all rows whose expiresAt <= now() regardless of how many hours were skipped.

C5. 02-event-types-and-validation.md — "1 call per day" unit undefined

Gap: Subscription rules say "Max 1 call per day". "Day" is ambiguous (UTC? consultant-local?). Current implementation uses UTC midnight (cross-check utils/slotAllocation/SlotValidationService.ts).
Patch: change rule to

Max 1 call per UTC day (measured from 00:00 UTC to 23:59:59 UTC).

C6. 13-cron-jobs-and-background-tasks.md — HTTP 207 operator response unstated

Gap: reconcile-slot-availability returns HTTP 207 on double-booking detection; doc doesn't say who's paged.
Patch: add under §reconcile-slot-availability:

On 207 Multi-Status, the response body includes doubleBookings[]. These require manual SRE review — no automatic remediation. See runbook docs/infrastructure/runbooks/booking-conflict.md (TODO).

C7 (P3). Missing ADR doc

Gap: no 00-architecture-decisions.md explaining 30-min slot granularity, Upstash vs self-hosted Redis, Prisma over raw SQL, Razorpay primary + Stripe secondary, etc.
Patch: create docs/booking/00-architecture-decisions.md as a short ADR register (one entry per decision: context → decision → consequences).

C8 (P3). 10-checkout-payment-integration.md — Payment.appointmentId write path undocumented

Gap: the doc doesn't spell out that checkout writes Payment.appointmentId and the webhook reads it. New contributors grep'ing for "who sets this" find nothing.
Patch: add to the data flow diagram and a one-liner:

Payment.appointmentId is set by the checkout handler (lib/payments/operations/checkout.ts) when the tentative appointment is created; the Razorpay webhook reads it during handlePaymentSuccess to confirm the booking.

---

Verification corrections (what the audit agents got wrong)

Logged here so future readers can trust the table above. Five code-agent claims were disproved against current source:

Claim from agent	Reality
"refund.created webhook handler missing"	Handler is present at app/api/webhooks/razorpay/route.ts:231-261 (also refund.processed, refund.failed at 263-292, refund.speed_changed at 295-300).
"No reschedule route handler"	Route exists at app/api/appointments/[appointmentId]/reschedule/route.ts. #448 tracks its UX gaps, not its absence.
"Waitlist position race — infinite loop possible"	lib/waitlist/slot-handler.ts:70-84 uses updateMany guarded by status: WAITING. Only one concurrent caller wins; the loser retries via i-- and getNextInQueue returns null on empty queue, terminating the loop.
"CANCELLED slots still block bookings"	utils/slotAllocation/occupancyPolicy.ts:23-28 filters at the event level using OCCUPIED_REQUEST_STATUSES = [PENDING, APPROVED, APPROVED_PENDING_PAYMENT, SCHEDULED]. Cancelled events are already excluded.
"Slot boundary overflow at slotTimeUtils.ts:375-383"	Misread — those lines are the overnight branch. The same-day branch (365-369) already enforces candidateEndMinutes <= availEndTimeUtc.

---

Roadmap to 100%

Phase 1 — Schema & refund hardening (P1, ~3d)

• Single migration for A1–A4 (CHECK constraints). Low risk; additive.
• B1 refund reconciliation (clientRefundId + webhook lookup + cron sweep).
• Prerequisites for Add DB-level exclusion constraint for consultant slot overlap prevention #440 (enable btree_gist, denormalize consultantProfileId on SlotOfAppointment). Target: 82%.

Phase 2 — Concurrency & timezone (P1, ~5d)

• Land [RESILIENCE] Distributed locking for cron jobs #476 (cron distributed lock) across every app/api/cleanup/*/route.ts.
• Land Harden date/timezone handling — 7 high-risk areas (Option C) #503 items 1, 2, 6 (replace getTimezoneOffsetMinutes heuristic with date-fns-tz, consolidate overnight handling, DST guards in processWeeklySlots).
• Land Add DB-level exclusion constraint for consultant slot overlap prevention #440 exclusion constraint after A5 denormalization. Target: 89%.

Phase 3 — Observability & UX (P1/P2, ~3d)

• Land Reschedule Flow: Missing notifications, no audit trail, staff/admin blind spots, and UX gaps #448 (notifications + RescheduleLog).
• Add CancellationAuditLog (B4).
• Land feat: Adopt structured logging with Winston (replace console.* calls) #531 structured-logging pass for booking paths.
• Add soft-delete to financial records (A10). Target: 94%.

Phase 4 — Polish (P2/P3, ~3d)

• Schema hardening A6, A7, A8, A9, A11.
• Docs patches C1–C8 in one PR (including creating 00-architecture-decisions.md).
• Land ChatGPT-5.4 Codex: PR CI does not gate on booking concurrency or payment-failure lifecycle regressions #545 booking concurrency CI gate. Target: 98%.

Phase 5 — Verification (ongoing, ~2d)

• Race test: two concurrent checkouts on the same slot → exactly one succeeds.
• DST transition tests: Mar 8 2026, Nov 1 2026 (US); Mar 29 2026, Oct 25 2026 (EU).
• Webhook replay test: duplicate payment.captured → exactly one side-effect.
• Refund orphan test: kill DB mid-Phase-3 after gateway call → reconciliation cron recovers.
• Target: 100% subject to no new discoveries.

---

Cross-references

Booking / scheduling / concurrency / docs:
#440 · #448 · #471 · #472 · #476 · #503 · #545 · #309

Production / infra / security:
#480 · #481 · #407 · #534

Payments / payouts / refunds (adjacent context):
#613 · #630 · #535 · #531

---

_{Generated from audit run on 2026-04-17 on branch feature/enterprise. Methodology: three parallel Explore subagents (docs, schema, code) with spot-verification pass against the source tree. See plan file /home/kaustav/.claude/plans/please-go-through-the-mossy-nova.md for exploration transcripts and verification notes.}

[teetangh]

Deep-dive addendum: allocation engine, calendar, cross-event conflicts, multi-TZ

Following up on this tracker — on re-review, the first audit pass stayed at the surface of booking lifecycle and didn't go deep into the allocation engine (auto / manual / requested modes in SlotAllocationService.allocate()), the calendar-rendering path, the cross-event-type occupancy matrix, or multi-timezone edge cases across the four event types (consultation, subscription, webinar, class). Did a second pass today covering those, with foreground verification against utils/slotAllocation/SlotAllocationService.ts (1838 lines), SlotValidationService.ts (866 lines), SlotCalculationService.ts (444 lines), occupancyPolicy.ts, slotTimeUtils.ts, the four validate + four allocate route files, and the public availability endpoints.

Below: only verified findings. Agent claims I disproved during verification are listed at the end so future readers can trust this addendum.

---

New P1 findings (verified against source)

AE-1. Consultee-side conflict not checked during allocation

Where: utils/slotAllocation/SlotValidationService.ts:228-254
Evidence: the single batched conflict query uses

{ user: { some: { id: consultantUserId } } }

as the sole user-filter (line 250). consulteeUserId is fetched in fetchEventData (SlotAllocationService.ts:1702, 1731) and passed to createAppointments (lines 398, 670, 1380-1381) for linking attendees to slots — but it is never passed to validator.validate(...) (calls at lines 636-643 for manual, and the auto path at 390-400). The validator has no consulteeUserId parameter today.

Issue: a consultee can be simultaneously booked into (a) a 1:1 consultation, (b) a subscription session, and (c) a webinar/class as an attendee at the same instant. Only the consultant side of each is checked against their own other bookings.

Impact: a consultee with a packed schedule silently ends up in two calendars at once. The host consultant of one event has no way to see the collision. Worst-case: they attend the group webinar (because attendees get auto-joined) and miss their paid 1:1 session; refund disputes follow.

Proposed fix:

1. Add a consulteeUserId?: string parameter to SlotValidationService.validate() and to validateNoConflicts().
2. In the conflict query, when consulteeUserId is present, also look up any Appointment whose slot has user.some.id = consulteeUserId in the same time envelope (same buildOccupiedAppointmentFilter() is reusable — it already covers all five event types).
3. For webinars/classes (group events, no single consultee), skip the consultee check, but add a capacity check + attendee-wide check (handled by waitlist today — no change needed).
4. Unit test: two concurrent bookings for the same consultee at the same time across different event types → exactly one must succeed.

---

AE-2. Class collaborators never consulted during allocation

Where: utils/slotAllocation/SlotAllocationService.ts:1755-1786 (the "class" branch of fetchEventData)
Evidence: the include only pulls classPlan.consultantProfile + classContents:

const event = await tx.class.findUnique({
  where: { id: eventId },
  include: {
    classPlan: {
      include: {
        consultantProfile: consultantProfileSelect,
        classContents: true,
      },
    },
    appointments: { include: { slotsOfAppointment: true } },
  },
});

No classPlan.classCollaborators relation is loaded. Downstream, findAvailableSlots + validateNoConflicts receive only the primary consultant's availability; ACCEPTED collaborators are not considered.

Issue: a class co-taught by primary A (IST) and collaborator B (PST). Auto-allocate selects slots from A's availability only. If B is busy at those times, the class is still scheduled — B shows up to a conflict.

Impact: co-taught classes silently schedule collaborators at times they're unavailable; since ClassCollaborator.revenueSharePercentage > 0, the earnings are still split but the collaborator can't deliver, degrading both UX and trust with the collaborator.

Proposed fix:

1. Extend the "class" include to load classPlan.classCollaborators where status = ACCEPTED, with each collaborator's consultantProfile.user, scheduleType, slotsOfAvailabilityWeekly, slotsOfAvailabilityCustom.
2. findAvailableSlots becomes AND-aware — a candidate slot must fit within every participant consultant's availability window.
3. validateNoConflicts loops over all [primary, ...collaborators] consultant IDs and short-circuits on the first hit.
4. Write an integration test: primary IST + collaborator PST with disjoint weekly availability → allocator either finds a shared window or throws AllocationValidationError with both users' constraints reported.

---

AE-3. Subscription.schedulingTimezone is ornamental

Where: prisma/schema.prisma:1441 (schedulingTimezone String @default("Asia/Kolkata"))
Evidence: grep across app/, lib/, utils/, components/, hooks/, jobs/, scripts/ for schedulingTimezone returns zero hits. The field is defined on every Subscription row but never read by any code path. Allocation uses the consultant's user.timezone (SlotAllocationService.ts:1811), never the subscription-scoped timezone.

Issue: the data contract says "this subscription is scheduled in IST", the runtime ignores it. Consumers who build reports or analytics against this field will get misleading values.

Impact: low operationally today (nothing reads it), but load-bearing for future enterprise features (e.g. an org booking on behalf of a team in a different zone, or a consultant who travels and whose user.timezone is updated but the subscription's original scheduling-zone should be preserved).

Proposed fix (pick one):

• Use it: thread subscription.schedulingTimezone into fetchEventData's consultant.timezone when the subscription defines one; fall back to consultant.user.timezone. Makes the field load-bearing.
• Remove it: drop the column in a follow-up migration. Currently zero risk since no reader would break.

My recommendation: use it — it gives us a way to pin the scheduling zone for a subscription independent of the consultant's current user-timezone, which directly addresses the "consultant travels mid-subscription" edge case.

---

New P2 findings (verified)

AE-4. Reschedule does not return the list of deleted appointment IDs to the client

Where: SlotAllocationService.ts:694 (and the mirrored return on the auto path)
Evidence: AllocationResult currently carries { success, appointments, warnings }. When manualAllocate handles a partial reschedule (3 of 48 sessions), it calls deleteExistingAppointments(..., onlyTentative: true) (line 655), then createAppointments for the replacements (line 664), then returns only the new appointments. The dashboard has no way to reconcile the IDs it held locally without a full refetch.

Issue: client state drift. Calendar UI either flashes stale slots or eagerly invalidates all 48 — both are worse than a surgical { deleted, created } diff.

Impact: UX-only today (consultees / consultants see a brief "ghost" of the old slots). Becomes correctness-relevant if the client ever does optimistic updates on these IDs.

Proposed fix: widen the return type to

type AllocationResult = {
  success: true;
  appointments: Appointment[];     // newly created
  deletedAppointmentIds?: string[]; // populated during reschedule/reallocation paths
  warnings: string[];
};

Populate deletedAppointmentIds from deleteExistingAppointments (already computed internally — it scans event.appointments.where({ isTentative: true }) before the deleteMany). Thread the ids into the return.

---

AE-5. Validator defaults slotDurationMinutes = 30 — correct for 30-min slot grain, but silent if a caller passes a longer candidate

Where: SlotValidationService.ts:197-216
Evidence: the signature is

async validateNoConflicts(
  slots: Date[],
  consultantUserId: string,
  slotDurationMinutes: number = 30,
  excludeAppointmentIds?: string[],
): Promise<ValidationResult>

and the envelope computation (lines 217-224) treats every candidate as slotDurationMs = 30 * 60 * 1000. This is correct because slot rows are always 30-min-grained today. But the parameter exists (not const), inviting a future caller to pass a longer duration and have per-slot overlap mismatch the envelope.

Issue: defensive-coding smell. Fine today; a single misbehaving refactor introduces a silent under-check.

Proposed fix: either (a) remove the parameter and inline SLOT_DURATION_MS = 30 * 60 * 1000 as a module constant, or (b) enforce at runtime if (slotDurationMinutes !== 30) throw until the architecture changes. No production bug — defence-in-depth.

---

Areas deep-dived and explicitly good

These came up in the audit and looked solid after verification — calling them out so the tracker reflects current state:

• Allocation mode switch (allocate → autoAllocate | manualAllocate | useRequestedSlots) at SlotAllocationService.ts:55-99 has clean error classification including Prisma P2002 → LOCK_CONTENTION 409 (lines 120-128). Matches #440's proposed app-code contract for when the DB exclusion constraint lands.
• Partial reschedule semantics: lines 1072-1088 build existingCallsPerWeek from this event's own confirmed appointments, excluding tentative ones via excludeSet. Initial callsThisWeek starts from that baseline (line 1100), so callsPerWeek is correctly respected during a partial reschedule. The agent's "subscriptions cluster in week 1" claim was incorrect — week-by-week distribution is enforced by the for (let day... && callsThisWeek < callsPerWeek) pattern at line 1102.
• schedulingPeriodStartsAt is enforced during auto-allocation (line 1119: slotTime < startDate → continue). The agent's "period boundaries only used for post-hoc validation" claim was wrong.
• Cross-event-type occupancy: buildOccupiedAppointmentFilter() in occupancyPolicy.ts:44-101 covers all 5 event-type ↔ 5 event-type pairs via event-level status filters (consultation, subscription, webinar, class, trial). Webinar/class hosts are correctly blocked from being booked into concurrent consultations because user.some.id = consultantUserId matches the host in the M2M — verified by tracing the filter through SlotValidationService.ts:250.
• Date-range sanity check on scheduling period exists at SlotAllocationService.ts:1795-1802 (startsAt >= endsAt throws AllocationValidationError). Good.

---

Already tracked — status check only

Finding from this pass	Where tracked	Comment
Tentative TTL 30-min (docs) vs 7-day (cron)	#676 C1 (this issue)	Already captured.
getTimezoneOffsetMinutes heuristic at slotTimeUtils.ts:307-326	#503 item 1	Use date-fns-tz — status: open.
24-hour reschedule window uses UTC ms, not local clock hours	#503 item 7	Already flagged; CA-decision on business intent still pending.
Calendar per-request, no materialisation / caching	#309	Slot-availability API optimisation.
Reschedule notifications / audit / UX	#448	Handles the deletedAppointmentIds adjacency in AE-4 from the notification side.
DST consolidation (isOvernightUTC triple-representation, custom midnight crossing, month overflow)	#503 items 2-6
DB-level exclusion for consultant slot overlap	#440	AE-1 and AE-2 both become easier to express once this lands.

---

Areas I triaged but couldn't verify in this pass

Flagging honestly rather than asserting:

• Auto-allocation when consultant has fragmented availability (e.g. 1.5-hour session but only non-adjacent 30-min windows). findAvailableSlots at SlotAllocationService.ts:1126-1140 requires a consecutive block; if unsatisfiable, it throws "No {N} consecutive slots available". UX is harsh — product-level decision on whether to warn at plan creation time instead.
• Min-notice / lead-time enforcement in manual allocate. Routes accept consultant-provided slots; couldn't find a consultant-profile-level minimumNoticeInHours field in the schema. Could be an entirely missing feature or a business rule enforced client-side only — needs product clarification.
• Class enrolment after initial allocation. reconnectEnrolledUsers (line 1413) runs during re-allocation; whether a separate enrollment API adds new users to existing SlotOfAppointment.user[] links on an already-scheduled class is outside this audit's scope and worth a focused check.
• Free-trial session counting in SlotCalculationService.calculateRequiredSlots — whether the trial consumes one of callsPerWeek × totalWeeks or is free on top. Product decision, not a code correctness gap.

---

Agent claims I disproved during verification

For transparency (same pattern as the main audit):

Claim	Reality
"Auto-allocate is greedy first-fit and clusters all calls in week 1"	Line 1102 enforces callsThisWeek < callsPerWeek per week, then advances the week pointer. Distribution across weeks is the default behaviour.
"schedulingPeriodStartsAt is only used for post-hoc validation, slots may be allocated in the past"	Line 1119 rejects slotTime < startDate inside the main allocation loop.
"Tentative-slot TTL mismatch (7d vs 30 min)"	Already captured here as C1; not a new finding.
"getTimezoneOffsetMinutes heuristic unreliable for DST"	Already captured in #503 item 1.
"24-hour reschedule window uses UTC ms instead of local clock-hours"	Already captured in #503 item 7.

---

Scorecard update

Given AE-1 (consultee double-booking) and AE-2 (collaborator availability) land directly on booking correctness, I'd adjust the booking-subsystem dimension "Functional correctness" from the original 80% down to ~76% until both are fixed. Everything else in the top-level scorecard still stands. The overall readiness estimate of ~75% holds.

Updated roadmap insert — Phase 3 additions

Into the Phase 3 (Observability & UX, ~3d) block of the top-level roadmap, add:

• AE-1: thread consulteeUserId into SlotValidationService.validate() and extend the conflict query with a second user.some.id branch.
• AE-2: widen fetchEventData's "class" include to load ACCEPTED collaborators; fan-out occupancy checks.
• AE-4: widen AllocationResult with deletedAppointmentIds.
• AE-3 / AE-5: decision items (use the field vs drop; lock the validator to a 30-min constant vs keep parametric).

/cc picking up in the Phase 3 PR for this tracker.

[teetangh]

Round 3 deep-dive — Concurrency & locking (CN-series)

Following the AE-series addendum, ran a deeper pass over Redis lock lifecycle, lock-vs-transaction timing, and the Redis-counter-vs-DB-count-vs-Waitlist three-way capacity story. Every claim below verified against source.

---

TL;DR

• CN-1 (P0): appointmentlock.ts bypasses the existing withCircuitBreaker() pattern — during a Redis partition, lockEventCheckout masks the unavailability error as a contention message, failing open.
• CN-2 (P0): extendLock() is defined at utils/appointmentlock.ts:226 but has zero production callers (grep-verified). The auto-allocate lock TTL = 150s covers the 120s tx; the event-checkout lock TTL = 60s with a 25s Serializable tx gives a nominal 35s buffer — safe in the happy path but lock cannot be extended if the tx stalls.
• CN-3 (P1): acquireEventSlot / releaseEventSlot / confirmEventSlot (Redis INCR semaphore) are dead code — defined but never imported outside their own file. Capacity is DB-only today; the Lua semaphore exists as an unused third source of truth.
• CN-4 (P1): capacity re-check in checkout runs at lib/payments/operations/checkout.ts:1783-1784 (revalidateInsideLock), which is outside the Serializable prisma.$transaction() block that starts at line 1864. The Redis lock + Serializable isolation together mitigate, but the capacity read is not TOCTOU-safe inside the tx.
• CN-5 (P2): webhook after() dispatch at app/api/webhooks/razorpay/route.ts:156-160 vs DEFAULT_EVENT_SLOT_TTL = 300000ms (5 min) — since the event-slot semaphore is unused today (CN-3), this isn't a live bug, but if the semaphore is ever wired in, the 5-min TTL is too tight for delayed webhooks.

---

Verified findings

CN-1 (P0) — Redis partition fails open on lockEventCheckout

File: utils/appointmentlock.ts:376-389, :84-158 (acquireLockWithRetry)
Verified: yes — grep confirms withCircuitBreaker is used in lib/redis.ts, lib/maintenance.ts, and scripts/stream/stream-sync.ts, but not in utils/appointmentlock.ts.

Code:

export async function lockEventCheckout(...) {
  try {
    return await acquireLockWithRetry(key, ttl);
  } catch (error) {
    throw new Error(
      `Another user is currently checking out this ${...}. Please try again in a few seconds.`,
    );
  }
}

Issue: any Redis error (network, Upstash REST timeout, TLS issue) inside acquireLockWithRetry is caught and rewritten as "another user is checking out". The caller cannot distinguish lock contention from Redis being down. The frontend treats this as transient and the user retries immediately — with no protective lock in place for either client.

Impact: during a Redis partition, two concurrent checkouts on a near-full webinar can both succeed → capacity exceeded. The DB-level Serializable tx doesn't save us because our capacity check is outside the tx (see CN-4).

Proposed fix:

1. Wrap lock operations in the existing withCircuitBreaker helper (already used in lib/redis.ts:269,307, lib/maintenance.ts:43).
2. On circuit-open, propagate a distinct error (ERR_LOCK_SERVICE_UNAVAILABLE) and have lockEventCheckout translate it to a 503 with "try again later" rather than 409-style contention.
3. Fail closed — reject checkout rather than proceed unlocked.

---

CN-2 (P0) — extendLock is never wired into a long transaction

File: utils/appointmentlock.ts:226 (definition), checkout tx at lib/payments/operations/checkout.ts:2052-2065, auto-allocate tx in SlotAllocationService.allocate.
Verified: yes — grep -rn "extendLock" {lib,app,utils,jobs,scripts}/**/*.ts returns only the definition. No production caller.

Current math:

• Event-checkout lock: TTL = 60000ms with driftFactor = 0.01 → effective 59 400 ms.
• Checkout tx timeout: 25000ms Serializable.
• Auto-allocate lock: TTL = 150000ms (appointmentlock.ts:726), with tx timeout 120000ms. This pair is correct — the 30s buffer is healthy.

The checkout pair is fine on the happy path (34s buffer), but there is no mechanism to save the lock if the tx stalls for > 35s (e.g., a slow Razorpay order creation inside the lock, or a GC pause under load). The defined extendLock helper solves this but is never called.

Impact: two failure modes:

1. Lock expires mid-tx → a second request acquires the same key → Serializable isolation normally prevents write conflict, but the Redis-lock-based capacity check (CN-4) is outside the tx, so the second request passes capacity validation using a stale view.
2. Attempts to release an expired lock hit the atomic Lua safe-release (line 169-179) correctly — good — but by that point the other request has already committed.

Proposed fix (two options, pick one):

1. Wire extendLock into long-running tx bodies — call extendLock(lock, 30000) via setInterval at ~50% of TTL, clearInterval in finally.
2. Simpler: raise event-checkout lock TTL to match the auto-allocate pattern (150s lock / 25s tx = 6× buffer).

Prefer (2) unless we see real evidence of contention — it's a 1-line change at appointmentlock.ts:726.

---

CN-3 (P1) — Redis event-slot semaphore is dead code

File: utils/appointmentlock.ts:415,502,566 (definitions of acquireEventSlot, releaseEventSlot, confirmEventSlot)
Verified: yes — grep -rn "acquireEventSlot|releaseEventSlot|confirmEventSlot" across {lib,app,utils,jobs,scripts}/**/*.ts returns only the three definitions. No importer.

The Lua-backed INCR semaphore (designed to be the hot-path capacity counter for webinar/class checkout) is fully implemented (lines 415-600-ish) but nothing ever calls it. Capacity enforcement today relies entirely on the DB via countWebinarParticipants / countUniqueParticipants in lib/payments/utils/participants.ts, which is correct inside a Serializable tx but not an effective hot-path throttle.

Impact: the doc at docs/booking/12-concurrency-and-locking.md promises a "3-layer concurrency model (Redis semaphore + Prisma tx + validation)". Layer 1 doesn't exist in production. For webinar/class paths, only the event-checkout lock + Serializable tx actually constrain concurrency. At 500+ concurrent checkout attempts for a hot webinar, the DB is the only backpressure.

Proposed fix (pick one):

1. Wire the semaphore: call acquireEventSlot inside checkout before the lock; confirmEventSlot on payment success; releaseEventSlot on failure / cleanup. This needs reconciliation with the DB count (Redis is source of truth for "in-flight", DB for "final"). Requires updating cleanup-abandoned-payments to decrement. ~1 day.
2. Delete the dead code and update the concurrency doc to admit we rely on Serializable + lock. Honest, cheaper, loses the hot-path protection.

My vote: delete unless there's a measurable capacity-contention problem. #476 (cron distributed lock) is a more pressing lock gap than this.

---

CN-4 (P1) — capacity re-check is outside the Serializable transaction

File: lib/payments/operations/checkout.ts:1783-1784 (revalidateInsideLock call), :1864 (tx start)
Verified: yes — the await revalidateInsideLock(...) call is 80 lines above the prisma.$transaction( call. Between them is payment-intent creation (+80 lines).

// STEP 3: RE-VALIDATE INSIDE LOCK (critical for preventing TOCTOU race conditions)
await revalidateInsideLock(validatedData, userId);                // ← capacity check here
// ...
// STEP 4: Create payment intent
// ...
// STEP 5: Create tentative appointment + payment record (INSIDE LOCK)
try {
  const result = await prisma.$transaction(
    async (tx) => { ... },                                        // ← tx starts here
    { timeout: 25000, isolationLevel: Prisma.TransactionIsolationLevel.Serializable }
  );
}

Issue: the window between capacity read and tx commit is roughly "payment-intent creation time" (100-400ms for Razorpay order creation over network). During that window, another checkout holding a different slot-based lock but the same event can pass its own capacity read. The event-checkout lock should prevent this for event-based lock types, but slot-based checkouts (lockType === "slot-based" for consultations/subscriptions with specific slot times) don't share the event lock with webinar/class checkouts. If a webinar host also sells 1:1 consultations, the two lock types don't mutex.

Impact: rare in practice (requires a consultant hosting both event-level and slot-level products simultaneously being near capacity on the event), but real — the Serializable isolation prevents phantom writes, not phantom reads.

Proposed fix: move the capacity re-check inside the $transaction body. For webinars/classes, re-query countWebinarParticipants(...) from the tx handle before doing the user-connect. Increases tx duration by one query (<10ms) but closes the TOCTOU.

---

P2 follow-ups

CN-5 (P2) — webhook async TTL vs event-slot reservation

File: app/api/webhooks/razorpay/route.ts:156-160, utils/appointmentlock.ts:52 (DEFAULT_EVENT_SLOT_TTL = 300000)

Note: this only matters if CN-3's semaphore is ever wired in. Today it's dead code. If wired: 5 minutes is too short for a delayed Razorpay retry, and there's no reconciliation cron for orphaned event-reservation:* keys. Fix: extend TTL to 15 minutes + add an orphan-reservation sweep to the reconcile-* cron family.

---

Already tracked — not restated

• Cron distributed locking — [RESILIENCE] Distributed locking for cron jobs #476. Broader problem than this audit; 16 payment + 10 appointment crons lack per-job locks.
• Prisma P2002 → LOCK_CONTENTION 409 mapping at SlotAllocationService.ts:120-128 is clean — good pattern.

---

What's working well

• Lua safe-release: appointmentlock.ts:169-179 uses atomic check-then-delete — prevents ABA (one client releasing another's lock after TTL-reacquire). Correct and stress-tested.
• Drift factor: 1% applied at acquisition to absorb clock skew between Upstash and our servers.
• Serializable isolation: all checkout $transaction calls use Prisma.TransactionIsolationLevel.Serializable. Backup safety net under CN-4.
• Auto-allocate lock (150s) / tx (120s) ratio: correct — the 30s buffer is exactly the extendLock-less hedge we want.

---

Agent claims I downgraded or rejected during verification

Claim	Reality
"Handshake race between validate and allocate" (event-reservation TTL perspective)	Rejected — the semaphore is dead code (CN-3), so no live race. Recategorised as CN-5 P2 if ever wired in.
"markWaitlistAsBooked doesn't decrement the semaphore"	Correct but a non-issue for the same reason — no semaphore to decrement. Agent-4 Finding 3 also softened.
"3-source-of-truth capacity drift"	Downgraded — in current code there are only 2 sources: Waitlist status and DB countWebinarParticipants. Redis counter is defined but never written.

---

Scorecard impact

"Concurrency / locking" dimension adjusts:

• Before: 75% (cron lock + versioning noted as blockers).
• After: 68% until CN-1 (fail-closed) and CN-4 (in-tx capacity check) ship. CN-2 (TTL buffer) is a 1-line config raise; CN-3 should be decided (wire it or delete it) before [RESILIENCE] Distributed locking for cron jobs #476 closes.

Next two comments in this thread

Calendar-rendering path, then recurring-expansion + validate-divergence + scheduling-period edges. Trials/waitlist/authz + scorecard consolidation after that.

[teetangh]

Round 3 deep-dive — Calendar rendering path (CA-series)

Second comment in the sequence. Focus: public availability routes, useCalendarData-adjacent hooks, server-calculated BookingStatus, and cross-timezone display. Some agent claims overlapped with AE-1 (consultee double-booking) and CN-4 (capacity in-tx); those are not restated.

---

TL;DR

• CA-1 (P1): SlotOfAvailabilityCustom (prisma/schema.prisma:1313-1325) has only @@index([consultantProfileId]). Range queries on startsAt/endsAt in app/api/slots/availability-with-allocation/[consultantId]/route.ts do a seq scan per consultant — fine at 10 rows, quadratic at 500+.
• CA-2 (P2): useCalendarData (consultant dashboard hook) never passes timezone to AllocationService.fetchAvailabilitySlots. Severity limited because this hook is consultant-side; the consultee booking path reads tz server-side from Intl.DateTimeFormat. Still a cache-consistency risk if a consultant laptop crosses TZ.
• CA-3 (P2): availability routes have no unstable_cache, no Redis layer, and no Cache-Control header. High-traffic consultants re-compute the same slot universe per request.
• CA-4 (P2): removeBookedSlots in app/api/slots/availability/[consultantId]/route.ts uses startsAt: { in: [...100 ISO timestamps] }. Works but fragile — prefer a gte/lte range with the composite index from CA-1.
• CA-5 (P3): getDayOfWeek uses date.getUTCDay() inside a path that's already toZonedTime-shifted. Consistent internally today; a footgun for a future reader.

Cross-ref: #309 (broader slot-availability optimisation umbrella). This comment narrows CA-1 to a specific missing index that would unblock most of #309's impact.

---

Verified findings

CA-1 (P1) — missing range index on SlotOfAvailabilityCustom

File: prisma/schema.prisma:1313-1325
Verified: yes — read the model; only @@index([consultantProfileId]) is present.

model SlotOfAvailabilityCustom {
  id       String   @id @default(uuid())
  startsAt DateTime @db.Timestamptz
  endsAt   DateTime @db.Timestamptz
  consultantProfileId String
  // ...
  @@index([consultantProfileId])          // only this
}

Callers filter on startsAt/endsAt range + consultantProfileId:

where: { consultantProfileId, startsAt: { gte: start, lt: end }, endsAt: { gt: start, lte: end } }

Postgres will use the consultantProfileId B-tree to filter rows, then seq-scan the range predicates. Cost scales with the number of custom slots per consultant (travel windows, one-off sessions). At 500+ rows per consultant × 100 req/s from the availability endpoint, the numbers add up quickly.

Proposed fix:

model SlotOfAvailabilityCustom {
  // ...
  @@index([consultantProfileId])
  @@index([consultantProfileId, startsAt, endsAt])  // new
}

One additive migration. No data migration needed.

---

CA-2 (P2) — useCalendarData doesn't key on timezone

File: app/dashboard/consultant/[consultantId]/(features)/shared/hooks/useCalendarData.ts:247-270
Verified: yes — read the hook. fetchAvailabilitySlots(consultantId, startDate, endDate) is called without a timezone arg. The underlying AllocationService.fetchAvailabilitySlots resolves timezone via Intl.DateTimeFormat().resolvedOptions().timeZone on the client.

Scope caveat: this is the consultant-dashboard hook, so the practical blast radius is limited — it's the consultant viewing their own calendar. The consultee-facing public availability route (app/api/slots/availability/[consultantId]/route.ts) reads tz from the request and does its own conversions server-side (toZonedTime at line 43). So no cross-user data leak.

Remaining issue: if a consultant flies IST → PST and their browser's Intl.DateTimeFormat flips, the hook may serve cached data from the previous timezone. The fetch isn't idempotent across the timezone boundary.

Proposed fix: pass timezone explicitly:

const tz = typeof Intl !== "undefined"
  ? Intl.DateTimeFormat().resolvedOptions().timeZone
  : "UTC";
const data = await AllocationService.fetchAvailabilitySlots(
  consultantId, startDate, endDate, tz
);

And include tz in the React Query key (if ever swapped off useCallback).

P2, not P1 — consultant-only hook.

---

CA-3 (P2) — no cache layer on availability routes

Files: app/api/slots/availability/[consultantId]/route.ts, app/api/slots/availability-with-allocation/[consultantId]/route.ts
Verified: yes — neither file uses unstable_cache, revalidateTag, or sets Cache-Control. Every GET recomputes the slot universe from scratch.

Worst case: a popular consultant viewed by 1000 consultees simultaneously over the same 2-week window triggers 1000 independent recomputations × 2-3 queries × 50-200ms each. The DB absorbs most of it; Netlify function cold starts compound it.

Proposed fix (this is the first concrete lever on #309):

1. unstable_cache-wrap the availability route body keyed on (consultantId, weekStart, timezone).
2. revalidate: 300 (5 minutes) + revalidateTag('availability').
3. Call revalidateTag('availability') from booking-create / booking-cancel side effects. Tag invalidation is server-wide, so one booking busts the lookup for all viewers — acceptable for a 5-min window.

Complements CA-1 (once indexed, cache miss is cheaper).

---

CA-4 (P2) — IN (...) filter instead of range

File: app/api/slots/availability/[consultantId]/route.ts:147-184
Verified: yes — prisma.appointment.findMany({ where: { slotsOfAppointment: { some: { startsAt: { in: slots.map(...) } } } } }).

The IN variant works correctly and hits the existing [startsAt, endsAt] index at schema.prisma:1996. But:

1. The Prisma-generated SQL includes all 100 parsed timestamps in the IN-list, which inflates the query plan cache.
2. A range (gte/lt) of [earliest, latest + slotDuration] would produce one stable query shape regardless of which specific timestamps are in scope.

Proposed fix:

const earliest = slots[0].slotStartTimeInUTC;
const latest = slots[slots.length - 1].slotStartTimeInUTC;
const appointments = await prisma.appointment.findMany({
  where: {
    slotsOfAppointment: {
      some: {
        startsAt: { gte: new Date(earliest), lte: new Date(latest) },
        user: { some: { id: consultantUserId } },
      },
    },
  },
  include: { slotsOfAppointment: { select: { startsAt: true } } },
});

Then do the exact-match filter in JS (it's already done downstream).

---

CA-5 (P3) — getDayOfWeek(date) uses getUTCDay

File: app/api/slots/availability/[consultantId]/route.ts:201-226
Verified: yes.

function getDayOfWeek(date: Date): DayOfWeek {
  const days = ["SUNDAY", ...];
  return days[date.getUTCDay()];
}

Called at line 283 with a userDate that has already been toZonedTime-converted at line 43. Because toZonedTime returns a Date whose UTC internals are shifted to represent the zoned time, getUTCDay() on the shifted Date returns the zoned day-of-week. That's actually correct by accident — the UTC call matches the zoned semantics of the converted Date.

But it's a footgun: a future reader who un-shifts the Date (or removes the toZonedTime wrapper) breaks the day math silently. Prefer format(userDate, "EEEE", { timeZone }) from date-fns-tz or an explicit comment.

---

P0/P1 claims from the agent that didn't land (for transparency)

Agent claim	My verdict
"P1 Race condition between display and booking — no version/etag"	Real concern, but already covered by AE-1 (consultee-side check) and CN-4 (in-tx capacity). Adding etag/version on the availability response doesn't fix either. Skipping.
"P1 Tentative slots counted in BookingStatus, blocking availability"	Partial — OCCUPIED_REQUEST_STATUSES includes PENDING and APPROVED_PENDING_PAYMENT, which is correct (tentative should block display). The only valid concern is when payment has expired but the event is still APPROVED_PENDING_PAYMENT — and SlotValidationService.ts:294-308 already handles that in the validator. The availability-with-allocation route doesn't replicate that check, so a stale tentative display persists until the cron sweeps. Noted as a narrow UX polish, not a finding.
"Week boundary computed in UTC instead of user TZ"	Not a correctness issue — intentional. Each user sees their own zoned week; the comparator is UTC-anchored. Closed.

---

Scorecard impact

Nothing in this set moves the top-line booking readiness. CA-1 (index) buys maybe 1-2 percentage points in the "Test coverage for booking flow" dimension once paired with a pg_stat check. CA-3 (cache) is a prerequisite for #309 rather than a standalone move.

Next comment: recurring expansion + validate-vs-allocate + scheduling-period edges.

[teetangh]

Round 3 deep-dive — Recurring expansion + validate-vs-allocate + scheduling-period (RV-series)

Third comment. Focus: recurring-event expansion horizon and storage, validate-vs-allocate filter consistency, and scheduling-period boundary semantics. All findings verified against source.

---

TL;DR

• RV-1 (P1): recurring events materialise all appointments up-front. A 24-month subscription with callsPerWeek=4 + 1-hour sessions = ~768 SlotOfAppointment rows per subscription. At 10k active subscriptions, that's ~7.7M rows with no archival story.
• RV-2 (P1): SlotAllocationService.findAvailableSlots does NOT honour the payment-expired mitigation that SlotValidationService.validateNoConflicts applies (:294-308). Validate can say "the tentative blocker expired, you're good" while allocate sees the same row and finds no free slots → inconsistent outcomes between /validate and /allocate on the same event.
• RV-3 (P2): no edit-single-instance API. Partial reschedule (tentative N of M) works; targeted "move session 7 only" doesn't exist — callers must re-allocate the tentative set.
• RV-4 (P2): validate-route response shape diverges by event type — subscription returns extra subscriptionValidation {...}, class returns extra weeklyDistributionErrors[], consultation/webinar return neither. Callable but the client has to special-case.
• RV-5 (P2): class validation doesn't factor in existing confirmed slots during partial reschedule — while the allocator does (SlotAllocationService.ts:1073-1088). Validate can green-light a weekly-limit-exceeding reschedule that the allocator then rejects.

---

Verified findings

RV-1 (P1) — no horizon cap on recurring expansion, no archival

File: utils/slotAllocation/SlotAllocationService.ts:1329-1405 (createAppointments), :1060-1190 (findAvailableSlots recurring loop)
Verified: yes — the recurring path loops weeks from config.schedulingPeriodStartsAt to endsAt and creates one Appointment per call, each with 1-N SlotOfAppointment rows depending on sessionDurationInHours / 0.5.

Math at common configs:

• Subscription durationInMonths=12, callsPerWeek=2, sessionDurationInHours=1 → ~52 weeks × 2 × 2 slots = 208 rows per subscription.
• Subscription durationInMonths=24, callsPerWeek=4, sessionDurationInHours=1 → ~104 × 4 × 2 = 832 rows.
• Class durationInMonths=12, meetingsPerWeek=3 with 30 enrollees → 52 × 3 × 2 slots = 312 slots, each joined to 30 users via the implicit M2M → 9 360 join rows per class.

No schema field anywhere records "this sub has been materialised to date X" so a 24-month run-rate × 10k subscriptions × co-joined class users is unbounded growth with no retention / archival / tiered-storage plan.

Proposed fix (phased):

1. Add deletedAt DateTime? @db.Timestamptz + @@index([deletedAt]) to SlotOfAppointment (already listed as A10 in this tracker).
2. New cron: 90 days after completedAt, soft-delete the slot. Update occupancy filter to deletedAt IS NULL.
3. Longer term: cap auto-allocation horizon at 90 days ahead and re-extend on a rolling basis (lazy materialisation). Existing partial-reschedule code at SlotAllocationService.ts:1072-1088 already tracks "existing calls this week", so the accounting holds.

A10 alone isn't enough without the horizon cap — soft-delete just reclaims past rows.

---

RV-2 (P1) — validate / allocate divergence on expired APPROVED_PENDING_PAYMENT

Files: mitigation in utils/slotAllocation/SlotValidationService.ts:294-308; allocation conflict read in utils/slotAllocation/SlotAllocationService.ts:893-931
Verified: yes — SlotValidationService.validateNoConflicts explicitly special-cases a blocker whose parent event is APPROVED_PENDING_PAYMENT with an expired payment and treats the slot as free:

// SlotValidationService.ts:294-308 — paraphrased
if (pendingStatus === RequestStatus.APPROVED_PENDING_PAYMENT) {
  const payment = existingAppointment.payment?.[0];
  if (payment?.expiresAt && new Date(payment.expiresAt) < new Date()) {
    continue;  // skip this conflict → slot is actually free
  }
}

SlotAllocationService.findAvailableSlots reads the same buildOccupiedAppointmentFilter() set but does not apply the payment-expiry check when assembling bookedSlots. Net effect: /validate can return "OK" (slot free because blocker's payment expired), user confirms, /allocate sees the same row as still occupied (because no expiry check), returns "no consecutive slots available."

Impact: users see a confusing "validation passed but allocation failed" error. Not a data-corruption bug — just UX + wasted Razorpay order creation (which happens between validate and allocate).

Proposed fix: extract the expiry-check logic into a shared helper (e.g., utils/slotAllocation/isOccupiedByLiveAppointment.ts) and apply it in both places. Or, simpler: the abandoned-payments / expire-stale-requests cron should flip such events out of APPROVED_PENDING_PAYMENT more aggressively — then the filter itself already excludes them.

---

P2 follow-ups

RV-3 (P2) — no single-instance edit API

File: utils/slotAllocation/SlotAllocationService.ts:1436-1507 (deleteExistingAppointments)
Verified: yes — onlyTentative: true path deletes all tentative slots, not a specific ID.

Today's reschedule contract: "mark N slots tentative, re-allocate" is atomic-ish but all-or-nothing on the tentative set. A user who wants to move a single session 7 has to re-trigger allocation for all tentative slots, which in practice means the whole remaining sub unless manually staged.

Proposed fix (breaking API change — punt to a future release):

• Accept sessionNumbersToReschedule?: number[] on the allocate route.
• In findAvailableSlots, respect already-confirmed adjacent slots and avoid reshuffling them.
• Cross-ref Reschedule Flow: Missing notifications, no audit trail, staff/admin blind spots, and UX gaps #448 (reschedule UX) — worth folding in there.

RV-4 (P2) — validate response shape drift across event types

Files: app/api/events/{consultations,subscriptions,webinars,classes}/[id]/validate/route.ts
Verified: yes.

• Subscription validate returns { conflicts, outsideAvailability, validSlots, subscriptionValidation: { weeklyInfo, totalCallsScheduled, totalRequired } }.
• Class validate returns { ..., weeklyDistributionErrors[] }.
• Consultation and webinar validate return only { conflicts, outsideAvailability, validSlots }.

Proposed fix: canonicalise the response interface in utils/slotAllocation/types.ts with the extras as optional discriminated-union fields. One touch point for future event types. Minor client refactor.

RV-5 (P2) — class validate ignores existing confirmed slots in weekly-limit check

File: utils/slotAllocation/SlotValidationService.ts:771-865 (validateClass)
Verified: yes — grouping at lines ~851-858 counts only proposed slots. Compare to SlotAllocationService.ts:1073-1088 where the allocator correctly initialises callsThisWeek from existing non-tentative appointments.

Scenario: a class with meetingsPerWeek=2 has 1 confirmed session in week 3. User submits a reschedule proposing 2 new slots in week 3. Validator sees 2 proposed ≤ 2 limit = true. Allocator sees 1 existing + 2 proposed = 3 > 2, throws. Same false-positive on validate as RV-2.

Proposed fix: pass excludeAppointmentIds to validateClass (mirroring how subscription validation already does) and factor existing confirmed slots into the weekly count.

RV-6 (P2) — slot duration constant is parametric but only 30 works

Files: utils/slotAllocation/SlotValidationService.ts:80, utils/slotAllocation/SlotAllocationService.ts:856
Verified: yes — earlier addendum flagged this as AE-5. Restating under RV only because it shows up in every recurring path.

RV-7 (P2) — leap-year / month-boundary test coverage

File: utils/slotAllocation/SlotCalculationService.ts:29-47 (countWeeks)
Verified: the math is correct (UTC-anchored, Sunday-start), but __tests__/booking-algorithm/ does not have explicit Feb 28 / 29 cases per grep. Low risk; add tests in the #545 CI-gate PR.

---

Claims I verified as NOT issues

Agent claim	Reality
"schedulingPeriodStartsAt in the past allocates slots in 2024"	No — SlotAllocationService.ts:1118 already short-circuits slotTime < now, and line 1061 defaults startDate to new Date() when the stored value is in the past. Display side is a separate question.
"Boundary exclusivity ambiguity (slotEnd > endDate)"	The validator uses end-exclusive, allocator uses start-exclusive — semantically consistent for half-open [start, end) intervals, which is the industry norm. No real ambiguity; just worth a comment in the code.
"Payment-expired asymmetry between validate and allocate" (different phrasing)	Collapsed into RV-2 above — one finding, not two.

---

Scorecard impact

• Data integrity (schema constraints): no change — RV-1 is orthogonal (addresses growth, not constraint correctness).
• Functional correctness: already at 76% after AE-1/AE-2. RV-2 takes it to 74% until the shared expired-payment helper ships. RV-5 stays at P2 (rare edge).
• New dimension worth tracking: "Storage / retention strategy" — currently unmeasured; RV-1 is the anchor finding.

Next comment: trials + waitlist + attendee M2M + authz.

[teetangh]

Round 3 deep-dive — Trials, waitlist, attendee M2M, authz (TW-series)

Fourth and final findings-comment in this sequence. Scorecard update posted next.

---

TL;DR

• TW-1 (P2): trial rejection (TrialSessionStatus.REJECTED) fires the notification but writes no ActivityLog entry — ACTIVITY_TYPE TRIAL_REJECTED doesn't exist. Every other trial transition has one.
• TW-2 (P2): @@unique([consulteeProfileId, consultantProfileId]) on TrialSession is bypassable via account delete + recreate — user-lifecycle gap, not a schema bug. Cross-ref User Lifecycle Robustness: Account deletion, recreation, spam prevention, and cleanup gaps #405.
• TW-3 (P2): authorizeEventAccess (lib/auth-helpers.ts:177-264) doesn't have an org-admin code path. Org admins of Org A cannot allocate on behalf of a consultant in Org A unless they're isPrivileged (platform admin/staff). Cross-ref design: personal vs organization scope across every feature — direction A (filter) vs direction B (split) #674 / design: org-creation governance — require signup intent, domain verification, and remove self-serve from consultee/consultant dashboards #675.
• VERIFIED GOOD: both waitlist expiry cron (scripts/waitlist/process-expired-notifications.ts — hourly via .github/workflows/process-waitlist-expirations.yml) and 12-hour reminder cron (scripts/waitlist/send-expiration-reminders.ts) exist. The "lazy-expiry-only" concern is unfounded.
• VERIFIED GOOD: cross-plan trial conversion is guarded — app/api/trials/[trialId]/route.ts:546-557 rejects when subscription.subscriptionPlanId !== existingTrial.subscriptionPlanId. Agent flagged this as an open question; source says it's already closed.

---

Verified findings

TW-1 (P2) — trial rejection has no activity-log entry

File: app/api/trials/[trialId]/route.ts:476-515
Verified: yes — the branch handling CANCELLED / REJECTED calls notifyTrialSessionCancelled and deletes the linked appointment, but does not call any logTrial* helper. Compare to the COMPLETED branch (lines ~450-474) which fires logTrialCompleted, and the CONVERTED branch (lines 518+) which fires logTrialConverted.

Schema-side: no TRIAL_REJECTED value exists in the ActivityType enum in prisma/schema.prisma. The existing values include TRIAL_COMPLETED and TRIAL_CONVERTED but no rejection equivalent.

Impact: consultant analytics ("trial acceptance rate", "time-to-reject") are skewed — every rejection is invisible in the activity stream. Cancellations by consultee are also lumped in with rejections by consultant, so the activityType alone doesn't distinguish them.

Proposed fix:

1. Add two enum values to ActivityType: TRIAL_REJECTED (consultant-declined) and TRIAL_CANCELLED_BY_CONSULTEE.
2. Add logTrialRejected / logTrialCancelled helpers next to logTrialCompleted.
3. In the status-transition branch, pick the right logger based on the session actor (consultant vs consultee), available via the existing PATCH authz check.
4. Also fixes doc-drift C3 (rejection path actor / notification not specified).

Severity P2, not P1 — this is an analytics / audit-trail gap, not a correctness bug.

---

TW-2 (P2) — one-trial-per-pair bypassable via account deletion

File: prisma/schema.prisma:1520 (the @@unique([consulteeProfileId, consultantProfileId])); user-lifecycle paths across app/api/auth + app/api/user.
Verified: yes — the schema constraint is correct for the (consulteeProfileId, consultantProfileId) pair, but consulteeProfileId is not a stable identity across account re-creation. Cross-ref #405 (user lifecycle robustness).

Impact: a user who wants a second free trial with the same consultant can (a) delete their account, (b) re-register with a fresh email, (c) request another trial. The consultant receives what looks like a new consultee's trial request.

Proposed fix (out of scope for this tracker — defer to #405):

• Persistent trial-history per User.email hash or per verified phone number.
• Or: move the constraint up one level to (userEmailHash, consultantProfileId).

Listing here for cross-reference only.

---

TW-3 (P2) — authorizeEventAccess has no org-admin path

File: lib/auth-helpers.ts:177-264
Verified: yes — the function checks consultantProfileId === event.plan.consultantProfileId (lines 199, 212, 224, 245) and consulteeProfileId === event.requestedById (lines 200, 213). The only bypass is isPrivileged(session.user.role) (line 182), which maps to platform ADMIN / STAFF.

What the agent claimed: "Staff of Org A (Alice) can POST allocate for consultant in Org B (Bob)." I disproved this — Alice's session.user.consultantProfileId is her own, not Bob's, so the equality check on line 199/212/224/245 fails. No horizontal privilege-escalation risk across orgs.

What's actually missing: an org admin of Org A who is not a platform admin cannot allocate for consultants in Org A. They have to either be themselves the consultant or be marked isPrivileged. For enterprise features (#674, #675 — org scoping, org governance), this needs a third authorization path: "session user is ACTIVE admin-role OrganizationMember of the same OrganizationProfile as the event's plan.consultantProfileId's org membership."

Proposed fix: add an org-admin branch to authorizeEventAccess:

// After the existing consultant/consultee checks:
if (!isAuthorized && consultantProfileId) {
  const ownerOrgMember = await prisma.organizationMemberProfile.findFirst({
    where: { consultantProfileId: eventConsultantProfileId },
    select: { organizationProfileId: true },
  });
  if (ownerOrgMember?.organizationProfileId) {
    const callerMember = await prisma.organizationMemberProfile.findFirst({
      where: {
        userId: session.user.id,
        organizationProfileId: ownerOrgMember.organizationProfileId,
        role: { in: ["OWNER", "ADMIN"] },
        status: "ACTIVE",
      },
    });
    isAuthorized = !!callerMember;
  }
}

Severity P2, not P1 — no current security hole, just an enterprise-feature gap.

---

Previously tracked — not restated here

• SlotOfAppointment.user[] implicit M2M — already A9 in the master tracker. Agent finding (feat) - ZegoCloud video conferencing #7 just restates A9.
• Redis event-slot semaphore not decremented on booking — already covered in the CN-series comment (CN-3: the semaphore is dead code today).
• Tentative TTL 30-min vs 7-day mismatch — doc drift C1.

---

What's working well (not reducing severity — explicit credit)

• Waitlist expiration cron at scripts/waitlist/process-expired-notifications.ts runs hourly via .github/workflows/process-waitlist-expirations.yml (cron 5 * * * *). Iterates WaitlistStatus.NOTIFIED rows with expiresAt < now and flips to EXPIRED. Correct + idempotent.
• 12-hour reminder cron at scripts/waitlist/send-expiration-reminders.ts, triggered by .github/workflows/send-waitlist-reminders.yml (cron 30 * * * *). Filters by a 12-13h expiry window and marks reminderSentAt to avoid double-sends. Correct.
• Cross-plan trial-conversion guard at app/api/trials/[trialId]/route.ts:546-557 — verified.
• Waitlist updateMany + status guard (lib/waitlist/slot-handler.ts:70-84) — already noted in Round-1; remains correct.

---

Scorecard impact

• Observability / audit trail: was 70% (A8 + B4 + C3/C4/C6). TW-1 (no TRIAL_REJECTED log) adds one more gap → still 70%, but TW-1 becomes the fastest single fix to move it.
• Authorization: not previously scored as a separate dimension. Let's add it — ~85% with TW-3 as the only remaining P2 (no current vulnerabilities, just an enterprise-feature gap).

Final comment in this sequence next: consolidated scorecard update + roadmap insertion for the 16 new Round-3 findings.

[teetangh]

Round 3 consolidation — scorecard update + roadmap insertion

Fifth and final comment in this round. Reconciles CN-series + CA-series + RV-series + TW-series into the top-level scorecard and roadmap.

---

New findings by severity (Round 3 only)

Sev	Count	IDs
P0	2	CN-1 (Redis partition fails open), CN-2 (extendLock not wired into long tx)
P1	5	CN-3 (event-slot semaphore dead code), CN-4 (capacity re-check outside tx), CA-1 (missing composite index), RV-1 (no recurring horizon), RV-2 (validate/allocate expired-payment asymmetry)
P2	13	CN-5 · CA-2 · CA-3 · CA-4 · CA-5 · RV-3 · RV-4 · RV-5 · RV-6 · RV-7 · TW-1 · TW-2 · TW-3

Two of the P0s (CN-1, CN-2) fail open, which is why they're P0 — a Redis outage today quietly removes the only hot-path concurrency guard and we have no mechanism to hold the lock through a long tx. The P1s are each a single-file fix and should land in one sprint.

---

Updated per-dimension scorecard

Dimension	Was	Now	Δ	Blocker to higher
Functional correctness	80%	74%	−6	AE-1, AE-2, RV-2
Data integrity (schema constraints)	65%	65%	0	A1–A4, #440
Concurrency / locking	75%	60%	−15	CN-1, CN-2, CN-4, #476
Timezone / DST	70%	70%	0	#503 (unchanged)
Observability / audit trail	70%	70%	0	A8, B4, C3–C6, TW-1 (one more gap but same tier)
Documentation accuracy	85%	85%	0	C1–C8
Test coverage for booking flow	65%	65%	0	#545
NEW Storage / retention strategy	—	55%	—	RV-1 (no archival; no horizon cap)
NEW Authorization	—	85%	—	TW-3 (enterprise org-admin path)

Overall booking readiness

Was: ~75% → Now: ~70%.

The drop is not a regression — it's finding more of what was always there. With the CN-series in-hand, concurrency is now honestly scored. The Round-1 number was flattering.

---

Roadmap to 100% — updated

Phase 1 — Schema + refund + concurrency fail-safety (P0/P1, ~4d, was ~3d)

• A1–A4: CHECK constraints migration (unchanged).
• B1: refund two-phase reconciliation (unchanged).
• NEW CN-1: wrap appointmentlock.ts in withCircuitBreaker (already used in lib/redis.ts, lib/maintenance.ts). Fail closed on Redis partition. ~4h.
• NEW CN-2: raise event-checkout lock TTL from 60s → 150s at utils/appointmentlock.ts:726 (matches auto-allocate pattern). ~15min.
  • Or wire extendLock into long tx via heartbeat — heavier. Prefer TTL raise unless telemetry shows contention.
• Target: 78%.

Phase 2 — Concurrency depth + timezone (P1, ~5d, unchanged)

• [RESILIENCE] Distributed locking for cron jobs #476 cron distributed lock.
• Harden date/timezone handling — 7 high-risk areas (Option C) #503 items 1, 2, 6.
• Add DB-level exclusion constraint for consultant slot overlap prevention #440 exclusion constraint migration.
• NEW CN-4: move capacity re-check inside the Serializable tx body in lib/payments/operations/checkout.ts. ~1d.
• NEW RV-2: extract shared isOccupiedByLiveAppointment helper (payment-expiry-aware); call from both SlotAllocationService.findAvailableSlots and SlotValidationService.validateNoConflicts. ~0.5d.
• Target: 86%.

Phase 3 — Observability + UX (P1/P2, ~4d, was ~3d)

• Reschedule Flow: Missing notifications, no audit trail, staff/admin blind spots, and UX gaps #448 notifications + RescheduleLog.
• CancellationAuditLog (B4).
• feat: Adopt structured logging with Winston (replace console.* calls) #531 structured logging sweep for booking paths.
• A10 soft-delete on financial records.
• NEW TW-1: TRIAL_REJECTED / TRIAL_CANCELLED_BY_CONSULTEE activity-log entries (+ C3 doc patch lands in the same PR).
• NEW RV-5: thread existing-confirmed-call count into validateClass weekly-limit check.
• NEW RV-4: canonicalise validate-route response shape in types.ts.
• Target: 91%.

Phase 4 — Polish + retention + index (P2/P3, ~5d, was ~3d)

• A6–A9, A11 schema hardening.
• C1–C8 doc patches in one PR.
• ChatGPT-5.4 Codex: PR CI does not gate on booking concurrency or payment-failure lifecycle regressions #545 concurrency CI gate.
• NEW AE-1: thread consulteeUserId into SlotValidationService.validate().
• NEW AE-2: widen fetchEventData class branch to load ACCEPTED collaborators.
• NEW AE-4: widen AllocationResult with deletedAppointmentIds.
• NEW CA-1: @@index([consultantProfileId, startsAt, endsAt]) on SlotOfAvailabilityCustom.
• NEW CA-3: unstable_cache-wrap availability routes + tag-based invalidation on booking create/cancel.
• NEW RV-1 (phase 1 of 2): add deletedAt on SlotOfAppointment + 90-day-post-completion soft-delete cron.
• NEW TW-3: add org-admin branch to authorizeEventAccess (gated by design: personal vs organization scope across every feature — direction A (filter) vs direction B (split) #674 / design: org-creation governance — require signup intent, domain verification, and remove self-serve from consultee/consultant dashboards #675).
• Target: 97%.

Phase 5 — Decisions + verification (P2/P3, ~3d, was ~2d)

• NEW CN-3: decide — wire the Redis event-slot semaphore, or delete it (acquireEventSlot/releaseEventSlot/confirmEventSlot + the Lua script at utils/appointmentlock.ts:415-600). Recommend delete unless telemetry shows hot-event contention beyond what the event-checkout lock handles.
• NEW RV-1 (phase 2 of 2): recurring-expansion horizon cap (90 days rolling) + lazy extension cron.
• NEW CA-4: swap IN filter for range-based filter in removeBookedSlots.
• Tests: race + DST + webhook-replay + refund orphan + trial rejection log + per-event shape.
• Target: 100% subject to no new discoveries.

---

Expected scorecard after each phase

After	Was (Round-2 plan)	Now
Phase 1	82%	78%
Phase 2	89%	86%
Phase 3	94%	91%
Phase 4	98%	97%
Phase 5	100%	100%

Lower intermediate-phase numbers reflect the larger surface area surfaced in Round 3. End-state still 100%, just more work to get there.

---

Findings index (complete, all rounds)

Round 1 (master body): A1–A11, B1–B4, C1–C8, D-cross-refs.
Round 2 (comment #4264418448): AE-1 – AE-5.
Round 3 — this sequence:

• Concurrency: CN-1 – CN-5.
• Calendar: CA-1 – CA-5.
• Recurring / validate / period: RV-1 – RV-7.
• Trials / waitlist / M2M / authz: TW-1 – TW-3.
• This comment: scorecard consolidation.

---

Verification discipline (same pattern as Round 2)

Across all three rounds, 15 agent claims were disproved against source before they could land in public comments:

• Round 1: 5 (refund webhook missing, reschedule route missing, waitlist race, CANCELLED blocks bookings, slot overflow)
• Round 2: 5 (greedy clustering, schedulingPeriod ignored, three duplicates of already-tracked items)
• Round 3: 5 (markWaitlistAsBooked semaphore decrement, three-source-of-truth drift, getUTCDay off-by-one, cross-plan trial conversion unguarded, horizontal privilege escalation across orgs)

The Explore subagent is valuable for breadth but only trustworthy after spot-checking every P0/P1. The per-finding [TRIAGE NEEDED] convention worked well in Round 3 — every claim marked that way was downgraded or rejected on verification.

---

Closing note

This tracker now has ~40 catalogued findings across 6 severities. Ready for triage into sprint work. Phases 1 + 2 are the leverage — they move readiness from 70% to 86% in under 2 weeks, and both phases are dominated by schema / config changes with small blast radius.

Cross-ref sibling tracker #677 (payments) which picks up the payment/refund/payout/dispute/tax findings that surfaced during this round (e.g., the payments side of RV-2, and the Razorpay HMAC / idempotency analysis).