NextChair/docs/phase-6-summary.md

Phase 6 — Owner Administration: Summary

The complete owner administration experience, in the same application as the customer and barber experiences: dashboard, all-staff calendar, business details/hours, staff management and invitations, roles and service eligibility, service categories and services, booking rules, loyalty programme configuration and reward redemption, and business-wide settings. No separate owner app — owner is a permission on a staff account (the seeded owner, Marcus Reed, is also a working barber), reusing the existing auth/permission system, the (staff)-pattern shell, and the design system throughout. Four new focused domain services were added (BusinessService, ServiceCatalogueService, a small booking-rule.service.ts, and OwnerReportingService); everything else extends StaffService/LoyaltyService or is reused as-is.

---

1. What was built

• Owner Dashboard (/owner) — real, data-backed: today's appointment totals by status, staff working today, estimated occupancy (clearly labelled as an estimate, no invented revenue), popular services (last 30 days), recent loyalty activity, customers with an available reward, and configuration warnings (no opening hours, staff with no working hours, a service with no eligible active staff, an incomplete-but-enabled loyalty programme, time-off/appointment conflicts).
• All-Staff Calendar (/owner/calendar) — Day and Agenda views, staff filter pills, current-time indicator, reuses the exact same DayCalendar/DateStrip/AppointmentCard components the barber calendar uses (parametrized, not forked). Owner can view any appointment, create one (via the existing /staff/book flow — never duplicated), block time for any staff member, and reschedule/reassign.
• Appointment Reassignment — "Reschedule / Reassign" on the owner appointment details page reuses BookingService.rescheduleBooking's existing (already staffId-aware) validation pipeline; no new domain logic was needed.
• Owner Appointment Access (/owner/appointments/[id]) — view/update status, reschedule/reassign, apply a loyalty reward, book on behalf of a customer, view customer notes — via owner-specific authorization helpers, kept separate from (not weakening) barber authorization.
• Business Details (/owner/settings/business) — name/logo/description/address/contact/social links/timezone/currency/locale/policies, backed by Business/BusinessLocation/BusinessSettings.
• Opening Hours (/owner/settings/hours) — per-weekday enable/times, "copy Monday to all days", conflict review before saving (shows affected future appointments, never auto-cancels, requires explicit "Save Anyway").
• Staff Management (/owner/team, /owner/team/[id]) — search/add/view/deactivate/reactivate, role assignment, service eligibility, working-hours edit-on-behalf-of. Deactivation is conflict-reviewed and last-owner-protected.
• Add Staff / Invitations (/owner/team/add, /invite/accept) — creates a fully usable staff profile immediately, plus a StaffInvitation row surfaced as a dev-safe copy-link (no real email delivery this phase).
• Roles and Permissions — fixed built-in Owner/Barber roles (schema supports more); last-active-owner protected against self-removal/self-deactivation.
• Staff Service Eligibility — per-staff checklist of active services, conflict-reviewed when removing a service with future bookings.
• Service Categories and Services (/owner/services) — create/rename/reorder (up/down buttons, not drag-and-drop)/activate-deactivate/delete-if-unused, assign eligible staff, configure online-booking/buffers. Money handled as strings end-to-end, never a JS number.
• Booking Rules (/owner/settings/booking-rules) — minimum notice, max advance window, cancellation/reschedule windows, slot interval, buffers, per-day and per-staff-per-day caps, guest booking, barber selection, approval requirement.
• Loyalty Configuration (/owner/settings/loyalty) — enable/disable, stamps required, reward type (percentage/fixed/free-service) and value, eligible services/staff, expiry, auto-apply, card appearance, terms.
• Loyalty Reward Redemption (new this phase — Phase 5 deliberately left it unbuilt) — apply an AVAILABLE reward to an eligible appointment, atomically marking it REDEEMED, deducting stamps, and recording a discount on the appointment; available to both Owner and Barber (it's an operational action, not owner-only configuration).
• Business Settings — currency/locale/timezone/policies via the existing structured BusinessSettings model (no unstructured JSON blob).
• Owner Settings Hub (/owner/settings) — links to all the above, plus "Switch to Barber Tools" and the existing personal notification-preferences page (reused, not duplicated).
• Audit Logging — staff added/deactivated/role-changed/services-changed, business profile/hours changed, booking rules changed, loyalty config changed, reward redeemed, appointment reassigned — all written to the pre-existing (previously-unused) AuditLog table.

2. Routes created

Inside (owner) (persistent nav via the shared StaffShell, parametrized with OWNER_NAV_ITEMS): /owner, /owner/calendar, /owner/appointments/[id], /owner/team, /owner/team/add, /owner/team/[id], /owner/team/[id]/hours, /owner/services, /owner/settings, /owner/settings/business, /owner/settings/hours, /owner/settings/booking-rules, /owner/settings/loyalty.

Outside (owner) (own fixed-bottom-bar UI, same route-group-splitting pattern Phase 4/5 established for /book and /staff/appointments/[id]/reschedule): /owner/appointments/[id]/reschedule.

Public (inside (auth) for its shared centered-card shell, not staff/owner-gated): /invite/accept.

3. Components

New, owner-scoped (src/features/owner/components/): owner-block-time-button.tsx, redeem-reward-button.tsx, business-details-form.tsx, opening-hours-form.tsx, add-staff-form.tsx, staff-detail-panel.tsx, catalogue-manager.tsx, service-form-sheet.tsx, booking-rules-form.tsx, loyalty-config-form.tsx.

New, shared auth (src/features/auth/components/accept-invitation-form.tsx).

Generalized, not forked (the same dependency-injection pattern Phase 5 used for ServiceSelector.onContinue):

• AppointmentStatusActions gained an optional actions?: AppointmentActionSet prop (default = staff Server Actions); the owner appointment page injects the owner variant instead of forking the component.
• WorkingHoursForm gained an optional onSave prop so /owner/team/[id]/hours injects updateStaffWorkingHoursAction instead of the self-service action.
• DayCalendar gained an optional appointmentHrefBase prop so the same component links to /owner/appointments/[id] or /staff/appointments/[id] depending on context.
• DateStrip gained an optional extraParams prop so the owner calendar's ?staffId= filter survives date navigation.
• StaffShell/StaffSidebarNav/BottomNav all gained an items prop (default STAFF_NAV_ITEMS); the owner layout passes OWNER_NAV_ITEMS instead. StaffSidebarNav additionally gained an optional footerLink prop for the owner's "Barber Tools" back-link — explicitly one shared nav component, not competing owner/staff variants.

4. Domain services

New:

• BusinessService (src/services/business/business.service.ts) — business profile/location/settings CRUD, opening-hours validation and conflict-checked read/write. Deliberately excludes booking rules (scheduling policy) and loyalty (its own service) — see its own file header.
• ServiceCatalogueService (src/services/catalogue/service-catalogue.service.ts) — categories and services CRUD, reordering, usage-conflict lookup. Staff eligibility stays in StaffService (it's staff-scoped data, not catalogue data).
• booking-rule.service.ts (src/services/scheduling/booking-rule.service.ts) — read/write and validation for the BookingRule row itself. A new sibling file rather than an addition to business-rules.service.ts, because that file is deliberately pure/Prisma-free (its own header says so) and needs to stay that way to remain cheap to unit test; this file owns the one thing that one doesn't — loading and persisting the configuration an owner actually edits.
• OwnerReportingService (src/services/reporting/owner-reporting.service.ts) — read-only dashboard aggregation (getDashboardSummary, getConfigurationWarnings). Exists only because the dashboard's queries are genuinely more than "call one existing service and render it"; not a general owner data-access layer, and no other feature imports from it.
• StaffInvitationService (src/services/staff/staff-invitation.service.ts) — invitation token generation/validation/acceptance. Kept out of StaffService deliberately (acceptance tracking is a distinct concern from the staff profile itself, which is fully usable the moment it's created).

Extended:

• StaffService — owner-facing additions: listStaffForBusiness, getStaffDetailById, listRolesForBusiness, createStaffProfile, updateStaffAsOwner, deactivateStaff/reactivateStaff (both last-owner-protected), setStaffServiceEligibility, all with matching conflict-finder functions (findStaffDeactivationConflicts, findServiceEligibilityConflicts).
• LoyaltyService — programme configuration (getProgrammeConfig, updateProgrammeConfig, setEligibleServices, setEligibleStaff) and reward redemption (listEligibleAppointmentsForReward, redeemReward).

Reused as-is: BookingService.rescheduleBooking (for reassignment), AppointmentService, AvailabilityService, StaffAvailabilityService, BusinessRulesService (evaluation logic only), CustomerService.

New (feature-layer, not domain services): src/features/owner/authorization.ts (assertOwnerPermission, mirroring src/features/staff/authorization.ts), src/lib/audit/write-audit-log.ts.

5. Schema changes

Two migrations:

20260803070350_owner_administration:

• Permission enum gained MANAGE_ALL_APPOINTMENTS and VIEW_REPORTING.
• Appointment.discountAmount Decimal? @db.Decimal(10,2) — the effect of a redeemed loyalty reward, kept separate from priceAtBooking/durationAtBookingMinutes snapshots so those never need to change.
• New StaffInvitation model (token, email, expiresAt, acceptedAt, invitedByUserId) — one per StaffProfile, opaque DB-validated token (not HMAC-signed like the booking-draft cookie, since it's a single-use server-validated lookup, not something a client needs to verify offline).
• LoyaltyReward gained a real FK for appliedToAppointment (was already a plain string column) plus redeemedByStaffId/redeemedByStaff.

20260803071240_loyalty_free_service:

• LoyaltyProgramme.freeServiceId/freeService — which service is free for a FREE_SERVICE reward. A genuine schema gap: the existing eligibleServices list serves a different purpose (which services earn stamps), not "which service the reward covers."

Both applied via npx prisma migrate dev against a real Postgres, then npx prisma generate; seed and tests updated to match.

Reviewed and deliberately not added: a Business.isPubliclyVisible toggle (no consumer/enforcement point yet in a single-business app), a dedicated "business exceptional closures" table (the brief said "where appropriate"; opening-hours conflict review already covers the common case).

6. Dashboard metric approach

getDashboardSummary composes, for a given date: listAppointments (existing service) filtered/counted by status for the totals row; WorkingHours/TimeOff for "staff working today" vs "staff on time off"; occupancy as bookedMinutes / availableMinutes across staff actually working that day, rounded to a percent and always rendered with the label "an estimate, not a financial figure" — never a revenue figure, since the brief explicitly warned against inventing one. Popular services aggregates AppointmentService rows for COMPLETED appointments in the last 30 days, in memory (not a SQL GROUP BY) since the dataset size doesn't warrant it. Configuration warnings (getConfigurationWarnings) are a separate, independently-callable function: no opening hours at all, a staff member with no working day set, an active service with no active eligible staff, an enabled-but-incomplete loyalty programme (reusing validateProgrammeConfig rather than re-implementing the check), and upcoming time-off that overlaps an existing appointment.

7. All-staff calendar approach

The owner calendar page is new, but it renders zero new calendar UI: it reuses DayCalendar (one column per staff member, or a single column when filtered) and AppointmentCard (agenda view) exactly as the barber calendar does, just fetching listAppointments for the whole business instead of one staff member and looping columns. The staff filter and Day/Agenda toggle are plain <Link>s carrying query params (?date=&view=&staffId=), so the page stays a Server Component with no client-side calendar state to keep in sync. "New" links straight to /staff/book (already lets any signed-in staff member, owner included, pick any eligible barber) rather than a duplicate /owner/book flow.

8. Business/opening-hours behaviour

setOpeningHours validates structurally first (open day needs both times, times within a single day, open before close), then — unless the caller passes acknowledgeConflicts — calls findOpeningHoursConflicts, which finds future, non-cancelled appointments that would fall outside the proposed hours (either on a day newly marked closed, or outside a still-open day's new window). If any exist, the save is rejected with the conflict list attached; the UI shows each affected appointment and offers "Go Back" or "Save Anyway." Saving never touches the appointments themselves — only BusinessHours rows, in one transaction, in an upsert per weekday. The customer-facing availability engine reads BusinessHours fresh on every request, so a save is reflected immediately with no cache to invalidate.

9. Staff invitation/management approach

createStaffProfile creates a fully usable User + StaffProfile + initial StaffService eligibility rows in one nested create — the profile can appear on the calendar and be booked immediately, it is never gated on invitation acceptance. StaffInvitationService.createInvitation separately creates a StaffInvitation row with a random 32-byte base64url token and a 7-day expiry; the owner UI surfaces it as a copy-link (/invite/accept?token=...) since there's no real email delivery this phase — documented as a deliberate dev-safe shortcut, not a production gap to hide. Accepting sets a password (bcrypt-hashed, mirroring registerAction), marks emailVerified/acceptedAt, and signs the new staff member in immediately. Deactivation (deactivateStaff) is conflict-reviewed exactly like opening hours (future appointments shown, "Deactivate Anyway" required) and last-owner-protected (see §14); it flips StaffProfile.status to INACTIVE and never deletes the row, preserving appointment history integrity (Appointment.staff is onDelete: Restrict for exactly this reason).

10. Service/category management approach

Categories and services share one conflict-review-free CRUD path for create/edit/reorder/activate-deactivate (these can never orphan an existing booking — a deactivated service or category simply stops appearing for new bookings), but deletion is different: deleteCategory refuses outright if the category still has any services (active or not), directing the owner to deactivate instead — deletion is only for genuinely empty, unused categories. Editing a service's price or duration only ever changes the live Service row; the historical AppointmentService.priceAtBooking/durationAtBookingMinutes snapshot on every past and already-confirmed appointment is never rewritten (verified by a dedicated integration test). Reordering is up/down buttons per item, not drag-and-drop, matching the brief's own accessibility note about keyboard alternatives.

11. Booking-rule behaviour

updateBookingRule validates every field's range (minimum notice ≥ 0, max advance ≥ 1 day, slot interval 5–120 minutes, per-day/per-staff-per-day caps ≥ 1 or unlimited) and upserts the single BookingRule row for the business. No conflict-review step exists for booking rules specifically — tightening a rule (e.g. requiring approval, shortening the cancellation window) changes how future bookings behave without altering any existing appointment's stored state, so there is nothing to show an affected-appointments list for; the customer booking flow reads the current BookingRule row fresh on every booking attempt, so a save takes effect on the very next booking (exercised directly in the E2E "require approval" journey, §16).

12. Loyalty configuration/redemption approach

updateProgrammeConfig validates only what's required when enabled (validateProgrammeConfig) — a disabled, half-configured draft is allowed since the owner may still be working on it; enabling a FREE_SERVICE reward additionally checks the chosen service is active. setEligibleServices/setEligibleStaff replace their respective lists wholesale in a transaction (delete-all-then-recreate), matching the same pattern setStaffServiceEligibility uses.

redeemReward is the one place LoyaltyReward.status, LoyaltyAccount.currentStamps, and Appointment.discountAmount ever change together, inside a single $transaction. The status flip uses a conditional updateMany (WHERE status = 'AVAILABLE') rather than a read-then-write, so two simultaneous redemption attempts can't both succeed — the loser sees REWARD_NOT_AVAILABLE, never a double deduction (covered by a dedicated integration test that redeems, then attempts a second redemption of the same reward). The discount is computed from the reward type (percentage of subtotal, fixed amount, or the price of the matching free-service line), clamped to [0, subtotal], and written to Appointment.discountAmount — the original priceAtBooking snapshots are never touched, so the subtotal is always recoverable and the final total is always subtotal - discountAmount, never negative. A documented simplification: redemption reads the loyalty programme's current stampsRequired/freeServiceId, not a value snapshotted when the reward was earned — if the owner reconfigures the programme in between, redemption reflects the new configuration.

13. Conflict-review behaviour

One pattern, reused everywhere a change could strand an existing appointment: validate → find affected future appointments → if any and not yet acknowledged, return them without writing anything → the UI shows each one and offers "Go Back" or an explicit "[Verb] Anyway" → only that second call actually writes, and only ever the configuration being changed, never the appointments themselves → the same call also writes an audit log entry. This exact shape now covers business opening hours (§8), staff deactivation (§9), and staff service-eligibility removal (§10) — all three share the "conflicts: []" / "acknowledgeConflicts" parameter shape and all three are exercised by an integration test asserting the blocked-then-Save-Anyway-then-appointment-still-intact sequence. Booking rules (§11) and loyalty configuration (§12) don't need this pattern, for the reasons given in their own sections.

14. Permission and business-isolation rules

The (owner) layout gates on MANAGE_STAFF as a coarse "is this person any kind of owner" shell check — but every individual Server Action re-derives the session and checks the specific permission that action needs (MANAGE_BUSINESS_PROFILE, MANAGE_SERVICES, MANAGE_BOOKING_RULES, MANAGE_LOYALTY_PROGRAMME, MANAGE_ALL_APPOINTMENTS, VIEW_ALL_STAFF_APPOINTMENTS, VIEW_REPORTING), via assertOwnerPermission → hasPermission, which re-queries the database every time rather than trusting the session/JWT — a permission change (or a demotion) takes effect on the very next request, not after the token expires (verified directly: see the integration test asserting a permission change is reflected immediately, §16). Every owner service function additionally re-scopes its query by businessId even though this is a single-business v1 app — explicit defense-in-depth, not dead code, matching the same discipline Phase 4/5 applied. Last-owner protection: "an owner" is defined as any staff member whose role holds MANAGE_STAFF (not a hardcoded role name, so a future custom role with that permission is automatically covered); both deactivateStaff and updateStaffAsOwner (role change) refuse the action if it would leave zero other active staff members holding MANAGE_STAFF.

15. Audit logging

writeAuditLog(prisma, {actorUserId, action, entityType, entityId, metadata}) is called from every owner mutation Server Action (not from inside the domain services themselves, keeping the domain layer free of "who did this and why" concerns) with an action-specific name: BUSINESS_PROFILE_UPDATED, STAFF_ADDED, STAFF_ROLE_CHANGED/STAFF_UPDATED, STAFF_DEACTIVATED/STAFF_REACTIVATED, STAFF_SERVICES_CHANGED, STAFF_WORKING_HOURS_CHANGED, BOOKING_RULES_UPDATED, LOYALTY_CONFIG_UPDATED, LOYALTY_REWARD_REDEEMED, APPOINTMENT_REASSIGNED (only written when the staff actually changes, not on a plain reschedule). metadata is typed Prisma.InputJsonValue and only ever carries safe, already-public-to-the-owner values (names, ids, booleans) — no passwords, invitation tokens, or other secrets are ever passed in.

16. Tests

Unit (Vitest, no DB — 179 tests total, up from ~150 before this phase): pure validators for every new input shape — validateBusinessProfileInput/validateOpeningHoursInput (business.service.test.ts), validateCategoryInput/validateServiceInput including the decimal-price regex (service-catalogue.service.test.ts), validateBookingRuleInput including every range boundary (booking-rule.service.test.ts), validateProgrammeConfig for all three reward types and the enabled-vs-disabled leniency (loyalty-config.test.ts), and validateCreateStaffInput (appended to the existing staff.service.test.ts).

Integration (Vitest, real throwaway Postgres — 86 tests total): business.service.integration.test.ts (opening-hours conflict detection + Save Anyway + the appointment stays untouched), service-catalogue.service.integration.test.ts (category-deletion-blocked-when-has-services, business isolation, and the historical-snapshot-preservation test described in §10), staff-owner.integration.test.ts (staff creation + duplicate-email rejection, last-owner protection on both deactivation and role change, deactivation/eligibility conflict review + Save Anyway), loyalty-owner.integration.test.ts (programme config create-then-update, free-service-must-be-active, eligible-services replace-wholesale, and the redemption suite: successful redemption's atomic discount/status/stamp effects, duplicate-redemption race prevention via the conditional updateMany, already-discounted-appointment rejection, wrong-customer rejection), and authorization.integration.test.ts (owner-vs-barber permission grants/denials against real Role/RolePermission rows, a live permission-change-takes-effect-immediately test, and business-isolation checks on updateStaffAsOwner/deactivateStaff/deleteCategory against a second business's data).

End-to-end (Playwright, e2e/owner-journeys.spec.ts, 12 journeys, run serially): dashboard with real data and configuration warnings; all-staff calendar filter + Day/Agenda; business details edit + persistence; opening hours tightened + conflict shown + Save Anyway + appointment untouched; add a barber and get a dev invite link; change a barber's role and service eligibility (round-tripped); create a category and service, verified immediately on the customer /book page; require booking approval and verify a fresh customer booking lands Pending Approval; configure the loyalty programme; redeem a customer's available reward; a barber without MANAGE_STAFF is redirected away from /owner; the owner switches back to Barber Tools without losing the barber nav. Every journey that mutates shared configuration (business details, opening hours, booking rules, loyalty config) restores the original value at the end of the same test, matching the Phase 5 precedent; journey 10 (redeem reward) is a documented one-shot consumption of the seed's single AVAILABLE reward, same category as Phase 5's own booking journeys.

Running them:

npm run test              # unit, no DB — 179 tests
npm run test:integration  # needs DATABASE_URL → a real Postgres — 86 tests
npm run test:e2e          # needs DATABASE_URL → a real (throwaway) Postgres — 27 journeys (6 Phase 4 + 9 Phase 5 + 12 Phase 6)

17. Manual verification

• Signed in as the owner (Marcus Reed) and walked every new page — dashboard, all-staff calendar (day + agenda, staff filter), business details, opening hours, team list + staff detail (role/eligibility/deactivate), add-staff + invite-link, services & categories (add/edit/reorder/delete-blocked), booking rules, loyalty config, appointment details + redeem reward, reschedule/reassign — in a real browser against seeded data, at both mobile (375px) and desktop (1280px) viewports.
• Signed in as a barber (Leo Vance, no MANAGE_STAFF) and confirmed /owner redirects to /staff with no owner nav visible.
• Verified the desktop two-column treatment on Business Details, Booking Rules, and Loyalty Configuration (element rects confirmed genuinely side-by-side, not just visually similar in a screenshot), the Team page's 2-column card grid, the Staff Detail page's master-detail split, and the all-staff calendar's multi-column day view — and confirmed all of them still stack to a single column at 375px with no regression.
• npx tsc --noEmit, npx eslint ., and npx next build all clean on the final state.
• All three automated suites (179 unit / 86 integration / 27 E2E) passed together on one freshly created, migrated, and seeded database in a single run — the authoritative verification (see §19 for why a repeated run against the same database needs care).

18. Assumptions made

• A single-business deployment, same as every prior phase — no multi-business owner switching was built or implied.
• "An owner" is a permission, not an account type — Owner/Barber are the only two roles seeded, but every last-owner check is written against "does this role hold MANAGE_STAFF," so a future Manager/Receptionist role with a subset of owner permissions fits without a schema or logic change.
• Redemption eligibility is service-agnostic beyond FREE_SERVICE — a percentage or fixed-amount reward can be applied to any of the customer's own appointments, not restricted to appointments containing "eligible" services (eligibility governs earning stamps, not which appointment a reward can be applied to).
• No payments/deposits are modelled — a redeemed reward's discount is recorded, but there is no payment capture, refund, or deposit-hold anywhere in this phase, matching the explicit scope boundary.
• The dev invite-link flow is accepted as a permanent, documented dev-mode behaviour for this phase, not a stopgap hidden from the summary — real delivery is explicitly out of scope (§20).

19. Known limitations

• Working-hours editing had no conflict detection (both the self-service and owner-on-behalf editors) — closed in Phase 7 ("Working-hours conflict review": findWorkingHoursConflicts / setWorkingHours({ acknowledgeConflicts }) in staff.service.ts, the conflict list in working-hours-form.tsx, covered by staff.service.integration.test.ts). Kept here only as history.
• Owner-editable breaks/whole-day time off for a staff member were not built — resolved. Owner-on-behalf-of editing of a staff member's breaks and whole-day time off was built in Phase 7 (Manage → Team → staff → Breaks / Time Off). The one remaining piece, editing and deleting partial-day "Block Time" entries (which OwnerBlockTimeButton creates), now also works: they are listed on the same Time Off page, for the owner (MANAGE_STAFF) and for staff on their own Time Off settings page, using the same update/delete actions and conflict review.
• Staff service eligibility is edited only from the Staff Detail page, not duplicated on the Services & Categories page (the brief mentions "assign eligible staff" under Services too) — one edit surface, avoiding two places that could drift out of sync.
• "Requires staff approval to redeem" and "Apply reward automatically" were removed from the loyalty settings form — neither did anything (redemption is always staff-initiated and gated by MANAGE_LOYALTY_STAMPS). The two LoyaltyProgramme columns still exist, unused.
• A repeated run of the E2E suite against the same (non-reseeded) database is not fully idempotent: journey 10 (redeem reward) consumes the seed's one AVAILABLE reward, and one seed appointment (appt-today-checkedin, timed via minutesFromNow to reliably exercise selectCurrentAppointment's CHECKED_IN tier) can occasionally start a few minutes before the business's 10:00 opening depending on exactly when the seed happens to run, which the opening-hours conflict test now handles defensively rather than assuming a clean save — this is a real, if narrow, characteristic of time-relative seed fixtures re-run without a fresh database, same category of issue Phase 5's own summary flagged (§13 there); it does not affect a single authoritative run against a freshly seeded database, which is how CI should always run it.
• Notification delivery, payments, deposits, advanced financial reporting, payroll, multi-business/multi-location, PWA, and offline remain entirely out of scope, per the brief's own boundary.

20. Review items for Phase 7

• Decide whether owner-editable breaks and whole-day time off (on behalf of staff) should be built — built in Phase 7; Block Time edit/delete followed later (see §19).
• Decide whether working-hours edits (both self-service and owner-on-behalf-of) should gain the same conflict-review treatment as breaks/time-off/business-hours, closing the gap flagged in §19.
• Real notification delivery (email/SMS/push) is still entirely unbuilt — both the Phase 5 preference grid and this phase's invite-link workaround are waiting on it.
• Payments/deposits and any real financial reporting beyond the operational dashboard estimate are unstarted; Appointment.discountAmount exists and is populated correctly, but nothing yet reconciles it against an actual payment.
• If a future phase adds custom (non-Owner/Barber) roles with a role editor, the "is an owner" check (role holds MANAGE_STAFF) and the fixed built-in-roles assumption in listRolesForBusiness/AddStaffForm should be revisited together.
• The E2E suite's reliance on a freshly seeded database for a fully clean run (§19) has no CI wiring yet to provision one automatically — same open item Phase 4/5 already flagged, still unresolved.