[forgetso]

What was broken

main requires exactly one status check to pass before a PR can merge, and it is called check.

Seven separate workflows each published a job called check — changesets, cypress, lint, pinned-versions, provider_image, tests and typecheck. When several check runs share a name, GitHub merges them into one context and takes the answer from whichever finished first. That was always the cheapest one. So a PR could go green and merge while the tests, the typecheck and the lint were all still running, or had already failed.

The comments in those workflows actually described this as a feature: a docs-only PR skips the path-filtered jobs, so changesets' unfiltered check was there to stop the PR hanging forever. It did do that. It was also the hole.

What changed

Each of the seven is now named after its own workflow, so no two report the same context. A new required-check workflow takes over the check name and earns it: it has no path filter, runs on every non-draft PR, and waits for every other check run on the commit, failing if any of them failed.

The dev and staging rulesets used to require the same context. Both branches are dead — dev last committed 2024-07, staging 2025-07 — so those rulesets were deleted separately and this workflow is scoped to main and release/*.

The aggregator is the one that can be required precisely because it always reports. The others can't be — they are path-filtered, and a required context that never reports blocks the PR forever.

Two other workflows also shared a name (build, in android-webview and ios-webview), so they are renamed too. That matters because the aggregator de-duplicates by name, so a shared name would hide one of them.

Also in here: this repo had no security scanning

Not a scan of any kind. Dependabot opens PRs for known-bad versions, which is useful, but it is not a scan and it gates nothing.

Added, on every PR plus a weekly full-history run:

• gitleaks — committed credentials
• semgrep — static analysis
• npm audit and cargo audit — known-vulnerable dependencies

All of it runs on GitHub-hosted runners rather than our own machines, because this repo is public and a fork PR would otherwise execute a contributor's code on hardware we own. Hosted runners are free and unlimited on public repos.

.gitleaks.toml tunes the scanner to what is actually secret here. The entropy heuristic flags every site key, and a site key is a public identifier — it is in the HTML of every page that loads the widget. Those are allowlisted by the shape of the value rather than by directory, so a real credential dropped into an allowlisted folder still gets reported.

Test coverage

Run locally against the real tree before opening this:

Check	Result
gitleaks, full history (11,868 commits)	no leaks found, exit 0
gitleaks, PR-range mode	no leaks found
npm audit --audit-level=critical (the gating level)	exit 0 — 19 advisories, none critical
cargo audit, native-ja4	clean, 35 dependencies
cargo audit, native-merkle	clean, 33 dependencies
every workflow file parses as YAML	pass
aggregator shell script, bash -n	pass
no two PR jobs share a display name	verified across all 20 workflows

The npm audit and semgrep gates are deliberately set so they cannot fail on debt that already exists — npm audit gates at critical and reports high, semgrep only reports findings a PR introduces. Otherwise every unrelated PR gets blocked by a backlog its author did not create, and the job gets deleted instead of the debt getting paid.

🤖 Generated with Claude Code

[forgetso]

Heads up on the red check: the failing jobs are the Android ones, and they are not caused by this PR.

This PR's entire change to those workflow files is a single name: line. The failure is inside android-actions/setup-android@v4, at the "Set up Android SDK" step, before any of our code runs:

Found preinstalled sdkmanager in /usr/local/lib/android/sdk/cmdline-tools/latest
Wrong version in preinstalled sdkmanager
[command] .../cmdline-tools/20.0/bin/sdkmanager --licenses
6 of 7 SDK package licenses not accepted.
...
All SDK package licenses accepted
Error: The process '.../sdkmanager' failed with exit code 1

Three jobs across two repos fail identically at that same step. The action's v4 tag has not moved since 2026-04-04, so the change is on GitHub's runner image side — the preinstalled Android cmdline-tools version moved and the action's licence-acceptance path no longer exits 0. The last green run of this job was 2026-09-10.

So this is pre-existing breakage that was previously invisible: the old gate took its answer from whichever same-named check reported first, so a broken Android job did not stop anything. The new aggregator noticing it is the change working, not a regression.

Fixing it looks like a one-line cmdline-tools-version input, but it is an unrelated toolchain change and I would rather not land it inside the PR that an auditor will read as the evidence for the branch-protection and scanning controls. Happy to raise it separately.