···11+## Context
22+33+Lively Forms currently has a simple creator model: a signed-in user owns forms personally and all creator authorization checks are based on `form.userId`. That keeps the product simple for solo usage, but it prevents teams from sharing forms, reviewing responses together, or managing a common workspace.
44+55+This change introduces organizations as collaborative workspaces while preserving personal forms. It is cross-cutting because it affects data modeling, access control, dashboard scoping, form creation/editing, response review/export, and new organization management screens.
66+77+## Goals / Non-Goals
88+99+**Goals:**
1010+- Add organization workspaces without removing personal workspaces.
1111+- Let any signed-in user create an organization and become its owner.
1212+- Let organization owners rename/delete the organization, manage members, and manage invite links.
1313+- Let all organization members use the same form-related permissions within that organization.
1414+- Keep existing personal forms working with minimal migration risk.
1515+- Make workspace context visible in the creator experience so users know whether they are working personally or inside an organization.
1616+1717+**Non-Goals:**
1818+- Granular roles beyond owner vs member in v1.
1919+- Per-form permissions inside an organization.
2020+- Billing, audit logs, or enterprise admin controls.
2121+- Public organization pages or directories.
2222+- Converting organizations into a fully generic workspace abstraction used everywhere in the product.
2323+2424+## Decisions
2525+2626+### 1. Keep personal ownership as-is and add optional organization ownership to forms
2727+Rather than replacing the current model with a generic `Workspace` table, forms should remain personally owned by default and optionally belong to an organization via an `organizationId`. This preserves the current personal-form behavior and reduces migration complexity.
2828+2929+**Why:**
3030+- Existing data and queries already assume personal ownership.
3131+- Personal forms remain first-class without needing a synthetic personal workspace record.
3232+- The migration path is simpler because existing forms can stay attached to their current user.
3333+3434+**Alternatives considered:**
3535+- Full generic workspace abstraction for users and organizations: more flexible long-term, but substantially more invasive for a first collaboration release.
3636+- Organization-only ownership with mandatory migration of all forms: rejected because it weakens the current solo flow.
3737+3838+### 2. Model organization membership with two roles: OWNER and MEMBER
3939+Organizations should use a membership table with exactly two roles in v1. The owner has organization-admin privileges. Members share all form-related permissions equally inside that organization.
4040+4141+**Why:**
4242+- Matches the requested product behavior.
4343+- Keeps authorization rules predictable and easy to explain.
4444+- Avoids premature complexity from editors/admins/viewers.
4545+4646+**Alternatives considered:**
4747+- Multiple granular roles: rejected as out of scope for the first release.
4848+- Owner-only form management with limited members: rejected because the desired collaboration model is equal member access to forms.
4949+5050+### 3. Use invite-link records managed by the organization owner
5151+Invite links should be first-class records tied to an organization and created/revoked by the owner. Joining through a valid invite adds the signed-in user as a member if they are not already in the organization.
5252+5353+**Why:**
5454+- Simple onboarding flow for small teams.
5555+- Supports multiple links over time if needed.
5656+- Gives the owner explicit control over active invite entry points.
5757+5858+**Alternatives considered:**
5959+- Email-only invitations: rejected because the user explicitly requested invite links.
6060+- One permanent invite token per organization: simpler, but weaker lifecycle control than managed invite records.
6161+6262+### 4. Centralize workspace-aware authorization in shared server helpers
6363+The codebase already uses shared helpers in `lib/forms.ts` for ownership checks. This change should extend that pattern with shared access helpers that answer questions like: personal owner? organization member? organization owner?
6464+6565+**Why:**
6666+- Prevents access logic from drifting across routes and pages.
6767+- Makes the transition from personal-only to workspace-aware authorization safer.
6868+- Supports builder, response review, and export consistently.
6969+7070+**Alternatives considered:**
7171+- Inline access checks per route/page: rejected because this change touches too many surfaces.
7272+7373+### 5. Add explicit creator workspace selection in the UI
7474+The creator experience should expose an active workspace context, starting with personal plus any organizations the user belongs to. Dashboard and form creation should use that active context.
7575+7676+**Why:**
7777+- Users need to know where new forms will be created.
7878+- Dashboard lists must be clearly scoped.
7979+- It reduces confusion when the same user belongs to multiple organizations.
8080+8181+**Alternatives considered:**
8282+- Global mixed list of all forms across personal and org contexts: rejected because it makes ownership and creation context ambiguous.
8383+- Separate dedicated organization app section only: rejected because it fragments the creator workflow.
8484+8585+### 6. Treat organization admin as owner-only, but form operations as member-wide
8686+Rename/delete organization, member management, and invite-link management should require owner role. Form creation, editing, publishing, response review, and response export should require membership only.
8787+8888+**Why:**
8989+- Directly matches the requested permission model.
9090+- Cleanly separates organization administration from everyday collaboration.
9191+9292+**Alternatives considered:**
9393+- Owner-only publishing or response access: rejected because members are meant to have the same permissions for workspace work.
9494+9595+## Risks / Trade-offs
9696+9797+- **Workspace-aware access expands many queries** → Centralize helper functions and update creator surfaces incrementally around those helpers.
9898+- **Mixed personal/org ownership can complicate UI wording** → Use explicit workspace labels and creation context in dashboard/builder surfaces.
9999+- **Invite-link misuse or stale links** → Support explicit owner-managed revocation and keep links tied to one organization.
100100+- **Membership edge cases (already a member, owner leaving, delete with active forms)** → Define simple v1 rules and enforce them consistently in server actions.
101101+- **This model may constrain future granular roles** → Keep membership and invite models extensible even if v1 only uses OWNER/MEMBER.
102102+103103+## Migration Plan
104104+105105+- Add organization, membership, and invite-link tables plus optional `organizationId` on forms.
106106+- Keep existing forms as personal forms owned by their current user.
107107+- Update server-side access helpers before exposing organization UI.
108108+- Roll out workspace selection and organization management screens after the data model and authorization layer are in place.
109109+- If rollback is needed, disable organization UI and routes while preserving personal-form behavior.
110110+111111+## Open Questions
112112+113113+- Whether invite links should be single-use or reusable in v1. Initial recommendation: reusable until revoked.
114114+- Whether organization owners can leave the organization without transferring ownership. Initial recommendation: no, ownership must be transferred or the org deleted.
115115+- Whether personal and organization forms should be movable between workspaces in v1. Initial recommendation: not in scope for the initial release.
···11+## Why
22+33+Lively Forms currently treats every form as a single user’s personal resource, which blocks teams from collaborating in a shared workspace. Adding organizations now unlocks multi-user use cases while keeping permissions simple: all members can work with organization forms, and only the organization owner handles organization administration.
44+55+## What Changes
66+77+- Add organizations as a new shared workspace type alongside a user’s personal workspace.
88+- Allow a signed-in user to create an organization and become its owner.
99+- Allow organization owners to generate and manage invite links for joining the organization.
1010+- Allow invited users to join an organization through an invite link.
1111+- Grant all organization members the same permissions for organization forms, responses, and exports.
1212+- Restrict organization rename, delete, membership management, and invite-link management to the organization owner.
1313+- **BREAKING** Change creator access semantics from strictly user-owned forms to workspace-based access covering personal and organization-owned forms.
1414+1515+## Capabilities
1616+1717+### New Capabilities
1818+- `organizations`: Create and manage organizations, members, and owner-only organization administration.
1919+- `organization-invites`: Join organizations through invite links managed by the organization owner.
2020+2121+### Modified Capabilities
2222+- `creator-auth`: Expand creator authorization from personal ownership only to workspace-aware access for personal and organization resources.
2323+- `conversational-form-builder`: Allow creators to create and manage forms within a selected personal or organization workspace.
2424+- `dashboard-form-views`: Update dashboard browsing so creators can view forms within the active workspace context.
2525+- `response-review`: Allow organization members to review responses for organization forms they can access.
2626+- `response-export`: Allow organization members to export responses for organization forms they can access.
2727+2828+## Impact
2929+3030+- Affected areas: authentication/authorization, form ownership model, dashboard context, builder flows, response review/export, and new organization management surfaces.
3131+- Likely code: Prisma schema, auth/session helpers, form query helpers in `lib/forms.ts`, dashboard pages, builder pages, response pages, and new organization routes/components.
3232+- Likely systems: workspace selection in the creator UI, membership checks, invite-link lifecycle handling, and migration of existing forms into a personal-workspace model.
···11+## MODIFIED Requirements
22+33+### Requirement: Creator can create and manage form metadata
44+The system SHALL allow an authenticated creator to create a form draft within their personal workspace or an organization workspace they belong to and edit the title and shareable identity for any form in an accessible workspace.
55+66+#### Scenario: Creator creates a new personal form
77+- **WHEN** an authenticated creator creates a form in their personal workspace
88+- **THEN** the system creates a new draft form in that creator's personal workspace
99+1010+#### Scenario: Creator creates a new organization form
1111+- **WHEN** an authenticated creator creates a form in an organization workspace they belong to
1212+- **THEN** the system creates a new draft form in that organization workspace
1313+1414+#### Scenario: Creator updates an accessible form title
1515+- **WHEN** an authenticated creator edits the title of a form in a workspace they can access
1616+- **THEN** the system saves the updated title for that form
1717+1818+### Requirement: Creator can manage an ordered list of supported blocks
1919+The system SHALL allow an authenticated creator to add, select, edit, reorder, and remove blocks in a form located in an accessible workspace using only the supported v0 block types: text, short text, long text, single choice, and multiple choice.
2020+2121+#### Scenario: Creator adds a block
2222+- **WHEN** an authenticated creator adds a supported block type to a form in an accessible workspace
2323+- **THEN** the system appends the new block to the form with a stable block identifier
2424+2525+#### Scenario: Creator reorders blocks
2626+- **WHEN** an authenticated creator changes the order of blocks in a form in an accessible workspace
2727+- **THEN** the system saves the new block order for the form
2828+2929+#### Scenario: Creator removes a block
3030+- **WHEN** an authenticated creator removes a block from a form in an accessible workspace
3131+- **THEN** the system removes that block from the current form structure
3232+3333+### Requirement: Creator can publish and unpublish forms
3434+The system SHALL allow an authenticated creator to publish or unpublish a form in an accessible workspace and SHALL expose a public shareable route only for published forms.
3535+3636+#### Scenario: Creator publishes a form
3737+- **WHEN** an authenticated creator publishes a form in an accessible workspace
3838+- **THEN** the system marks the form as published and makes its public route available for respondents
3939+4040+#### Scenario: Creator unpublishes a form
4141+- **WHEN** an authenticated creator unpublishes a form in an accessible workspace
4242+- **THEN** the system marks the form as unavailable for new public submissions
4343+4444+## ADDED Requirements
4545+4646+### Requirement: Builder reflects the active workspace context
4747+The system SHALL show the active workspace context when a creator creates or edits a form so they can tell whether the form belongs to their personal workspace or an organization.
4848+4949+#### Scenario: Creator opens a form builder in an organization workspace
5050+- **WHEN** an authenticated creator opens a form that belongs to an organization workspace
5151+- **THEN** the system shows that organization context in the builder chrome
···11+## MODIFIED Requirements
22+33+### Requirement: Creator ownership is enforced for managed forms
44+The system SHALL allow creators to manage personal forms they own and organization forms belonging to organizations where they are members, and SHALL prevent access to editing, publishing, response review, or response export for forms outside those accessible workspaces.
55+66+#### Scenario: Creator opens a personal form they own
77+- **WHEN** an authenticated creator requests a personal form they own
88+- **THEN** the system allows them to edit and manage that form
99+1010+#### Scenario: Creator opens an organization form in a joined organization
1111+- **WHEN** an authenticated creator requests a form belonging to an organization where they are a member
1212+- **THEN** the system allows them to manage that form according to organization membership access
1313+1414+#### Scenario: Creator opens another creator's inaccessible form
1515+- **WHEN** an authenticated creator requests a form they do not own personally and that does not belong to an organization they are part of
1616+- **THEN** the system denies access to form management, response review, and response export for that form
···11+## ADDED Requirements
22+33+### Requirement: Dashboard views are scoped to the active workspace
44+The system SHALL scope dashboard form listings to the creator's selected personal or organization workspace.
55+66+#### Scenario: Creator views personal workspace dashboard
77+- **WHEN** an authenticated creator selects their personal workspace in the dashboard
88+- **THEN** the system shows only forms from that personal workspace
99+1010+#### Scenario: Creator views organization workspace dashboard
1111+- **WHEN** an authenticated creator selects an organization workspace they belong to in the dashboard
1212+- **THEN** the system shows only forms from that organization workspace
···11+## ADDED Requirements
22+33+### Requirement: Organization owner can create and revoke invite links
44+The system SHALL allow the organization owner to create invite links for that organization and SHALL allow the owner to revoke active invite links.
55+66+#### Scenario: Owner creates an invite link
77+- **WHEN** the organization owner creates an invite link
88+- **THEN** the system issues a joinable invite link for that organization
99+1010+#### Scenario: Owner revokes an invite link
1111+- **WHEN** the organization owner revokes an active invite link
1212+- **THEN** the system prevents that link from being used for new joins
1313+1414+### Requirement: Authenticated user can join organization through a valid invite link
1515+The system SHALL allow an authenticated user to join an organization through a valid invite link managed by that organization.
1616+1717+#### Scenario: User joins via valid invite
1818+- **WHEN** an authenticated user opens a valid organization invite link and accepts the invitation
1919+- **THEN** the system adds that user as a member of the organization
2020+2121+#### Scenario: User opens revoked or invalid invite link
2222+- **WHEN** an authenticated user opens an invalid or revoked organization invite link
2323+- **THEN** the system does not add them to the organization
2424+2525+### Requirement: Existing members are not duplicated through invite acceptance
2626+The system SHALL prevent duplicate membership when a user who is already a member opens a valid invite link for the same organization.
2727+2828+#### Scenario: Existing member opens valid invite
2929+- **WHEN** an authenticated user who already belongs to the organization accepts a valid invite link
3030+- **THEN** the system keeps a single membership record and does not create a duplicate
···11+## ADDED Requirements
22+33+### Requirement: Authenticated user can create an organization
44+The system SHALL allow an authenticated user to create an organization and SHALL make that user the owner of the new organization.
55+66+#### Scenario: User creates an organization
77+- **WHEN** an authenticated user submits a valid organization name
88+- **THEN** the system creates the organization and records that user as its owner
99+1010+### Requirement: Organization members share form-workspace permissions
1111+The system SHALL allow every member of an organization to create and manage forms, review responses, and export responses within that organization.
1212+1313+#### Scenario: Member works with organization forms
1414+- **WHEN** an authenticated member opens an organization workspace
1515+- **THEN** the system allows that member to use the same form-related features as any other non-owner member in that organization
1616+1717+### Requirement: Organization owner manages organization administration
1818+The system SHALL restrict organization rename, delete, membership management, and invite-link management to the organization owner.
1919+2020+#### Scenario: Owner renames organization
2121+- **WHEN** the organization owner updates the organization name
2222+- **THEN** the system saves the new organization name
2323+2424+#### Scenario: Owner removes a member
2525+- **WHEN** the organization owner removes a member from the organization
2626+- **THEN** the system revokes that member's access to the organization workspace
2727+2828+#### Scenario: Non-owner attempts organization administration
2929+- **WHEN** a non-owner member attempts to rename, delete, manage members, or manage invite links for the organization
3030+- **THEN** the system denies the request
3131+3232+### Requirement: Creator UI exposes personal and organization workspaces
3333+The system SHALL present a creator with their personal workspace and any organizations they belong to as selectable workspace contexts.
3434+3535+#### Scenario: User belongs to one or more organizations
3636+- **WHEN** an authenticated creator opens the creator experience
3737+- **THEN** the system shows the personal workspace plus each accessible organization as available workspace contexts
···11+## MODIFIED Requirements
22+33+### Requirement: Creator can export owned form responses in CSV and XLSX formats
44+The system SHALL allow an authenticated creator to export responses in CSV and XLSX formats for personal forms they own and organization forms belonging to organizations where they are members.
55+66+#### Scenario: Creator exports personal form responses as CSV
77+- **WHEN** an authenticated creator requests a CSV export for a personal form they own
88+- **THEN** the system downloads a CSV file containing that form's responses
99+1010+#### Scenario: Creator exports organization form responses as XLSX
1111+- **WHEN** an authenticated creator requests an XLSX export for a form belonging to an organization where they are a member
1212+- **THEN** the system downloads an XLSX file containing that form's responses
1313+1414+### Requirement: Export requests are restricted by form ownership
1515+The system SHALL allow response exports only for forms in workspaces the authenticated creator can access and SHALL deny export access for forms outside those workspaces.
1616+1717+#### Scenario: Creator exports inaccessible form
1818+- **WHEN** an authenticated creator requests an export for a form they do not own personally and that does not belong to an organization they are part of
1919+- **THEN** the system denies access and does not return response data
···11+## MODIFIED Requirements
22+33+### Requirement: Creator can list responses for owned forms
44+The system SHALL allow an authenticated creator to view submitted responses for personal forms they own and organization forms belonging to organizations where they are members, and SHALL prevent them from listing responses for forms outside those accessible workspaces.
55+66+#### Scenario: Creator opens responses for a personal form they own
77+- **WHEN** an authenticated creator opens the responses view for a personal form they own
88+- **THEN** the system displays the submitted responses for that form
99+1010+#### Scenario: Creator opens responses for an organization form in a joined organization
1111+- **WHEN** an authenticated creator opens the responses view for a form belonging to an organization where they are a member
1212+- **THEN** the system displays the submitted responses for that form
1313+1414+#### Scenario: Creator opens responses for an inaccessible form
1515+- **WHEN** an authenticated creator opens the responses view for a form they do not own personally and that does not belong to an organization they are part of
1616+- **THEN** the system denies access to that form's submitted responses
1717+1818+### Requirement: Creator can start response exports from the responses view
1919+The system SHALL present response export actions in the responses view for a form in a workspace the authenticated creator can access.
2020+2121+#### Scenario: Creator opens responses for an accessible form
2222+- **WHEN** an authenticated creator opens the responses view for a form in a workspace they can access
2323+- **THEN** the system displays available export actions for the supported response export formats
···11+## 1. Data model and migration
22+33+- [x] 1.1 Add Prisma models for organizations, memberships, and invite links.
44+- [x] 1.2 Add optional organization ownership fields to forms while preserving personal ownership.
55+- [x] 1.3 Generate and apply the migration for the new organization data model.
66+- [x] 1.4 Update shared TypeScript/domain types for workspace-aware forms and organization entities.
77+88+## 2. Workspace-aware authorization
99+1010+- [x] 2.1 Add shared server helpers for personal ownership, organization membership, and organization-owner checks.
1111+- [x] 2.2 Refactor form, response review, and response export access checks to use workspace-aware authorization.
1212+- [x] 2.3 Prevent non-owner members from performing organization admin actions.
1313+1414+## 3. Organization and invite flows
1515+1616+- [x] 3.1 Add server endpoints or actions to create, rename, and delete organizations.
1717+- [x] 3.2 Add server endpoints or actions to list members, remove members, and manage invite links.
1818+- [x] 3.3 Add the authenticated join flow for valid organization invite links.
1919+- [x] 3.4 Handle duplicate-member and revoked/invalid-invite cases cleanly.
2020+2121+## 4. Creator workspace UI
2222+2323+- [x] 4.1 Add creator UI for selecting the active personal or organization workspace.
2424+- [x] 4.2 Scope dashboard form listings to the active workspace.
2525+- [x] 4.3 Update form creation so a new form is created in the selected workspace.
2626+- [x] 4.4 Show workspace context in the builder and responses surfaces.
2727+- [x] 4.5 Add organization settings UI for owner-only admin actions and invite-link management.
2828+2929+## 5. Verification
3030+3131+- [x] 5.1 Verify personal-form flows still work after introducing organizations.
3232+- [x] 5.2 Verify organization members can create/manage forms and review/export responses in the organization workspace.
3333+- [x] 5.3 Verify non-member access is denied and non-owner org admin actions are denied.
3434+- [x] 5.4 Run the production build and fix any type, migration, or route issues introduced by the change.
···11## ADDED Requirements
2233### Requirement: Creator can create and manage form metadata
44-The system SHALL allow an authenticated creator to create a form draft and edit its title and shareable identity needed for public publishing.
44+The system SHALL allow an authenticated creator to create a form draft within their personal workspace or an organization workspace they belong to and edit the title and shareable identity for any form in an accessible workspace.
5566-#### Scenario: Creator creates a new form
77-- **WHEN** an authenticated creator creates a form
88-- **THEN** the system creates a new draft form owned by that creator
66+#### Scenario: Creator creates a new personal form
77+- **WHEN** an authenticated creator creates a form in their personal workspace
88+- **THEN** the system creates a new draft form in that creator's personal workspace
99+1010+#### Scenario: Creator creates a new organization form
1111+- **WHEN** an authenticated creator creates a form in an organization workspace they belong to
1212+- **THEN** the system creates a new draft form in that organization workspace
9131010-#### Scenario: Creator updates form title
1111-- **WHEN** an authenticated creator edits the title of an owned form
1414+#### Scenario: Creator updates an accessible form title
1515+- **WHEN** an authenticated creator edits the title of a form in a workspace they can access
1216- **THEN** the system saves the updated title for that form
13171418### Requirement: Creator can manage an ordered list of supported blocks
1515-The system SHALL allow an authenticated creator to add, select, edit, reorder, and remove blocks in a form using only the supported v0 block types: text, short text, long text, single choice, and multiple choice.
1919+The system SHALL allow an authenticated creator to add, select, edit, reorder, and remove blocks in a form located in an accessible workspace using only the supported v0 block types: text, short text, long text, single choice, and multiple choice.
16201721#### Scenario: Creator adds a block
1818-- **WHEN** an authenticated creator adds a supported block type to an owned form
2222+- **WHEN** an authenticated creator adds a supported block type to a form in an accessible workspace
1923- **THEN** the system appends the new block to the form with a stable block identifier
20242125#### Scenario: Creator reorders blocks
2222-- **WHEN** an authenticated creator changes the order of blocks in an owned form
2626+- **WHEN** an authenticated creator changes the order of blocks in a form in an accessible workspace
2327- **THEN** the system saves the new block order for the form
24282529#### Scenario: Creator removes a block
2626-- **WHEN** an authenticated creator removes a block from an owned form
3030+- **WHEN** an authenticated creator removes a block from a form in an accessible workspace
2731- **THEN** the system removes that block from the current form structure
28322933### Requirement: Builder exposes block editing through a master-detail layout
···4953- **THEN** the system allows content updates without exposing answer validation settings
50545155### Requirement: Creator can publish and unpublish forms
5252-The system SHALL allow an authenticated creator to publish or unpublish an owned form and SHALL expose a public shareable route only for published forms.
5656+The system SHALL allow an authenticated creator to publish or unpublish a form in an accessible workspace and SHALL expose a public shareable route only for published forms.
53575458#### Scenario: Creator publishes a form
5555-- **WHEN** an authenticated creator publishes an owned form
5959+- **WHEN** an authenticated creator publishes a form in an accessible workspace
5660- **THEN** the system marks the form as published and makes its public route available for respondents
57615862#### Scenario: Creator unpublishes a form
5959-- **WHEN** an authenticated creator unpublishes an owned form
6363+- **WHEN** an authenticated creator unpublishes a form in an accessible workspace
6064- **THEN** the system marks the form as unavailable for new public submissions
61656266### Requirement: Builder chrome stays focused on editing
···8488#### Scenario: Creator leaves follow-up link incomplete
8589- **WHEN** an authenticated creator leaves the follow-up link label or URL empty
8690- **THEN** the system does not save or expose a partial follow-up link for the form
9191+9292+### Requirement: Builder reflects the active workspace context
9393+The system SHALL show the active workspace context when a creator creates or edits a form so they can tell whether the form belongs to their personal workspace or an organization.
9494+9595+#### Scenario: Creator opens a form builder in an organization workspace
9696+- **WHEN** an authenticated creator opens a form that belongs to an organization workspace
9797+- **THEN** the system shows that organization context in the builder chrome
+10-6
openspec/specs/creator-auth/spec.md
···1212- **THEN** the system grants access to creator functionality associated with their account
13131414### Requirement: Creator ownership is enforced for managed forms
1515-The system SHALL allow creators to manage only forms they own and SHALL prevent access to editing, publishing, or response review for forms owned by other creators.
1515+The system SHALL allow creators to manage personal forms they own and organization forms belonging to organizations where they are members, and SHALL prevent access to editing, publishing, response review, or response export for forms outside those accessible workspaces.
16161717-#### Scenario: Creator opens an owned form
1818-- **WHEN** an authenticated creator requests a form they own
1717+#### Scenario: Creator opens a personal form they own
1818+- **WHEN** an authenticated creator requests a personal form they own
1919- **THEN** the system allows them to edit and manage that form
20202121-#### Scenario: Creator opens another creator's form
2222-- **WHEN** an authenticated creator requests a form they do not own
2323-- **THEN** the system denies access to form management and response review for that form
2121+#### Scenario: Creator opens an organization form in a joined organization
2222+- **WHEN** an authenticated creator requests a form belonging to an organization where they are a member
2323+- **THEN** the system allows them to manage that form according to organization membership access
2424+2525+#### Scenario: Creator opens another creator's inaccessible form
2626+- **WHEN** an authenticated creator requests a form they do not own personally and that does not belong to an organization they are part of
2727+- **THEN** the system denies access to form management, response review, and response export for that form
+11
openspec/specs/dashboard-form-views/spec.md
···4444#### Scenario: Creator opens a form from table view
4545- **WHEN** an authenticated creator uses a dashboard action in table view
4646- **THEN** the system allows direct navigation to the builder or responses for that form
4747+4848+### Requirement: Dashboard views are scoped to the active workspace
4949+The system SHALL scope dashboard form listings to the creator's selected personal or organization workspace.
5050+5151+#### Scenario: Creator views personal workspace dashboard
5252+- **WHEN** an authenticated creator selects their personal workspace in the dashboard
5353+- **THEN** the system shows only forms from that personal workspace
5454+5555+#### Scenario: Creator views organization workspace dashboard
5656+- **WHEN** an authenticated creator selects an organization workspace they belong to in the dashboard
5757+- **THEN** the system shows only forms from that organization workspace
+30
openspec/specs/organization-invites/spec.md
···11+## ADDED Requirements
22+33+### Requirement: Organization owner can create and revoke invite links
44+The system SHALL allow the organization owner to create invite links for that organization and SHALL allow the owner to revoke active invite links.
55+66+#### Scenario: Owner creates an invite link
77+- **WHEN** the organization owner creates an invite link
88+- **THEN** the system issues a joinable invite link for that organization
99+1010+#### Scenario: Owner revokes an invite link
1111+- **WHEN** the organization owner revokes an active invite link
1212+- **THEN** the system prevents that link from being used for new joins
1313+1414+### Requirement: Authenticated user can join organization through a valid invite link
1515+The system SHALL allow an authenticated user to join an organization through a valid invite link managed by that organization.
1616+1717+#### Scenario: User joins via valid invite
1818+- **WHEN** an authenticated user opens a valid organization invite link and accepts the invitation
1919+- **THEN** the system adds that user as a member of the organization
2020+2121+#### Scenario: User opens revoked or invalid invite link
2222+- **WHEN** an authenticated user opens an invalid or revoked organization invite link
2323+- **THEN** the system does not add them to the organization
2424+2525+### Requirement: Existing members are not duplicated through invite acceptance
2626+The system SHALL prevent duplicate membership when a user who is already a member opens a valid invite link for the same organization.
2727+2828+#### Scenario: Existing member opens valid invite
2929+- **WHEN** an authenticated user who already belongs to the organization accepts a valid invite link
3030+- **THEN** the system keeps a single membership record and does not create a duplicate
+37
openspec/specs/organizations/spec.md
···11+## ADDED Requirements
22+33+### Requirement: Authenticated user can create an organization
44+The system SHALL allow an authenticated user to create an organization and SHALL make that user the owner of the new organization.
55+66+#### Scenario: User creates an organization
77+- **WHEN** an authenticated user submits a valid organization name
88+- **THEN** the system creates the organization and records that user as its owner
99+1010+### Requirement: Organization members share form-workspace permissions
1111+The system SHALL allow every member of an organization to create and manage forms, review responses, and export responses within that organization.
1212+1313+#### Scenario: Member works with organization forms
1414+- **WHEN** an authenticated member opens an organization workspace
1515+- **THEN** the system allows that member to use the same form-related features as any other non-owner member in that organization
1616+1717+### Requirement: Organization owner manages organization administration
1818+The system SHALL restrict organization rename, delete, membership management, and invite-link management to the organization owner.
1919+2020+#### Scenario: Owner renames organization
2121+- **WHEN** the organization owner updates the organization name
2222+- **THEN** the system saves the new organization name
2323+2424+#### Scenario: Owner removes a member
2525+- **WHEN** the organization owner removes a member from the organization
2626+- **THEN** the system revokes that member's access to the organization workspace
2727+2828+#### Scenario: Non-owner attempts organization administration
2929+- **WHEN** a non-owner member attempts to rename, delete, manage members, or manage invite links for the organization
3030+- **THEN** the system denies the request
3131+3232+### Requirement: Creator UI exposes personal and organization workspaces
3333+The system SHALL present a creator with their personal workspace and any organizations they belong to as selectable workspace contexts.
3434+3535+#### Scenario: User belongs to one or more organizations
3636+- **WHEN** an authenticated creator opens the creator experience
3737+- **THEN** the system shows the personal workspace plus each accessible organization as available workspace contexts
+8-8
openspec/specs/response-export/spec.md
···11## ADDED Requirements
2233### Requirement: Creator can export owned form responses in CSV and XLSX formats
44-The system SHALL allow an authenticated creator to export responses for a form they own in CSV and XLSX formats.
44+The system SHALL allow an authenticated creator to export responses in CSV and XLSX formats for personal forms they own and organization forms belonging to organizations where they are members.
5566-#### Scenario: Creator exports owned form responses as CSV
77-- **WHEN** an authenticated creator requests a CSV export for a form they own
66+#### Scenario: Creator exports personal form responses as CSV
77+- **WHEN** an authenticated creator requests a CSV export for a personal form they own
88- **THEN** the system downloads a CSV file containing that form's responses
991010-#### Scenario: Creator exports owned form responses as XLSX
1111-- **WHEN** an authenticated creator requests an XLSX export for a form they own
1010+#### Scenario: Creator exports organization form responses as XLSX
1111+- **WHEN** an authenticated creator requests an XLSX export for a form belonging to an organization where they are a member
1212- **THEN** the system downloads an XLSX file containing that form's responses
13131414### Requirement: Export requests are restricted by form ownership
1515-The system SHALL allow response exports only for forms owned by the authenticated creator and SHALL deny export access for forms owned by others.
1515+The system SHALL allow response exports only for forms in workspaces the authenticated creator can access and SHALL deny export access for forms outside those workspaces.
16161717-#### Scenario: Creator exports another creator's form
1818-- **WHEN** an authenticated creator requests an export for a form they do not own
1717+#### Scenario: Creator exports inaccessible form
1818+- **WHEN** an authenticated creator requests an export for a form they do not own personally and that does not belong to an organization they are part of
1919- **THEN** the system denies access and does not return response data
20202121### Requirement: Export output uses one row per submission with stable columns
+12-8
openspec/specs/response-review/spec.md
···11## ADDED Requirements
2233### Requirement: Creator can list responses for owned forms
44-The system SHALL allow an authenticated creator to view submitted responses for forms they own and SHALL prevent them from listing responses for forms owned by others.
44+The system SHALL allow an authenticated creator to view submitted responses for personal forms they own and organization forms belonging to organizations where they are members, and SHALL prevent them from listing responses for forms outside those accessible workspaces.
5566-#### Scenario: Creator opens responses for an owned form
77-- **WHEN** an authenticated creator opens the responses view for a form they own
66+#### Scenario: Creator opens responses for a personal form they own
77+- **WHEN** an authenticated creator opens the responses view for a personal form they own
88- **THEN** the system displays the submitted responses for that form
991010-#### Scenario: Creator opens responses for another creator's form
1111-- **WHEN** an authenticated creator opens the responses view for a form they do not own
1010+#### Scenario: Creator opens responses for an organization form in a joined organization
1111+- **WHEN** an authenticated creator opens the responses view for a form belonging to an organization where they are a member
1212+- **THEN** the system displays the submitted responses for that form
1313+1414+#### Scenario: Creator opens responses for an inaccessible form
1515+- **WHEN** an authenticated creator opens the responses view for a form they do not own personally and that does not belong to an organization they are part of
1216- **THEN** the system denies access to that form's submitted responses
13171418### Requirement: Creator can inspect a single response in form order
···2327- **THEN** the system shows only answerable block responses while preserving the form order context for the submission
24282529### Requirement: Creator can start response exports from the responses view
2626-The system SHALL present response export actions in the responses view for a form owned by the authenticated creator.
3030+The system SHALL present response export actions in the responses view for a form in a workspace the authenticated creator can access.
27312828-#### Scenario: Creator opens responses for an owned form
2929-- **WHEN** an authenticated creator opens the responses view for a form they own
3232+#### Scenario: Creator opens responses for an accessible form
3333+- **WHEN** an authenticated creator opens the responses view for a form in a workspace they can access
3034- **THEN** the system displays available export actions for the supported response export formats