de:wasserversorger-discover

Population coverage rose from 96.99% to 97.33% (9953/10943 municipalities claimed, 990 residual). Ran a 60-singleton batch via two synchronous subagents (60/60 resolved, 0 unresolved, 38 new companies minted, 27 standing domain collisions unchanged after fixing one newly-surfaced swapped-domain bug on a pre-existing record — two different real municipalities both named "Hochdorf" had had their domains crossed). Multi-member pool (10 units) and the standing 27-collision backlog remain untouched, awaiting the overdue human decision noted in prior runs; 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: 2745 companies, 96.99% population coverage (9893/1050 claimed/residual), 1028 singletons remaining, multi-member pool unchanged at 10 units/22 municipalities (still awaiting the overdue human decision, correctly left alone), 27 standing domain collisions.

Batch build: ran build_gv_layer.mjs/coverage.mjs fresh rather than trusting the journal number, confirmed exact match. Excluded the 9 AGS with checked_at:"2026-08-31" still same-day (Talheim newly joined this list since the 08:00 run; the other 8 unchanged: Schelklingen, Römhild, Weiler-Simmerberg, Berga-Wünschendorf, Gmund a.Tegernsee, Leun, Frankenblick, Grebenstein) and the 161 AGS belonging to the untouched 10-unit multi-member pool, via a one-off inline filter over residual-top.csv (deleted after use, same as every prior run — worth a human finally adding a same-day-exclusion flag to build_batch60.mjs, now 5th run in a row hand-rolling this). Took the top 60 singletons by residual_population (4883 down to 4604 — marginal yield per municipality still shrinking as expected this deep into phase 2b). Split 30/30, dispatched as two general-purpose Agent subagents in a single message, both run_in_background: false (synchronous), mandatory no-Agent-tool line inlined, full method + schema + host-trap list + explicit reuse-before-mint instruction inlined directly in each prompt. Company_id range wv-de-19002–19061 (verified against the actual max used ID, 19001, before assigning).

Shard A: 30/30 resolved, 0 unresolved. 20 new companies minted (mostly self-supplying Gemeinden/Städte/Märkte on their own Eigenbetrieb, plus 4 Zweckverbände), 10 reused via pre-dispatch grep -F against the existing roster. No known host traps hit.

Shard B: 30/30 resolved, 0 unresolved. 18 new companies minted, 12 reused (plus one bonus link: Bellenberg found served by an already-rostered Eigenbetrieb). Minor new host snags: stockheim-online.de needed curl -k (incomplete TLS chain, same pattern as the standing bodensee-wasserversorgung.de trap); a same-name-different-place near-miss caught before minting (eisingen.de Bavaria vs. the seeded eisingen-enzkreis.de Baden-Württemberg — cross-checked against the seeded land field).

Mandatory cross-shard-plus-existing-roster domain-collision recompute (over all 137 roster.part-*.jsonl shards, never roster.jsonl itself — same reasoning as prior runs, it's fully derived from those shards) found 28, one more than the standing 27. The extra one (hochdorf.de) was not a duplicate mint — it was shard A independently minting wv-de-19017 for a genuine second, unrelated municipality also named Hochdorf (Kreis Esslingen), and in the process discovering that the pre-existing wv-de-11009 (Hochdorf, Kreis Biberach, from the 2026-08-29 vg10 batch) had its official_domain/alternate_domains swapped: hochdorf.de actually belongs to the Esslingen one, gemeinde-hochdorf.de to the Biberach one — confirmed by this run's own direct fetch (PLZ 73269 vs 88454). Fixed the pre-existing record in place (roster.part-vg10-shardA.jsonl): corrected official_domain to gemeinde-hochdorf.de, nulled supply_area_url/impressum_url/alternate_domains rather than guess new paths on the corrected domain, and downgraded confidence to low pending a future re-check of the actual page — the substantive supply-area finding (e.wa riss Netze GmbH technical Betriebsführung since 2021, Landeswasserversorgung as bulk source) is very likely still correct for Biberach's Hochdorf since it names a different operator and date than the Esslingen one's own page (Stadtwerke Esslingen since 2024), but the exact source URL needs re-verification rather than staying silently wrong. Also confirmed (separately) a same-name coincidence that is NOT a bug: two distinct real municipalities both called "Gemeinde Stockheim (Wasserversorgung)" — Kreis Kronach (stockheim-online.de, this run's wv-de-19036) and Kreis Rhön-Grabfeld (gemeinde-stockheim.de, pre-existing wv-de-2613) — different domains, different AGS, both legitimately self-supplying; left both rows as-is. Domain-collision check after the Hochdorf fix: exactly 27, matching the standing backlog, confirming the fix was complete and introduced nothing new.

Merge/finish: map_roster.mjs: 13685 → 13745 roster-links rows (+60, exact), needs-review queue 1067 (up slightly, driven by newly-harvested no-AGS names, not a regression). consolidate_roster.mjs: 3004 shard rows (221 dupes) → 2783 distinct companies (+38 = 20+18 minted, exact). coverage.mjs: municipalities claimed 9893 → 9953 (+60, exact — all 60 dispatched resolved, 0 unresolved this batch), population 96.99% → 97.33% (+0.34pp), residual 1050 → 990 municipalities / 2.516M → 2.231M people. build_gv_layer.mjs: multi-member pool unchanged at 10 units/22 municipalities, singletons 1028 → 968 (-60, exact).

Crossed 97.3% population coverage this run.

For next run: continue singleton batches by residual_population descending — 968 singletons remain, largest still ~6.6k (Schelklingen) since none of the 9 same-day-excluded AGS were touched; re-include them once the run date advances past 2026-08-31. The 10-unit/22-municipality multi-member queue is still awaiting the overdue human decision — do not spend another run on it without new information. Standing 27-domain-collision backlog unchanged (one swap fixed, no net change to the count) — still awaiting the overdue human consolidation pass on the rest. Reinforcing the standing recommendation from the 08:00 run: grep -F a candidate's exact name against roster.jsonl before minting — it worked this run (30 reuses caught across both shards, 0 new exact-name duplicate mints), but a same-domain, different-entity mixup like Hochdorf/Hochdorf isn't caught by a name grep at all, only by the mandatory end-of-batch domain-collision recompute — that check remains load-bearing and must keep running every batch, not just when something feels off. _tasks/netzbetreiber-contact/german-water/ remains absent from this checkout, unaddressed again this run (not touched, out of scope for discovery).