Reverse spec drafted

Client Profile

Client identity, contact preferences, addresses, Matching Profile, Project Opportunities, Projects, decisions, Files, Tasks and Communications.

Observed route/admin/clients/:idFuture Spec 13 →

Current maturityPromised canonical profile not implemented

Evidence confidenceKnown limitation

Last reviewedAugust 4, 2026

Visual evidenceDeferred during UI updates

Current-state summary

The current product describes one Client Profile across Leads, Projects, Communications, Files, Tasks and Matchmaking, but no Client detail route or Profile interface exists. The directory row and Edit Client modal are the only Client-specific surfaces observed. A future Client Profile must become the shared canonical record behind Registry, Designer and permission-scoped Client Portal views.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

Element	Current behavior	Verification
Profile header	Absent; should show Client ID, name, preferred contact, Relationship Owner, Portal state and permitted actions.	Future requirement
Overview	Absent; should summarize contact, household/organization relationships, addresses, preferences, active work and next actions.	Future requirement
Work modules	Absent; Project Opportunities, Projects, approvals, decisions, Files, Tasks and Communication require shared tabs.	Future requirement
Matching Profile	Editable only in the directory modal; requires completeness, freshness, source and Project-specific overrides.	Partial current data
Portal access	No invitation, pending, active, suspended or revoked state appears.	Future requirement

User journeys

Current flows

Manage Client relationship

Open Client Profile
Review identity, consent and preferences
Review Project Opportunities and Projects
Complete Matching Profile
Assign next work
Communicate from Client context

Activate Client Portal

Invite verified Client contact
Authenticate
Accept access
Grant Project-scoped Portal view
Update or revoke access without deleting history

State model

Current and expected states

Passive Client Entity

Likely current state for seeded Clients; no Portal status displayed.

Portal invited/pending/active

Not implemented in Profile.

Duplicate or merged

Not represented.

No active work

Directory can show zero Projects but lacks Profile empty state.

Contact restricted

Permission-redacted variant not verified.

Product rules

Non-negotiable boundaries

Client Profile is one canonical Entity Profile.
Client Portal is an authenticated projection, not a duplicate profile.
A Project-specific preference or decision does not silently overwrite durable Client facts.
Internal Notes, Provider comparisons, margins and unrelated Projects never appear in the Client Portal.
Contact consent, preferred channel and Communication history are auditable.

Dependencies

Spec 13 Client PortalClient EntityWorkspace and Project access grantsProject Opportunities and ProjectsMatching ProfileApprovals and DecisionsFiles, Tasks and CommunicationsPermissions and audit

Known current limitations · 3 mapped

What is missing, broken or unverified

Future Spec 13 owns closure →

No live route, header, tabs, portal state, activity or history exists.
Current data can only be edited from the directory.
No household, organization, secondary contact or consent model is visible.

Future alignment

Required evolution

01Implement the Client Profile and route.
02Reuse shared Entity modules with role-specific visibility.
03Link every directory count to its source records.
04Add Portal lifecycle, household/organization relationships, consent and duplicate management.

Current baseline

Acceptance record

The current absence is accurately represented.
Client Profile and Client Portal are not conflated.
Future modules and security boundaries are explicit.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented