Reverse spec drafted

Compatible partners (current label)

Ranked Match Candidates with fit signals, service-area exceptions and profile access; the generic live label must become category-specific.

Observed route/admin/leads/:id?tab=matchmakingFuture Spec 10 →

Current maturityWorking Designer recommendation tab with inconsistent scoring context

Evidence confidenceVerified

Last reviewedAugust 4, 2026

Visual evidenceDeferred during UI updates

Current-state summary

The Project Opportunity Matchmaking tab uses the generic label Compatible partners while ranking two Designer Studios. It shows concise fit evidence, eligibility/review language, availability, next-start dates and profile links, and permits shortlist selection before sending Offers. Interior Designers is the only enabled category; Storage, White-glove Delivery, Photographers and Millwork are disabled without Coming soon labels. The same Forest Hill Match Candidates score 100/30 here but 92/68 in the full workspace, with no visible Match Run or Criteria Set explanation.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

Element	Current behavior	Verification
Category selector	Interior designers is active; four Provider categories are disabled.	Verified live
Candidate cards	Show rank, identity, city, availability, next start, fit tags, warning, score/status and profile link.	Verified live
Selection	Each Designer has a shortlist checkbox; Send offers remains disabled until selection.	Verified live; no selection changed
Full matching link	Opens /admin/matchmaking with legacy leadId query.	Verified live

User journeys

Current flows

Review recommendations

Open record Matchmaking
Review ranked Designers
Read fit reasons and warnings
Open profile
Select candidates or open full matching

State model

Current and expected states

Compatible

Atelier Maison displays 100/100 and Compatible.

Review needed

Studio North displays 30/100, a Project-type warning and Review needed.

Provider category unavailable

Category buttons are disabled without explanation.

No selection

Send offers is disabled.

Product rules

Non-negotiable boundaries

Inline and full Matchmaking must display results from the same identified Match Run.
Scores cannot be compared without Criteria Set version and freshness context.
Use Compatible Designers, Compatible Providers or Match Candidates; Partner is not the canonical general participant term.
Disabled categories explain availability and do not imply working Provider Matchmaking.
Candidate cards reveal only authorized evidence.
Shortlist state is one canonical record shared with the full workspace.

Dependencies

Match RunDesigner Studio profileAvailabilityShortlistOffer serviceProject Opportunity permissions

Known current limitations · 6 mapped

What is missing, broken or unverified

Future Spec 10 owns closure →

The generic Compatible partners label conflicts with the governed Designer/Provider vocabulary.
Scores conflict with the full workspace for the same visible subject and Match Candidates.
No Match Run ID, Criteria Set version, timestamp or freshness is shown.
Provider Categories are unexplained disabled controls.
Service-area exceptions are less detailed than earlier evidence.
Empty, error, stale and insufficient-data states were not observed.

Future alignment

Required evolution

01Replace Compatible partners with category-specific Match Candidate labels.
02Render a compact projection of the latest valid Match Run.
03Show score confidence, run freshness and top reasons consistently.
04Mark unavailable Provider Categories Coming soon until Project-based Matchmaking exists.
05Use canonical Pipeline Record links instead of leadId routes.

Current baseline

Acceptance record

Two Designer candidates and their visible evidence are documented.
Inline selection and full-workspace handoff are present.
Score inconsistency is treated as a correction requirement.
Disabled Provider categories are not described as implemented.

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