de:wasserversorger-discover

Journal entry appended. Here's the final report:

Phase-2a batch 9 complete: resolved all 60 assigned singleton units (Rees → Neustrelitz, 20,191–21,913 residents each) via two clean synchronous subagent shards, no background-agent recursion. Minted 49 new companies and matched 13 to pre-existing regional suppliers via mandatory pre-mint grep checks; population coverage rose from 67.44% to 68.95% (+1.51pp, 6,266→6,326 municipalities claimed), with the post-merge domain-collision check confirming zero new collisions introduced. Phase-2a pool now stands at 696 units / 9.86M people remaining, with the next handoff (starting at Lilienthal, company_id range from wv-de-3535) recorded in the journal for the next run.

Continued phase-2a from the 22:00 run's exact handoff (verified pool: 756 units / 11.12M people, next-up list matched exactly — Rees down to Neustrelitz). resolve_singleton.mjs was not retried (still reported broken last run); both subagents researched directly via WebSearch/WebFetch per the skill's "Per municipality" method.

Took the next 60 singleton units by residual_population descending, 21,913 (Rees) down to 20,191 (Neustrelitz). Split 2 SYNCHRONOUS subagents (p2p / p2q, 30 cities each), each launched with run_in_background: false and the exact required line ("You may not use the Agent/Task tool...do not end your turn until output files exist"). Both finished cleanly on the first try — no delegation, no background children — 6th consecutive batch confirming the fix holds. Non-overlapping company_id ranges (3481-3510 / 3511-3540).

All 60 resolved, 0 fully unresolved, 3 pending_domain (Zweckverband Ampergruppe's Puchheim-Bahnhof half, Gemeindewerke Nottuln, Gemeindewerke Neunkirchen-Seelscheid — municipal departments/Zweckverbände with no independently confirmed domain of their own). 49 new companies minted across both shards (26 in p2p, 23 in p2q), 13 municipalities matched to pre-existing roster companies instead of minting (Wipperfürth→BEW, Eckernförde→existing Stadtwerke Eckernförde, Elsdorf→RWW, Xanten→KWW GmbH, Spremberg→SWAZ, Stadtlohn→LokalWerke, Geseke→VGW GmbH, Sondershausen→TAZ Helbe-Wipper, Zerbst/Anhalt→Heidewasser GmbH, Senden(NRW)→GELSENWASSER AG, Duderstadt→Eichsfelder Energie- und Wasserversorgungs GmbH, Neustrelitz→Wasserzweckverband Strelitz, Werdau→Wasserwerke Zwickau GmbH) — each caught by the mandatory grep-both-names step before minting.

The mandatory post-merge cross-shard domain-collision check (run across both new shards + the base roster.jsonl, before consolidate_roster.mjs) found 0 new collisions — only the same 2 pre-existing/accepted hits from prior runs (sw-augsburg.de keep-both parent/subsidiary, emkendorf.de 3-way small-Eigenbetrieb share). Also checked new-shard-vs-new-shard for exact company-name matches (a check not yet formalised in the skill but cheap and worth keeping): 0 hits. Both subagents also independently caught their own near-misses before minting: p2p flagged Spremberg's SWAZ as already existing under the Amt Döbern-Land discovery; p2q flagged Coswig (Sachsen) vs. Coswig (Anhalt) and Steinhagen (NRW) vs. two same-named Mecklenburg villages as name collisions to guard against, and confirmed Stadtwerke Herford serves Enger's gas/heat but explicitly not its water, and Stadtwerke Zerbst GmbH does baths/gas/electricity but not water (Heidewasser GmbH is the actual supplier) — both good examples of the skill's non-supplier filter applied correctly at the brand level, not just the entity-type level.

Genuine within-municipality overlaps recorded as separate link rows per "Overlap is real": Xanten (KWW GmbH primary + Stadtwerke Kalkar for its carved-out districts), Zossen (KMS Zossen excl. Nunsdorf/Schöneiche), Zülpich (Verbandswasserwerk GmbH excl. WZV Neffeltal districts), Puchheim (WBV Puchheim-Ort + Zweckverband Ampergruppe for Puchheim-Bahnhof), Fröndenberg/Ruhr (Stadtwerke Fröndenberg Wickede + GELSENWASSER for 6 western Ortsteile).

Ran the Finish sequence: map_roster.mjs (6,901 links total, 6 unmatched — same 6 administrative-unit/Ortsteil names with no direct AGS as last run, no_ags_for_this_name, left unmatched rather than guessed) → consolidate_roster.mjs (1,033 distinct companies, up from 984; 6 shard-level duplicates resolved by last-shard-wins, verified all 6 pre-existing from batches before this one, none from this run's p2p/p2q shards) → coverage.mjs → build_gv_layer.mjs. Population coverage 67.44% → 68.95% (+1.51pp); municipalities claimed 6,266 → 6,326 (+60, exactly the seeded count — no bonus harvest this batch since singleton units by definition claim only themselves, unlike multi-member-unit sweeps). Domain-collision check after merge: same 2 known/accepted hits, confirmed no new ones.

Phase-2a pool remaining: 696 units / 9.86M people (next up: Lilienthal 20,166, Borna 20,131, Nidderau 20,119, Telgte 20,069, Wilnsdorf 20,039, Kürten 20,033, Meinerzhagen 20,019, Moosburg a.d.Isar 20,012, Donauwörth 19,990, Leinefelde-Worbis 19,957). Pool has now dropped under 10M people remaining — roughly 4-5 more batches of this size should exhaust phase-2a per the originally estimated ~34.9M-person / 1,229-unit pool from 2026-08-24.

For next run: continue phase-2a from Lilienthal down, same method. Next free company_id range starts at wv-de-3535 (this run used 3481-3506 in p2p contiguous, and 3511-3534 in p2q non-contiguous with one gap at 3524 — that single slot and everything from 3535 up is free; no retirements this run, unlike the last two). Keep the explicit "you may not use the Agent/Task tool" line verbatim in every subagent prompt — 6th consecutive clean batch, no recursion. Keep grepping the existing roster on both municipality name and candidate company name before minting — it caught 13 matches this batch, more than any prior single batch, likely because phase-2a is now deep enough into mid-size cities that regional multi-city utilities (GELSENWASSER, RWW, Heidewasser, Eichsfelder EWV) increasingly already cover them from earlier sweeps. Continue running the mandatory post-merge domain-collision check every batch regardless — it has now returned clean (0 new collisions) for two consecutive batches, but that is exactly the population where it previously caught real duplicates (Schleswig, Rathenow, Schaumburg-Lippe, Heide all happened in this same size range), so do not treat two clean runs as reason to skip it. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT per last run's note) — still not blocking since the direct-research path works, but now unfixed across 3+ runs.