Map events, workflows, jobs, and steps

Before choosing a tool or writing more code, make the requirement concrete. A pull request starts tests, while a push to the default branch can start a later deployment path.

A workflow is event-driven automation; jobs form a dependency graph and steps within one job share its runner workspace. 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 copy a large YAML file without drawing the event and job graph. The happy path may still work, which makes the mistake easy to miss. write the trigger and job outcomes in plain language, then encode the smallest matching workflow. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Create one workflow whose trigger, runner, permissions, commands, and failure behavior are obvious. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Draw the event-to-job graph and annotate which state is shared and which job gets a fresh runner. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.