Make prerequisites explicit before starting workers
A dependent task needs an interface whose required behavior has been checked.
A game’s spell animation can look finished before collision detection exists. The animation plays, the screenshot is persuasive and the task receives a completed status. Later, the spell passes through walls because the worker assumed that somebody else would supply the missing behavior.
When I specified Infini-Wizard, an iOS dungeon game, I asked for dependencies on each task so work would not happen in an order that broke the application. I later reported that the original requirements had been implemented and assets imported. Those are my contemporary reports; this account does not establish a device-tested or publicly released game.
Dependencies matter because an agent can often produce plausible code around a missing component. A function name and a comment may be enough to continue generating files, even when the behavior needed by the next task has never run.
The collision interface
For an illustrative projectile feature, “collision system complete” is too broad. A usable prerequisite would say that the system accepts a movement segment and returns whether it intersects a wall, including the contact position. A saved test should demonstrate an unobstructed segment and one that reaches a wall.
The projectile worker can then use that behavior without inventing it. Its own task adds motion, renders the projectile and applies the collision result. A test can confirm that the displayed projectile stops at the same contact position returned by the collision system.
Notice the difference between a dependency on a file and a dependency on a behavior. The file may exist while containing a placeholder. Conversely, an implementation may move between files while preserving the required interface. The planning record should identify both where the worker finds the prerequisite and how the worker confirms that it is usable.
When the collision prerequisite is declared ready, have the dependent worker rerun its saved examples in the environment where the projectile feature will execute, since a successful check in another configuration may leave an important difference unexamined. Preserve the coordinate values and the contact result from that run, and compare them after any change to scaling or camera position so a visual adjustment cannot silently alter the meaning of the shared coordinates.
What can start before the interface is settled
If nobody knows how the collision interface should work, starting several dependent tasks spreads that uncertainty. Each worker may settle the question differently while trying to make local progress. The project then needs a reconciliation task that would have been unnecessary if the shared choice had been made first.
A small exploratory task can answer the uncertain question. Give it a deliberately limited deliverable, such as a tested collision interface with two example inputs. Do not call the whole game ready because this experiment succeeds, and do not let the experiment expand into unrelated rendering work.
Once the interface is available, independent tasks can proceed. A worker might build spell visuals while another prepares level data, provided their contracts are stable and their changes remain within separate ownership boundaries.
A changed coordinate system
A completed prerequisite is not permanent evidence. If another task changes how coordinates are represented, the collision checks may need to run again before dependent work can be accepted. The test result applies to the version that produced it.
The same principle applies to assets. A placeholder image can satisfy a dimensions test while failing a final-art requirement. If a downstream task assumes the art is final, the project has concealed a dependency on future visual work inside an apparently completed story.
Record the unfinished condition explicitly. A task may be complete for prototype integration while remaining unsuitable for release. Those are different decisions, and the task record should say which one has been made.
Inspect a running scene with a wall, a projectile and a known starting position. Compare the visual result with the collision output and preserve the fixture. If the projectile stops correctly but the final animation is still missing, record both observations so the next worker can continue without mistaking a successful mechanical test for a finished player experience.
Source notes
Drew Wiberg, Infini-Wizard requirements and implementation report, 26 January 2026. Implementation is author-reported; release and device validation are not established here.
Worked examples and review procedures in this article are instructional applications, not additional historical project results.
