Keep nested reusable workflow details together during compilation

[lox]

Why

The compiler replaces each reusable-workflow call with the jobs inside that workflow. Those jobs must keep several details from every caller: where the job came from, which secrets and token permissions it may use, inputs that depend on an earlier job, required jobs and outputs, and conditions attached to each call.

Previously, recursive workflow loading, job expansion, and plan creation each carried and rebuilt different parts of that context. A change in one stage could preserve a nested job but accidentally lose its caller's condition, secret mapping, or dependency in another stage.

For example:

jobs:
  build:
    outputs:
      version: ${{ steps.version.outputs.value }}

  release:
    needs: build
    if: github.ref == 'refs/heads/main'
    uses: ./.github/workflows/release.yml
    with:
      version: ${{ needs.build.outputs.version }}
    secrets:
      release_token: ${{ secrets.DEPLOY_TOKEN }}

If release.yml calls another workflow, every resulting job still needs the original condition, deferred version input, dependency on build, source workflow, and release_token mapping. Keeping those details together makes that rule explicit and reduces the number of places a future reusable-workflow change must update.

What

Add one private reusable-job component that owns this context from recursive workflow loading until each concrete job plan is built. It now:

• carries source details, permissions, inherited or explicitly mapped secrets, inputs, dependencies, outputs, and call conditions together;
• creates flattened job instances and resolves their dependencies; and
• writes the same context into the final job plan.

The graph expander and plan builder now coordinate these steps instead of independently interpreting reusable-workflow calls. The compiler's JSON and serialized plan formats remain unchanged.

An end-to-end nested-workflow test verifies source paths, secret and token permissions, deferred outputs, status-only dependencies, call conditions, and plan encoding together. Existing explicit secret-forwarding tests also cover the behavior added to main while this branch was open.

[lox]

@lox @wolfeidau: please provide explicit sign-off on this ownership refactor once you are satisfied with the design and preserved nested reusable-workflow semantics. @wolfeidau can approve via review; because @lox authored the PR, GitHub requires @lox to sign off explicitly in a comment.

[buildsworth-bk-app]

The secret-inheritance and GITHUB_TOKEN permission authority paths make this a high-impact ownership refactor that needs human review. I found no specific issue to add.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 18737, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.

[lox]

Acknowledged Buildsworth review 4980516167: it classified the authority paths as requiring human review and reported no specific issue. Human sign-off remains requested from @lox and @wolfeidau.

[lox]

Acknowledged for review 4980516167: no specific issue was reported; the requested human authority review remains pending.

[lox]

@lox @wolfeidau: this PR is now rebased onto current main at a93c6f8. The conflict resolution preserves the newly merged explicit reusable-workflow secret mappings inside the consolidated authority state; go test ./internal/compiler and mise run check pass locally. Please re-review and explicitly sign off on this current head once CI is green.

[buildsworth-bk-app]

I found no specific issue in the current rebased head. The secret-inheritance and GITHUB_TOKEN permission authority paths still need human review.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 19611, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.