Control minutes, storage, and runners

The project removes a redundant matrix axis, shortens artifact retention, and keeps untrusted fork code off persistent privileged runners. That contrast gives us something useful to test instead of a rule to memorize.

CI/CD consumes compute and stores data; self-hosted runners also create a persistent trust boundary. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can optimize only by adding caches or run all work on one powerful self-hosted machine and still get one successful demo. Push past the demo. profile the workflow, remove low-value work, bound stored data, and isolate runner trust according to the event, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Operate the pipeline as a production system with useful signals, bounded cost, maintenance ownership, and recovery. Save the before-and-after evidence now; it will make the final project review much more honest.

Produce a cost and risk report for each job, cache, artifact, and runner type. Save the evidence, then explain which requirement would force you to choose a different design.