# RBAC Implementation - Flagged Questions & Context

## Purpose
This document supplements Claude Code's RBAC implementation plan with questions and considerations for ResolutionFlow's multi-tenant SaaS architecture.

---

## Multi-Tenant Model Overview

### Account Tiers
- **Free/Individual** — Single user, access to public trees only
- **Team Package** — Team owner + invited members, private team trees + public trees

### Content Visibility
- **Public Trees** — ResolutionFlow official content, visible to all authenticated users
- **Team Trees** — Created by team members, visible only to that team

### Role Hierarchy

| Role | Scope | Capabilities |
|------|-------|--------------|
| **Super Admin** | System-wide | Manage public trees, all teams, all users |
| **Team Owner** | Their team | Everything Team Admin can do + billing management |
| **Team Admin** | Their team | Invite/remove members, assign roles, manage team trees |
| **Engineer** | Their team | Create/edit team trees & steps, fork public trees |
| **Viewer** | Their team | Read-only access to team + public trees, run sessions |

### Key Architectural Decisions
- Database should support multi-team membership (junction table), but UI enforces single team for now
- Team Owner is functionally a Team Admin with billing powers (no separate role needed initially)

---

## Flagged Questions for Implementation

### 1. Step Library Permissions (Phase 2.5)
- Can viewers rate/review steps, or is that engineer+ only?
- How do ratings work across teams — are they global or team-scoped?

### 2. Session Permissions
- Can viewers *create* new troubleshooting sessions, or only view past session history?
- Clarify the intended behavior before implementing.

### 3. Personal Tree Branching (Phase 2.5)
- When a user forks a public tree into their team's space, who owns it?
- Does the original author get attribution, or is it a clean copy?

### 4. Team Content Isolation
- The current plan references `team_id` but doesn't explicitly enforce that team trees are invisible to other teams.
- Ensure `build_tree_access_filter()` and `build_visibility_filter()` account for:
  - User's team membership
  - Public vs team-private trees
  - Cross-team isolation

### 5. Super Admin Role
- The plan has "admin" but doesn't distinguish between "ResolutionFlow super admin" (system-wide) and "Team Admin" (team-scoped).
- Consider: Should the database have an `is_super_admin` flag, or is this handled by a specific team/user ID?

### 6. Future Multi-Team Membership
- The database should support users belonging to multiple teams (junction table) even if the UI enforces single-team for now.
- Confirm the schema supports this or flag what migration would be needed later.

### 7. Subscription Lapse Handling (Low Priority - Not MVP)
- What happens to team trees if a team subscription expires?
- Options to consider:
  - Team downgraded to viewer-only (can see but not edit)
  - Grace period before content becomes inaccessible
  - Export option before lockout
- Not needed for MVP, but note where this logic would hook in.

---

## Implementation Checklist

Before starting RBAC implementation, confirm answers to:

- [ ] Session permissions: Can viewers create sessions or only view history?
- [ ] Step ratings: Viewer participation yes/no?
- [ ] Super admin flag: New DB field or handled differently?
- [ ] Multi-team schema: Current schema supports this or needs migration?

---

## Related Documentation
- Claude Code's original RBAC plan (see project knowledge)
- Phase 2.5 roadmap (Step Library, Personal Branching)
- CURRENT-STATE.md

---

*Last updated: February 2025*