Generated jobs lack a compile-stable runner override/inheritance mechanism

[j-srodka]

Summary

Some generated / framework jobs are emitted with framework-chosen runs-on values after compile. Authors lack a durable, compile-stable way to express runner inheritance or override for those jobs.

Analysis

Without a supported mechanism, source intent and the compiled artifact can diverge: recompile restores framework defaults, so teams re-patch lockfiles to restore labels required for capacity, image choice, or environment guarantees. That is a compile-durability and operator-control gap in the product, not a one-off local preference.

Author sets runner policy for the workflow; compile regenerates jobs with a different runs-on; CI runs on unintended queues or fails eligibility until the lockfile is patched again.

Implementation plan

1. Where technically safe, let generated jobs inherit runner choice from an author-declared workflow or job default, or add explicit source fields for generated-job runners.
2. Alternatively, provide a supported override hook (frontmatter, compiler option, or similar) that persists across recompile.
3. If certain generated jobs must stay on a fixed runner for framework invariants, document which jobs are pinned and why, so authors do not rely on unsupported patches.

Expected outcome

Runner selection for generated jobs is predictable across compile cycles, or explicitly constrained and documented—reducing unsupported lockfile churn.