Reverse spec drafted

Pipeline board and grid

Pipeline record browsing, filtering, sorting, columns and stage-based views.

Observed route/admin/pipelinesFuture Spec 09 →

Current maturityWorking board and enterprise table over inconsistent legacy record projections

Evidence confidenceVerified

Last reviewedAugust 4, 2026

Visual evidenceDeferred during UI updates

Current-state summary

The Pipeline workspace provides six swim lanes and a populated enterprise table for the same three opportunities. Table mode supports row selection, fourteen named sort options, sortable headers, export and a column manager that can show, hide and reorder fields while protecting Opportunity and Opportunity ID. The views are functional, but the selected Forest Hill record exposes reconciliation drift: PO-00001/Qualification/3 days in the directory versus LD-101/Qualified/2d in the record header.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

Element	Current behavior	Verification
View switch	Swim lanes and Table are peer buttons above a shared count.	Verified live
Stage lane	Shows stage name, category such as open/qualified/converted/closed, record count and empty or populated content.	Six live stages reviewed
Opportunity card	Shows PO identifier, priority, Project title, Client, Project type, age and owner context.	Three live cards reviewed
Open action	Each card has an accessible Open [Project] button.	Verified by opening Forest Hill Residence
Record count	Displays 3 records / 6 stages above the view.	Verified live
Table surface	Shows Opportunity, Opportunity ID, Stage, Priority, Client, Project type and Age with sortable headers and row selection.	Verified live
Table controls	Provides fourteen sort choices, CSV export and a column panel with visibility plus left/right ordering. Opportunity and Opportunity ID are required.	Verified live; preference persistence and export file contents not tested
Cross-view identity	Forest Hill is PO-00001 in board/table but LD-101 in the profile; stage and age also differ.	Verified live

User journeys

Current flows

Scan by stage

Select Swim lanes
Read lane counts
Compare cards
Identify priority and age
Open a record

Switch to table

Select Table
Review the same Pipeline records in rows
Sort from the selector or column header
Configure visible/order columns
Select or open a row
Export if authorized

Move stage

Initiate a permitted stage transition
Validate required fields
Run automations
Write audit event
Update board

State model

Current and expected states

Populated lane

Qualification contains one card and Client review contains two.

Empty lane

Shows zero and No records.

Open stage

New intake, Qualification and Client review use open semantics.

Qualified stage

Ready to convert is labeled qualified.

Terminal-looking stage

Converted to project and Closed look terminal in the board, but the builder currently classifies every stage as open.

Selected rows

Checkboxes exist, but no bulk action outcome was verified.

Product rules

Non-negotiable boundaries

Board and Table must represent the same canonical record set.
Project Opportunities expose one canonical PO identifier; legacy LD identifiers are hidden aliases only.
Stage colours and labels come from the published Pipeline version.
A stage move must enforce transition requirements and authorization.
Counts and values update from canonical records.
Card content must remain readable without exposing fields the viewer cannot access.

Dependencies

Pipeline stagesPipeline record queryEnterprise data gridTransition validatorField definitionsAutomation engineAudit events

Known current limitations · 7 mapped

What is missing, broken or unverified

Future Spec 09 owns closure →

Critical: board/table and record profile disagree on identifier, stage label and age for the same record.
The builder classifies Converted and Closed as open, weakening terminal-state meaning.
No stage movement control—drag, menu or keyboard—was observed.
No general filtering or search exists in Table mode.
Column preference persistence and export contents were not tested.
Row selection exposes no verified bulk action.
No large-volume pagination or virtualization behavior was tested.

Future alignment

Required evolution

01Use the shared enterprise grid for Table mode.
02Expose the canonical PO identifier consistently and remove LD identity from active views.
03Provide accessible stage changes independent of drag-and-drop.
04Show blocked-transition reasons before mutation.
05Support saved filters, ownership views and overdue/attention signals.
06Retain version-aware stage history when definitions change.

Current baseline

Acceptance record

Six configured stages render in order.
Each live card shows useful identity and work context.
Empty stages are explicit.
Board and Table represent the same three records.
Table sorting, required columns and column arrangement are documented.
Cross-surface identity drift is treated as a release blocker for canonicalization.

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