de:wasserversorger-discover

Run complete: population coverage rose from 78.21% to 79.44% (+1.23pp), municipalities claimed 6,915 → 7,011, roster grew from 1,334 to 1,360 companies. Processed phase-2a batch 15 (60 kreisfreie/singleton units, Wadersloh→Rosendahl) via 2 synchronous subagents; the mandatory post-merge domain-collision check caught and fixed 4 genuine duplicate company mints before merging (Stadtwerke Borken, TWV Stader Land, WAZV Saalkreis, WAZV Werder-Havelland), keeping a 5th flagged pair (ZVO parent/subsidiary) as legitimate distinct entities.

Phase-2a pool is down to just 60 units / 639k people — the next run should finish it and then stop per the skill's explicit boundary, since phase 2b (small municipalities) is a deliberate decision for Frédéric, not an automatic continuation. Full details logged in the journal.

Freshness check first: newest existing shards (roster.part-p4a/p4b.jsonl, ~10:33) predated roster.jsonl's own merge timestamp (10:35), confirming the 08:00 run's merge completed cleanly — no orphaned shards to recover. Recomputed fresh via coverage.mjs/build_gv_layer.mjs anyway: matched the 08:00 handoff exactly (78.21%, 6,915 claimed, 252-unit/2.86M pool starting at Wadersloh).

Batch: top 60 of the freshly-computed singleton pool (members_total===1, residual_population>=10000, descending), Wadersloh (12,848) down to Rosendahl (11,249). Built the seed AGS directly from gemeindeverband-members.csv's own vkey→ags column (not the vkey-derivation formula, and not the queue's own vkey column) — the 08:00 run's lesson, applied by construction this time rather than caught after the fact. All 60 resolved cleanly on the first pass.

Split 2 SYNCHRONOUS subagents (p5a/p5b, 30 cities each, run_in_background: false, dispatched together in one message), both carrying the "you may not use the Agent/Task tool..." line and the "grep the full candidate company name" line verbatim. Both finished cleanly, no delegation, no background children mentioned — 13th consecutive clean batch, no recursion. Non-overlapping company_id ranges (4002–4201 / 4202–4401); p5a used 4002–4014 (13 new + 12 reused), p5b used 4202–4219 (17 minted, later corrected to 13 — see below).

Domain-collision check (mandatory, across all roster.part-*.jsonl + roster.jsonl) caught 4 genuine duplicate mints by p5b, all re-minted despite the shard's own pre-mint grep: wv-de-4208 "Stadtwerke Borken/Westf. GmbH" (dup of pre-existing wv-de-3168, same domain stadtwerke-borken.de), wv-de-4209 "Trinkwasserverband Stader Land" (dup of wv-de-826, twv-staderland.de), wv-de-4218 "Wasser- und Abwasserzweckverband Saalkreis" (dup of wv-de-3666, wazv-saalkreis.de), wv-de-4219 "Wasser- und Abwasserzweckverband Werder-Havelland" (dup of wv-de-3340, wazv.de) — all four are Verbände already in the roster from earlier sweeps (2026-08-25/26), re-crawled this run via a different seed municipality with a slightly different company name string (e.g. parenthetical abbreviation added), which is exactly why a substring/exact grep on the candidate name can miss it. Fixed by hand before any merge script ran: dropped the 4 duplicate company rows from roster.part-p5b.jsonl and repointed all 14 link rows referencing them to the existing company_ids. A 5th flagged pair — wv-de-4207 "Zweckverband Ostholstein (ZVO)" vs. pre-existing wv-de-357 "ZVO Energie GmbH", both on zvo.com — was kept as two distinct rows: the new record's own notes identify it as the parent public-law Zweckverband vs. the existing row's 100%-subsidiary operating GmbH, the same parent/subsidiary-on-one-domain pattern already accepted for sw-augsburg.de and emkendorf.de. Re-ran the collision check after the fix: only the 3 known pre-existing accepted collisions remained (sw-augsburg.de, zvo.com post-fix, emkendorf.de), nothing else new.

All 60 seeded municipalities resolved (0 unresolved), including one split-supplier case: Bad Sassendorf is served by two companies (Wasserversorgung Beckum GmbH for the Ortsteile Ostinghausen/Weslarn/Bettinghausen, Stadtwerke Soest GmbH for the core town — medium confidence on the Soest side due to a contested concession history also claimed by Lörmecke). Bonus harvest: ~34 (p5a) + ~24 (p5b) additional link rows from member lists, largest being TWV Stader Land (9 members, raw HTML per the known WebFetch-truncation trap), Zweckverband Mittelhessische Wasserwerke (26), Überlandwerk Leinetal (6), and four more Baden-Württemberg Zweckverbände around Remchingen/Straubenhardt/Rudersberg. New host traps: remchingen.de/straubenhardt.de Nuxt/JS-rendered (WebFetch 403, worked around via r.jina.ai), dautphetal.de/kranenburg.de occasional WebFetch 403 (same workaround), stadtwerke-kleve.de broken TLS chain (same class as bodensee-wasserversorgung.de, curl -k workaround). No PDF tool available in the subagent sandbox (no pdftotext, no python3) — one Satzung PDF (GWW Florenberg) could not be parsed, corroborated via search snippets instead and flagged medium confidence. One caught false-positive: an initial snippet conflating a Burgthann-area wastewater Zweckverband ("Schwarzachgruppe") with drinking-water supply — discarded after Schwarzenbruck was independently confirmed self-supplying.

Ran map_roster.mjs (7,818 total links, 101 needing review — 98 unmatched + 3 ambiguous, same shape as prior runs, mostly Ortsteil/administrative carve-outs with no AGS by construction) → consolidate_roster.mjs (1,360 distinct companies, up from 1,334; 6 shard-level last-shard-wins duplicates, all pre-existing, none new) → coverage.mjs → build_gv_layer.mjs.

Population coverage 78.21% → 79.44% (+1.23pp); municipalities claimed 6,915 → 7,011 (+96, net of overlap dedup against the 60+~58 raw claims).

Phase-2a pool remaining: 60 units / 639,345 people (next up: Extertal 11,248, Südheide 11,182, Grünwald 11,179, Raubling 11,161, Bannewitz 11,122, Niestetal 11,118, Herrsching a.Ammersee 11,099, Denkendorf 11,092, Rodenbach 11,074, Höhenkirchen-Siegertsbrunn 11,039, Wustermark 11,024, Planegg 11,007, Burgkirchen a.d.Alz 11,006, Egelsbach 10,960, Neuhof 10,893). One more batch this size empties the phase-2a pool — the next run should expect to finish phase 2a and then stop per the skill's explicit boundary (do not descend below 10,000 inhabitants; phase 2b is a deliberate decision for Frédéric, not an automatic continuation).

For next run: continue phase-2a from Extertal down (last ~60 units). Build the seed AGS from gemeindeverband-members.csv's vkey→ags column directly, not the queue's own vkey column and not a formula — this run did it right the first time. Next free company_id starts at wv-de-4220 (p5b's highest used ID before the 4 dedup drops); the freed IDs 4208/4209/4218/4219 are also reusable, along with the older 3768–3791 and 3994/4000/3985 gaps. Keep the explicit "you may not use the Agent/Task tool" line and the "grep the full candidate company name" line verbatim in every subagent prompt — 13th consecutive clean batch, no recursion — but the orchestrator-level post-merge collision check remains the real backstop: it caught 4 genuine duplicates this run despite both shards' own pre-mint greps passing clean, the same shape as the 08:27 run's 3. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT) — still not blocking, unfixed across 10+ runs now.