[sync] Create .github/workflows/dispatch-review.yaml

[automation-nsheaps]

Org-sync from nsheaps/.github

Direct push was blocked by branch protection. This PR applies the
central file update via the standard PR flow.

Path: .github/workflows/dispatch-review.yaml
Action: Create

Branch org-sync/-github-workflows-dispatch-review-yaml is stable — subsequent runs update this PR.

[henry-nsheaps]

Review — Dispatch PR Review template sync

Verdict: 💬 COMMENT — Two P2 doc-accuracy nits; the workflow itself is correct and safe to merge.

Summary

Adds .github/workflows/dispatch-review.yaml (76 lines, new file) that forwards pull_request events to nsheaps/agents/.github/workflows/review-dispatch.yaml. This is an org-sync PR — the file is byte-identical to the upstream template in nsheaps/.github (both blob SHAs 35aea4d…), so structural feedback belongs upstream; this review is scoped to whether the file as-shipped is correct and safe.

How I arrived at this

• Fetched PR metadata, diff, files, prior reviews (none), prior review comments (none).
• Confirmed the reusable target nsheaps/agents/.github/workflows/review-dispatch.yaml@c11e86f4… exists and reads the same secrets the caller passes (AUTOMATION_GITHUB_APP_ID, AUTOMATION_GITHUB_APP_PRIVATE_KEY).
• Confirmed the caller SHA (c11e86f4…) is an ancestor snapshot on nsheaps/agents@main (current tip: 51887d0d…) — so # main is a truthful branch marker, not a stale ref.
• Compared the shipped file against nsheaps/.github/.github/workflows/dispatch-review.yaml@main — byte-identical (both blob 35aea4d…).
• Checked event filter, permissions, and secret handling against GitHub reusable-workflow docs.

Strengths

• ✅ SHA-pinned callee (nsheaps/agents@c11e86f4…) — correct security posture for a third-party-style reusable workflow, even though it's same-owner.
• ✅ Least-privilege permissions, declared at both top-level (satisfies checkov CKV2_GHA_1) and job-level (needed because secrets: block prevents reliance on caller default).
• ✅ Gate logic is right: state == 'open' plus draft-or-labeled disjunction correctly distinguishes "auto-fires on ready PRs" from "labeled override for drafts." The inline commentary about converted_to_draft and label-name coupling is genuinely useful for anyone modifying it.
• ✅ Explicit secrets: block — future-proofs against org moves and documents the callee's secret surface clearly.
• ✅ Header block explains cred boundaries (automation vs. reviewer identity) with a spec link — good "why" documentation.

Improvements (both P2, doc-accuracy)

1. Comment/code contradiction on the uses: block (L64–68) — The comment describes @main rolling-update semantics, but the line is SHA-pinned. Reword to describe the actual pinning strategy.
2. secrets: inherit doesn't pass cross-repo (L69) — Imprecise. inherit works within the same org/user account (which this call is); the real constraint is cross-org. Fix upstream so the template teaches the right lesson.

Both fixes belong in nsheaps/.github upstream — patching here would be overwritten on the next sync.

Critical issues

None. No P0/P1 findings.

Follow-ups

• P2 — Rewrite the @main comment block upstream to match the SHA-pin reality (or drop the pin).
• P2 — Rewrite the secrets: inherit justification upstream to reflect same-org/user-account inheritance rules.

Recommendation

Merge when green — the file works as intended and matches the canonical source. Address the two comment inaccuracies upstream in nsheaps/.github so subsequent syncs propagate the fix to every consumer repo.

---

_{🤖 Review by henry-nsheaps · job · sha 4fc325c}

[henry-nsheaps]

🟡 P2 · maintainability — Comment contradicts the uses: line.

The comment describes @main semantics ("rolling updates", "operators who need pinned stability should replace @main with a commit SHA"), but line 68 is already SHA-pinned to c11e86f… with a trailing # main marker. A reader following the comment will look for a floating ref and be confused when they see a pin instead. The two are saying opposite things about the same line.

Pick one story and tell it consistently. If the intent is "pin to a SHA that tracks main and bump on plugin release," reword to describe that (e.g. "Pinned to a nsheaps/agents commit on main; bump in lock-step with plugin releases. Trailing # main records the branch the SHA came from.") If the intent really is @main, drop the SHA.

Note: the file in this PR is byte-identical to nsheaps/.github/.github/workflows/dispatch-review.yaml@main (both share blob SHA 35aea4d…). This is an org-sync PR, so any wording fix belongs upstream in nsheaps/.github — editing only here would be overwritten on the next sync.

[henry-nsheaps]

🟡 P2 · documentation accuracy — The secrets: inherit doesn't pass cross-repo justification is imprecise.

Per GitHub's reusable-workflow docs, secrets: inherit works when the called workflow lives in the same organization or user account as the caller. Both nsheaps/github-actions (caller) and nsheaps/agents (callee) are owned by the nsheaps account, so secrets: inherit would in fact pass. The real limitation is cross-organization calls, and secret visibility (org-level vs. repo-level) — not cross-repo per se.

Keeping the explicit secrets: block is still a fine choice — it's clearer about which secrets the callee actually needs, and it's future-proof if the callee ever moves to a different org. But the comment as written will teach the wrong lesson to anyone copying this template. Suggested rewording:

Suggested change

	# secrets: inherit doesn't pass cross-repo (GitHub limitation).
	# Explicit secrets (rather than `secrets: inherit`) so it's obvious which
	# secrets the callee consumes, and so this still works if nsheaps/agents
	# ever moves to a different org (inherit only crosses repos within the
	# same org/user account).

Note: as with the other comment, the wording fix belongs upstream in nsheaps/.github/.github/workflows/dispatch-review.yaml — this file is a byte-identical sync.