Clients directory
Workspace Client list with contact, Project Opportunity, Project, Pipeline value and Matching Profile summaries.
/admin/clientsFuture Spec 13 →Current-state summary
The Clients directory lists three seeded Client Entities with contact, location, communication preference, legacy Lead count, Project count, Pipeline value, Match Profile completeness, Assigned Admin and activity date. It claims one Client Profile across work, but Client names and IDs do not link to a detail route; the only row action opens a large Edit Client modal. All three Clients have one open Lead, zero Projects and 18% Match Profile completion.
Interface inventory
Anatomy and verified behavior
Verification states separate observed behavior from requirements or assumptions.
| Element | Current behavior | Verification |
|---|---|---|
| Header and creation | Relationships, Clients, one-profile claim and Add Client. | Verified live |
| Metrics | Total Clients 3, Clients with open Leads 3, Combined Pipeline $1,645,000 and Complete Match Profiles 0. | Verified live |
| Filter | One Assigned Admin option, Demo Administrator. | Verified live |
| Grid | Client, ID, Phone, Location, Preferred Contact, Leads, Projects, Pipeline Value, Match Profile, Assigned Admin, Last Activity and Actions. | Verified live |
| Edit modal | Contact, address and matching criteria with required names and standardized address/time controls. | Verified without saving |
| Profile navigation | Absent; names and IDs are not links and Edit is the only action. | Verified absent |
User journeys
Current flows
Find and edit Client
- Search or sort Clients
- Review row summaries
- Select Edit
- Update contact, address or Matching Profile
- Save
Open Client Profile
- Select Client name or ID
- Open Overview
- Review Project Opportunities, Projects, decisions, Files, Tasks and Communications
State model
Current and expected states
All three rows use legacy Lead count 1.
All Project counts are zero.
All rows show 18%; no completeness explanation.
No warning or merge state was observed.
Not represented.
Product rules
Non-negotiable boundaries
- Client is the canonical Entity term; Lead is replaced by Project Opportunity or Pipeline Record.
- One Client Entity may have many Project Opportunities and Projects.
- Client Profile and Client Portal are distinct: the Profile is the canonical relationship record; the Portal is the Client’s authenticated experience.
- Assigned Admin should become Relationship Owner and must reference a Teammate.
- Contact and financial columns, export and search obey field permissions.
- Matching fields support correct multiplicity and shared option registries.
Known current limitations · 6 mapped
What is missing, broken or unverified
Future Spec 13 owns closure →- No dedicated Client Profile exists.
- Legacy Leads labels remain in metrics and columns.
- Client rows expose phone, email and Pipeline value without a verified permission variant.
- Rooms, Services Needed and Designer Specialties appear as single-select controls despite likely multi-value semantics.
- Matching Profile percentage is unexplained.
- Duplicate detection, merge, household/organization relationships and Portal status are absent.
Future alignment
Required evolution
- 01Build dedicated Client Profile from Spec 13.
- 02Replace Leads with Project Opportunities and canonical Pipeline Record links.
- 03Add Overview, Project Opportunities, Projects, Matching, Decisions, Files, Tasks, Communication, Activity and History modules.
- 04Correct multi-select fields through the shared field registry.
- 05Add duplicate resolution, household/organization relationships and Client Portal access state.
Current baseline
Acceptance record
- All three rows, metrics, columns and editor sections are documented.
- The missing Profile is explicit.
- No Client data was changed.
Reverse-spec completeness
Documentation coverage
The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.
Purpose and user outcome
DocumentedRoles and access
DocumentedRoutes and entry points
DocumentedPage and component anatomy
DocumentedFields and displayed data
DocumentedPrimary actions
DocumentedForms and validation
DocumentedStates and transitions
DocumentedEmpty, loading and error states
DocumentedResponsive behavior
PartialAccessibility behavior
PartialActivity and audit events
PartialData sources and persistence
DocumentedNotifications and automation
PartialKnown defects and limitations
DocumentedReusable component dependencies
DocumentedFuture-spec conflicts
PartialVisual and repository evidence
DeferredAcceptance of current baseline
Documented