Workspaces

Try a personal workspace and a team

A workspace is a separate container for accounts, content and permissions. Complete database-backed sign-in first. Open the dashboard and note the current workspace name. Use the workspace switcher to choose another workspace you belong to; the displayed records should change to that workspace's records.

To try a team, follow Organizations to create one, invite a second test email and accept that invitation in a private browser window signed in as that second account. Confirm a member sees that team's records while an unrelated account cannot open them. Owner and admin roles manage the team; member access is narrower. Keep the two accounts in separate browser sessions during this test.

If you ask an agent to add a new product table or screen, explicitly request workspaceId on every user-owned record and server-side membership checks for every read and write. A workspace ID in a URL identifies the workspace; it does not grant access. Have the agent test an unrelated account before using the screen with real customer data.

• Create a team and invite members
• Verify records stay private to their workspace

Resolve the workspace from the session

Personal workspaces give each user an ownership boundary. The server resolves the current workspace from trusted authentication context. Client-supplied IDs must never replace that check.

Scope reads and writes

Include workspaceId in every user-owned lookup or mutation. A detail route needs the same isolation as a list route. Task IDs, recovery URLs, and idempotency keys identify work but do not authorize access.

Apply this rule to your product tables as well as the shared task, usage, and provider configuration records.

Test cross-workspace denial

Create two independent workspace contexts. Verify that the owner can read and change their record, the other workspace cannot, and an anonymous request is rejected. Confirm rejected writes leave the persisted record unchanged.