syncode/workflow

feat: lower a workflow into the plans its jobs describe #7

Merged

day01 merged %!d() commits from %!s() into %!s()

2026-08-14 06:15:13 +00:00

day01 commented

2026-08-14 06:13:23 +00:00

Owner

A plan holds a single job, because a node executes a single job: an assignment names one, reports one, and holds a lease on one. What did not follow is that a workflow is one plan. It is as many plans as it has jobs.

Lowering refused anything else — execution plan requires exactly one job, got N — and that refusal was the whole of the gap between what this compiler produces and what a forge running the same repository produces. Measured against the five SynCode repositories (syncode/control #18): three agreed with the forge exactly, and the two that did not both failed here and nowhere else, on four jobs and on five.

Everything needed was already carried. WorkflowHir holds every job, and each JobHir already states what it waits for, which survives into JobPlan.needs. So each job becomes its own plan, keeping its needs, and plans() replaces the single-job TryFrom.

What this deliberately does not do is decide when each may run. It says what the jobs are; ordering them by needs belongs to whoever queues them, and comes with the control-plane half.

After this lands and the pin is bumped, the comparison should go from two diverging repositories to none — which is the check, rather than my word for it.

A plan holds a single job, because a node executes a single job: an assignment names one, reports one, and holds a lease on one. What did not follow is that a *workflow* is one plan. It is as many plans as it has jobs. Lowering refused anything else — `execution plan requires exactly one job, got N` — and that refusal was the whole of the gap between what this compiler produces and what a forge running the same repository produces. Measured against the five SynCode repositories (syncode/control #18): three agreed with the forge exactly, and the two that did not both failed here and nowhere else, on four jobs and on five. Everything needed was already carried. `WorkflowHir` holds every job, and each `JobHir` already states what it waits for, which survives into `JobPlan.needs`. So each job becomes its own plan, keeping its `needs`, and `plans()` replaces the single-job `TryFrom`. What this deliberately does not do is decide *when* each may run. It says what the jobs are; ordering them by `needs` belongs to whoever queues them, and comes with the control-plane half. After this lands and the pin is bumped, the comparison should go from two diverging repositories to none — which is the check, rather than my word for it.

day01 added 1 commit 2026-08-14 06:13:24 +00:00

feat: lower a workflow into the plans its jobs describe

		A plan holds a single job, because a node executes a single job: an assignment
names one, reports one, and holds a lease on one. What did not follow is that a
workflow is one plan. It is as many as it has jobs.

Lowering refused anything else, and that refusal was the whole of the gap
between what this compiler produces and what a forge running the same
repository produces. Measured against the five SynCode repositories, the two
that diverged both failed here and nowhere else, on four jobs and on five.

Everything the jobs need was already carried: the HIR holds them all, and each
one states what it waits for. So each becomes its own plan, keeping its
`needs`, and what is left to whoever queues them is the order.

day01 merged commit 77f6f6321f into %!s()

2026-08-14 06:15:13 +00:00

day01 deleted branch feat/lower-a-workflow-into-the-plans-its-jobs-describe

2026-08-14 06:15:14 +00:00

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: syncode/workflow#7