The Design Registry

12 — Tasks, Calendar, Resource Scheduling & Project Time Tracking

Version: 1.0
Prepared: August 2026
Status: Engineering and product source of truth
Depends on: Product Vision; Spec 03 Teammates, Teams, Role Labels & Notifications; Spec 04 Workspace Dashboard & Profiles; Spec 05 Provider Applications; Spec 06 Proposals, Work Orders, Invoicing & Payments; Spec 07 Projects, Calendar, Items, Budgets & Provider Operations; Spec 08 Permissions; Spec 09 Pipeline, Forms & Automation Builder; Spec 10 Matchmaking, Offers & Network Assignment Engine; Spec 11 Communications, Unified Inbox & Client Collaboration

1. Executive Summary

The Design Registry already contains the visible foundation of a useful task system: a global Tasks navigation item, record-level Tasks tabs, an enterprise task grid, and a create-task form supporting title, description, type, state, priority, owner, collaborators, due date and a linked record. This specification upgrades that existing tool into the shared work-management and scheduling system for the entire platform.

The finished module must answer three different operational questions without confusing them:

1. What work must be completed? — Tasks, checklists, dependencies, milestones, approvals and completion evidence.
2. When will work or an appointment occur? — Calendar events, deadlines, meetings, site visits, deliveries, installations and recurring schedules.
3. Who or what has capacity to perform it? — People, teams, provider crews, vehicles, rooms, receiving docks, equipment, fabrication capacity and storage capacity.

The system must work across Registry administrators, independent design studios, clients and every approved provider type. It must also fit the platform’s core architecture: build once, reuse everywhere. A Project Opportunity, Project, Provider Job, Work Order, client record or internal workspace must not implement its own incompatible task or calendar feature. Each surface is a permission-filtered view of the same canonical services.

Projects remain the operational centre. Project Templates create the initial Tasks, Milestones and events for the seven-Phase process—Concept, Design, Design Package, Construction Administration, Decorating, Procurement and Installation—while allowing Phases to overlap. Provider Offers and Work Orders then create or reserve the Provider work required by those Projects. The same schedule supplies workload views, resource availability, Matchmaking capacity signals, Provider dashboards, Client appointments and operational reporting.

This is an upgrade, not a replacement. Existing tasks and UI patterns must migrate in place with no loss of history, links or ownership.

2. Product Outcomes

The module succeeds when it:

• gives every user one dependable place to understand what is due, blocked, waiting and next;
• turns Project Templates into executable schedules rather than static checklists;
• lets designers coordinate clients and providers without rebuilding schedules in spreadsheets;
• lets providers operate inside The Design Registry because the schedule is useful to their real workflow;
• prevents double-booking of exclusive people, crews, vehicles, rooms and appointments;
• connects offers, Work Orders, items, shipments, receiving, delivery and installation to the same Project timeline;
• provides controlled capacity signals to matchmaking without exposing private schedule details;
• makes client-visible appointments and decisions clear while protecting internal tasks and provider economics;
• preserves a complete, searchable audit history;
• supports future Google Calendar synchronization without making Google the system of record;
• scales from a single designer to multi-team, multi-provider and multi-market operations.

2.1 Success measures

• At least 90% of active Projects have an owner and due date on every actionable task.
• At least 80% of active Projects use a Project Template-generated schedule.
• Fewer than 2% of confirmed bookings result in unresolved resource conflicts.
• At least 75% of accepted provider Work Orders are actively updated through provider task or schedule views.
• Overdue, blocked and waiting work is visible without opening each Project.
• Project schedule changes produce an impact preview before downstream dates are changed.
• Matchmaking can distinguish available, constrained and unavailable providers from governed capacity data.

3. Scope

3.1 In scope

• Existing Tasks page, task grid and task form enhancement.
• Tasks, subtasks/checklists, dependencies, recurring tasks and completion evidence.
• Milestones and phase gates.
• Global and record-level calendar experiences.
• Project timeline and Gantt-style planning.
• Workload and resource scheduling.
• Resource availability, holds, bookings, conflicts and capacity pools.
• Project Template scheduling rules and versioning.
• Provider-specific schedules and operational projections.
• Time tracking foundation required by future billing and profitability.
• Notifications and reminders through the Notification Builder.
• Activity, audit, reporting, permissions and AI assistance.
• Migration of current task data.
• Stable contracts for future calendar and communications integrations.

3.2 Out of scope for this specification

• The detailed Google Calendar OAuth and two-way synchronization implementation.
• GPS vendor selection and map-routing algorithms.
• Payroll, employee scheduling compliance and time-off administration.
• Full accounting, invoicing and payment settlement rules, owned by Spec 06.
• The content of role templates, owned by Spec 08.
• General messaging transport, calling and email ingestion, owned by Spec 11.

Out-of-scope integrations may consume the APIs and events defined here. Their absence must not prevent the native task and calendar experience from working.

3.3 Current product correction contract

The August 4, 2026 live review confirms a useful Tasks directory with two seeded Tasks, Open/In progress/Blocked/Overdue metrics, State/Priority/Owner filters, row selection, bulk State change, sorting, export and configurable columns. The following corrections are required before the current tool can be treated as a safe canonical Task system:

• Edit Task is a release blocker: selecting Edit currently opens a blank/default Create task form instead of loading the selected Task identity and values. Edit must use an explicit update command, show the Task ID/current version and prevent accidental duplicate creation.
• Owner identity must reconcile: the grid displays Demo Administrator while the editor defaults to Brad Mitchell. Grid, form, export, Activity and notifications must resolve one Membership-backed identity for the same saved Owner.
• Task Links must expand: the current Designer, Project and Project Opportunity choices do not support Clients, Providers, Applications, Project Phases, Provider Jobs, Work Orders, Items, commercial records or other required contexts.
• Task Profile is missing: Task titles are not links and no detail, comments, checklist, dependency, recurrence, evidence, Calendar, Time Entry or Task Activity view exists.
• Closed control must be clear: replace the ambiguous Closed checkbox with an explicit Include closed control or a governed saved view.
• Dates must use the shared date system: directory values, forms, exports and notifications use locale-aware display while preserving canonical date/time and time-zone semantics.

Existing Task IDs and Activity must be preserved through correction. No migration may interpret the broken Edit modal’s defaults as the saved record.

4. Guiding Principles

4.1 Build once, reuse everywhere

Tasks, milestones, events and resource bookings are shared platform services. Interfaces may add role-specific cards or filtered views, but must not fork the model.

4.2 Projects connect the network

Most cross-workspace work must link to a Project and, where relevant, a Project phase, Work Package, Offer, Work Order, item, shipment or appointment.

4.3 One accountable owner

Every actionable task has one accountable owner. Any number of collaborators, followers or assigned teams may assist. A group cannot replace accountability.

4.4 Work is not time, and time is not capacity

A task can exist without a calendar event. A calendar event can exist without a task. A booking reserves a resource. The UI may connect these records, but the database must preserve their meanings.

4.5 Human-approved commitments

AI and automations may suggest dates, create drafts and identify conflicts. They may not silently confirm client appointments, award provider capacity, move critical milestones or reschedule other work.

4.6 Permission and visibility by default

Internal tasks remain internal. Client and provider visibility is explicit. Record access does not automatically expose private contact, financial, schedule-detail or communication fields.

4.7 History is durable

Changes to assignee, due date, dependency, booking, visibility and completion evidence are auditable. Completed recurring instances and historical schedules are never rewritten.

4.8 Time-zone correctness

Timed events store UTC instants and their intended time zone. All-day dates remain dates. Users see local time with a visible time zone when participants span zones.

5. Canonical Definitions

5.1 Task

A unit of work with an expected outcome. It may have an owner, collaborators, dates, priority, checklist, dependencies, context and evidence.

5.2 Checklist item

A lightweight completion step inside a task. A checklist item does not independently own scheduling, resource booking or cross-record permissions. If it needs those properties, it must be promoted to a task.

5.3 Milestone

A meaningful outcome or control point such as “Concept approved,” “Millwork drawings approved,” “All procurement released” or “Installation complete.” A milestone may require tasks, approvals, files, payments or evidence.

5.4 Calendar event

A dated or timed occurrence such as a meeting, site measure, presentation, receiving appointment, delivery or installation window. It may link to tasks and operational records.

5.5 Resource

A schedulable person, team, crew, vehicle, room, facility, dock, equipment asset or capacity pool.

5.6 Resource booking

A proposed, held or confirmed allocation of one or more resources for a time range or capacity period.

5.7 Availability

The working hours, exceptions, declared capacity and eligible time during which a resource may be booked. Availability is not itself a commitment.

5.8 Decision and approval

A governed response with an accountable decision-maker, choices, due date and outcome. It may block a task or milestone, but must not be reduced to a checkbox.

5.9 Exception or issue

A structured operational problem such as damage, missing item, failed delivery or blocked site access. It may generate remediation tasks and affect the schedule.

5.10 Provider Job and Work Order

A Provider Job is the provider’s operational view of Project scope. A Work Order is the authorized commercial instruction. Both may generate tasks, events and resource commitments, but neither is replaced by them.

6. Information Architecture

6.1 Global navigation

The existing Tasks item remains. Add Calendar as a first-class navigation item for users with calendar access.

• Tasks: My Work, Workspace Work, Waiting On, Exceptions, completed work and saved views.
• Calendar: Agenda, Day, Week, Month, Project Timeline, Workload and Resource Schedule.
• Resource Schedule appears as an authorized Calendar view, not a universal separate navigation item.

Mobile navigation may place Calendar under More, but today’s agenda and urgent tasks must remain accessible from the dashboard.

6.2 Record-level navigation

Reuse Tasks and Calendar tabs on:

• Project Opportunities;
• Projects;
• client records when the client has shared appointments or actions;
• designer studio and provider workspace profiles for authorized internal users;
• Offers, Provider Jobs and Work Orders;
• application records where review tasks and interviews are scheduled;
• general pipeline records when enabled by the Pipeline Builder.

Each tab must be a scoped view of the same canonical data, not embedded duplicate records.

6.3 Dashboard surfaces

Dashboards consume shared widgets:

• My Work;
• Today and upcoming;
• Waiting on others;
• overdue and blocked;
• workload/capacity;
• client appointments;
• provider operational schedule;
• schedule exceptions;
• recent changes.

7. Existing Tasks Tool: Required Upgrade

7.1 Preserve

Preserve the current enterprise grid, Add Task action, filter/sort/export/column controls, row selection, task detail route, record-level Tasks tab and create-task modal. Preserve existing fields and task links.

7.2 Extend the grid

Available columns must include:

• task, type, state, priority;
• owner, collaborators and assigned team;
• Project, phase, Work Package and linked record;
• start, due, completed and duration;
• milestone and dependency state;
• waiting on, blocked reason and age;
• client/provider visibility;
• estimated and actual hours;
• recurrence;
• evidence status;
• source: manual, template, automation, communication, Work Order or AI draft;
• last updated and updated by.

Users can save private or shared views. Shared views require permission. Export obeys field-level access and must never reveal masked contacts or financial data.

7.3 Views

• Table for enterprise operations.
• Board grouped by state, phase, owner or priority.
• My Work grouped into Today, Upcoming, Waiting, Blocked and Overdue.
• Timeline for dated tasks and dependencies.
• Completed with immutable completion history.

Drag-and-drop state changes must validate required fields, dependencies, permissions and completion rules before committing.

7.4 Quick create and full create

The default modal remains fast. It asks for title, owner, due date, priority and linked context. An Add details action expands the form into:

1. Core details;
2. Assignment;
3. Schedule;
4. Project and record context;
5. Dependencies and milestone;
6. Checklist;
7. Completion evidence;
8. Visibility and notifications;
9. Time estimate and billing classification.

The form must use the platform’s standardized dropdowns, currency/number formatting, address controls and date/time pickers. Searchable options are alphabetized unless operational ranking is intentional.

8. Task Model and Behaviour

8.1 Required fields

• workspace;
• title;
• system state;
• display type;
• accountable owner or valid unassigned queue;
• visibility classification;
• source and source version;
• created/updated metadata.

8.2 System states

Stable internal states are:

• backlog;
• ready;
• in_progress;
• blocked;
• waiting;
• review;
• complete;
• cancelled.

Workspaces may customize labels and colours, but not the underlying meaning. Existing Open tasks migrate to ready and may display “Open” until the workspace changes the label.

8.3 State rules

• Blocked requires a blocker link or explanation.
• Waiting requires a person, workspace, decision, delivery, payment or other awaited condition where possible.
• Review requires a reviewer or governed approval link.
• Complete validates required checklist items, evidence and dependencies.
• Cancelled requires a reason and cannot be silently deleted.
• Reopening preserves prior completion history.

8.4 Ownership and collaboration

A task has one owner, optional assigned team, collaborators, followers and external participants. Assignment must verify that the user or queue can access the linked Project/Job. Cross-workspace assignments are allowed only through an active Project, Offer, Work Order or approved collaboration relationship.

8.5 Dates

Support:

• no date;
• start date;
• due date;
• start/end date-time;
• duration;
• all-day;
• hard deadline versus target date;
• flexible scheduling window;
• relative template date;
• actual started/completed time.

8.6 Completion evidence

Templates and task types may require one or more of:

• checklist completion;
• file or image upload;
• client/provider approval;
• signature;
• numeric measurement;
• note;
• geotag/time stamp where legally and operationally appropriate;
• linked operational event such as item receipt or delivery proof.

Evidence is versioned and retained according to workspace policy.

8.7 Comments, mentions and source links

Task discussion uses the shared communication composer and supports mentions, files and internal/external visibility. A task created from email, chat or call keeps a source link and excerpt permitted by access rules.

9. Checklists, Dependencies and Critical Path

9.1 Checklists

Checklist templates can be reused. Items can be reordered, required, assigned to the task owner or marked not applicable with a reason. Checklist completion contributes to task progress but does not create independent resource demand.

9.2 Dependencies

Support:

• finish-to-start;
• start-to-start;
• finish-to-finish;
• start-to-finish for advanced use;
• positive or negative lag;
• a simple “blocked by” interaction for non-planners.

The system must prevent circular dependencies and explain the cycle before save. Cross-Project dependencies require explicit access and are visually distinguished.

9.3 Schedule propagation

When a predecessor moves, the platform calculates affected tasks, milestones, events, bookings, client commitments and provider Work Orders. It shows a change set with:

• original and proposed dates;
• hard versus flexible commitments;
• resource conflicts;
• affected people/workspaces;
• notifications that will be sent;
• items that cannot move automatically.

The user may apply all, apply selected safe changes or keep dates and create exceptions. Confirmed client/provider appointments are never silently moved.

9.4 Critical path and risk

For sufficiently scheduled Projects, calculate the critical path, slack, overdue dependencies and milestone risk. The calculation is advisory and records its inputs and timestamp.

10. Recurring Work

Recurring work is defined by a recurrence template and generated as dated task instances. Supported patterns include daily, weekday, weekly, monthly, annual and custom interval rules with end conditions.

• Instances are generated within a controlled future horizon.
• Completed and historical instances never change when the rule changes.
• Editing offers: this instance, this and future, or recurrence rule.
• Skipped occurrences record a reason.
• Ownership can resolve by user, role label, team, Project role or provider assignment.
• Failed generation is retried idempotently and surfaced to administrators.

Examples include weekly client updates, monthly storage inventory checks, pre-install confirmations and post-delivery follow-ups.

11. Milestones and Phase Gates

Milestones have title, phase, target date, owner, state, visibility and completion requirements. Requirements may reference tasks, approvals, files, invoices/payments, item states, Work Order states or evidence.

Milestone states are upcoming, at risk, blocked, achieved, waived and cancelled. Waiver requires permission, reason and audit entry.

Project phase movement may be automatic when configured, but only when all hard gate requirements are satisfied. Overlapping phases are allowed: a Project can begin Procurement for approved rooms while Design continues elsewhere. The UI must show progress by phase without pretending the seven stages are mutually exclusive tabs.

12. Calendar Experience

12.1 Views

• Agenda;
• Day;
• Week;
• Month;
• Project Timeline;
• Resource Schedule;
• Workload;
• provider dispatch/appointment view where applicable;
• mobile Today and route/agenda projections.

12.2 Calendar sources

The native calendar projects:

• task dates and deadlines;
• milestones;
• meetings and calls;
• client presentations and approvals;
• site visits and measurements;
• provider appointments;
• construction activities and inspections;
• expected shipment and arrival dates;
• receiving appointments;
• storage release and pickup;
• delivery and installation windows;
• photography shoots;
• payment and contract dates where permitted;
• workspace events and blackouts.

Users can filter by Project, phase, workspace, provider type, record type, owner, participant, resource, event type and visibility.

12.3 Event form

Fields include:

• title and event type;
• Project, phase and linked records;
• start/end, all-day and time zone;
• location, address, room or virtual link;
• organizer and participants;
• required resources;
• appointment window and arrival instructions;
• client/provider/internal visibility;
• recurrence;
• reminders;
• linked task, milestone, Work Order, items or shipment;
• status and completion/cancellation evidence;
• external-sync state reserved for future integration.

12.4 Event status

Draft, proposed, tentative, confirmed, in progress, completed, cancelled and no-show. Proposed times do not reserve exclusive capacity unless a hold is created.

12.5 Scheduling assistant

The assistant finds candidate slots using participant availability, resource requirements, duration, working hours, time zones, dependencies, service area, travel buffers, skills and capacity. The user chooses and confirms the slot.

12.6 Invitations and responses

Internal users, clients and providers may receive invitations through their app and configured notification channels. Response states are needs action, accepted, tentative and declined. A decline may request alternatives and create a scheduling exception.

13. Resource Scheduling Model

13.1 Resource types

• individual users;
• teams;
• provider crews;
• vehicles;
• rooms, showrooms and meeting spaces;
• facilities and receiving docks;
• tools and equipment;
• production lines or fabrication capacity;
• storage capacity pools;
• configurable workspace-specific resources.

13.2 Named resources versus capacity pools

A named resource is booked for a time range, such as Crew A or Vehicle 12. A capacity pool is consumed by quantity over a period, such as 1,200 square feet of storage or 40 fabrication hours. The system must support both without modeling square footage as a fake person.

13.3 Resource profile

Each resource may define:

• owning workspace;
• type and status;
• display name and private operational identifier;
• service area/location;
• skills, specialties and credentials;
• working calendar;
• maximum concurrent bookings;
• turnaround and travel buffers;
• capacity unit and quantity;
• eligible event/Work Order types;
• maintenance/blackout periods;
• visibility rules.

13.4 Availability

Availability combines recurring working patterns, holidays, time off, maintenance, declared provider capacity, external busy/free projections and existing bookings. Schedule detail remains private: matchmaking and other workspaces receive governed availability signals, not event names or client identities.

13.5 Booking lifecycle

• proposed — planning only, no capacity reserved;
• soft_hold — capacity temporarily reserved with expiry;
• confirmed — committed;
• in_progress;
• completed;
• cancelled;
• no_show.

Shortlisting a provider does not reserve capacity. A confirmed Offer may create a soft hold. Awarding a Work Order converts valid holds into commitments. Expired holds release capacity automatically and trigger configured notifications.

13.6 Conflict policy

Resources can be exclusive, limited-concurrency or informational. Exclusive confirmed bookings cannot overlap. Authorized dispatchers may override a warning only where policy permits, with a reason. Capacity pools reject commitments that exceed quantity unless controlled overbooking is enabled.

14. Workload and Capacity Views

14.1 People workload

Display estimated task effort, scheduled time, capacity, overdue work and allocation by day/week/month. Do not infer that every due-date task consumes the entire day. Users may compare effort against working hours.

14.2 Provider capacity

Providers can publish simple availability or operate detailed resources. Their workspace sees operational detail; designers and Registry staff see only information allowed by the provider relationship and Offer/Job access.

14.3 Planner interaction

Planners can drag tentative work, request a provider time, assign eligible resources and preview conflicts. Moving a confirmed booking opens a reschedule workflow, captures the reason and notifies affected parties.

14.4 Matchmaking projection

The Matchmaking Engine consumes controlled signals:

• earliest eligible start;
• availability band;
• declared capacity;
• confirmed utilization;
• service-area fit;
• skill/resource fit;
• confidence and freshness.

It must never inspect private event content. Resource scheduling is the canonical source of commitments; matchmaking stores scored snapshots and provenance.

15. Seven-Phase Project Scheduling

Every Project task, milestone and event may belong to one of the seven stages while stages remain overlap-capable.

15.1 Concept

Brief, discovery, measurements, inspiration, feasibility, initial budget, client decisions and concept presentation.

15.2 Design

Space planning, selections, iterations, consultant coordination, client reviews and approval dependencies.

15.3 Design Package

Drawings, schedules, specifications, pricing package, document issue and final approvals.

15.4 Construction Administration

Site meetings, contractor/trade coordination, materials, submittals, inspections, RFIs, change decisions and deficiencies.

15.5 Decorating

Room/category planning, decorative item selection, client approvals, styling, photography preparation and budget checks.

15.6 Procurement

Quotes, purchase orders, deposits, vendor acknowledgements, expected arrival, shipment, receiving, damage resolution, storage and release readiness.

15.7 Installation

Site readiness, delivery routes, crews, vehicles, item allocation, installation windows, punch list, completion evidence and photography.

The Project profile shows a meaningful timeline, current milestones, critical risks, next actions and upcoming appointments. Decorative process tabs must not replace useful task and schedule views.

16. Project Builder 2.0 Requirements

The existing Project Builder in Settings must become the authoring environment for executable Project Templates.

16.1 Template sections

• Project metadata and applicability;
• seven-Phase configuration;
• Task Library and task instances;
• milestones and gates;
• calendar events and appointment rules;
• resource requirements;
• dependencies;
• relative schedule anchors;
• automations and notifications;
• client/provider visibility;
• completion evidence;
• versioning and migration.

16.2 Relative scheduling

Dates may anchor to Project start, contract date, phase start, milestone, client approval, purchase order, expected arrival, Work Order or installation date. Rules support offsets, working days, time windows and fallback behaviour.

16.3 Owner resolution

Templates assign by Project role, workspace role label, team, provider Job role or named queue—not hard-coded user unless explicitly intended.

16.4 Validation and preview

Before publishing, validate missing owners, invalid offsets, cycles, unreachable milestones, resource types, notification templates and access conflicts. Preview a sample calendar and critical path.

16.5 Instantiation

Project creation instantiates tasks, dependencies, milestones, events and draft resource requirements idempotently. Re-running provisioning must not create duplicates.

16.6 Template versions

Published versions are immutable. New Projects use the active version. Updating an active Project requires a migration preview identifying additions, removals, changed dates, owner changes and conflicts. Historical completion is preserved.

17. Provider-Specific Operations

All providers receive the shared Tasks and Calendar functions. Their portal adds service-specific views and resources.

17.1 Vendors and product suppliers

Track quote follow-ups, acknowledgements, production milestones, expected ship/arrival dates, samples, replacements and representative appointments. Product/item records remain canonical; schedule projections link to them.

17.2 Photographers

Schedule scouting, shoot date, crew, equipment, rooms, shot list, editing tasks and delivery milestone. Completion evidence may include contact sheets or delivered gallery link.

17.3 Contractors and trades

Schedule crews, site access, shifts, inspections, dependencies, materials readiness, RFIs and deficiencies. Work Order scope remains authoritative.

17.4 Millwork providers

Schedule measure, shop drawings, approvals, fabrication capacity, finishing, delivery and installation resources. Client/design approval can block production.

17.5 Storage providers

Schedule receiving docks and staff; receive items against purchase orders/shipments; inspect, photograph and flag condition; allocate storage capacity; schedule release and pickup. Damage creates an exception and linked remediation tasks.

17.6 White-glove delivery providers

Schedule pickup/delivery windows, vehicles, crews, routes and item manifests. Surface planned/en route/arrived/completed status to permitted participants. Live tracking is a specialized projection; the confirmed booking remains the schedule commitment.

17.7 Installers

Schedule crews by skill, room and item requirement; track site readiness, installation sequence, punch items and completion evidence.

17.8 Configurable provider types

Administrators can define additional provider types, resource types, task templates and event types without changing the core engine.

18. Client Experience

Clients see only explicitly shared appointments, milestones, decisions, approvals and actions. They do not see internal assignees, provider cost, referral economics, private notes, workload or resource identifiers.

Client functions include:

• accept, tentatively accept or decline appointment;
• request alternative times;
• add an appointment to an external calendar through a standard calendar file/link;
• receive reminders;
• complete assigned client actions;
• upload requested material;
• view approved Project milestones;
• receive reschedule/cancellation explanations.

A client action may be represented as a shared task only when appropriate. Formal approval remains a decision record.

19. Project Time Tracking and Hours

Time tracking is a core Project function, not only a future billing foundation. The platform must calculate how many hours each person has spent on a Project and compare actual effort with the Project, phase and task estimates.

19.1 Time entry identity and context

Every time entry must reference exactly one user. A team, role label or task owner cannot replace the user who performed the work. The entry must also reference one workspace and one Project. It may additionally reference:

• task or milestone;
• one of the seven Project phases;
• room or area;
• Work Package;
• Provider Job or Work Order;
• client-facing service or internal activity category;
• communication, appointment or source record.

Required fields are user, Project, work date, duration, description, classification, entry source and audit metadata. Optional start/end times support detailed timesheets, but Project hour totals use stored duration in minutes to avoid rounding errors.

19.2 Ways to track time

• Start a timer from a Project, task, appointment or Provider Job.
• Add a manual duration after the work is completed.
• Enter start and end times on a daily or weekly timesheet.
• Duplicate a previous entry when permitted.
• Create an AI-drafted entry from a call, calendar event or activity for the user to confirm.
• Import approved historical time during migration with source provenance.

A user may have only one running timer by default. Starting another timer prompts the user to stop or discard the first. Workspace policy may permit parallel timers only for exceptional operational cases.

19.3 Project Time & Hours view

Every Project includes a permission-controlled Time & Hours tab and an Overview summary card. The tab provides:

• total tracked hours;
• estimated versus actual hours and remaining estimate;
• hours by user;
• hours by phase, task, Work Package and Provider Job;
• billable, non-billable and internal hours;
• submitted, approved, rejected, locked and uninvoiced hours;
• day, week, month and custom-date trends;
• entries missing task/phase detail;
• table with user, date, description, duration, context, status and actions;
• filters, saved views and permission-safe export.

Project totals must be computed from canonical time entries rather than manually editable summary fields. A user profile and workspace report can show the same hours grouped across Projects.

19.4 Estimates and capacity

Projects, phases, Work Packages and tasks may hold estimated hours. Estimates can originate from the Project Template and be revised through versioned forecast adjustments. The system reports original estimate, current estimate, actual approved hours, actual unapproved hours and estimate at completion.

Actual time informs workload and future estimating but does not automatically alter resource availability or Project price. An authorized user must approve forecast changes.

19.5 Classification and rates

Time can be billable, non-billable, included in fixed fee, internal or not yet classified. Activity categories are workspace-configurable with stable reporting codes. Rate source and calculated value are separate protected financial fields; users may be allowed to enter hours without seeing rates or revenue.

19.6 Review, locking and correction

• Draft entries remain editable by their user within workspace policy.
• Submitted entries are routed to an authorized approver.
• Approved entries contribute to approved-hour and invoice-eligible totals.
• Rejected entries return with a reason.
• Locked or invoiced entries cannot be overwritten.
• Corrections to locked time use an adjustment/reversal linked to the original entry.
• Administrators cannot silently attribute time to another user; proxy entry records both the performing user and entering user.

Approval is configurable. A workspace may use direct approval, weekly timesheets or automatic approval for trusted internal categories. Cross-workspace/provider entries obey the governing Work Order and access rules.

19.7 Timer resilience and controls

Running timers survive navigation and supported session changes. The platform warns about unusually long timers, overlapping detailed time ranges, future time and durations exceeding workspace limits. Offline field users may queue a completed manual entry; server confirmation is required before it contributes to approved totals.

19.8 Commercial handoff

Spec 06 may consume approved, invoice-eligible entries by Project, Work Order and billing period. This module owns the time record and approval history; it does not calculate payment settlement. Invoicing must store the exact included time-entry IDs so later Project reports can distinguish uninvoiced, invoiced, adjusted and written-off hours.

20. Notifications, Reminders and Escalations

Every new notification introduced here must register as an editable Notification Builder template, not hard-coded copy.

Required events include:

• task assigned, reassigned, due soon, overdue, blocked, unblocked, waiting too long, mentioned, completed, reopened or cancelled;
• checklist/evidence requirement failed;
• milestone at risk, achieved or waived;
• appointment proposed, confirmed, changed, declined, cancelled, starting soon or no-show;
• resource hold created, expiring, expired, confirmed or conflicted;
• schedule change requiring approval;
• dependency now ready or delayed;
• recurring generation failed;
• provider capacity request and response;
• time entry submitted, rejected or approved.

Templates support in-app and, when enabled, Resend email, Twilio SMS and communication-channel delivery. Users control preferences within policy; mandatory operational/security notifications cannot be disabled. Deduplication and digest rules prevent notification storms after schedule propagation.

21. Automations and Pipeline Integration

The Pipeline Builder and Project Builder may create/update tasks, milestones and draft events through versioned actions.

Triggers include record created, stage entered/exited, field changed, form submitted, Offer accepted, Work Order issued, item status changed, shipment received, exception raised, milestone achieved and scheduled time reached.

Actions include:

• create task from template;
• assign by role/queue;
• set relative due date;
• create proposed event;
• request resource hold;
• create reminder/escalation;
• update task state when a governed source record changes;
• notify participants.

Automations must be idempotent, show their source/version and avoid feedback loops. An automation may not bypass hard phase gates, resource conflicts or permissions.

22. Communications Integration Contract

Spec 11 can create a task, follow-up, appointment proposal or reminder from an email, message or call. The resulting record stores the communication reference and permitted excerpt. Communications can display linked work and schedule state without copying it.

Examples:

• an email asking for revised drawings creates a task linked to the thread and Project;
• a call transcript produces AI-drafted follow-ups for human confirmation;
• an email containing a proposed meeting time opens the scheduling assistant;
• a provider delay updates the shipment source record, which creates a schedule-impact preview.

23. AI Requirements

23.1 Permitted assistance

• draft task plans and checklists from a brief, Work Order or communication;
• suggest owners, durations and dependencies from templates/history;
• recommend available appointment slots;
• identify conflict, critical-path and workload risk;
• summarize today, this week or a Project schedule;
• extract tasks/dates from email, calls, documents and purchase orders;
• predict delay risk with visible factors and confidence;
• propose schedule recovery options;
• generate client/provider-friendly update drafts.

23.2 Guardrails

AI output is draft unless a user confirms it or an explicitly governed low-risk automation applies. AI cannot confirm a provider booking, expose private schedules, change a client commitment, mark evidence complete, approve time or waive a gate. Every accepted AI change records provenance.

24. Permissions and Visibility

Use Spec 08’s capability and field-access model. Required capability families include:

• tasks.view/create/edit/assign/complete/cancel/export/manage_types;
• milestones.view/create/edit/achieve/waive;
• calendar.view/create/edit/cancel/invite/export;
• resources.view/manage/declare_availability/book/override_conflict/view_utilization;
• time_entries.view/create/edit/approve/view_rates/invoice;
• templates.tasks.manage and templates.schedules.manage.

Access is additionally constrained by workspace, Project, Provider Job, Work Order and client relationship. Resource privacy supports detail, title-only and busy/free levels. Contact and financial fields remain independently protected.

25. Data Model

The production backend is Supabase/Postgres. Identifiers are UUIDs. Core records include workspace, created/updated metadata, soft-archive state where appropriate and audit correlation IDs.

25.1 Task tables

• task_types
• tasks
• task_assignments
• task_collaborators
• task_followers
• task_checklist_items
• task_dependencies
• task_recurrence_rules
• task_evidence
• task_record_links
• task_templates
• task_template_versions
• task_template_nodes

tasks stores system state separately from customizable display label. Links use typed association tables with referential validation; unconstrained polymorphic IDs are prohibited.

25.2 Milestone tables

• milestones
• milestone_requirements
• milestone_task_links
• milestone_history

25.3 Calendar tables

• calendar_events
• event_participants
• event_record_links
• event_recurrence_rules
• event_reminders
• event_responses

25.4 Resource tables

• resource_types
• resources
• resource_skills
• work_calendars
• availability_rules
• availability_exceptions
• capacity_pools
• capacity_periods
• resource_bookings
• booking_resources
• booking_holds
• booking_history

Use timestamp ranges for time-bound bookings. Database constraints prevent prohibited overlaps for exclusive confirmed resources. Capacity consumption is transactionally checked before commitment.

25.5 Time and scheduling operations

• time_entries
• time_entry_approvals
• time_entry_adjustments
• time_entry_categories
• project_time_estimates
• timesheet_periods
• schedule_change_sets
• schedule_change_items
• reminder_jobs
• scheduling_outbox
• scheduling_dead_letters

25.6 Projection ownership

Operational source records remain canonical: item receipt status belongs to inventory/receiving; shipment arrival belongs to shipment; payment date belongs to commercial records. Calendar projections reference those records and update through domain events rather than duplicating editable truth.

26. Supabase Architecture

• Postgres is the canonical state store.
• Row Level Security restricts rows by workspace, Project and Job relationship; explicit grants remain separately configured.
• Private Realtime channels may deliver authorized task, event and booking changes. Realtime is a transport, not the source of truth.
• Use a transactional outbox for domain events and notification work.
• Use a durable queue for recurrence generation, reminders, schedule recalculation and propagation fan-out.
• Use scheduled database jobs for periodic due scans, expired-hold release and reconciliation—not one scheduled database job per task or reminder.
• Store intended local time, IANA time zone and computed UTC time for scheduled automations.
• All workers use idempotency keys and bounded retries; exhausted jobs enter a dead-letter view.
• Do not update scheduler catalog tables directly; use documented scheduling functions and migrations.
• Queue delay semantics must not be the sole source of exact delivery timing; due records remain queryable and recoverable from Postgres.

27. API Design

27.1 Tasks

• GET /tasks
• POST /tasks
• GET /tasks/{id}
• PATCH /tasks/{id}
• POST /tasks/{id}/transition
• POST /tasks/{id}/assign
• POST /tasks/{id}/checklist
• POST /tasks/{id}/evidence
• POST /tasks/{id}/dependencies
• POST /tasks/{id}/complete

27.2 Calendar and scheduling

• GET /calendar/events
• POST /calendar/events
• PATCH /calendar/events/{id}
• POST /calendar/events/{id}/respond
• POST /calendar/suggest-slots
• POST /schedule/preview-change
• POST /schedule/apply-change-set

27.3 Resources

• GET /resources
• POST /resources
• GET /resources/availability
• POST /resource-holds
• POST /resource-bookings
• POST /resource-bookings/{id}/confirm
• POST /resource-bookings/{id}/reschedule
• POST /resource-bookings/{id}/cancel

27.4 Templates and time

• POST /task-templates
• POST /project-templates/{id}/schedule-preview
• POST /projects/{id}/instantiate-schedule
• POST /projects/{id}/template-migration-preview
• GET /time-entries
• POST /time-entries
• POST /time-entries/{id}/submit
• POST /time-entries/{id}/approve
• POST /time-entries/start-timer
• POST /time-entries/{id}/stop-timer
• POST /time-entries/{id}/adjust
• GET /projects/{id}/time-summary
• GET /users/{id}/timesheet

List endpoints use cursor pagination, stable sort, typed filters and field masking. Mutations accept idempotency keys and optimistic concurrency tokens. Errors return user-actionable conflict and validation details.

28. Domain Events

Publish versioned events including:

• task.created, task.assigned, task.state_changed, task.due_changed, task.completed, task.blocked;
• milestone.risk_changed, milestone.achieved, milestone.waived;
• calendar.event_proposed, calendar.event_confirmed, calendar.event_rescheduled, calendar.event_cancelled;
• resource.hold_created, resource.hold_expired, resource.booking_confirmed, resource.conflict_detected;
• schedule.change_set_created, schedule.change_set_applied;
• time_entry.submitted, time_entry.approved.

Events include actor, workspace, subject, Project/Job context, correlation ID, source version and safe summary. Consumers may not infer permission from event receipt.

29. Search, Filters and Reporting

Global search indexes permitted task titles, descriptions, Projects, linked records and owners. Saved filters support relative dates and operational states.

Reports include:

• completion and on-time rate;
• overdue aging;
• blocked/waiting reasons;
• milestone reliability;
• estimated versus actual effort;
• Project hours by user, phase, task, Work Package and Provider Job;
• billable/non-billable, approved/unapproved and invoiced/uninvoiced hours;
• workload/utilization;
• resource conflict and cancellation rate;
• provider response and schedule reliability;
• template performance;
• client appointment acceptance/no-show;
• schedule-change volume and causes.

Metrics distinguish targets, confirmed commitments and actuals. Reports are permission-filtered and state their time zone and as-of time.

30. Activity, Audit and Retention

Activity timelines show useful summaries. The audit log stores before/after values for sensitive changes, actor, impersonation context, automation/source, timestamp and correlation ID.

Audit events include assignment, state, dates, dependency, resource, visibility, evidence, recurrence, override, waiver, export and time approval. Deletion uses archive/cancellation according to record type. Legal and financial retention rules override workspace cleanup preferences.

31. Mobile and Offline Behaviour

Mobile prioritizes Today, next appointment, route/arrival actions, task update, checklist, photos/evidence, comments and exception reporting.

Authorized field users may cache assigned tasks and event details and queue safe updates offline. Sync is idempotent and shows conflicts. A device may not confirm or reschedule a shared exclusive resource while offline; it can submit a pending request for server validation.

32. Accessibility and Design System

• Meet WCAG 2.2 AA.
• All calendar actions have keyboard and list-view equivalents.
• Colour never communicates state alone.
• Drag-and-drop has accessible move controls.
• Focus returns correctly after modals and drawers.
• Date/time controls are labelled, locale-aware and screen-reader compatible.
• Dense planners support zoom without losing essential controls.
• Black-and-white brand styling remains elegant; state colours are restrained, accessible accents.
• Cards, grids, drawers, empty states, dropdowns, filters and date pickers reuse the existing design system.

33. Non-Functional Requirements

• Normal task list interactions should respond within 500 ms at p95 excluding network variance.
• Calendar range queries should render first useful content within 1.5 seconds at p95 for standard workspaces.
• Scheduling conflict checks must be transactional for confirmed bookings.
• All date mutation endpoints are idempotent and concurrency-safe.
• Realtime degradation must not prevent refresh or canonical reads.
• Reminder and recurrence workers are observable and recoverable.
• Availability queries cache safe projections without leaking private details.
• Large Projects support at least 10,000 tasks/events through pagination and virtualization.
• Audit and domain events remain complete under retry.

34. Migration Plan

Phase 1 — Inventory and compatibility

• inventory current tasks, states, owners, collaborators, dates and links;
• map current Open and completed values to stable system states;
• identify orphaned links and invalid users;
• add new nullable columns and association tables;
• create compatibility views/adapters for existing frontend calls.

Phase 2 — Backfill

• backfill workspace and record relationships;
• preserve original identifiers where safe;
• create audit baseline entries;
• validate counts, owners, dates and linked record routes;
• do not invent missing dates or completion evidence.

Phase 3 — Dual-read validation

• compare old and new task list/detail results;
• shadow conflict and due calculations;
• measure mismatches;
• migrate UI components behind feature flags.

Phase 4 — UI upgrade

• release enhanced task detail and views;
• add native Calendar;
• add record-level Calendar tabs;
• preserve current quick create;
• progressively enable dependencies, milestones and recurrence.

Phase 5 — Resource scheduling

• onboard internal people/teams;
• add provider resources and availability;
• enable holds and bookings by provider type;
• connect Work Orders and matchmaking capacity.

Phase 6 — Retirement

• stop writes to legacy task structures after reconciliation;
• retain read-only rollback capability for an agreed period;
• remove adapters only after audit sign-off.

No migration may delete task history or expose a task to a workspace that could not previously access its linked record.

35. Implementation Phases

35.1 Foundation

Canonical task model, existing UI compatibility, states, ownership, links, activity, permissions and Notification Builder events.

35.2 Task depth

Full task detail, checklists, evidence, dependencies, recurring tasks, saved views, comments and mobile updates.

35.3 Calendar

Global calendar, event model, invitations, record projections, Project timeline and appointment workflow.

35.4 Templates and milestones

Project Builder scheduling, milestones, gates, relative dates, versioning and schedule-change previews.

35.5 Resources

Resource directory, working calendars, availability, soft holds, commitments, conflict protection, workload and capacity.

35.6 Provider operations

Receiving, delivery, installation, photography, millwork, contractor/trade and vendor scheduling projections.

35.7 Intelligence and integrations

AI planning/risk, advanced reporting, external calendar synchronization and specialized routing/tracking integrations.

Each phase must include migration rehearsal, RLS tests, accessibility checks, notification validation, analytics and rollback controls.

36. User Stories

Designer

• As a designer, I can see every task and appointment across my Projects without opening them individually.
• As a Designer, I can create a Project from a Template and receive a realistic, editable seven-Phase schedule.
• As a designer, I can request a provider appointment without seeing the provider’s private calendar.
• As a designer, I can understand which procurement delay threatens installation.

Provider owner

• As a provider owner, I can define crews, vehicles, docks or capacity relevant to my service.
• As a provider owner, I can accept an Offer, confirm capacity and turn it into an operational schedule.
• As a provider owner, I can run my own business tasks while exposing only governed Project commitments.

Provider field user

• As a field user, I can see today’s assigned jobs, update status, take evidence photos and flag a problem from mobile.

Client

• As a client, I can see and respond to my appointments and actions without seeing internal work or provider economics.

Registry administrator

• As an administrator, I can monitor cross-network exceptions and workload without automatically gaining access to private workspace details.
• As an administrator, I can configure notification templates and Project schedule templates.

Operations planner

• As a planner, I can see resource conflicts, propose changes and understand downstream impact before committing them.

37. Acceptance Criteria

Existing tool continuity

• Existing tasks appear in the upgraded Tasks page with the same title, owner, collaborators, date, link and completion history.
• Current task URLs or supported redirects continue to work.
• Quick create remains available and uses the canonical model.

Task operations

• A task has one accountable owner and any number of collaborators.
• State transitions validate configured requirements.
• Required evidence prevents completion and explains what is missing.
• Circular dependencies cannot be saved.
• Recurrence changes do not rewrite completed instances.

Calendar

• Users can view agenda/day/week/month and filter by permitted context.
• Project tasks, milestones, appointments, shipments and provider events appear from canonical sources.
• All-day dates and timed events remain correct across time zones and daylight-saving changes.
• Client/provider reschedules require confirmation and audit history.

Resources

• Exclusive confirmed resources cannot be double-booked.
• Soft holds expire and release capacity.
• Capacity pools enforce configured quantities transactionally.
• Matchmaking can consume availability signals without private event detail.

Project Templates

• A published template creates tasks, dependencies, milestones and draft events exactly once.
• Invalid cycles, owners and anchors block publication.
• Template updates show a Project migration preview and preserve history.
• All seven Project Phases are supported and may overlap.

Provider operations

• Each named provider type can represent its relevant appointments/resources using shared components.
• Storage receiving can link appointments, items, condition evidence and exceptions.
• White-glove delivery can link vehicle, crew, route/manifest and delivery status.
• Work Order award can convert a valid hold to a confirmed booking.

Permissions and notifications

• RLS and application permissions prevent cross-workspace leakage.
• Busy/free access does not reveal private event content.
• Every listed notification is editable in the Notification Builder.
• Bulk exports and realtime updates obey field masking.

Reliability

• Jobs are idempotent and retryable.
• Failed reminder/recurrence jobs are visible and recoverable.
• Concurrent booking attempts cannot both confirm an exclusive resource.
• Audit entries exist for all sensitive schedule and ownership changes.

Project time tracking

• Every time entry references one performing user and one Project.
• A user can start/stop a timer or add a manual entry from an authorized Project or task.
• Project totals reconcile exactly to the permitted canonical entries in the selected date range.
• Authorized users can view hours by user, phase, task, Work Package and Provider Job.
• Estimates and actuals are shown separately; unapproved hours are not misrepresented as approved.
• Users can record hours without receiving permission to view protected rates or financial totals.
• Locked or invoiced entries can only be corrected through linked adjustments.
• Proxy entries identify both the performing user and the user who entered the time.

38. Release Readiness Checklist

• Product and engineering approve canonical boundaries.
• Current task migration reconciles counts and samples.
• Permissions matrix and RLS tests pass for admin, designer, client and every provider class.
• Notification templates exist with safe defaults.
• Time-zone and daylight-saving test suite passes.
• Dependency-cycle, recurrence and concurrency tests pass.
• Provider workflows are tested with realistic Projects, items and Work Orders.
• Accessibility review passes for grid, board, calendar, dialogs and drag alternatives.
• Observability dashboards and dead-letter runbooks exist.
• Support documentation explains Tasks versus Events versus Bookings.
• Feature flags and rollback path are confirmed.

39. Final Product Direction

The Design Registry must not become a collection of disconnected checklists and calendars. The existing Tasks tool should grow into a quiet, dependable operating layer connecting designers, clients and providers through Projects. Tasks describe accountable work. Calendars describe time. Resource schedules describe capacity and commitments. Templates provide repeatable process. Offers and Work Orders authorize provider participation. Items, shipments, receiving and delivery contribute operational truth.

When these boundaries are maintained and the same components are reused across every portal, the platform becomes more valuable to every participant: designers gain control without administrative overload, providers gain workflow software worth operating inside, clients receive a coordinated experience, and The Design Registry gains the reliable network data required for matchmaking, automation and AI assistance.

Live-product correction contract — Task Builder

The current Task Builder provides a useful Provider-onboarding template foundation but requires the following corrections:

1. Rename the Leads module to Project Opportunities or Pipeline Records.
2. Use one shared Task Type, State and Priority registry in the builder, Task form, directories, filters, exports, notifications and reports. Urgent currently exists in Task Builder but not in the Tasks directory Priority filter.
3. Alphabetize customer-configurable Type and assignment options while preserving stable keys.
4. Add start/due anchors, working-day calendars, duration, estimates, dependencies, checklists, recurrence, Phase placement, resources, capacity, completion evidence, visibility and escalation.
5. Add contexts for Offers, Work Packages, Work Orders, Provider Jobs, Items, receiving, delivery, installation, approvals and commercial work.
6. Generate canonical Tasks idempotently from stable Domain Events. Every generated Task records trigger event, Task Template version and assignment resolution.
7. Preview created Tasks and dependency graphs before enabling a template.
8. Do not allow Role Label assignment rules to bypass Access Roles or record scope.
9. Fix the separate live critical defect where editing a Task opens an empty Create Task form before expanding automation usage.
10. Resolve Task Owner display identity consistently across grids, forms, exports, Activity and reporting.

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

Current-product review gap closure register

Generated: August 4, 2026
Owning future specification: 12
Mapped current-product profiles: 5
Recorded review gaps: 20

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 — Record Tasks

Current-product profile: record-tasks
Observed route: /admin/leads/:id?tab=tasks
Evidence confidence: Verified

Review gaps

• No live populated record task was available.
• Subtasks, dependencies, recurrence, time tracking and resource scheduling are not shown here.
• Template instantiation and assignment fallbacks are unverified.
• Due-date timezone and reminder behavior are unverified.

Required future closure

• Unify record tasks with Project schedules, Calendar, resource planning and time tracking in Spec 12.
• Support dependencies, milestones and provider-facing task visibility.
• Keep templates configurable while preserving historical task instances.
• Add overdue, blocked and workload signals.

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 Calendar

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

Review gaps

• No current Calendar UI exists in the Project.
• No conflict, availability, recurrence, timezone, resource or external-sync behavior is visible.
• Installation Date is offered as a template anchor without an observed canonical Project field.

Required future closure

• Add Project Calendar and agenda surfaces from Spec 12.
• Make Phase targets, milestones and Provider appointments visible in context.
• Support resource and installation-day coordination.
• Add permission-scoped external synchronization with clear source and sync health.

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 — Tasks directory

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

Review gaps

• No Task detail route or history.
• Only seeded Tasks are visible.
• No saved views, Team filter, Project/Phase filter, dependency, checklist, recurrence, evidence, time or calendar columns.
• The Closed checkbox label is ambiguous.
• Owner identity conflicts with the editor default.

Required future closure

• Add My Work, Workspace Work, Waiting On, Exceptions and saved views.
• Open a canonical Task Profile rather than only an editor modal.
• Connect Tasks to Calendar, resources, dependencies, evidence and Time Entries.
• Add permission-safe role-specific views for Designers, Providers and Registry operators.

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 — Create and edit Task

Current-product profile: create-and-edit-task
Observed route: /admin/tasks
Evidence confidence: Verified

Review gaps

• Edit is unsafe and cannot be considered functional.
• Link types omit Client, Provider, Application, Project Phase, Provider Job, Work Order, Item and other work contexts.
• No checklist, dependency, recurrence, evidence, follower, Team, visibility, estimate or Time Entry controls.
• No Task ID or Activity is visible.

Required future closure

• Fix Edit before enabling updates.
• Implement the complete Task editor and Task Profile from Spec 12.
• Expand typed links and permission-aware record search.
• Add dependencies, checklists, recurrence, completion evidence, reminders, Calendar and Time Entries.

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 — Task Builder

Current-product profile: task-builder
Observed route: /admin/settings/tasks
Evidence confidence: Verified

Review gaps

• Legacy Leads module.
• Priority taxonomy conflict.
• Types not alphabetized.
• No dependencies, checklists, recurrence, evidence, Phase, start date, resource or duration controls.

Required future closure

• Rename Leads to Project Opportunities/Pipeline Records.
• Use a shared taxonomy registry.
• Add complete scheduling and dependency controls from Spec 12.
• Add Offer, commercial, receiving and Provider Job contexts.

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 -->