Krzysztof kuhy Rudnicki 98213cbc40 Check the toolchain versions CI actually installs, not just the ones declared ... `.fvmrc` is a declaration nothing in this fleet reads. `subosito/flutter-action` takes its own `flutter-version:`, and that pin is what the runner installs, so the two drift in silence and the failure mode is the worst kind: green locally, red in CI, with no diff to explain it. kuhylog is the live case. Its runner is on Flutter **3.44.9**, which predates the `@awaitNotRequired` annotation, so `unawaited(Navigator.push(...))` is `unnecessary_unawaited` on 3.47.2 here and `discarded_futures` there -- the two SDKs demand opposite code and CI went red on a commit that is clean locally. The fleet is spread across 3.44.6, 3.44.8, 3.47.0 and 3.47.1 with no one tracking it. So a workflow's `flutter-version:` / `node-version:` is now a dependency like any other, judged against the same latest stable. That needs no separate "these must agree" rule: two values both required to equal latest already agree. A channel name and a `${{ }}` expression are skipped -- one is not a version, the other resolves at run time and guessing is worse than silence. Found real drift on its first run: both TypeScript workflows here pinned `node-version: 24`, a floating major that lets two runs of the same commit install different Node. Now 24.20.0. 321 tests, 100% branch coverage on every production module. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CRykabMwPgDzFHcARoqpaK		2026-08-28 15:04:00 +02:00
..
workflows	Check the toolchain versions CI actually installs, not just the ones declared	2026-08-28 15:04:00 +02:00