ci: trigger scaffold sync on every push to main

[ggallen]

Summary

• Add push trigger on main to the notify-scaffold-sync workflow so it fires automatically on every merge, not just via manual workflow_dispatch.

Test plan

• Verify the workflow appears in the Actions tab after merge
• Merge a test PR and confirm the scaffold sync dispatch fires

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

CI: trigger scaffold sync automatically on pushes to main

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Trigger scaffold sync notification automatically on every push to main.
• Keep manual workflow_dispatch support for ad-hoc runs.
• Ensure .fullsend scaffold reconciliation is initiated after merges to main.

Diagram

graph TD
  A(["Push to main"]) --> C[["notify-scaffold-sync" workflow]] --> D{"Repo/ref guard"} --> E["Notify job"] --> F[[".fullsend repo" dispatch]]
  B(["Manual dispatch"]) --> C
  E -. "on failure" .-> G["Slack webhook"]
  subgraph Legend
    direction LR
    _evt(["Trigger"]) ~~~ _wf[["Workflow/Repo"]] ~~~ _job["Job/Step"] ~~~ _dec{"Decision"}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Trigger via workflow_run after main CI succeeds

• ➕ Ensures scaffold sync dispatch only happens after the main pipeline passes
• ➕ Avoids dispatching when main is updated by unusual workflows (e.g., reverted merges)
• ➖ More complex wiring (must reference the correct CI workflow name/event)
• ➖ Adds latency; dispatch waits for CI completion

2. Add path filters to limit when sync dispatch runs

• ➕ Avoids running scaffold reconciliation when unrelated files change
• ➕ Reduces noise and external dispatch volume
• ➖ Requires maintaining an accurate list of scaffold-relevant paths
• ➖ Risk of missing needed syncs if paths change over time

Recommendation: Current approach (push on main + existing repo/ref guard) is the simplest and most reliable way to ensure .fullsend is notified after every merge. Consider workflow_run only if you need the dispatch to be strictly gated on a successful CI pipeline, or add path filters if dispatch volume becomes a concern.

Files changed (1) +2 / -0

Other (1) +2 / -0

notify-scaffold-sync.ymlRun scaffold sync notify workflow on pushes to main +2/-0

Run scaffold sync notify workflow on pushes to main

• Adds a 'push' trigger for the 'main' branch so the workflow runs automatically on merges/updates to 'main', while retaining manual 'workflow_dispatch' support.

.github/workflows/notify-scaffold-sync.yml

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 1:52 PM UTC · Ended 1:58 PM UTC

Commit: a616c02 · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. Queued runs dispatch stale sha ✓ Resolved 🐞 Bug ≡ Correctness

Description

With the new push trigger, multiple runs can queue behind the same concurrency.group and later
dispatch with client_payload[sha]=${{ github.sha }} from an older push even though the receiver
"builds from main HEAD" at dispatch time. This creates redundant dispatches and breaks the intended
traceability of the sha payload when runs are delayed/queued.

Code

.github/workflows/notify-scaffold-sync.yml[R17-18]

+  push:
+    branches: [main]

Relevance

●●● Strong

Recent workflow precedents accept concurrency fixes for stale queued runs; this finding directly
targets duplicate dispatch and SHA freshness.

PR-#2106
PR-#1215

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR adds a push trigger to main, which increases run frequency. The workflow’s concurrency
group is constant and does not cancel in-progress runs, so pushes can queue. The dispatch step
always sends ${{ github.sha }} from the triggering event, while a comment states the receiver
builds from main HEAD, meaning a delayed/queued run can dispatch with an old SHA that no longer
matches the head being built/synced.

.github/workflows/notify-scaffold-sync.yml[16-23]
.github/workflows/notify-scaffold-sync.yml[21-23]
.github/workflows/notify-scaffold-sync.yml[42-51]
PR-#2106

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow now triggers on every push to `main`, but concurrency is configured with only `group: ${{ github.workflow }}` and no `cancel-in-progress`. This queues old runs instead of cancelling them, so an older queued run can dispatch after newer commits land and send a stale `client_payload[sha]` while the receiver actually builds from `main` HEAD.

### Issue Context
This is activated by the PR adding the `push` trigger; previously the workflow primarily ran manually.

### Fix Focus Areas
- .github/workflows/notify-scaffold-sync.yml[16-23]
- .github/workflows/notify-scaffold-sync.yml[21-23]
- .github/workflows/notify-scaffold-sync.yml[42-51]

### Suggested fix
1. Update `concurrency` to cancel in-progress/queued runs so only the latest push results in a dispatch, e.g.:
  - `concurrency.group: ${{ github.workflow }}-${{ github.ref }}` (or `...-${{ github.ref_name }}`)
  - `concurrency.cancel-in-progress: true`
2. Keep `client_payload[sha]=${{ github.sha }}`; once stale runs are cancelled, it remains accurate for traceability.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 59 rules

✅ Skills: writing-user-docs, writing-adrs

Review mode: ⚖️ Balanced

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:00 PM UTC · Completed 2:12 PM UTC

Commit: b89b547 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $2.43

[fullsend-ai-review]

Review

Findings

High

• [API contract violation] .github/workflows/notify-scaffold-sync.yml:22 — The cancel-in-progress: true is unconditional, but the workflow now triggers on push to main. This violates the documented CI convention (docs/contributing/ci-workflows.md): "Never cancel in-progress runs on the default branch. Gate cancel-in-progress when the workflow triggers on push to main." When multiple PRs merge to main in rapid succession, in-flight scaffold sync dispatches will be cancelled, and the notify-failure job will also be cancelled (GitHub cancels all jobs in a cancelled run), so no Slack alert fires either — creating a fail-open path where sync is silently skipped.
  Remediation: Gate cancel-in-progress so it is false on the default branch. Since this workflow only fires on main pushes and manual dispatch, the simplest fix is to remove cancel-in-progress: true entirely (allowing runs to queue and execute sequentially), or use cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}.

• [protected-path] .github/workflows/notify-scaffold-sync.yml — This PR modifies a file under the protected .github/ path. No linked issue provides authorization for the change. Human approval is required for all changes to governance and infrastructure files.

Low

• [missing-authorization] .github/workflows/notify-scaffold-sync.yml — No linked issue authorizing this change. The change is near-mechanical (adds a push trigger aligning with the workflow's documented purpose), but protected-path changes benefit from explicit authorization via a linked issue.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

[fullsend-ai-review]

See the review comment for full details.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:31 PM UTC · Completed 2:43 PM UTC

Commit: 057969e · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $2.45

[fullsend-ai-review]

Review skipped — this PR is already merged.

The /fs-review command only reviews open PRs/MRs.

_{Posted by fullsend pre-review check}

[fullsend-ai-review]

Review skipped — this PR is already merged.

The /fs-review command only reviews open PRs/MRs.

_{Posted by fullsend post-review check}