de:wasserversorger-discover

Population coverage rose from 94.31% to 94.82% (+0.51pp), municipalities claimed 9502→9562/10943, roster now 2572 companies. All 60 singleton municipalities in this batch resolved cleanly; I also tested a genuine Land-level bulk registry (LWBV) as a new method for the stuck 9-unit multi-member queue but it doesn't cover those specific villages — that queue has now failed 4 different methods and I've recommended routing it to human review rather than continued automated retries. Caught and fixed 6 duplicate-company mints before merging (subagents found the right existing supplier but minted new IDs anyway); domain-collision backlog stayed at the standing 27, no new ones. Journal updated with full details for the next run.

Read CLAUDE.md and journal tail, then SKILL.md in full. On-disk state before starting: 2537 companies, 94.31% population coverage, 9502/10943 municipalities claimed, multi-member pool still exactly 10 units/22 municipalities (unchanged across the prior 3 discover runs) — matched journal exactly after a fresh coverage.mjs/build_gv_layer.mjs.

Tested the bulk-source hypothesis for the multi-member queue one more time, briefly, before committing to another full retry. Found a genuine Land-level registry — LWBV (Landesverband der Wasser- und Bodenverbände Schleswig-Holstein), lwbv.de/lwbv/mitglieder/wasserverbaende/ — lists every Wasserbeschaffungsverband/Wasserverband in SH with contact info. Real bulk source, but it doesn't cover this specific residual set: cross-referenced the 20 SH/TH/BW residual villages (Krems II, Strukdorf, Travenhorst, Lockstedt, Mühlenbarbek, Wiedenborstel, Großharrie, Schillsdorf, Heilshoop, Mönkhagen, Bienstädt, Zimmernsupra, Bothkamp, Wahlstorf, Bendorf, Bornholt, Guggenhausen, Unterwaldhausen, Fredeburg, Kittlitz) against the LWBV list by name — zero direct matches. Per-village WebSearch (as opposed to per-Amt, tried last run) also came up empty; one promising-looking snippet claiming "no central water supply" for Lockstedt/Mühlenbarbek/Wiedenborstel/Sarlhusen could not be traced to an actual page (checked the cited source directly — it said nothing about water), so per hard rule #2 ("a negative must be earned") it was not recorded, just discarded as unverifiable. A candidate Kreis-level page (kreis-pinneberg.de .../Öffentliche+Wasserversorgung.html) 503'd twice and is moot anyway since none of the 9 target units sit in Kreis Pinneberg. Conclusion: this is now a 4th failed method (site-crawl x2, Amt/Verband-name search x1, village-name search + SH-level bulk registry x1) on the same 9 real units (the 10th, Küstengewässer vkey 130009999, is 0-population coastal-shelf artifact, not a real target — flagged again, still not filtered at the source). Recommend this queue stop being retried automatically each run — route the 9 units to the human queue instead. It is 22 municipalities / ~6.9k people total, i.e. a rounding error next to the singleton pool; further automated attempts are very unlikely to be the differential use of a run's time.

Batch: switched to top-60 singletons by residual_population only (build_batch60.mjs unmodified — its population-sort naturally excludes the multi-member queue anyway, since all 10 of those units sit under 1,600 residual_population vs. the batch's ~6,780-person cutoff, so no manual override was needed to deprioritize them this run). Split 30/30, dispatched as shards "shardA-run2026-08-30-0800" / "shardB-run2026-08-30-0800", both subagents run_in_background: false in one message, mandatory no-Agent-tool instruction, full method + schema inlined (still no _tasks/netzbetreiber-contact/german-water/ in this checkout). Company_id ranges wv-de-18700– 18729 / 18730–18759.

Both shards: 30/30 resolved, 0 unresolved — first fully-clean batch in a while, expected since these are ~6,800–7,800-person singleton towns (well-documented one-Stadtwerke-per-town regime), not the genuinely hard residual. Shard A: 17 new companies, reused 10 existing roster companies (caught via a systematic domain-collision pass, not just a name grep — worth noting since name-only grepping missed all 10 on a first pass per the subagent's own report). Notable finds: Ruhstorf a.d.Rott genuinely split between two Zweckverbände (2 link rows, not a guessed boundary); Immenhausen initially looked self-supplied but a closer check found a real Zweckverband (ZKD Immenhausen-Espenau) with its own Satzung; Bad Sachsa's water supply legally moved from Stadtwerke Bad Sachsa GmbH to the Stadt itself on 2025-01-01 (Harz Energie is contracted network operator only, correctly not credited as supplier). New host trap: zkd-immenhausen-espenau.de has an expired TLS cert (WebFetch fails, curl -k confirms the site is real).

Duplicate mints caught before merge: the mandatory domain-collision check across every roster.part-*.jsonl shard found 6 new collisions, all in shard B, all the same failure mode — the subagent found the correct existing regional supplier but minted a new company_id instead of reusing it despite its own report claiming it had checked: kat-artern.de (new wv-de-18731 duped existing wv-de-1401, KAT), stadtwerke-huntetal.de (new wv-de-18735 duped wv-de-2201), ovag.de (new wv-de-18739 duped wv-de-18509), rzv-glauchau.de (new wv-de-18743 duped wv-de-3494), zv-owv.de (new wv-de-18749 duped wv-de-4544), aurachergruppe.de (new wv-de-18750 duped wv-de-10035). Fixed by hand: repointed all 6 roster-links rows to the existing company_ids, deleted the 6 duplicate roster rows, re-ran the collision check — back to the standing 27 collisions, none new. Standing backlog (six pairs incl. Wiesenbachgruppe, sw-augsburg.de, 27 domain collisions total) still awaits the overdue human consolidation pass, unchanged by this run.

Merge/finish: validated all 4 shard files as well-formed JSONL (17/18 roster rows post-fix, 31/30 link rows) before trusting them. map_roster.mjs: 12148 → 12209 roster-links rows (+61, exact), 493 needing review. consolidate_roster.mjs: 2793 shard rows (221 dupes) → 2572 distinct companies (+35 = 17+18, matches exactly). coverage.mjs: municipalities claimed 9502 → 9562 (+60, exact), population 94.31% → 94.82% (+0.51pp), residual 1441 → 1381 municipalities / 4.758M → 4.332M people. build_gv_layer.mjs: multi-member pool unchanged at 10 units / 22 municipalities / ~6.9k people (as expected — none targeted this run per the reasoning above), singletons 1419 → 1359 (-60).

For next run: continue singleton batches by residual_population descending (1359 singletons remain, largest now ~6.8k people each — Neukirchen/Erzgeb., Herscheid, Grömitz, Dinkelscherben, Erndtebrück, Böhlen, Dettenheim). Residual concentrated in Bayern (2.18M people unclaimed, still the biggest lever by far), Hessen (675k), Sachsen (428k), Baden-Württemberg (299k), Thüringen (278k). The 9-unit multi-member queue (SH x7, Thüringen x1, Baden-Württemberg x1) has now failed 4 independently-different methods — recommend a human look at it directly (or accept it as a permanent small gap) rather than another automated attempt; the 10th unit in that pool (Küstengewässer, MV, 0 population) should be filtered out of build_gv_layer.mjs's queue logic entirely, not just flagged in the journal each time. New host-trap note to fold into SKILL.md: zkd-immenhausen-espenau.de expired TLS cert, use curl -k. Watch for the "found the right existing company but minted a new ID anyway" duplicate pattern seen in shard B this run — worth emphasizing in the subagent prompt that reuse-checking must be a systematic domain-collision pass, not a name-only grep, since even a subagent that claims it checked can still miss most of them.