de:wasserversorger-discover

Phase 2a is now complete. This run took the last 60 singleton units (≥10,000 residents) in the phase-2a queue, dispatched 2 synchronous research subagents (30 units each), and verified all output before merging — raising population coverage from 79.44% to 80.30% (7,082/10,943 municipalities claimed) and growing the roster from 1,360 to 1,399 companies. 59 of 60 units resolved cleanly (1 genuine gap: Bannewitz, Sachsen, with no verifiable supplier found after exhausting leads); the domain-collision check came back clean with only the 3 previously-accepted collisions. Per the skill's explicit boundary, the run stopped here rather than descending below 10,000 inhabitants — starting phase 2b (~2,700 small singletons, 7.3M people) is a deliberate decision that needs Frédéric's go-ahead, not an automatic continuation.

Triggered via chat (users/108934946863892655718), not the schedule. Freshness check first: recomputed coverage.mjs/build_gv_layer.mjs fresh before touching anything — matched the 13:00 run's handoff exactly (79.44%, 7,011 claimed, 60-unit/639,345-person pool starting at Extertal). No orphaned shards.

Built the seed AGS directly from gemeindeverband-members.csv's own vkey→ags column (not the queue's own vkey column, not a formula) — third run running this has been done right by construction. All 60 singleton units resolved to exactly one member each.

Split 2 SYNCHRONOUS subagents (p6a/p6b, 30 units each, run_in_background: false, dispatched together in one message so both block before the turn continues), both carrying the "you may not use the Agent/Task tool..." line and the "grep the full candidate company name against roster.jsonl AND the sibling shard" line verbatim. Both finished cleanly, no delegation, no background children mentioned — 14th consecutive clean batch, no recursion. Non-overlapping company_id ranges (4220–4249 / 4250–4279); p6a minted 23 (4220–4242), p6b minted only 16 (4250–4265) — the rest reused via grep-before-mint.

Dedup was unusually high this batch: p6a reused 9 pre-existing companies (GELSENWASSER AG among them — its Versorgungsgebiet list had been flagged "not yet harvested" in an earlier company's own notes, then harvested this run for ~7 new towns), p6b reused 14 of its 30 municipalities' suppliers from earlier sweeps (Gelsenwasser, Stadtwerke Frankenthal, Hochsauerlandwasser, Lörmecke-Wasserwerk, Wasserverband Lingener Land and others) — in several cases the existing roster row's own notes had already named the seeded municipality as a member with no link row yet, so the fix was adding the missing link, not re-minting. Only 39 genuinely new companies total (1,360 → 1,399).

Resolution: 59/60 resolved (29 high/medium in p6a's own count, 30/30 in p6b — see below), 1 unresolved: Bannewitz (Sachsen) — checked and ruled out WVW Freital (wrong service area), DREWAG (absent from Sachsen's own official Trinkwasserversorgungsgebiete registry, apps.gesunde.sachsen.de/trinkwasser.php — a genuinely useful authoritative Land-level cross-check, worth reusing for future Sachsen seeds), IWB GmbH (an engineering consultancy, not a supplier), TWF Freital (wastewater only). Recorded company_id: null with full negative-evidence notes — an honest gap, still counted as residual per the null-company_id invariant.

Five genuine split-supplier units, each correctly recorded as 2+ company rows rather than forced into one: Schkopau, Schwielowsee, Feldkirchen-Westerham (p6a); Böhl-Iggelheim (Böhl→Zweckverband Pfälzische Mittelrheingruppe, Iggelheim→Gemeindewerke Haßloch), Emsbüren (Ahlde Ortsteil→TAV, rest→ Wasserverband Lingener Land) (p6b). One caught false-positive: Gemeindewerke Bobenheim-Roxheim GmbH looks like a water utility by name but its own site says Stadtwerke Frankenthal actually delivers the water — not minted. Another near-miss: wbv-exter.de ("Wasserbeschaffungsverband Exter-Süd") matched Extertal by river name but its own Mitgliederinformation names Vlotho (Kreis Herford) — a different place; not claimed.

Domain-collision check (mandatory, across all roster.part-*.jsonl + roster.jsonl) — clean. Only the 3 known pre-existing accepted collisions remained (sw-augsburg.de, zvo.com, emkendorf.de), nothing new from p6a/p6b.

New host traps: several more Nuxt/JS-shell municipal sites needed r.jina.ai proxying (Raubling, Planegg, Burgkirchen, Feldkirchen-Westerham, Malente, Neuhof, Ruppichteroth); wasserwerke-zwickau.de and wbv-exter.de both have broken TLS chains (curl -k workaround, same class as bodensee-wasserversorgung.de/stadtwerke-kleve.de). No PDF tool available in either subagent sandbox (no pdftotext, no python3) — blocked verbatim confirmation of Klipphausen's and Hünstetten's Wasserversorgungssatzung PDFs (recorded medium/low confidence with the gap noted, not guessed past it).

Ran the Finish steps: map_roster.mjs (7,912 total links, 108 needing review — 105 unmatched + 3 ambiguous, same no-AGS-by-construction shape as every prior run) → consolidate_roster.mjs (1,399 distinct companies, up from 1,360; 6 shard-level last-shard-wins duplicates, all pre-existing, none new) → coverage.mjs → build_gv_layer.mjs.

Population coverage 79.44% → 80.30% (+0.86pp); municipalities claimed 7,011 → 7,082 (+71, net of overlap dedup and bonus harvest against the 60 raw seeds).

PHASE 2A IS NOW COMPLETE. gemeindeverband-queue.csv has zero singleton units with residual_population >= 10,000 remaining except Bannewitz itself (still queued because it's genuinely unresolved, not because the phase pool missed it) — the next-largest singleton is Dettingen an der Erms at 9,993, below the phase-2a floor. Stopped here per the skill's explicit boundary: do not descend below 10,000 inhabitants; phase 2b (~2,700 small singletons + 701 2–4-member units, 7.3M people, where the municipal-website route measurably fails) is a deliberate decision for Frédéric, not an automatic continuation.

For next run: phase-2a is done — this run should NOT auto-continue into phase 2b. Escalate to Frédéric for a go/no-go on 2b before any further discovery batches. If a retry on Bannewitz is ever wanted, the Sachsen state Trinkwasserversorgungsgebiete registry cross-check (apps.gesunde.sachsen.de/trinkwasser.php) is the strongest tool available and was already checked negative. Next free company_id starts at wv-de-4266 (p6b's highest used ID); p6a's unused 4243–4249 and p6b's unused 4266–4279 are also free. Keep the explicit "you may not use the Agent/Task tool" line and the "grep the full candidate company name against roster.jsonl AND the sibling shard" line verbatim in every subagent prompt — 14th consecutive clean batch, no recursion. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT) — still not blocking, unfixed across 10+ runs now, and moot for phase 2a since it's now complete.