BC
Brad CodyAdministrator
Current product→Pipelines and record experience
Reverse spec drafted

Pipeline transitions and Project conversion

Validated stage progression, readiness, terminal outcomes and idempotent conversion into a Project.

Observed route/admin/leads/:idFuture Spec 09 →
Current maturityVisible conversion action over an incomplete transition model
Evidence confidencePartially verified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The published Project Opportunities workflow defines six ordered stages and a Project outcome, while the record header exposes Convert to Project. The builder warns that New intake, Qualification and Client review have no next step. Every stage—including Converted to project and Closed—is currently typed as open. No stage-change control was found on cards, rows or the record profile, and the conversion action was not executed because it can create a real Project. The UI therefore communicates an intended lifecycle without yet demonstrating a coherent, validated transition engine.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Published stagesNew intake, Qualification, Client review, Ready to convert, Converted to project and Closed are ordered and colour-configured.Verified live builder
Stable stage keysBuilder shows new_intake, qualification, client_review, ready_to_convert, converted and closed.Verified live
Stage categoriesAll six currently select open, even terminal-looking stages.Verified live
Next-step configurationBuilder warns that three open stages have no next step and presents a disabled from/to editor until a draft is created.Verified live
Record transition controlNo general stage-change action was found on the board, table or profile.Verified across reviewed surfaces
Project conversionConvert to Project is visible to the Admin on LD-101.Visible; intentionally not executed
Outcome configurationDirectory says successful outcome creates Project, while the builder Outcomes section is still an implementation placeholder.Verified live

User journeys

Current flows

01

Advance stage

  1. Choose an allowed next step
  2. Evaluate authorization
  3. Validate required transition fields
  4. Confirm consequential action
  5. Persist stage event
  6. Run automations
  7. Refresh all projections
Observed result

Required behavior; no working transition control was observed.

02

Convert to Project

  1. Reach Ready to convert
  2. Resolve blockers and Client identity
  3. Select Convert to Project
  4. Create Project once
  5. Link source and outcome
  6. Move record to Converted
  7. Write Activity/audit and notifications
Observed result

Only the entry button and intended outcome are verified.

03

Close without conversion

  1. Choose an allowed unsuccessful/cancelled outcome
  2. Capture reason
  3. Stop inappropriate automations
  4. Retain history
Observed result

Closed stage exists, but outcome type and close-reason handling are not represented.

State model

Current and expected states

Open intake

First three lanes are active but have no configured next step according to the builder warning.

Ready to convert

Exists with a zero record count; readiness conditions are not visible.

Converted

Exists as an empty lane but remains categorized open.

Closed

Exists as an empty lane but remains categorized open.

Conversion in progress/success/failure

Button implementation may expose these states, but they were not exercised in production.

Product rules

Non-negotiable boundaries

  • Transitions use stable stage IDs and an explicit next-step graph, not label comparison.
  • Only configured transitions are available to the current actor.
  • Required-field and guard failures explain exactly what must be resolved without partially moving the record.
  • Converted, unsuccessful, cancelled and archived categories drive reporting and automation semantics.
  • Project conversion is idempotent: one source record can create at most one governing Project outcome unless an authorized reversal model exists.
  • Conversion copies or links data according to a defined mapping; it does not create disconnected duplicates.
  • Every attempt and result has actor, version, timestamp and correlation/audit data.
  • Automations and notifications run from durable transition events after the transaction succeeds.
Dependencies
Stage and next-step graphTransition guardsRequired fieldsEffective permissionsClient resolutionProject provisioningAutomation engineNotification BuilderActivity and immutable audit historyIdempotency store

Known current limitations · 8 mapped

What is missing, broken or unverified

Future Spec 09 owns closure →
  1. Critical: three active stages have no configured next step.
  2. Critical: every stage is categorized open, including Converted and Closed.
  3. No general stage-change control was found.
  4. Readiness requirements and blocking fields are not visible.
  5. Outcomes configuration is a placeholder despite the directory claiming a Project outcome.
  6. Conversion confirmation, duplicate prevention, rollback and partial-failure behavior were not tested.
  7. Profile and board stage labels already disagree, so a transition may update only one projection.
  8. Automations, access, version history and record-detail builder sections remain placeholders.

Future alignment

Required evolution

  • 01Complete the versioned transition graph and terminal categories before enabling free stage movement.
  • 02Define per-transition required fields, role/capability, confirmation, automation and notification rules.
  • 03Make Ready to convert a calculated, explainable readiness state.
  • 04Implement Project conversion as a governed outcome service reused by other entity-creating Pipelines.
  • 05Expose transition history in Activity and immutable History with human-readable reasons.

Current baseline

Acceptance record

  • All six stage keys, colours and current categories are recorded.
  • Missing next steps and placeholder builder sections are explicit.
  • Conversion is not claimed as working end to end because it was not executed.
  • Idempotency, mapping, audit and notification requirements are captured.
  • Stage projection drift is treated as a blocker before enabling workflow automation.

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
← Feature inventoryOpen Future Spec 09 →