> ## Documentation Index
> Fetch the complete documentation index at: https://ihub.learnille.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Verify consultation rescheduling and rebooking

> Regression coverage and live acceptance checks for consultant prompts, replacement sessions, and repeat purchases

**Owner:** Backend Engineering and QA

**Last reviewed:** 2026-09-23

**Next review:** 2026-12-23

Use this checklist with the [lifecycle guide](https://ihub.learnille.com/engineering/architecture/consultation-rescheduling-and-rebooking.md)
to verify backend behavior and the integrated frontend journey.

## Automated regression checks

From the server repository, use Node 24 and pnpm 9.15.4:

```bash theme={null}
pnpm exec vitest run --config test/vitest.unit.config.ts src/consultation/sessions-reschedule.spec.ts src/order/consultation-rebooking.spec.ts src/consultation/consultation-rebooking.spec.ts
pnpm typecheck:ci
```

The last recorded implementation verification passed all 54 focused tests and the
full TypeScript check. The older cart/order suites had the same 41 failures before
and after the rebooking change; they are not a passing full-suite result. Rerun the
checks for the revision being released.

The focused tests use mocked external dependencies. They cover permissions, prompt
payloads, scheduling rules, free/paid paths, sequential duplicate payment processing,
approval, attendance reset, release scheduling, cart/direct repeat purchases, course
ownership protection, and separation of booking/enrollment/ledger records.

## Live test prerequisites

* Select a non-production Infisical environment with secrets path `/server` and
  confirm disposable student/consultant accounts, test notification recipients,
  and sandbox payment integrations. Do not record secret values in iHub.
* Deploy the relevant backend revision and run the required workers, database,
  queue, and notification integrations.
* Prepare a missed session with rescheduling enabled and an available replacement
  time, plus consultations covering free, paid, one-off, and recurring purchases.
* Record the tested revision/environment and evidence. Live checks below remain
  unverified until their actual results are recorded.

## Consultant prompt and rescheduling acceptance

* [ ] Owning consultant prompts a missed session; receive HTTP 201, actual email,
  and in-app notification with correct IDs and `SESSION_RESCHEDULE_REQUESTED`.
* [ ] Verify prompting leaves persisted session dates, status, attendance, and payment unchanged.
* [ ] Reject unauthenticated/unrelated callers, missing sessions, invalid UUIDs,
  non-missed sessions, cancelled bookings, disabled rescheduling, exhausted limits,
  and pending reschedule payments. Surface notification-trigger failures.
* [ ] Student opens the notification, selects a future available time, and submits
  rescheduling. Verify replacement-time notice for missed sessions, cooldowns, and
  rejection of past/unavailable times and unauthorized callers.
* [ ] Free rescheduling persists `rescheduled` and replacement dates, clears
  attendance, and replaces reminder/status/finalization jobs.
* [ ] Paid rescheduling retains old dates until sandbox payment is confirmed by
  the backend. Replay the payment callback and inspect for duplicate effects.
* [ ] Owning consultant/admin approval produces `scheduled` and the student notification.
* [ ] Both parties join the replacement session. Completion and worker execution
  update attendance/status and schedule the original ledger entry's release after
  the hold. Inspect actual release separately; scheduling release is not settlement.

## Rebooking acceptance

* [ ] For a previously purchased consultation, enrollment check permits purchase
  through `canPurchase`, including when `isEnrolled` remains true. Verify all frontend
  booking/checkout gates use `canPurchase`.
* [ ] Purchase the same consultation again at a new time through both direct and
  cart checkout, including an existing active booking and a completed booking.
* [ ] Verify current price and new payment reference; after payment processing,
  inspect separate order, enrollment, booking, sessions, and ledger entries.
* [ ] Verify the earlier booking, session dates, enrollment links, and payments
  are unchanged, and each new session links to its own order's enrollment.
* [ ] Cover a zero-total purchase and a recurring purchase with a fresh session set.
* [ ] Recheck a cart slot taken after insertion; checkout must reject it. Retain
  unavailable-slot, inactive-product, self-booking, duplicate-cart-entry, and
  duplicate-course-purchase restrictions.
* [ ] Replay fulfillment for the same order item; no duplicate booking or credit
  may be created. A second purchase uses a different order item.

## Record the result

For each run, record revision, environment, date, test-account identifiers, pass/fail
per case, and sanitized evidence or bug references. Keep tokens, secrets, and customer
personal information out of screenshots and logs attached to the result.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.