Review summary

PR #179 adds a GitHub-hosted oracle for GITHUB_TOKEN behavior across nested reusable workflows. The top-level workflow invokes the same middle and leaf workflow chain twice, granting contents: read to one call and issues: read to the other. Each leaf hashes its job token, forwards the fingerprint through both reusable-workflow output layers, and a final job verifies that both fingerprints are present and distinct. The final job also writes a short comparison to the GitHub job summary without printing either raw token.

The PR references GitHub issue #160, which tracks eventual buildkite-gha support for job tokens in local reusable workflows. No Linear issue ID was present in the branch, PR title, or PR description.

What I reviewed

• Read the complete diff and all three added workflows:
  • .github/workflows/github-token-nesting-oracle.yml
  • .github/workflows/github-token-nesting-middle.yml
  • .github/workflows/github-token-nesting-leaf.yml
• Compared the change with the repository's existing differential oracles and reusable-workflow example.
• Checked docs/compatibility.md for the current reusable-workflow, output-propagation, permissions, and token boundaries.
• Inspected compiler tests covering nested reusable-workflow outputs and permission narrowing to confirm that the workflow shape matches the behaviors under investigation.
• Read the completed GitHub Actions run and job logs. The leaf setup logs reported Contents: read for the contents chain and Issues: read for the issues chain, with Metadata: read added to each. Both leaf jobs and the distinct-fingerprint verification job passed.
• Confirmed through GitHub checks that Buildkite build #833 and every other non-review PR check passed.
• Ran git diff --check successfully.

I could not run mise run check or invoke the Go CLI locally because this workspace did not contain mise or go. Direct bk queries were also unavailable to the configured token, so Buildkite status was verified through the successful GitHub check instead.

Findings and verdict

I found no actionable correctness, security, or consistency issues and posted no inline comments. The implementation keeps the requested scopes read-only, compares irreversible SHA-256 fingerprints rather than raw tokens, propagates outputs correctly through both reusable-workflow levels, and gives the verification job no repository permissions beyond GitHub's automatic metadata access.

I submitted a COMMENT review rather than an approval because the change directly exercises token issuance and permission propagation and should receive human review before merge.

Review: #179 (review)

Trigger source: automatic.