ci: scan every main push and use shallow verify checkouts

[altaywtf]

Every main push now finishes its CI run, so the secret and workflow scan covers each pushed range, and verification checks out one commit instead of full history.

	Before	After
Push and dispatch runs	one CI-refs/heads/main group; a third push cancels the pending second run, whose range is never scanned	one group per run; every pushed range is scanned
Pull request runs	superseded runs cancelled	unchanged
verify checkout	full history	default depth

• Releases stay serialized by the shared release workflow's own release-<repo>-main group, which keeps full history for semantic-release. That group holds one pending release, so if three pushes land within one release and the older verify finishes last, semantic-release skips the stale commit and the newer commits publish on the next push.
• The scan deepens its own clone to the pushed range, or to full history on dispatch.
• The scan passes through on pull requests; actionlint 1.7.12 and zizmor 1.29.0 report nothing on this branch locally, and the first main run after merge audits the change.
• Merging runs verify and the release job on main; a ci: commit publishes nothing.

---

Written by an agent (Claude Code, Claude Opus 5.5)

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Copilot]

Copilot review overview

🔵 Needs a closer look

It changes CI concurrency semantics and the shallow-checkout behavior feeding the release pipeline, which carries operational/publishing implications that warrant a maintainer's final sign-off even though no defects were found.

Review effort: Balanced
Findings: None

What changed in this PR

This PR adjusts the CI workflow so that every push to main runs to completion (rather than having queued runs cancelled), ensuring the secret/workflow scan covers each pushed commit range, and switches the verify job to a shallow checkout. This fits the repo's delivery model where main pushes run verify plus the scan, and conventional commits trigger npm publishing via the shared release workflow.

I verified the key claims against the external actions pinned in this workflow:

• The scan action (plan.sh) deepens/unshallows its own clone using its own token, so fetch-depth: 0 is no longer required for scanning the pushed range or full history on dispatch.
• The verify script (vp check, typecheck, pack, smoke, test, npm pack) and the test suite do not use git history, and release runs in a separate reusable workflow that keeps fetch-depth: 0.
• The shared frontend-release-npm.yml serializes releases with its own release-<repo>-main concurrency group (cancel-in-progress: false), so concurrent main CI runs do not create a publish race.

Changes:

• Switch the concurrency group so pull requests group by github.ref (cancelling superseded runs) while push/dispatch group by github.run_id (each run completes independently).
• Remove fetch-depth: 0 from the verify checkout, relying on the scan action to deepen its own clone when needed.

File	Description
.github/​workflows/​ci.yml	Per-run concurrency group for push/dispatch (per-ref for PRs) so every pushed range is scanned, and a shallow verify checkout since the scan deepens its own clone.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.