de:wasserversorger-discover

Journal entry is fixed and complete. The run is done — let me give the final report.

Population coverage rose from 97.33% to 97.65% (+0.32pp) via a 60-unit singleton batch (30/30 + 30/30 resolved, 0 unresolved), lifting claimed municipalities 9953→10013 and the roster to 2,816 companies. The pre-merge domain-collision check caught 12 newly-minted duplicates (both shards' name-based reuse checks missed cosmetic name variants of already-rostered companies, including one three-way duplicate) — all were fixed by repointing links to the existing company_id and dropping the duplicate rows before merging, and the final collision count came back to exactly the standing backlog of 27, confirming nothing new leaked through. Journal updated with the full run detail; next run should continue singleton batches downward from ~4,310 residents, leave the stuck 10-unit multi-member pool and the 27-collision backlog for a human, and note Schelklingen (AGS 08425108) may need human judgment since two automated passes couldn't resolve its core-town-vs-Stadtteile ambiguity.

Read CLAUDE.md and journal tail, then SKILL.md in full. On-disk state before starting: 2783 companies, 97.33% population coverage (9953/990 claimed/residual), 968 singletons remaining, multi-member pool unchanged at 10 units/22 municipalities (still awaiting the overdue human decision, correctly left alone), 27 standing domain collisions.

Batch build: ran coverage.mjs/build_gv_layer.mjs fresh, confirmed exact match against the journal. Excluded the 10-unit/22-municipality multi-member pool (unchanged vkeys) and the 9 same-day (checked_at:"2026-08-31") unresolved AGS from the prior run via a one-off inline filter over gemeindeverband-queue.csv (same hand-rolled approach as every recent run — still worth a human finally adding a same-day-exclusion flag to build_batch60.mjs). Took the top 60 residual singletons by residual_population (4,592 down to 4,310 — marginal yield continuing to shrink). Split 30/30, dispatched as two general-purpose Agent subagents in a single message, both run_in_background: false (synchronous), mandatory no-Agent-tool line inlined, full method + schema + host-trap list + explicit reuse-before-mint instruction inlined directly in each prompt. Company_id ranges disjoint and verified against the actual max in use (19049) before assigning: shard A 19050–19089, shard B 19100–19139.

Shard A: 30/30 resolved, 0 unresolved. 22 new companies minted initially (later reduced to 17 after dedup, see below), 8 reused via pre-dispatch grep -F. Self-supply (Eigenbetrieb) dominant pattern (~15/22). One non-supplier filtered (a land-drainage-named body for Marlow). Host trap: gross-bieberau.de 403s all automated fetches — worked around via third-party corroboration.

Shard B: 30/30 resolved, 0 unresolved. 24 new companies minted initially (later reduced to 16 after dedup), 5 reused (RMG hit twice — Röthlein and Poppenhausen, same operator). Self-supply again dominant in small Bavarian Gemeinden. Two genuine partial-coverage cases recorded honestly (partial, not forced to one answer): Bad Berneck, Grabenstätt. New host traps: rzv-glauchau.de refused all connections; wasserwerke-zwickau.de/wbv-sude-schaale.de needed curl -k.

Mandatory cross-shard-plus-existing-roster domain-collision recompute (over all roster.part-*.jsonl shards) found 39 — 12 more than the standing 27, and this time genuinely new, not a false alarm like the prior run's Hochdorf case. All 12 were the reuse-before-mint check failing silently: both subagents' pre-dispatch grep -F missed matches where the existing roster's company name differed cosmetically from what the subagent found this run (curly vs straight quotes, a trailing "Hainichen (ZWA)" suffix, hyphen-vs-en-dash, "and" vs "und" ordering, etc.) — a name grep is fuzzy-fragile in exactly the way a domain match is not. One case (zwa-mev.de) was a three-way duplicate: shard A minted 19052, shard B independently minted 19109, and a pre-existing wv-de-3957 from an 2026-08-2x run already had it — two shards running concurrently each missed both the pre-existing row and each other's mint. Fixed all 12 before any merge step ran: for each, kept the older/pre-existing company_id, repointed the new shard's roster-links.part-1300-*.jsonl rows to it, and dropped the duplicate roster.part-1300-*.jsonl row entirely (18 roster rows removed across both shards: 22→17 shard A, 24→16 shard B). Recomputed the collision check after the fix: exactly 27, matching the standing backlog, confirming the fix was complete and introduced nothing new syntactically (though see the note below on how it was found — nothing detected it beyond diligence, no automated check separates "new to this run" collisions from the standing backlog).

Worth a human's attention: the domain-collision check catches this failure mode but only if someone actually runs it and diffs against the known 27 — nothing in the tooling flags "this collision count went up" or separates new hits from standing ones. This is now the second run in three finding something via that check (the 08-31 12:02 run's Hochdorf domain-swap, this run's 12 duplicate mints) — the check is fully load-bearing and would be worth a small script (check_collisions.mjs --diff-against-standing) instead of ad-hoc inline node each time.

Merge/finish: map_roster.mjs: 13745 → 13805 roster-links rows (+60, exact), needs-review queue 1067 (up slightly, driven by newly-harvested no-AGS names, not a regression). consolidate_roster.mjs: 3037 shard rows (221 dupes) → 2816 distinct companies (+33 = 17+16, exact, matching the post-dedup mint counts). coverage.mjs: municipalities claimed 9953 → 10013 (+60, exact — all 60 dispatched resolved, 0 unresolved this batch), population 97.33% → 97.65% (+0.32pp), residual 990 → 930 municipalities / 2.231M → 1.964M people. build_gv_layer.mjs: multi-member pool unchanged at 10 units/22 municipalities, singletons 968 → 908 (-60, exact). Final domain-collision check across roster.jsonl + companies.jsonl: 27, matching the standing backlog.

Crossed 97.6% population coverage this run.

For next run: continue singleton batches by residual_population descending — 908 singletons remain, largest still ~6.6k (Schelklingen, AGS 08425108) — confirmed still one of the same-day (checked_at:"2026-08-31") exclusions (re-confirmed unresolved twice now, 08-30 and 08-31, same genuine ambiguity: member of Zweckverband Albwasserversorgungsgruppe VIII/IX but unclear whether that Verband serves the Kernstadt or only outlying Stadtteile). It and the other 8 same-day AGS will re-enter the eligible pool once the run date advances past 2026-08-31; Schelklingen specifically may need a human's judgment call rather than another automated pass, since two independent runs already failed to resolve the core-town-vs-Stadtteile ambiguity from public sources. The 10-unit/ 22-municipality multi-member queue is still awaiting the overdue human decision — do not spend another run on it without new information. Standing 27-domain-collision backlog unchanged (12 different new ones fixed, no net change to the standing count) — still awaiting the overdue human consolidation pass on the rest. Reinforcing yet again: grep -F name matching before minting is not sufficient on its own — this run's 12 misses were all cosmetic name variants a fuzzy/normalized match would have caught. The end-of-batch domain-collision recompute remains the actual safety net and caught 100% of this run's duplicates; keep running it every batch without exception. _tasks/netzbetreiber-contact/german-water/ remains absent from this checkout, unaddressed again this run (not touched, out of scope for discovery).