Custom safe-output jobs cannot declare needs / ordering relative to generated jobs (e.g. safe_outputs)

[j-srodka]

Summary

Custom safe-output jobs compile with fixed dependency behavior. There is no first-class, source-level way to declare needs: (or equivalent) so a custom job runs after generated jobs such as safe_outputs.

Analysis

Legitimate patterns need custom steps to run only after sanitized outputs exist—for example consuming safe_outputs artifacts or performing a final packaging step. Without ordering in the source model, authors patch needs: into compiled lockfiles or add extra workflows as workarounds. Those approaches break on recompile and are easy to get wrong.

Custom job races or runs before safe_outputs; author adds needs: in .lock.yml; next compile removes it.

Implementation plan

1. Support needs: on custom safe-output jobs in the source format, with validation against known generated job ids (including safe_outputs).
2. If raw needs: is undesirable, add a supported alias such as after: safe_outputs that the compiler lowers to concrete needs:.
3. Document valid dependency targets; fail the compile with a clear error when a target is unknown or would create a cycle.

Expected outcome

Custom safe-output jobs can be ordered relative to generated jobs in a way that survives compile, without lockfile surgery.