Epic 1: Workspace and team access in-progress

Users can create a workspace, sign in, invite others, and work within role boundaries with strict tenant isolation. Self sign-up is supported: a new user picks a plan (Solo Free / Solo Pro / Team Starter / Team Business) at /sign-up and a workspace is provisioned on the chosen plan (Story 1.3.2). The first invitation issued by a Solo workspace auto-promotes it to a Team plan.

doneStory 1.1: Application scaffold per architecture

As a developer, I want the Quorum web app initialized per architecture decisions, So that all subsequent stories build on a consistent stack.

Maps to: ARCH-1, ARCH-2 (schema shell), ARCH-3 (auth placeholder).

Acceptance Criteria:

Given a clean repository
When the scaffold is applied per architecture.md
Then the app runs locally (dev server) with TypeScript, App Router, and Tailwind baseline
And ESLint (or configured linter) passes on CI or npm run lint
And DATABASE_URL can point at Postgres with Prisma client generation succeeding


doneStory 1.2: Create and name a workspace

As a signed-in user, I want to create and name a workspace, So that I have an isolated place for my product effort.

Maps to: FR1, FR5 (initial row scoping).

Acceptance Criteria:

Given an authenticated user
When they submit a valid workspace name
Then a workspace is created and they are redirected or focused into it
And all new records created in-session are scoped with that workspace_id
And validation prevents empty names and handles duplicate name policy (document chosen policy in UI)


doneStory 1.3: Sign-in and workspace membership

As a user, I want to authenticate and see workspaces I belong to, So that I can access my product work securely.

Maps to: FR2.

Acceptance Criteria:

Given valid credentials (per chosen auth provider)
When the user completes sign-in
Then they land on a workspace list or last-used workspace
And session handling follows NFR-S3 baseline (secure cookies/tokens, no secrets in client)


doneStory 1.4: Invite members and assign roles

As a workspace owner, I want to invite members and assign roles, So that my team can collaborate with appropriate permissions.

Maps to: FR3, FR4 (invitation acceptance flow).

Acceptance Criteria:

Given a user with owner (or delegated) permission
When they invite by email and pick a role
Then the invitee can accept and join with that role
And role labels match RBAC matrix intent from PRD (owner/member/contributor/viewer as implemented)


reviewStory 1.5: Enforce role permissions on key actions

As a workspace member, I want the UI and API to prevent actions outside my role, So that I cannot bypass governance.

Maps to: FR4.

Acceptance Criteria:

Given users with different roles
When a viewer attempts a mutating action (e.g. override filter, change billing)
Then the API returns forbidden and the UI shows disabled control + tooltip (UX-DR10 pattern)
And permitted roles succeed for the same action


doneStory 1.6: Tenant isolation guarantees

As a platform, I want strict workspace isolation, So that no tenant can read another’s data.

Maps to: FR5, NFR-S1.

Acceptance Criteria:

Given two workspaces A and B with test data
When a user authenticated to A requests B’s resource IDs
Then all such requests return 404 or 403 with no data leakage
And automated test covers representative read/write paths


doneStory 1.7: Leave or remove member flows

As a member or owner, I want to leave or remove someone per rules, So that access stays current.

Maps to: FR6.

Acceptance Criteria:

Given role rules (owner cannot remove sole owner without transfer, etc.)
When leave/remove is triggered
Then membership updates and the user loses access immediately on next request
And destructive actions require confirmation