The Design Registry

Teammates, Teams, Role Labels & Notifications

Document: 03 - Teammates, Teams, Role Labels & Notifications
Version: 3.0
Prepared: August 2026
Status: Archived implementation baseline — complete
Primary audience: Product, design, engineering, QA and operations

1. Executive Summary

The Design Registry is a multi-organization operating platform for independent interior designers, clients and specialized Providers. The identity system must support people who participate in several organizations and projects without creating duplicate accounts, leaking data between workspaces or forcing each Provider category into a separate application.

This specification defines the production foundation behind the four existing Settings experiences at /admin/settings/teammates, /admin/settings/teams, /admin/settings/roles and /admin/settings/notifications. It preserves the current shared shell and enterprise data-grid patterns while replacing prototype-only data behavior with a durable multi-workspace model.

This specification defines:

• Global user identity
• Google and email/password authentication
• Workspace creation and organization identity
• Team invitations
• Workspace memberships
• Workspace switching
• Owner and teammate administration
• Team creation, leadership and membership
• Workspace-defined Role Labels
• A strict separation between descriptive role labels and future permissions
• Resend-powered transactional email delivery
• The shared Notification Builder, template registry and in-app notification model
• Stable capability hooks for a later Permissions specification
• Limited external and application access
• Security, audit and notification requirements
• Supabase-oriented data and service architecture

The central model is:

Person
  └── User account
        ├── Membership in Designer Studio A
        ├── Membership in Provider Workspace B
        ├── Client access to Project C
        └── Pending application access for Provider Category D

A User is never duplicated merely because the person joins another organization. A workspace role never changes the person's global identity. A pending Provider application never blocks access to the person's other active workspaces.

The primary product principle is:

One person. Many relationships. Explicit access. No accidental visibility.

The companion operating principle is:

Teams organize people. Role labels describe people. Permissions authorize actions. Notifications explain what happened and what requires attention.

2. Business Context

The Design Registry succeeds when Designers and Providers conduct real work inside the platform. This requires onboarding additional participants without making access management feel like enterprise software.

Typical users include:

• A solo Designer who owns a Designer Studio workspace
• A growing Designer Studio with Designers, Project Managers and procurement staff
• A warehouse owner with receiving and floor staff
• A white-glove delivery company with dispatchers, drivers and installers
• A millwork company with estimators, project managers and shop staff
• A photographer who works alone
• A client invited to one or more Projects
• A person who belongs to both a Provider company and a Designer Studio
• Design Registry administrators operating the network

The platform must feel simple to each user while retaining enterprise-grade separation and auditability underneath.

2.1 Existing product review

The production shell reviewed in August 2026 already establishes the intended Settings navigation:

Settings
├── Teammates        /admin/settings/teammates
├── Teams            /admin/settings/teams
├── Role Labels      /admin/settings/roles
├── Project Builder
├── Pipeline Builder
├── Notifications    /admin/settings/notifications
└── Data Reconciliation

The revised specification treats those four people-and-communication areas as separate settings pages, not tabs nested under Teammates.

The current shell also establishes reusable patterns that should be retained:

• Settings-specific left navigation with an Exit Settings action
• Page kicker, title, description and a right-aligned primary action
• Metric cards
• Enterprise data grids with selection, sorting, export and column controls
• Empty, loading and partial-failure states
• A Notification Builder with definition counts, search and an editor region

The reviewed shell is not yet production-complete. Observed gaps include:

• The Teammates directory can enter a temporary-unavailable state while displaying zero metrics.
• Teams and Role Labels can remain indefinitely in an access-loading state.
• The Teammates page does not expose the invite action when access resolution fails.
• Notification definitions may be empty, leaving the editor with no actionable guidance.
• Legacy Proper Gallery branding remains visible in part of the Teammates experience and browser title.
• Current loading and failure states do not distinguish authorization, connectivity, missing configuration and empty data.

Implementation must preserve the design language while correcting these gaps. A failed summary request must not make successfully loaded records disappear. Branding must use The Design Registry consistently.

3. Goals and Success Measures

3.1 Product goals

1. Allow a person to create or access one global User account.
2. Allow that User to belong to multiple Workspaces safely.
3. Allow a Workspace Owner to invite and manage teammates without support intervention.
4. Keep Role Labels and Team structure flexible for each business.
5. Prepare for detailed permissions without placing a full permissions builder in this release.
6. Support Provider application access before Provider workspace approval.
7. Support Project-scoped client and Provider participation.
8. Make membership and access changes auditable and reversible where appropriate.
9. Establish a reusable identity foundation for every future module.

3.2 Success measures

• At least 90% of valid teammate invitations are accepted without support.
• Median invitation-to-first-session time is measurable.
• Duplicate User creation caused by joining a second Workspace is effectively eliminated.
• Workspace-crossing authorization incidents are zero.
• Owners can complete common teammate administration within two minutes.
• Membership removal takes effect on protected APIs immediately.
• Invitation, authentication and membership events have complete audit records.
• All identity and membership experiences meet WCAG 2.2 AA expectations.

3.3 Non-goals

This specification does not define:

• The full permission-matrix builder
• Fine-grained project financial permissions
• Provider application review workflows
• Provider qualification and matchmaking
• Commercial Offer, Proposal or Work Order access rules
• Billing plans or seat-based subscription rules
• Human-resources records, payroll or time-off management
• Public Provider or Designer profiles

Those systems reference this identity foundation but are governed elsewhere.

4. Product Principles

4.1 A User is a person

Authentication credentials and personal profile data belong to the person, not to an organization.

4.2 A Workspace is an organization

The workspace stores business identity, teammates, operating configuration and organization-owned records.

4.3 Membership creates the relationship

Workspace-specific title, Role Labels, Teams, status and operating identity belong to the Membership relationship.

4.4 Access is contextual

Authorization evaluates the User, active Workspace, Membership, capability and record scope. It never relies on a role label alone.

4.5 Invitations are safe and understandable

Invitations clearly identify the inviting organization and do not create hidden duplicate accounts.

4.6 Removal is immediate but history remains

Removing access prevents future protected actions while preserving historical authorship and business audit records.

4.7 Build once, reuse everywhere

Authentication, identity, invitation, membership and access components are shared across Designer, Provider, client and administrator experiences.

5. Terminology

5.1 User

A globally unique authenticated person.

5.2 User Profile

Person-controlled identity information such as name, profile photo, preferred contact information, time zone and locale.

5.3 Workspace

The secure organization environment in which records and configuration are owned.

Workspace types include:

• registry_admin
• designer_studio
• provider
• client_organization, future or optional

5.4 Workspace Profile

Organization-controlled business identity. The detailed profile UX is governed by Specification 04.

5.5 Workspace Membership

The relationship between a User and Workspace.

5.6 Workspace Owner

The accountable member with protected ownership authority. Every active Workspace has exactly one active Owner.

5.7 Teammate

An active or invited person associated with a Workspace through an invitation or Membership.

5.8 Role Label

A customer-facing descriptive label such as Project Manager, Dispatcher or Finance. It is not a permission bundle.

5.9 Capability

A stable system key representing an action or area of authority. Capability configuration is finalized in a separate Permissions specification.

5.10 Access Grant

A limited, auditable and revocable relationship allowing access without ordinary organization membership or beyond its normal record scope.

5.11 Active Workspace

The Workspace currently selected for navigation, data queries and authorization context.

5.12 Invitation

A time-limited request for a person at a specific email address to join a Workspace.

6. Identity Architecture

6.1 Required separation

auth identity
    ↓
User
    ↓
User Profile
    ↓
Workspace Memberships
    ↓
Workspace-owned records and scoped Access Grants

Authentication proves control of an identity. It does not itself grant access to a Workspace, application, Project or commercial record.

6.2 Global identity rules

• One User can have multiple authentication identities when safely linked.
• One authentication identity cannot belong to multiple Users.
• Email comparison uses normalized email for identity discovery while preserving original display casing.
• Email is not used as the permanent foreign key for business records.
• Changing email does not change User ID, Memberships, authorship or history.
• User IDs are opaque UUIDs.
• Deactivated Users remain referentially valid in historical records.

6.3 Account linking

If a User signs in with Google using an email matching a verified email/password identity, the system may offer safe account linking after authentication and risk checks.

The platform must not automatically merge two established Users based only on matching unverified email strings.

Account linking records:

• Existing User
• Added identity provider
• Provider subject identifier
• Verified email at the time of linking
• Linking method
• Timestamp
• Session and audit information

6.4 Duplicate account recovery

When support identifies duplicate Users:

1. Verify identity ownership.
2. Select the surviving User.
3. Move eligible Memberships and personal preferences.
4. Detect Membership conflicts.
5. Preserve authorship mappings.
6. Revoke sessions for the duplicate User.
7. Record a protected merge audit event.
8. Mark the duplicate as merged rather than deleting it.

An administrator tool for this is future scope, but the schema must not make safe merging impossible.

7. Authentication Experience

7.1 Sign-in page

Required elements:

• The Design Registry identity
• Continue with Google
• Email field
• Password field
• Show/hide password
• Sign in
• Forgot password
• Link to create an account
• Terms and Privacy links
• Clear loading and error states

Authentication pages use the same refined black-and-white design system as the product: high contrast, generous spacing, elegant typography, rounded controls and restrained messaging.

7.2 Google sign-in

Flow:

Select Continue with Google
→ OAuth consent
→ Validate provider response/state/nonce
→ Resolve or create identity
→ Resolve User
→ Determine valid destinations
→ Enter last valid Workspace or Workspace Chooser

Cancelled OAuth returns to the sign-in page without an alarming error.

7.3 Email/password sign-up

Fields:

• First name
• Last name
• Email
• Password
• Confirm password
• Agreement checkbox

Requirements:

• Display password requirements before failure.
• Prevent common compromised passwords where supported.
• Verify email before granting protected access.
• Do not create a Workspace unless the initiating journey requires one.
• Preserve invitation/application context across verification.

7.4 Email verification

• Verification links are single-use and expiring.
• A replacement invalidates or supersedes prior links according to provider behavior.
• The verification landing page explains the next step.
• If opened on another device, the user may be asked to authenticate.
• A verified User returns to the invitation, application or workspace journey that initiated signup.

7.5 Forgot password

The request form always returns a neutral response:

If an account exists for this email, password reset instructions have been sent.

Reset links are single-use, expiring and protected against token leakage. Successful reset revokes other password-based sessions according to security policy and sends a security notification.

7.6 Session behavior

• Sessions have idle and absolute expiration policies.
• Refresh tokens are rotated according to Supabase Auth best practices.
• Sign out current session is always available.
• Sign out all sessions requires recent authentication.
• High-risk operations may require reauthentication.
• Suspended Memberships cannot continue using cached Workspace access.
• Session state does not contain the only source of authorization truth.

7.7 Authentication errors

Use clear but non-enumerating language for:

• Invalid credentials
• Unverified email
• Expired link
• Used link
• OAuth cancelled
• Rate limit
• Temporarily unavailable authentication provider
• Account requiring support review

8. Entry Routing After Authentication

8.1 Destination resolution

After authentication, resolve in this order:

1. Valid signed invitation continuation
2. Valid pending application continuation
3. Explicit deep link the User is authorized to access
4. Last active valid Workspace
5. Only active Workspace
6. Workspace Chooser
7. No-access recovery screen

8.2 No-access recovery

A User with no active Membership and no valid Access Grant sees:

• Join through an invitation
• Continue a saved application, if any
• Create a Designer Studio workspace, if allowed
• Apply as a Provider
• Contact support

The screen must not create a blank Provider Workspace that bypasses approval.

9. Workspace Model

9.1 Workspace creation paths

Designer Studio:

• Created through authorized onboarding
• User becomes Owner
• Workspace begins in onboarding state

Provider:

• Provisioned through Provider approval under Specification 05
• Existing provisional data is reconciled
• Applicant becomes Owner Membership

Registry administration:

• Created only through controlled administration

Client access:

• Normally uses Project Access Grants rather than creating a full organization Workspace for every household

9.2 Workspace states

provisioning → onboarding → active
                         ↘ restricted
                         ↘ suspended
                         ↘ archived

State definitions:

• provisioning: system transaction incomplete
• onboarding: usable but setup incomplete
• active: normally operational
• restricted: limited due to verification, risk or configuration
• suspended: protected access blocked except recovery/contact paths
• archived: organization no longer operates; history retained

9.3 Workspace ownership

Rules:

• Exactly one active Owner exists.
• Owner is represented by a protected ownership relation, not merely the role label “Owner.”
• Owner cannot remove or suspend themselves without a completed transfer.
• Workspace archiving requires Owner authority and recent authentication.
• Registry administrators cannot silently become Workspace Owner.

10. Membership Lifecycle

10.1 States

invited → active → suspended → active
             ↓          ↓
          removed    removed

Additional terminal/context states may include:

• invitation_expired
• invitation_revoked
• left_workspace

10.2 Invited

An Invitation exists, but no active Membership authority exists. A placeholder may appear in Teammates as Invited.

10.3 Active

The User can enter the Workspace subject to system access level, capability and record-scope checks. Role Labels do not authorize entry.

10.4 Suspended

The User remains associated for audit and may be reactivated, but cannot access protected Workspace data.

10.5 Removed

The relationship is terminated. Historical authorship remains. Reactivation should normally create a new active Membership event rather than rewriting history.

10.6 Effective authorization

Every protected request evaluates:

authenticated User
+ active Workspace
+ active Membership or valid Access Grant
+ required capability
+ permitted record relationship
+ workspace/record state
= allow or deny

11. Settings Information Architecture

11.1 Navigation decision

The existing Settings navigation is the approved information architecture:

People & Access
├── Teammates
├── Teams
└── Role Labels

Communications
└── Notifications

These are distinct pages that reuse the same settings shell. Do not collapse them into tabs inside a single Teammates page. Direct URLs remain stable so notification links, support instructions and browser history resolve predictably.

Detailed per-capability configuration is deferred to the separate Permissions specification. The UI may show a concise read-only access summary, but Role Labels and Teams never become hidden permission editors.

11.2 Shared page anatomy

Each page uses:

• Settings category kicker
• Page title and plain-language description
• Primary action when the current member is authorized
• Metric cards only when the metrics help a decision
• Search and filters appropriate to the record type
• Shared enterprise data grid
• Bulk actions when safe
• Empty, loading, partial-failure, forbidden and retry states
• Activity and audit events for material changes

Page data must load independently. Summary cards, the grid and primary-action authority may be separate requests or projections. Failure in one region must not automatically blank every other region.

11.3 Teammates page

Route: /admin/settings/teammates

Purpose: invite people, manage Workspace relationships and preserve a clear record of who did what.

Header metrics:

• Active teammates
• Pending invitations
• Teams
• Custom role labels

Primary action: Invite teammate.

The page uses one directory that can include active Memberships and pending invitations. Status chips make the distinction explicit. The directory must not show a fabricated zero state while a request has failed.

Default grid columns, aligned to the current shell:

• Selection
• Teammate: avatar, preferred name and email
• Role labels: zero or more descriptive labels
• Teams: zero or more Team memberships
• Access level: Owner, Teammate or Limited participant as a system relationship
• Job title: Workspace-specific free-text title
• Access: Active, Invited, Suspended, Removed or Expired
• Last active
• Actions

Grid behavior:

• Search name, email, title, Team and Role Label
• Filter by Membership state, invitation state, Team, Role Label and access level
• Sort by the options present in the shell plus joined date and last active
• Select visible rows and support authorized bulk assignment
• Export only authorized, non-sensitive directory fields
• Configure columns through the shared Columns control
• Preserve filter and column state per User and Workspace
• Use accessible pagination or virtualization for large workspaces

Row actions vary by state:

• Active: view details, edit Workspace details, assign Teams, assign Role Labels, suspend or remove
• Invited: view delivery, resend, edit intended Teams/labels/title, copy link if allowed or revoke
• Suspended: view history, reactivate or remove
• Removed/expired: view history and send a new invitation when appropriate

11.4 Teams page

Route: /admin/settings/teams

Purpose: group teammates by location, discipline or operating group without changing their Workspace access.

Primary action: Create team.

Default grid columns:

• Selection
• Team name
• Description or purpose
• Members
• Team lead
• Related location or discipline, optional
• Status
• Last updated
• Actions

The shell's existing Team, Members and Team lead columns remain the minimum viable presentation.

11.5 Role Labels page

Route: /admin/settings/roles

Purpose: customize the descriptive labels used across invitations, Teams, Projects and Assignments.

Primary action: Create role label.

Default grid columns:

• Selection
• Role label
• Description
• Teammates
• Default on invite
• Status
• Last updated
• Actions

The shell's existing Role label, Teammates and Default on invite columns remain the minimum viable presentation.

11.6 Notifications Builder page

Route: /admin/settings/notifications

Purpose: maintain standardized notification definitions and published channel templates inherited by Designer, Provider, Client and Registry workspaces.

The existing split view is retained:

• Summary cards for Definitions, Published templates and Drafts
• Searchable definition list in the left rail
• Definition and template editor in the main region

The page must ship with the mandatory system notification registry. A zero-definition production state is a configuration error, not a normal blank workspace.

11.7 Responsive behavior

On smaller screens:

• Settings navigation becomes a labelled drawer or back-linked section menu.
• Metric cards become a horizontally scrollable or two-column set without losing labels.
• Data grids use a prioritized card/list representation or controlled horizontal scrolling.
• Bulk actions appear only after selection.
• Member, Team and Role Label editors become full-screen sheets.
• The Notification Builder list becomes a selection screen followed by a full-screen editor.

12. Teams

12.1 Product purpose

A Team is an organization-owned grouping of active Workspace Memberships. Teams help people filter work, route notifications, assign responsibility and understand the business structure. They do not independently grant access to records or actions.

Examples include:

• Ottawa Studio
• Toronto Studio
• Design Team
• Procurement
• Finance
• Receiving
• Warehouse Floor
• Dispatch
• Delivery Crew A
• Photography
• Estimating
• Installation

Workspaces may organize Teams by location, discipline, department, crew or another customer-defined model. The product does not force a universal hierarchy.

12.2 Core rules

• A Workspace may have any reasonable number of Teams.
• A Teammate may belong to zero, one or many Teams.
• Only active Workspace Memberships can be active Team members.
• Each Team may have zero or one designated Team Lead in the initial release.
• The Team Lead must be an active member of that Team.
• A Team may reference one Workspace location when location support exists.
• Team membership does not override Project, Work Order or future permission rules.
• Removing a person from a Team does not remove the person's Workspace Membership.
• Suspending or removing a Membership makes every Team membership inactive immediately.
• Historical Team references remain readable in Activity and reporting.

12.3 Create Team flow

Fields:

• Team name, required and unique within active Teams in the Workspace
• Description, optional
• Team Lead, optional
• Members, optional at creation
• Location, optional
• Team type, optional customer-defined classification
• Notification routing eligibility, enabled by default

Flow:

Select Create team
→ enter identity and purpose
→ optionally select lead and members
→ validate active Memberships and duplicate name
→ save Team and Team memberships atomically
→ write Activity and audit events
→ show Team detail

12.4 Team detail

The Team detail drawer or page displays:

• Name and description
• Lead
• Member count and active members
• Location or classification
• Related active Projects, Tasks or Work Orders when those modules opt into Team assignment
• Notification subscriptions or routing rules that reference the Team
• Created by, created date and last updated
• Activity history

Team-related work is a projection of source records. The Team does not own duplicate Project or Task records.

12.5 Team membership management

Authorized Workspace administrators can:

• Add one or more active Teammates
• Remove one or more Team memberships
• Set or replace the Team Lead
• Move selected Teammates between Teams
• Copy selected Teammates into another Team
• Bulk assign a Team from the Teammates directory

Before removing a Team Lead, require selection of a replacement or explicit confirmation that the Team will have no lead.

12.6 Team assignment to work

Modules may reference a Team as an operational owner or routing audience, but the assigned individual remains visible where accountability requires it.

Examples:

• A Project Task is assigned to Procurement with one accountable Owner.
• A warehouse exception notifies the Receiving Team.
• A delivery Work Order is associated with Dispatch and Delivery Crew A.
• A Registry-generated lead is routed to an internal market Team.

Team assignment must not silently expose a Project to every Team member. Authorization still evaluates Workspace Membership, record relationship and future capability rules.

12.7 Archive Team

Teams are archived, not hard deleted, after use.

Before archive, show:

• Active members
• Active work references
• Notification rules
• Pending assignments
• Team Lead

Blocking references must be reassigned or explicitly resolved. Historical activity continues to display the archived Team name.

12.8 Team notifications

Required events include:

• team.created
• team.updated
• team.member_added
• team.member_removed
• team.lead_assigned
• team.lead_removed
• team.archived

Not every event sends a message. Each event is registered so the Notification Builder can determine whether an in-app or email template is enabled and who should receive it.

12.9 Team acceptance criteria

• Teams page reflects the existing grid design.
• Authorized Owners can create and edit Teams.
• One Teammate may belong to multiple Teams.
• Team Lead must be an active Team member.
• Team membership never changes authorization by itself.
• Bulk Team assignment uses one transactional service.
• Archived Teams cannot receive new assignments.
• Team changes appear in Activity and protected audit records where appropriate.

13. Role Labels

13.1 Product purpose

Role Labels are customer-defined descriptors that make The Design Registry feel native to each business. A Designer Studio may use Designer, Project Manager and Procurement. A warehouse may use Receiving, Inventory and Warehouse Manager. A delivery company may use Dispatcher, Driver and Crew Lead.

Role Labels answer what this person does. They do not answer what this person is allowed to access or change.

13.2 Separation from permissions

This is a hard architectural rule:

Role Label = customer-facing description
Team = organizational grouping
Job Title = free-text employment or operating title
Ownership = protected system relationship
Permission = future authorization configuration

Product code must not contain checks such as role_name == "Project Manager". A customer can rename any non-protected Role Label without changing system behavior.

The separate Permissions specification will define capabilities, permission sets, record scopes and administrative authority. This document only requires stable hooks so that future permissions can attach to Memberships without corrupting Role Labels.

13.3 Default suggestions by Workspace type

Designer Studio suggestions:

• Studio Owner
• Studio Administrator
• Designer
• Project Manager
• Procurement
• Finance
• Assistant

Vendors and Product Suppliers:

• Owner
• Sales
• Trade Account Manager
• Order Desk
• Customer Service
• Finance

Millwork and Custom Fabrication:

• Owner
• Estimator
• Project Manager
• Drafting
• Shop Manager
• Installer
• Finance

Contractors and Specialty Trades:

• Owner
• Estimator
• Project Manager
• Site Supervisor
• Trade Professional
• Finance

Photography:

• Owner
• Photographer
• Producer
• Editor
• Assistant

Measurement and Drafting:

• Owner
• Surveyor
• Drafter
• Reviewer
• Scheduler

Receiving, Warehouse and Storage:

• Owner
• Operations Manager
• Receiving
• Inventory and Storage
• Warehouse Floor
• Finance

White-Glove Delivery:

• Owner
• Dispatcher
• Driver
• Crew Lead
• Delivery Crew
• Finance

Installation Services:

• Owner
• Project Manager
• Installer
• Crew Lead
• Deficiency Coordinator
• Finance

General Service Providers receive a short generic set and may customize it.

13.4 Role Label fields

• Name, required
• Description, optional
• Workspace, required
• Status: active or archived
• Default on invite, boolean
• Display order
• Optional neutral colour token drawn from an accessible palette
• Created by and timestamps

Only one Role Label may be the default on invite for a Workspace in the initial release. A Workspace may choose no default.

13.5 Assignment rules

• A Teammate may have zero, one or several Role Labels.
• Invitations may include one or more intended Role Labels.
• Accepted invitations copy intended labels to the Membership atomically.
• Labels may be assigned from the Role Label page, Teammate detail or invitation form.
• Archived labels remain on historical events but cannot be assigned.
• Removing a label does not suspend the Membership or remove record access.

13.6 Create and edit flow

Creation validates normalized uniqueness within active Workspace labels. Editing a name updates its presentation everywhere without changing immutable IDs or history.

The edit experience shows:

• Label identity and description
• Number of assigned active Teammates
• Whether it is the invitation default
• Recent assignment activity
• A clear statement that permissions are managed separately

13.7 Archive and reassignment

If a Role Label is assigned, archive offers:

1. Reassign all active Teammates to another label and archive.
2. Remove the label from active Teammates and archive.
3. Cancel.

The system must not require replacement if Teammates are allowed to have no Role Label. Every result is audited.

13.8 Role Label notifications

Required events include:

• role_label.created
• role_label.updated
• role_label.assigned
• role_label.unassigned
• role_label.default_changed
• role_label.archived

Assignment and removal notifications are off by default unless the change materially affects onboarding or a Workspace enables them. Activity is still recorded.

13.9 Role Label acceptance criteria

• Role Labels page reflects the current grid design.
• Workspace can create, rename, reorder and archive labels.
• One Teammate can hold multiple labels.
• One optional default invite label is enforced transactionally.
• Label changes never grant or revoke authority.
• No application code authorizes by customer-editable label text.
• Archived labels remain intelligible in history.
• Permissions are clearly identified as a separate future configuration area.

14. Invite Teammate Flow

14.1 Entry points

• Settings → Teammates → Invite teammate
• Empty-state action
• Workspace onboarding checklist
• Future Project workflow that prompts an Owner to invite staff

All entry points use the same invitation component and service.

14.2 Form fields

• Email address, required
• First name, optional
• Last name, optional
• Workspace title, optional
• Role Labels, optional; use the Workspace default when configured
• Teams, optional
• Personal welcome message, optional

14.3 Validation

• Validate normalized email format.
• Prevent duplicate pending invitations in the same Workspace.
• If the User is already active, offer to edit their Membership instead.
• If removed or suspended, explain reactivation options.
• Prevent inviting an email explicitly blocked by security policy.
• Confirm the inviter still has authority at submission time.

14.4 Confirmation

Before sending, show:

• Recipient email
• Workspace name
• Intended Role Labels and Teams
• Summary of what acceptance provides

For unusually sensitive roles, require an additional confirmation when the future Permissions specification marks them as elevated.

14.5 Email content

Invitation email contains:

• Inviting person
• Workspace name
• The Design Registry identity
• Role Label and job-title context
• Accept invitation action
• Expiration date
• Security note if the recipient did not expect the invitation

Do not include private Workspace or Project details in the email.

14.6 Existing User acceptance

Open invitation
→ authenticate if needed
→ verify intended email or approved alternate-email policy
→ review Workspace, Role Labels and Teams
→ accept
→ create active Membership atomically
→ enter Workspace onboarding/dashboard

14.7 New User acceptance

Open invitation
→ create User through Google or email/password
→ verify identity
→ return to invitation
→ accept
→ create Membership
→ complete minimal personal profile
→ enter Workspace

14.8 Expired or revoked invitation

Explain that the invitation is unavailable and provide a safe way to request a new invitation from the Workspace without revealing additional Workspace data.

15. Member Detail Experience

Open as a right-side drawer on desktop and full-screen sheet on mobile.

15.1 Summary

• Avatar
• Name
• Email
• Workspace title
• Role Labels
• Teams
• Membership state
• Joined date
• Last active

15.2 Workspace details

Owner-editable:

• Workspace title
• Role Label assignments
• Team assignments
• Contact visibility settings, future

The Owner cannot edit the member's global legal or personal identity.

15.3 Assigned work summary

Read-only links, subject to authority:

• Active Projects or Provider Jobs
• Open tasks
• Commercial assignments
• Calendar assignments

The summary consumes shared module projections; it does not duplicate ownership data.

15.4 Security and access summary

• Membership state
• Role Labels and Teams
• Last active session in this Workspace
• Access restrictions
• Active Project or application grants where authorized

15.5 Activity

Show material membership history:

• Invited
• Invitation accepted
• Title changed
• Role Labels changed
• Team assignments changed
• Suspended/reactivated
• Ownership transferred
• Removed

16. Membership Administration

16.1 Change Role Labels or Teams

• Show current and proposed labels or Team assignments.
• Save atomically.
• Do not imply the descriptive change alters permissions.
• Notify affected member according to policy.
• Audit actor, before/after and reason when required.

16.2 Suspend member

Use when access should stop temporarily.

Confirmation shows consequences:

• Immediate loss of Workspace access
• Assignments and history remain
• Tasks/work may require reassignment
• User retains access to other Workspaces

Suspension does not delete authored records.

16.3 Reactivate member

Restores the existing Membership when safe. Re-evaluate the system access level, Team assignments and any expired record grants before activation.

16.4 Remove member

Removal confirmation must identify:

• Active assignments
• Owned tasks
• Approval responsibilities
• Scheduled work
• Unresolved handoff requirements

The system may require reassignment of blocking responsibilities before removal. Nonblocking removal may proceed with explicit warning.

16.5 Member leaves Workspace

A non-Owner may leave voluntarily unless blocked by an active legal/operational workflow requiring administrator handling. Leaving follows the same history-preserving access removal model.

17. Ownership Transfer

17.1 Preconditions

• Initiator is current Owner.
• Target is an active Workspace member.
• Target identity is verified.
• Current Owner recently reauthenticated.
• Workspace is not in a transfer-blocking state.

17.2 Flow

Owner selects Transfer ownership
→ choose active member
→ review consequences
→ reauthenticate
→ target confirms, when configured
→ atomic ownership switch
→ prior Owner receives the configured fallback access level and retains descriptive labels
→ notify both parties
→ write protected audit event

17.3 Failure handling

The Workspace must never have zero or two active Owners. Use a database transaction and uniqueness constraint/locking strategy.

17.4 Emergency recovery

Support-assisted recovery requires documented identity and business verification, dual authorization for privileged staff and a protected audit record.

18. Permissions Handoff

18.1 Product decision

Detailed permissions are intentionally outside this specification. Role Labels remain customer options, Teams remain organizational groups and Ownership remains a protected system relationship.

Until the Permissions specification is implemented, the product may use a deliberately small set of system access levels required to operate safely:

• Owner
• Workspace administrator, if enabled
• Active Teammate
• Limited external participant through an Access Grant

These access levels must not be presented as customizable Role Labels. Expansion requires the separate Permissions specification, migration rules and server-side authorization tests.

18.2 Stable capability hooks

Representative keys:

workspace.profile.view
workspace.profile.edit
team.view
team.manage
role_labels.view
role_labels.manage
projects.view
projects.manage
tasks.view
tasks.manage
calendar.view
calendar.manage
offers.view
offers.respond
proposals.create
proposals.submit
proposals.review
work_orders.view
work_orders.manage
invoices.view
invoices.create
invoices.approve
payments.view
notifications.manage_templates

This specification does not determine capability bundles or a role-to-capability mapping. It requires that code use stable capability keys and system relationships instead of Role Label names.

18.3 Protected Owner authority

Some authority comes from ownership status and cannot be accidentally removed through custom role editing:

• Transfer ownership
• Archive Workspace
• Recover critical configuration
• Assign another active member as Owner

18.4 Future Permissions integration contract

The future Permissions module may attach permission sets to Memberships, Teams or scoped assignments. It must:

• Preserve Role Labels as descriptive metadata.
• Preserve Team membership as organization structure.
• Evaluate authority server-side.
• Support least privilege and record scope.
• Explain effective access without exposing sensitive configuration.
• Keep protected Owner actions outside accidental removal.
• Provide a migration path from the initial coarse access levels.

19. Workspace Switcher

19.1 Location and display

The switcher appears at the top of the authenticated navigation and displays:

• Workspace logo/initials
• Workspace name
• Workspace type or category context when useful
• Current Membership title, optional

19.2 Menu groups

• Active Workspaces
• Pending application contexts
• Limited Project/client contexts, when presented through the switcher
• Create/apply actions where allowed

19.3 Switching behavior

Switching updates:

• Active Workspace in the URL/session context
• Navigation
• Search scope
• Dashboard configuration
• Notification scope
• Quick actions
• Effective capabilities
• Data subscriptions

The client clears Workspace-owned cached data before rendering the new context.

19.4 Deep links

When opening a deep link:

• If authorized, switch or prompt to switch to the correct Workspace.
• If the User has multiple valid contexts, choose the record-owning context.
• If not authorized, show a safe unavailable state.
• Never reveal record title or sensitive metadata before authorization.

20. Access Grants

20.1 Purpose

Access Grants support relationships that are not ordinary staff Memberships.

20.2 Grant types

• application_access
• client_project_access
• provider_offer_access
• provider_job_access
• external_approver_access
• support_impersonation, highly restricted future capability

20.3 Required attributes

• User or invited identity
• Granting Workspace
• Grant type
• Source record
• Allowed resource scopes
• Field visibility policy
• Effective date/time
• Expiration
• Revocation state/reason
• Created by/source automation
• Audit metadata

20.4 Application access

A Provider applicant may access only their application, requested actions, application communications, files and personal profile. This grant does not create a Provider Workspace Membership until approval provisioning.

20.5 Project and Provider access

Detailed Provider-application and commercial scopes are defined by Specifications 05 and 06. This specification supplies the common grant mechanism.

20.6 Revocation

Revocation takes effect immediately for API authorization and Realtime subscriptions. Required historical commercial artifacts remain available only when the owning specification and legal policy permit them.

21. Notifications, Notification Builder and Resend

21.1 Product objective

Notifications make the operating network dependable. They tell a person that something happened, explain whether action is required and take the person to the correct authorized context.

Every product event that may notify a User or Workspace must be registered in the shared Notification Builder. Feature teams do not hard-code independent email wording, recipient logic or one-off delivery calls.

Initial channels:

• In-app notifications
• Transactional email through Resend

Future governed channels:

• SMS through Twilio
• Push notifications
• Digest delivery

Adding a channel must not require each product module to rebuild notification logic.

21.2 Notification definition

A Notification Definition is the permanent system contract for one event and audience purpose.

Required fields:

• Stable definition key, such as team.invitation_created
• Human-readable name
• Description and user outcome
• Product domain
• Event source
• Audience resolver
• Available channels
• Required or optional classification
• Security and sensitivity classification
• Supported variables with descriptions and example values
• Default deep-link resolver
• Default template set
• User-preference eligibility
• Workspace-override eligibility
• Digest eligibility
• Status and version

Mandatory definitions cannot be deleted. They may be deprecated only through a governed replacement and migration.

21.3 Builder information architecture

The current split layout remains:

Notifications Builder
├── Summary: definitions / published / drafts
├── Searchable definition list
└── Selected definition
    ├── Overview
    ├── In-app template
    ├── Email template
    ├── Variables
    ├── Audience and rules
    ├── Preview and test
    └── Version history

Definition list filters:

• Domain
• Channel
• Published state
• Required/optional
• Workspace-overridable
• Validation errors

21.4 Template lifecycle

Templates use immutable published versions:

Published version
→ Create draft
→ Edit and preview
→ Validate variables and links
→ Send authorized test
→ Publish new version
→ New deliveries use new version
→ Historical deliveries retain original version reference

Publishing does not rewrite previously rendered Notifications or delivery logs. Rollback selects a prior valid version as the new active version and records the action.

21.5 Email template fields

• Sender identity
• Reply-to policy
• Subject
• Preheader
• Heading
• Body
• Primary action label and URL resolver
• Optional secondary action
• Footer
• Legal and preference content based on classification
• Plain-text fallback

The editor supports structured blocks or a constrained rich-text experience. It does not permit arbitrary scripts, unsafe HTML or unvalidated external tracking.

21.6 In-app template fields

• Short title
• Body
• Icon or event category
• Severity: information, attention, warning or critical
• Primary deep link
• Optional secondary action
• Read/dismiss behavior
• Expiration, if any

In-app copy should be concise and preserve context: actor, Workspace, source record, action and timing when relevant.

21.7 Variable registry

Every variable is registered with:

• Stable key
• Data type
• Description
• Example
• Required or optional state
• Escaping rule
• Sensitivity classification
• Allowed channels
• Fallback behavior

Example invitation variables:

recipient.first_name
inviter.display_name
workspace.name
workspace.logo_url
membership.job_title
membership.role_labels
invitation.accept_url
invitation.expires_at
support.url

The editor inserts variables from a picker. Publishing fails when required variables are unresolved, unsupported variables are present or sensitive variables are used in an unauthorized channel.

21.8 Audience resolution

Recipient logic is code-governed and testable. Templates may not arbitrarily change who receives a security or commercial notification.

Audience resolvers support:

• Specific User
• Invitation email before User creation
• Workspace Owner
• Selected Workspace Members
• Team members
• Team Lead
• Record Owner or assignee
• Client participant
• Provider participant
• Registry operations audience

Resolution occurs at delivery time using current Membership and Access Grant state. A removed member must not receive later Workspace content merely because the person was subscribed earlier.

21.9 User preferences

Users may control optional categories and channels. They cannot disable messages required for:

• Authentication and account security
• Invitation acceptance
• Ownership transfer
• Payment or legally required commercial records
• Critical service or safety events

Preferences are scoped to User and Workspace when appropriate. One person may want different operational notifications from different businesses.

21.10 Workspace overrides

The Design Registry owns canonical defaults. A Workspace may customize approved brand and copy fields only when the definition permits it.

Workspace override rules:

• Start from the active Registry template.
• Store override fields separately from the canonical definition.
• Preview the resolved template with Workspace branding.
• Prevent removal of required meaning, security text or legal content.
• Validate every override before publish.
• Allow reset to Registry default.
• Do not let one Workspace affect another.

21.11 Resend integration

Resend is the transactional email delivery provider. The integration is centralized behind a Notification Delivery service. Product modules enqueue a notification request; they do not call Resend directly.

Domain event committed
→ notification request queued
→ definition and active template resolved
→ recipient authorization rechecked
→ variables rendered
→ delivery idempotency checked
→ Resend message submitted
→ provider message ID stored
→ webhook updates delivery state
→ retry or exception workflow when required

Required Resend configuration:

• Verified production sending domain
• Separate development, staging and production configuration
• Approved From identities
• Reply-to policy by definition
• API key stored only in server-side secrets
• Webhook signing-secret validation
• Suppression and bounce handling
• Delivery metrics and alerts
• No production recipient leakage from non-production environments

21.12 Resend email identity

Recommended system identities:

• notifications@design-registry.com for general operational messages
• security@design-registry.com for account security
• invitations@design-registry.com for invitation flows, if operationally helpful

Actual addresses depend on verified domain configuration. The displayed sender may identify the Workspace where permitted, but the authenticated sending domain remains controlled by The Design Registry. Reply-to can route to the inviting or operating Workspace only when that does not expose hidden Registry/provider relationships.

21.13 Delivery states

Canonical states:

queued
rendering
submitted
delivered
delivery_delayed
bounced
complained
suppressed
failed
cancelled

Provider-specific webhook names map into these canonical states. Store raw provider payload references securely for troubleshooting without treating them as the product model.

21.14 Idempotency and retries

The delivery idempotency key combines the notification event, recipient, channel and intended template version. Reprocessing the same event must not send duplicate invitations or security messages.

Retry policy:

• Retry transient network and provider errors with exponential backoff.
• Do not retry hard bounces, complaints, invalid addresses or permanent template errors.
• Place exhausted requests in an exception queue.
• Surface operational alerts for required messages.
• Allow an authorized manual retry after the underlying issue is corrected.
• Record every attempt.

21.15 Webhooks

Resend webhook processing must:

• Verify signature before parsing.
• Reject replay outside the allowed window.
• Deduplicate by provider event ID.
• Map provider message ID to Delivery.
• Update state idempotently.
• Preserve event time and received time.
• Trigger in-app or operational exceptions when required delivery fails.
• Avoid logging full sensitive payloads in ordinary application logs.

21.16 Invitation events

• team.invitation_created
• team.invitation_queued
• team.invitation_submitted
• team.invitation_delivered
• team.invitation_delivery_delayed
• team.invitation_delivery_failed
• team.invitation_reminder
• team.invitation_expiring
• team.invitation_accepted
• team.invitation_expired
• team.invitation_revoked

Invitation emails are required while the invitation is active. Delivery failure creates a visible exception for the inviter. Resend action must generate a new delivery attempt without creating a duplicate invitation record or silently extending expiry unless the user explicitly chooses that option.

21.17 Membership events

• membership.activated
• membership.job_title_changed
• membership.role_labels_changed
• membership.teams_changed
• membership.suspended
• membership.reactivated
• membership.removed
• membership.left_workspace

21.18 Ownership events

• workspace.ownership_transfer_requested
• workspace.ownership_transfer_cancelled
• workspace.ownership_transferred

21.19 Security events

• security.email_verification_requested
• security.email_verified
• security.password_changed
• security.password_reset_requested
• security.email_change_requested
• security.email_changed
• security.new_sign_in
• security.sessions_revoked

21.20 Notification Center

The authenticated shell provides a shared Notification Center showing authorized notifications across the active Workspace.

Capabilities:

• Unread count
• Chronological list
• Category and unread filters
• Mark read/unread
• Mark all read within current scope
• Deep link to authorized record
• Clear expired informational entries where policy permits
• Workspace context indicator

Critical notifications cannot be hidden merely by dismissing an email. The source record continues to show the required state.

21.21 Observability

Operational dashboards track:

• Requests by definition and channel
• Queue time
• Render failures
• Submission success
• Delivery, bounce and complaint rates
• Time to delivery
• Retry volume
• Suppression volume
• Required-notification failure count
• Template version performance
• Invitation delivery-to-acceptance conversion

Alerts focus on systemic failures, abnormal bounce/complaint rates, webhook lag and required-message failure.

21.22 Notification acceptance criteria

• Mandatory definitions are seeded in every environment.
• Notification Builder never presents a normal zero-definition production state.
• Draft, preview, test, publish, version and rollback flows work.
• Invalid or sensitive variables cannot be published incorrectly.
• Product modules enqueue through one delivery service.
• Resend secrets and webhook verification remain server-side.
• Delivery is idempotent and webhook processing is deduplicated.
• Removed or unauthorized recipients do not receive protected Workspace content.
• Invitation delivery failure is visible and recoverable.
• In-app and email messages reference the same domain event.
• All material template and delivery actions are auditable.

22. Activity and Audit

22.1 Activity versus audit

Activity is an understandable product timeline. Audit is the immutable security/business record. A single domain event may produce both representations.

22.2 Audit event attributes

• Event ID
• Event type
• Actor User and Membership
• Active Workspace
• Target type and ID
• Before/after values where safe
• Reason
• Source channel
• Request/correlation ID
• IP/device/session metadata according to privacy policy
• Timestamp
• Outcome

22.3 Protected events

Ownership transfer, privileged role change, Membership removal, security changes and support recovery are retained according to elevated audit policy.

22.4 Privacy

Do not place passwords, tokens, full authentication secrets or unnecessary sensitive personal data in activity or audit payloads.

23. Security Requirements

23.1 Server-side enforcement

Every protected operation authorizes on the server. Client navigation and disabled buttons are usability controls, not security.

23.2 Tenant isolation

• Workspace-owned tables include workspace_id where appropriate.
• Supabase Row Level Security is enabled on exposed tenant tables.
• Policies use authenticated User plus valid Membership/Grant relationships.
• Service-role operations are isolated to trusted server/Edge Function paths.
• Storage paths and signed URLs enforce the same ownership relationships.

23.3 Invitation security

• Store invitation tokens hashed when the application owns token generation.
• Use high-entropy single-use tokens.
• Expire invitations.
• Rate-limit resend and acceptance attempts.
• Bind acceptance to the intended identity policy.
• Prevent open redirects in continuation URLs.

23.4 Rate limiting and abuse

Rate-limit:

• Sign-in attempts
• Password resets
• Verification resend
• Invitation creation/resend
• Invitation-token checks
• Workspace enumeration endpoints

23.5 Sensitive actions

Require recent authentication for:

• Ownership transfer
• Email change
• Password change when session risk is elevated
• Sign out all sessions
• Workspace archiving
• Future privileged permission changes

23.6 Impersonation

Do not implement ordinary silent impersonation. Any future support-access feature requires explicit authorization, reason, visible banner, short expiration, restricted capabilities and immutable audit.

24. Privacy and Data Rights

24.1 Personal versus business records

Users may update personal profile information. Business records created during a Membership remain with the owning Workspace subject to contractual and legal requirements.

24.2 Account deletion request

Deletion handling must distinguish:

• Authentication identity
• Personal profile data
• Required audit/security records
• Workspace-owned authored business records
• Active legal/commercial obligations

Where deletion is not possible, data may be minimized or de-identified while preserving required attribution.

24.3 Export

Personal export does not include another Workspace's confidential business data merely because the User interacted with it.

25. Accessibility and Responsive Design

25.1 Accessibility

• WCAG 2.2 AA target
• Complete keyboard operation
• Visible focus
• Semantic labels and descriptions
• Programmatic error association
• Non-colour status indicators
• Sufficient touch targets
• Screen-reader announcement of invitation and save outcomes
• Reduced-motion support
• Accessible confirmation dialogs

25.2 Mobile

• Teammate tables become list cards or priority columns.
• Member drawer becomes full-screen.
• Invite form uses a single-column layout.
• Workspace switcher supports long organization names.
• Destructive actions remain separated from common actions.

26. Empty, Loading and Error States

26.1 New Workspace

Show the Owner and an invitation action:

Build your team when you are ready. Invite teammates, organize Teams and choose the labels that describe how everyone works.

26.2 No pending invitations

Explain that sent invitations appear here.

26.3 Loading

Use stable skeletons that preserve layout. Do not briefly show “no access” while Membership resolution is loading.

The primary action may show a short loading state only while authority is unresolved. If resolution exceeds the interface threshold, keep the page usable and show a scoped status with retry. Do not leave “Loading access…” indefinitely.

26.4 Partial failure

If teammate summary fails but profile loads, retain available settings and provide scoped retry.

The current shell's “team directory is temporarily unavailable” case must preserve any successfully cached directory data, mark metrics as unavailable rather than zero and keep a clear retry action. A metric of zero is shown only after a successful empty response.

26.5 Configuration empty state

Teams and Role Labels may be genuinely empty and should explain their purpose with a primary creation action. Notification Definitions are different: required definitions are platform configuration. If none are available, show a Registry-operator configuration error with correlation ID and support path, not a customer-facing empty state.

26.6 Save conflict

Use optimistic versioning for Membership edits. If another administrator changed the record, show the current value and require review before retry.

26.7 Lost authority

If the acting administrator loses team.manage while a form is open, reject the save safely and refresh the interface.

26.8 Error classification

The UI distinguishes:

• Empty data
• Loading
• Network or service failure
• Unauthorized
• Forbidden
• Missing platform configuration
• Validation error
• Version conflict
• Delivery-provider failure

Every state explains whether data was saved, what remains available, what the user can do and whether support needs a correlation ID.

27. Data Model

27.1 Core tables

users
user_profiles
user_emails
auth_identity_links
workspaces
workspace_profiles
workspace_memberships
workspace_invitations
workspace_ownership_transfers
teams
team_memberships
role_labels
membership_role_labels
invitation_team_assignments
invitation_role_labels
access_grants
access_grant_scopes
notification_definitions
notification_definition_variables
notification_templates
notification_template_versions
workspace_notification_overrides
user_notification_preferences
notifications
notification_deliveries
notification_delivery_attempts
notification_provider_events
security_events
audit_events

27.2 users

Key fields:

• id uuid primary key
• auth_user_id uuid unique
• status
• primary_email_normalized
• created_at
• updated_at
• merged_into_user_id nullable
• deactivated_at nullable

27.3 user_profiles

• user_id
• first_name
• last_name
• display_name
• avatar_file_id
• phone_e164
• time_zone
• locale
• accessibility_preferences jsonb
• profile_version

27.4 workspaces

• id
• workspace_type
• status
• display_name
• slug
• owner_membership_id
• created_from_type
• created_from_id
• created_at
• archived_at
• row_version

27.5 workspace_memberships

• id
• workspace_id
• user_id
• status
• job_title
• system_access_level
• is_owner
• invitation_id
• joined_at
• suspended_at
• removed_at
• row_version

Constraints:

• Unique active Membership per User/Workspace
• One active is_owner Membership per Workspace
• Owner Membership belongs to the same Workspace as owner_membership_id

27.6 workspace_invitations

• id
• workspace_id
• email_normalized
• email_display
• intended_first_name
• intended_last_name
• workspace_title
• intended_job_title
• intended_system_access_level
• invited_by_membership_id
• status
• token_hash
• expires_at
• accepted_by_user_id
• accepted_at
• revoked_at
• delivery_state
• last_sent_at
• send_count
• row_version

Intended Teams and Role Labels use junction tables so invitations may carry multiple selections without JSON-only relationships.

27.7 teams

• id
• workspace_id
• name
• description
• team_type nullable
• workspace_location_id nullable
• lead_membership_id nullable
• status
• display_order
• created_by_membership_id
• created_at
• updated_at
• archived_at nullable
• row_version

Constraint: normalized active Team name is unique within Workspace.

27.8 team_memberships

• id
• team_id
• workspace_membership_id
• status
• added_by_membership_id
• added_at
• removed_at nullable

Constraint: active Team membership is unique for Team and Workspace Membership. Database validation ensures both records belong to the same Workspace.

27.9 role_labels

• id
• workspace_id nullable for platform suggestions
• name
• description
• status
• is_default_invite_label
• display_order
• colour_token nullable
• source_template_key
• created_at
• archived_at

27.10 membership_role_labels

• workspace_membership_id
• role_label_id
• assigned_by_membership_id
• assigned_at
• removed_at nullable

Constraint: active assignment is unique and both records belong to the same Workspace.

27.11 Notification definitions and templates

notification_definitions stores the stable event contract. notification_definition_variables stores allowed variables. notification_templates identifies a definition, channel and scope. notification_template_versions stores immutable drafts and published versions. Workspace overrides reference the canonical definition and contain only permitted override fields.

Every Delivery stores the exact Definition and Template Version used.

27.12 notifications

• id
• definition_id
• event_id
• recipient_user_id
• workspace_id nullable
• source_type
• source_id
• rendered_title
• rendered_body
• deep_link
• severity
• created_at
• read_at nullable
• dismissed_at nullable
• expires_at nullable

27.13 notification_deliveries

• id
• notification_id nullable for pre-account invitation email
• definition_id
• template_version_id
• event_id
• channel
• recipient_user_id nullable
• recipient_address_normalized
• workspace_id nullable
• idempotency_key unique
• provider
• provider_message_id nullable
• canonical_state
• queued_at
• submitted_at nullable
• delivered_at nullable
• failed_at nullable
• failure_code nullable
• attempt_count
• last_attempt_at nullable

27.14 notification_provider_events

• provider
• provider_event_id unique
• provider_message_id
• event_type
• canonical_state
• provider_occurred_at
• received_at
• signature_verified_at
• processed_at nullable
• payload_reference nullable

27.15 access_grants

• id
• user_id nullable
• invited_email_normalized nullable
• granting_workspace_id
• grant_type
• source_type
• source_id
• status
• effective_at
• expires_at
• revoked_at
• revocation_reason
• created_by_user_id nullable
• policy_version

27.16 Audit design

Audit tables are append-only to ordinary application roles. Sensitive before/after data may be stored in protected JSON with a deliberate schema and retention policy.

28. Supabase Architecture

28.1 Authentication

Use Supabase Auth for Google OAuth, email/password, verification, password recovery and session management.

28.2 Profile provisioning

An idempotent trusted function creates the application users and user_profiles rows from a new Auth User. Do not rely solely on the browser to provision required rows.

28.3 Row Level Security

Policy helper functions may include:

current_app_user_id()
has_active_membership(workspace_id)
has_workspace_capability(workspace_id, capability_key)
has_active_access_grant(source_type, source_id, scope_key)

Security-definer helpers must be narrowly scoped, schema-qualified and protected from unsafe search paths.

All tables in an exposed schema have RLS enabled. Policies combine authenticated role targeting with explicit Workspace, User or Access Grant predicates. Update policies use both existing-row and resulting-row checks, and the corresponding Select policy is present. Aggregation views used by metric cards are either security-invoker views on supported Postgres versions or placed in a non-exposed schema with explicit server-only access.

Authorization must not use user-editable authentication metadata. System authorization data belongs in trusted application tables or protected app metadata with an explicit freshness strategy.

28.4 Edge Functions/server operations

Use trusted server operations for:

• Invitation creation and sending
• Invitation acceptance transaction
• Ownership transfer
• Membership removal with dependency checks
• Bulk Team and Role Label assignment
• Session revocation
• Notification request processing and Resend dispatch
• Resend webhook verification and delivery-state updates
• Support recovery

28.5 Realtime

Membership suspension/removal, Team changes, Role Label changes and in-app notifications should update active clients promptly. Realtime improves UX, but API authorization remains authoritative.

28.6 Storage

User avatars and Workspace logos use separate logical buckets or policies. A person may update their avatar; Workspace logo authority comes from Workspace profile capability.

28.7 Notification processing topology

Short authenticated administration requests, Resend submission and signed Resend webhooks may use Supabase Edge Functions or an equivalent trusted server runtime. Long-running retries, digests and exception processing use a durable queue/worker pattern rather than holding an HTTP request open.

The public webhook endpoint does not rely on a User JWT. It authenticates the provider through Resend's signed webhook contract, validates replay constraints and performs only idempotent event ingestion before asynchronous processing.

Resend API keys, webhook secrets and privileged Supabase credentials never enter the browser bundle. Frontend clients use publishable credentials and RLS-protected data access only.

29. API and Service Contracts

29.1 Identity

GET    /me
PATCH  /me/profile
GET    /me/workspaces
POST   /me/change-email
POST   /me/change-password
POST   /me/sessions/revoke-others

29.2 Active Workspace

POST   /session/active-workspace
GET    /workspaces/:workspaceId/context

29.3 Members

GET    /workspaces/:workspaceId/members
GET    /workspaces/:workspaceId/members/:membershipId
PATCH  /workspaces/:workspaceId/members/:membershipId
POST   /workspaces/:workspaceId/members/:membershipId/suspend
POST   /workspaces/:workspaceId/members/:membershipId/reactivate
POST   /workspaces/:workspaceId/members/:membershipId/remove
POST   /workspaces/:workspaceId/members/leave

29.4 Invitations

GET    /workspaces/:workspaceId/invitations
POST   /workspaces/:workspaceId/invitations
PATCH  /workspaces/:workspaceId/invitations/:invitationId
POST   /workspaces/:workspaceId/invitations/:invitationId/resend
POST   /workspaces/:workspaceId/invitations/:invitationId/revoke
GET    /invitations/:token/preview
POST   /invitations/:token/accept

Invitation preview returns only safe metadata before authentication.

29.5 Teams

GET    /workspaces/:workspaceId/teams
POST   /workspaces/:workspaceId/teams
GET    /workspaces/:workspaceId/teams/:teamId
PATCH  /workspaces/:workspaceId/teams/:teamId
POST   /workspaces/:workspaceId/teams/:teamId/members
DELETE /workspaces/:workspaceId/teams/:teamId/members/:membershipId
POST   /workspaces/:workspaceId/teams/:teamId/archive

29.6 Role Labels

GET    /workspaces/:workspaceId/role-labels
POST   /workspaces/:workspaceId/role-labels
PATCH  /workspaces/:workspaceId/role-labels/:roleLabelId
POST   /workspaces/:workspaceId/role-labels/:roleLabelId/archive
POST   /workspaces/:workspaceId/role-labels/:roleLabelId/reassign-and-archive
POST   /workspaces/:workspaceId/members/:membershipId/role-labels
DELETE /workspaces/:workspaceId/members/:membershipId/role-labels/:roleLabelId

29.7 Notification Builder

GET    /notification-definitions
GET    /notification-definitions/:definitionId
POST   /notification-definitions/:definitionId/templates/:channel/drafts
PATCH  /notification-template-versions/:versionId
POST   /notification-template-versions/:versionId/validate
POST   /notification-template-versions/:versionId/test
POST   /notification-template-versions/:versionId/publish
POST   /notification-template-versions/:versionId/rollback
GET    /workspaces/:workspaceId/notification-overrides
PUT    /workspaces/:workspaceId/notification-overrides/:definitionId/:channel
DELETE /workspaces/:workspaceId/notification-overrides/:definitionId/:channel

29.8 Notification Center and preferences

GET    /me/notifications
POST   /me/notifications/:notificationId/read
POST   /me/notifications/:notificationId/unread
POST   /me/notifications/read-all
GET    /me/notification-preferences
PUT    /me/notification-preferences

29.9 Delivery and Resend webhook

POST   /internal/notification-requests
POST   /internal/notification-deliveries/:deliveryId/retry
POST   /webhooks/resend
GET    /admin/notification-deliveries
GET    /admin/notification-deliveries/:deliveryId

Internal endpoints are callable only through trusted services. The Resend webhook validates the provider signature before accepting the event.

29.10 Ownership

POST   /workspaces/:workspaceId/ownership-transfers
POST   /workspaces/:workspaceId/ownership-transfers/:transferId/confirm
POST   /workspaces/:workspaceId/ownership-transfers/:transferId/cancel

29.11 Error contract

Use stable machine codes such as:

• membership_required
• membership_inactive
• capability_required
• invitation_expired
• invitation_revoked
• invitation_email_mismatch
• duplicate_membership
• owner_transfer_required
• membership_has_blocking_assignments
• record_version_conflict
• team_name_conflict
• team_lead_must_be_member
• role_label_name_conflict
• role_label_archived
• notification_definition_required
• notification_template_invalid
• notification_variable_invalid
• notification_delivery_suppressed

Messages remain understandable without exposing unauthorized data.

30. Analytics

Track privacy-conscious events:

• Sign-up started/completed
• Authentication method
• Verification completion
• Password recovery completion
• Invitation created/sent/delivered/accepted/expired
• Time to accept
• Existing versus new User acceptance
• Teammate management actions
• Workspace switching
• No-access recovery usage
• Membership suspension/removal/reactivation

Do not send invitation tokens, passwords or unnecessary personal data to analytics.

31. User Stories

31.1 Workspace Owner

As a Workspace Owner, I want to invite my team so that they can work inside the organization without sharing credentials.

As a Workspace Owner, I want roles named for my business so that the product reflects how my company operates.

As a Workspace Owner, I want to organize people into Teams without changing their access so that the directory reflects how my company actually works.

As a Workspace Owner, I want invitation delivery status and a safe resend action so that I can help a teammate who did not receive the email.

As a Workspace Owner, I want to suspend access immediately so that a departing teammate cannot continue viewing records.

As a Workspace Owner, I want to transfer ownership safely so that the Workspace is never orphaned.

31.2 Teammate

As an invited teammate, I want to understand who invited me and what Workspace I am joining.

As a teammate with an existing account, I want to join another Workspace without creating a second login.

As a teammate in multiple organizations, I want to switch context clearly so that I do not act in the wrong Workspace.

As a Team Lead, I want my Team to be a reusable assignment and notification audience so that operational work reaches the right people.

31.3 Provider Applicant

As a Provider applicant, I want to access my pending application without receiving a fully approved Provider Workspace.

As an applicant who already belongs to another Workspace, I want that Workspace to remain accessible during review.

31.4 Client or external participant

As a client, I want access only to my Project and approved information without becoming a staff member of the Designer Studio.

31.5 Administrator

As a Registry administrator, I want complete membership audit history without silently taking ownership of customer Workspaces.

As a Registry administrator, I want every notification event to use a governed definition and versioned template so that communications remain consistent and recoverable.

As a Registry operator, I want required Resend failures surfaced with delivery history so that invitations and security messages do not fail silently.

31.6 Notification recipient

As a User, I want notifications to identify the correct Workspace and take me to an authorized record so that I can act without confusion.

As a User in several Workspaces, I want optional notification preferences scoped appropriately so that I can reduce noise without missing security or required commercial messages.

32. Acceptance Criteria

32.1 Authentication

• Google and email/password sign-in work.
• Email verification and forgot-password flows are complete.
• Neutral recovery language prevents account enumeration.
• Invitation/application continuation survives authentication.
• Session revocation works as designed.

32.2 Identity

• One User may belong to multiple Workspaces.
• Adding a Membership does not create a duplicate User.
• Email changes do not break Memberships or history.
• Pending application state does not globally disable a User.

32.3 Invitations

• Authorized Owners/admins can invite teammates.
• Duplicate active/pending relationships are handled safely.
• Existing and new Users can accept.
• Expired/revoked tokens cannot create Memberships.
• Acceptance is atomic and idempotent.
• Resend and revoke are audited.
• Resending creates a new delivery attempt without duplicating the invitation.
• Invitation delivery state reflects verified Resend webhook events.
• Required delivery failure is visible to the inviter with a safe recovery action.

32.4 Memberships

• People table supports required search, filter, sort and status display.
• Job-title, Role Label and Team changes take effect promptly.
• Suspension and removal block protected APIs immediately.
• Historical authorship remains.
• Blocking assignments are surfaced before removal.

32.5 Ownership

• Every active Workspace has exactly one active Owner.
• Owner cannot remove themselves without transfer.
• Transfer requires recent authentication.
• Transfer is atomic, notified and audited.

32.6 Teams

• Authorized administrators can create, edit and archive Teams.
• One Teammate can belong to multiple Teams.
• Team Lead must be an active member of the Team.
• Bulk assignment is transactional and audited.
• Team membership does not independently grant record access.
• Archived Teams cannot receive new assignments.

32.7 Role Labels

• Workspace can use recommended or custom role labels.
• Product code does not authorize by role-name string.
• One Teammate may hold multiple Role Labels.
• One optional default-on-invite label is enforced correctly.
• Role Label archive cannot strand assigned members without a deliberate resolution.
• Full capability editing remains separated for the Permissions specification.

32.8 Notifications and Resend

• Required Notification Definitions are seeded outside ordinary Workspace data.
• Notification Builder supports draft, preview, validation, test, publish, version history and rollback.
• Published versions are immutable.
• Workspace overrides cannot remove required meaning or security content.
• Product modules use the shared delivery service rather than calling Resend directly.
• Email delivery is idempotent.
• Resend webhooks are signature-verified, replay-resistant and deduplicated.
• Canonical delivery states update from provider events.
• Retries distinguish transient and permanent failures.
• Removed or unauthorized recipients are excluded at delivery time.
• User preferences cannot disable required security and commercial messages.
• In-app notifications deep-link only to authorized contexts.

32.9 Workspace context

• Switcher displays all and only valid contexts.
• Workspace switch clears inappropriate cached data.
• Deep links resolve safely.
• Unauthorized metadata is not disclosed.

32.10 Access Grants

• Application, client and Provider limited-access relationships do not require staff Membership.
• Grants are scoped, expiring/revocable and audited.
• Revocation affects API and live subscriptions promptly.

32.11 Quality

• UX is responsive and WCAG 2.2 AA aligned.
• Errors are recoverable and non-enumerating.
• Material events are audited.
• Required notification event definitions exist.
• RLS and service authorization tests pass for cross-Workspace isolation.
• Legacy Proper Gallery branding is absent from this module.

33. Test Matrix

Required scenarios include:

1. New User accepts invitation through Google.
2. New User accepts through email/password and verification.
3. Existing User joins a second Workspace.
4. User opens invitation while signed into the wrong email identity.
5. Invitation expires during signup.
6. Invitation is accepted twice.
7. Two administrators edit one Membership concurrently.
8. Owner attempts self-removal.
9. Owner transfer fails midway.
10. Suspended member has an active browser session.
11. Removed member is subscribed to Realtime.
12. User switches rapidly between Workspaces.
13. User opens an unauthorized deep link.
14. Provider applicant also has an active Designer Membership.
15. Member with blocking tasks is removed.
16. Role Label is archived while assigned.
17. Password reset link is reused.
18. OAuth is cancelled or provider is unavailable.
19. Cross-Workspace ID is submitted to an API.
20. Invitation resend rate limit is reached.
21. Teammate is assigned to several Teams and Role Labels in one save.
22. Team Lead is removed from the Team.
23. Team is archived while referenced by active Tasks or notification rules.
24. Role Label is renamed and historical activity remains intelligible.
25. Workspace Owner creates a Role Label named Owner without granting protected ownership authority.
26. Teammates metrics fail while directory records load successfully.
27. Access resolution fails while the user opens Teams.
28. Required Notification Definitions are missing in an environment.
29. Template draft contains an unsupported variable.
30. Workspace override attempts to remove required security copy.
31. Same notification request is processed twice.
32. Resend webhook event is delivered twice.
33. Resend webhook signature is invalid.
34. Email hard-bounces and is not retried.
35. Transient Resend error retries and later succeeds.
36. Invitation is revoked before a queued delivery is submitted.
37. Member is removed between event creation and delivery resolution.
38. Notification deep link is opened from the wrong active Workspace.
39. User disables an optional category in one Workspace but not another.
40. Published template is rolled back to a prior version.

34. Migration and Compatibility

If prototype data currently stores users directly inside modules:

1. Inventory every user-like record and email field.
2. Create canonical Users by verified identity rules.
3. Create Workspaces for organization records.
4. Convert embedded team records into Memberships.
5. Preserve old IDs in migration mapping tables.
6. Repoint authorship and assignments to User/Membership IDs.
7. Convert pending invitations.
8. Backfill Owner relationships.
9. Introduce RLS in report-only/test mode where possible.
10. Validate counts, orphan records and cross-Workspace access.
11. Cut over reads, then writes.
12. Retire legacy user stores after a rollback window.

Current-shell migration also requires:

1. Replace remaining Proper Gallery interface strings and document titles with The Design Registry.
2. Preserve the existing Settings URLs and shared grid behavior.
3. Convert any singular role field into Role Labels plus a separate system access level.
4. Create Team records and many-to-many Team memberships from any embedded group fields.
5. Seed category-appropriate Role Label suggestions without forcing assignments.
6. Seed mandatory Notification Definitions and canonical templates in every environment.
7. Configure verified Resend domains, From identities, secrets and signed webhooks by environment.
8. Map prototype notification/email logs into canonical Delivery states where reliable.
9. Run invitation delivery in shadow/reporting mode before enabling production sends.
10. Reconcile teammate, Team, Role Label, invitation and notification counts before cutover.

Migration must be idempotent and produce reconciliation reports.

35. Implementation Phases

Phase 1 — Identity and authentication

• Supabase Auth configuration
• User/Profile provisioning
• Google and email/password
• Verification and password recovery
• Session/security events

Phase 2 — Workspace and Membership foundation

• Workspace tables
• Membership model
• Owner constraint
• Active Workspace context
• Initial RLS

Phase 3 — Invitations and Teammates

• Invitation service
• Notification Definition integration
• Resend delivery and webhook foundation
• Acceptance journeys
• Teammates directory and invitation states
• Member drawer

Phase 4 — Teams and Role Labels

• Teams grid, detail and membership management
• Team Lead rules
• Bulk assignment
• Role Label suggestions and customer labels
• Multiple labels per Membership
• Default-on-invite behavior
• Archive and reassignment

Phase 5 — Membership administration

• Job-title, Team and Role Label changes
• Suspend/reactivate/remove
• Dependency summaries and reassignment hooks
• Ownership transfer

Phase 6 — Notification Builder and Center

• Mandatory definition registry
• In-app and email templates
• Variables, validation and preview
• Test, publish, version and rollback
• Workspace override policy
• Notification Center and preferences
• Delivery observability and exception operations

Phase 7 — Permission readiness and Access Grants

• Stable capability registry
• Application Access Grants
• Client/Provider scoped grant foundation
• Explicit handoff to the separate Permissions specification

Phase 8 — Hardening and migration

• Authorization/RLS test suite
• Rate limiting
• Audit review
• Accessibility
• Analytics
• Recovery and migration tooling
• Legacy-brand removal
• Current-shell state and failure-state remediation
• Resend deliverability review

36. Definition of Done

This module is complete when:

• A person can authenticate securely.
• A person can join multiple Workspaces with one account.
• Owners can manage teammates without support.
• Owners can organize Teams and Role Labels without confusing either feature with permissions.
• The live Teammates, Teams and Role Labels pages load independently and recover from partial failures.
• Invitation email delivery, failure and resend are visible and auditable.
• Mandatory notification definitions and versioned templates are managed through the Notification Builder.
• In-app notification and Resend email delivery use the same domain event and shared delivery service.
• Workspace context is always clear.
• Membership changes immediately affect authorization.
• Ownership cannot become invalid.
• Limited external access works without fake staff Memberships.
• Provider application approval can provision into this model.
• Dashboards can resolve the active User/Workspace context.
• Commercial modules can rely on Membership and Access Grant relationships.
• Supabase RLS and server checks prevent cross-Workspace access.
• Audit, notifications, accessibility and failure states are production-ready.
• No legacy Proper Gallery branding remains in the module.

37. Final Product Standard

Users and teams should feel effortless to the customer even though the underlying system is rigorous. A solo Designer should not feel burdened by enterprise concepts. A large Provider should still be able to manage real operational staff safely. The identity architecture must remain invisible when everything is working—and exceptionally clear when access changes, invitations expire or a person belongs to multiple organizations.

This foundation is mandatory before Provider applications, category dashboards, matchmaking, Offers, Proposals, Work Orders, invoices or payments can be trusted at production scale.

The completed experience must pass five practical tests:

• Solo-business: a solo Designer or Photographer can work immediately without being forced to configure Teams, Role Labels or template overrides.
• Operating-company: a warehouse, delivery company, Vendor or fabrication business can organize real staff, use familiar language and route work without shared credentials or duplicate accounts.
• Trust: nobody can see another Workspace's directory, invitations or notification metadata; removal takes effect promptly; descriptive labels never become accidental authorization rules.
• Communication: every important message has a registered purpose, governed template, known audience, traceable version and delivery state; failures create clear recovery actions.
• Coherence: Teammates manages people and invitations, Teams organizes people for work, Role Labels describe how the business operates and Notifications governs communication—all using the same shell, grids, forms, Activity, audit and failure language.

The Design Registry name and visual system remain consistent throughout.

The final standard is simple:

A Workspace Owner can bring the right people into the business, organize them in familiar language and trust that every important message reaches the correct authorized person—with no duplicate accounts, hidden permission behavior or silent delivery failure.

Live-product correction contract — August 4, 2026

The current Settings implementation establishes useful foundations, but this specification governs the following mandatory corrections:

1. Rename the Custom roles metric to Role Labels and the New role action to New role label. A Role Label describes function and never grants authority.
2. Enforce exactly one active default Role Label per Workspace. The current data marks both Teammate and Administrator as Default on invite; migration must choose one deterministic default and retain all other labels as optional.
3. Protect system-required labels from unsafe archive behavior and preserve archived labels on historical Memberships.
4. Use one canonical Membership query for Teammate counts, grids, assignment pickers and embedded profile tabs. The live product has previously shown conflicting People counts.
5. Preserve Teams as permission-neutral operational groups. Team membership and Team Lead designation must not change Access Roles or record scope.
6. Expand Notifications Builder beyond its current 28 invitation, Application, provisioning and Provider-onboarding events. Every future specification must register its Project, Task, Offer, commercial, approval, receiving, delivery, communication, security and integration events in the shared Domain Event catalogue.
7. Keep delivery records provider-neutral while using Resend as the initial email provider. Add webhook-confirmed delivery, suppression, retry and failure states before reporting email as delivered.
8. Do not expose SMS templates or rules until Twilio sender configuration, consent, opt-out and quiet-hour requirements are implemented.
9. Ownership transfer must require recent authentication, an eligible active Membership, atomic execution, notification and immutable audit.
10. Invitation acceptance must resolve to one User and one Workspace Membership without creating duplicate identities.

<!-- CURRENT-PRODUCT-GAP-COVERAGE:START -->

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 03
Mapped current-product profiles: 6
Recorded review gaps: 21

This register is part of the release contract. It maps the current-product reverse review into required future behavior. A gap is not closed because a screen exists; closure requires the corrected canonical data, permissions, states, migration, audit and test evidence described below.

Register rules

1. Every profile in the Current Product Library must resolve to one owning future specification.
2. Current limitations are evidence, not optional ideas. If a limitation is intentionally retained, the specification must record the decision, risk, owner and review date.
3. Shared-component defects are corrected through Spec 16 and then consumed here; feature teams may not create local replacement controls.
4. Permission, contact, financial and visibility defects also require Spec 08 enforcement, even when the functional feature is owned by another specification.
5. Legacy Proper Gallery, Lead, Partner and implementation-facing labels are migration inputs only and must not return through new UI, APIs, exports or notifications.
6. Verification must use realistic fixtures for Admin, Designer, Provider and Client audiences where applicable.

G01 — Workspace switcher

Current-product profile: workspace-switcher
Observed route: /admin
Evidence confidence: Partially verified

Review gaps

• Menu contents and actual switching are not verified.
• Only one active Workspace has been observed.
• Legacy Proper Gallery naming remains visible.
• Deep links into records owned by another Workspace are unverified.
• Long names and mobile layout are unverified.

Required future closure

• Group active, pending and limited-context Workspaces where applicable.
• Clear Workspace-owned caches before rendering a new context.
• Handle deep-link switch prompts safely.
• Show Workspace type or Provider category consistently.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G02 — Notification centre

Current-product profile: notification-centre
Observed route: /admin
Evidence confidence: Partially verified

Review gaps

• Notification panel behavior is not documented.
• Unread counts, preferences, grouping, dismissal and mark-all-read are unknown.
• The relationship between current in-app alerts and Resend delivery is unverified.

Required future closure

• Provide actionable grouping, record links, read state and clear Workspace context.
• Add every new operational event to the editable template system within protected rules.
• Expose delivery and failure state where appropriate.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G03 — Teammates

Current-product profile: teammates
Observed route: /admin/settings/teammates
Evidence confidence: Verified

Review gaps

• Legacy Proper Gallery identity remains.
• Custom roles terminology conflates labels and authority.
• Invitation lifecycle, suspension and removal were not verified.
• Cross-profile teammate counts have previously conflicted.

Required future closure

• Implement Spec 03 correction contract.
• Rename Custom roles to Role Labels.
• Use one Membership-backed identity and count everywhere.
• Register invitation, acceptance, expiry, revocation, access-change and ownership events.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G04 — Teams

Current-product profile: teams
Observed route: /admin/settings/teams
Evidence confidence: Verified

Review gaps

• No populated Team or creation form was reviewed.
• No archive, membership history or downstream usage is visible.

Required future closure

• Complete Team lifecycle in Spec 03.
• Reuse Teams in Tasks, Projects, queues and notifications.
• Preserve permission neutrality in every picker.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G05 — Role Labels

Current-product profile: role-labels
Observed route: /admin/settings/roles
Evidence confidence: Verified

Review gaps

• Ambiguous two-default state.
• New role wording is incorrect.
• Protected-label and archive behavior are unverified.

Required future closure

• Repair the default invariant and migrate existing data.
• Rename actions and metrics to Role Label.
• Separate Access Role configuration into Spec 08.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G06 — Notifications Builder

Current-product profile: notifications-builder
Observed route: /admin/settings/notifications
Evidence confidence: Verified

Review gaps

• No Project, Task, Offer, commercial, receiving, delivery, approval, communication, security or integration events are registered.
• No SMS templates/rules are visible.
• No real delivery history exists.
• Template localization and accessibility checks are not evidenced.

Required future closure

• Expand to the cross-product event matrix in every future spec.
• Add User and Workspace preferences, quiet hours, digesting and escalation.
• Connect Resend webhooks, retry state and suppression handling.
• Add SMS only with consent and compliant sender configuration.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

<!-- CURRENT-PRODUCT-GAP-COVERAGE:END -->