de:wasserversorger-enrich

Everything checks out and the journal is up to date.

Enriched 45 more German water suppliers (2064 → 2109 of 3375 on the roster; 1291 remain pending, none blocked on a missing domain). All 45 were confirmed genuine suppliers with no invented contact data — 35/45 (78%) got a real published water-analysis document, ahead of the campaign's historical rate, and population coverage held steady at 99.99% (24 residual municipalities, ~11k people). Flagged several roster-correction candidates for human review (a TLS-mismatched domain, two possibly-stale operator classifications, a missed second supply zone, two dead roster URLs) without acting on them, and caught a subagent-orchestration issue mid-run (one shard's subagent handed off to background sub-agents and returned before they finished) by waiting for all four to complete and merging their output myself rather than losing the work.

build_enrich_batch_excl.mjs 45 → 0 pending_domain again (roster 3375, 2064 enriched entering, 1331 pending, 6 standing duplicate-mint pairs excluded). Split shard A (23) / shard B (22). Shard A ran as a single subagent that internally fanned out 4 parallel research passes and merged/wrote its own output. Shard B's subagent instead spawned 4 background sub-subagents (groups of 5-6 companies each) and returned its own "done" message before they finished — a orchestration pattern that under this harness's headless-run rules would have silently lost the work if I hadn't caught it. Waited for all 4 group-completion notifications, then merged their temp files (.tmp-group{1..4}-{enrich,links}.jsonl) into the target shard files myself and deleted the temps. Worth remembering: when delegating this task to a subagent, its own internal parallelism is invisible until it either blocks on it or (like this run) doesn't — verify shard line counts before trusting a "done" message.

Verification before merge: both final shard files valid JSON (23+22 lines, 0 bad, 23+22 distinct company_ids each, exact match against the two batch files, 0 collisions with existing 2064 records, 0 overlap between shards). enrichment.jsonl 2069 → 2114 lines (2109 distinct company_ids, +45, 5 pre-existing re-research duplicates as expected under append-only). map_roster.mjs: 21083 → 21171 links (+88, matching the shards' 59+29 exactly). consolidate_roster.mjs: still 177 shards / 3375 distinct companies (unchanged, expected); roster-links.csv 17880 distinct after dedup. coverage.mjs: population 99.99% → 99.99% (unchanged, expected), same 24 residual municipalities / 11,023 people, Hartmannsdorf-Reichenau still largest at 1,040.

Non-suppliers found: 0 — all 45 confirmed genuine drinking-water/self-supply operators.

Field recovery (45 companies): address/phone/website_url found for nearly all; email found for most but several small Eigenbetrieb municipalities route only through a general Rathaus contact form, no dedicated water email; emergency_phone_number found for roughly half, honestly not_found/not_published for the rest after checking Notdienst/Störung pages; handelsregister_nr correctly not_applicable for the ~40 public-law entities, found for a handful of GmbH/private operators (Stadtwerke Oberkochen, WZV Warndt, Verbandswasserwerk Aldenhoven, Gemeindliche Werke Hengersberg). Analysis locator: 24 pdf + 11 html = 35/45 (78%) got a real own-domain analysis document/page, ahead of the campaign's historical ~70% rate; the 10 not_found cases are all earned negatives (self-supply/Satzung independently confirmed, but no analysis published online), not roster defects.

Recurring blocker, worth fixing rather than re-noting: neither subagent had pdftotext or Python available for PDF text extraction, so several genuine own-domain PDFs (Strohgäu, WZV Warndt, Bad Grund, Küps, Illingen, Windach, Verbandswasserwerk Aldenhoven, Schömberg, Pfronten, Thalfang am Erbeskopf) were downloaded but graded tier 2/evidence_value: null rather than read — conservative, not wrong, but a repeat of a known gap. One group did successfully use the existing .pdftext.mjs helper (zlib-based, no external binary) to pull real analyte values out of a PDF WebFetch's own summarizer reported as unreadable binary (Heidenrod) — that helper should be the default reflex before grading a PDF evidence_value: null, not a fallback only some agents think to try.

Roster corrections/questions flagged for human review, not acted on:

• wv-de-18578 Zweckverband Strohgäu-Wasserversorgung: roster's official_domain (strowa.de) serves a mismatched TLS cert (mittwaldserver.info), so a plain HTTPS fetch fails; the same organisation's real, fully-working site is strohgaeuwasser.de. Recorded contact/analysis data from the working domain but did not repoint official_domain in the roster (dedup key change, needs a human decision) — new host trap either way.
• wv-de-18585 Gemeinde Feldkirchen (Lkr. München): roster models it as pure self-supply, but independent evidence points to actual operation now sitting with joint utility gKU VE|MO (HQ Poing) — contradicts the roster's operator-model classification.
• wv-de-18640 Stadt Horstmar: roster's self_only/eigenbetrieb status looks stale — a 2024 40-year concession now has Stadtwerke Emsdetten operating Horstmar's water jointly with Metelen/Schöppingen/Saerbeck under a shared Preisblatt since 2024-07-01.
  • wv-de-18594 Verbandswasserwerk Aldenhoven GmbH: has a second, entirely separate supply zone ("Versorgungsgebiet Niederzier", >15,000 residents) not mentioned anywhere in the existing roster row's notes.
• wv-de-18592 Markt Küps: one of its apparent supply zones, Oberlangenstadt, is actually an Ortsteil of neighbouring Kronach, not of Küps — a cross-municipality boundary question.
• wv-de-6529 Gemeinde Langenargen: found operational interconnection (shared 2023 boil-water notices) with ZWUS and a third zone "Haslach-Wasserversorgung", not mentioned in roster notes (which only cite a future merger masterplan) — recorded as low-confidence links pending review.
• wv-de-209 ZV Wasserversorgung Westpfalz: only contactable via personal staff email addresses at Stadtwerke Kaiserslautern (swk-kl.de domain), not the Zweckverband's own domain — flagged rather than treated as the ZV's own contact channel.
• Two roster URLs found dead this pass: wv-de-18638 Großmehring's impressum_url (current path is /service-links/impressum) and wv-de-18651 Leipheim's supply_area_url (404).

New host traps this batch: strowa.de TLS cert mismatch (see above); strullendorf.de's Joomla "townhall widget" CMS returns the same generic nav shell to any plain fetch regardless of URL, making article-level content unreadable even when a matching page is search-confirmed to exist; Niedersachsen NOLIS portal sites (Bad Grund, Nörten-Hardenberg) need a ?vs=1 query-param to bypass an interstitial redirect; bad-koetzting.de's Satzungen directory listing 403s while files inside it are directly reachable; icking.de's Neos-CMS serves a near-empty nav/footer-only shell on one path while a differently-pathed sibling page holds the real content — likely to recur on other Neos/digiPublica sites.

For next run: continue with build_enrich_batch_excl.mjs 45. Still 0 pending_domain, 1286 other pending (3375 roster total, 2109 distinct company_ids enriched, 6 excluded). New standing items from this pass: Strohgäu domain-correction question, Feldkirchen (Lkr. München) operator question, Horstmar concession/operator question, Aldenhoven Niederzier second-zone gap, Küps/ Kronach boundary question, Langenargen/ZWUS interconnection question, ZWV Westpfalz contact-domain question, and two dead roster URLs (Großmehring, Leipheim). All prior standing items carried in the 2026-09-05 15:30 entry (Schwarzenbruck GmbH wrong-entity question, Lechraingruppe/ Hardhofgruppe 4th-member question, Bad Endbach HR exception, Fuchstal/Vilgertshofen source question, Neunkirchen a. Brand/Rosenbach operator question, and the long tail of older items) remain open, none touched this pass.