[Bug] The only machine that runs the quality gate is not on the pinned toolchain

brenno commented

2026-07-22 16:18:15 +00:00

Owner

Found in the pre-publication security review, confirmed by a second reviewer.

Evidence: .tool-versions pins flutter 3.44.6-stable; README.md:46, docs/BUILD.md:18 and .github/workflows/ci.yml:35,132,193 all name 3.44.6. But flutter --version on the machine where the gates actually run reports:

Flutter 3.44.2 • channel [user-branch] • unknown source

with binaries under /opt/homebrew/Caskroom/flutter/3.29.0/ — a third version number in the path. Because there is no CI runner, this machine is the only place make check has ever run.

Why this matters now: every green gate the publication rests on — and COMPLIANCE.md QA.04, "repeatable test procedures" — was produced on a toolchain that is not the documented one, from an unofficial channel. That is not a theoretical difference: an analyzer or formatter change between 3.44.2 and 3.44.6 means "make check is green" proves something other than what the documentation promises. It is also among the first things a reviewer reproduces.

Related: CONTRIBUTING.md:24-28 demands 3.44.6 exactly, arguing that dart format reflows between releases — a prerequisite stricter than the one the maintainer meets, which sends a newcomer off to reinstall a toolchain for a problem they would not have hit. Consider relaxing it to "3.44.x; the pin in .tool-versions is what the maintainer runs, and a format-check failure on an untouched file means your dart format differs — that is the only symptom."

Proposal: install 3.44.6-stable through the official channel (or asdf/fvm per .tool-versions), re-run make check-full once, and record in docs/CHECKS.md the exact flutter --version that produced the snapshot table. While there, add the measured gate duration (~3 minutes) — nowhere does any document say it is that cheap, and a reader facing "5,627 tests plus a coverage floor plus eight ratchets" reasonably assumes half an hour and never tries.

Found in the pre-publication security review, confirmed by a second reviewer. **Evidence:** `.tool-versions` pins `flutter 3.44.6-stable`; `README.md:46`, `docs/BUILD.md:18` and `.github/workflows/ci.yml:35,132,193` all name 3.44.6. But `flutter --version` on the machine where the gates actually run reports: Flutter 3.44.2 • channel [user-branch] • unknown source with binaries under `/opt/homebrew/Caskroom/flutter/3.29.0/` — a third version number in the path. Because there is no CI runner, this machine is the only place `make check` has ever run. **Why this matters now:** every green gate the publication rests on — and `COMPLIANCE.md` QA.04, "repeatable test procedures" — was produced on a toolchain that is not the documented one, from an unofficial channel. That is not a theoretical difference: an analyzer or formatter change between 3.44.2 and 3.44.6 means "make check is green" proves something other than what the documentation promises. It is also among the first things a reviewer reproduces. Related: `CONTRIBUTING.md:24-28` demands 3.44.6 *exactly*, arguing that `dart format` reflows between releases — a prerequisite stricter than the one the maintainer meets, which sends a newcomer off to reinstall a toolchain for a problem they would not have hit. Consider relaxing it to "3.44.x; the pin in `.tool-versions` is what the maintainer runs, and a format-check failure on an untouched file means your `dart format` differs — that is the only symptom." **Proposal:** install 3.44.6-stable through the official channel (or asdf/fvm per `.tool-versions`), re-run `make check-full` once, and record in `docs/CHECKS.md` the exact `flutter --version` that produced the snapshot table. While there, add the measured gate duration (~3 minutes) — nowhere does any document say it is that cheap, and a reader facing "5,627 tests plus a coverage floor plus eight ratchets" reasonably assumes half an hour and never tries.

brenno added the

bug

label

2026-07-22 16:18:15 +00:00

brenno referenced this issue from a commit

2026-07-22 17:10:07 +00:00

docs: haal negen achterhaalde beweringen uit de publieke teksten

brenno referenced this issue

2026-07-22 17:13:34 +00:00

docs: haal negen achterhaalde beweringen uit de publieke teksten #655

brenno commented

2026-07-22 17:19:15 +00:00

Author

Owner

Opgelost in `cc00070` (PR #655).

De bullet zegt nu dat er geen applicatie-backend voor bewerken is, en dat het ene optionele server-onderdeel de CORS-fetch-proxy van de webbuild is die alleen ruwe bytes doorgeeft, met een verwijzing naar ARCHITECTURE.md. Daarmee spreekt docs/FAQ.md zichzelf niet langer twee secties verderop tegen.

Opgelost in \`cc00070\` (PR #655). De bullet zegt nu dat er geen applicatie-backend voor bewerken is, en dat het ene optionele server-onderdeel de CORS-fetch-proxy van de webbuild is die alleen ruwe bytes doorgeeft, met een verwijzing naar ARCHITECTURE.md. Daarmee spreekt `docs/FAQ.md` zichzelf niet langer twee secties verderop tegen.

brenno closed this issue

2026-07-22 17:19:15 +00:00

brenno commented

2026-07-22 17:32:08 +00:00

Author

Owner

Ten onrechte gesloten — dit is niet gedaan. Excuses.

Ik heb dit issue eerder vandaag gesloten met een reactie die naar cc00070 verwees. Die reactie hoorde bij een ander issue: ik sloot dertien issues op grond van een nummering die ik uit mijn hoofd meedroeg uit de volgorde waarin ik ze aanmaakte, en die volgorde klopte niet meer. Ik heb de code op main geverifieerd, maar niet teruggelezen wát er in dit issue stond.

Er is aan dit punt niets veranderd. Het staat weer open, ongewijzigd.

**Ten onrechte gesloten — dit is niet gedaan.** Excuses. Ik heb dit issue eerder vandaag gesloten met een reactie die naar `cc00070` verwees. Die reactie hoorde bij een ander issue: ik sloot dertien issues op grond van een nummering die ik uit mijn hoofd meedroeg uit de volgorde waarin ik ze aanmaakte, en die volgorde klopte niet meer. Ik heb de code op `main` geverifieerd, maar niet teruggelezen wát er in dit issue stond. Er is aan dit punt niets veranderd. Het staat weer open, ongewijzigd.

brenno reopened this issue

2026-07-22 17:32:08 +00:00

brenno added the

in-progress

label

2026-07-22 20:33:06 +00:00

brenno referenced this issue

2026-07-22 20:36:03 +00:00

docs(toolchain): schrijf op waarop de poort echt draait, en hoe lang hij duurt (#598) #685

brenno referenced this issue from a commit

2026-07-22 20:36:03 +00:00

docs(toolchain): schrijf op waarop de poort echt draait, en hoe lang hij duurt (#598)

brenno removed the

in-progress

label

2026-07-22 20:36:20 +00:00

brenno referenced this issue from a commit

2026-07-22 20:36:20 +00:00

Merge pull request 'docs(toolchain): schrijf op waarop de poort echt draait, en hoe lang hij duurt (#598)' (#685) from docs/toolchain-598 into main

brenno commented

2026-07-22 20:36:20 +00:00

Author

Owner

Twee van de vier punten opgelost (PR #685), op main. Het issue blijft open voor de installatie.

Wat er nu staat. docs/CHECKS.md noemde 3.44.2 als terzijde; het staat er nu als wat het is, mét de volledige flutter --version in een codeblok: 3.44.2 • channel [user-branch] • unknown source, binaries onder /opt/homebrew/Caskroom/flutter/3.29.0/, tegenover een pin die 3.44.6-stable zegt. Opgeschreven in plaats van stilletjes rechtgezet — de lezer hoort te weten welk van die twee getallen werkelijk gedraaid heeft, en dat is precies wat COMPLIANCE.md QA.04 belooft.

En de duur staat erbij, gemeten: de suite doet 2:04 (5.768 tests, 2 overgeslagen), de poort als geheel ongeveer drie minuten. Dat was de goedkoopste van je vier punten en misschien de nuttigste: nergens stond dat het zo goedkoop is, en "5.700 tests plus een dekkingsvloer plus acht ratchets" leest als een half uur.

CONTRIBUTING.md is versoepeld naar 3.44.x, met jouw formulering als basis: het enige symptoom dat de pin moet voorkomen staat er herkenbaar bij.

Wat er niet in zit: 3.44.6-stable installeren en make check-full daarop opnieuw draaien. Dat verandert de ontwikkelomgeving van deze machine en is niet iets wat ik onderweg doe. Zodra dat gebeurd is kan de waarschuwing in CHECKS.md eruit; daarvoor blijft dit open.

Twee van de vier punten opgelost (PR #685), op main. **Het issue blijft open** voor de installatie. **Wat er nu staat.** `docs/CHECKS.md` noemde 3.44.2 als terzijde; het staat er nu als wat het is, mét de volledige `flutter --version` in een codeblok: `3.44.2 • channel [user-branch] • unknown source`, binaries onder `/opt/homebrew/Caskroom/flutter/3.29.0/`, tegenover een pin die 3.44.6-stable zegt. Opgeschreven in plaats van stilletjes rechtgezet — de lezer hoort te weten welk van die twee getallen werkelijk gedraaid heeft, en dat is precies wat COMPLIANCE.md QA.04 belooft. **En de duur staat erbij, gemeten:** de suite doet 2:04 (5.768 tests, 2 overgeslagen), de poort als geheel ongeveer drie minuten. Dat was de goedkoopste van je vier punten en misschien de nuttigste: nergens stond dat het zo goedkoop is, en "5.700 tests plus een dekkingsvloer plus acht ratchets" leest als een half uur. **`CONTRIBUTING.md` is versoepeld** naar 3.44.x, met jouw formulering als basis: het enige symptoom dat de pin moet voorkomen staat er herkenbaar bij. **Wat er niet in zit:** 3.44.6-stable installeren en `make check-full` daarop opnieuw draaien. Dat verandert de ontwikkelomgeving van deze machine en is niet iets wat ik onderweg doe. Zodra dat gebeurd is kan de waarschuwing in CHECKS.md eruit; daarvoor blijft dit open.

brenno commented

2026-07-23 07:52:18 +00:00

Author

Owner

Stand nagekeken: het repo-deel is al af, van eerdere rondes.

docs/CHECKS.md legt de werkelijk draaiende toolchain vast (Flutter 3.44.2 • channel [user-branch], met de volle uitleg dat dit níét de gepinde is en waarom dat telt), verwijst naar dit issue, én noemt de gemeten poortduur (~3 minuten). Precies je twee documentatievoorstellen.
CONTRIBUTING.md is versoepeld van "3.44.6 exactly" naar "3.44.x", met je eigen redenering: de pin is wat de beheerder draait, en een format-check die op een onaangeraakt bestand valt is het énige symptoom dat je dart format afwijkt.

flutter --version op deze machine zegt nog steeds 3.44.2 ([user-branch], binaries onder /opt/homebrew/Caskroom/flutter/3.29.0/). Wat dus rest is de kern: de gepinde 3.44.6-stable via het officiële kanaal (of asdf/fvm per .tool-versions) installeren, actief maken, en make check-full één keer opnieuw draaien om de snapshot-tabel te verversen.

Dat raakt je hele ontwikkelomgeving — een andere brew-cask/asdf-toolchain, en het verzet de actieve flutter. Dat doe ik niet ongevraagd op jouw machine. Zeg het als je wilt dat ik je erdoorheen loods of het onder jouw toezicht uitvoer; anders laat ik dit als de enige openstaande stap bij jou. Alles eromheen klopt.

Stand nagekeken: het repo-deel is al af, van eerdere rondes. - `docs/CHECKS.md` legt de werkelijk draaiende toolchain vast (`Flutter 3.44.2 • channel [user-branch]`, met de volle uitleg dat dit níét de gepinde is en waarom dat telt), verwijst naar dit issue, én noemt de gemeten poortduur (~3 minuten). Precies je twee documentatievoorstellen. - `CONTRIBUTING.md` is versoepeld van "3.44.6 exactly" naar "3.44.x", met je eigen redenering: de pin is wat de beheerder draait, en een format-check die op een onaangeraakt bestand valt is het énige symptoom dat je `dart format` afwijkt. `flutter --version` op deze machine zegt nog steeds **3.44.2** (`[user-branch]`, binaries onder `/opt/homebrew/Caskroom/flutter/3.29.0/`). Wat dus rest is de kern: de gepinde **3.44.6-stable** via het officiële kanaal (of asdf/fvm per `.tool-versions`) installeren, actief maken, en `make check-full` één keer opnieuw draaien om de snapshot-tabel te verversen. Dat raakt je hele ontwikkelomgeving — een andere brew-cask/asdf-toolchain, en het verzet de actieve `flutter`. Dat doe ik niet ongevraagd op jouw machine. Zeg het als je wilt dat ik je erdoorheen loods of het onder jouw toezicht uitvoer; anders laat ik dit als de enige openstaande stap bij jou. Alles eromheen klopt.

brenno referenced this issue

2026-07-23 08:07:22 +00:00

[Feature] lib/services has 93 flat files and a parts/ directory mixing four libraries #632

brenno referenced this issue

2026-07-23 08:23:12 +00:00

refactor(services): los lib/services/parts/ op in onderwerpmappen (#632) #713

brenno commented

2026-07-23 08:23:50 +00:00

Author

Owner

De toolchain is vervangen, en de kern van dit issue is daarmee grotendeels weg.

flutter --version op de machine zegt nu:

Flutter 3.44.7 • channel stable • https://github.com/flutter/flutter.git

Waar het bij het melden 3.44.2 • channel [user-branch] • unknown source was, met binaries onder een derde versienummer. Het niet-officiële kanaal — je zwaarste punt, want dat maakte "de poort is groen" een uitspraak over een toolchain die niemand kon reproduceren — is daarmee opgelost. Het is nu officieel stable, uit de echte repo.

Wat overblijft is één patch verschil: .tool-versions pint 3.44.6-stable, de machine draait 3.44.7. Onder de versoepelde CONTRIBUTING-regel ("3.44.x") is dat toegestaan, dus dit is geen blokkade meer maar een keuze: de pin optrekken naar 3.44.7, of de machine terugzetten op 3.44.6.

Bewezen dat het werkt: ik heb de volledige poort er meteen op gedraaid voor PR #713 — make check groen (5837 tests), make test-golden groen (33), check-secrets en sast schoon. Dat is de eerste keer dat een groene poort op deze repo op een officiële stable-toolchain staat. En omdat 3.44.7 een nieuwere dart format heeft dan waarop dat werk geschreven was, is de opmaakpoort daar meteen op meebevestigd — precies de reflow waar CONTRIBUTING voor waarschuwt, en die deed zich niet voor.

Wat er nog te doen is, en het is klein: docs/CHECKS.md draagt nog de oude momentopname (3.44.2, user-branch, met de uitleg waarom dat telt). Die alinea klopt niet meer. Zeg maar of je de pin op 3.44.7 wilt of de machine op 3.44.6; dán werk ik CHECKS.md bij met een verse tabel op de definitieve toolchain, en kan dit issue dicht.

**De toolchain is vervangen, en de kern van dit issue is daarmee grotendeels weg.** `flutter --version` op de machine zegt nu: ``` Flutter 3.44.7 • channel stable • https://github.com/flutter/flutter.git ``` Waar het bij het melden `3.44.2 • channel [user-branch] • unknown source` was, met binaries onder een derde versienummer. Het **niet-officiële kanaal** — je zwaarste punt, want dat maakte "de poort is groen" een uitspraak over een toolchain die niemand kon reproduceren — is daarmee opgelost. Het is nu officieel stable, uit de echte repo. Wat overblijft is één patch verschil: `.tool-versions` pint `3.44.6-stable`, de machine draait `3.44.7`. Onder de versoepelde CONTRIBUTING-regel ("3.44.x") is dat toegestaan, dus dit is geen blokkade meer maar een keuze: de pin optrekken naar 3.44.7, of de machine terugzetten op 3.44.6. **Bewezen dat het werkt:** ik heb de volledige poort er meteen op gedraaid voor PR #713 — `make check` groen (5837 tests), `make test-golden` groen (33), `check-secrets` en `sast` schoon. Dat is de eerste keer dat een groene poort op deze repo op een officiële stable-toolchain staat. En omdat 3.44.7 een nieuwere `dart format` heeft dan waarop dat werk geschreven was, is de opmaakpoort daar meteen op meebevestigd — precies de reflow waar CONTRIBUTING voor waarschuwt, en die deed zich niet voor. **Wat er nog te doen is, en het is klein:** `docs/CHECKS.md` draagt nog de oude momentopname (3.44.2, user-branch, met de uitleg waarom dat telt). Die alinea klopt niet meer. Zeg maar of je de pin op 3.44.7 wilt of de machine op 3.44.6; dán werk ik CHECKS.md bij met een verse tabel op de definitieve toolchain, en kan dit issue dicht.

brenno referenced this issue

2026-07-23 10:56:32 +00:00

build(toolchain): één Flutter op de machine, de laatste stable, en een poort erop (#598) #723

brenno referenced this issue from a commit

2026-07-23 10:56:32 +00:00

build(toolchain): één Flutter op de machine, de laatste stable, en een poort erop

brenno referenced this issue from a commit

2026-07-23 10:56:39 +00:00

Merge pull request 'build(toolchain): één Flutter op de machine, de laatste stable, en een poort erop (#598)' (#723) from fix/toolchain-poort-598 into main

brenno commented

2026-07-23 10:57:03 +00:00

Author

Owner

Opgelost op main: 7ad0d67a (PR #723). Alle vier je punten, plus de oorzaak die niemand had gevonden.

De oorzaak was PATH-volgorde, geen ontbrekende installatie. In ~/.zshrc stond $HOME/flutter/bin op regel 11, en tien regels lager zette "Zet Homebrew correct" /opt/homebrew/bin er alsnog vóór. De cask won dus altijd. Dat verklaart ook het derde versienummer waar je over viel: --version zei 3.44.2 terwijl het pad Caskroom/flutter/3.29.0/ heette. Die regel staat nu als laatste in .zshrc, mét de reden erbij.

De machine draait nu:

Flutter 3.44.7 • channel stable • https://github.com/flutter/flutter.git
Tools • Dart 3.12.2

Uit het officiële release-archief, met de sha256 getoetst tegen releases_macos.json vóór het uitpakken. De brew-cask is verwijderd — er staat nu precies één Flutter op deze machine.

De pin ging omhoog, niet de machine omlaag. 3.44.7 is de laatste stable (20-07-2026); .tool-versions, README, BUILD.md, CONTRIBUTING en de acht plekken in beide workflows staan er nu op. De SBOM droeg de SDK-versie en is meegegaan — die viel meteen rood, wat precies de bedoeling van die poort is.

En er staat nu een poort op, want dit was twee keer onopgemerkt ontstaan en dát is het echte gebrek. make check-toolchain eist kanaal stable, de officiële repository, en de versie exact gelijk aan de pin. Elk van de drie is apart fataal en alle gebreken worden in één run gemeld. Daarbovenop moet de toolchain in docs/CHECKS.md staan, zodat een pin-verhoging de documentatie niet achterlaat.

Op één punt ben ik je voorstel niet gevolgd, en de andere kant op. Je stelde voor CONTRIBUTING.md te versoepelen naar "3.44.x", omdat de eis strenger was dan wat de beheerder zelf haalde. Dat is gisteren ook gebeurd. Het antwoord op een beheerdersmachine met een onreproduceerbare build is echter de machine repareren, niet de regel voor iedereen verruimen — en dart format reflowt tussen releases, dus een groene opmaakpoort op een buurversie zegt iets over een andere formatter dan CI draait. CONTRIBUTING is weer exact, nu met een machine die eraan voldoet, plus de regel die eronder ligt: één Flutter per machine, niet één per project.

Je documentatiepunten zaten al in eerdere rondes: docs/CHECKS.md legt de draaiende toolchain vast (nu de goede) en noemt de gemeten poortduur van ~3 minuten.

Daarmee is dit issue rond. Sluiten.

Opgelost op main: `7ad0d67a` (PR #723). Alle vier je punten, plus de oorzaak die niemand had gevonden. **De oorzaak was PATH-volgorde, geen ontbrekende installatie.** In `~/.zshrc` stond `$HOME/flutter/bin` op regel 11, en tien regels lager zette "Zet Homebrew correct" `/opt/homebrew/bin` er alsnog vóór. De cask won dus altijd. Dat verklaart ook het derde versienummer waar je over viel: `--version` zei 3.44.2 terwijl het pad `Caskroom/flutter/3.29.0/` heette. Die regel staat nu als laatste in `.zshrc`, mét de reden erbij. **De machine draait nu:** ``` Flutter 3.44.7 • channel stable • https://github.com/flutter/flutter.git Tools • Dart 3.12.2 ``` Uit het officiële release-archief, met de sha256 getoetst tegen `releases_macos.json` vóór het uitpakken. De brew-cask is verwijderd — er staat nu precies één Flutter op deze machine. **De pin ging omhoog, niet de machine omlaag.** 3.44.7 is de laatste stable (20-07-2026); `.tool-versions`, README, BUILD.md, CONTRIBUTING en de acht plekken in beide workflows staan er nu op. De SBOM droeg de SDK-versie en is meegegaan — die viel meteen rood, wat precies de bedoeling van die poort is. **En er staat nu een poort op**, want dit was twee keer onopgemerkt ontstaan en dát is het echte gebrek. `make check-toolchain` eist kanaal `stable`, de officiële repository, en de versie **exact** gelijk aan de pin. Elk van de drie is apart fataal en alle gebreken worden in één run gemeld. Daarbovenop moet de toolchain in `docs/CHECKS.md` staan, zodat een pin-verhoging de documentatie niet achterlaat. **Op één punt ben ik je voorstel niet gevolgd, en de andere kant op.** Je stelde voor `CONTRIBUTING.md` te versoepelen naar "3.44.x", omdat de eis strenger was dan wat de beheerder zelf haalde. Dat is gisteren ook gebeurd. Het antwoord op een beheerdersmachine met een onreproduceerbare build is echter de machine repareren, niet de regel voor iedereen verruimen — en `dart format` reflowt tussen releases, dus een groene opmaakpoort op een buurversie zegt iets over een andere formatter dan CI draait. CONTRIBUTING is weer exact, nu met een machine die eraan voldoet, plus de regel die eronder ligt: **één Flutter per machine, niet één per project.** **Je documentatiepunten** zaten al in eerdere rondes: `docs/CHECKS.md` legt de draaiende toolchain vast (nu de goede) en noemt de gemeten poortduur van ~3 minuten. Daarmee is dit issue rond. Sluiten.

brenno closed this issue

2026-07-23 10:57:03 +00:00

brenno referenced this issue from a commit

2026-07-23 11:03:50 +00:00

fix(poort): de vijftien versie-eisen moeten het eens zijn (#721)

brenno referenced this issue

2026-07-23 11:04:20 +00:00

De Flutter-pin (3.44.6) loopt achter op de bouwmachine (3.44.7), en niets bewaakt dat de dertien plekken die hem noemen het eens zijn #721

brenno referenced this issue

2026-07-23 11:25:05 +00:00

fix(toolchain): pin naar Flutter 3.44.7, en bewaak dat alle plekken meebewegen (#598, #721) #728

brenno referenced this issue from a commit