op in onderwerpmappen (#632) #713

Merged

brenno merged 1 commit from refactor/services-parts-opsplitsen-632 into main

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

brenno commented

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

Owner

Voert de ene stap uit die #632 voorschrijft: lib/services/parts/ oplossen.

Waarom die map wegmoest

parts/ was geen onderwerp maar een mechanisme. Hij hield de part-bestanden van vier ongerelateerde libraries door elkaar:

Library	Parts
`file_service.dart`	9
`marp_html_service.dart`	11
`markdown_service.dart`	3
`slide_quality_analyzer.dart`	1

Wie een onbekende repo met ls verkent, kreeg op de vraag "waar hoort dit bij" het antwoord "bij een taalconstructie". Nu staat elke part in een onderwerpmap naast zijn library: file/, marp_html/, markdown_parse/, slide_quality/.

De vorm: minimaal, en waarom

De libraries zelf blijven in services/. Dat is wat het issue voorschrijft ("place each part beside its library"), en het houdt de blast-radius klein: part of '../file_service.dart' blijft ongewijzigd kloppen, omdat de nieuwe map net als parts/ één niveau onder services/ zit. Alleen de part 'parts/…'-regels in de vier libraries wijzigen.

De libraries zélf verplaatsen zou elke import ervan raken — een veel breder conflictoppervlak, en niet wat hier gevraagd werd.

Wat er stil kapot had kunnen gaan

Drie plekken noemden de oude paden hardgecodeerd, en die zouden niet gecompileerd zijn maar gewoon niets meer doen:

tool/check_audience_boundary.dart — registreert exportoppervlakken op pad::symbool en zoekt het bestand met File(...).existsSync(). Ongewijzigd zou die poort stil zijn gaan zwijgen over de pakket- en dossier-export.
test/network_sink_guard_test.dart — padconstanten voor de netwerk-sink-bewaking.
SOURCE_MAP, ARCHITECTURE, PERFORMANCE_GUIDE, API_DOCUMENTATION en drie ontwerpdocs.

Dat is precies de soort schade die een pure verplaatsing gevaarlijk maakt: de compiler zegt niets.

Niet gedaan

De 93 losse bestanden in services/ groeperen. Het issue noemt dat zelf "can follow later, or never"; dit is bewust de ene stap.

Getoetst

make check groen — 5837 tests. make test-golden groen (33). check-secrets en sast schoon.
Uitgevoerd op Flutter 3.44.7 stable, een nieuwere formatter dan waarop de verplaatsing geschreven is. Dat de opmaakpoort daar meteen groen op staat, is een gratis extra bevestiging.

Aantekening bij de toolchain

Deze tak lag een tijd stil omdat de Dart/Flutter-toolchain van de machine mid-sessie uitviel (dart-SDK-cache verdwenen, flutter segfault bij zelfherstel) — de instabiele toolchain uit #598. Hij is inmiddels hersteld, en wel naar 3.44.7 op het officiële stable-kanaal, waar het eerst 3.44.2 op [user-branch] was. Dat verandert de stand van #598 wezenlijk; ik werk dat issue apart bij.

Closes #632

Voert de ene stap uit die #632 voorschrijft: `lib/services/parts/` oplossen. ## Waarom die map wegmoest `parts/` was geen onderwerp maar een **mechanisme**. Hij hield de `part`-bestanden van vier ongerelateerde libraries door elkaar: | Library | Parts | | --- | --- | | `file_service.dart` | 9 | | `marp_html_service.dart` | 11 | | `markdown_service.dart` | 3 | | `slide_quality_analyzer.dart` | 1 | Wie een onbekende repo met `ls` verkent, kreeg op de vraag "waar hoort dit bij" het antwoord "bij een taalconstructie". Nu staat elke part in een onderwerpmap naast zijn library: `file/`, `marp_html/`, `markdown_parse/`, `slide_quality/`. ## De vorm: minimaal, en waarom De libraries zelf blijven in `services/`. Dat is wat het issue voorschrijft ("place each part beside its library"), en het houdt de blast-radius klein: **`part of '../file_service.dart'` blijft ongewijzigd kloppen**, omdat de nieuwe map net als `parts/` één niveau onder `services/` zit. Alleen de `part 'parts/…'`-regels in de vier libraries wijzigen. De libraries zélf verplaatsen zou elke `import` ervan raken — een veel breder conflictoppervlak, en niet wat hier gevraagd werd. ## Wat er stil kapot had kunnen gaan Drie plekken noemden de oude paden **hardgecodeerd**, en die zouden niet gecompileerd zijn maar gewoon *niets meer doen*: - `tool/check_audience_boundary.dart` — registreert exportoppervlakken op `pad::symbool` en zoekt het bestand met `File(...).existsSync()`. Ongewijzigd zou die poort stil zijn gaan zwijgen over de pakket- en dossier-export. - `test/network_sink_guard_test.dart` — padconstanten voor de netwerk-sink-bewaking. - SOURCE_MAP, ARCHITECTURE, PERFORMANCE_GUIDE, API_DOCUMENTATION en drie ontwerpdocs. Dat is precies de soort schade die een pure verplaatsing gevaarlijk maakt: de compiler zegt niets. ## Niet gedaan De 93 losse bestanden in `services/` groeperen. Het issue noemt dat zelf "can follow later, or never"; dit is bewust de ene stap. ## Getoetst - `make check` groen — 5837 tests. `make test-golden` groen (33). `check-secrets` en `sast` schoon. - Uitgevoerd op **Flutter 3.44.7 stable**, een nieuwere formatter dan waarop de verplaatsing geschreven is. Dat de opmaakpoort daar meteen groen op staat, is een gratis extra bevestiging. ## Aantekening bij de toolchain Deze tak lag een tijd stil omdat de Dart/Flutter-toolchain van de machine mid-sessie uitviel (dart-SDK-cache verdwenen, flutter segfault bij zelfherstel) — de instabiele toolchain uit #598. Hij is inmiddels hersteld, en wel naar **3.44.7 op het officiële stable-kanaal**, waar het eerst 3.44.2 op `[user-branch]` was. Dat verandert de stand van #598 wezenlijk; ik werk dat issue apart bij. Closes #632

brenno added 1 commit

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

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

`lib/services/parts/` was geen onderwerp maar een mechanisme: het hield de
`part`-bestanden van vier ongerelateerde libraries door elkaar — `file_service`
(9), `marp_html_service` (11), `markdown_service` (3) en `slide_quality_analyzer`
(1). Wie de repo met `ls` verkent kreeg op "waar hoort dit bij" het antwoord
"bij een taalconstructie".

Elke part staat nu in een onderwerpmap naast zijn library: `file/`, `marp_html/`,
`markdown_parse/`, `slide_quality/`. De libraries zelf blijven in `services/` —
dat is de minimale vorm die het issue voorschrijft, en hij houdt de blast-radius
klein: `part of '../file_service.dart'` blijft ongewijzigd kloppen omdat de
nieuwe map net als `parts/` één niveau onder `services/` zit, dus alleen de
`part 'parts/…'`-regels in de vier libraries wijzigen.

Meeverhuisd omdat ze de oude paden hardgecodeerd noemden: de
audience-boundary-registraties in `tool/check_audience_boundary.dart` (die de
bestanden op pad opzoekt en anders stil niets meer bewaakt), de padconstanten in
`test/network_sink_guard_test.dart`, en de verwijzingen in SOURCE_MAP,
ARCHITECTURE, PERFORMANCE_GUIDE, API_DOCUMENTATION en drie ontwerpdocs.

De 93 losse bestanden in `services/` groeperen is bewust NIET gedaan — dat noemt
het issue "can follow later, or never". Dit is de ene stap: het mechanisme-mapje
weg.

Getoetst nadat de toolchain van de machine hersteld was: `make check` groen
(5837 tests), `make test-golden` groen (33), `check-secrets` en `sast` schoon —
en dat op Flutter 3.44.7 stable, een nieuwere formatter dan waarop de
verplaatsing geschreven is, wat de opmaak meteen meebevestigt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit e92376fd13 into main

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

brenno referenced this pull request from a commit

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

Merge pull request 'refactor(services): los lib/services/parts/ op in onderwerpmappen (#632)' (#713) from refactor/services-parts-opsplitsen-632 into main

brenno referenced this pull request

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

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