de:wasserversorger-discover

Phase-2a batch 4 complete: researched 60 singleton cities (Schwerte → Warendorf) via two synchronous subagents, all 60 resolved with 0 unresolved, 47 new companies plus 13 dedupe reuses. Caught and fixed one duplicate company row (Kreiswerke Grevenbroich GmbH minted twice under different IDs) before it corrupted the roster, verified via the domain-collision check. Population coverage rose 56.04% → 59.01% (+2.97pp), municipalities claimed 5,922 → 5,982, roster now at 797 distinct companies; phase-2a pool remaining is 1,002 units / 17.99M people (next up: Saarlouis), well within SKILL.md's phase-2b stop boundary so this run halted cleanly as designed.

Continued phase-2a exactly where the 22:00 run left off: next 60 units of the singleton pool (residual_population >= 10,000, descending, via lib.mjs::parseCsv — confirmed matches the prior run's stated next-up list exactly) — Schwerte (45,821) down to Warendorf (37,703). Split into 2 synchronous subagents of 30 cities each (slices p2f/p2g), non-overlapping company_id ranges (3157-3200 and 3201-3244), both blocked on in this turn per the skill's synchronous-subagent rule. resolve_singleton.mjs is broken in this environment — its gemeinden_deutschland.csv input (resolved via TASKDIR to /_tasks/netzbetreiber-contact/german-water/...) does not exist anywhere on this filesystem, not just an empty file. Skipped it and went straight to direct WebSearch/WebFetch per city, same as every batch's actual per-city work has been regardless. Worth a look by whoever owns _tasks/ if the pre-pass is ever expected to run again.

Result: 60/60 resolved, 0 unresolved. 47 new companies (23 in p2f: wv-de-3157..3179; 24 in p2g: wv-de-3201..3224 before a de-dupe correction below dropped one), 13 reused via the required domain/name dedupe against roster.jsonl before minting (Falkensee→OWA GmbH, Bernau bei Berlin→WAV Panke/Finow, Seevetal→Wasserbeschaffungsverband Harburg, Monheim am Rhein→Verbandswasserwerk Langenfeld-Monheim, Kamen→GSW Kamen/Bönen/Bergkamen, Laatzen→enercity AG, Eberswalde→ZWA Eberswalde, Nordhausen→Wasserverband Nordhausen, Eisenach→TAVEE, Königswinter→rhenag AG, Mettmann→Stadtwerke Düsseldorf AG, Königs Wusterhausen→MAWV, Haltern am See→GELSENWASSER AG). 0 new pending_domain rows this batch (one, Kehl, landed pending_domain on a 404 Impressum but corroborated via a secondary registry page). Several "own energy Stadtwerke ≠ water supplier" splits worth remembering as a pattern, not one-offs: Kaarst (Stadtwerke Kaarst does gas/electricity only; water is Kreiswerke Grevenbroich GmbH), Gifhorn (energy Stadtwerke vs. a distinct Wasserwerk Gifhorn GmbH & Co. KG), Freital (Freitaler Stadtwerke/TWF are energy/wastewater only; water is Wasserversorgung Weißeritzgruppe GmbH), Ilmenau (Stadtwerke Ilmenau is energy-only; water is WAVI), Haltern am See (local "Stadtwerke Haltern" has no water line at all; GELSENWASSER supplies it directly).

Dedupe miss caught and fixed before it reached the roster: the domain-collision check (see Finish sequence below) flagged kw-gv.de on two different company_ids — wv-de-3081 (Kreiswerke Grevenbroich GmbH, minted 2026-08-24 for the Grevenbroich city lookup, whose notes already named Kaarst as one of 5 unrowed "bonus" municipalities on the same page) and a brand-new wv-de-3167 minted by this run's p2f subagent, which independently researched Kaarst's water supplier, correctly identified the same Kreiswerke Grevenbroich GmbH, but never found wv-de-3081 because its dedupe grep ran before both shards had been consolidated into roster.jsonl. Fixed by hand: deleted the wv-de-3167 row from roster.part-p2f.jsonl, repointed the Kaarst row in roster-links.part-p2f.jsonl to wv-de-3081, and filed an enrichment of wv-de-3081 (adding the supply_area_url that only the duplicate attempt had found) into the existing late-sorting roster.part-zzz-p2fix.jsonl shard so it wins the merge. Re-ran map_roster.mjs → consolidate_roster.mjs after the fix; company count dropped from 798 to the correct 797 and the collision cleared. For next run: a same-batch dedupe grep only sees shards already merged into roster.jsonl at the time the previous run's Finish sequence ran — a city named as an unverified "bonus" in one batch's notes (not given its own roster-links row) is invisible to a same-day sibling shard's dedupe check until the next consolidation. If you see a note saying "N other named municipalities are a bonus list, not independently rowed" from a recent batch, check it against your own assigned cities by name before minting, not just by grep — grep alone caught 13/14 of this batch's real dedupes and missed exactly this one case.

Traps avoided, worth remembering: two new host traps for the SKILL.md list — wasser-freiberg.de/impressum (Freiberg) returns HTTP 403 to both WebFetch and curl -k, same shape as the existing l.de bot-protection entry; technische-dienste-kehl.de 404s on every Impressum path tried via both WebFetch and curl (Kehl, downgraded to medium/pending_domain). Same-name/decoy traps hit and avoided: NRW's Stadtwerke Borken/Westf. vs. the unrelated Stadtwerke Borken (Hessen); the paper-only "Stadtwerke Mettmann GmbH" (not operational per a 2023 press article — actual supplier is Stadtwerke Düsseldorf AG). No CAPTCHAs, IP bans (78.46.40.200, l.de), or forms touched — research only, all fetches via WebSearch/WebFetch/curl against the suppliers' own sites.

Ran the Finish sequence: map_roster.mjs (6,539 links, 0 ambiguous/unmatched, both before and after the dedupe fix) → consolidate_roster.mjs (797 distinct companies, up from 751) → coverage.mjs → build_gv_layer.mjs. Population coverage 56.04% → 59.01% (+2.97pp) from 60 rows; municipalities claimed 5,922 → 5,982 (+60, all singletons as expected). Domain-collision check across roster.jsonl + companies.jsonl: back to the same 1 known hit (emkendorf.de, unchanged since 2026-08-19) after the kw-gv.de fix above — confirmed clean.

Phase-2a pool remaining: 1,002 units / 17.99M people (next up: Saarlouis 37,667, Bautzen 37,566, Fürstenfeldbruck 37,420, Papenburg 37,206, Erding 37,171, Beckum 37,133 — the pool has now dropped under 18M people, a bit over half the original 34.9M).

For next run: continue phase-2a from Saarlouis down, same method (2 synchronous subagents, 30 cities each, lib.mjs::parseCsv on gemeindeverband-queue.csv, cross-referenced with gemeindeverband-members.csv for AGS, dedupe-by-domain-and-name against roster.jsonl before minting a company_id, next new-id range starts at wv-de-3225). Do the dedupe check by name against recent batches' "bonus list, not independently rowed" notes too, not just grep-by-domain — see the kw-gv.de case above. resolve_singleton.mjs remains unusable in this environment (missing gemeinden_deutschland.csv); direct WebSearch/WebFetch per city continues to work fine and is what every batch actually does regardless. Pool is now under 18M people and continuing to shrink toward the 10,000-population floor — stop and report per SKILL.md's explicit phase-2b boundary when the pool empties or drops below it, do not descend automatically.