fix(groom): default workflows_ref to github.job_workflow_sha so assets can't desync from the uses: pin (BE-4169)

[mattmillerai]

ELI-5

The groom workflow reads its instruction files (the finder/verifier/builder briefs + the dedup ledger) out of this repo. Until now, callers had to hand-copy the same commit SHA into two places — the uses: line and a workflows_ref: input — to make the code and the instructions match. Nobody enforced that they stayed equal, so a caller that forgot workflows_ref ran the pinned code but read instructions from moving main, and a pin bump that touched only one line ran code and instructions at different commits. This change makes the workflow default to pulling its assets from the exact commit it was itself resolved from (github.job_workflow_sha), so callers don't have to mirror anything and the two can't drift.

What changed

.github/workflows/groom.yml only:

• Changed the effective checkout ref of every _groom_assets step from ${{ inputs.workflows_ref }} to ${{ inputs.workflows_ref || github.job_workflow_sha }} (all six asset checkouts: finder briefs, verifier briefs, both ledger checkouts, the builder brief, and the signature marker — leaving any one bare would reintroduce the desync).
• Changed the workflows_ref input default from main to '' (empty), so an unset input falls through to github.job_workflow_sha — documented as "for jobs using a reusable workflow, the commit SHA for the reusable workflow file."
• Kept workflows_ref as an explicit override (e.g. testing briefs from a branch) and rewrote its description to say so.
• Dropped the workflows_ref: <sha> line from the caller-pattern comment block and refreshed the adjacent security comment.

Why this is safe

groom.yml is on: workflow_call only, so github.job_workflow_sha is always populated with the reusable workflow's own resolved commit when its jobs run. The || returns the first truthy operand: an explicit workflows_ref still wins; an empty/unset one falls back to the auto-pin. The degenerate "both empty" case cannot occur for a workflow_call-only reusable, and even if it did, an empty ref just checks out github-workflows' default branch — no worse than the old default: main. default: main was the naive initial default introduced with the workflow itself in #49 (BE-3872); this ticket is its intended correction (deferred from the review thread on comfy-cloud-mcp-server#786).

Scope / follow-ups (deliberately not in this PR)

Both remaining caller cleanups must wait until each caller's uses: pin is bumped to a SHA that includes this fix — dropping workflows_ref from a caller whose uses: still points at the pre-fix groom.yml would make that old workflow default to main, i.e. the exact drift bug:

• This repo's own ci-groom.yml still passes workflows_ref: 07154fb… (its uses: pins the old groom.yml). Left as-is; it becomes removable once the pin is bumped (bump-callers machinery).
• comfy-cloud-mcp-server pilot caller (its lines 49–51, per the ticket) — a follow-up in that repo after its pin is bumped.

Verification

• python3 -m unittest discover -s .github/groom/tests → 48 tests pass.
• YAML parses; all six bare inputs.workflows_ref refs confirmed replaced.
• Human pre-merge check requested by the ticket: confirm github.job_workflow_sha is populated on a SHA-pinned uses: dispatch (a live dry-run of ci-groom.yml against a SHA carrying this change). Not runnable from the coding loop (needs a live run + secrets).
• Note: actionlint 1.7.12 flags github.job_workflow_sha as an unknown context property — that's a stale-schema false positive (the property is documented and quoted above); this repo's CI does not run actionlint on workflows.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 39 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4ed93d36-2212-44be-b7b4-f867a87826a9

📥 Commits

Reviewing files that changed from the base of the PR and between fd35bf2 and 55385c6.

📒 Files selected for processing (1)

• .github/workflows/groom.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-4169-groom-workflows-ref-default

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-4169-groom-workflows-ref-default

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔍 Cursor Review — Consolidated panel

Triggered by @mattmillerai.

Found 1 finding(s).

Severity	Count
🟢 Low	1

Panel: 7/8 reviewers contributed findings.

Reviewers that did not contribute: gpt-5.6-sol-max:adversarial (error)