BC
Brad CodyAdministrator
Current productMatchmaking and assignments
Reverse spec drafted

Matchmaking workspace

Central matchmaking queue and governed matching work.

Observed route/admin/matchmakingFuture Spec 10
Current maturitySubstantial Designer-matching prototype with unsafe stale-result state
Evidence confidenceVerified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The live Matchmaking workspace lets an Admin select one of three Project Opportunities, review its saved matching profile, make temporary criteria adjustments, see profile-completeness guidance, and prepare offers from a shortlist. However, changing the selected opportunity does not clear or reconcile the prior policy snapshot, criteria snapshot, scores, or shortlist. Forest Hill Residence remained paired with an Oakville/New build/$500K–$1M result set, making the visible Create offers action unsafe until a new immutable Match Run is created.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Subject selectorSearchable dropdown lists Forest Hill Residence, Oakville Lakeside and Rosedale Heritage with Client names; leadId deep links preselect a record.Verified live
Matching profileShows Project, budget, location, timing, style and needs from saved opportunity data plus missing-detail guidance.Verified live
Temporary adjustmentsProject type, budget, property type, language, location, province, start date and timeline can be changed for the run; specialties/styles/services/rooms display as summarized chips.Verified live; no values saved
Run actionFind compatible designers is available and states that the saved profile will be used.Visible; not executed to avoid creating a real run
Policy and criteria snapshotDisplays Proper Gallery residential matching v2 and a criteria summary that can belong to a different opportunity than the active selection.Critical mismatch verified live
Shortlist and candidatesShows up to two seeded Designer cards with score, eligibility, availability and add/remove actions.Verified live
Offer preparationCreate offers opens a modal for shortlisted Designers, permission-safe summary, response deadline and portal delivery.Modal verified; offer not sent

User journeys

Current flows

01

Start from a record

  1. Open Matchmaking with leadId
  2. Resolve the Project Opportunity
  3. Review saved criteria and missing details
  4. Run matching
  5. Review results
Observed result

Deep-link selection works; existing result state is not safely bound to the resolved subject.

02

Adjust one run

  1. Open Adjust criteria
  2. Change temporary inputs
  3. Run matching
  4. Store an immutable snapshot
Observed result

Adjustment controls exist; rerun and snapshot behavior were not exercised.

03

Prepare offers

  1. Shortlist candidates
  2. Select Create offers
  3. Review visible summary and deadline
  4. Send
Observed result

Preparation modal verified; send intentionally not executed.

State model

Current and expected states

No subject selected

Shows selection guidance but still displays seeded policy, shortlist and candidate results.

Subject selected

Displays saved profile and completion guidance.

Adjusting criteria

Inline temporary criteria panel opens.

Stale/mismatched run

No warning or block appears when result snapshot disagrees with selected subject.

Offer modal

Shows shortlisted Designer, summary, deadline, disclosure statement and send count.

Product rules

Non-negotiable boundaries

  • A Match Run, result set, shortlist and outreach action must reference the same canonical subject ID and snapshot hash.
  • Changing subject clears unbound draft state or labels the prior run stale and blocks outreach.
  • Scores always identify Criteria Set version, run time and data freshness.
  • Offers can be created only from a completed non-stale run and its saved shortlist.
  • Temporary adjustments never overwrite the Project Opportunity unless explicitly saved through its canonical form.
  • Client-private details are excluded from pre-acceptance outreach.
Dependencies
Canonical Project OpportunityMatch ProfileCriteria SetMatch Run serviceDesigner profilesShortlistOffer serviceNotification BuilderPermissions and audit

Known current limitations · 7 mapped

What is missing, broken or unverified

Future Spec 10 owns closure →
  1. Critical: active subject and visible result snapshot can disagree.
  2. The empty-selection state still shows seeded candidates and shortlist.
  3. Complete criteria produced no visible action during review.
  4. Temporary adjustments mention saving to the opportunity but expose no clear save action.
  5. Proper Gallery policy branding and legacy /admin/leads links remain.
  6. Loading, run failure, no-match, partial evaluation and stale-data states are not represented.
  7. Provider matching is not available on this workspace.

Future alignment

Required evolution

  • 01Bind every result and shortlist to an immutable subject/run identity from Spec 10.
  • 02Replace legacy Lead links and Proper Gallery policy language.
  • 03Implement readiness, stale-run, running, failure, no-match and superseded states.
  • 04Add governed Provider matching from Project Requirements and Work Packages.
  • 05Prevent offer creation whenever subject, run, shortlist or disclosure snapshot is inconsistent.

Current baseline

Acceptance record

  • Subject selection and deep linking are documented.
  • Visible matching-profile fields and temporary criteria are inventoried.
  • Offer preparation is separated from actual sending.
  • Stale cross-subject results are a release blocker.
  • No real Match Run or Offer was created during review.

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