The Design Registry

Design System, Fields & Reusable Components

Document: 16 - Design System, Fields & Reusable Components
Version: 2.1
Prepared: August 2026
Status: Engineering, product and design source of truth
Primary principle: Build once, reuse everywhere—with one interaction, one data contract and one accessibility standard.

1. Executive Summary

This specification defines the reusable interface and data-entry system for The Design Registry. It is not only a visual style guide. Every approved component combines:

• a visual and interaction pattern;
• a stable component API;
• a canonical data shape;
• formatting and normalization rules;
• client and server validation;
• accessibility requirements;
• permissions and privacy behavior;
• loading, empty, warning, error and read-only states;
• analytics and Activity expectations; and
• an adoption and migration plan.

The current product already reuses visual ideas—rounded fields, cards, grids, tabs, modals, pills and black primary actions—but similar-looking controls often behave differently. Dropdown options are not always ordered consistently. Task Priority values differ between the Task Builder and Tasks directory. Phone numbers have no defined international storage format. Financial inputs imply dollars without consistently storing currency. Date controls do not always distinguish date-only values from timed events. Application summary mappings demonstrate that a label cannot safely identify a field.

This document establishes the Registry Component System: one approved library consumed by Registry Administration, Designer Studio, Provider and Client experiences, public Applications, Client-facing Project Presentations and generated documents.

A component is reusable only when its appearance, behavior, value semantics, accessibility and error states are reusable.

2. Objectives

1. Eliminate one-off fields and local component copies.
2. Ensure equivalent business values behave identically everywhere.
3. Make forms safe for international contact, financial, address and scheduling data.
4. Preserve stable field and option keys while allowing customer-facing labels to change.
5. Make every component keyboard, screen-reader, zoom and touch accessible.
6. Give Codex and future engineers a deterministic catalogue for choosing existing components.
7. Support schema-driven forms, builders, grids, filters, exports and integrations from the same definitions.
8. Allow incremental migration without breaking current records.

3. Non-Goals

• A second design language for each portal.
• A generic component library disconnected from Registry business semantics.
• Storing formatted display strings as canonical data.
• Allowing editable labels to become database identifiers.
• Replacing domain-specific product specifications.

4. Definition of an Approved Reusable Component

A component is approved for platform-wide reuse only when it has:

Visual similarity alone does not qualify a control as shared.

5. Component Architecture

Design tokens
  ↓
Interaction primitives
  ↓
Field and option registries
  ↓
Reusable components
  ↓
Dynamic Form schemas and Record module registry
  ↓
Admin, Designer, Provider, Client and public experiences
  ↓
Grids, exports, documents, notifications and integrations

5.1 Required packages

The implementation should maintain clear internal boundaries:

• tokens: colour, typography, spacing, radius, elevation, motion and responsive values;
• primitives: focus, overlay, popover, listbox, dialog, tooltip and live-region foundations;
• fields: typed inputs and their formatters/validators;
• selectors: option, Entity, record and assignee selection;
• patterns: grids, tabs, timelines, cards, upload queues and feedback;
• schemas: field definitions, option registries and dynamic form versions;
• formatters: shared read-only and export formatting;
• testing: interaction and accessibility fixtures.

Domain modules compose these packages; they do not copy their source.

6. Global Field Contract

Every field definition includes:

field_key
field_type
schema_version
label
help_text
placeholder
required_rule
default_value
privacy_classification
visibility_rule
edit_rule
normalization_rule
validation_rules
display_formatter
export_formatter
option_registry_key
autocomplete_purpose
analytics_policy

6.1 Stable identity

• field_key is immutable after publication.
• Labels, help text, order and layout may change by version.
• Mappings use field_key, never label text or array position.
• Historical records retain the schema version used when their values were captured.

6.2 Null semantics

The system distinguishes:

• not collected;
• intentionally blank;
• unknown;
• not applicable;
• zero;
• false;
• empty collection; and
• redacted from the current viewer.

Interfaces must not collapse these into one blank display.

6.3 Formatting

Formatting occurs at the display boundary. Canonical values do not contain currency symbols, thousands separators, unit labels or localized date strings.

7. Text Input

Use for short names, titles, identifiers and labels.

Required behavior:

• persistent visible label;
• optional help text, prefix, suffix and character counter;
• configurable minimum and maximum length;
• normalization of leading/trailing whitespace unless explicitly preserved;
• Unicode-safe length and normalization;
• browser autocomplete token where purpose is known;
• duplicate-name guidance where uniqueness matters;
• read-only formatter identical to stored meaning.

Do not use a placeholder as the label. Do not silently truncate.

8. Textarea and Rich-Text Editor

8.1 Plain textarea

Use for unformatted descriptions and explanations. It supports resize where layout allows, character guidance, autosave state and unsaved-change protection.

8.2 Rich text

Use only when headings, lists, links, emphasis, mentions, attachments or structured content are materially useful. Store sanitized structured-document JSON, not arbitrary HTML.

Required rich-text behavior:

• accessible toolbar and keyboard commands;
• paste sanitization;
• mention and attachment permissions;
• revision history for durable business content;
• AI suggestions displayed as proposed changes before acceptance;
• safe plain-text and document export.

Internal Notes, Project Vision, Proposal terms and Client-facing content may share the editor with different allowed toolbars.

9. Email Input

An email value may represent a login identity, invitation target, contact method or message recipient. Those purposes remain distinct.

Required behavior:

• type=email and mobile email keyboard;
• trim surrounding whitespace;
• normalize domain case;
• preserve original display form;
• syntax validation without claiming deliverability;
• optional verification state and timestamp;
• safe duplicate-identity resolution;
• primary/secondary and purpose labels;
• non-enumerating authentication errors.

Email must never be the immutable primary key for User or Entity records.

10. Phone Number Input

This is a high-priority shared component.

10.1 Input anatomy

• searchable country selector with flag optional and country name/calling code required;
• national-number input using inputmode=tel;
• optional extension field;
• type label: mobile, office, home, fax or other;
• verification indicator where applicable;
• channel capability and consent shown separately.

10.2 Storage

raw_input
e164_number
country_calling_code
national_number
extension
phone_type
verification_state
verified_at

Use an international phone-number library and current numbering metadata. Store E.164 when valid. Display in the viewer’s or number’s appropriate national format, but dialing and Twilio integrations use E.164.

10.3 Rules

• Default country may come from Workspace or address context but remains editable.
• A valid phone number does not imply mobile capability.
• Presence of a number does not imply SMS or marketing consent.
• Consent is a separate, versioned record by channel and purpose.
• Do not discard raw input on validation failure.
• Extensions are never appended ambiguously to the canonical E.164 value.

11. URL Input

Use for websites, portfolios, product pages and external resources.

• Accept a user-friendly domain and normalize to an absolute HTTPS URL after validation.
• Permit only approved protocols.
• Reject executable or unsafe schemes.
• Preserve a display label separate from the canonical URL.
• Indicate external navigation.
• Store source and optional last-checked status.
• Product import/extraction state belongs to a related import job, not the URL string.

12. Number, Quantity and Unit Input

The field definition declares:

• integer or decimal;
• minimum/maximum;
• step and precision;
• signed/unsigned;
• unit code;
• whether zero is meaningful;
• whether blank, unknown and not applicable are allowed.

Users may type locale separators. The system normalizes to a numeric value and renders thousands separators consistently. Units are stable codes such as sq_ft, in, cm, hours or items; unit labels are never embedded in the numeric column.

13. Money, Rate and Percentage Input

13.1 Money

• always includes ISO currency;
• stores exact minor units or fixed decimal;
• never uses binary floating point for authoritative amounts;
• formats separators, symbol and precision by locale/currency;
• distinguishes blank from zero;
• supports negative values only where the domain permits them.

13.2 Rate

Rate includes amount, currency and basis: hourly, daily, per-item, per-square-foot, fixed or another governed unit.

13.3 Percentage

The schema defines whether user input 15 represents 15%. Canonical storage uses one consistent normalized decimal. Display and calculations use shared utilities.

Tax-exclusive, tax-inclusive, markup, margin, commission and discount are separate business semantics even when they share the percentage control.

14. Date, Time and Range Picker

The component has explicit variants:

1. date-only;
2. time-only with timezone context;
3. local date-time;
4. absolute timestamp;
5. date range;
6. date-time range;
7. month/year;
8. recurrence rule.

Date-only values are stored as dates. Timed events store UTC instant, IANA timezone and original local representation. The control supports typing and calendar selection, clear/today actions where useful, min/max rules, start/end validation, daylight-saving exceptions and business-day calculation.

15. Address Lookup and Structured Address

Autocomplete accelerates entry but never prevents manual international entry.

Canonical address:

address_line_1
address_line_2
locality
administrative_area
postal_code
country_code
formatted_address
provider_place_id
latitude
longitude
geocode_confidence
user_overrides

Client billing, Project site, shipping, receiving facility, Service Area and delivery destination are typed relationships to Address records. Selecting a suggestion fills structured fields that remain editable.

16. Single-Select Dropdown

16.1 When to use

• Native select: short, stable, familiar list.
• Searchable combobox: long, remote, frequently changing or context-rich list.
• Radio group: two to five important choices that should remain visible.

16.2 Ordering

Alphabetize by display label unless a documented semantic order applies:

• lifecycle progression;
• severity/priority;
• chronological order;
• ranked recommendation; or
• administrator-defined display order.

Do not preserve accidental database order.

16.3 Option contract

option_key
label
description
group
display_order
colour_token
active_state
disabled_reason
effective_dates

The stored value is option_key, never label.

17. Multi-Select Dropdown

Use a searchable multi-combobox for scalable lists and a checkbox group only for short visible choices.

Required behavior:

• selected chips or accessible compact summary;
• search and remote loading;
• add/remove announcement;
• deterministic selected-value order;
• maximum selection count;
• duplicate prevention;
• clear-all action;
• select-all with explicit scope: all visible, all filtered or entire dataset;
• retired-value display;
• no comma-joined storage.

Use for services, rooms, specialties, languages, Provider Categories, Task Collaborators and report filters.

18. Checkbox, Radio and Toggle

• Checkbox: independent boolean or multiple choices.
• Radio: exactly one choice from a visible set.
• Toggle: an immediate setting that takes effect when changed.

Required states include unchecked, checked, indeterminate, disabled and read-only. Group labels use fieldset and legend. Required declarations and consent record the exact statement version, actor and timestamp rather than only a boolean.

19. Entity, Record and Assignee Picker

This component selects canonical Users, Memberships, Teams, Clients, Designer Studios, Providers, Projects, Pipeline Records, Items and commercial records.

Required behavior:

• server-side permission-scoped search;
• type-aware results;
• primary label plus distinguishing context;
• recent selections;
• loading, no-result, error and pagination states;
• exact canonical relationship storage;
• duplicate-name safety;
• disabled or ineligible reason;
• no leakage through result counts.

Assignee selection resolves User through active Workspace Membership and never copies a display name into the Task.

20. Dynamic Form System

Dynamic Forms compose the approved field components. They add:

• versioned sections and layout;
• field visibility and edit rules;
• conditional logic;
• cross-field validation;
• repeatable groups;
• save-and-return;
• draft and publication states;
• applicant and reviewer preview;
• mapping validation;
• schema comparison and migration.

Form publication is blocked when fields have duplicate keys, missing registry definitions, invalid mappings, inaccessible required fields or contradictory conditions.

21. Enterprise Data Grid

One permission-scoped query powers metrics, rows, filters, selection, bulk actions and exports.

Required capabilities:

• server-side search, filter, sort and pagination;
• keyboard and screen-reader table/grid semantics;
• configurable and persistent columns;
• density and responsive behavior;
• row and cell actions;
• select page/select all filtered semantics;
• per-record bulk validation and partial-failure report;
• saved views and URL query state;
• export jobs with identical permissions;
• loading, empty, filtered-empty, error, stale and redacted states.

22. Search, Filter and Sort

Search, filters and sort use canonical field keys and typed operators. Active filters appear as removable chips and support Clear all. Shareable query state belongs in the URL; reusable personal/team queries become Saved Views.

Ambiguous controls such as Closed without a clear include/exclude meaning are prohibited. Every filter states its scope and result count impact.

23. Pagination and Progressive Loading

• Cursor pagination for changing operational feeds.
• Page pagination for stable reports and tables where direct navigation matters.
• Load more only when progressive browsing is preferable and position preservation is reliable.
• Infinite scrolling is avoided for high-accountability work unless there is a parallel accessible navigation mechanism.

The system preserves query, cursor/page, selection and scroll position when opening and returning from records.

24. Record Tabs and Module Registry

The shared module registry governs Overview, Activity, Notes, Files, Tasks, Communication, Matchmaking, Proposals, History and future modules.

Availability considers:

• record type;
• Workspace type;
• participant relationship;
• permission scope;
• feature readiness;
• record lifecycle; and
• market configuration.

Unavailable modules are omitted or labelled Coming soon. They never appear as unexplained dead clicks. Deep links preserve the active tab.

25. Activity Timeline and Audit History

Activity is participant-readable operational history. History is immutable audit. They are not aliases.

Every event includes stable type, actor, occurred time, recorded time, visibility, canonical links and safe display snapshot. Overview uses an authorized recent-Activity projection rather than a separate data store.

26. Modal, Drawer and Full-Page Editor

26.1 Modal

Use for focused, bounded work that can be completed without extensive navigation.

26.2 Drawer

Use for contextual review or light editing while preserving the underlying list or record.

26.3 Full-page editor

Use for long, multi-section, versioned or high-risk workflows such as Application Builder, Project Builder, Proposals and complex profiles.

Every editor declares Create, Edit, View or Confirm mode and target identity. Edit never opens blank Create state. Focus is trapped/restored appropriately, dirty-state protection is required and optimistic-concurrency conflicts receive a resolution experience.

27. Buttons and Action Menus

• one primary action per local decision area;
• secondary and tertiary hierarchy;
• navigation is a link, mutation is a button;
• loading state prevents duplicate commands;
• destructive actions identify target and consequence;
• icon-only controls have accessible names and tooltips where helpful;
• disabled actions communicate why;
• unavailable future actions say Coming soon rather than appearing broken;
• commands include target version and idempotency key.

28. Validation and Feedback

28.1 Field validation

Validate at an appropriate time, preserve the entered value and show actionable inline text.

28.2 Form summary

Long forms provide an error summary linked to each invalid field. Focus moves to the summary or first invalid control after submission.

28.3 Conflict

Stale-version or simultaneous-edit responses identify changed fields and allow safe reload, compare or retry. They are not shown as generic save failures.

Validation results use stable codes and field keys so logic does not depend on English text.

29. Loading, Empty, Error and Permission States

Every reusable surface supports:

• loading without false zero metrics;
• true zero records;
• no search/filter results;
• unavailable feature;
• permission-hidden or permission-redacted data;
• recoverable error with retry;
• non-recoverable error with escalation path;
• stale or partial data with freshness; and
• offline/reconnecting where relevant.

Empty network categories remain visible with zero counts when their absence is operationally meaningful.

30. Toast, Banner and Inline Alert

• Toast: transient confirmation of a completed low-risk action.
• Banner: persistent page, Workspace, security, access-session or integration condition.
• Inline alert: contextual warning or error next to affected content.

Required decisions never live only in a toast. Messages define severity, scope, dismissibility, expiry and action. Confirmations use polite live-region status; urgent failures use alert semantics carefully.

31. Status Pills and Semantic Colours

Every state has a stable semantic key separate from label and colour. The same registry powers builders, forms, pills, grids, filters, exports and reports.

Colour is never the only signal. Text and optional icon/pattern communicate state. Custom colours pass contrast validation. Retired values remain renderable historically.

32. File and Image Uploader

Required capabilities:

• file picker and drag/drop;
• accepted type, size and count guidance;
• upload queue with progress;
• cancel and retry;
• checksum and duplicate detection;
• security-processing state;
• image orientation and metadata handling;
• title, document type and visibility where required;
• immutable File identity and versions;
• typed links to canonical records;
• permission-safe previews and downloads.

Files are binaries. Documents add business meaning. Attachments are typed relationships.

33. Cards, Summary Sections and Metric Tiles

Approved variants:

• metric tile;
• information summary;
• action card;
• collection preview;
• status/attention card.

Cards consume projections; they never maintain separate editable business state. Metric tiles include definition or accessible explanation, scope, source and freshness where decisions depend on them. Responsive layouts must not overflow their parent container.

34. Avatar, Identity Chip and Participant Label

Identity always resolves from a canonical User/Membership, Workspace, Entity or system actor.

• approved image or deterministic initials fallback;
• display name plus distinguishing context when needed;
• Role Label separate from Access Role;
• immutable event snapshot plus canonical actor ID;
• privacy-aware image usage;
• no colour-only identity cue.

The current Task Owner conflict—Demo Administrator in a grid and Brad Mitchell in an editor—must be eliminated through one Membership-backed resolver.

35. Accessibility Standard

Every approved component passes:

• keyboard-only operation;
• visible focus and logical focus order;
• screen-reader names, roles, states and relationships;
• 200% and 400% zoom/reflow where applicable;
• minimum touch target and spacing;
• colour contrast and non-colour cues;
• reduced-motion preference;
• error identification and recovery;
• mobile and desktop interaction; and
• automated checks plus manual assistive-technology testing.

Accessibility acceptance belongs in the component library, not repeated inconsistently by each consuming feature.

36. Permissions and Privacy

Components accept an explicit authorization result:

• hidden;
• visible and editable;
• visible and read-only;
• visible with redacted value;
• unavailable with safe reason.

The UI never determines authorization by itself. Server commands and Row Level Security enforce the same scope. Search results, option counts, validation, exports and Activity must not leak hidden values.

37. Internationalization and Localization

The first release may be English-first, but component contracts must support:

• translated labels and validation messages;
• text expansion;
• locale-aware number, money, phone and date formatting;
• ISO currencies and countries;
• IANA timezones;
• right-to-left readiness in primitives; and
• stable keys independent of language.

38. Testing Strategy

Each component includes:

1. unit tests for normalization and formatting;
2. interaction tests for pointer and keyboard;
3. serialization round-trip tests;
4. accessibility tests;
5. visual state fixtures;
6. responsive tests;
7. permission-state tests;
8. integration tests through Dynamic Forms and grids; and
9. regression fixtures from known live inconsistencies.

Required regression cases include phone parsing, currency precision, date/timezone conversion, Application stable mappings, Urgent Priority visibility, Task Owner identity and modal Edit mode.

39. Governance

39.1 Ownership

Product owns business semantics. Design owns interaction and tokens. Engineering owns implementation API and quality. Accessibility and security acceptance are shared release requirements.

39.2 Adding a component

Before adding a new component, the contributor must:

1. search the component catalogue;
2. explain why an existing component/variant cannot satisfy the need;
3. define value and state contracts;
4. identify at least one real consumer;
5. add tests and documentation; and
6. receive review from component-system owners.

39.3 Deprecation

Deprecated components remain documented with replacement, affected consumers, migration date and compatibility boundary. Silent parallel copies are prohibited.

40. Migration Plan

Phase 1 — Inventory and keys

• Freeze the catalogue in this document and current-product library.
• Inventory local component copies.
• Assign stable field, option and status keys.
• Correct critical data conflicts before visual replacement.

Phase 2 — Foundational field controls

• Text, textarea, email, phone, URL, number, money/percentage, date/time and address.
• Single-select, multi-select, checkbox/radio/toggle and Entity picker.
• Shared formatters and validators.

Phase 3 — Form and feedback system

• Dynamic Forms integration.
• Validation summaries, loading/error states, toasts/banners and editor modes.
• Application mapping tests.

Phase 4 — Data and record patterns

• Enterprise grid, search/filter/sort, pagination, tabs, Activity and upload queue.
• Saved Views and permission-safe exports.

Phase 5 — Adoption

• Migrate Teammates, Tasks, Applications, Workspace Profile, Pipelines, Projects and Entity Profiles.
• Remove local copies after parity and regression tests.

41. Acceptance Criteria

The component system is ready when:

1. Every component in the current-product Shared Components section has a profile and owner.
2. Phone numbers parse internationally and store E.164 plus raw input and extension.
3. Single- and multi-select controls use stable option keys and deterministic ordering.
4. Money and percentages store exact canonical values and display consistently.
5. Date-only and timed values have distinct storage and timezone behavior.
6. Addresses preserve structured, editable international data.
7. Dynamic Forms map fields by stable key and block invalid publication.
8. Task Type, State and Priority values are identical across builders, forms, grids, filters and reports.
9. Entity pickers use permission-scoped canonical relationships.
10. Grids, exports and counts share the same authorized dataset.
11. Modal Edit mode loads the selected record identity and version.
12. Every component passes the accessibility standard.
13. Registry, Designer, Provider, Client and public experiences consume the same approved library.
14. Local copies have documented migrations and are removed after adoption.

42. Definition of Done

The Design Registry can say build once, reuse everywhere only when a developer or Codex can open the component catalogue, identify the correct existing component, understand its exact data and behavior contract, reuse it without guessing, and trust that the same value will behave consistently in every portal, grid, document, notification and integration.

43. Canonical Component Specification Template

Every component must be documented using the same specification record. A screenshot or Storybook story is supporting evidence; neither replaces the contract.

43.1 Maturity states

No feature specification may treat concept designed as implementation-ready.

43.2 Required component manifest

Each approved component exposes a machine-readable manifest so Codex, linting and documentation can identify it without guessing.

type ComponentManifest = {
  key: string;
  version: string;
  maturity: "beta" | "approved" | "deprecated";
  package: string;
  owner: string;
  variants: string[];
  valueSchema?: string;
  permissions?: string[];
  events: string[];
  accessibilityStandard: string;
  consumers: string[];
  replacementKey?: string;
};

The catalogue page is generated from manifests and design documentation. It displays ownership, maturity, available states, usage examples, consumers, known gaps and links to tests.

44. Product Tokens and Foundations

Tokens are semantic decisions, not convenient colour aliases. Product code consumes roles such as surface.canvas, text.muted, status.attention and focus.ring; it does not introduce arbitrary hexadecimal values or local spacing constants.

44.1 Token groups

44.2 Density

The same component may use an approved density without forking its semantics:

• Comfortable: default for profiles, forms, Client surfaces and ordinary Project work; rows are normally 48–56 pixels.
• Compact: high-volume operational grids, receiving queues and administrative directories; rows are normally 36–44 pixels.
• Presentation: Client presentations, printable documents and executive summaries; hierarchy expands while controls recede.

Density never reduces a touch target below the accessibility minimum, removes required labels or hides state.

44.3 Workspace branding boundary

Workspace branding may configure logo, Workspace name, approved accent token, document cover, typography from an approved set and Client-facing footer details. It may not alter status meanings, error colours, focus treatment, control anatomy, validation, accessibility, permissions or Provider workflow semantics.

45. Application Shell and Navigation Components

The shell is a governed component family shared by Registry Administration, Designer, Provider and Client Workspaces.

45.1 Application shell

Required regions:

1. Workspace identity and switcher;
2. permission-projected primary navigation;
3. global search or command menu;
4. current account and notification access;
5. contextual Page Header and actions;
6. main content landmark; and
7. responsive navigation projection.

The shell must not render inaccessible navigation and then merely disable it. The server supplies the authorized navigation projection. A missing feature that is intentionally announced uses a non-interactive Coming soon state; it never routes to an empty or broken screen.

45.2 Navigation registry

navigation_key
canonical_label
icon_key
route_pattern
required_capability
audience_projection
badge_source
coming_soon_state
mobile_priority

Canonical top-level jobs are Home, Pipelines, Projects, Network, Tasks, Calendar, Inbox and Financials. Feature specifications may add contextual modules but may not create new global entries without navigation governance review.

45.3 Page and Record Headers

A Page Header contains breadcrumb/back context, title, supporting metadata, state and prioritized actions. A Record Header adds immutable record identity and version-safe actions.

• One primary action is permitted per action region.
• Overflow actions remain named for assistive technology.
• Record state is not embedded only in title colour.
• Metadata wraps rather than truncating critical identity.
• Actions project by permission and current lifecycle state.
• Mobile moves secondary actions into a bottom sheet or named menu.

45.4 Tabs and contextual navigation

Tabs change a view within the current record. They are not filters, status indicators or decorative category labels. A module registry defines tab key, route, audience, capability, availability, badge source and empty state. Deep links remain durable. On narrow screens, tabs scroll with visible affordance or become an accessible selector without changing the route contract.

46. Collaboration Components

Tasks, Notes, Activity and communication appear throughout the platform. They share identity, linking, visibility and Activity infrastructure while preserving their distinct purpose.

46.1 Internal Note and composer

An Internal Note is durable Project or record knowledge for authorized internal participants. It is not an email draft, audit event or ephemeral chat message.

Required anatomy includes author and Workspace context; created and edited timestamps; rich or plain body; mentions and canonical record links; attachments with visibility inheritance; pinned state; audience label; revision indicator; and permitted actions.

Notes cannot be silently deleted. Archival or redaction preserves audit evidence. Mentions resolve Workspace Memberships, trigger editable Notification Templates and never broaden the Note’s visibility. AI may improve or summarize text but must preserve facts, links, mentions and audience.

The composer supports @ mentions, # record linking, attachments, emoji where permitted, AI improvement, save state and unsaved-change protection. It shows the audience before submission. The submit payload includes body document, linked records, mentions, attachment IDs, pin intent, visibility policy and source record version.

46.2 Task row, card and detail

The Task family shares one canonical Task record. A row is a compact collection projection; a card is a board/calendar projection; a drawer or full page provides complete detail.

Required Task fields include title, description, Type, State, Priority, Owner Membership, Collaborators, due/start dates, timezone when timed, Project, Phase, linked records, checklist, dependencies, estimated effort, tracked time, source template and version.

Task components support complete/reopen, one Owner plus permitted Collaborators, checklist progress, predecessor and successor explanation, blocked reason, milestone distinction, timer/manual Time Entry, template provenance, comments or Notes, and Activity history without duplicating the audit ledger.

46.3 Activity and History

Activity is a human-readable projection of meaningful events. History is the governed audit record. One event service supplies both projections.

47. Builder Framework

Pipeline, Form, Automation, Notification, Project Template, Permission, Proposal Template, Saved View and Project Presentation Builders share one Builder Framework.

47.1 Builder anatomy

1. Builder Header: object identity, draft status, preview, version and publish actions.
2. Library Rail: available stages, fields, rules, blocks or modules.
3. Canvas: ordered composition and selection.
4. Properties Panel: configuration for the selected object.
5. Validation Panel: errors, warnings and affected consumers.
6. Test/Preview Mode: realistic audience and data fixtures.
7. Version Controls: autosave, compare, restore, publish and rollback.

The framework provides drag-and-drop as an enhancement. Every reorder and insertion also works by keyboard and explicit Move actions.

47.2 Draft and publication contract

builder_key
definition_type
draft_version
published_version
base_version
change_set
validation_result
affected_consumers
created_by
updated_by
published_by
published_at

Publication is a controlled mutation. The server validates stable keys, references, permissions, unreachable states, contradictory rules, required-but-hidden fields, Notification Templates, migrations and active-record impact. A publish request returns warnings separately from blockers and records an Activity/Audit event.

47.3 Builder-specific adapters

47.4 Builder acceptance requirements

• Autosave shows saving, saved, offline and conflict states.
• Preview uses the same renderer as production.
• Published records retain the definition version that governed them.
• Existing active records are never silently reinterpreted.
• Rollback creates a new version; it does not erase history.
• Destructive changes explain affected records and migration choices.
• Test mode can simulate Registry, Designer, Provider and Client audiences.

48. Profiles, Identity and Record Modules

48.1 Shared profile framework

Client, Designer Studio, Provider, User and Workspace Profiles share Profile Header, identity and relationship state, permission-aware Record Tabs, configurable Overview Card registry, Activity, Files, Tasks and Communication services, canonical related-record collections and audience-specific access projections.

The framework is shared, but the Overview prioritizes the record’s job:

• Clients centre Projects, decisions and preferences.
• Designer Studios centre practice, team, capacity and matching.
• Providers centre qualification, service area, capacity and Provider Category operations.
• User Profiles centre identity, Memberships, assigned Projects, Tasks, capacity and recent work.
• Workspace Profiles centre business identity, team, active Projects, network relationships and operating health.

User and Workspace Profiles use the same Profile Header, Record Tabs, Overview Card registry, Activity, Projects, Files, Tasks, Communication and History composition as Client, Designer Studio and Provider Profiles. Settings may provide additional configuration entry points, but it does not create a separate profile design.

48.2 Profile module contract

module_key
record_type
supported_audiences
required_capabilities
data_query_key
empty_state_key
layout_span
display_priority
provider_category_adapter
mobile_priority
print_behavior

Modules are composed from the registry. Feature teams do not hard-code audience-specific profile forks.

48.3 Identity components

Avatar, Logo, Identity Chip and Participant Label always resolve canonical identity. Initials are a fallback derived from governed display-name rules; they are not stored as identity. Components distinguish User, Workspace Membership, Client, Designer Studio, Provider, Team and system actor. Role Label is descriptive metadata and never substitutes for Access Role.

49. Operational Project Components

The Project is the operational centre. Domain components reuse the field, collection, feedback, permission and Activity foundations defined earlier.

49.1 Provider Category adapters

Provider components extend shared operational records rather than creating separate products:

• Vendor and Manufacturer: catalogue, quote, acknowledgement, production and shipment.
• Contractor and Trade: scope, site schedule, daily progress, change and deficiency.
• Millwork: measurement, shop drawing, approval, fabrication, finishing and installation.
• Receiving, Warehouse and Storage: appointments, receiving, condition, locations, releases and inventory.
• White-Glove Delivery and Installation: manifest, crew, route, live status, proof and deficiency.
• Photographer and Creative: brief, shot list, schedule, usage rights, selects and deliverables.
• Floor Plan and Documentation: site measure, inputs, drafting, review, revision and issued files.
• Procurement Service: sourcing, quote comparison, order administration, exception and reconciliation.
• Other Professional Service: governed configurable milestones without bypassing shared Work Orders, Tasks, Files and communication.

50. Network and Commercial Components

50.1 Match Candidate and score explanation

A Match Candidate Card displays Entity identity, eligible Provider Category or Designer specialty, total score, material score dimensions, hard-rule exceptions, availability, service area and permitted actions. Score Explanation distinguishes verified facts, self-reported attributes, inferred values and missing data. It never presents a percentage without an explanation and advisory disclaimer.

50.2 Offer and response

Offer Card and Offer Response Panel share one Offer record. They display Project-safe scope, response deadline, commercial disclosure allowed at that stage, included attachments and response options. Accept, decline, request clarification and counter/reflect actions are governed states with confirmation, timestamps and Notification events.

50.3 Proposal, Work Order and Invoice

Commercial components share Money, line-item, tax, party, Project, status, version, acceptance, File and Activity primitives.

• Proposal communicates scope and price before commitment.
• Accepted Proposal creates or informs a Work Order through an explicit conversion event.
• Work Order is the operational commercial authorization.
• Change Order versions a change to authorized scope or value.
• Invoice requests payment against the correct commercial source.
• Payment records settlement and reconciliation; it is not inferred from an Invoice status label.

Financial visibility components support full, summarized, redacted and hidden states without leaking totals through badges, counts, exports or Activity text.

51. Component API and Composition Rules

51.1 Prefer controlled business components

Feature code provides canonical value, schema/configuration, permission projection and event handlers. The component owns display, interaction, normalization, validation presentation and accessible behavior.

<MoneyField
  fieldKey="project.estimated_budget"
  value={{ amountMinor: 25000000, currency: "CAD" }}
  locale="en-CA"
  permission="edit"
  onChange={setBudget}
  onCommit={saveBudget}
/>

Feature code must not recreate the currency prefix, parsing, error message or read-only formatter.

51.2 Domain adapters

A domain adapter maps business schema to a shared component without changing its foundational behavior.

type ProviderPickerAdapter = {
  providerCategory?: ProviderCategoryKey;
  projectId?: ProjectId;
  eligibilityRule?: EligibilityRuleKey;
  resultProjection: "identity" | "operational" | "match-candidate";
};

Adapters may add context, columns or eligibility explanation. They may not bypass permission-scoped search, canonical identity or picker accessibility.

51.3 Prohibited composition

• Interactive controls nested inside another interactive control.
• A card that is both a link and contains unrelated buttons without a defined keyboard model.
• Locally formatted money, phone, date or address values.
• UI-only permission checks.
• Reusing Status Pill for categories, tags or decorative emphasis.
• Modal forms that become multi-page operating surfaces.
• New dropdown implementations for domain-specific option lists.
• Copying a component to change padding, colour or one event.

52. Events, Analytics and Observability

Components emit semantic events; analytics must not scrape labels or document structure.

component_key
component_version
event_key
surface_key
workspace_id
actor_membership_id
record_type
record_id (when policy permits)
outcome
duration_ms
error_code
metadata_allowlist
occurred_at

Examples include field.validation_failed, picker.search_completed, grid.export_requested, task.completed, builder.publish_blocked, upload.processing_failed and offer.response_submitted.

Rules:

• Never capture unrestricted field values, message bodies, Notes, credentials or payment data in analytics.
• Error codes are stable and human-facing messages remain localizable.
• Performance measurements distinguish network, server and render time.
• Retries and duplicate submissions share an idempotency key.
• Component versions allow regression analysis during migration.

53. Responsive, Touch, Print and PDF Contract

Responsive behavior is specified per component, not added after desktop implementation.

53.1 Collection projection

Enterprise grids may become prioritized rows or cards on mobile. The projection preserves record identity, primary state, the most important operational exception and the primary action. Columns hidden visually remain available through detail; inaccessible data is never shipped merely because it is hidden.

53.2 Overlays

Desktop menus and popovers may become anchored surfaces. Drawers and complex modals become full-height sheets on mobile. Focus containment, back-button behavior, safe-area padding and keyboard avoidance are mandatory.

53.3 Touch and field entry

• Minimum 44 by 44 pixel operational touch target.
• Appropriate mobile keyboard through inputmode and autocomplete.
• No hover-only action.
• Drag interactions include explicit move controls.
• Receiving, delivery and installation evidence supports camera capture.
• Long-running uploads survive temporary view changes where technically safe.

53.4 Print and PDF

Printed or generated output hides application navigation, expands important truncation, repeats table headers, preserves semantic status labels, displays URLs appropriately and uses a stable snapshot timestamp and document version. Interactive controls become labels, values, signatures or omitted non-content actions.

54. Engineering Adoption and Enforcement

54.1 Required repository controls

• One documented import path for each approved package.
• Lint rule preventing forbidden local primitives and raw semantic colours.
• Typed field, option, status and event registries.
• Visual fixture page for every state.
• Automated accessibility and interaction checks.
• Bundle monitoring so the system does not require every component in every route.
• Changelog and migration notes for breaking changes.
• Consumer inventory generated from imports and manifests.

54.2 Pull request evidence

A feature using or changing the system provides:

1. catalogue link and component version;
2. screenshots or fixtures for affected states;
3. keyboard and screen-reader behavior where interaction changes;
4. permission fixtures for affected audiences;
5. canonical value and serialization tests;
6. responsive evidence;
7. migration impact; and
8. explanation for any requested new primitive.

54.3 Migration priority

54.4 Full-product conformance programme

This specification is a system-wide migration contract, not a component-library pilot. Implementation is complete only when every supported Admin, Designer Studio, Provider, Client and Registry-operator surface uses the approved shared system or an explicitly recorded, time-bounded migration adapter.

The migration inventory must include, at minimum:

1. authentication and recovery;
2. the application shell, navigation, global actions and search;
3. dashboards and attention queues;
4. Pipeline directories, boards, grids, records and transitions;
5. Client, Designer Studio, Provider, User and Workspace Profiles;
6. Project Profiles and the seven-Phase Project operating experience;
7. Tasks, Notes, Activity, History, Files, Calendar, scheduling and time tracking;
8. Teammates, Teams, Role Labels, notifications and Settings;
9. Pipeline, Form, Automation, Notification, Project Template and Permission Builders;
10. Applications, approval, matchmaking, Offers and assignments;
11. items, Categories, Budgets, imports, Purchase Orders and Provider operations;
12. Proposals, Work Orders, Invoices, payments and commercial approvals;
13. communications, inbox, email, SMS and calling surfaces;
14. reports, exports, print and PDF output; and
15. every Provider Category portal and its category-specific operational modules.

Migration may be released in dependency order, but it may not redefine “done” as the first release. Each phase must leave working production behavior, preserve canonical data and permissions, and feed the remaining consumer inventory until the full-product conformance register reaches zero unresolved legacy consumers.

Required conformance register

For every route and reusable consumer, record:

• audience and Workspace type;
• current component or local implementation;
• approved replacement and domain adapter;
• field, option, status and glossary dependencies;
• loading, empty, populated, error, conflict, offline and restricted states;
• responsive, keyboard, screen-reader, print and PDF evidence as applicable;
• data migration or serialization impact;
• owner, release phase and status;
• automated regression coverage; and
• removal date for any temporary adapter.

No local field, modal, table, tab system, profile shell, status vocabulary or record-module variant may remain merely because it predates this specification. Exceptions require an architectural decision with an owner, rationale, expiry date and explicit product approval.

Profile conformance requirement

Client, Designer Studio, Provider, User and Workspace Profiles must all migrate to the Shared Profile Framework in Section 48. They share Profile Header, Record Tabs, Overview Card Registry, Activity, Projects, Files, Tasks, Communication and History. Profile type, audience, permissions, relationships, Overview Cards and Provider Category modules configure the experience; they do not justify separate page architectures.

Completion gate

The programme is complete only when:

• the conformance register contains no unapproved legacy consumers;
• temporary adapters have been removed or have an approved active exception;
• legacy Proper Gallery, Lead and Partner labels no longer appear outside documented migration history;
• canonical glossary labels are used in UI, notifications, exports, APIs and tests;
• all supported audiences pass permission and field-visibility fixtures;
• all shared components pass their acceptance matrices; and
• production monitoring shows no material regression in task completion, validation, accessibility, performance or data integrity.

55. Expanded Acceptance Matrix

55.1 Every approved component

• Has a manifest, owner, version and maturity state.
• Uses approved tokens and primitives only.
• Documents anatomy, variants, values, states, permissions and responsive behavior.
• Supports keyboard, screen reader, 200% zoom and touch where applicable.
• Has loading, empty, invalid, error, restricted and read-only behavior where meaningful.
• Emits approved semantic events without sensitive content.
• Includes a realistic Registry, Designer, Provider or Client fixture.
• Has no locally duplicated consumer implementation.

55.2 Shared fields and forms

• Canonical values round-trip without losing precision, timezone, structure or raw input needed for correction.
• Form publication blocks invalid mappings and inaccessible required fields.
• Labels can change without changing keys or historical meaning.
• AI-extracted values display source, confidence and confirmation state.
• Concurrency preserves unsaved work and offers safe resolution.

55.3 Collections and profiles

• Metrics, rows, bulk actions and exports use one permission-scoped dataset.
• Mobile projection preserves identity, state, exception and action.
• Profile modules are registry-composed and audience-projected.
• User and Workspace Profiles use the same Shared Profile Framework as Client, Designer Studio and Provider Profiles while varying their identity, permissions, Overview Cards and available modules by profile type.

55.4 Collaboration and Builders

• Mentions never widen visibility.
• Tasks use one identity across list, board, Calendar, Project and reporting.
• Builder preview uses production renderers.
• Publish validates references and active-record impact.
• Versions and rollback preserve history.

55.5 Project, Provider and commercial operations

• Items, Budgets, Purchase Orders, shipments, receiving, storage, delivery and installation share canonical records.
• Provider portals use shared components with Category adapters rather than separate implementations.
• Offers, Proposals, Work Orders, Invoices and Payments retain distinct lifecycle semantics.
• Financial permissions prevent leakage through summaries, Activity, Notifications and exports.

55.6 Release gate

The component-system release is accepted only when Product, Design, Engineering, Accessibility and the primary operating owner confirm that the catalogue is sufficient for a new feature team—or Codex—to build without inventing local fields, selectors, status language, form behavior, profile structure or feedback patterns.

56. Visual-to-Engineering Coverage Matrix

The Product Style Guide is the visual companion to this specification. A concept shown there becomes build-ready only when the corresponding contract below is complete.

Concept status in the visual guide means the intended hierarchy and composition are represented. Engineering status remains governed by manifests, tests and migration evidence.

57. Unified Inbox and Communication Components

The Unified Inbox composition uses one communication frame across email, SMS, calling and in-app messaging. Channel adapters retain different consent, addressing, delivery and transcript rules.

57.1 Conversation list

Required list-row data includes Conversation identity, participant projection, subject or summary, latest permitted preview, latest Activity time, channel mix, assignment, unread count, Priority, Project and Entity links, Tags and state. Rows support unread, selected, assigned, unassigned, waiting, snoozed, closed and restricted states. Search and counts are server-scoped.

57.2 Thread and composer

Thread entries distinguish inbound/outbound message, Internal Note, call, voicemail, transcript, delivery event and linked Activity. Each entry shows actor, channel, exact timestamp, delivery state, attachments, reply context and permitted actions.

The composer configuration includes channel, sender identity, recipients, Project context, approved template, signature, attachments, consent status and AI state. Channel switching validates capability and consent. AI-generated drafts remain unsent suggestions. Internal Note mode changes audience and Notification behavior; it never sends externally.

57.3 Context and AI summary panel

The detail panel composes canonical Project and Entity links, assignment, Tags, response age, recent contact and open Tasks. AI summaries are time-stamped, cite the messages summarized, distinguish facts from suggestions and refresh only through an explicit or governed event.

57.4 Acceptance requirements

• Sending, sent, delivered, failed, bounced, undeliverable and replied are distinct.
• Calls expose recording consent, recording state, transcript processing and transcript availability.
• Purchased phone numbers identify owning Workspace and permitted Users.
• Closing a Conversation does not alter the underlying Project or Tasks.
• Mentions and assignments use templates managed in the Notification Builder.
• Restricted participants and content never appear in previews, counts or AI context.

58. Files, Uploads, Media and Evidence

58.1 Upload queue contract

Every upload becomes an Upload Job before it becomes an approved File Version. It records Workspace, source surface and record, original name, declared and detected media type, size, checksum, visibility, processing state, progress, retries, error, actor and timestamps.

Processing states include queued, uploading, uploaded, scanning, extracting, thumbnailing, mapping required, ready, failed and quarantined. Progress is never represented as ready. A failed upload preserves retryable metadata but does not create an apparently usable File.

58.2 Dropzone and mobile capture

Dropzone supports browse, drag-and-drop and paste where safe. Mobile supports camera, photo library and file selection. The interface states accepted types, size limits, destination and visibility before upload. Camera capture records evidence purpose and does not silently publish to Clients.

58.3 File Row and File Card

Both project one File and current File Version. They show name, type, preview, version, source, size, uploader, date, processing and visibility state, plus authorized actions. Rename changes display metadata, not storage identity. Replace creates a new version. Delete follows retention and audit policy.

58.4 Evidence and AI extraction

Receiving, delivery, installation, credentials and approvals use Evidence Capture with evidence type, subject, timestamp, actor, location when permitted, description and visibility. AI extraction creates proposed structured values with source region and confidence; a person confirms consequential values.

58.5 Spreadsheet and Google Sheets state

Spreadsheet uploads may enter Mapping required. The File links to Import Mapping Builder and preserves the original source. Mapping, validation, preview, import, partial failure and rollback are Import Job states rather than generic File statuses.

59. Calendar, Scheduling, Resources and Time

59.1 Shared Calendar Views

Calendar supports day, week, month, agenda and resource projections from one permission-scoped query. Events include Task date, meeting, site visit, delivery window, receiving appointment, Project milestone, Resource Booking and personal busy block.

Each event exposes Event Type, title, start/end, all-day state, IANA timezone, Project, linked records, participants/resources, location, recurrence, owner, visibility, external-sync state and operational status.

59.2 Resource Booking

Resources may be Users, Teams, crews, vehicles, rooms, equipment, storage bays or Provider capacity blocks. Booking validates availability, working hours, service area, travel buffer and conflicts. A warning may be overridden only with capability and reason; hard constraints block saving.

59.3 Delivery and receiving windows

Operational windows may express earliest/latest arrival, confirmed slot, duration, facility constraints, carrier, Manifest and live state. A delay updates the operational record and Calendar projection through one event, not independent edits.

59.4 Time Entry and timer

Timer and manual Time Entry share User Membership, Project, Task, start/end or duration, timezone, billable classification, rate visibility, notes, approval and source. Only one running timer per User is permitted unless policy allows otherwise. Corrections preserve the original entry and audit change.

59.5 Responsive behavior

Desktop may use a time grid. Mobile defaults to agenda or prioritized day view, with accessible alternatives for drag operations. Colour never identifies Event Type alone. Overlapping events remain discoverable by keyboard and assistive technology.

60. Project Items, Categories, Budgets and Imports

60.1 Budget Summary and Category row

Budget Summary displays approved, revised, specified, committed, ordered, invoiced, paid and forecast values using identical server-authorized calculations. Each value shows currency and freshness. Category rows roll up their Items and expose variance without inventing a second calculation.

• Approved is the currently authorized plan.
• Specified is the current selected Item estimate.
• Committed is covered by an accepted commercial commitment.
• Ordered has an issued Purchase Order.
• Invoiced has a valid supplier or Provider Invoice.
• Paid has reconciled settlement.
• Forecast includes expected remaining cost.

60.2 Item Grid

Item Grid extends Enterprise Data Grid with thumbnail and identity, Item Type, Space, Category, specification state, approval, Vendor/Provider, quantity, unit, Unit Price, total, tax treatment, Purchase Order, expected arrival, receiving, Storage Location and installation state.

Columns use the same formatters as Item Detail. Inline edit is permitted only for explicitly safe fields and preserves validation, version and permissions. Bulk action reports per-Item success and failure.

60.3 Construction and Decorating Items

Construction materials and Decorating/FF&E Items share identity, cost, Category, Files, approvals and history but use typed adapters. Construction adds coverage, unit, finish, lot/dye batch, installer and site requirement. Decorating adds dimensions, colourway, lead time, Vendor SKU, quantity, room placement and procurement state.

60.4 Import experience

Import begins with CSV/XLSX upload or connected Google Sheet selection. Import Mapping Builder provides sheet selection, header detection, field mapping, transformations, option resolution, duplicate strategy, validation preview and saved Mapping Template.

Import is blocked for unknown required fields, invalid canonical values, duplicate stable identifiers or inaccessible target records. Partial import produces an exception report and reversible Import Job where downstream dependencies permit.

60.5 Create Purchase Order action

Create Purchase Order is a permission-aware bulk action for eligible Items with compatible Vendor, currency and Project context. The preview groups lines, identifies missing commercial data and never silently excludes a selected Item.

61. Receiving, Storage, Delivery and Installation

61.1 Receiving Card

Receiving Card reconciles expected Item/Shipment quantity with actual receipt. It requires receiver, timestamp, facility, Purchase Order/Shipment, Item identity, quantity, packaging condition, Item condition, evidence where policy requires, Storage Location and discrepancy state.

Condition states include good, packaging damaged, Item damaged, shortage, overage, wrong Item, concealed damage suspected and inspection pending. Severity and resolution are separate. A discrepancy may create a Condition Flag, Task, Notification and claim through governed Automation.

61.2 Storage Location and movement

Location Picker searches authorized facilities and valid zones, bays, racks and bins. Every movement records from/to, Item quantity, actor, time and reason. Current location is a projection of movement history, not a manually edited label.

61.3 Delivery Manifest and Live Status

Manifest contains Project, origin, destination, window, crew/vehicle, ordered Items and quantities, load sequence, access notes, Client-safe instructions, signatures and exceptions. Status is planned, approved, loading, loaded, dispatched, in transit, arrived, installing, completed or cancelled.

Live Status displays event time, source and freshness. Location appears only when policy and access permit it. An outdated signal is labelled stale. ETA is an estimate with source and last update, never a guaranteed appointment.

61.4 Installation and deficiency

Installation Checklist resolves each manifested Item to installed, positioned, incomplete, damaged, missing, returned or not applicable. Evidence, placement, installer and time attach to the result. Deficiency Record retains severity, responsibility, corrective work, target date, evidence and sign-off.

62. Matchmaking, Offers and Commercial Status

62.1 Match Candidate

Candidate Card contains canonical Entity identity, eligible service or specialty, advisory score, ranked dimensions, disqualifying rules, service area, capacity, earliest start, qualification freshness and profile access. Why this match? opens Score Explanation without exposing hidden Provider data or internal weighting beyond approved policy.

62.2 Shortlist and Offer

Shortlist is tied to one Match Request and Provider Category. Adding a candidate records actor and rationale. Sending an Offer snapshots the permitted Project scope, Item list, documents, assumptions, deadline and recipient.

Offer Response states include unopened, viewed, clarification requested, accepted, declined, expired and withdrawn. Counter or reflect behavior, when enabled, creates an explicit response version. Acceptance does not create a Work Order until conversion rules succeed.

62.3 Commercial status chain

The visual flow must not collapse distinct records:

Proposal accepted
  → explicit conversion
Work Order authorized
  → work performed / changes authorized
Invoice issued
  → payment initiated
Payment settled and reconciled

Each state includes source record, version, actor, effective time and permitted next actions. Financial redaction removes values and derived totals from cards, grids, Activity, Notifications, exports and analytics while preserving an appropriate non-financial lifecycle status.

63. User and Workspace Profiles

User and Workspace Profiles use the exact shared profile framework defined in Section 48: Profile Header, Record Tabs, Overview Card Registry, Activity, Projects, Files, Tasks, Communication and History. They are not a separate Settings-only profile design.

User Profile owns personal identity, Memberships, assigned Projects, Tasks, capacity, recent work and permitted contact details. Workspace Profile owns business identity, team, active Projects, network relationships, operating health and permitted Workspace information.

Settings may link from the profile to security, Notification preferences, branding, billing, integrations or defaults. Those are configuration modules, not replacements for the shared profile architecture.

Editing User and Workspace records remains distinct. A User may belong to multiple Workspaces through Memberships. Workspace branding never overwrites personal identity. Shared Email, Phone, Address, File, Activity and permission components apply without local variants.

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

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 16
Mapped current-product profiles: 28
Recorded review gaps: 92

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 — Text input

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

Review gaps

• Character limits are not consistently visible.
• Whitespace and duplicate-name behavior are undocumented.
• Browser autocomplete purpose is not consistently declared.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Project and Pipeline titles, Workspace and Entity names, Task titles, Application questions, builder labels, search inputs.

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 — Textarea and rich-text editor

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

Review gaps

• No canonical rich-text schema is visible.
• Autosave and unsaved-change behavior vary.
• Mention, attachment and revision support is limited to certain composers.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Project Vision, Internal Notes, Task descriptions, Application narratives, Proposal terms, AI-assisted writing.

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 — Email input

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

Review gaps

• Verification state is inconsistently surfaced.
• Duplicate User/contact handling is undocumented.
• Primary versus secondary email semantics are not standardized.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• 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.

G04 — Phone number input

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

Review gaps

• Numbers may currently be stored as unstructured text.
• Country context and extensions are not consistently captured.
• Consent, type and verification are not linked to the field.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• 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.

G05 — URL input

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

Review gaps

• Protocol handling is undocumented.
• No shared broken-link or reachability state.
• External-link privacy and tracking behavior are inconsistent.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Workspace websites, Designer portfolios, Provider galleries, product sourcing, external documents, integration references.

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 — Number input

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

Review gaps

• Comma formatting is inconsistent.
• Unit may be embedded in labels or display strings.
• Precision and negative-value behavior are undocumented.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: square footage, quantities, design hours, team and crew size, capacity, lead times, task offsets.

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 — Money, rate and percentage input

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

Review gaps

• Currency is often implied as dollars.
• Rate basis is rendered inconsistently.
• Blank/zero and tax-inclusive/exclusive behavior are not standardized.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Project values, Budget Categories, Items, shopping lists, Proposals, Purchase Orders, Invoices, commissions and taxes.

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 — Date, time and date-range picker

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

Review gaps

• Current controls often capture date only.
• Timezone and all-day semantics are unclear.
• No shared date-range, recurrence or business-day control is evidenced.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Task due dates, Project milestones, availability, credentials, expected arrivals, receiving, delivery and installation, Calendar.

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 — Address lookup and structured address

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

Review gaps

• Free text may coexist with structured fields inconsistently.
• No visible geocode/confidence model.
• Country/region option behavior is inconsistent.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Client billing, Project sites, Workspace Profiles, Provider facilities, Service Areas, shipping, receiving and delivery.

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 — Single-select dropdown

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

Review gaps

• Task Builder Type order is not alphabetical.
• Urgent exists in builder but not directory filters.
• Select an option placeholders and clear behavior vary.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Pipeline Stage, Task Type/State/Priority, countries and regions, owners, Provider Categories, statuses, builder configuration.

Closure evidence required

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

G11 — Multi-select dropdown

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

Review gaps

• Checkbox and dropdown approaches vary.
• Selected-item overflow is not standardized.
• No consistent remote search or select-all semantics.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: services needed, rooms, specialties, languages, Provider Categories, Task collaborators, Teams, report filters.

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 — Checkbox, radio and toggle controls

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

Review gaps

• Checkboxes are used for semantically different actions.
• Indeterminate group state is not evidenced.
• Consent/evidence versioning is not consistently represented.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: boolean form fields, collaborators, bulk selection, builder requirements, delivery rules, consent and declarations.

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 — Entity, record and assignee picker

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

Review gaps

• Task link types are incomplete.
• Demo Administrator and Brad Mitchell identity conflict exists.
• Large-list search and duplicate-name handling are not standardized.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Task Owner and links, Project Participants, Client and Designer assignment, Provider matching, Teams, commercial counterparties, record relations.

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 — Enterprise data grid

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

Review gaps

• No saved views.
• Column persistence unverified.
• Export output/audit unverified.
• Taxonomy conflicts can make valid records unfilterable.
• Loading metrics may briefly misrepresent zero.

Required future closure

• Make the grid a documented shared component with domain adapters.
• 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.

G15 — Search, filter and sort controls

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

Review gaps

• Active filters are not always visible.
• Closed Task checkbox is ambiguous.
• Saved views and URL state are absent.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: all enterprise grids, Activity, Files, Tasks, Pipelines, Entities, Reports and Matchmaking.

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 — Pagination and progressive loading

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

Review gaps

• No consistent live pattern is evidenced.
• Selection across pages is undefined.
• Total-count freshness and cursor recovery are undocumented.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: directories, Items, Activity, Unified Inbox, Files, Applications, delivery history, Reports.

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 — Dynamic form system

Current-product profile: dynamic-form-system
Observed route: Shared component
Evidence confidence: Verified

Review gaps

• No visible authoritative registry.
• Option ordering conflicts.
• Mapping defect in Applications.
• Money, date/timezone and address normalization are not fully verified.
• Concurrency states are absent.

Required future closure

• Build one schema-driven form renderer and field registry.
• Add preview, schema diff and migration validation.
• Reuse exact controls in Admin, Designer, Provider, Client and public application surfaces.

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

Current-product profile: record-tab-system
Observed route: Shared component
Evidence confidence: Verified

Review gaps

• Dead/disabled modules are inconsistently labelled.
• Activity/History purpose conflict.
• Audience composition is not visible as one governed registry.
• Deep-link and mobile overflow behavior are not fully verified.

Required future closure

• Create one module registry and availability contract.
• Reuse shared services across every profile.
• Add explicit loading, empty, unavailable, unauthorized and 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.

G19 — Activity timeline

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

Review gaps

• Activity and History overlap.
• External participant language is inconsistent.
• Redaction, retention and export are unverified.
• No communication events exist yet.

Required future closure

• Separate Activity projection from audit ledger.
• Add Project, Provider, commercial, receiving, delivery and communication events.
• Define retention and privacy behavior.

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 — Modal, drawer and full-page editor

Current-product profile: modal-and-form-dialogs
Observed route: Shared component
Evidence confidence: Verified

Review gaps

• Critical Task Edit mode defect.
• Long forms can be unwieldy.
• Focus, keyboard, mobile and conflict behavior are not fully verified.
• Unsaved-change protection unverified.

Required future closure

• Enforce dialog mode and record identity centrally.
• Use full-page editors for complex builders.
• Add consistent validation, saving, error, conflict and focus behavior.

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 — Buttons, split actions and action menus

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

Review gaps

• Disabled Proposals/Reports lacked Coming soon labels.
• Loading and duplicate-submission behavior is not consistently evidenced.
• Icon-only overflow action names require review.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: record headers, dialogs, builders, grids, cards, bulk actions, commercial approvals.

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 — Field validation and form feedback

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

Review gaps

• Application mappings can be wrong without blocking publish.
• Long modal validation behavior is unclear.
• Optimistic concurrency conflicts are not represented.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: all forms, builders, imports, commercial documents, Application review, integrations.

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 — Loading, empty, error and permission states

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

Review gaps

• Metrics may flash zero while loading.
• Provider Categories disappear at zero.
• Some disabled modules appear broken.
• Permission-redacted states are not explicit.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: dashboards, grids, record tabs, builders, integrations, Files, communications, Reports.

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 — Toast, banner and inline alert

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

Review gaps

• No central severity/duration rules are evidenced.
• Notification centre and toast responsibilities may overlap.
• Failure recovery actions are inconsistent.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• 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.

G25 — Status pills and semantic colours

Current-product profile: status-pills-and-colours
Observed route: Shared component
Evidence confidence: Verified

Review gaps

• No visible semantic registry.
• Priority conflict exists.
• Contrast, dark mode, printing and unknown-value behavior are unverified.

Required future closure

• Create governed status and priority registries.
• Add icon/pattern alternatives and contrast validation.
• Reuse tokens in every portal and document output.

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 — File and image uploader

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

Review gaps

• Different surfaces imply separate upload patterns.
• Progress/retry and malware-processing states are not evidenced.
• Visibility defaults and metadata requirements vary.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: Record Files, Project inspiration, Internal Notes, Application Documents, receiving photos, delivery proof, Credentials, Project Presentations.

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 — Cards, summary sections and metric tiles

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

Review gaps

• Cards have previously overflowed containers.
• Metric definitions and freshness are not always visible.
• Nested cards can create excessive hierarchy.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: dashboard, record Overview, Project phases, Workspace Profile, Entity metrics, Settings summaries, Matchmaking.

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 — Avatar, identity chip and participant label

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

Review gaps

• Task Owner identity conflict exists.
• Role Label and Access Role context can be conflated.
• Image privacy and fallback rules are not documented.

Required future closure

• Promote this pattern into the approved component library.
• Replace local copies incrementally and retain migration adapters only where required.
• Add automated interaction, validation, accessibility and serialization tests.
• Track reuse across: sidebar account, Teammates, Notes, Tasks, Activity, Project Participants, Offers, approvals and audit.

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