Reverse spec drafted

Assignments directory

Central table of network assignments, accepted opportunities and linked parties.

Observed route/admin/assignmentsFuture Spec 10 →

Current maturityFunctional shared grid that conflates Offer and Assignment records

Evidence confidenceVerified

Last reviewedAugust 4, 2026

Visual evidenceDeferred during UI updates

Current-state summary

Assignments is a polished shared data grid with search, selection, a combined Type/Status filter, sixteen sort choices, export and configurable columns. It currently contains one active direct Designer assignment (AS-00001) and one sent Designer offer (OF-00002). Both Open actions lead back to legacy Project Opportunity records rather than dedicated Offer or Assignment profiles, so the table provides portfolio visibility but not lifecycle management.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

Element	Current behavior	Verification
Search and count	Search assignments input and two-relationship count.	Verified live
Filter	One dropdown mixes All, Offer, Assignment, Active and Sent.	Verified live
Sort	Sixteen A–Z/Z–A options across relationship, ID, type, Provider type, assigned Provider, status, date and source.	Verified live
Columns	Eight data columns can be reordered; Relationship and Relationship ID are protected from hiding.	Verified live
Rows	AS-00001 active direct assignment and OF-00002 sent offer, both for Designers.	Verified live
Open action	Both relationships open /admin/leads records rather than their own detail.	Verified live

User journeys

Current flows

Find relationship

Search/filter/sort
Review type, party, status, date and source
Open relationship
Take lifecycle action

State model

Current and expected states

Offer sent

OF-00002 shows Sent and an expiry date in Source.

Assignment active

AS-00001 shows Active and Direct assignment.

Selected rows

Checkboxes exist; no bulk actions were exposed.

Provider participation

No non-Designer Provider rows are present.

Product rules

Non-negotiable boundaries

Offer and Assignment are separate canonical records with separate lifecycle states.
Open routes to the relationship record, not merely its source opportunity.
Accepted Offers do not become Assignments until configured acceptance/award prerequisites pass.
Assignments carry Project scope and access-grant linkage.
Workspace and field permissions govern rows, exports and actions.

Dependencies

Offer serviceAssignment serviceProject Opportunity and ProjectProvider/Designer EntityAccess grantsEnterprise data gridNotifications and audit

Known current limitations · 6 mapped

What is missing, broken or unverified

Future Spec 10 owns closure →

No dedicated Offer or Assignment profile is available from the grid.
The filter mixes record type and status in one control.
No response, accept, decline, withdraw, expire, cancel, reassign or close actions are exposed.
No Provider-category relationships are present.
Bulk-selection outcome and export contents were not tested.
Legacy Lead routes remain.

Future alignment

Required evolution

01Add dedicated Offer and Assignment profiles with their own histories and actions.
02Separate record-type, status, category, Project, owner and date filters.
03Link accepted Offers to Proposal/Work Order and atomic Project assignment creation.
04Support Designer and all Provider-category participation from one grid.
05Remove legacy Lead links in favor of canonical source and relationship routes.

Current baseline

Acceptance record

The two current relationship rows and their IDs are recorded.
Grid controls and protected columns are documented.
Offer and Assignment are not treated as one lifecycle.
Missing relationship detail and actions 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