feat(sync): add the Track B distribution caller workflow

[kyle-sexton]

Summary

Activates the Track B config-distribution caller per the plan doc's activation checklist (docs/dedup-program/config-distribution-plan.md):

• Calls melodic-software/ci-workflows/.github/workflows/standards-sync.yml@9cf6d13 (latest main, includes the targets filter from ci-workflows#56), SHA-pinned per D5.
• Wires STANDARDS_SYNC_APP_ID / STANDARDS_SYNC_APP_PRIVATE_KEY (already set on this repo; App verified installed on the org with exactly contents:write + pull_requests:write).
• Deliberate deviation from the plan-doc snippet: workflow_dispatch only. The snippet's push (paths) + weekly schedule triggers would let a modules-touching merge or the Monday 06:00 UTC cron fire a full-fleet REAL sync before the single-target pilot is confirmed (inputs.dry-run || false evaluates to a real run on both events). They land in a follow-up PR after the pilot — the header comment carries the snippet's || false inversion warning forward.
• Adds a targets passthrough so the pilot can run against melodic-software/github-iac alone.

Verification

actionlint + zizmor clean locally; the dry-run dispatch (engine plan job needs no secrets) is the next activation step.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GbDWhcUtduCejgi7mcbMfy

---

Note

Medium Risk
Enables org-wide config distribution PRs via a GitHub App once dry-run is turned off; staged dispatch limits blast radius but misconfiguration or premature activation could still open many PRs.

Overview
Adds .github/workflows/sync.yml, the Track B caller that invokes the SHA-pinned reusable standards-sync engine in ci-workflows to distribute manifest-driven config and open per-repo PRs.

Activation is staged: only workflow_dispatch with dry-run defaulting to true and an optional targets allowlist for a single-repo pilot. push and weekly schedule triggers are intentionally deferred so merges or cron cannot run a full-fleet real sync before the pilot. The job passes STANDARDS_SYNC_APP_* secrets and keeps contents: read on the caller.

^{Reviewed by Cursor Bugbot for commit 39b2fcb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

Claude finished @kyle-sexton's task in 1m 33s —— View job

---

Code Review

• Load tools
• Read guidelines and context
• Analyze and write review

---

File reviewed: .github/workflows/sync.yml

This is a clean, well-scoped activation PR. The deliberate deviation from the plan-doc snippet is correctly reasoned and well-documented. No blocking issues found.

---

What looks good

SHA pinning — Full SHA (9cf6d135...) with inline short-hash + date comment on line 32 satisfies D5. Matches the pattern in ci-workflows' own referenced actions throughout ci.yml.

dry-run: true default — Safe for dispatch. The plan-doc snippet's inputs.dry-run || false pattern is only needed once schedule/push triggers land (to coerce null → false on non-dispatch events). Omitting it here is correct; using it here would be a no-op at best or confusing at worst.

Permission footprint — permissions: contents: read at the caller level is the right minimal scope. The cross-repo writes happen via the GitHub App installation token (minted inside the reusable engine), not GITHUB_TOKEN, so the caller needs no elevated permissions in this repo.

targets passthrough — Good pilot-phase control. Empty default preserves the "all targets" semantics for later; the pilot can pass melodic-software/github-iac explicitly without any code change.

Header comment — The || false inversion warning carried forward is worth keeping; it'll save the follow-up PR author from the same analysis.

---

Nits / low-risk observations

1. Missing concurrency block — Every other workflow in this repo uses:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

A workflow_dispatch-only workflow is low risk since back-to-back manual triggers are unlikely, but adding it now is cheap and consistent. The ref for dispatches is the selected branch, so the group key would correctly serialize per-branch runs. Worth adding before the follow-up PR wires the push/schedule triggers, where back-to-back invocations are real.

2. No timeout-minutes on the sync job — uses: jobs inherit GitHub's 6-hour runner default unless set. Every runs-on job in ci.yml specifies timeout-minutes: 15. The reusable engine presumably has its own job-level timeouts, but if it ever hangs, this caller has no backstop. Consider adding a conservative caller-level timeout (e.g. timeout-minutes: 30) to match the repo's convention and provide an upper bound independent of the engine's own settings.

---

Plan-doc checklist status (informational)

This PR correctly lands only the ungated "Author the standards caller workflow" item. The gated activation steps (re-confirming targets against live repos, GitHub App IaC wiring, Layer-1 package publishing) remain open per the plan doc — that's the right sequencing.

---

Verdict: approve with the above nits noted. Both are cosmetic/conventions issues, not correctness or security problems. The concurrency block is the more worthwhile of the two to address before the follow-up trigger PR lands.

[cursor]

Risk: medium. Cursor Bugbot completed with no findings. Approved; no reviewers assigned.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}