BC
Brad CodyAdministrator
Current product→Projects and project operations
Reverse spec drafted

Seven-phase Project process

Concept, Design, Design Package, Construction Administration, Decorating, Procurement and Installation.

Observed route/admin/projects/:slug?tab=processFuture Spec 07 →
Current maturityCanonical seven-phase shell with minimal execution depth
Evidence confidenceVerified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

The Project Process tab correctly implements the seven canonical Project Phases: Concept, Design, Design Package, Construction Administration, Decorating, Procurement and Installation. It displays per-phase progress and a current Phase status. The active Design Phase has no tasks and no approvals. Project Builder enables phases, display labels, default durations and free-text completion rules, but its seeded template contains only two Concept tasks and uses editable text lists for roles, deliverables, approvals, forms and automation rules.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Canonical phase navigationSeven buttons display exact canonical phase names and progress.Verified live
Active Phase headerDesign is active with 28% progress and in progress state.Verified live
Phase tasksDesign Tasks shows no tasks assigned to this phase.Verified live
Phase approvalsNo approvals are waiting.Verified live
Phase advancementOverview exposes Complete phase and advance.Trigger verified; transition not executed
Project Builder phasesEach phase can be enabled, relabeled, assigned a duration and given free-text completion rules.Verified live
Template task libraryTwo Concept tasks support group, owner role, type, due anchor, offset and dependency.Verified live

User journeys

Current flows

01

Complete a Phase

  1. Perform required tasks and deliverables
  2. Resolve required approvals and exceptions
  3. Validate completion rules
  4. Complete the Phase
  5. Record transition and enable downstream work
Observed result

Only the shell and action are visible; rule evaluation was not exercised.

02

Configure a Project Template

  1. Enable canonical phases
  2. Set display labels and duration
  3. Create tasks and milestones
  4. Define dependencies and owner roles
  5. Configure Provider Requirements, forms, deliverables, approvals and automations
  6. Validate and publish immutable version
Observed result

Phase and basic task configuration exist; structured Provider Requirements and governed completion configuration are missing.

State model

Current and expected states

Complete

Concept shows 100%.

In Progress

Design shows 28%.

Not Started

The five later phases show 0%.

Blocked

No phase-level blocked state or reason was observed.

Overlapping Phases

Not represented despite the need for overlapping professional work.

Disabled Phase

Builder permits disabling, but Project behavior was not observed.

Product rules

Non-negotiable boundaries

  • Project workflow positions are called Phases, never Pipeline Stages.
  • Canonical phase keys remain stable even when customer display labels are customized.
  • One Primary Project Phase supports reporting while work may overlap across phases.
  • Progress derives from governed work and is explainable.
  • Completion rules are structured and machine-validatable rather than authoritative free text.
  • Published template versions are immutable for existing Projects.
Dependencies
Project Template versionTask and Milestone templatesApprovalsDeliverables and FormsProvider RequirementsAutomation EngineCalendar anchorsAudit trail

Known current limitations · 6 mapped

What is missing, broken or unverified

Future Spec 07 owns closure →
  1. Only two tasks exist and both belong to Concept.
  2. Design can show 28% despite having no visible tasks or approvals.
  3. Completion rules and automation rules are free-text lines.
  4. Project roles are stored as text and include Client / Household rather than governed participant roles.
  5. No phase deliverables, forms, decisions, Files, Items, Budget Categories, Provider Work Packages or schedule are visible in Process.
  6. No blocked, skipped, reopened or overlapping-phase model is visible.

Future alignment

Required evolution

  • 01Implement structured phase requirements and explainable progress.
  • 02Allow overlap while maintaining one Primary Project Phase.
  • 03Add phase-specific modules for Construction Items, Decorating Items, Procurement and Installation.
  • 04Replace Partner roles and free-text role lists with Project Participants and Provider Requirements.
  • 05Generate tasks, milestones, approvals, deliverables, forms, schedule anchors and notifications from immutable templates.

Current baseline

Acceptance record

  • All seven canonical Phase names are exact and ordered.
  • Stage is reserved for Pipelines.
  • Observed progress contradictions and missing execution depth are explicit.
  • No phase was advanced 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
← Feature inventoryOpen Future Spec 07 →