de:wasserversorger-discover

Discovery run complete. Population coverage rose 95.35% → 95.78% (+0.43pp), municipalities claimed 9639 → 9697 (+58 of 60 dispatched singletons), roster grew from 2607 to 2643 companies. A duplicate company mint (Rhön-Maintal-Gruppe) was caught by the mandatory cross-shard domain-collision check and fixed before merge, keeping the standing collision count at 27; 4 municipalities (Weiler-Simmerberg, Sohland a.d.Spree, Schelklingen, Römhild) remain genuinely unresolved after real investigation. Journal updated with full details and a recommendation for next run.

Read CLAUDE.md and journal tail, then SKILL.md in full. On-disk state before starting: 2607 companies, 95.35% population coverage, 9639/1304 claimed/residual — matched journal exactly after a fresh coverage.mjs/build_gv_layer.mjs. Multi-member pool unchanged at 10 units/22 municipalities (still awaiting human decision per the last 3 discover runs — left untouched, no 5th method tried).

Batch construction refinement: build_batch60.mjs's plain top-60 pulled in Schelklingen and Römhild — both genuinely investigated and marked UNRESOLVED by the 13:00 run earlier today, with detailed notes. Re-running the same search within hours would waste effort, so this run filtered the candidate queue to exclude singleton units whose sole residual member already has an UNRESOLVED roster-links row with checked_at: "2026-08-30" before taking the top 60 (24 such AGS excluded, from today's earlier runs collectively). Worth folding into build_batch60.mjs itself so future runs don't need this ad hoc filter step.

Batch: top-60 singletons by residual_population (after the same-day-unresolved filter), split 30/30, dispatched as shards "shardA-1730"/"shardB-1730", both subagents run_in_background: false in one message, mandatory no-Agent-tool instruction, full method + schema + host-trap list inlined directly in the prompt. Company_id ranges wv-de-18807–18836 / 18837–18866.

Shard A: 28/30 resolved, 2 unresolved (Weiler-Simmerberg — three separate local suppliers, no single retail entity confirmed; Sohland a.d.Spree — multiple local Wasserwerke plus a regional Fernwasser group mentioned in third-party sources, no owned-domain confirmation). 19 new companies minted (wv-de-18807–18825), 9 links resolved to existing roster companies via domain grep before minting (incl. Rötha via Zweckverband Wasser/Abwasser Bornaer Land's full 11-member list — a link the prior pass had missed — and Gersheim via Stadtwerke Bliestal). Correction flagged: Gemeindewerke Hofbieber (not Zweckverband Gruppenwasserwerk Vorderrhön) is the actual retail distributor for Hofbieber.

Shard B: 30/30 resolved, 0 unresolved. 18 new companies minted (wv-de-18837–18854), 12 links resolved to existing companies (incl. two namesake traps correctly avoided: MIDEWA's Arnstein vs. a different Arnstein in Bayern, and ENTEGA's Stockstadt am Rhein vs. Stockstadt am Main). Notably resolved Kirchheim am Neckar (the GVV Bönnigheim residual member) which prior passes hadn't reached: its own Gemeindebetrieb, not the Besigheimer Wasserversorgungsgruppe (whose scanned Satzung PDF has no text layer).

Duplicate mint caught by the mandatory cross-shard domain-collision check: shard B minted wv-de-18838 ("Zweckverband zur Wasserversorgung der Rhön-Maintal-Gruppe", domain rmg-poppenhausen.de) for Gochsheim, which collided with pre-existing wv-de-1202 (same domain, same entity minus a "(RMG)" suffix in the name) — the subagent's own reuse-check missed it despite explicit instructions. Fixed before merge: removed the duplicate row from roster.part-shardB-1730.jsonl, repointed the Gochsheim link to wv-de-1202 with a note explaining the correction. Re-ran the collision check after the fix: back to the standing 27, confirming the fix and that no other new collision was introduced. This is the same failure mode flagged in three prior journal entries (vg9, vg10, this run) — a subagent being told to grep for reuse is not sufficient on its own; the orchestrator-level recheck remains load-bearing every single time, not just when a shard "looks risky."

Merge/finish: all 4 shard files validated as well-formed JSONL before trusting them (19/18→17 after the fix, 51/30 link rows). map_roster.mjs: 12549 → 12630 roster-links rows (+81 = 51+30, exact), needs-review queue 565 → 565 (churn, not net growth). consolidate_roster.mjs: 2864 shard rows (221 dupes) → 2643 distinct companies (+36 = 19+18-1 duplicate, exact). coverage.mjs: municipalities claimed 9639 → 9697 (+58 = 60 dispatched − 2 unresolved), population 95.35% → 95.78% (+0.43pp), residual 1304 → 1246 municipalities / 3.882M → 3.526M people. build_gv_layer.mjs: multi-member pool unchanged at 10 units/22 municipalities (untouched this run, as planned), singletons 1282 → 1224 (-58, exact). Final domain-collision check (roster.jsonl + companies.jsonl): 27, none new after the fix.

For next run: continue singleton batches by residual_population descending — 1224 singletons remain, largest now ~6.3k people (Sohland a.d.Spree and Weiler-Simmerberg just joined the unresolved pool alongside Schelklingen/Römhild, all 4 genuinely checked and empty, all checked_at: 2026-08-30 so a build_batch60.mjs run today should keep excluding them; worth re-including once a day has passed). The 10-unit/22-municipality multi-member queue is still awaiting a human decision (4 failed automated methods across 3 prior runs) — do not spend a 5th run on it without new information. Küstengewässer (vkey 130009999, 0-population MV artifact) still not filtered out of build_gv_layer.mjs at the source. Standing 27-domain-collision backlog unchanged (six known duplicate-mint pairs), still awaiting the overdue human consolidation pass. Recommend adding the same-day-unresolved exclusion filter into build_batch60.mjs itself rather than repeating it ad hoc each run.