[cunninghamcard-bit]

Requested by li · project thread

Before: every pull request ran all 24 jobs, five of them on macOS, whatever it changed. A documentation-only pull request or master push ran the whole workflow too, about 92 runner-minutes; the four RFC and roadmap merges on 2026-10-15 queued four full runs one after another. The free plan runs at most five macOS jobs at a time across all open pull requests, so one change to a single binding waited behind everybody's macOS legs.

After: a pull request runs only the jobs its change can affect, on Linux unless it touches something platform-specific.

The pull request changes	Jobs that run
Only documentation (top-level Markdown, docs/, rfc/, assets/)	none; CI result passes
Only bindings/<name>/	that binding's jobs and contract tests
aimux-ffi/	Rust core, aimux-ffi, the bindings that link the C ABI (Java, Kotlin, Go, Flutter and its example, Swift), contract tests
Anything else (Rust crates, tools, scripts, fixtures, Cargo manifests, workflows, any .gitattributes)	every job

docs/api/providers.md is generated and checked by contract tests, so it counts as code. Node and Python link the Rust crates directly, not the C ABI, so an aimux-ffi/ change does not run them.

The macOS and Windows legs of the Node, aimux-ffi, Go and Flutter example jobs are added only when the change touches the C ABI, the Node, Go, Flutter or Swift bindings, a Cargo manifest, a build script, a .gitattributes, the toolchain or the workflows. The Rust code itself is platform-neutral (rustls, no platform cfg outside tools/). A change to the shared Rust code still runs the Windows x64 Node tests, the only job that runs that code on Windows. Swift contract tests are macOS-only and run whenever their row says so; they caught a stack overflow no Linux job hit.

Pushes to master run everything when code changed, as the AI SDK does, so a platform problem shows up on master at the latest. A documentation-only master push still runs nothing. A run with no base to compare with runs everything.

This follows RFC-0043 §9.2: the summary check still runs, a version-controlled path rule decides what is needed, and a skipped job never counts as a pass by itself. It is based on master so it can land before #262; #262 then merges master and applies the same rules to its reorganized jobs.

How

• A changes job diffs the change against its base (the first parent of the test merge commit for a pull request, the previous head for a push) and writes one JSON map, job name to true or false, plus the matrices of the jobs that have macOS or Windows legs. Matrices are built there because a static exclude cannot drop a leg that include adds back.
• Every build and test job has needs: changes and runs when its entry in the map is true.
• CI result always runs. It passes only when changes succeeded and every job either succeeded or was skipped because the map says it is not needed. A failure, a cancellation, or any other skip fails it, and so does a job missing from the map. It is the one check to require in branch protection.

This is the pattern ruff, uv, rust-analyzer and pydantic-core use. A workflow-level paths filter, as in node or polars, would skip the whole run and leave a required check waiting, which RFC-0043 rules out.

Why skipping is safe

• No binding reads another binding: outside its own directory a binding reads only the Rust crates, contract-tests/, aimux-ffi/ and build output; mentions of other bindings are comments. bindings/node and bindings/python are separate Cargo workspaces that depend on aimux-core, aimux-providers and aimux-provider-utils, not on aimux-ffi, and the Rust workspace does not include any binding.
• No platform cfg in the workspace crates outside tools/ (which this workflow only ever built on Linux), and TLS is rustls. A change to the shared Rust code still runs on all three systems: every job on Linux, the Node x64 tests on Windows, and the Swift contract tests on macOS.
• Replay of history: all 706 completed runs of this workflow from 2026-07-31 to 2026-10-12, with each pull request run's change fed through the new rule. Of the 364 jobs that failed on pull requests, 361 would still run. The other three were not caused by their pull requests: a Windows runner lost on a documentation-only pull request, and two runs on a pull request that touched only bindings/node, bindings/python and the changelog, while master was already red on a clippy error in tools/aimux-web (master's own push run 31920814130 failed the same way).
• What a pull request no longer shows: a job turning red for reasons outside the change (a new release of a dependency, since Cargo.lock is not committed, or a runner image update) is not seen on a pull request that does not run that job. Pushes to master run everything, so it shows up there.

Checks

• 28 pull request scenarios plus push cases run against the real diff logic on a scratch repository: documentation, each binding alone, aimux-ffi/, shared Rust, Cargo manifests, build scripts, nested .gitattributes and the workflow itself. Each checks the job map, the legs and the CI result verdict.
• Four review rounds, including codex; the last round found nothing.
• actionlint is clean.
• The follow-up merge into ci: speed up test builds, deduplicate caches, and use prebuilt cargo-ndk #262 is prepared and passes the same scenarios on ci: speed up test builds, deduplicate caches, and use prebuilt cargo-ndk #262's jobs.
• On this pull request itself the workflow file changes, so every job and every leg ran: 26 of 26 green on cdd499c.