de:wasserversorger-discover

Phase-2a batch 6 complete: resolved 60/60 cities (Burgdorf down to Heppenheim), minted 47 new companies and reused 16 existing ones, lifting population coverage from 61.46% to 63.57% (6,102/10,943 municipalities). The run hit a real process failure — both shard subagents spawned their own background sub-agents against the skill's rule, which caused duplicate work and one genuine cross-shard defect (AVU AG minted twice under two company_ids for Schwelm); I caught and fixed this during the final merge, then hardened SKILL.md with the exact instruction line that stops subagents from delegating. Domain-collision check stayed at the same single known pre-existing hit (emkendorf.de), nothing new. Phase-2a pool now stands at 882 units / 14.18M people remaining, next up Strausberg (27,719) — journal updated for the next run.

Continued phase-2a from the 08:00 run's exact handoff (verified pool state matched: 942 units / 15.95M people, next-up list identical). Took the next 60 singleton units by residual_population descending, Burgdorf (31,051) down to Heppenheim (Bergstraße) (27,864). Split 2 synchronous subagents (p2j 30 cities / p2k 30 cities), non-overlapping company_id ranges (3281-3310 / 3311-3340) — this part followed the skill exactly. What happened after did not.

Process failure, in detail, because it's the important part of this run. Both top-level subagents violated "do the work yourself, synchronously" — each spawned its own background sub-agents (5 regional groups for p2j via the Task tool; several ad-hoc regional Agent calls for p2k) and then ended its turn with "I'll wait for them to report back" — the exact failure this skill's banner warns about, just one level deeper than the banner anticipated. Neither parent agent had a way to actually block on background children once it existed as a run_in_background:false call that had already returned to me; sending it a "stop delegating, wait synchronously, merge yourself" instruction via SendMessage got the same "I'll wait" response again even after being told explicitly not to. What saved the run: grandchildren's completion notifications arrived directly to my session (the top-level orchestrator), not to the parent that spawned them — an implementation detail I didn't ask for and can't rely on. p2j's five sub-batches were trackable via the shared Task tool (TaskList/TaskGet), so I could poll their output files on disk and merge myself once all five landed (24 new companies, 30 links, verified 0 collisions). p2k's parent eventually did recover on its own, waited out its own children, and produced a complete, independently-merged roster.part-p2k.jsonl/roster-links.part-p2k.jsonl (30/30 resolved) — including re-researching 4 cities itself after one grandchild's report went to me instead of it. But I didn't know that was coming: after ~10 polling cycles with zero p2k files on disk, I concluded it was stalled and dispatched two fresh replacement subagents for the remaining 26 cities with much more explicit "you may not use the Agent/Task tool, do not delegate, do not end your turn until files exist" instructions (this worked — both finished cleanly, no further delegation). The original p2k parent's full merge landed while the replacements were still running, so I ended up with three overlapping, redundant result sets for the same 30 cities and colliding company_id ranges. Caught one real cross-shard defect from this mess: AVU AG (the Ennepe-Ruhr regional utility) got minted twice — wv-de-3289 in p2j (for Gevelsberg/ Ennepetal, high confidence, TrinkwV page names Schwelm too) and wv-de-3331 in p2k (for Schwelm specifically, medium confidence, weaker evidence) — because the two shards' research happened concurrently and neither could see the other's not-yet-merged output. Fixed by hand: dropped the wv-de-3331 roster row, repointed Schwelm's link row to wv-de-3289 (keeping the better-evidenced citation), discarded the redundant replacement-agent files entirely (their 23 cities were already covered, better, in the parent's own merge). Net correction to the skill's assumption: telling a subagent to "do the work synchronously yourself" in a shared preamble is not enough — general- purpose agents default to spawning parallel sub-agents for anything that looks parallelizable unless the prompt explicitly says "you may not use the Agent or Task tool for this." The two replacement agents given that explicit line did not delegate. For next run: put that explicit line in every research-subagent prompt, not just the top-level banner — it is the one phrasing that actually worked here.

Also load-bearing for next time: the final merge step is not optional busywork, it is where cross-shard duplicates get caught — no single shard could have seen the AVU AG collision, only the person merging both shards against each other and against roster.jsonl could. Always recompute the dedupe check (by domain, across roster.jsonl + every roster.part-*.jsonl shard about to be merged, not just the pre-existing roster) as the very last step before running consolidate_roster.mjs, even when every individual shard reports "0 collisions" on its own.

Result once untangled: 60/60 resolved, 0 unresolved. 47 new companies minted (24 in p2j: wv-de-3281-3291, 3296-3298, 3300-3309; 23 in p2k: wv-de-3311-3330 less the retired 3331), 16 reused across both shards (GELSENWASSER wv-de-122 ×2 [Werne, Waltrop], Wasserversorgung Beckum wv-de-3229 [Oelde], VGW GmbH wv-de-3146 [Rietberg], AVU AG wv-de-3289 ×3 [Gevelsberg, Ennepetal, Schwelm], Wasserzweckverband Saale-Fuhne-Ziethe wv-de-2600 [Bernburg], Wasserverband Heidekreis considered-and-rejected for Walsrode [see trap below], Avacon Wasser wv-de-968 [Springe], WAZV Arnstadt wv-de-1180 [Arnstadt], ZV Kaltenkirchen/Henstedt-Ulzburg wv-de-1164 [Henstedt-Ulzburg], Hamburger Wasserwerke wv-de-102 [Reinbek], Kreiswasserwerk Heinsberg wv-de-3159 [Wegberg — this one a pure latent dedupe win, the company was already in the roster from an earlier Erkelenz batch and its own homepage already named Wegberg]).

Trap patterns, same shapes as every recent batch, worth re-confirming rather than re-explaining: energy-only "Stadtwerke" brand ≠ water supplier (Waltrop→GELSENWASSER, Saalfeld→ZWA Saalfeld- Rudolstadt not the energy-only Stadtwerke Saalfeld GmbH, Schwelm→AVU not Technische Betriebe Schwelm AöR which is wastewater-only); wholesale-vs-retail splits at the Impressum level (Höxter: VGW extracts, GWH retails; Leichlingen: WVV Rhein-Wupper wholesale, Stadtwerke Leichlingen retail; several Hessen cities buying from Hessenwasser GmbH & Co. KG but billing under their own city Stadtwerke/Eigenbetrieb — Griesheim, Hattersheim, Kelkheim; Bad Neuenahr-Ahrweiler buying from the Wahnbach reservoir but billing directly). Two governance-vs-retail near-misses caught by checking the candidate's own site rather than trusting an existing roster membership list: Walsrode (Wasserverband Heidekreis, wv-de-2025, lists "Stadt Walsrode" as a member for Verbandsumlage purposes, but Stadtwerke Böhmetal GmbH is the actual retail biller — minted fresh rather than reusing) and Osterholz-Scharmbeck (Wasser- und Abwasserverband Osterholz, wv-de-2204, is the bulk body; Osterholzer Stadtwerke GmbH & Co. KG bills — minted fresh). One decoy domain: stadtwerke- baunatal.de now resolves to unrelated squatted/gambling content, real site is baunatal.de. One distinct-but-same-brand trap: NEW Tönisvorst GmbH (HRB 9096) is legally separate from both NEW AG (wv-de-123) and NEW NiederrheinWasser GmbH (wv-de-3247) despite sharing the new.de group site — minted separately with official_domain: null/pending_domain since it has no domain of its own. Friedberg (Hessen) vs Friedberg, St. (Bayern) name collision handled correctly by both subagents independently, cross-referenced in both records' notes.

Ran the Finish sequence: map_roster.mjs (6,659 links, 0 ambiguous/unmatched) → consolidate_roster.mjs (896 distinct companies, up from 849; 6 shard-level duplicate company_ids found and resolved by last-shard-wins, all pre-existing from earlier batches, none from this run's own shards) → coverage.mjs → build_gv_layer.mjs. Population coverage 61.46% → 63.57% (+2.11pp); municipalities claimed 6,042 → 6,102 (+60, confirming no accidental double- or under-claims after the AVU fix). Domain-collision check across roster.jsonl: back to the same 1 known hit (emkendorf.de, unchanged since 2026-08-19) — confirmed clean, nothing new introduced by this batch (the one real collision this batch produced, AVU AG, was cross-shard between two roster.part-*.jsonl files rather than against the base roster.jsonl, so it wasn't visible to that specific check until the shards were merged first — worth remembering that the domain-collision check needs to run after the shard merge, not before).

Phase-2a pool remaining: 882 units / 14.18M people (next up: Strausberg 27,719, Teltow 27,682, Sundern (Sauerland) 27,654, Grimma 27,529, Northeim 27,326, Olching 27,310, Neukirchen-Vluyn 27,140, Verden (Aller) 27,121, Werder (Havel) 27,065, Butzbach 27,046).

For next run: continue phase-2a from Strausberg down, same method, next new-id range starts at wv-de-3335 (3331-3334 were consumed/retired in this run's cross-shard cleanup — don't reuse them for anything else, just skip past them). Most importantly: put the explicit "you may not use the Agent/Task tool, do not delegate, do not end your turn until output files exist" line directly in every research-subagent prompt — the generic "do this synchronously" framing in the skill banner was not sufficient to stop two independent subagents from spawning their own background children this run. If a shard still goes quiet for a long stretch, prefer messaging it for a status check before assuming it's dead and dispatching replacements — the p2k parent's independent recovery mid- replacement is exactly the race that produced this run's one real defect.