The refusal rule is the part worth copying. In the builder described on dev.to, a subtask with an empty dependency list means "checked, independent"; a subtask with no entry at all means "nobody looked", and the run will not start [11]. Those two states look identical to any agent asked to derive a graph, which is how you get subtask 7.3 built against four prerequisites from a phase that is not in this run, and a service that does not exist yet [12][13]. The distinction matters because it is the only thing standing between an unexamined task and a merge.
The spread is worth examining directly. Same repository, same model, allocation the only variable: 34.3 divided by 8.7 is about 3.9, a gap of 25.6 points [23]. For that ratio to mean anything in your shop, your partitions would have to vary as widely as theirs did, your score would have to be end-to-end resolution rather than per-file diff quality, and two runs on one repo would have to stand in for a distribution. The writeup reports it as exactly two runs [6]. Treat it as evidence that allocation variance is large, not as a coefficient you can multiply by.
The graph was supposed to come out of the plan. The plan is 1,300 lines, 115 open subtasks, three weeks of work by someone who knew the order [7]. One subtask states its dependency in a form a machine can read [8]. That is roughly 0.9% coverage [24], and the missing 99% lives in a human head, not in the project.
The forbidden-path guard shows the same move twice. Version one was an instruction: do not touch these paths [16]. Version two runs on the diff, in code, immediately before the merge, piping `git diff --name-only base...branch` into the path matcher, and one match ends the run with no warning and no retry [17]. The reason given is bookkeeping trust: once the status file has been written by an engineer, its running total is no longer verifiable [18]. Two concurrent writers had already corrupted that file twice, and git stayed quiet both times because they touched different lines [15]. The matcher carries 18 test cases, and the important ones are the non-matches: `services/watchdog/BUILDPLAN.md` must pass, because only the root file is the status document [19]. A pattern that is too wide halts good work, which costs the same as a rule that never fires [20].
Then the log. Two lines, one second apart, engineer one finishing 7.1 before engineer two had a worktree [21]. The isolation was genuine: separate branches, separate worktrees, test-gated merges into a single trial branch, one at a time [3]. `git worktree list` answers a question about isolation, truthfully, but it says nothing about wall-clock overlap. The engineer loop was synchronous, and the design, the dashboard and the tests all had no opinion about it [22]. Five subtasks in under a minute [4] is a throughput number that survives either way, which is precisely why it did not catch this.
