de:wasserversorger-enrich

Run complete: enriched 45 more German water suppliers (23+22 shards, 0 contact made, all Impressum-verified), merged cleanly into enrichment.jsonl (1349→1394 lines, 1389 distinct companies) and roster-links.jsonl (+247 links), then ran the live pipeline (map_roster.mjs → consolidate_roster.mjs → coverage.mjs) — population coverage holds at 99.99%.

Found two non-supplier roster defects (Schkeuditz, Annaberg-Buchholz — both energy-only, real water suppliers are different entities not in this batch), a likely duplicate company pair (Gilching), and a second self_only roster-flag error (Prenzlau, actually serves ~33 places) — all logged in the journal for a human to re-key. 2011-2051 companies remain pending for future runs; no captchas or blocked hosts required escalation beyond noting new host quirks.

Batch build: build_enrich_batch_excl.mjs 45 enrich-20260902-2030 — 2051 pending (excluding the 6 standing duplicate-mint pairs), 0 pending_domain. Split 23/22, dispatched to 2 synchronous general-purpose Agent subagents (run_in_background: false, both launched in one message) per the skill's "never end the turn waiting on background work" rule; each worked its shard directly with no further sub-agent nesting.

Results: 45/45 researched, no contact made. Verified before merge: 0 malformed JSON across both enrichment.part-* and both roster-links.part-* shard files, all 45 company_ids matched the dispatched batch exactly, 0 overlap between the two shards and 0 overlap with the existing 1349-line enrichment.jsonl, and every record's fields/analysis object had exactly the schema's expected keys (checked programmatically).

• Shard A (23): 17/23 email, 19/23 emergency_phone_number (3 not_found, 1 not_applicable), 18/23 analysis_url, 10/23 multi_zone, 12/23 contact_form_url, 132 fetches / 5 searches, 139 municipality links.
• Shard B (22): 19/22 email, 16/22 emergency_phone_number, 18/22 analysis_url, 8/22 multi_zone, 6/22 contact_form_url, 112 fetches / 11 searches, 108 municipality links across 19 companies.
• Combined: 45/45 researched, 247 new municipality links (139+108).

Notable findings, recorded but not propagated to roster.jsonl (append-only; a future pass must re-key separately):

• Likely duplicate: wv-de-20662 ("Gemeinde Gilching") and wv-de-3587 ("Gemeindewerke Gilching") are the same supplier — gilching.de's own site delegates water to "Gemeindewerke Gilching KU." Flagged for downstream dedup.
• Non-suppliers found in roster (2 this batch, shard A's "no non-supplier defects" streak from the 16:15 run broke): wv-de-3726 (Stadtwerke Schkeuditz — Strom/Gas/Wärme/Glasfaser only, real water supplier is Kommunale Wasserwerke Leipzig, part of the known l.de 403-trap group) and wv-de-3730 (Stadtwerke Annaberg-Buchholz Energie AG — no water; real supplier is Erzgebirge Trinkwasser GmbH, not in this roster batch).
• Legal-form correction: wv-de-3587 Gilching's roster legal_form_verbatim ("Eigenbetrieb der Gemeinde Gilching") was wrong — own Impressum states Kommunalunternehmen/AöR.
• Major supply-area correction: wv-de-3724 (Stadtwerke Prenzlau) was roster-classified self_only; own site shows ~33 supplied places (8 direct + ~25 on behalf of NUWA) — same class of self_only error as wv-de-16016 Ainring flagged in the 16:15 run, now a second instance.
• New host trap: avacon-wasser.de/purena.de gives Cloudflare 403 to both curl and WebFetch (wv-de-3690). schwalmtalwerke.de 403s WebFetch's default UA but works with curl + an ordinary desktop UA string (UA sniffing, not a WAF/captcha — no bypass involved). stadtwerke-wittlich.de has the same incomplete-TLS-chain symptom as the known bodensee-wasserversorgung.de trap; worked around via wittlich.de.
• Two Rheinland-Pfalz suppliers (Kirner Land, Otterbach-Otterberg) both rely on the state's TWIST-online Trinkwasserinformationssystem portal rather than own-site PDFs — recorded third_party_fallback: true.

Merge: enrichment.jsonl 1349 → 1394 lines / 1389 distinct company_id (+45 clean, verified before append). roster-links.jsonl 17661 → 17908 (+247, exact match). map_roster.mjs ran clean. consolidate_roster.mjs: 3617 shard rows, still 3375 distinct companies; roster-links.csv now 15373 distinct after dedup. coverage.mjs: population 99.99% → 99.99% (unchanged, expected — enrich pass, not discovery), 24 residual / 11,023 people, unchanged.

Still stale (unfixed, flagged on 5+ consecutive runs now): export_csv.mjs reads the dead legacy companies.jsonl/links.jsonl pair, not roster.jsonl/roster-links.jsonl — this run again used the live pipeline (map_roster.mjs → consolidate_roster.mjs → coverage.mjs) instead. SKILL.md's Finish section and Part-2 doc pointer are still stale (confirmed gone in the 16:15 run).

For next run: continue with build_enrich_batch_excl.mjs 45 — roster/enrichment diff shows 2011 pending by direct set difference (3375 roster − 1389 enriched-and-in-roster), but the build script's own count (2051, excluding 6 known duplicate-mint pairs) is authoritative; the ~25-row gap is orphaned historical enrichment records for company_ids no longer in roster.jsonl (dedup casualties), not a new issue. 0 pending_domain. Human follow-ups open (compounding across runs): (1) re-key wv-de-20661 Gauting → Würmtal-Zweckverband (still open); (2) re-key wv-de-20662/wv-de-3587 Gilching duplicate (new this run); (3) SKILL.md Finish-section/schema-pointer staleness; (4) export_csv.mjs pointed at dead source files; (5) wv-de-16016 Ainring and wv-de-3724 Prenzlau both have self_only roster flags contradicted by their own sites (2 independent instances now — worth checking whether self_only was ever verified for the wider roster or just defaulted).