give management enough to run the business, not enough to break it. Do it in two phases so we don’t block launch.

What access should management have?

Use least-privilege RBAC with one extra safety net (audit logs).

Roles (today)

owner – god mode (you). Bypass paywall, billing, API keys, everything.

admin – ops/engineering: refunds, price changes, user upgrades/downgrades, view all analytics, domain/API key management.

manager – business side: read analytics, export CSVs, issue coupon codes, comp a user for X days, approve/cancel brands, moderate content. No API keys, no pricing edits, no refunds.

pro – paying customer.

user – free tier.

Permissions by area

Paywall bypass: owner, admin (yes). manager (no).

Brand Kit generation (internal/unlimited): owner, admin (yes). manager (rate-limited sandbox only).

Refunds / Stripe portal: owner, admin (yes). manager (request-only workflow).

Pricing & plans: owner, admin (edit). manager (read).

Coupons / promos: owner, admin, manager (create %/fixed, cap usage & expiry).

Analytics (revenue, conversion, cohorts): owner, admin (full). manager (read-only).

User management: owner, admin (upgrade/downgrade/ban). manager (cannot ban; can comp days).

API keys (GoDaddy, Stripe, image gen): owner, admin (view/rotate). manager (no view; can trigger “connect” flows).

Content moderation (logos/slogans abuse): owner, admin, manager (approve/reject).

Exports (brand book PDFs, CSVs): owner, admin, manager (yes).

Should we roll it now or wait?

Do it now, but keep it small.
Implement a Phase A guard in Replit today (low risk, quick win). Leave the fancy stuff for Phase B.

Phase A (today: ~1–2 files touched)

Add a manager role and a single helper: hasStaffAccess() = isOwner || isAdmin || isManager.

Gate sensitive screens with:

hasProAccess() (for customers) vs hasStaffAccess() (for internal).

Add read-only Analytics and Coupons screens for manager.

Force owner/admin only for refunds, pricing, API keys.

Replit prompt (paste this):

Add a 'manager' role and scoped staff access:

1) Update AuthContext:
   - isManager = users/{uid}.role === 'manager'
   - hasStaffAccess = isOwner || isAdmin || isManager
   - Export { isOwner, isAdmin, isManager, hasStaffAccess, hasProAccess }

2) Route guards:
   - /brandkit: Pro OR Staff (manager allowed)
   - /pricing-editor, /api-keys, /billing/refunds: Owner/Admin only
   - /analytics: Staff read-only (manager allowed)
   - /coupons: Staff (create, but enforce max uses + expiry)

3) Server:
   - In serverAuth.resolveServerAccess return isManager + hasStaffAccess
   - Enforce on APIs:
     - AdminOnly: pricing, refunds, api-keys
     - StaffOnly: analytics read, coupons create/list
     - ProOrStaff: brandkit generate

4) UI:
   - Hide buttons if forbidden; show a small lock tooltip.
   - Add audit logs for staff actions (create a 'logs' collection with {uid, action, ts, meta}).

Phase B (later, when we care about fine control)

Move from pure RBAC to RBAC + scopes (permissions array):
permissions: ["analytics.read","coupons.create","users.compDays","brandkit.generate.unlimited"]

Add just-in-time elevation for scary actions (refunds → OTP confirm).

Granular rate limits for staff sandbox (e.g., manager can generate 20 brand kits/day).

Per-env keys and secrets rotation UI (no raw key exposure to manager).

Guardrails (so nobody nukes prod)

Audit everything staff does: coupons, comps, deletions, refunds.

No raw secrets shown to manager. Provide “Connect” buttons, never plaintext keys.

Staging vs Prod: staff gets unlimited in staging by default; prod is rate-limited.

Impersonation: allow owner/admin to “view as user” read-only, no write.

TL;DR

Give management = manager role today: analytics (read), coupons, moderation, comp days — no pricing/refunds/API keys.

Ship Phase A now; it’s simple and removes your paywall pain for staff while staying safe.

Save Phase B (scopes, OTP for refunds, rate limits) for after launch.