de:wasserversorger-enrich

Enriched 45 German water suppliers (23+22 split across two synchronous subagents), covering the 3 remaining pending_domain rows plus 42 by population served (34.4k–31.5k). All 45 records merged cleanly into enrichment.jsonl (885→930 lines, 925 distinct companies, 2217 pending); municipality links merged via map_roster.mjs (+46 rows); population coverage holds steady at 99.70% as expected for an enrichment-only pass.

Also caught and worked around a real bug: map_ags.mjs (the skill's literal "Finish" step) silently rebuilds links.jsonl from only the 25-company pilot shards, destroying any rows appended to it since — it had already quietly wiped a prior run's 1215-row growth back to 905. I skipped running it this pass to avoid destroying today's newly-collected link data, used the safe roster-links.jsonl/map_roster.mjs path instead, and left detailed remediation notes in the journal for a human or future run to fix properly.

State on entry: 3110→3142 roster companies (picked up after the 03:00 discovery run), 880 distinct enriched, 99.70% population coverage (10559/384 claimed/residual) — coverage numbers unaffected by this pass as expected (enrichment doesn't add new roster companies).

Batch build: build_enrich_batch_excl.mjs 45 enrich-2026-09-01-0530 (still excludes the 6 standing duplicate-mint pairs) surfaced the 3 remaining pending_domain rows (all three newly-minted by the 03:00 discovery run: wv-de-19668, 19673, 19677) + 42 by population served (34,446 down to 31,521). Split 23/22, dispatched as two synchronous general-purpose Agent subagents in one message, both run_in_background: false, both carrying explicit no-Agent/ no-Task-tool instructions. Both completed inline this turn (durations ~1730s / ~1106s).

Shard A (23, incl. all 3 pending_domain): all 23 complete. The 3 pending_domain rows confirmed genuinely still pending (no discoverable own site) rather than guessed — recorded with reason. Field recovery: name 23/23, website_url 21/23, email 20/23, phone 21/23, emergency 20/23, contact_form_url 15/23, supply_area_municipalities 22/23 (Hallertau's is a map image with no text list, honestly left empty), analysis locator found for all 23 (3 as third-party fallback). New host trap: ewb-duderstadt.de/de/Home/Impressum/ 403s while other pages on the same domain fetch fine. New interactive-widget pattern (oeffentlichkeit.gw-manager.com, seen on Stadtwerke Gelnhausen) comparable to the known GELSENWASSER vnc_twa widget. The campaign's pdfextract.mjs PDF text extractor cracked a PDF WebFetch's summarizer couldn't (Zweckverband Torgau-Westelbien), surfacing a richer multi-zone member list plus a flagged, unresolved Dommitzsch drinking-water-vs-wastewater contradiction.

Shard B (22, all known-domain): all 22 complete. Field recovery: name 22/22, website_url 22/22, phone 21/22, email 17/22 (5 not_found, JS-obfuscated Impressum emails with no static plaintext, not guessed), emergency 15/22 found + 1 verified not_published, contact_form_url 9/22, supply_area_municipalities 22/22 (reused/confirmed from roster pre-population), handelsregister_nr 9/22 found + 12 not_applicable + 1 not_found. Analysis locator: analysis_url for 19/22, multi_zone true for 13/22. Roster correction candidate surfaced: wv-de-1404 (Wasserversorgung Sulinger Land) — roster's legal_form_verbatim said "kommunales Unternehmen", this pass's own Impressum fetch found the precise statement "Zweckverband – Körperschaft öffentlichen Rechts" (recorded in this run's record, roster itself not touched).

Important process finding — map_ags.mjs silently destroys accumulated Part-3 link data. Shard A was (mistakenly, on my instruction) told to append its 72 municipality-link rows directly to links.jsonl, matching what the 00:30 run's journal entry described as the current convention. Shard B's agent instead flagged that this convention is unsound: map_ags.mjs unconditionally rebuilds companies.jsonl and links.jsonl from only links.part-a.jsonl + links.part-b.jsonl (the original 25-company pilot, 465+440=905 rows) via writeFileSync — running it wipes out any rows appended to links.jsonl since, silently. links.jsonl was exactly 905 lines on entry to this run (a prior run's literal "Finish" execution of map_ags.mjs had already reset it, discarding whatever the 00:30 run's shards had appended past 905 — that run's own journal entry claims growth to 1215 rows that no longer exist). The real, live merge path for Part-3 links is roster-links.part-*.jsonl → map_roster.mjs (glob-merges every roster-links.part-*.jsonl file present, resolves AGS, rewrites roster-links.jsonl in full — additive as long as part files stay on disk) → coverage.mjs's sweep claims. links.jsonl's pilot1 claims are a secondary, fragile path that coincidentally hasn't affected coverage % much because the same municipalities are usually already claimed via roster-links.jsonl, but the specific link/attribution data recorded in it keeps getting silently discarded.

This run's remediation: did not run map_ags.mjs (would have reset links.jsonl from 977 back to 905, destroying shard A's 72 new rows). Instead: appended shard B's raw crawl shard (roster-links.part-enrich-2026-09-01-0530-shardB.jsonl, 46 rows) into the live merge path by running map_roster.mjs (roster-links.jsonl 14823→14869, +46 exact; needs-review queue 1231→1236). Ran coverage.mjs (safe/non-destructive, reads links.jsonl ∪ longtail.jsonl ∪ roster-links.jsonl): unchanged at 10559 claimed / 99.70% / 384 residual, as expected for an enrichment-only pass. Ran export_csv.mjs last (also non-destructive, just renders CSV from current companies.jsonl/links.jsonl) — wrote 25/977 rows, confirming links.jsonl's 72 new rows survived. companies.jsonl and links.jsonl were left un-rebuilt this run — a future run must not blindly run map_ags.mjs per the skill's literal Finish step 1 without first checking whether links.jsonl has grown past 905; if it has, back it up or fix map_ags.mjs to also read links.jsonl-appended rows (or, better, retire the direct-append-to-links.jsonl convention entirely in favor of the roster-links.part-*.jsonl → map_roster.mjs path shard B used, and have future shards write there instead of to links.jsonl directly).

Validation before calling it done: both shard files well-formed (23/23, 22/22, 0 malformed), all 45 batch company_ids present in the merged shards, 0 already had a pre-existing enrichment.jsonl record before merge. enrichment.jsonl 885→930 lines (+45 exact), 925 distinct company_ids (2 pre-existing multi-record ids unrelated to this batch — wv-de-7559/7554, each already at 3 records before this run, not touched; wv-de-2600's known intentional 2-record supersede also untouched). Pending count 2262→2217.

For next run: continue by population served — build_enrich_batch_excl.mjs 45 will pick up around 31,500 and below. Decide and fix the map_ags.mjs/links.jsonl destructive-merge issue above before the next several enrichment runs accumulate more at-risk data in links.jsonl — this is now flagged in detail for a human or a future run with slack. Follow up on wv-de-1404's legal-form correction (apply to roster if a human confirms). Reconcile the Dommitzsch drinking-water/wastewater contradiction in Zweckverband Torgau-Westelbien's member table. Standing backlog unchanged: 6 duplicate-mint pairs, 28-collision domain-review queue, GIPS-platform email cipher (Balingen/Gaggenau/Hemer/Wedel, still uncracked), pdftext2.mjs/pdfextract.mjs CMap bug, resolve_singleton.mjs's ENOENT dependency on the absent _tasks/netzbetreiber-contact/german-water/ directory (discovery-side, unrelated to this run), and that directory's continued absence from this checkout (noted every run).