Choose the right reuse boundary

Before choosing a tool or writing more code, make the requirement concrete. Several repositories call one deployment workflow with explicit inputs and inherited secrets only where required.

Reuse has layers: scripts share commands, composite actions share steps, and reusable workflows share jobs and policy. 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 abstract one-off YAML immediately or copy security policy across repositories. The happy path may still work, which makes the mistake easy to miss. extract only stable repeated behavior and define inputs, secrets, permissions, versions, and ownership at the boundary. Keep the first version small enough that every important input and output remains visible.

This supports the module goal: Turn a verified build artifact into one controlled deployment with environment history and rollback. Capture the request, command, trace, screenshot, test result, or other evidence that proves the result.

Compare two workflows and choose the smallest reuse mechanism that removes meaningful duplication. Change one condition on purpose, predict the result, and compare the prediction with what actually happened.