The Design Registry

Authenticated Workspace Dashboard, Profiles & Project Operations

Document: 04 - Authenticated Workspace Dashboard & Profiles
Version: 2.0
Prepared: August 2026
Status: Archived implementation baseline — complete
Primary product principle: Designer first. Projects connect everything.

1. Executive Summary

This specification defines the authenticated experience that every Design Registry user enters after signing in: the shared application shell, role- and workspace-aware dashboard, Project-driven operational queues, Workspace Profile, User Profile, category-specific Provider portals, and the notifications that keep work moving.

The dashboard is not a separate reporting product and must not become a second source of truth. It is a live, permission-scoped projection of the underlying Project process. Every card, count, alert, milestone and call to action resolves to a canonical Project, Project Phase, task, decision, item, Offer, Proposal, Work Order, invoice, payment, message, file, appointment or profile record. A user should never need to reconcile a dashboard number with a different operational record.

The authenticated experience must serve four distinct audiences through one component system:

1. Designer Studios manage their own Projects, clients, teams, budgets, specifications, sourcing, Providers and financial work.
2. Providers receive Offers and operate accepted work through category-specific workflows that are useful enough to replace email, spreadsheets and disconnected field tools.
3. Clients see a calm, curated and approval-oriented version of their Project without internal operational or commercial information.
4. Registry operators oversee applications, matchmaking, Projects, service quality, exceptions and marketplace health across authorized markets.

The product must feel tailored to each audience without creating separate applications. The Design Registry will build the shell, dashboard framework, Project cards, lists, task modules, activity feed, calendar, files, messaging, commercial summaries and profile framework once. Configuration, capabilities, Project access, audience visibility and Provider category determine which modules appear and how they behave.

1.1 Intended outcome

After signing in, every user can answer five questions within ten seconds:

• What needs my action now?
• What is happening today and next?
• Which Projects or jobs are at risk?
• What am I waiting on from someone else?
• What is the next correct action?

1.2 Product promise

The dashboard turns the Project process into a usable daily operating system. It does not merely summarize activity; it directs work, exposes exceptions and brings every participant into the same controlled Project record.

The home screen is the user’s operating queue. The Project remains the operational centre.

2. Scope, Ownership and Related Specifications

2.1 In scope

• Shared authenticated shell and responsive navigation
• Workspace switching and active Workspace context
• Dashboard framework and card registry
• Project-driven attention, action, waiting and exception queues
• Seven-Phase Project process representation
• Designer Studio dashboard
• Client dashboard
• Registry administration dashboard
• Common Provider dashboard
• Category-specific Provider operational dashboards
• Provider Job projection of assigned Project work
• Workspace Profile and Network Profile
• User Profile and personal preferences
• Workspace branding and presentation controls
• Profile readiness, verification and matching completeness
• Shared tasks, calendar, messages, files and activity modules
• Notifications Centre and Notification Builder event requirements
• Data model, APIs, read models, event handling and audit requirements
• Supabase implementation direction
• Migration, testing, acceptance criteria and implementation phases

2.2 Out of scope

• Final authorization matrix and permission-builder UX
• Full application and approval workflow definitions
• Complete Offer, Proposal, Work Order, invoice and payment state machines
• Full Project, items, budgets and Provider Operations specification
• Public marketing website and public application experience
• Accounting rules, tax advice or legal contract language

These systems are referenced where the authenticated experience consumes their records or events. This document does not create competing definitions.

2.3 Ownership map

2.4 Conflict rule

If a status, amount, assignment or date differs between a dashboard projection and its source record, the source record wins. The platform must show a stale-data indicator, rebuild the projection and log the discrepancy. Users must not be asked to manually correct derived dashboard data.

3. Product Principles

3.1 Build once, reuse everywhere

The same primitives must power admin, Designer, Provider and Client experiences:

• Application shell
• Page header
• Workspace switcher
• Global search
• Command and quick-action menu
• Notification centre
• Metric card
• Attention card
• Project card and Project table
• Task list
• Calendar agenda
• Activity timeline
• Files list
• Message thread preview
• Offer and Work Order summary
• Profile section and completeness indicator
• Empty, loading, stale, offline and error states

Audience-specific behaviour is configuration over shared components, not copied code.

3.2 Projects connect everything

The Project is the durable operating container for clients, Designer Studios, Providers, tasks, phases, deliverables, items, budgets, decisions, schedules, commercial records, communications and evidence. Dashboard modules may aggregate across Projects, but actions always return the user to the correct Project context.

3.3 Exception first

Routine work should remain quiet. The interface elevates missing decisions, blocked dependencies, overdue tasks, damaged items, schedule risk, expiring Offers, rejected deliverables, payment holds and other exceptions. A high card count is not useful unless the user understands what to do next.

3.4 Audience-safe by default

The same Project may have different views for Registry staff, Designer Studio users, Clients and Providers. Sensitive internal notes, negotiated Provider pricing, Registry revenue, referral economics, other Provider identities and unrelated Project scope must not leak through dashboards, search, notifications, exports, files or activity feeds.

3.5 Calm luxury, operational precision

The product retains the black-and-white, restrained Design Registry visual system. Operational urgency is communicated through typography, spacing, clear labels and a limited semantic colour system. Dashboards should feel composed, not crowded.

3.6 Mobile is an operational surface

Receiving staff, delivery crews, installers, photographers and trades will use phones on site. Critical actions—receive, photograph, flag damage, start route, arrive, complete, upload proof, respond to an Offer, update a task and message the Project—must be field-ready.

3.7 Profiles are structured operational data

Profiles are not decorative biographies. Service areas, capabilities, capacity, certifications, categories, coverage, availability and matching attributes drive qualification, matchmaking, Project access and dashboard relevance.

4. Review of the Existing Product Shell

The current authenticated admin experience already establishes valuable reusable patterns:

• Persistent left navigation with Overview, Pipelines, Matchmaking, Projects, Designer Studios, Clients, Assignments, Messages, Tasks, Proposals and Reports
• Workspace identity and signed-in user summary
• Global search and notifications entry points
• Attention-first overview with metrics, prioritized work, Project progress, tasks and recent activity
• Dedicated Settings shell with Teammates, Teams, Role Labels, Project Builder, Pipeline Builder, Notifications and Data Reconciliation
• Project Builder language that recognizes seven canonical phases and immutable published template versions

This specification preserves those patterns while correcting five gaps:

1. Audience configuration: the current shell is admin-centric; navigation must adapt to Designer, Client and Provider operating needs.
2. Canonical Project vocabulary: all Project surfaces must use the seven agreed phases rather than temporary labels such as Selections.
3. Operational depth: Provider portals need action surfaces, not generic metric cards.
4. Profile separation: User Profile, Workspace Profile, Network Profile and Project participation data must be distinct.
5. Projection discipline: dashboard states must be derived from canonical records and events rather than stored as independent business state.

5. Core Domain Model

5.1 Identity hierarchy

User
  └── Workspace Membership
        ├── Role Label
        ├── Team memberships
        ├── Active/invited/suspended state
        └── Capability grants (future permissions)

Workspace
  ├── Workspace type
  ├── Provider category, when applicable
  ├── Workspace Profile
  ├── Network Profile
  ├── Branding
  ├── Integrations
  └── Project relationships

Project
  ├── Client relationship
  ├── Designer Studio relationship
  ├── Project participants and access grants
  ├── Seven phases
  ├── Work packages
  ├── Provider assignments
  ├── Items and materials
  ├── Commercial records
  └── Activity and evidence

5.2 Workspace types

• Registry Administration
• Designer Studio
• Client
• Provider

A Provider Workspace has one primary Provider category and may hold approved secondary categories. Category changes may require Registry review because they affect matching, workflow templates and visibility.

5.3 Project participation

A Workspace does not gain access to an entire Project merely because it appears in the same marketplace. Access is granted through an explicit Project relationship:

• Client relationship
• Lead Designer Studio relationship
• Registry oversight relationship
• Accepted Provider Offer or active Provider Work Order
• Explicit Project Access Grant

5.4 Provider Job

A Provider Job is a scoped projection of a Project for a Provider. It is not a duplicated Project.

It may contain:

• Authorized Project identity and site details
• Assigned Work Packages and Work Orders
• Relevant rooms, items and materials
• Required tasks, dependencies and deadlines
• Authorized contacts and messages
• Approved files, briefs, drawings and manifests
• Appointments and access instructions
• Change requests and evidence
• Invoice and payment status appropriate to that Provider

It must exclude unrelated scope, other Provider pricing, Designer internal notes, Client-private data and Registry commercial terms.

6. Shared Authenticated Shell

6.1 Required regions

1. Brand and active Workspace identity
2. Workspace switcher
3. Primary navigation
4. Global search
5. Quick create/action menu
6. Notification centre
7. Help and support
8. Signed-in user menu
9. Responsive content area
10. Connectivity and data-freshness indicator when relevant

6.2 Workspace switcher

Users with more than one membership can switch Workspaces without signing out. Switching changes:

• Active tenant context
• Navigation
• Dashboard layout
• Search scope
• Notification context
• Available quick actions
• Branding presentation
• Data access

The selected Workspace ID must be validated server-side against an active membership. A URL or locally cached Workspace selection cannot grant access.

6.3 Navigation rules

Navigation is generated from Workspace type, Provider category, enabled modules, current membership and later permission capabilities. Hidden navigation is presentation only; APIs enforce authorization.

Every top-level table uses the shared enterprise data-grid pattern: search, saved views, filters, sorting, column configuration, pagination or virtualization, bulk selection, permitted bulk actions, export controls and durable URL state.

6.4 Global search

Search returns only records the active membership may access. Results are grouped by record type and include enough context to distinguish similar records.

Searchable domains may include:

• Projects and Provider Jobs
• Clients and authorized contacts
• Designer Studios and Providers
• Tasks and decisions
• Items and materials
• Offers, Proposals, Work Orders and invoices
• Files by metadata and permitted extracted text
• Messages where access is allowed

Search analytics must never store sensitive query text in unrestricted logs.

6.5 Quick actions

Quick actions are contextual. Examples:

• Create Project opportunity
• Create Project
• Add task
• Schedule appointment
• Upload file
• Invite teammate
• Create Offer or Proposal
• Report receiving exception
• Start delivery route

Actions not supported by the active Workspace or current Project access are not shown.

6.6 Responsive behaviour

Desktop uses persistent navigation and multi-column dashboards. Tablet uses a collapsible rail. Mobile uses a bottom or drawer navigation optimized around Home, Projects/Jobs, Tasks, Messages and More. Critical field actions remain one-handed and do not require horizontal tables.

7. Dashboard Architecture

7.1 Dashboard contract

The dashboard is assembled from a versioned card registry. Each card definition declares:

• Stable card key
• Supported Workspace types and Provider categories
• Required capability
• Data source/read model
• Refresh strategy
• Default position and size
• Mandatory or optional state
• Empty, loading, stale, offline and error states
• Deep-link target
• Mobile rendering mode
• Analytics events

7.2 Default page order

1. Greeting and current date
2. Critical attention and action queue
3. Today and upcoming schedule
4. Project/Job health
5. Audience-specific operational work
6. Commercial work
7. Waiting and approvals
8. Activity
9. Profile/setup readiness

7.3 Card personalization

Users may reorder and hide optional cards. Workspace Owners may set a default layout by Workspace type. The following cannot be hidden when non-empty:

• Critical safety or damage alerts
• Overdue Client/Provider decisions assigned to the user
• Expiring Offers requiring action
• Credential or integration failures that block active work
• Payment or compliance holds that block Project progression

Personal layout changes affect presentation only.

7.4 Projection rules

• Dashboard cards do not own workflow status.
• Counts and summaries are recomputable from canonical records.
• Each projection records source_updated_at, projected_at and projection_version.
• A stale projection displays “Updated…” and a retry path.
• Mutating actions call the canonical service and wait for authoritative confirmation.
• Optimistic UI is permitted only when rollback is clear and no financial, access or irreversible consequence exists.

7.5 Attention priority

Attention items are ranked using explicit rules, not opaque AI alone:

1. Safety, damage, access or compliance blocker
2. Action overdue
3. Action due within configured threshold
4. Project critical-path dependency
5. Expiring Offer, Proposal or approval
6. Financial hold or invoice exception
7. New actionable assignment
8. Informational status change

Within a tier, Project risk, due date, economic value and time since last action may influence order. The interface explains why an item is prioritized.

7.6 Action states

Every actionable dashboard object is classified as one of:

• Requires my action
• Requires my Workspace’s action
• Waiting on another party
• Scheduled
• Blocked
• At risk
• Informational
• Complete

7.7 Empty states

Empty states must distinguish:

• No records exist yet
• No records match current filters
• User lacks access
• Module not enabled
• Data is loading
• Integration is disconnected
• Projection failed

Each state provides the next legitimate action without exposing inaccessible record counts.

8. Project Process Integration

8.1 Canonical seven-Phase process

All Project dashboards and Project Builder templates use these canonical phases:

1. Concept
2. Design
3. Design Package
4. Construction Administration
5. Decorating
6. Procurement
7. Installation

A Project template may disable a phase when genuinely inapplicable, but may not silently rename or reorder the canonical phase identifiers. A Workspace may configure display descriptions while preserving canonical IDs for analytics and automation.

8.2 Phase projection

For every Project visible on a dashboard, show:

• Current phase
• Phase progress
• Overall Project health
• Next milestone and due date
• Next action owner
• Open decisions
• Blocking dependencies
• Budget or item exceptions
• Latest material activity

Progress is computed from configured milestones, required tasks, approvals and completion conditions. It must not be a manually typed percentage.

8.3 Phase entry and exit gates

The dashboard surfaces unmet gates without changing the Project workflow rules. Examples:

8.4 Cross-phase work

Real Projects overlap. The dashboard may show active work from more than one phase while maintaining one current reporting phase. Cross-phase tasks and items retain their own phase association. The interface must not force Procurement work to disappear because Construction Administration is still active.

8.5 Automated phase movement

Project status may advance automatically only when the Project template’s published transition rules are satisfied. Automatic movement must:

• Evaluate the immutable template version attached to the Project
• Record the triggering events and rule version
• Respect manual approval gates
• Create a visible activity event
• Notify configured participants
• Be reversible only through an authorized correction workflow

8.6 Project health

Health values are on_track, attention, at_risk, blocked and complete. Health is derived from critical-path dates, blocked tasks, overdue approvals, item lead-time risk, unresolved damage, Provider acceptance, budget variance and financial holds. Users may add a documented manual override; the original computed result remains auditable.

8.7 Project cards and rows

The shared Project card has compact and expanded variants. Minimum fields:

• Project name and image/initials
• Client or site label appropriate to viewer
• Current phase
• Health
• Progress
• Next milestone
• Next action owner
• Due/overdue label
• Relevant financial or item exception summary

Provider versions show Job scope and Work Order, not the entire Project value.

8.8 Deep links

Dashboard actions open the precise Project location, for example:

/projects/:projectId/tasks/:taskId
/projects/:projectId/items/:itemId/receiving
/jobs/:providerJobId/offers/:offerId
/projects/:projectId/decisions/:decisionId

Returning to the dashboard preserves filters and scroll position.

9. Shared Operational Queues

9.1 My work

Aggregates tasks, approvals, decisions, exceptions and commercial actions assigned to the signed-in user. Supports due date, Project, phase, type, priority and status filtering.

9.2 Workspace work

Aggregates unassigned or team-owned actions for the active Workspace. Owners and managers can assign or reassign work subject to permissions.

9.3 Waiting on

Shows actions the Workspace cannot complete until another participant responds. Each row names the dependency, responsible party in audience-safe language, age, deadline and follow-up rules.

9.4 Exceptions

Exception types include:

• Item damage or quantity discrepancy
• Unidentified receiving item
• Late or unconfirmed shipment
• Missing site measurement
• Delivery access issue
• Schedule conflict
• Expired or expiring credential
• Budget variance
• Rejected deliverable
• Work Order change awaiting response
• Invoice mismatch or payment failure

9.5 Bulk actions

Bulk actions are permitted only when they share an unambiguous outcome and authorization rule. Financial approvals, phase changes, damage resolution and access grants must not be bulk-completed by default.

10. Calendar and Schedule

10.1 Unified Project calendar

The dashboard calendar combines permitted Project milestones, tasks, appointments, site visits, deliveries, receiving appointments, shoots, inspections, installations and internal events.

10.2 Views

• Today agenda
• Week
• Month
• Project timeline
• Provider dispatch/schedule board
• Mobile day route

10.3 Google Calendar integration

Users may connect Google Calendar. The integration supports:

• Publish selected Design Registry events to a connected calendar
• Import busy/free availability without copying private event details
• Detect conflicts
• Store external event IDs and sync state
• Handle revoked consent and failed sync
• Avoid duplicate events through idempotency keys

Project data sent externally must be minimized according to audience and Workspace policy.

10.4 Scheduling rules

• Time zone is explicit on all events.
• Project/site time zone is the default for field work.
• Rescheduling creates an activity event and triggers editable notifications.
• An external calendar edit cannot bypass Project approval or dependency rules.
• Delivery routes and crew schedules may have category-specific views while sharing event primitives.

11. Designer Studio Dashboard

11.1 Primary jobs to be done

• See every active Project and its true next action
• Protect design time by exposing only meaningful exceptions
• Manage Client decisions and approvals
• Coordinate Providers without disconnected email chains
• Understand budgets, items and procurement risk
• Respond to new Project opportunities and manage owned leads
• Run the Studio’s team, profile and integrations

11.2 Default modules

1. Requires my attention
2. Today and upcoming
3. Active Projects by phase and health
4. Client approvals and overdue decisions
5. Tasks and critical dependencies
6. Item, budget and procurement exceptions
7. Provider matching, Offers and accepted work
8. Proposals, Work Orders, invoices and payments
9. Recent Project activity
10. Studio profile and integration readiness

11.3 Project opportunity integration

Designers may receive matched Project opportunities. The dashboard shows opportunity summary, response deadline, fit signals, authorized Client/Project information and response actions. Opportunity data remains distinct from active Projects until conversion.

11.4 Owned Projects

Designer Studios may create and manage their own Projects, leads and Clients. These Projects use the same Project process and may optionally purchase Registry Provider services. The dashboard distinguishes Registry-sourced and Studio-owned work only where operationally useful; the core Project experience remains consistent.

11.5 Design and procurement intelligence

The dashboard should highlight:

• Client decisions holding up design
• Rooms/categories exceeding target budget
• Items needing approval or purchase
• Vendor price or availability changes
• Items with lead times threatening milestones
• Purchase orders not acknowledged
• Expected receipts without appointments
• Received items damaged or incomplete
• Installation items not delivery-ready

12. Client Dashboard

12.1 Experience objective

The Client dashboard is calm, guided and intentionally narrower. It should feel like a premium Project concierge, not an internal operations tool.

12.2 Default modules

• Project welcome and current phase
• What we need from you
• Upcoming meetings and milestones
• Approvals and decisions
• Approved budget summary and payment requests
• Curated Project progress
• Messages
• Published files and presentations
• Installation/delivery schedule appropriate to the Client

12.3 Visibility rules

Clients must not see:

• Internal notes
• Provider bid comparisons unless intentionally shared
• Registry margin, referral revenue or negotiated Provider rates
• Provider identities that are intentionally managed behind the service layer
• Unpublished drafts
• Internal health scoring or staff performance analytics
• Other Clients or Projects

12.4 Client actions

• Approve, reject or request changes with comment
• Sign or accept a Proposal where enabled
• Pay an invoice or view payment instructions
• Upload requested information
• Confirm availability or access
• Message authorized Project participants
• Review a curated timeline

High-impact approvals require an explicit review screen and timestamped confirmation.

13. Registry Administration Dashboard

13.1 Purpose

Registry operators monitor marketplace and Project execution without becoming the daily owner of every task.

13.2 Default modules

• Applications requiring review
• Matching queues and opportunity response
• Active Projects by market, phase and health
• Project escalations
• Provider capacity and service quality
• Offer, Proposal and Work Order exceptions
• Invoice and payment exceptions
• Profile verification and credential expiry
• Integration and notification delivery failures
• Marketplace volume and operational performance

13.3 Market context

Authorized Registry users can filter by market, Provider category, Designer cohort, Project source and date. Market access must be enforced server-side.

13.4 Existing overview evolution

The existing Overview’s attention cards, Project progress table, Designer workload and recent activity are retained as shared patterns. Temporary Phase labels must be mapped to the canonical seven-Phase process, and every summary must deep-link to its source queue.

14. Common Provider Dashboard

14.1 Provider value proposition

Providers must receive enough operational value to keep Offers, Project work, evidence, invoices and payments inside the Design Registry. The portal is a practical business operating surface, not a marketplace inbox.

14.2 Common modules

1. New and expiring Offers
2. Proposals requested or awaiting response
3. Active Provider Jobs
4. Work Orders requiring acknowledgement
5. Today’s schedule
6. Tasks and dependencies
7. Exceptions and blocked work
8. Items/materials relevant to assigned scope
9. Invoices and payment status
10. Recent messages and activity
11. Profile, capacity and credential readiness

14.3 Offers

Every Provider category receives Offers. A Provider can:

• Review authorized Project and scope information
• Ask a question through the scoped thread
• Accept
• Decline with structured reason
• Request clarification or a response extension where allowed
• Submit a Proposal when requested

“Reflect” is not an accepted product term; the action is Decline or Request changes/clarification, depending on intent.

14.4 Accepted work

Accepted Offers may lead to Proposal review, Work Order issuance and invoicing. Provider dashboards show only assigned or accepted scope. Unaccepted marketplace opportunities do not grant general Project access.

14.5 Provider business tools

Providers may use CRM, Project, task, calendar, Proposal and invoicing tools for their own business where enabled. Registry-mediated Projects and Provider-owned records use the same components but remain distinguishable by source and data-sharing rules.

15. Provider Category Dashboards

15.1 Vendors and Product Suppliers

Primary modules

• Quote and availability requests
• Samples requested, shipped and returned
• Product substitutions and discontinued items
• Purchase order acknowledgement
• Deposit/balance requirements
• Lead-time changes
• Shipment tracking and expected arrival
• Claims, returns and replacements
• Invoice readiness

Project integration

Items are the core operational object. Vendors see only requested or ordered product lines, authorized specifications, quantities, ship-to instructions and relevant deadlines. Updating availability or lead time creates a Project item event and may trigger risk recalculation.

15.2 Millwork and Custom Fabrication

Primary modules

• Bid invitations and scope packages
• Site measurement dependencies
• Shop drawing/submittal queue
• Client/Designer approvals
• Material selections
• Fabrication schedule
• Change requests
• Delivery and installation milestones
• Deficiencies and completion evidence

Project integration

Work is organized by fabricated assembly, room, drawing package and Work Order. Approval versions are immutable; superseded drawings remain available in history.

15.3 Contractors and Specialty Trades

Primary modules

• Bid/quote requests
• Site schedule and access
• Assigned scope and phase tasks
• RFIs and responses
• Material/submittal approvals
• Inspections
• Change requests
• Deficiencies and closeout
• Invoice readiness

Project integration

Construction materials are distinct from decorating/procurement product items but share the item framework. They support submittals, quantities, alternates, delivery to site, installation status and evidence.

15.4 Photography

Primary modules

• Shoot Offers
• Brief and shot-list readiness
• Styling/site dependencies
• Calendar and access contacts
• Asset upload and delivery
• Revision requests
• Usage rights and release status
• Invoice readiness

Project integration

Photography Jobs are attached to a Project milestone or completed Project. Assets inherit explicit audience and usage permissions rather than becoming globally visible on upload.

15.5 Measurement and Drafting

Primary modules

• Site visit requests
• Access/contact readiness
• Measurement scope and checklist
• Drawing deliverable queue
• Quality review
• Revision requests
• Issued file versions
• Invoice readiness

Project integration

Measurements and drawings feed the Concept, Design and Design Package phases. Issued documents are versioned Project deliverables and can satisfy configured phase gates.

15.6 Receiving, Warehouse and Storage

Primary modules

• Expected arrivals
• Receiving appointments
• Scan/search by PO, tracking number, barcode or item
• Receive item and quantity
• Condition assessment and required photographs
• Damage, shortage, overage and unidentified-item exceptions
• Storage location assignment
• Inventory aging and storage duration
• Pull lists, releases and delivery readiness
• Recurring storage invoice readiness

Project integration

Receiving changes the canonical item custody state. The workflow must record who received the item, timestamp, facility, quantity, condition, photographs and storage location. Damage immediately creates an exception visible to authorized Designer and Registry users. A release cannot be completed for an item on hold without documented resolution.

15.7 White-Glove Delivery

Primary modules

• Delivery Offers and estimate requests
• Manifests and item readiness
• Pickup and delivery appointments
• Vehicle, crew and route assignment
• Access instructions and contact confirmation
• Load confirmation
• En route, arrived and service-in-progress states
• Item-level delivery outcomes
• Proof of delivery, photographs and signature
• Damage or access exceptions
• Invoice readiness

Project integration

The Designer dashboard receives authorized live route milestones so the team knows where the crew is on installation day. Exact tracking visibility, retention and Client sharing are configurable. GPS collection requires explicit workforce policy and is limited to active routes.

15.8 Installation Services

Primary modules

• Install Offers and scope
• Installation date and crew
• Site readiness checklist
• Item readiness and room plan
• Sequence and dependencies
• Installed/not installed/blocked outcomes
• Deficiencies and punch list
• Completion photographs and sign-off
• Invoice readiness

Project integration

Installation updates both item state and Project completion. A Job cannot be marked complete while required deficiencies remain open unless an authorized partial-completion path is used.

15.9 General Service Providers

General Providers use a configurable version of Offers, Jobs, tasks, schedule, deliverables, evidence and invoicing. New categories must be assembled from approved modules before custom code is introduced.

16. Commercial Operations on the Dashboard

16.1 Shared progression

Offer
  → Provider response
  → Proposal, when required
  → Approved commercial commitment
  → Work Order
  → Work performed and evidenced
  → Invoice
  → Payment

Not every job requires every step, but skipped steps must be explicit in the governing workflow.

16.2 Commercial cards

Cards group canonical statuses into presentation queues without overwriting them:

• Needs response
• Drafting
• Awaiting review
• Approved/accepted
• Active work
• Ready to invoice
• Payment pending
• Closed
• Exception

16.3 Financial visibility

• Designers see Client and Provider amounts only as authorized by Project role and commercial model.
• Providers see their own quoted, ordered, invoiced and paid amounts.
• Clients see approved Client-facing totals, invoices and payments.
• Registry operators see platform economics only with appropriate access.

Dashboard totals must specify currency, tax inclusion and date basis. Cross-currency totals are not added without a defined conversion basis.

16.4 Stripe and manual payment support

Payment surfaces support Stripe payment states and manually reconciled bank payments. The dashboard never treats a Client-side success redirect as proof of payment; authoritative webhook or reconciliation state is required.

16.5 QuickBooks integration

Where enabled, invoice/payment sync shows connected organization, last sync, failures and reconciliation state. QuickBooks does not become the source of Project operational status.

17. Items, Materials, Budgets and Logistics

17.1 Shared item framework

Items support two primary operational classes:

• Construction materials and assemblies
• Decorating/procurement products and furnishings

They share identifiers, attachments, quantities, pricing, schedule, custody and evidence primitives while exposing class-specific fields and views.

17.2 Dashboard summaries

• Items awaiting approval
• Items over budget
• Items not ordered
• Unconfirmed lead times
• Shipments at risk
• Expected this week
• Received with exception
• In storage
• Ready for release
• Scheduled for delivery
• Delivered, installed or deficient

17.3 Budget integration

Budget cards are calculated from Project categories and item values. They show planned, committed, ordered, invoiced, paid and forecast amounts, plus variance. Every aggregate drills into the contributing categories and items.

17.4 Spreadsheet import

Imported item lists create a staged validation session. Users map columns, resolve duplicates and validation errors, preview changes and then commit. Imports must not bypass item type, currency, category or Project access rules.

17.5 Google Sheets

Where enabled, Sheets export/sync is a convenience surface. The Design Registry remains authoritative for Project workflow and item state. Sync conflicts are visible and never silently overwrite a newer canonical change.

18. Workspace Profile Architecture

18.1 Profile separation

One profile must never be overloaded to serve all four purposes.

18.2 Workspace Profile common sections

• Legal and display name
• Logo and brand assets
• Primary contact
• Business addresses
• Phone, email and website
• Time zone, locale and default currency
• Service areas
• Business hours
• Capacity and availability
• Insurance, licences and credentials
• Tax and invoicing settings
• Integrations
• Notification defaults
• Public/Network visibility controls
• Data and security settings

18.3 Designer Studio fields

• Studio description and approach
• Design specialties
• Style attributes
• Project types
• Minimum/typical budgets
• Service areas
• Languages
• Team size and capacity
• Portfolio and media
• Services offered
• Availability and lead time
• Matching preferences

18.4 Provider common fields

• Primary and secondary Provider categories
• Capabilities and services
• Service areas and travel rules
• Minimum job value
• Lead times and capacity
• Hours and emergency availability
• Commercial contact
• Operational contacts
• Insurance/licences/certifications
• Facilities, vehicles or equipment where relevant
• Matching attributes
• Project references, portfolio and evidence

18.5 Category-specific profile fields

Examples:

• Vendor: brands, product categories, trade program, shipping regions, samples, order minimums
• Millwork: fabrication types, materials, shop capacity, engineering/drawing capabilities, install capability
• Trade: trade specialties, licence jurisdictions, crew capacity, project scale
• Photography: specialties, usage terms, delivery turnaround, equipment/crew
• Drafting: measurement methods, deliverable formats, software, professional credentials
• Storage: facility locations, receiving hours, storage types, climate control, handling capability
• White-glove: service regions, vehicles, crews, route capacity, assembly, packaging removal
• Installation: categories installed, crew capacity, service regions, tools/certifications

18.6 Profile impact warnings

Edits to category, service area, insurance, verification, capacity or matching fields may affect active matchmaking and Projects. Before saving, show impact and whether Registry review is required. Existing Work Orders are not silently invalidated.

18.7 Completeness and readiness

Completeness is section-based and explains missing requirements. Readiness states:

• Setup incomplete
• Ready for internal use
• Pending Registry verification
• Network active
• Limited/expiring
• Suspended

A cosmetic percentage alone is insufficient.

18.8 Canonical Entity Profiles

The platform uses one reusable Entity Profile shell with role-specific extensions:

• Designer Studio Profile for the durable studio organization;
• Provider Profile for the durable Provider organization;
• Client Profile for the durable Client relationship;
• person-level Designer Profile and User Profile where individual identity is required.

The shared shell provides a stable Entity ID, header, Network Status or relationship state, Relationship Owner, permitted actions, Overview, Teammates, Credentials, Assignments, Files, Tasks, Communication, Notes, Activity, Performance and History. Entity- and Category-specific information configures these modules instead of forking their implementation.

A Provider Profile visibly lists all nine canonical Provider Categories and the Provider’s qualification state in each applicable Category. Categories with no Providers remain visible in the directory as zero-count entry points. One Provider may hold multiple Category Qualifications while retaining one Entity, Workspace, Teammate roster and activity history.

18.9 Administrative Access Sessions

Registry support may enter another Workspace only through a governed Administrative Access Session. The entry action must not be labelled simply Log in to workspace.

Required controls:

• selected reason and optional support reference;
• target Workspace and scope preview;
• time-limited session with a persistent visual banner;
• immutable actor, start, end and action audit events;
• step-up authentication for protected actions;
• explicit exit and automatic expiry;
• no password, authentication-factor or private-token disclosure;
• configurable restrictions on payments, exports, identity, permissions and destructive actions.

Administrative Access Sessions are separate from Memberships and do not silently create permanent access.

19. User Profile

19.1 Person-owned fields

• Preferred name and legal name where required
• Profile image
• Email and phone
• Time zone and locale
• Pronouns, optional
• Accessibility preferences
• Notification preferences
• Calendar connection and availability
• Security and authentication entry points
• Connected account status

19.2 Workspace-specific fields

Job title, Role Label, Team membership, default assignment rules and Workspace membership state belong to the membership/teammates system, not the global User Profile.

19.3 Owner controls

A Workspace Owner can edit the Workspace Profile and permitted membership details. They cannot rewrite another person’s global identity, personal notification choices or authentication credentials.

19.4 Account menu

• My Profile
• Notification preferences
• Calendar and connected accounts
• Switch Workspace
• Security
• Help
• Sign out

20. Branding and Personalization

20.1 Brand controls

Workspace Owners may configure:

• Workspace logo
• Display name
• Approved accent colour
• Client-facing email footer
• Proposal and invoice branding
• Optional cover imagery
• Sender display preferences where supported

20.2 Guardrails

• The Design Registry shell and accessibility standards remain intact.
• Contrast must meet accessibility requirements.
• Branding cannot obscure record provenance or legal sender identity.
• Provider-facing Project work must clearly identify the relevant Project and issuing party.
• A Workspace cannot imitate another Workspace or the Registry administration identity.

20.3 Client presentation

Client-facing experiences may emphasize the Designer Studio’s brand while retaining subtle Design Registry attribution and secure account context.

21. Shared Modules

21.1 Tasks

Tasks support title, description, type, state, priority, owner, collaborators, due date/time, Project, phase, Work Package, dependency, recurrence, attachments and activity. Dashboard task changes update the canonical task record.

21.2 Activity

Activity is an append-oriented timeline of material business events. It distinguishes system changes, communications, tasks, files, approvals, commercial events and field evidence. Audience filtering happens before rendering.

21.3 Files

Files have source, owner, Project, phase, category, version, audience, malware scan status and retention metadata. Dashboards show recent or actionable files without creating duplicates.

21.4 Communications

Messages, email, SMS and permitted calling events are threaded by Project and participant context. Dashboard previews do not expose content to users who could not open the full thread.

21.5 Notes

Internal notes remain internal to their authorized audience. Client notes and Provider-visible messages are distinct communication types, not a visibility toggle on the same unrestricted text object.

22. Notifications Centre and Builder Integration

22.1 Rule

Every new event that may notify a user or Workspace must register a stable event definition in the Notification Builder. Features may not embed uneditable email/SMS copy directly in application code except protected security or legal templates.

22.2 Required event families

Project

• project.created
• project.phase_changed
• project.health_changed
• project.milestone_due
• project.milestone_overdue
• project.decision_requested
• project.decision_overdue
• project.file_published
• project.message_received

Offer and commercial

• offer.received
• offer.expiring
• offer.accepted
• offer.declined
• proposal.requested
• proposal.submitted
• proposal.changes_requested
• work_order.issued
• work_order.changed
• work_order.acknowledgement_required
• invoice.submitted
• invoice.approved
• invoice.payment_failed
• payment.received

Items and logistics

• item.approval_requested
• item.expected_receipt
• item.received
• item.receiving_exception
• item.damage_reported
• item.storage_location_changed
• item.release_requested
• delivery.scheduled
• delivery.en_route
• delivery.arrived
• delivery.completed
• delivery.exception
• installation.deficiency_reported

Profile and operations

• profile.incomplete
• profile.verification_required
• credential.expiring
• integration.disconnected
• calendar.sync_failed
• projection.rebuild_failed

22.3 Editable controls

Authorized owners can configure:

• Subject/title and body within protected constraints
• In-app, email and SMS channel enablement
• Recipient rules
• Timing, reminders and escalation
• Quiet hours
• Workspace branding
• Locale variants

22.4 Recipient resolution

Recipients are resolved at event time from Project relationships, assignment, Workspace membership, Team rules and personal notification preferences. Recipient resolution is logged. Removed or suspended members are excluded.

22.5 Delivery providers

• Resend for transactional email
• Twilio for SMS and future calling workflows
• In-app notifications through the platform
• Push as a future channel

Notification failure does not roll back the Project event. Failed delivery is retried according to policy and shown in delivery history.

23. Navigation Matrix

The matrix is a product default, not the final permissions model.

24. Data Model

24.1 Core tables

workspace_profiles
workspace_profile_versions
workspace_branding
workspace_capabilities
provider_category_profiles
provider_credentials
provider_capacity_periods
user_profiles
user_preferences
user_connected_accounts

dashboard_definitions
dashboard_card_definitions
dashboard_layout_defaults
dashboard_user_layouts
dashboard_card_states
dashboard_projections
attention_items
attention_item_assignments
provider_job_projections

project_access_grants
project_participants
project_phase_instances
project_health_snapshots
project_milestones
project_decisions
activity_events

notification_event_definitions
notification_variable_schemas
notification_templates
notification_template_versions
notification_delivery_rules
notification_deliveries
notification_delivery_attempts

24.2 Key constraints

• Every tenant-owned record has workspace_id or an unambiguous parent leading to Workspace scope.
• Project projections reference canonical project_id.
• Provider Job projections reference Provider Workspace, Project and authorized Work Order/assignment.
• User layouts are unique by user, Workspace and dashboard definition version.
• Profile versions are append-only after publication/review.
• Notification event keys are globally stable and cannot be recycled.
• Soft deletion never grants access to archived relationships.

24.3 Suggested projection record

dashboard_projections
  id
  workspace_id
  user_id nullable
  projection_type
  source_type
  source_id
  payload_jsonb
  priority
  source_updated_at
  projected_at
  projection_version
  stale_after

JSON payloads are presentation projections, not arbitrary replacements for relational source data.

24.4 Audit fields

Material records include created_at, created_by, updated_at, updated_by, source, correlation_id and version where applicable. High-impact actions record before/after values and reason.

25. Supabase Architecture

25.1 Services

• Supabase Auth for authenticated identity
• Postgres for canonical data and read models
• Row Level Security for tenant and Project relationship enforcement
• Storage for logos, profile media, files and evidence
• Realtime for selected in-app updates, not as the sole delivery guarantee
• Edge Functions for trusted integration and webhook workflows
• Queued/background processing for projection rebuilds, notifications and external sync

25.2 Row Level Security direction

RLS policies must evaluate active Workspace membership and, for Project-scoped data, explicit Project relationships/access grants. Provider access is constrained to its Workspace and authorized Provider Jobs. Client access is constrained to published Client-visible records.

Service-role operations are limited to trusted server functions and are never exposed to the browser. Views used by the dashboard must preserve security boundaries and must not bypass underlying access rules.

25.3 Projection processing

Canonical domain changes write an outbox/event record in the same transaction where practical. Workers process events idempotently to:

• Recalculate attention
• Rebuild dashboard projections
• Recalculate Project health
• Register activity
• Resolve notification recipients
• Trigger permitted external sync

Each handler uses an idempotency key based on event ID and handler version.

25.4 Storage

Buckets and paths separate Workspace and Project scope. Signed URLs are short-lived. Metadata authorization happens before signed URL issuance. Uploaded evidence is scanned and is not published to broader audiences before validation.

25.5 Realtime

Realtime may update attention counts, Project health, new messages, route status and receiving events. Reconnection triggers a canonical refresh so missed realtime events do not create stale truth.

26. API Design

26.1 Dashboard

GET   /v1/workspaces/:workspaceId/dashboard
GET   /v1/workspaces/:workspaceId/dashboard/attention
GET   /v1/workspaces/:workspaceId/dashboard/schedule
GET   /v1/workspaces/:workspaceId/dashboard/projects
GET   /v1/workspaces/:workspaceId/dashboard/jobs
GET   /v1/workspaces/:workspaceId/dashboard/commercial
GET   /v1/workspaces/:workspaceId/dashboard/activity
PATCH /v1/workspaces/:workspaceId/dashboard/layout
POST  /v1/workspaces/:workspaceId/dashboard/rebuild

26.2 Profiles

GET   /v1/me/profile
PATCH /v1/me/profile
GET   /v1/me/preferences
PATCH /v1/me/preferences

GET   /v1/workspaces/:workspaceId/profile
PATCH /v1/workspaces/:workspaceId/profile
GET   /v1/workspaces/:workspaceId/network-profile
PATCH /v1/workspaces/:workspaceId/network-profile
POST  /v1/workspaces/:workspaceId/profile/submit-for-review

26.3 Provider Jobs

GET   /v1/workspaces/:workspaceId/jobs
GET   /v1/jobs/:jobId
GET   /v1/jobs/:jobId/items
GET   /v1/jobs/:jobId/schedule
GET   /v1/jobs/:jobId/tasks
GET   /v1/jobs/:jobId/commercial
POST  /v1/jobs/:jobId/evidence
POST  /v1/jobs/:jobId/exceptions

26.4 Response requirements

• Stable IDs and canonical status values
• Viewer-specific permitted links/actions
• Currency and time-zone metadata
• Projection timestamps and staleness
• Pagination cursors for lists
• No hidden data included for client-side filtering
• Correlation ID for support and audit

26.5 Error model

{
  "error": {
    "code": "PROJECT_ACTION_BLOCKED",
    "message": "This action is blocked by two required approvals.",
    "details": {"blockingRecordIds": ["..."]},
    "correlationId": "..."
  }
}

User messages are specific and safe; internal stack traces and inaccessible record details are excluded.

27. AI Assistance

27.1 Approved uses

• Summarize authorized Project activity
• Draft a daily briefing from visible records
• Suggest task prioritization with explanation
• Extract structured profile data from uploaded credentials for confirmation
• Flag potential schedule or item risk
• Draft Provider responses, Project updates and profile copy
• Map spreadsheet columns during item import

27.2 Guardrails

• AI does not grant access or change permissions.
• AI does not automatically approve spend, Offers, Work Orders, invoices, phase gates or damage resolution.
• AI only receives data the requesting user may access.
• Suggestions identify their source records and uncertainty.
• User confirmation is required before external communication or material record change.
• Sensitive data is minimized and retained according to policy.

27.3 AI daily brief

The optional daily brief groups facts into Requires action, Today, At risk and Waiting. Every statement links to its source. If no reliable source exists, the brief omits the claim.

28. Analytics and Success Metrics

28.1 Product metrics

• Weekly active Workspaces by type
• Percentage of active Projects with current next action
• Median time from attention item creation to resolution
• Overdue approval and task rate
• Offer response time and acceptance rate
• Provider Job activity completed inside the platform
• Receiving exception resolution time
• Delivery/install completion captured with evidence
• Invoice and payment processing through the platform
• Profile/network readiness completion
• Notification delivery and action conversion

28.2 Quality metrics

• Projection reconciliation failure rate
• Unauthorized access test failures: target zero
• Duplicate notification rate
• Calendar sync conflict rate
• Dashboard API latency
• Mobile field-action completion rate
• Support cases caused by unclear next action

28.3 Event examples

dashboard_viewed
dashboard_card_opened
attention_item_opened
attention_item_resolved
project_stage_summary_opened
provider_job_opened
offer_response_started
receiving_exception_created
delivery_status_updated
profile_section_completed

Analytics payloads use IDs and controlled attributes rather than message content, file names or sensitive notes.

29. User Stories

29.1 Designer

• As a Designer, I can see the next action across every Project so I do not rebuild a status sheet.
• As a Designer, I can see which Client decisions block the critical path.
• As a Designer, I can see budget, item and delivery exceptions before they affect installation.
• As a Studio Owner, I can see team workload and Workspace readiness.
• As a Designer, I can send Provider work from the Project and track it without exposing unrelated scope.

29.2 Provider

• As a Provider, I can review and respond to new Offers in one queue.
• As a storage Provider, I can receive an item, record condition and assign a storage location from my phone.
• As a white-glove Provider, I can run a route and give authorized Designers useful live status.
• As a millworker, I can submit a drawing version and know which approval is current.
• As a Provider Owner, I can manage my business profile, capacity, Jobs, invoices and payments.

29.3 Client

• As a Client, I can see what the Project needs from me without seeing internal complexity.
• As a Client, I can approve a decision with a durable record.
• As a Client, I can see upcoming Project events and published progress.

29.4 Registry operator

• As an operator, I can identify Project and marketplace exceptions across my market.
• As an operator, I can see Provider readiness and credential risk.
• As an operator, I can trace every dashboard alert to a canonical record and event.

30. Acceptance Criteria

30.1 Shared shell

• A user with multiple active memberships can switch Workspace and sees the correct navigation and data.
• A user cannot access another Workspace by changing a URL or request body.
• Navigation adapts by Workspace type without creating separate front-end applications.
• Search returns only authorized records.

30.2 Dashboard

• Every card has loading, empty, stale, error and access-denied behaviour.
• Every displayed Project, Job, task, decision, item or commercial record deep-links to its canonical source.
• Dashboard state can be rebuilt from canonical records.
• Mandatory critical attention cannot be hidden.
• Returning from a source record preserves dashboard context.

30.3 Project integration

• All dashboards use the seven canonical Project phases.
• Project progress is derived from the attached template version and completion criteria.
• Cross-phase tasks remain visible.
• Automated phase movement records its trigger and creates activity.
• Provider actions update canonical Project/Job records, not dashboard-only fields.

30.4 Provider portals

• Every Provider category receives Offers.
• A Provider sees only accepted/assigned Project scope and authorized pre-acceptance Offer data.
• Storage can capture item condition, photos, exceptions and location.
• White-glove can manage manifests, crews, route states and proof.
• Installation can record item-level outcomes and deficiencies.
• Category activity appears in the authorized Designer/Registry Project view.

30.5 Profiles

• Workspace Owner can edit Workspace Profile and branding.
• Each user can edit their own User Profile and personal preferences.
• Membership role data is not edited through the global User Profile.
• Matching-impact changes show warning and review state.
• Client-facing, Network and operational fields respect publication status.

30.6 Notifications

• Every notification-capable event is registered in Notification Builder.
• Templates are versioned and variable schemas validated.
• Resend/Twilio failures are retried and visible without rolling back the business event.
• Removed or suspended members do not receive new Workspace notifications.

30.7 Mobile and accessibility

• Critical Provider field actions are usable at mobile width.
• Keyboard navigation, focus order, labels and contrast meet the chosen accessibility standard.
• Status is never communicated by colour alone.
• Dates, currency and time zones are explicit and localized.

31. Test Matrix

31.1 Tenant and Project isolation

Test every endpoint and realtime channel across:

• Same user, two Workspaces
• Two users, same Workspace
• Suspended membership
• Provider with one accepted Job and one unrelated Project
• Client with one Project
• Registry user restricted to one market
• Expired access grant

31.2 Projection reconciliation

• Canonical record changes while worker is unavailable
• Duplicate event delivery
• Out-of-order event delivery
• Projection schema/version upgrade
• Source record archived
• Project access revoked

31.3 Notifications

• Email success/failure
• SMS success/failure
• Quiet hours
• Template variable missing
• Recipient suspended after event but before send
• Duplicate webhook
• User preference versus protected required notification

31.4 Field workflows

• Poor connectivity during receiving
• Photo upload retry
• Duplicate barcode scan
• Partial quantity received
• Route state update without location permission
• Delivery exception and proof upload
• Installation partial completion

31.5 Profile workflows

• Draft save
• Review-required field change
• Credential expiry
• Branding contrast failure
• Network profile publication
• Category change with active Work Orders

32. Migration Plan

32.1 Preserve the current shell

Retain the current left navigation, page headers, search, notification entry point, attention patterns, Project table, Settings shell and shared visual language.

32.2 Normalize vocabulary

• Replace temporary Project phase labels with canonical IDs and mapped display values.
• Rename Provider types to the approved Provider taxonomy.
• Replace ambiguous Offer actions with Accept, Decline and Request clarification/changes.
• Use Workspace, Project, Provider Job and Work Order consistently.

32.3 Introduce profiles without duplication

Migrate existing Designer/Provider entity fields into structured Workspace and Network Profiles. Keep a field mapping and reconciliation report. Do not discard unknown legacy values.

32.4 Introduce projections

1. Create projection tables and event outbox.
2. Backfill from canonical records.
3. Compare new and existing dashboard counts in shadow mode.
4. Resolve discrepancies.
5. Switch cards to new read models.
6. Retain reconciliation tooling during stabilization.

32.5 Provider portal rollout

Start with common Offers, Jobs, tasks, calendar, messages and profile. Add category operations in an order aligned to marketplace launch, with receiving/storage and white-glove prioritized because they create differentiated operational value.

33. Implementation Phases

Phase 1 — Foundations

• Workspace context and switcher hardening
• Shared shell/navigation registry
• User and Workspace Profile separation
• Dashboard card registry
• Project access grants
• Projection/outbox foundations
• Notification event registration contract

Phase 2 — Designer and Registry dashboards

• Project-driven attention
• Seven-phase Project summaries
• Tasks, calendar, activity and Client decision queues
• Project health and milestones
• Existing admin Overview migration

Phase 3 — Common Provider portal

• Offers
• Provider Jobs
• Work Orders
• Tasks, messages, files and schedule
• Profile/capacity/credential readiness
• Invoice/payment summaries

Phase 4 — Logistics Provider operations

• Receiving/warehouse/storage
• White-glove dispatch and tracking
• Installation readiness and deficiencies
• Item custody chain and evidence

Phase 5 — Design and construction Provider operations

• Vendor/product workflows
• Millwork/fabrication
• Contractors/trades
• Measurement/drafting
• Photography

Phase 6 — Client experience and financial integration

• Curated Client dashboard
• Approvals and published files
• Stripe/manual payment surfaces
• QuickBooks reconciliation
• Client calendar and messaging

Phase 7 — Intelligence and optimization

• AI daily brief
• Risk suggestions
• Advanced capacity and matching signals
• Personal layout controls
• Operational analytics and benchmarks

Each phase must ship with RLS tests, audit coverage, Notification Builder events, mobile states, accessibility review and projection reconciliation.

34. Definition of Done

The authenticated Workspace experience is complete when:

1. The same shared shell supports Registry, Designer, Client and all Provider categories.
2. The dashboard is a reliable projection of Projects and commercial operations, not an alternate workflow database.
3. Every user can identify the next correct action immediately.
4. The seven-Phase Project process is represented consistently across dashboards and category workflows.
5. Providers can operate accepted work deeply enough that using the portal is easier than returning to email and spreadsheets.
6. Clients receive a premium, controlled and audience-safe experience.
7. Workspace Owners can manage Workspace identity, profile, brand, readiness and integrations while users manage their own profiles.
8. Every relevant event is represented in the Notification Builder.
9. Tenant, Project and audience isolation are enforced in the backend and verified by tests.
10. Every dashboard value can be traced to a canonical record, source event and projection timestamp.

The Design Registry succeeds when the dashboard disappears into the work: Designers stay focused, Providers coordinate through the Project, Clients always know what is needed, and the network gains a trustworthy operational record.

Live-product correction contract — August 4, 2026

The current Workspace Profile is version 0, private and incomplete. It exposes identity, operations, qualification, branding, integrations and visibility, but still carries Proper Gallery seed identity and the implementation-oriented Workspace type platform admin.

• Replace legacy seed identity with the actual Workspace identity during migration; do not copy Proper Gallery into new Workspaces.
• Use canonical Workspace types: Registry Administration, Designer Studio, Provider and Client where a Client Workspace exists.
• Store shared identity once, then extend it by Workspace type and Provider Category without duplicating profiles.
• Implement actual draft, publish and immutable-version behavior before claiming that every save creates an immutable snapshot.
• Make completeness and readiness rules explicit by section and Workspace type.
• Apply field-level visibility to public profiles, cross-Workspace projections, Matchmaking, documents and AI context.
• Reuse Workspace branding in Notifications, Proposals, Invoices, Project Presentations and portal surfaces through one versioned brand profile.
• Accept approved Application data only through stable field mappings with provenance, review status and conflict handling.

Profile design families — live clarification

The product intentionally uses two different profile design families. They share the Design Registry field system, typography, actions and accessibility standards, but they must not be forced into the same page anatomy.

Settings-profile family

Used by:

• User Profile at /account/profile; and
• Workspace Profile at /admin/settings/workspace-profile.

This family is a dedicated full-page settings editor with:

• contextual eyebrow and explanatory ownership copy;
• section navigation rather than operational record tabs;
• grouped form fields and preferences;
• one explicit save model with dirty, saving, saved, error and conflict states;
• no general Notes, Files, Tasks, Activity or History tabs; and
• clear separation between person-owned, Workspace-owned and authentication-owned values.

Operational Entity-profile family

Used by Designer Studios, Providers, Clients and other durable network Entities. This family emphasizes record identity, summary cards, status, relationships and reusable operational modules such as Activity, Notes, Files, Tasks, Communications, Matchmaking and commercial work.

The two families reuse the same underlying components and canonical records but solve different user jobs. A settings profile should not be visually converted into an operational CRM record merely to achieve superficial consistency.

User Profile correction contract — August 4, 2026

The live User Profile includes Personal, Accessibility, Calendar, Notifications and Security sections. The following corrections and extensions are required:

1. Replace the general Phone textbox with the international Phone Number component from Spec 16, including E.164 storage, raw input, country, extension, type and separate communication consent.
2. Replace free-text Typical working hours and Working days with structured availability and Calendar controls.
3. Preserve timezone, locale, date format and time format as person-owned preferences that apply across Workspaces.
4. Apply Reduce motion, Higher contrast and Larger interface text early enough to avoid presentation flashes.
5. Generate Notification preferences from the complete Domain Event catalogue. The current list is dominated by Application and provisioning events because other product domains have not yet registered their events.
6. Required operational and security notifications remain visible and cannot be disabled.
7. Add direct verified sign-in-email change, MFA, active-session/device management, session revocation and recent security-event history through Supabase Auth-safe flows.
8. Never place Job title, Role Label, Team, Access Role or Workspace Membership state in the global User Profile.
9. Workspace Owners may manage permitted Membership data but cannot edit another person’s global identity, accessibility settings, personal Calendar defaults, notification preferences or authentication credentials.
10. Add unsaved-change protection, server validation, optimistic-concurrency handling and clear save confirmation across every section.

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

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 04
Mapped current-product profiles: 9
Recorded review gaps: 49

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

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

Review gaps

• Messages, Proposals and Reports have non-routable placeholder links.
• The resolved Workspace still displays the legacy name Proper Gallery.
• Loading content is visibly rendered before membership and Workspace resolution.
• Designer, Provider and Client shell variants have not been validated.
• Mobile, tablet, offline and connectivity behavior have not been validated.
• The repository implementation has not yet been traced for this reverse spec.

Required future closure

• Replace legacy Workspace naming and seed data.
• Complete all top-level routes or visibly label unavailable modules.
• Generate navigation from Workspace type, Provider category, enabled modules and effective permissions.
• Add responsive navigation and connectivity/data freshness behavior.
• Prevent Workspace-loading flicker from revealing stale or previous-context 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.

G02 — Global Workspace search

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

Review gaps

• No current search result behavior has been validated.
• Searchable record types and extracted-file search are unknown.
• Keyboard navigation, debounce and recent search behavior are unknown.
• The control was observed on Overview; global availability on every route is unverified.

Required future closure

• Group results by record type.
• Cover Projects, Entities, tasks, items, commercial records, files and authorized messages.
• Maintain durable Workspace scope and safe analytics.

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 — Global create menu

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

Review gaps

• Menu contents have not been captured.
• Contextual actions and route availability are unknown.
• Mobile and keyboard behavior are unknown.

Required future closure

• Support contextual actions such as Project Opportunity, Project, Task, appointment, file, teammate invitation, Offer or Proposal.
• Use the same command and form components as destination 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.

G04 — User account menu

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

Review gaps

• Menu contents and actions are unverified.
• Display currently falls back to the email instead of a completed personal name.
• Sign out, profile, notification preferences and security routes have not been validated.
• Session-expired behavior is unknown.

Required future closure

• Include My Profile, notification preferences, connected accounts, Workspace switch, Security, Help and Sign out.
• Display the user’s preferred name when available while retaining a clear account identifier.
• 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

• Only the Registry Administration dashboard has been verified; Designer, Provider and Client variants remain undocumented.
• Recent activity exposes raw event keys such as Workspace.Assisted Access.Ended and internal record identifiers, which are not human-friendly.
• The dashboard still displays the legacy Workspace name Proper Gallery.
• The greeting falls back to the email address instead of a completed preferred name.
• Messages, Proposals and Reports remain placeholder navigation even though dashboard work may depend on them.
• Card-level errors, stale data, offline operation and partial loading have not been observed.
• Metric and progress calculation formulas have not been traced to repository code.
• Mobile and tablet layouts remain unverified.

Required future closure

• Create tested dashboard compositions for Designer Studios and every Provider category while reusing the same card framework.
• Humanize Activity labels and source references without losing audit traceability.
• Add clear card-level freshness, failure and retry behavior.
• Ensure every attention item resolves to an accountable person, record and next action.
• Use preferred User Profile name and current Design Registry Workspace branding.
• 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

• Save persistence, reload behavior and cross-device behavior were not tested.
• There is no observed Restore defaults action.
• No live dashboard preview appears inside the modal.
• Width is limited to Half or Wide; full-width and more granular layouts are not available.
• 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.
• Mobile-specific card ordering and width behavior are unverified.

Required future closure

• Add Restore defaults and clear unsaved-change behavior.
• Define User-level, Workspace-default and role/category template precedence.
• Handle newly added, retired or permission-removed cards without corrupting preferences.
• Provide responsive meaning for widths while maintaining one saved preference model.
• 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 — User Profile

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

Review gaps

• Phone is currently a general textbox without the standardized international Phone Number component, E.164 contract, extension or channel-consent context.
• Typical working hours and working days appear as text inputs rather than structured reusable schedule controls.
• Notification preferences expose the incomplete current event catalogue and therefore over-represent Applications/provisioning while other product domains are absent.
• Security lacks MFA, active sessions, device/session revocation, recent security events and direct verified email-change workflow.
• Autosave, unsaved-change protection, server validation, save confirmation and concurrent-update behavior were not verified.

Required future closure

• Preserve this separate settings-style profile family in Spec 04.
• Adopt the Spec 16 Phone Number, timezone, locale, date/time and structured availability components.
• Expand Notification preferences automatically as the cross-product Domain Event catalogue grows.
• Add security-session management, MFA and verified email-change controls without storing credentials in the profile.
• Expose safe User Profile identity consistently through Avatars and Identity Chips while Membership context remains Workspace-specific.

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 — Workspace Profile

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

Review gaps

• Legacy Proper Gallery name.
• platform admin is implementation language.
• No saved versions.
• Section completeness and public projection were not verified.

Required future closure

• Adopt Registry Administration terminology.
• Implement draft/publish/version behavior.
• Map approved Application fields through stable field keys.
• Reuse branding in proposals, presentations and notifications.

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 — Designer Studio Profile

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

Review gaps

• Profile subtitle exposes an internal slug instead of the Studio ID.
• Team badge and embedded Teammate counts conflict.
• Assignments still says Leads & Assignments, Manage brokerage, Shared CRM lead and Open lead.
• Activity and History are duplicates.
• Performance has no snapshots.
• Shared platform connection IDs such as crm-account-am are implementation-facing.
• Administrative access safety controls are not visible.

Required future closure

• Adopt the Entity Profile architecture and canonical Studio ID.
• Resolve Membership-backed people counts.
• Replace legacy Assignment and brokerage language.
• Separate Activity from History.
• Harden and rename cross-Workspace access.
• Connect Projects, reporting and shared modules to canonical records rather than readiness placeholders.

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