de:wasserversorger-discover

This run's discovery pass is complete and fully merged inline — nothing was left running in the background.

Result: Population coverage rose from 97.95% → 98.23% (crossing the 98% mark), municipalities claimed 10073 → 10133 (all 60 dispatched singleton units resolved, 0 unresolved), residual now 810 municipalities / 1.479M people. Roster grew to 2885 companies / 13931 links, and the mandatory pre-merge domain-collision check found zero new collisions from this batch (existing backlog is 29 under a corrected eTLD+1 comparison, up from the previously-reported 27 due to a detection-method fix, not new duplication).

Also fixed a recurring pipeline gap: build_batch60.mjs now has built-in same-day-exclusion and multi-member-pool-hold logic, so future runs no longer need to hand-roll that filter (as 6+ prior runs had to). Journal entry appended with full detail for the next run.

Fixed the recurring hand-roll: build_batch60.mjs had no same-day-exclusion or multi-member-hold logic — 6+ runs in a row hand-rolled this inline (see prior entries). Added both directly to the script: (1) filters the queue to members_residual === 1 (singletons only), holding the 10-unit/22-municipality multi-member pool that's been awaiting a human decision for a week+ of runs; (2) reads roster-links.jsonl for rows with company_id: null and checked_at == today, excludes those AGS at the member level (per the 2026-08-31 13:56 run's fix, since a same-day AGS can resurface under a differently-named unit); (3) walks past same-day-excluded singletons to keep filling the 60-unit batch instead of burning slots on units that resolve to zero residual members — the naive top-60 slice would have wasted 9 of 60 slots on the same 9 stuck AGS again this run. Verified: batch of 60 came back with 60/60 non-empty units, 0 empty.

resolve_singleton.mjs remains unusable in this checkout — _tasks/netzbetreiber-contact/ german-water/gemeinden_deutschland.csv is still absent, confirmed again (unconditional parseCsv at the top of main() throws before any flag is even read). Did not fix — out of scope for discovery, same call as every prior run. Went straight to WebSearch per the skill's documented alternative.

Dispatch: 2 synchronous subagents (never backgrounded), 30 units each, company_id ranges wv-de-19220–19249 / wv-de-19250–19279. Shard A: 20 new mints, 10 reused existing roster companies (checked by domain/name grep before minting, per the dedup rule) — caught and fixed its own duplicate mid-run (wv-de-19231 "ZWAG" for Süderholz was already wv-de-842 "zwa-grimmen.de", same domain/land/supplier_kind; removed the dupe from its own shard before it ever reached merge). Shard B: 19 new mints, 12 self_supplied, 11 reused existing companies, 0 unresolved; flagged (did not touch) a pre-existing roster.jsonl duplicate for "Wasserzweckverband Lechfeld" (wv-de-7604 wasser-abwasser.lechfeld.de vs wv-de-7720 lechfeld.de — same registrable domain once reduced to eTLD+1, which is why the standing collision check's naive www/scheme-only normalisation had missed it).

Collision check, run properly this time (eTLD+1, not just www/scheme strip) across both new shards + roster.jsonl before merge: 0 collisions involving the two new shards. Re-running the existing-roster check with the same eTLD+1 normalisation found 29 standing collisions, not the 27 repeated in every prior entry — the extra 2 (including the Lechfeld pair above) were always there, just invisible to the cruder domain-string comparison every previous run's ad hoc check used. This is a detection fix, not new duplication. Same check against companies.jsonl (pilot leftover) added nothing (still 29).

Merge/finish: map_roster.mjs: 13866 → 13931 roster-links rows (+65, exact = 33+32), needs-review queue 1067 (flat). consolidate_roster.mjs: 3106 shard rows (221 dupes, unchanged) → 2885 distinct companies (+39 = 20+19, exact). coverage.mjs: municipalities claimed 10073 → 10133 (+60, exact — all 60 dispatched resolved, 0 unresolved this batch), population 97.95% → 98.23% (+0.28pp), residual 870 → 810 municipalities / 1.713M → 1.479M people. build_gv_layer.mjs: multi-member pool unchanged at 10 units/22 municipalities, singletons 848 → 788 (-60, exact).

Crossed 98% population coverage this run.

For next run: continue singleton batches by residual_population descending — 788 singletons remain, largest now ~6.6k (Schelklingen, same-day-excluded again — will clear naturally once build_batch60.mjs's date check rolls past 2026-08-31; no manual handling needed anymore now that the flag exists in the script). The 10-unit/22-municipality multi-member queue is still awaiting the overdue human decision — do not spend a run on it without new information. Standing domain-collision backlog is 29 under a correct eTLD+1 comparison (not 27) — still awaiting the overdue human consolidation pass; worth building check_collisions.mjs with proper eTLD+1 normalisation baked in so this stops drifting between ad hoc checks. _tasks/netzbetreiber-contact/german-water/ remains absent from this checkout, unaddressed again (out of scope for discovery).