The Design Registry

07 — Projects, Items, Budgets & Provider Operations

Version: 2.0
Prepared: August 2026
Status: Engineering and product source of truth
Depends on: Product Vision; Spec 03 Teammates, Teams, Role Labels & Notifications; Spec 04 Authenticated Workspace Dashboard & Profiles; Spec 05 Provider Applications; Spec 06 Proposals, Work Orders, Invoicing & Payments; Spec 08 Permissions; Spec 09 Pipeline, Forms & Automation Builder; Spec 10 Matchmaking, Offers & Network Assignment Engine; Spec 12 Tasks, Calendar & Resource Scheduling; Spec 13 Client Portal; Spec 14 Files, Documents, Notes, Deliverables & Version Control

1. Executive Summary

Projects are the operational centre of The Design Registry. Pipelines qualify opportunities and create durable Entities; Projects connect those Entities to the work. Every Client, Designer, Provider, task, schedule, Item, budget, approval, File, communication, Offer, Proposal, Work Order, Purchase Order, shipment, Receiving Record, delivery and installation outcome must converge on one canonical Project Record.

This specification upgrades the current Project shell into a complete interior-design operating system. It preserves the existing black-and-white interface, shared data grids, forms, tabs, cards, activity, Files, Tasks and Project Vision & Inspiration. It adds the operational depth Designers need to leave spreadsheets and the workflow value Providers need to keep work and payments inside the platform.

The Project process uses seven canonical Phases:

1. Concept
2. Design
3. Design Package
4. Construction Administration
5. Decorating
6. Procurement
7. Installation

Project workflow positions are always called Phases. Stages belong to Pipelines. A Project may have one Primary Project Phase for reporting while work continues across overlapping Phases.

Construction Items and Decorating Items share one canonical Item service but use different fields, category sets, approvals and operating views. Budget Categories are integrated with Items and commercial records. Spreadsheet and Google Sheets import must support field mapping, preview, validation, deduplication, provenance and safe retry. Provider Requirements become Work Packages, Offers, Proposals, Work Orders and operating assignments without creating disconnected copies.

The Project also includes an AI-assisted Project Presentation Builder. Designers can assemble a branded Client-facing webpage from authorized Project data, Vision & Inspiration, selections, decisions and Files, review every generated statement, publish an access-controlled version and export the same version to PDF.

2. Product Outcomes

The finished module must:

• give Designers one dependable Project Record instead of fragmented spreadsheets, Canva decks, inboxes and shared folders;
• give Clients a polished, controlled experience for decisions, approvals, appointments and progress;
• give each Provider a useful Project Job projection tied to its actual operating workflow;
• make the seven-Phase process executable through tasks, milestones, approvals, deliverables, Items and schedule;
• support construction materials and Decorating selections without collapsing their different workflows;
• calculate budgets from Item and commercial activity while preserving approved baselines;
• make receiving, condition, storage, delivery and installation status visible at Item level;
• turn Provider Requirements into governed matching, Work Packages and assignments;
• preserve one canonical record while supporting Admin, Designer, Client and Provider views;
• let Designers import existing spreadsheets without losing source traceability;
• create elegant Project Presentations without requiring Canva;
• keep every consequential change attributable and auditable.

2.1 Success measures

• 80% of activated Designer Workspaces create or import an active Project within thirty days.
• 75% of active Projects use a published Project Template.
• 90% of purchased Items have a Budget Category, expected arrival and receiving destination.
• 95% of received Items have quantity and condition recorded.
• Fewer than 2% of import retries create duplicate Items.
• 80% of active Provider Work Orders receive an in-platform operational update.
• Project budget variance is explainable from Items, Work Orders, Purchase Orders, Invoices and approved changes.
• Designers can publish a Client-ready Project Presentation in less than thirty minutes.

3. Scope

3.1 In scope

• Projects directory and Project Record profile.
• Direct Project creation and idempotent Project Opportunity conversion.
• Project Templates and immutable published versions.
• Seven canonical Project Phases and overlapping work.
• Project Participants, roles, assignments and access grants.
• Spaces, floors, rooms and zones.
• Tasks, milestones, approvals, decisions, deliverables, Files and communications in Project context.
• Construction Items and Decorating Items.
• Item Categories, Budget Categories and Project budgets.
• Shopping Lists and Client selection workflows.
• Spreadsheet and Google Sheets Item import with field mapping.
• AI-assisted product URL, quote and Purchase Order extraction with confirmation.
• Provider Requirements, Work Packages and Project assignments.
• Purchase Orders, expected arrival, shipment, receiving, condition, storage, delivery and installation linkage.
• Calendar and resource-schedule projections owned by Spec 12.
• Project Presentation Builder, controlled sharing and PDF output.
• Notifications, activity, audit, reporting, permissions and migration.

3.2 Out of scope

• Accounting-ledger implementation, owned by Spec 06 and QuickBooks integration.
• Detailed task and resource-scheduling engine, owned by Spec 12.
• General communications transport, owned by Spec 11.
• Provider-category portal details beyond Project integration, owned by Spec 16.
• Final third-party AI, mapping, PDF or route-provider selection.

4. Canonical Terminology

The company glossary is authoritative. Product labels, specifications, notifications, exports, APIs and database documentation must use these terms consistently.

Canonical Phase keys are stable. Customer display labels may be customized, but reports, automations, migrations and APIs map them to:

• concept
• design
• design_package
• construction_administration
• decorating
• procurement
• installation

5. Current Product Baseline and Correction Contract

The current product already provides:

• a Projects directory with search, metrics, sorting, export and columns;
• stable-looking Project IDs and dedicated routes;
• Overview, Process, Participants, Files, Communication and Activity tabs;
• seven Phase controls and progress values;
• Project Pulse, planning budget, blockers, approvals, Spaces & Rooms, Vision & Inspiration and decisions summaries;
• a Project Builder with Phase enablement, display labels, duration, completion-rule text, Item/Budget Categories and basic Task templates;
• a structured New Project form.

The correction release must address these observed gaps:

1. Replace legacy Proper Gallery template copy and seed data.
2. Replace Partner roles with Project Participants and Provider Requirements.
3. Reserve Stage for Pipelines; use Phase everywhere in Projects.
4. Replace lowercase Phase and health labels with canonical display values.
5. Make progress and health explainable from governed records.
6. Replace free-text completion and automation rules with structured builder configuration.
7. Add first-class Tasks, Calendar, Items & Budgets, Provider Operations, commercial and Presentation modules.
8. Link Client/household to a Client Entity rather than a copied text field.
9. Separate Construction and Decorating category behavior.
10. Ensure Project Opportunity conversion and direct creation use the same idempotent Project command.

No new work may deepen the legacy terminology or create a second Project data model.

6. Information Architecture

6.1 Projects directory

The directory supports:

• search;
• saved views;
• filters for Phase, health, Client, Designer, Provider Requirement, owner, template, location and dates;
• sortable and configurable columns;
• permission-aware financial columns;
• selection and governed bulk actions;
• export with the same field permissions as the screen;
• empty, loading, partial, error and offline states.

Core columns are Project, Project ID, Client, Primary Project Phase, Progress, Health, Location, Planning Budget, Forecast, Completion Target and Owner.

6.2 Project profile tabs

The shared Project profile supports these modules:

1. Overview
2. Process
3. Tasks
4. Calendar
5. Spaces
6. Items & Budgets
7. Providers
8. Participants
9. Approvals & Decisions
10. Files
11. Communication
12. Commercial
13. Presentation
14. Activity

Tabs are permission- and module-aware. Hiding a tab never replaces backend authorization. Unavailable modules are disabled and labeled Coming soon rather than linking to # or presenting a dead action.

6.3 Provider Project Job

A Provider does not receive a duplicate Project. Its Project Job is a permission-scoped projection containing assigned Work Packages and Work Orders, authorized Items, dates, locations, Files, contacts, evidence, issues, messages and payment records.

7. Project Record

7.1 Core fields

• Project ID and slug
• Workspace owner
• Project name
• Client Entity
• Project type
• Project Template version
• Primary Project Phase
• enabled Phases
• health and health reasons
• overall progress and calculation version
• start, Completion Target and installation dates
• property and billing addresses
• currency and time zone
• planning budget and approved baseline
• assigned Designer Studio and Project lead
• market and Studio Location
• source Project Opportunity and conversion event
• state: draft, active, on hold, completed, cancelled or archived

7.2 Identity and references

The Project ID is stable and human-readable. URL slugs may change without changing the identity. Client, Designer, Provider and user names are rendered from linked Entities and Memberships, not copied into authoritative free-text fields.

7.3 Creation paths

• Project Opportunity conversion
• direct Project creation
• duplicate from authorized Project structure
• import through governed migration
• API creation by approved integration

All creation paths invoke one idempotent command, validate required references, attach an immutable Project Template version and write an Activity event.

8. Project Templates and Builder

8.1 Template contents

A Project Template defines:

• Project type and intended use;
• enabled canonical Phases and display labels;
• default durations, targets and overlap rules;
• Task, checklist and Milestone templates;
• dependencies and schedule anchors;
• Project Participant role requirements;
• Provider Requirements by Phase;
• Space and room-type defaults;
• Construction and Decorating Item Categories;
• Budget Categories and roll-up rules;
• required forms, Files, deliverables, approvals and decisions;
• Work Package recipes;
• notification and automation references;
• Project Presentation templates;
• health and progress calculation configuration.

8.2 Draft and publish lifecycle

Templates have Draft, Validation Failed, Ready, Published, Superseded and Archived states. Publishing creates an immutable version. Existing Projects retain their version. Applying a later version requires a preview showing added, changed, removed and conflicting work followed by an explicit migration decision.

8.3 Structured rules

Completion rules and automations use the shared rule builder. Free-text descriptions may explain a rule but cannot execute it. Rules reference stable field, Task, Milestone, Approval, Deliverable, Item, Budget and Provider Requirement identifiers.

8.4 Validation

Publish is blocked when:

• a Task references a disabled Phase;
• dependencies form a cycle;
• a due anchor does not exist;
• a required Participant role or Provider Category is invalid;
• a Category code is duplicated;
• a completion rule cannot be evaluated;
• an automation action or Notification Template is missing;
• a Client-visible requirement exposes internal-only data.

9. Seven-Phase Project Process

9.1 Phase model

Each Phase instance stores key, display label, state, dates, progress, health, owner, requirements, blockers, completion event and reopen history.

States are Not Started, Ready, In Progress, Blocked, Complete, Skipped and Reopened. Skipping or reopening requires authority and a reason.

9.2 Overlap

Phases may overlap. One Primary Project Phase is used for high-level communication and reporting. Tasks, Items and Provider work retain their actual Phase references.

9.3 Progress

Phase Progress is calculated from configured weighted Tasks, Milestones, Approvals, Deliverables, forms, Item thresholds and exceptions. Overall Project Progress rolls up enabled Phases using the published Template calculation. The interface shows what contributes to the percentage.

9.4 Advance Phase

Complete Phase and Advance performs a server-side validation and returns:

• satisfied requirements;
• blocking requirements;
• warnings;
• downstream Tasks, events and notifications to create;
• the proposed next Primary Project Phase.

The user confirms before mutation. Completion and advancement are separately auditable events.

10. Spaces, Floors and Rooms

Spaces form a Project-specific hierarchy supporting property, building, floor, area, room, zone and exterior location. A Space may link to:

• dimensions and square footage;
• plans and revisions;
• Construction and Decorating Items;
• photos and measurements;
• Tasks, issues and approvals;
• Client Presentation sections;
• delivery and installation placement.

Deleting a referenced Space is prohibited. It may be merged, archived or replaced with audited relationship updates.

11. Canonical Item Model

11.1 Shared fields

Every Item supports:

• Item ID, Project and Workspace;
• Item type and Category;
• title, description, image and source;
• Space, Phase and package relationships;
• specification, dimensions, finish, colour and variant;
• quantity, unit and allowances;
• Vendor or source Provider;
• currency, source cost, trade cost, Client price, tax and markup;
• Budget Category;
• selection, approval, ordering and operational state;
• expected arrival and receiving destination;
• Files, notes, activity and exceptions.

11.2 Construction Items

Construction Items add specification section, drawing/detail reference, material, manufacturer, model, finish schedule, measurement basis, waste factor, contractor scope, required-on-site date, substitution state and field-installation status.

Examples include flooring, tile, stone, plumbing fixtures, lighting, appliances, hardware, paint, millwork materials and architectural components.

11.3 Decorating Items

Decorating Items add shopping-list state, room placement, product URL, client-selection state, trade availability, lead time, sample status, presentation state, sourcing alternatives and installation placement.

Examples include furniture, rugs, art, accessories, textiles and window treatments.

11.4 Shopping Lists

A Shopping List is a filtered, grouped view of Decorating Items. It never creates disconnected item copies. Designers can group by Space, Category, Presentation, Client decision or purchasing readiness.

12. Item and Budget Categories

Item Categories and Budget Categories are separate but may have default mappings.

An Item Category defines fields, validation, workflow and reporting behavior. A Budget Category defines financial roll-up and baseline behavior. Category trees support stable codes, display labels, parent relationships, applicable Item types and active dates.

Projects may add permitted custom Categories without altering the source Template. Custom categories preserve Workspace and Project ownership and cannot reuse protected codes.

13. Budget Model

13.1 Values

Each Budget Category and Project total supports:

• Planning
• Approved Baseline
• Committed
• Actual
• Forecast
• Remaining
• Variance

13.2 Calculation

Values derive from approved Items, Work Orders, Purchase Orders, Invoices, credits and approved Change Orders. Manual adjustments require authority, reason and Activity.

13.3 Visibility

Permissions separately govern planning, internal cost, trade cost, Client price, markup, Provider pricing, margin, Invoice and payment fields. A user allowed to see Project identity does not automatically see financials.

13.4 Multi-currency

The Project has a reporting currency. Source transactions preserve original currency, amount, rate source and conversion date. Historical values are not silently recalculated.

14. Import and Data Onboarding

14.1 Sources

• .xlsx, .xls, .csv and .tsv upload;
• Google Sheets selected through an authorized connected account;
• copy/paste into a structured staging grid;
• approved API source;
• AI-assisted product URL, Vendor quote or Purchase Order extraction.

14.2 Import workflow

1. Select source and destination Item type.
2. Choose sheet and header row.
3. Map source columns to canonical fields.
4. Apply transformations for currency, dates, quantities, Categories and addresses.
5. Preview valid rows, warnings and errors.
6. Review duplicate candidates and update rules.
7. Confirm create/update counts.
8. Commit an idempotent Import Batch.
9. Reconcile rejected rows without reimporting successes.

14.3 AI extraction

AI may propose fields from a URL, quote or Purchase Order. The interface shows source evidence, confidence and missing fields. A user confirms changes before canonical records are created. AI never fabricates price, availability, lead time or order status.

15. Provider Requirements and Work Packages

15.1 Provider Requirements

Templates and Projects declare required Provider Categories, scope, location, dates, qualifications, evidence, capacity, commercial model and visibility. Use Provider Requirement, not Partner role.

15.2 Work Package creation

A Work Package snapshots the authorized Project information sent for pricing or execution:

• scope and exclusions;
• Items and quantities;
• dates, locations and access requirements;
• drawings and Files;
• evidence recipe;
• response deadline;
• commercial instructions;
• Client and internal visibility rules.

15.3 Matching and assignment

Provider matching uses the Work Package and Project context. An accepted Offer may lead to a Proposal, Work Order and Project Assignment. These are related canonical records, not status names on one row.

15.4 Access

Provider access is Project-, Work Package- and field-scoped. Assignment or Work Order activation creates the minimum access grant. Completion, cancellation or suspension may revoke active access while preserving history.

16. Procurement and Purchase Orders

Approved Items may be grouped into Purchase Orders by Vendor, currency, receiving destination and commercial terms. Purchase Orders preserve line-item source, quantity, price, expected arrival, acknowledgements, revisions and status.

States include Draft, Approval Required, Approved, Sent, Acknowledged, Partially Shipped, Shipped, Partially Received, Received, Closed and Cancelled.

Vendor acknowledgement differences create structured exceptions for price, quantity, variant, availability and date. They do not silently overwrite approved Project facts.

17. Shipment, Receiving and Storage

17.1 Shipment

A shipment connects Purchase Order lines and Items to carrier, tracking, package count, origin, destination and expected dates.

17.2 Receiving Record

The Storage or Receiving Provider records:

• received date and time;
• receiver;
• Item and quantity;
• package and identifier;
• condition;
• photographs;
• discrepancy or damage;
• immediate disposition;
• Storage Location.

17.3 Condition and exceptions

Condition values are Good, Packaging Damaged, Item Damaged, Missing Parts, Incorrect Item, Quantity Variance and Inspection Required. Exceptions create Tasks, notifications and claim records where configured.

17.4 Storage

Storage Locations support facility, zone, aisle, rack, bay, shelf, pallet or Provider-defined hierarchy. Moves preserve chain of custody. An Item cannot be released without an authorized Delivery Manifest or disposition.

18. Delivery and Installation

A Delivery Manifest contains Items, quantities, origin, destination, appointment, crew, vehicle, handling requirements and placement instructions. White-glove Providers update en route, arrived, unloading, placed, exception and complete states. Live location may be shared during an authorized delivery window and expires automatically.

Installation planning groups Items by Project, Space, sequence and crew. The install-day view shows readiness, delivery status, placement, condition, dependencies and exceptions. Completion evidence may include photographs, signatures and deficiency creation.

19. Project Calendar and Tasks

Spec 12 owns canonical Tasks, Calendar events, resources and time entries. The Project profile embeds permission-scoped projections:

• Phase Tasks and Milestones;
• Project Calendar and agenda;
• Provider appointments;
• receiving, delivery and installation windows;
• Client meetings and decisions;
• resource and capacity conflicts;
• user-attributed time by Project and Phase.

Google Calendar is an integration target, never the source of truth for Project completion.

20. Approvals and Decisions

Approvals are versioned requests with subject, version, decision-maker, due date, visibility and outcome. Decisions preserve the selected outcome, actor, time, source version, comments and downstream effects.

Approval subjects include Vision, Design Package, Item selection, Budget change, Purchase Order, substitution, Work Package, schedule change and Project Presentation.

An edited approved artifact becomes a new version and may require reapproval.

21. Project Presentation Builder

21.1 Purpose

Designers create an elegant Client-facing Project webpage and PDF using the same Project data they already maintain.

21.2 Sources

• Project identity and approved Client-visible summary;
• Vision & Inspiration version;
• selected Spaces, plans and images;
• approved Items and Shopping Lists;
• approved budgets or ranges;
• decisions, milestones and schedule;
• Designer-authored text and uploaded Files.

21.3 Builder

The builder supports Workspace-branded templates, section library, drag-and-drop order, prompt-based draft generation, section-level regeneration, direct editing, image selection, visibility checks, desktop/mobile preview and version comparison.

21.4 AI rules

• AI output is always a draft.
• Source records and versions are preserved.
• Unsupported claims are flagged.
• Internal Notes, margins, hidden Provider data and unauthorized contacts are excluded by default.
• A human approves the exact version before publishing.

21.5 Publishing

Publishing creates an immutable Presentation version with access controls, expiration, optional passcode, recipient context and audit. Editing creates a successor. A published version may be revoked without deleting history.

21.6 PDF

PDF uses the same approved content version and brand tokens as the webpage. Rendering supports page breaks, print-safe colour, image quality, links, accessibility metadata and repeatable output.

22. Files, Communication and Activity

Project Files use versioning from Spec 14. Plans and drawings expose revision, discipline, status and supersession. Project Communication uses Spec 11 and links authorized email, SMS, calling and in-app threads to the Project and relevant Provider, Item or Work Order.

Activity records consequential events such as Project creation, phase transition, assignment, approval, Item import, budget baseline, Purchase Order, receipt, damage, storage move, delivery, installation, Presentation publish and access revocation.

23. Notifications and Automation

Every new Project event that may notify a person is registered in the Notifications Builder as an editable template with protected trigger, recipient and security rules.

Required templates include:

• Project assigned;
• Phase ready, blocked, completed or reopened;
• approval requested, overdue or decided;
• Provider Requirement ready for matching;
• Offer or Work Package received;
• Purchase Order acknowledged or changed;
• shipment delayed;
• Item received, damaged or missing;
• delivery scheduled, en route or completed;
• installation exception;
• Project Presentation shared or viewed;
• budget threshold or variance exceeded.

Automations are idempotent and auditable. External delivery failure never rolls back the domain event.

24. Permissions and Visibility

Permissions must cover actions and scopes for:

• Project identity and contact information;
• financial summary, internal cost, Client price, markup and margin;
• Items, Categories and imports;
• Provider identities, comparisons and contact details;
• Work Packages, commercial records and payments;
• Client-visible content;
• internal Notes and communication;
• phase advancement and Project closure;
• Presentation generation, approval, publishing and revocation.

Supabase Row Level Security enforces Workspace and Project boundaries beneath the interface.

25. Data Model

Minimum canonical tables or equivalent aggregates:

• projects
• project_template_versions
• project_phase_instances
• project_participants
• project_assignments
• project_access_grants
• project_spaces
• project_health_snapshots
• project_progress_snapshots
• project_provider_requirements
• work_packages
• project_items
• item_categories
• budget_categories
• project_budget_baselines
• project_budget_snapshots
• item_import_batches
• item_import_rows
• purchase_orders
• purchase_order_lines
• shipments
• shipment_items
• receiving_records
• storage_locations
• item_location_events
• delivery_manifests
• delivery_manifest_items
• installation_items
• project_approvals
• project_decisions
• project_vision_versions
• project_inspiration_assets
• project_presentations
• project_presentation_versions
• project_presentation_access
• project_activity_events

Every table carries appropriate Workspace ownership, Project reference, created/updated actor and timestamps. Versioned records are append-only after publication or approval.

26. API and Domain Events

Representative commands:

• POST /projects
• POST /project-opportunities/{id}/convert
• POST /projects/{id}/phases/{phase}/complete
• POST /projects/{id}/participants
• POST /projects/{id}/items/imports
• POST /projects/{id}/items
• POST /projects/{id}/budget-baselines
• POST /projects/{id}/provider-requirements
• POST /projects/{id}/work-packages
• POST /projects/{id}/purchase-orders
• POST /receiving-records
• POST /delivery-manifests
• POST /projects/{id}/presentations/generate-draft
• POST /project-presentations/{id}/publish

Representative events:

• ProjectCreated
• ProjectConverted
• ProjectPhaseCompleted
• ProjectPhaseReopened
• ProjectParticipantAdded
• ProjectItemImported
• BudgetBaselineApproved
• ProviderRequirementCreated
• WorkPackageIssued
• PurchaseOrderAcknowledged
• ShipmentDelayed
• ItemReceived
• ItemConditionFlagged
• ItemStorageLocationChanged
• DeliveryManifestReleased
• InstallationExceptionCreated
• ProjectPresentationPublished

Commands use idempotency keys. Events use an outbox or equivalent durable delivery pattern.

27. AI Requirements

AI may:

• improve Vision copy while preserving facts;
• suggest Template Tasks and Provider Requirements;
• map spreadsheet columns;
• normalize Categories and duplicate candidates;
• extract product, quote and Purchase Order data;
• summarize Project status and blockers;
• draft Presentation structure and copy;
• identify missing approvals, inconsistent dates and budget risks.

AI may not:

• approve Client decisions;
• award Provider work;
• publish a Presentation;
• invent price, stock, lead time, tracking or delivery status;
• expose hidden financial, Provider or Client data;
• mutate canonical records without review when confidence or impact is material.

Every AI output stores source references, model, prompt template version, actor, time and acceptance outcome where appropriate.

28. Migration Plan

Phase 0 — Inventory and terminology

• inventory current Project and Template records;
• replace Proper Gallery seed copy;
• map Partner roles to Project Participants or Provider Requirements;
• enforce Project Phase terminology;
• catalogue current planning budgets and Categories.

Phase 1 — Canonical Project foundation

• create Project, Template version, Phase instance, Participant and access models;
• migrate current Projects and preserve IDs/routes;
• link Client and Designer Entities;
• backfill Activity.

Phase 2 — Tasks, Calendar and Files

• connect existing Tasks and Files;
• generate Phase work from Templates;
• add Calendar projection and Milestones;
• preserve current links and history.

Phase 3 — Items and Budgets

• create canonical Items and Categories;
• add import staging and reconciliation;
• migrate spreadsheet-derived seed data;
• establish budget baselines and calculations.

Phase 4 — Provider Operations

• add Provider Requirements and Work Packages;
• connect Offers, Proposals, Work Orders and Assignments;
• add Purchase Order, shipment, receiving, storage, delivery and installation records.

Phase 5 — Client and Presentation

• connect approvals and Client Portal projections;
• build Presentation generation, sharing and PDF;
• add analytics and notification templates.

Migration uses dual-read validation before cutover and never deletes legacy source until reconciliation is complete.

29. Acceptance Criteria

29.1 Terminology

• All Project workflow UI uses Phase; all Pipeline workflow UI uses Stage.
• Provider is the general term; Vendor is used only for the product-supplier category.
• Partner role is removed from Project Builder.
• Project Record and Project Presentation are used consistently in UI, specs, exports and APIs.

29.2 Project foundation

• Direct creation and Project Opportunity conversion produce one canonical Project without duplicates.
• The Project references an immutable Template version and linked Client Entity.
• Every Phase transition validates structured requirements and writes Activity.
• Progress and health show calculation inputs and freshness.

29.3 Items and budgets

• Construction and Decorating Items share one service but expose correct category-specific fields.
• Shopping Lists display canonical Decorating Items.
• Budget Category totals reconcile to source Items and commercial records.
• Spreadsheet and Google Sheets imports support mapping, preview, errors, deduplication, provenance and idempotent retry.

29.4 Provider operations

• Provider Requirements create governed Work Packages.
• Provider Project Jobs expose only assigned scope.
• Purchase Order lines remain linked through shipment, receiving, storage, delivery and installation.
• Damage and discrepancies create evidence-backed exceptions and notifications.

29.5 Presentation

• AI-generated output remains Draft until human approval.
• Published versions are immutable and access-controlled.
• Hidden data is excluded by default and permissions are rechecked at publication and view time.
• Web and PDF outputs use the same approved content version.

29.6 Quality

• Desktop and mobile Provider workflows are usable.
• Empty, loading, partial, permission-redacted, stale, conflict and recoverable error states exist.
• Audit and Activity identify actor, Workspace, record, change, reason and time.
• Existing Project IDs, links, Tasks, Files and history survive migration.

30. Implementation Order

1. Terminology and legacy seed cleanup.
2. Canonical Project, Template version, Phase and Participant model.
3. Project shell corrections and Entity links.
4. Structured Project Builder and Phase requirements.
5. Tasks, Calendar, Files, approvals and decisions.
6. Spaces, Construction Items and Decorating Items.
7. Import and Budget engine.
8. Provider Requirements, Work Packages and assignments.
9. Purchase Orders, shipment, receiving and storage.
10. Delivery and installation.
11. Client Portal projections and Project Presentation Builder.
12. AI assistance, reporting, integrations and optimization.

The delivery principle remains: build once, reuse everywhere; preserve one canonical Project; make every participant’s view useful enough to maintain the shared record.

Live-product correction contract — Project Builder

The existing Project Builder must evolve as the versioned configuration surface for the same canonical Project service. It must not become a separate checklist product.

• Preserve the seven canonical Project Phases: Concept, Design, Design Package, Construction Administration, Decorating, Procurement and Installation.
• Configure tasks, milestones, dependencies, forms, deliverables, approvals, Item Category sets, Budget Categories, Provider Requirements, Calendar anchors, resources and completion evidence inside those Phases.
• Publish immutable Project Template versions. A Project retains its originating version and receives later changes only through an explicit, previewable upgrade.
• Let a Project override seeded work without breaking template lineage or changing other Projects.
• Validate duplicate milestones, circular dependencies, missing assignees, invalid Provider Categories, inaccessible forms and incomplete budget/item configuration before publish.
• Preview the generated Project for Registry, Designer Studio, Provider and Client audiences before activation.
• Register Task, milestone, approval, Provider Requirement and exception events with Notifications Builder.

<!-- CURRENT-PRODUCT-GAP-COVERAGE:START -->

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 07
Mapped current-product profiles: 7
Recorded review gaps: 33

This register is part of the release contract. It maps the current-product reverse review into required future behavior. A gap is not closed because a screen exists; closure requires the corrected canonical data, permissions, states, migration, audit and test evidence described below.

Register rules

1. Every profile in the Current Product Library must resolve to one owning future specification.
2. Current limitations are evidence, not optional ideas. If a limitation is intentionally retained, the specification must record the decision, risk, owner and review date.
3. Shared-component defects are corrected through Spec 16 and then consumed here; feature teams may not create local replacement controls.
4. Permission, contact, financial and visibility defects also require Spec 08 enforcement, even when the functional feature is owned by another specification.
5. Legacy Proper Gallery, Lead, Partner and implementation-facing labels are migration inputs only and must not return through new UI, APIs, exports or notifications.
6. Verification must use realistic fixtures for Admin, Designer, Provider and Client audiences where applicable.

G01 — Projects directory

Current-product profile: projects-directory
Observed route: /admin/projects
Evidence confidence: Verified

Review gaps

• Only two seeded Projects are represented.
• Phase and health values use lowercase display labels.
• Health reasons are absent from the directory.
• Export output, columns behavior and bulk selection actions were not exercised.
• Create Project duplicates a large amount of Project Opportunity information without an explicit conversion context.
• The observed Workspace still uses legacy Proper Gallery data.

Required future closure

• Adopt glossary-governed labels and title casing.
• Add saved views, filters, owners, Provider requirements, Client, template and date ranges.
• Expose health reasons and progress methodology.
• Use the same create command for direct creation and idempotent Project Opportunity conversion.
• Add empty, partial, permission-redacted and recoverable error states.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G02 — Project profile

Current-product profile: project-profile
Observed route: /admin/projects/:slug
Evidence confidence: Verified

Review gaps

• The profile lacks first-class Tasks, Calendar, Items & Budgets, Provider Operations, Proposals/Work Orders/Invoices and Presentation tabs.
• View tasks, View approvals and Manage spaces read like destinations but no working destination was verified.
• Client/household and location are editable plain text in the core edit form.
• Progress, health and phase-advance calculation are not explained.
• Project Communication is only readiness copy, not a working inbox.
• The phrase Premium project book is decorative and not glossary-governed.

Required future closure

• Build the Project workspace defined in Spec 07 around permission-aware modules.
• Link Client and participant Entities instead of copying names.
• Add phase validation, transition blockers, explanation and rollback governance.
• Connect Tasks, Calendar, Items, Budgets, commercial work and Provider Work Packages.
• Use Project Presentation for the client-facing authored output; do not overload Project Book as a data type.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G03 — Project Vision & Inspiration

Current-product profile: project-vision-and-inspiration
Observed route: /admin/projects/:slug
Evidence confidence: Partially verified

Review gaps

• The current Project is empty despite stated carry-forward behavior.
• No version, approval, image metadata, reordering or removal behavior was observed.
• AI loading, comparison, acceptance and failure states are not documented in the live UI.
• No direct Present or Add to Presentation action exists.

Required future closure

• Create versioned Vision and Inspiration records.
• Preserve Opportunity provenance during conversion.
• Add reorder, caption, rights, accessibility and Client-visibility controls.
• Connect directly to Project Presentation sections and PDF output.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G04 — Seven-phase Project process

Current-product profile: seven-stage-project-process
Observed route: /admin/projects/:slug?tab=process
Evidence confidence: Verified

Review gaps

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

Required future closure

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

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G05 — Project Items & Budgets

Current-product profile: project-items-and-budgets
Observed route: /admin/projects/:slug
Evidence confidence: Known limitation

Review gaps

• No operational Item or Budget module exists.
• Construction and Decorating category semantics are mixed.
• Categories have no type, parent, budget behavior, required fields or lifecycle configuration.
• The template claims Projects may add categories but no Project-level category action was found.
• No import, AI product extraction, URL ingestion or Purchase Order parsing exists.
• No receiving, storage, delivery or installation connection exists.

Required future closure

• Build typed Item and Budget workspaces in Spec 07.
• Add spreadsheet and Google Sheets import with field mapping.
• Support AI-assisted URL, quote and Purchase Order extraction with confirmation.
• Connect Items to Provider Work Packages and the full procurement chain.
• Expose Category budgets and Item pricing in one explainable financial model.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G06 — Project Presentation Builder

Current-product profile: project-presentations
Observed route: /admin/projects/:slug
Evidence confidence: Known limitation

Review gaps

• No current implementation exists.
• No template, prompt, data-selection, section, approval, sharing, PDF or analytics behavior is available.
• Current Vision content is empty for the reviewed Project.

Required future closure

• Implement the Project Presentation Builder in Spec 07.
• Provide source-aware AI generation and section-level regeneration.
• Add safe Client preview, approval and access-controlled sharing.
• Support stable PDF rendering, version history, revocation and audit.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

G07 — Project Builder

Current-product profile: project-builder
Observed route: /admin/settings/projects
Evidence confidence: Partially verified

Review gaps

• Complete live builder anatomy was not re-exercised in this Settings pass.
• Advanced operational primitives are not evidenced.

Required future closure

• Apply Spec 07 correction contract.
• Add validation, preview and impact analysis.
• Preserve the seven-Phase process while allowing optional work within Phases.

Closure evidence required

• The corrected behavior is demonstrated in the relevant loading, empty, populated, error, permission and responsive states.
• Server-side rules, data migration and audit behavior are verified where this feature changes canonical records.
• Automated tests cover the identified defect or missing journey so it cannot silently regress.
• Product, Engineering and the operating owner accept any deliberately deferred item with an owner and target phase.

<!-- CURRENT-PRODUCT-GAP-COVERAGE:END -->