How it works

From idea to architect-grade context

Describe a feature in plain language. QEEK surfaces assumptions, maps your repo structure, and produces specs grounded in real files and dependencies — before anyone writes a line of code.

Try the live demo below
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.

RBAC System
├── Data Layer (Firestore)
│   ├── teams/{teamId}/members/{userId}
│   └── invitations/{inviteId}
├── Enforcement Layer
│   ├── Firestore Security Rules
│   └── API Middleware (checkPermission)
└── UI Layer
    ├── Role-gated components
    └── Permission hooks (usePermission)

2. Data Models

2.1 Team Member Document

Stored at teams/{teamId}/members/{userId}

typescript
interface TeamMember {
  userId: string;
  email: string;
  displayName: string;
  role: 'owner' | 'admin' | 'member' | 'viewer';
  joinedAt: Timestamp;
  invitedBy: string;
}

2.2 Invitation Document

Stored at invitations/{inviteId}

typescript
interface Invitation {
  id: string;
  teamId: string;
  email: string;
  role: 'admin' | 'member' | 'viewer';
  status: 'pending' | 'accepted' | 'expired';
  createdBy: string;
  createdAt: Timestamp;
  expiresAt: Timestamp; // 7 days from creation
}

2.3 Permissions Map

typescript
const PERMISSIONS: Record = {
  owner:  ['view', 'create', 'edit', 'delete', 'comment', 'manage_members', 'billing', 'transfer_ownership'],
  admin:  ['view', 'create', 'edit', 'delete', 'comment', 'manage_members'],
  member: ['view', 'create', 'edit', 'comment'],
  viewer: ['view', 'comment'],
};

3. Enforcement Layer

3.1 Firestore Security Rules

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

  1. Admin calls POST /api/teams/{teamId}/invitations
  2. Backend validates admin has manage_members permission
  3. Creates invitation document with 7-day expiry
  4. Sends email via Resend with magic link
  5. On click: validates invite → creates team member → marks invite accepted

4.2 Ownership Transfer

  1. Owner calls POST /api/teams/{teamId}/transfer-ownership
  2. 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

EndpointMethodPermission Required
/api/teams/{id}/membersGETview
/api/teams/{id}/invitationsPOSTmanage_members
/api/teams/{id}/members/{uid}/rolePATCHmanage_members
/api/teams/{id}/transfer-ownershipPOSTtransfer_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.
Qeek10:18 AM
Role-Based Access Control
Architect Session
Ready
Specs
product-spec.mdtechnical-spec.md
Mockups
team-management.htmlinvite-modal.htmlrole-picker.html
Describe what you want to build...

Review specs, mockups, and iterate with the AI — all in one workspace.

What QEEK actually produces

Every output is grounded in your real codebase — not generic templates.

Product Spec
Team Management — RBAC
Scope: invite flow, role picker, permission matrix
Edge cases: self-demotion, last-admin guard
Assumptions: 3 roles (admin, editor, viewer)
Technical Specrepo-grounded
src/services/teamService.ts
→ inviteMember(email, role)
src/models/TeamMember.ts
→ role: "admin" | "editor" | "viewer"
src/middleware/rbac.ts
→ checkPermission(userId, action)
6 file references verified
Wireframe Mockups
Team management dashboard
Invite member modal
Role picker dropdown

Generated from spec context — not generic templates.

LibraryShare · Comment · Refine
Notification Systemshared
2 specs, 4 mockups2 hours agoShared with 4
Auth Flow v2approved
2 specs, 7 mockupsYesterdayShared with 6
Dashboard Redesigndraft
1 spec, 3 mockups3 days ago
Verifiable by design

File paths, functions, and data models reference your actual repo.

Built for teams

Share briefs, add comments, refine specs in chat — together.

From idea to aligned execution

Each exchange reduces ambiguity and sharpens the plan.

01
Describe

State the intent

Describe the feature in plain language. No templates, no ceremony. QEEK asks clarifying questions to surface scope boundaries and edge cases.

02
Architect

Dialogue reveals assumptions

Through interactive conversation, QEEK maps your idea against real repo structure, types, and dependencies. Assumptions become explicit.

03
Converge

Inspectable artifacts

Product spec, technical spec, and mockups — all generated from dialogue. Grounded in your actual codebase, not abstract diagrams.

04
Execute

Build with clarity

Hand off to engineers or AI coding tools with full architectural context. Teams start aligned — reducing mid-sprint surprises and rework.

Grounded in real system context
Engineers can verify every claim
Ambiguity resolved before implementation

Start your next feature as a conversation

From idea to implementation-ready specs — grounded in your real codebase.

Free to start
No credit card required
Works with your repo