Design the job graph

Before choosing a tool or writing more code, make the requirement concrete. Lint and unit tests run together; the package job waits for both; deployment waits for the package and environment approval.

Jobs can run in parallel unless dependencies say otherwise, so the graph should reflect real data and release gates. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

A common failure is to put every command in one job or serialize unrelated work through unnecessary needs. The happy path may still work, which makes the mistake easy to miss. draw required outputs and gates, parallelize independent checks, and keep each job’s purpose visible. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Build a fast CI graph that preserves useful evidence without sharing mutable state accidentally. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Measure a serial workflow, then reshape it into a dependency graph and compare total time and diagnostic clarity. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.