de:wasserversorger-discover

Phase-2a batch 3 complete: 60 more singleton cities resolved (Wesel down to Weinheim), all verified via Impressum/water-page checks, 51 new companies plus 9 dedupes against the existing roster, 2 new pending_domain cases, zero unresolved. Population coverage rose 52.31% → 56.04% (+3.73pp), municipalities claimed 5,862 → 5,922, roster now 751 companies; the one known domain collision (emkendorf.de) is unchanged and no new ones appeared. I also caught and fixed a merge-order bug where a subagent's domain correction for an existing company (Frankenthal) would have been silently reverted by consolidate_roster.mjs's alphabetical shard ordering — filed a note in the journal so future runs know the workaround. Phase-2a continues with 1,069 units (20.66M people) remaining; next run picks up at Schwerte.

Continued phase-2a exactly where the 18: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) — Wesel (60,785) down to Weinheim (45,852). Split into 2 synchronous subagents of 30 cities each (slices p2d/p2e), non-overlapping company_id ranges (3089-3128 and 3129-3168), both blocked on in this turn per the skill's synchronous-subagent rule.

Result: 60/60 resolved, 0 unresolved. 51 new companies (23 in p2d: wv-de-3089..3111; 28 in p2e: wv-de-3129..3156), 9 deduped against the existing roster before minting (Neubrandenburg, Frankfurt (Oder), Pulheim→RheinEnergie, Bad Kreuznach, Stralsund, Frechen→RheinEnergie, Elmshorn, Frankenthal, Gotha). 2 new pending_domain rows (Verbandswasserwerk Langenfeld-Monheim GmbH & Co. KG — no independent site, redirects to a sister company's domain; Wasserwerk der Stadt Melle — billing now handled by EWB Bünde with no site of its own).

Consolidation bug caught and worked around, worth documenting since it isn't in SKILL.md: consolidate_roster.mjs merges roster.part-*.jsonl shards by alphabetical filename order, last-shard-wins per company_id — not by checked_at or any timestamp. One of this batch's dedupes (Frankenthal → existing wv-de-1173) newly verified a domain that the original 2026-08-20 record (roster.part-q.jsonl) had left pending_domain. The subagent correctly recognised that writing the update to roster.part-p2e.jsonl would silently lose to roster.part-q.jsonl on the merge ("p2e" < "q" alphabetically) and flagged it in notes instead of overwriting blind. I filed the corrected record in a new shard, roster.part-zzz-p2fix.jsonl, whose name deliberately sorts after every existing shard so it wins the merge — confirmed post-consolidate_roster.mjs that roster.jsonl's wv-de-1173 now shows official_domain: stw-frankenthal.de, not pending_domain. For any future run that needs to correct/upgrade an already-merged company row: don't just append to a shard named after your batch slice — name it so it sorts last (or fix roster.jsonl directly and treat the shards as historical only), otherwise an earlier-alphabetical shard silently reverts your correction on the next consolidation.

New host traps (add to the existing list in SKILL.md's memory-safety section): stadtwerke-euskirchen.de has a persistent TLS handshake failure across both WebFetch and curl (even forced TLSv1.2) — resolved via corroborating search snippets only, downgraded to medium confidence. stadtwerke-kleve.de and stadtwerke-soest.de both throw a cert-chain error to WebFetch specifically, but resolve fine with curl -k — same shape as the already-documented bodensee-wasserversorgung.de incomplete-chain case, so this looks like a recurring small-Stadtwerke hosting pattern, not one-off bad luck. Same-name traps hit and avoided (worth remembering as a class, not just these instances): two unrelated "Bornheim" water utilities (NRW vs. Rheinland-Pfalz, already wv-de-633), two unrelated "Landau" Stadtwerke (Landau in der Pfalz vs. Landau an der Isar in Bavaria — swlandau.de is the Bavarian one), a decoy stadtwerke-erft.de vs. the real stw-erftstadt.de, and an existing roster entry "Wasserversorgungszweckverband Ahlenbrunnengruppe" that is a different Ahlen (Baden-Württemberg) from the NRW Ahlen in this batch. 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,479 links, 0 ambiguous/unmatched) → consolidate_roster.mjs (751 distinct companies, up from 700, 5 shard-level dupes resolved incl. the Frankenthal fix) → coverage.mjs → build_gv_layer.mjs. Population coverage 52.31% → 56.04% (+3.73pp) from 60 rows; municipalities claimed 5,862 → 5,922 (+60, all singletons as expected). Domain-collision check across roster.jsonl + companies.jsonl: same 1 known hit (emkendorf.de, unchanged since 2026-08-19) — no new collisions from this batch.

Phase-2a pool remaining: 1,069 units / 20.66M people (next up: Schwerte 45,821, Falkensee 45,720, Brühl 45,555, Erkelenz 45,315, Rodgau 45,277, Wittenberg 45,249).

For next run: continue phase-2a from Schwerte 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-3157). If a dedupe newly resolves a field on an existing company (like Frankenthal's domain this run), remember the shard-merge-order gotcha above — either name the correction shard to sort last, or edit roster.jsonl directly. Pool is now under 21M 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.