The Design Registry

Customizable Roles, Permissions & Access Control

Document: 08 - Customizable Roles, Permissions & Access Control
Version: 2.0
Date: August 2026
Status: Engineering source of truth
Primary systems: Authenticated Workspaces, Teammates, Teams, Projects, Clients, Providers, Offers, Proposals, Work Orders, Items, Budgets, Invoicing, Payments, Notifications and Reporting
Production backend: Supabase Auth, Postgres, Row Level Security, Storage, Realtime and Edge Functions

1. Executive Summary

The Design Registry requires a permission model that can support very different businesses without building a separate application for every participant. A Designer Studio, storage facility, white-glove delivery company, furniture Vendor, millwork shop, photographer, contractor, Client and Registry operator all use the same platform, but they must not receive the same authority or see the same information.

This specification defines a customizable, relationship-aware access-control system. Workspace Owners can create Access Roles, choose the actions each role may perform, choose the records those actions apply to and decide whether sensitive fields are hidden, masked, view-only or editable. The system remains safe because customization operates inside non-negotiable platform boundaries. A Workspace cannot grant itself access to another Workspace, expose another Provider's quote, show a Client internal Provider economics or override the scope of an accepted Work Order.

The model combines:

• Role-based access control through customizable Access Roles;
• Relationship-based access through Workspace, Team, Project, Client and Provider Job relationships;
• Field-level visibility for contact, financial, commercial, verification, banking and tax information;
• Time-limited and Project-specific grants for temporary collaboration;
• Supabase Row Level Security and server-side authorization for enforcement;
• Versioning, simulation, access reviews and immutable audit history for governance.

The most important distinction is:

Role Labels describe what a person does. Access Roles determine what that person is allowed to do. Relationships determine where that authority applies.

A user may therefore have the Role Label “Procurement Manager,” an Access Role that allows purchasing and budget updates, and a Project assignment that limits those rights to three Projects. The label never grants access by itself.

The design follows the platform's shared-component principle: build one capability registry, one Access Role Builder, one field-visibility system and one authorization evaluator, then reuse them across every Workspace and Provider workflow.

2. Outcomes and Success Measures

2.1 Required outcomes

The completed model must:

1. Allow every Workspace to create and maintain its own Access Roles.
2. Keep Workspace-defined Role Labels separate from authority.
3. Support direct, Team-based, Project-based and Provider Job-based assignments.
4. Protect sensitive contact and financial information independently from general record access.
5. Allow Providers to operate in the same Project without seeing one another's confidential information.
6. Give Clients a clear, intentionally limited Project experience.
7. Apply permission changes immediately across the application, APIs, exports, files and Realtime subscriptions.
8. Make every meaningful permission change auditable.
9. Prevent the last Workspace Owner from locking themselves or the Workspace out.
10. Provide understandable explanations for allowed, masked and denied access.

2.2 Product success measures

3. Principles

3.1 Default deny

If the platform cannot prove that a user is authenticated, has an active Membership, holds the required capability, falls within the permitted record scope and has the required field visibility, access is denied.

3.2 Authority is not presentation

Navigation, hidden buttons and disabled controls improve usability but are not security. The database and server must independently enforce every protected action.

3.3 Customizable inside protected boundaries

Workspace Owners may personalize access, but cannot weaken tenant isolation, Project relationship boundaries, Client privacy, Provider confidentiality, payment protections or Registry-only controls.

3.4 Least privilege with useful starter roles

New Members receive the smallest practical access. Onboarding provides strong starter roles so Owners do not need to design security from a blank page.

3.5 Projects connect participants; they do not erase boundaries

A Project can include a Designer Studio, Client and several Providers. Participation exposes only the information required for the participant's assigned work.

3.6 Sensitive data is separately governed

Seeing a Client, Project, Provider, invoice or order record does not automatically mean seeing every contact, price, margin, commission, payment or tax field on it.

3.7 Stable keys, editable names

Customers may rename roles and labels. Engineering authorization uses stable capability keys and field-classification keys that cannot be changed by a customer.

3.8 Immediate revocation

Removing a role, suspending a Member, ending a Project grant or closing a Provider Job must remove the corresponding access without waiting for a long-lived user token to expire.

3.9 Explainability and accountability

Owners must be able to answer: “Why can this person see this?” and “Who changed their access?” without engineering assistance.

4. Definitions

5. Conceptual Model

User
  → Active Workspace Membership
      → Protected system relationship
      → Role Labels (description only)
      → Direct Access Roles
      → Team Access Roles
      → Scoped Access Grants
          → Project assignment
          → Client relationship
          → Provider Job assignment
          → Temporary collaboration
      → Effective capabilities and field visibility
          constrained by immutable platform boundaries

5.1 Why a hybrid model is required

Pure role-based access is too broad. A “Project Manager” role alone cannot express that the Member may edit only Projects assigned to their Team. Pure relationship-based access is too difficult to administer. A Project assignment alone cannot express whether the Member may view budgets, approve invoices or export contact details.

The Design Registry therefore evaluates both:

• Can the user perform the action? Determined by Access Roles and capability grants.
• On which records? Determined by the grant's record scope and current relationships.
• Which fields may be returned or changed? Determined by field-visibility rules.
• Does a protected platform boundary prohibit it? Determined by immutable system policy.

5.2 Role Labels versus Access Roles

The Teammate form must place these controls in separate sections and explain the difference. Selecting a Role Label must never silently attach an Access Role.

6. Protected System Relationships

6.1 Workspace Owner

Every Workspace has exactly one active Owner at launch. The Owner may:

• manage Workspace settings and Access Roles;
• transfer ownership through a protected workflow;
• assign high-risk capabilities;
• initiate access reviews;
• view the Workspace permission audit.

The Owner cannot be removed, suspended or stripped of ownership while they remain the only Owner. Ownership transfer requires recent authentication, confirmation from the receiving active Member and immutable audit entries.

6.2 Registry operators

Registry operational access is separately governed and never created by a customer Access Role. Registry starter roles include Platform Owner, Market Administrator, Applications Reviewer, Matchmaking Operator, Project Operations, Finance Operations and Support Read Only.

Registry staff must not receive universal access merely because they work for the platform. Market, application, Project or financial scope must still be explicit.

6.3 Pending and restricted identities

Pending applicants, suspended Members, removed Members and disabled Users receive no authenticated Workspace access except the specifically designed pending-application experience. An application status is not an Access Role.

7. Access Role Architecture

7.1 Customer experience

The main customer-facing concept is Access Role. An Owner sees plain-language controls rather than database policy syntax. Internally, every published Access Role is stored as an immutable permission-set version.

Each Access Role contains:

• name and description;
• applicable Workspace types;
• capability grants;
• a record scope for each capability group;
• field visibility and editing rights;
• optional approval limits;
• default Team or Project assignment behavior;
• risk classification;
• version history and publishing metadata.

7.2 Lifecycle

Editing a published role creates a new Draft. Publishing shows an impact preview: affected Members and Teams, active Projects, capabilities added or removed, newly exposed field groups and any high-risk change.

7.3 Assignment sources

Access Roles may be assigned through:

1. Direct Membership assignment — suitable for Administrators or unique functions.
2. Team assignment — every active Team Member inherits the Team's role.
3. Project assignment — capability is restricted to a named Project or group of Projects.
4. Provider Job assignment — a Provider teammate receives access only to assigned Jobs.
5. Temporary grant — a limited role expires at a defined date and time.

Multiple valid roles combine as an allow-union inside the user's maximum permitted boundary. A restrictive system or relationship boundary always wins.

7.4 No general customer-authored deny rules in version one

Arbitrary allow-and-deny combinations are difficult to explain and can create unsafe policy conflicts. Version one uses explicit allowed capabilities plus protected system denials. A later version may introduce advanced restrictive policies after the simulator and policy tooling have proven reliable.

8. Capability Registry

8.1 Capability grammar

Every action uses a stable namespaced key:

resource.subresource.action

Display names and help text may change. Keys are immutable after production use. Deprecated keys remain resolvable during migrations.

8.2 Workspace and team capabilities

8.3 Project capabilities

8.4 Commercial and Provider capabilities

8.5 Governed business commands

Where records must remain auditable, capabilities use governed commands such as archive, cancel, void or reverse instead of generic delete. A user who may edit an invoice does not automatically have authority to void it. A user who may edit an item cannot automatically authorize its release from storage.

9. Record Scope

9.1 Supported scopes

9.2 Scope is evaluated at request time

Scope is not copied into a browser token. Team membership, Project assignment, Work Order status and temporary-grant expiry are evaluated against current server data.

9.3 Provider boundaries

An accepted Offer and Work Order create a Provider Job. The Provider sees only:

• the portion of the Project needed to quote, schedule and perform the work;
• included items, quantities, rooms, specifications and approved attachments;
• delivery, receiving, site and contact details explicitly shared for the Job;
• its own offer, proposal, Work Order, change orders, evidence, invoice and payment status;
• shared messages, tasks and calendar events related to the Job.

The Provider does not see competing offers, other Providers, the Designer's internal margin, Registry commercial agreements, unrelated Project files or Client information not required for fulfilment.

9.4 Client boundaries

Client access derives from an active Client–Project relationship and a Client Access Role. Clients can never be granted internal notes, Provider comparisons, hidden markups, internal commissions, Provider verification files, unrelated Projects or Registry operations.

10. Sensitive Data and Field-Level Permissions

10.1 Requirement

Record access and field access are independent. A user may be allowed to view a Project while some values are omitted or masked. Field protections apply to pages, grids, search, activity events, exports, generated documents, API responses, Realtime payloads, AI context and integration payloads.

10.2 Visibility levels

“Edit” never grants record access by itself. It is effective only when the user also has the required record and action capability.

10.3 Standard field groups

10.4 Financial separation

The platform must distinguish at least four financial views:

1. Client view — Client-facing approved prices, invoices, payments and budget summaries.
2. Designer operating view — Project budgets, item pricing, commitments and Client-facing financials.
3. Provider view — only the Provider's offer, Work Order value, change orders, invoices and payment status.
4. Registry financial view — marketplace fees, referral fees, commissions, platform revenue, payouts and reconciliation.

A Workspace Owner can customize access within their own view but cannot expose a higher protected layer. For example, a Designer Studio can decide whether a Junior Designer sees Project budgets, but cannot use a custom role to see Registry–Provider negotiated economics.

10.5 Contact-information controls

Contact visibility supports operational need without indiscriminate exposure:

• A Designer may see Client contact information after the Client is assigned or matched according to the Project workflow.
• A Provider may receive a designated site contact only when an Offer or Work Order requires it.
• A Driver may see a delivery-day name, phone and address but not the Client's billing information or full Project budget.
• A Warehouse Receiver may see the purchase-order contact and delivery instructions but not unrelated Client information.
• A Finance teammate may view billing details without receiving site-access notes.

The Access Role Builder offers presets such as No contact details, Masked contact details, Operational contact only and Full authorized contact.

10.6 Sensitive-data exports and AI

Exports include only fields visible to the requesting user. Export templates cannot bypass permissions. AI features receive a server-generated, permission-filtered context; the model must never be given hidden fields and asked merely not to display them.

11. Starter Access Roles

Starter roles are platform-maintained templates cloned into a Workspace during provisioning. Owners may rename or customize the clone. Protected system roles remain platform-controlled.

11.1 Designer Studio

11.2 Provider Workspace

Category-specific starters include Storage Receiver, Inventory Manager, Dispatcher, Driver / Crew Lead, Vendor Order Manager, Fulfilment Coordinator, Millwork Estimator, Shop Lead, Site Installer, Photographer and Editor.

11.3 Client Workspace

11.4 Registry Workspace

Registry roles are protected templates and scoped by Market or operating function. Platform Owner is never assigned through a customer-facing builder.

12. Settings Information Architecture

Settings
├── Teammates
├── Teams
├── Role Labels
├── Permissions
│   ├── Access Roles
│   ├── Teammate Access
│   ├── Team Defaults
│   ├── Project Access Defaults
│   ├── Field Visibility
│   ├── Access Simulator
│   ├── Access Reviews
│   └── Audit
└── Notifications

Role Labels remain a separate tab. Permissions is available only to Members with permissions.view; edits require the corresponding management or assignment capabilities.

13. Access Role Builder Experience

13.1 Role list

The Access Roles page shows:

• role name and description;
• draft, published or retired status;
• number of direct Members and Teams using it;
• last published date and publisher;
• high-risk indicator;
• starter/custom designation;
• actions: open, duplicate, create draft, retire and compare versions.

13.2 Builder sections

1. Overview — name, description and intended user.
2. Workspace and people — profile, Teammate, Team, role-label and integration capabilities.
3. Projects and Clients — Project, task, calendar, file, note and Client actions with scope.
4. Items and operations — categories, budgets, purchase orders, receiving, storage, delivery and installation.
5. Offers and commercial documents — offers, proposals, Work Orders, invoices and payments.
6. Sensitive information — field-group visibility and editing.
7. Assignments and defaults — direct, Team and Project defaults.
8. Risk and approvals — thresholds, separation of duties and high-risk confirmation.
9. Preview — plain-language summary and affected-user impact.
10. Version history — compare, publish and restore as a new Draft.

13.3 Module cards, not one giant matrix

Each module card starts with a preset: No access, View, Contribute, Manage or Custom. Expanding the card exposes individual capabilities, record scope and relevant field groups. Search and “Show changed only” make large roles manageable.

13.4 Publishing flow

Before publishing, the system must:

1. validate every capability and scope combination;
2. reject protected-boundary violations;
3. show the number and identity of affected Members and Teams;
4. call out newly exposed contact or financial field groups;
5. show capabilities removed from active operational users;
6. require recent authentication for high-risk changes;
7. require a typed confirmation for material financial or permission-administration changes;
8. create the immutable published version and audit event;
9. invalidate effective-permission caches;
10. notify affected users when configured or security-required.

14. Teammate and Team Access

14.1 Teammate access panel

Every Teammate profile includes an Access panel showing:

• protected system relationship;
• Role Labels;
• direct Access Roles;
• inherited Team Access Roles;
• active Project and Provider Job grants;
• temporary access and expiry;
• sensitive-capability warnings;
• an “Explain access” action;
• recent access changes.

14.2 Team defaults

A Team may carry one or more Access Roles. Joining the Team grants those roles; leaving removes them. The audit identifies the Team as the source. Team Access Roles do not automatically grant Project relationships unless the Access Role scope is explicitly Team Projects and the Project is assigned to that Team.

14.3 Immediate suspension

Suspending a Membership denies all Workspace access, including inherited roles and temporary grants. It does not delete historical authorship, assignments or audit evidence.

15. Project and Provider Access Integration

15.1 Project participation

Project access is created through explicit assignments and access recipes. Project Templates may reference stable access recipes such as “Client Decision Maker,” “Provider Quote Access,” “Storage Receiving Job” or “Delivery Crew.” They must never reference a Workspace's display role name.

15.2 Provider lifecycle

Provider matched
  → Offer sent
    → limited quote access grant
      → Offer accepted
        → Work Order issued
          → Provider Job grant activated
            → Provider assigns internal teammates
              → work completed or cancelled
                → operational grant reduced or closed

The Provider Workspace first needs a valid external Project/Job grant. Its internal Member also needs a Provider Access Role and Job assignment. Neither condition alone is sufficient.

15.3 Stage-sensitive access

• Before an Offer: Provider receives no Project access.
• During quoting: Provider sees only the quote package and necessary questions.
• After acceptance: Provider sees Work Order scope and authorized operational data.
• During delivery/install: selected field Members receive time-limited site and contact details.
• After completion: mutation rights close; commercial and evidence records remain available according to retention policy.
• After cancellation or removal: access is revoked immediately except for protected historical documents belonging to the Provider.

15.4 Files and shared evidence

Files carry visibility classifications and record links. A file is accessible only when the user can access the linked record and its visibility class. Signed URLs are generated only after authorization and remain short-lived.

16. Approval Authority and Separation of Duties

16.1 Optional thresholds

Access Roles may contain limits such as:

• approve proposals up to a configured value;
• approve purchase orders up to a configured value;
• approve budget variance up to a percentage or amount;
• approve invoices up to a configured value;
• record manual payments up to a configured value;
• authorize storage release or refunds only with a second reviewer.

Values are stored in Workspace currency and evaluated server-side.

16.2 Self-approval controls

The Workspace may enable protected rules including:

• a proposal creator cannot approve the same proposal;
• an invoice submitter cannot approve their own invoice;
• a purchase-order creator needs a second approver above a threshold;
• manual payments and refunds above a threshold require a second review;
• changes to banking or payout data require Owner confirmation and recent authentication.

16.3 High-risk capabilities

The interface must visibly identify:

• permission management and assignment;
• ownership transfer;
• financial approval, void, refund and manual payment actions;
• integration connection and secret management;
• banking, tax, verification and internal-margin access;
• bulk contact or financial export;
• Registry-wide or Market-wide access.

17. Access Simulator

17.1 Inputs

An authorized administrator selects:

• a User or pending Access Role Draft;
• active Workspace;
• action or capability;
• a real Project, Client, Provider Job, invoice, item or other record;
• optional field group.

17.2 Result

The simulator returns:

• Allowed, View Only, Masked, Hidden or Denied;
• the Access Role and assignment source;
• matching record scope or relationship;
• protected boundary applied;
• field-visibility result;
• effective policy version;
• expiration if temporary;
• a plain-language explanation.

Example:

Masked. Jordan can view this Delivery Job through the Driver role and Job assignment. Client direct contact is limited to Operational Contact, so the delivery phone number is visible while the Client email and billing address are hidden.

The simulator itself respects permissions and cannot reveal hidden values to the administrator running it.

18. Access Reviews and Emergency Access

18.1 Access reviews

Owners may schedule quarterly, semi-annual or annual reviews. Review items include:

• active Members and direct Access Roles;
• Team-inherited roles;
• unused or dormant high-risk access;
• active Project and Provider Job grants;
• temporary grants nearing or past expiry;
• suspended or inactive Users;
• access to banking, tax, contact export, margin, invoices and payments;
• unassigned starter roles and retired roles still in use.

Review actions are certify, reduce, revoke, reassign or investigate. Completion creates a signed audit summary.

18.2 Break-glass access

Emergency access is Registry-controlled and must never be silent support impersonation. It requires a reason, incident or support reference, recent strong authentication, narrow scope, short expiry, prominent notification and immutable audit. It cannot be granted by a Workspace-created Access Role.

19. Navigation and User Experience Enforcement

Navigation is generated from effective capabilities:

• hide modules with no available records or capabilities;
• display assigned-only counts where appropriate;
• remove actions the user cannot perform;
• use disabled controls with explanations only when educational value outweighs clutter;
• show an access-request path where the Workspace allows requests;
• return a neutral Not Found experience when revealing record existence would leak information.

The interface must re-check access after Workspace switching, role updates, Team changes and Project reassignment. Cached pages must not continue showing removed sensitive values.

20. Notification Builder Integration

Every new permission-related notification is registered in the shared Notification Builder. Templates can be configured by Workspace, channel, audience, language and brand where permitted.

Resend is the default transactional email provider. In-app notifications use the same event and template registry. SMS through Twilio is reserved for urgent, explicitly configured events. Security-critical delivery cannot be disabled merely by editing a customer notification template.

21. Audit and Observability

21.1 Immutable change history

Audit events record:

• actor User, Membership and Workspace;
• action and stable capability key;
• target role, assignment, grant or policy;
• previous and new values or version identifiers;
• affected Members, Teams, Projects and Jobs;
• reason and approval reference where required;
• IP, device/session reference and authentication assurance for high-risk actions;
• timestamp and correlation ID.

21.2 Decision logging

Logging every successful read would be too costly and noisy. The system logs:

• all permission changes;
• all high-risk allows and denials;
• sensitive exports;
• ownership and break-glass actions;
• repeated authorization failures and suspicious patterns;
• policy-evaluation errors.

Operational metrics include authorization latency, cache hit rate, denied-action volume, stale-grant cleanup, RLS failures and policy version adoption.

22. Data Model

22.1 Core authorization tables

22.2 Governance tables

22.3 Required constraints

• All tenant-owned rows include workspace_id.
• Published role versions are immutable.
• Role names are unique within active Workspace roles, case-insensitively.
• Capability keys and field-group keys are unique and immutable.
• Assignments reference active Memberships in the same Workspace.
• Temporary grants require an expiry.
• Project and Provider Job grants reference valid participant relationships.
• One active Workspace Owner is required.
• Soft deletion or retirement preserves historical authorization evidence.

22.4 Indexing

Indexes must cover common RLS and evaluation predicates, including:

• (workspace_id, membership_id, active) assignments;
• (workspace_id, team_id, active) Team roles;
• (workspace_id, project_id, participant_workspace_id, status) Project grants;
• (provider_job_id, membership_id, status) Job assignments;
• (access_role_version_id, capability_key) capabilities;
• active partial indexes for non-expired temporary grants;
• authorization version by Workspace and Membership.

Query plans must be tested against realistic high-volume Project, item and activity tables.

23. Supabase Security Architecture

23.1 Row Level Security

RLS is enabled on every table in an exposed schema. Policies require an authenticated User, active Membership, matching Workspace or governed relationship and the necessary access condition. TO authenticated alone is never considered authorization.

Read, insert, update and delete/archive policies are defined separately. Update policies include both USING and WITH CHECK, and a compatible select policy.

23.2 Authorization functions

Internal functions may include:

• is_active_workspace_member(workspace_id);
• has_workspace_capability(workspace_id, capability_key);
• can_access_project(project_id, capability_key);
• can_access_provider_job(provider_job_id, capability_key);
• field_access_level(workspace_id, record_context, field_group_key).

Prefer security-invoker behavior. If a narrowly scoped security-definer function is unavoidable for an internal lookup, it lives in a non-exposed schema, fixes search_path, validates auth.uid() internally, receives the minimum privileges and has execution revoked from PUBLIC before explicit grants.

23.3 JWT and freshness

The complete permission matrix must not be stored in the JWT. It becomes stale, may exceed cookie limits and cannot safely represent fast revocation. User-editable metadata is never used for authorization. Current database relationships and authorization versions remain authoritative.

23.4 Service-role use

Service-role credentials are never exposed to a browser. Edge Functions and background jobs using elevated credentials explicitly authorize the requesting User and Workspace before reading or mutating data. Elevated access is not a substitute for a permission check.

23.5 Views, files and Realtime

• Customer-accessible database views use security-invoker behavior or remain outside exposed schemas.
• Storage metadata is authorized before a short-lived signed URL is generated.
• Realtime channels follow the same Workspace, Project and Provider Job boundaries.
• Realtime payloads never contain fields hidden from the subscriber.
• Removing access terminates or invalidates affected subscriptions.

23.6 Effective-permission cache

An optional server-side cache may store normalized effective grants keyed by User, Membership, Workspace and authorization version. Publishing a role, changing a Team, changing a Project relationship, suspending a Member or revoking a grant increments the relevant version and invalidates the cache.

Sensitive writes and high-risk operations always verify current authoritative state.

24. API Design

24.1 Capability and role APIs

24.2 Assignment and simulation APIs

All mutation endpoints support idempotency keys, optimistic concurrency/version checks and audit correlation IDs.

25. Evaluation Algorithm

For a requested action, the server evaluates in this order:

1. Confirm an authenticated, non-disabled User and valid session requirements.
2. Confirm active Membership in the selected Workspace.
3. Apply immutable platform and tenant boundaries.
4. Confirm the target record exists inside an authorized relationship without leaking existence.
5. Resolve direct, Team and scoped role assignments using current published versions.
6. Resolve Project, Client, Provider Job and temporary grants.
7. Confirm at least one capability grant covers the action and record scope.
8. Apply approval thresholds, self-approval rules and authentication assurance.
9. Resolve the field-visibility level for every sensitive field read or written.
10. Allow, mask, omit or deny; record audit/telemetry when required.

The evaluator returns a stable reason code in addition to a safe user message. Reason codes support testing and support diagnostics without exposing sensitive record details.

26. User Stories

26.1 Workspace Owner

• As an Owner, I can start from a Studio or Provider role template and customize it.
• As an Owner, I can decide that Designers see Client contact information but not internal margins.
• As an Owner, I can give Finance access to invoices and payments without granting Project design editing.
• As an Owner, I can preview who will gain financial access before publishing a role.
• As an Owner, I can review and revoke dormant high-risk access.

26.2 Designer Studio Member

• As a Designer, I see only my assigned or Team Projects according to my role.
• As a Junior Designer, I can work with tasks, files and selections while Project costs remain masked.
• As a Procurement Member, I can import items and issue approved purchase orders without seeing banking details.

26.3 Provider Owner and teammates

• As a Provider Owner, I can create a Driver role that exposes delivery-day contact details only.
• As a Dispatcher, I can assign Jobs and update schedules but cannot view payout banking data.
• As a Receiver, I can record item condition and photographs without seeing the full Client budget.
• As a Provider Finance Member, I can manage our invoices without seeing Jobs belonging to another Provider.

26.4 Client

• As a Client Decision Maker, I can approve Client-facing proposals and view my invoices.
• As a Client Collaborator, I can see shared design information but cannot approve spending unless granted.
• As a Client, I never see internal Provider comparisons or hidden commercial arrangements.

26.5 Registry operator

• As a Market Administrator, I see only my assigned market.
• As an Applications Reviewer, I can review vetting data without receiving payment authority.
• As Finance Operations, I can reconcile platform payments without editing design work.

27. Acceptance Criteria

27.1 Role and assignment behavior

• Role Labels never change effective access.
• An Owner can create, duplicate, validate, publish, compare and retire Access Roles.
• Published versions cannot be mutated in place.
• Direct and Team roles identify their assignment source.
• Removing a Team Member removes Team-inherited access.
• The last Owner cannot be suspended, removed or stripped of ownership.

27.2 Record boundaries

• A Member with assigned-only Project access cannot query or open an unassigned Project.
• A Provider cannot access a Project without an active Offer/Job grant.
• A Provider Member additionally requires internal Job assignment where configured.
• A Provider never sees another Provider's offer, Work Order or invoice.
• A Client never sees internal notes or restricted commercial fields.
• Workspace switching cannot carry access from the previous Workspace.

27.3 Field visibility

• Client and Provider contact information can independently be hidden, masked, viewed or edited.
• Project budgets, item prices, costs, markups, commissions, invoices, payments, banking, tax and verification data use distinct field groups.
• Pages, grids, search, exports, AI context, generated documents and Realtime apply the same field rules.
• Hidden values are omitted server-side, not merely concealed with CSS.
• A role cannot expose a field group beyond its Workspace's protected maximum.

27.4 Security and governance

• Every exposed authorization table has RLS and explicit policies.
• API requests cannot authorize from user-editable metadata.
• High-risk changes require recent authentication and confirmation.
• Publishing invalidates effective-access caches.
• Suspensions and revocations take effect immediately for sensitive actions.
• Permission changes, sensitive exports, ownership changes and break-glass access are audited.
• Simulator explanations match enforced decisions in automated tests.

27.5 Accessibility and usability

• Builder controls are keyboard accessible and screen-reader labelled.
• Colour is not the only high-risk indicator.
• Permission summaries use plain language and expose advanced keys on demand.
• Owners can search capabilities and show only customized modules.

28. Migration from Current Access Levels

28.1 Mapping

28.2 Migration guarantees

• Migration must not broaden existing access.
• Ambiguous users receive the conservative role and appear in an Owner review queue.
• Existing authorship and history remain unchanged.
• Every backfilled assignment records migration source and version.
• Owners see an access summary before new enforcement becomes authoritative.

28.3 Shadow evaluation

For a controlled period, the new evaluator runs alongside existing checks and records differences without changing the user result. Engineering reviews unexpected allows, denials, query performance and field masking before enforcement.

29. Implementation Phases

Phase 1 — Foundations

• Define capability and field-group registries.
• Implement Access Role data model and published versions.
• Add active Membership, Workspace and protected Owner boundaries.
• Add core RLS helpers, indexes and automated authorization tests.
• Map current Owner/Admin/Member access into starter roles.

Phase 2 — Role Builder and teammate access

• Build Access Role list, Builder, validation and impact preview.
• Add direct and Team assignments.
• Add Teammate Access panel and effective summary.
• Add cache versioning and immediate revocation.
• Register notification events and audit history.

Phase 3 — Projects, Clients and Providers

• Add Project, Client, Provider Job and temporary grants.
• Connect grant recipes to Offers, Work Orders and Project Templates.
• Apply field visibility to contact, files, items and operational workflows.
• Add stage-sensitive Provider access.

Phase 4 — Financial and commercial controls

• Apply budgets, price, cost, margin, commission, invoice, payment, banking and tax field groups.
• Add approval thresholds, self-approval rules and high-risk step-up authentication.
• Secure exports, generated documents, integrations and AI context.

Phase 5 — Governance and rollout

• Launch simulator, recurring access reviews and break-glass controls.
• Run shadow evaluation and security testing.
• Resolve migration review queue.
• Enforce new authorization model by module.
• Monitor denials, latency, cache invalidation and support cases.

30. Testing Strategy

30.1 Authorization matrix tests

Automated tests cover every Workspace type, starter role, capability, record scope and field group. At minimum, each action has positive and negative cases.

30.2 Adversarial tests

• change Workspace IDs in requests;
• enumerate record identifiers;
• access another Provider's Job or file;
• request hidden fields through exports, search, Realtime or AI endpoints;
• manipulate Role Labels or user metadata;
• use stale sessions after suspension;
• race a role change against a financial approval;
• attempt self-approval above threshold;
• reuse signed file URLs after revocation;
• call elevated Edge Functions without authorized context.

30.3 Database and performance tests

• test RLS policies directly as representative authenticated Users;
• confirm unauthenticated requests return no protected data;
• run database security and performance advisors;
• inspect query plans for Project, item, activity and reporting lists;
• load-test large Workspaces and Providers with many Jobs;
• verify indexes cover policy predicates;
• confirm views and functions do not bypass RLS.

30.4 Release gates

No module moves to enforcement until:

• its capability and field groups are registered;
• positive and negative authorization tests pass;
• simulator results match enforced results;
• migration mapping has been reviewed;
• denial and latency telemetry is available;
• rollback restores the previous enforcement path without losing audit history.

31. Non-Goals for Initial Release

• A customer-authored programming language for arbitrary security policies.
• Silent support impersonation.
• Cross-Workspace shared super-roles created by customers.
• Using Role Labels as permission shortcuts.
• Storing the full permission matrix in authentication tokens.
• Relying on client-side hiding for security.
• Unrestricted direct database access for Workspace customers.
• Custom denial precedence beyond protected platform boundaries.

32. Final Product Decision

The Design Registry will ship one customizable authorization system across every participant experience. Workspace Owners receive meaningful control over people, Projects, operations, contact information and financial visibility. That flexibility stops at deliberate platform boundaries protecting Clients, Providers, other Workspaces and Registry operations.

The durable formula is:

Effective access = active identity + active Membership + allowed capability + valid record relationship + permitted field visibility, constrained by protected platform policy.

This model is expressive enough for a small Designer Studio, operational enough for storage and delivery Providers, safe enough for financial workflows and scalable enough for a multi-market marketplace. It also preserves the platform's defining architecture: Projects connect the work, shared modules are built once, and every participant receives only the slice required to succeed.

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

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 08
Mapped current-product profiles: 61
Recorded review gaps: 25

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 — Sign in

Current-product profile: sign-in
Observed route: /sign-in
Evidence confidence: Known limitation

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Complete identity linking, session security and account recovery in Spec 17.

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 — Forgot and reset password

Current-product profile: forgot-and-reset-password
Observed route: /forgot-password
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Connect recovery delivery to the canonical notification and security event model.

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 — Authenticated application shell

Current-product profile: authenticated-shell
Observed route: /admin
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Generate navigation from Workspace type, Provider category, enabled modules and effective permissions.

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 — User account menu

Current-product profile: account-menu
Observed route: /admin
Evidence confidence: Partially verified

Review gaps

• Sign out, profile, notification preferences and security routes have not been validated.

Required future closure

• Include My Profile, notification preferences, connected accounts, Workspace switch, Security, Help and Sign out.
• Provide sign-out-all and other sensitive controls through protected Security flows.

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 — Workspace Overview dashboard

Current-product profile: workspace-overview
Observed route: /admin
Evidence confidence: Verified

Review gaps

• Recent activity exposes raw event keys such as Workspace.Assisted Access.Ended and internal record identifiers, which are not human-friendly.

Required future closure

• Complete permission-controlled commercial, schedule and Provider operational cards defined by Spec 04.

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 — Dashboard customization

Current-product profile: dashboard-customization
Observed route: /admin
Evidence confidence: Verified

Review gaps

• Reordering uses up/down controls rather than direct drag-and-drop; this is accessible but may be slow for larger card sets.
• Role-level or Workspace-default layouts are not exposed in this personal editor.
• Conflict handling when card availability changes after permissions or Provider category changes is unverified.

Required future closure

• Define User-level, Workspace-default and role/category template precedence.
• Handle newly added, retired or permission-removed cards without corrupting preferences.
• Keep mandatory attention and security cards outside optional visibility control.

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.

G07 — Pipeline board and grid

Current-product profile: pipeline-board-and-grid
Observed route: /admin/pipelines
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Provide accessible stage changes independent of drag-and-drop.

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.

G08 — Pipeline record profile

Current-product profile: pipeline-record-profile
Observed route: /admin/leads/:id
Evidence confidence: Verified

Review gaps

• Permission-based tab and field redaction were not validated.

Required future closure

• Enforce the governing permission, visibility and redaction rules from Spec 08 across this feature.

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.

G09 — Record Overview

Current-product profile: record-overview
Observed route: /admin/leads/:id
Evidence confidence: Verified

Review gaps

• Field-level access variants were not verified.

Required future closure

• Reuse the same standardized summary modules for Admin, Designer, Provider and Client with permission-aware content.

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.

G10 — Pipeline record creation and editing

Current-product profile: pipeline-record-create-and-edit
Observed route: /admin/pipelines
Evidence confidence: Verified

Review gaps

• Conditional fields, per-stage visibility and permission-based field redaction are not evidenced.

Required future closure

• Resolve or create durable Client entities without duplicate contacts.

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.

G11 — Pipeline transitions and Project conversion

Current-product profile: pipeline-transition-and-conversion
Observed route: /admin/leads/:id
Evidence confidence: Partially verified

Review gaps

• Automations, access, version history and record-detail builder sections remain placeholders.

Required future closure

• Define per-transition required fields, role/capability, confirmation, automation and notification rules.

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.

G12 — Record Activity

Current-product profile: record-activity
Observed route: /admin/leads/:id?tab=activity
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Separate participant-facing Activity from immutable security and audit history.
• Support permissions and retention by event visibility class.

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.

G13 — Record Notes

Current-product profile: record-notes
Observed route: /admin/leads/:id?tab=notes
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Reuse Notes across records and Projects with explicit visibility classes.

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.

G14 — Record Files

Current-product profile: record-files
Observed route: /admin/leads/:id?tab=files
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Support client/provider visibility without copying the file.
• Preserve audit evidence for replacement, archive and access.

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.

G15 — Record Tasks

Current-product profile: record-tasks
Observed route: /admin/leads/:id?tab=tasks
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Support dependencies, milestones and provider-facing task visibility.

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.

G16 — Record Communications

Current-product profile: record-communications
Observed route: /admin/leads/:id?tab=communication
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Use one communication object across Admin, Designer, Provider and Client relationships with strict visibility.

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.

G17 — Record Proposals

Current-product profile: record-proposals
Observed route: /admin/leads/:id?tab=proposals
Evidence confidence: Known limitation

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Replace the disabled placeholder only when loading, empty, populated, error and permission states exist.

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.

G18 — Record History

Current-product profile: record-history
Observed route: /admin/leads/:id?tab=history
Evidence confidence: Known limitation

Review gaps

• Coming soon provides no alternate audit access for authorized operators.

Required future closure

• Enforce the governing permission, visibility and redaction rules from Spec 08 across this feature.

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.

G19 — Applications directory

Current-product profile: applications-directory
Observed route: /admin/applications
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Implement one permission-scoped directory for Designer and every Provider Category application.

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.

G20 — Projects directory

Current-product profile: projects-directory
Observed route: /admin/projects
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add empty, partial, permission-redacted and recoverable error states.

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.

G21 — Project profile

Current-product profile: project-profile
Observed route: /admin/projects/:slug
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Build the Project workspace defined in Spec 07 around permission-aware modules.

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.

G22 — Project Vision & Inspiration

Current-product profile: project-vision-and-inspiration
Observed route: /admin/projects/:slug
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add reorder, caption, rights, accessibility and Client-visibility controls.

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.

G23 — Seven-phase Project process

Current-product profile: seven-stage-project-process
Observed route: /admin/projects/:slug?tab=process
Evidence confidence: Verified

Review gaps

• Project roles are stored as text and include Client / Household rather than governed participant roles.

Required future closure

• Replace Partner roles and free-text role lists with Project Participants and Provider Requirements.

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.

G24 — Project Calendar

Current-product profile: project-calendar
Observed route: /admin/projects/:slug
Evidence confidence: Known limitation

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add permission-scoped external synchronization with clear source and sync health.

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.

G25 — Project Items & Budgets

Current-product profile: project-items-and-budgets
Observed route: /admin/projects/:slug
Evidence confidence: Known limitation

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Expose Category budgets and Item pricing in one explainable financial model.

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.

G26 — Project Presentation Builder

Current-product profile: project-presentations
Observed route: /admin/projects/:slug
Evidence confidence: Known limitation

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add safe Client preview, approval and access-controlled sharing.

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.

G27 — User Profile

Current-product profile: user-profile
Observed route: /account/profile
Evidence confidence: Verified

Review gaps

• Security lacks MFA, active sessions, device/session revocation, recent security events and direct verified email-change workflow.

Required future closure

• Add security-session management, MFA and verified email-change controls without storing credentials in the profile.

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.

G28 — Designer Studio Profile

Current-product profile: designer-studio-profile
Observed route: /admin/designer-network/:id
Evidence confidence: Verified

Review gaps

• Administrative access safety controls are not visible.

Required future closure

• Harden and rename cross-Workspace access.

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.

G29 — Clients directory

Current-product profile: clients-directory
Observed route: /admin/clients
Evidence confidence: Verified

Review gaps

• Client rows expose phone, email and Pipeline value without a verified permission variant.

Required future closure

• Add duplicate resolution, household/organization relationships and Client Portal access state.

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.

G30 — Client Profile

Current-product profile: client-profile
Observed route: /admin/clients/:id
Evidence confidence: Known limitation

Review gaps

• No household, organization, secondary contact or consent model is visible.

Required future closure

• Reuse shared Entity modules with role-specific visibility.

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.

G31 — Tasks directory

Current-product profile: tasks-directory
Observed route: /admin/tasks
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add permission-safe role-specific views for Designers, Providers and Registry operators.

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.

G32 — Create and edit Task

Current-product profile: create-and-edit-task
Observed route: /admin/tasks
Evidence confidence: Verified

Review gaps

• No checklist, dependency, recurrence, evidence, follower, Team, visibility, estimate or Time Entry controls.

Required future closure

• Expand typed links and permission-aware record search.

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.

G33 — Reports and operational intelligence

Current-product profile: reports
Observed route: Coming soon — no route
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add permission-safe drilldown, saved filters, exports, scheduled delivery and freshness indicators.

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.

G34 — Teammates

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

Review gaps

• Custom roles terminology conflates labels and authority.

Required future closure

• Rename Custom roles to Role Labels.
• 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.

G35 — Teams

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

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• 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.

G36 — Role Labels

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

Review gaps

• New role wording is incorrect.

Required future closure

• 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.

G37 — 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.
• Template localization and accessibility checks are not evidenced.

Required future closure

• Enforce the governing permission, visibility and redaction rules from Spec 08 across this feature.

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.

G38 — Text input

Current-product profile: text-input
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G39 — Textarea and rich-text editor

Current-product profile: textarea-rich-text
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G40 — Email input

Current-product profile: email-input
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• Duplicate User/contact handling is undocumented.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Sign in and recovery, Teammate invitations, Client contacts, Provider Applications, Workspace Profile, communications.

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.

G41 — Phone number input

Current-product profile: phone-number-input
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Client contacts, Teammates, Designer and Provider profiles, Applications, Workspace Profile, Twilio calling and SMS, delivery contacts.

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.

G42 — URL input

Current-product profile: url-input
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G43 — Number input

Current-product profile: number-input
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G44 — Money, rate and percentage input

Current-product profile: money-percent-input
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G45 — Date, time and date-range picker

Current-product profile: date-time-picker
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G46 — Address lookup and structured address

Current-product profile: address-lookup
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G47 — Single-select dropdown

Current-product profile: single-select-dropdown
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G48 — Multi-select dropdown

Current-product profile: multi-select-dropdown
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G49 — Checkbox, radio and toggle controls

Current-product profile: checkbox-radio-toggle
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G50 — Entity, record and assignee picker

Current-product profile: entity-record-picker
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G51 — Enterprise data grid

Current-product profile: enterprise-data-grid
Observed route: Shared component
Evidence confidence: Verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add saved views, URL state, server-side query, accessible virtualization and export jobs.
• Standardize empty, error, redacted and partial-failure states.

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.

G52 — Search, filter and sort controls

Current-product profile: search-filter-sort
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G53 — Pagination and progressive loading

Current-product profile: pagination-load-more
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G54 — Activity timeline

Current-product profile: activity-timeline-component
Observed route: Shared component
Evidence confidence: Verified

Review gaps

• Redaction, retention and export are unverified.

Required future closure

• Enforce the governing permission, visibility and redaction rules from Spec 08 across this feature.

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.

G55 — Buttons, split actions and action menus

Current-product profile: buttons-action-menus
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G56 — Field validation and form feedback

Current-product profile: field-validation-feedback
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G57 — Loading, empty, error and permission states

Current-product profile: loading-empty-error-states
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• Permission-redacted states are not explicit.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G58 — Toast, banner and inline alert

Current-product profile: toast-banner-inline-alert
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: saves, imports, provisioning, administrative access, integration health, payments, delivery exceptions, security.

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.

G59 — File and image uploader

Current-product profile: file-image-uploader
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• Visibility defaults and metadata requirements vary.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G60 — Cards, summary sections and metric tiles

Current-product profile: card-summary-section
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• No limitation was recorded; retain regression coverage for the approved current baseline.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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.

G61 — Avatar, identity chip and participant label

Current-product profile: avatar-identity-chip
Observed route: Shared component
Evidence confidence: Partially verified

Review gaps

• Role Label and Access Role context can be conflated.

Required future closure

• Add automated interaction, validation, accessibility and serialization tests.

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 -->