Turn decisions into work with clear outcomes
A useful build plan says more than what to edit next. It explains what the work should produce, what it depends on and which requirement it serves.
Wildo records those concerns separately. The plan can connect a task’s purpose to its expected output without mistaking a permitted work area for proof of completion.
Example — Connect contacts to companies
A relationship task follows the contact and company schemas. It identifies the relationship it should produce and the requirement that needs it, so implementation has both prerequisites and a clear intended result.
For engineers
Follow a real relationship task
This entry comes from Wonder CRM’s build plan. Its surrounding graph supplies the referenced tasks and requirements:
{
"taskRef": "build-task-contact-company-relationship",
"objective": "Wire relationship contact ↔ company with one-to-many cardinality intent, where contact holds the reference.",
"target": {
"kind": BuildPlanTaskTargetKind.RELATIONSHIP,
"moduleRef": "relationship-records",
"relationshipRef": "contact-company"
},
"produces": [{ "kind": BuildPlanTaskProductKind.RESOURCE_RELATIONSHIP, "relationshipRef": "contact-company", "sourceResourceRef": "contact", "targetResourceRef": "company" }],
"functionalTopic": MetaWorkflow_FunctionalTopic.MODEL_DOMAIN_GRAPH,
"skillRefs": [
"module-relationships"
],
"prerequisiteTaskRefs": [
"build-task-contact-schema",
"build-task-company-schema"
],
"servesRefs": [
"functional-requirement-shared-contact-and-company-records"
]
},
target describes the work scope. produces names the expected semantic artifact, including the relationship endpoints. prerequisiteTaskRefs expresses dependency; skillRefs supplies method context; servesRefs explains product purpose. Each answers a different question.
Validate dependencies as well as names
The graph checks task references, duplicate product identities and invalid dependencies. Resource-stage validation checks both the existence of a predecessor and whether it is in the task’s transitive prerequisites. The semantic authority distinguishes hard ordering faults from warnings about a missing predecessor that may already exist outside a partial plan.
| Evidence | What it tells you |
|---|---|
| Task target | Where the task is intended to work |
| Declared product | What the task is accountable for producing |
| Prerequisite relationship | Which work must precede it |
| Product probe and committed content | Evidence used for a product-bearing task’s result |
| Framework generation condition | The generation step’s own required committed outputs or schema-plan state |
| Completed run without a declared product | A recorded execution, separately marked as unverifiable landed work |
Framework generation tasks have a separate completion path. Label, email-template and logo generation use the outputs defined by their pipelines; database migrations use the schema-plan-in-sync condition. A migration file’s mere presence is not that condition, and these generation tasks do not need a coding task’s produces declaration.
For other tasks without a declared product, the dispatcher can advance from a durable completed run while marking the result as unverifiable. Do not read every advanced task as a product-proven result.
Inspect the implementation outcome
Check the actual changes and relevant behavior after a task runs. Scope is not a security guarantee by itself, and a relationship declaration is not proof of the whole customer workflow. The task’s product and requirement references help select the verification that matters.