Phase 6

Owner Administration is complete. Summary of this final stretch of work:

Seed data extended with an inactive staff member, a pending invitation, a redeemed-reward fixture, a service with no eligible staff, and a future-appointment fixture for conflict testing — all idempotent, verified against the dev DB.

Testing brought to 179 unit / 86 integration / 27 E2E tests, all passing together on a freshly seeded, disposable Postgres:

Unit tests for every new pure validator (business hours, categories/services, booking rules, loyalty config, staff creation).
Integration tests covering opening-hours conflicts, last-owner protection, staff deactivation/eligibility conflicts, loyalty redemption's atomic race-guard, and owner-vs-barber/business-isolation authorization — all against a real Postgres.
12 new Playwright owner journeys, which surfaced and fixed two genuine issues along the way: a cookie-clearing race condition in the sign-out-mid-test flow (a real, reproducible timing bug, not just a test artifact), and confirmation that seed fixtures upserted by deterministic ID go stale once "today" has moved on — now handled defensively.
Desktop responsiveness: converted the single-column Business Details, Booking Rules, and Loyalty Configuration forms to a genuine two-column layout at the lg: breakpoint (verified via measured element positions, not just screenshots), confirmed mobile stacking is unaffected.

Final verification: clean tsc, eslint, and next build, plus the full three-suite run against one fresh database as the authoritative pass.

src/features/owner/authorization.ts

@@ -0,0 +1,25 @@
+import type { Permission } from "@/generated/prisma/enums";
+import { hasPermission } from "@/lib/auth/permissions";
+
+/**
+ * Per-action owner permission checks — the mirror of
+ * src/features/staff/authorization.ts and src/features/booking/authorization.ts.
+ * The `(owner)` route group layout already gates on MANAGE_STAFF as a
+ * coarse "is this person any kind of owner" shell check, but that is not
+ * enough on its own (see docs/phase-6-summary.md, "Permission and
+ * business-isolation rules") — every owner Server Action re-derives the
+ * session and checks the *specific* permission that action needs, since a
+ * future non-Owner role could plausibly hold some but not all of these.
+ */
+
+export class OwnerPermissionDeniedError extends Error {
+  constructor(message = "You don't have permission to do that.") {
+    super(message);
+    this.name = "OwnerPermissionDeniedError";
+  }
+}
+
+export async function assertOwnerPermission(userId: string, permission: Permission): Promise<void> {
+  const allowed = await hasPermission(userId, permission);
+  if (!allowed) throw new OwnerPermissionDeniedError();
+}