Connect your repos. QEEK builds a persistent, living map of your codebase. Describe a feature in plain language and get specs that reference real files and dependencies before anyone writes a line of code.
Try the live demo below
A Technial Architect that creates specs and mockups from knowledge of your actual code base. Ready to hand off.
QEEK
Session ChatRBAC System
Qeek10:18 AM
I've created the initial product spec and technical spec for the RBAC system. The tech spec covers the data models, Firestore security rules, and the permission checking middleware.
Sarah (PM)10:20 AM
The permissions matrix looks good, but we need to make sure Viewers can still comment on tickets — they just can't create or edit them.
Qeek10:21 AM
Updated! I've added a "comment" permission to the matrix and set it to `true` for all roles including Viewer. I also updated the tech spec's middleware section to show how comment creation checks for `canComment` instead of `canEdit`.
Sarah (PM)10:23 AM
Can you add a section about what happens when an Owner leaves the team? We need a transfer ownership flow.
Qeek10:24 AM
Done! Added a new section to both specs. The product spec now covers the ownership transfer flow (Owner must designate a new Owner before they can leave). The tech spec includes the Firestore transaction that atomically swaps the owner role.
Sarah (PM)10:26 AM
This is looking solid. Let me review the technical spec before we share it with the engineering team.
Qeek10:26 AM
Of course! I've opened the technical spec in the workspace. You can see the full permissions matrix, data models, and the new ownership transfer section. Let me know if anything needs adjusting before you share it.
Ask about this spec...
Qeek has context of all session files
Technical Spectechnical-spec.md
Tech Spec: Role-Based Access Control
1. System Architecture
1.1 High-Level Overview
RBAC is implemented as a cross-cutting concern across three layers: Firestore data model, backend middleware, and frontend UI gating.
match /teams/{teamId}/tickets/{ticketId} {
allow read: if isTeamMember(teamId);
allow create, update: if hasPermission(teamId, 'edit');
allow delete: if hasPermission(teamId, 'delete');
}
function isTeamMember(teamId) {
return exists(/databases/$(database)/documents/teams/$(teamId)/members/$(request.auth.uid));
}
function hasPermission(teamId, permission) {
let member = get(/databases/$(database)/documents/teams/$(teamId)/members/$(request.auth.uid));
return permission in PERMISSIONS[member.data.role];
}
3.2 Frontend Permission Hook
typescript
function usePermission(permission: Permission): boolean {
const { currentTeamMember } = useTeamContext();
if (!currentTeamMember) return false;
return PERMISSIONS[currentTeamMember.role].includes(permission);
}
// Usage in components:
function DeleteTicketButton({ ticketId }: { ticketId: string }) {
const canDelete = usePermission('delete');
if (!canDelete) return null;
return ;
}
4. Key Workflows
4.1 Invite Flow
•Admin calls POST /api/teams/{teamId}/invitations
•Backend validates admin has manage_members permission
•Creates invitation document with 7-day expiry
•Sends email via Resend with magic link
•On click: validates invite → creates team member → marks invite accepted
4.2 Ownership Transfer
•Owner calls POST /api/teams/{teamId}/transfer-ownership
•Backend runs Firestore transaction:
●Verify caller is current owner
●Set target user's role to owner
●Set caller's role to admin
●Both writes are atomic
5. API Endpoints
Endpoint
Method
Permission Required
/api/teams/{id}/members
GET
view
/api/teams/{id}/invitations
POST
manage_members
/api/teams/{id}/members/{uid}/role
PATCH
manage_members
/api/teams/{id}/transfer-ownership
POST
transfer_ownership
6. Migration Strategy
6.1 Existing Teams
All existing team members will be migrated to the member role. The team creator will be set as owner. This migration runs as a one-time Cloud Function.
6.2 Rollout
●Week 1: Deploy with feature flag, internal testing
●Week 2: Enable for beta teams, gather feedback
●Week 3: GA rollout with in-app announcement
Session
RBAC System
New file
acme/project-mgmt
QEEK
SP
RBAC Feature
Started today at 10:15 AM
Qeek10:15 AM
Welcome back! You have 2 active projects. What would you like to work on today?
Sarah (PM)10:16 AM
We need to add role-based access control to the app. Right now everyone on a team has the same permissions, but customers are asking for admin vs. member vs. viewer roles. We also need an invite flow where admins can invite people with a specific role.
Qeek10:17 AM
That's a critical feature — getting RBAC wrong leads to security gaps and a lot of rework. Let me think through the architecture. I see four areas to spec out: 1. Role Model & Permissions Matrix — Define the roles (Owner, Admin, Member, Viewer) and map each to specific permissions across projects, tickets, settings, and billing. 2. Invite Flow — Admins can invite users by email with a pre-assigned role. Handle edge cases: existing users, expired invites, role changes. 3. Enforcement Layer — How permissions are checked on both the frontend (UI gating) and backend (API middleware). This needs to be consistent. 4. Team Management UI — A settings page where admins can see members, change roles, and revoke access. Let me create the specs and an initial mockup for the team management page.