Task Builder
Reusable Task Templates, triggers, required work, due offsets and assignment rules by operating context.
/admin/settings/tasksFuture Spec 12 →Current-state summary
Task Builder is organized into Applications, User onboarding, Provider onboarding, Projects, Leads, Clients and Matchmaking. Provider onboarding contains one enabled template triggered by Provider approved with four required tasks and due offsets. Its Task Type options are not alphabetized, it exposes Urgent Priority even though the Tasks directory filter does not, and the Leads module retains retired terminology. Dependencies, Phase placement, recurrence, evidence, start anchors and resource requirements are absent.
Interface inventory
Anatomy and verified behavior
Verification states separate observed behavior from requirements or assumptions.
| Element | Current behavior | Verification |
|---|---|---|
| Module navigation | Seven contexts, including legacy Leads. | Verified live |
| Template | Provider onboarding; trigger Provider approved; enabled; four required tasks. | Verified live |
| Task rows | Agreement, credentials/evidence, Matchmaking Profile and orientation due in 2/3/5/7 days. | Verified live |
| Assignment | Workspace Owner, record owner/applicant, administrator, Project Lead, assigned Designer/Provider, specific teammate, Team, Role Label or unassigned. | Verified live |
| Taxonomy | Type options are not alphabetized; Urgent conflicts with directory filters. | Verified live |
User journeys
Current flows
Publish Task Template
- Choose operating context
- Select stable Domain Event trigger
- Add ordered Tasks
- Set Owner rule, Type, Priority, required state and date anchor
- Add dependencies/evidence/resources
- Preview created work
- Publish immutable version
State model
Current and expected states
Provider onboarding is enabled.
Control exists.
Not exercised.
Urgent cannot be filtered consistently downstream.
Product rules
Non-negotiable boundaries
- Task Templates create canonical Tasks; they are not Tasks themselves.
- Type, State and Priority use shared registries everywhere.
- Triggers are stable Domain Events.
- Published template versions are immutable.
- Generated Tasks retain template/version lineage and idempotency key.
Known current limitations · 4 mapped
What is missing, broken or unverified
Future Spec 12 owns closure →- Legacy Leads module.
- Priority taxonomy conflict.
- Types not alphabetized.
- No dependencies, checklists, recurrence, evidence, Phase, start date, resource or duration controls.
Future alignment
Required evolution
- 01Rename Leads to Project Opportunities/Pipeline Records.
- 02Use a shared taxonomy registry.
- 03Add complete scheduling and dependency controls from Spec 12.
- 04Add Offer, commercial, receiving and Provider Job contexts.
Current baseline
Acceptance record
- Every generated Task is traceable to trigger and template version.
- All builder values appear in directories and filters.
- No retired Lead label remains.
- Configuration validates before activation.
Reverse-spec completeness
Documentation coverage
The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.
Purpose and user outcome
DocumentedRoles and access
DocumentedRoutes and entry points
DocumentedPage and component anatomy
DocumentedFields and displayed data
DocumentedPrimary actions
DocumentedForms and validation
DocumentedStates and transitions
DocumentedEmpty, loading and error states
DocumentedResponsive behavior
PartialAccessibility behavior
PartialActivity and audit events
PartialData sources and persistence
DocumentedNotifications and automation
PartialKnown defects and limitations
DocumentedReusable component dependencies
DocumentedFuture-spec conflicts
PartialVisual and repository evidence
DeferredAcceptance of current baseline
Documented