Advance independent work together
Independent work does not always need to wait in line. Wildo can run compatible methods together within a round, run separate composites at the same time, and bring their results into the next decision.
Before admitting the work, it compares the artifact families the methods can write, including outputs of their composed children. This keeps a parent method and another writer of the same result from being selected together in that round.
Example — Keep parallel work from claiming the same result
Market research can contribute alongside unrelated work. But a market-analysis umbrella and its own snapshot producer both lead to the market snapshot, so the admission check keeps them apart.
For engineers
Include children in the scope
This selected runtime implementation walks admitted descendants as well as the parent:
const families = new Set<string>();
const outputOwners = new Map<string, Set<string>>();
const unresolvedRefs: string[] = [];
const visited = new Set<string>();
const pending: string[] = [playbookRef];
while (pending.length > 0) {
const ref = pending.shift()!;
if (visited.has(ref)) continue;
visited.add(ref);
const playbook = playbooksByRef.get(ref);
if (playbook === undefined) {
unresolvedRefs.push(ref);
continue;
}
(playbook.outputs ?? []).forEach((output) => {
families.add(output.family);
const owners = outputOwners.get(output.family) ?? new Set<string>();
owners.add(ref);
outputOwners.set(output.family, owners);
});
pending.push(...(playbook.method?.choreography?.admits ?? []));
}
This is an excerpt from resolvePlaybookWriteScope, not an application extension point. A composite with outputs: [] is therefore not assumed to write nothing when its children produce artifacts.
Admit a compatible portfolio
The admission function walks proposed lanes in order. It holds back a later lane whose families overlap those already admitted and returns a reason for that decision. If a referenced child cannot be resolved, its scope is unknown: it can run alone, but is not treated as safe to combine with another lane.
The outer loop bounds its portfolio, and composites also bound child concurrency. Child results are collected before the next selection round.
| Execution boundary | Current behavior |
|---|---|
| Methods within a loop round | Bounded parallel execution with declared family-scope admission |
| Children within a composite | Bounded parallel execution and isolated child outcomes |
| Different composites, or instances of one | Run at the same time, each under its own lease |
| A second run of the same composite instance | Refused, naming the run that holds it |
| Another unattended loop in the same application | Refused while a loop is active |
| Build-plan coding runs | Up to five at once by default in one worktree, set with wildo workbench parallelism <n> |
| Other coding dispatches | One at a time, under the coding lane’s workspace lock |
Keep concurrency claims precise
Round admission compares declared artifact outputs. It is not a filesystem sandbox or a branch-and-merge service, and it does not turn unrelated manual writers into coordinated lanes.
A secondary line of work runs as its own composite instance, opened for its own purpose, beside the main line. The two share one working tree. A landing re-reads the file it is about to replace: a family that holds several documents merges them, and a single-value family that another run landed after this run read it refuses the second landing and writes nothing. Each run records the other runs whose windows overlapped its own, and wildo context journey shows them under the settled run. Parallel build runs also share the tree: the companion prevents a task being built twice at once, records suspected interference on each run, and commits what the wave left once it has drained. A run of two lines at once on a real application is still to be measured.