de:wasserversorger-discover

Run complete. Final report:

Discovered water suppliers for 60 more German singleton-unit cities (Borna down to Hochheim am Main, pop. 18–20k each), all 60 resolved with 0 unresolved — 44 new companies minted plus a 16-town bonus harvest via Wasserversorgung Bischofswerda GmbH. Population coverage rose 71.99% → 73.5% (municipalities claimed 6,517 → 6,594), roster now at 1,156 companies, and the mandatory cross-shard domain-collision check found zero new collisions (only the 2 known pre-existing ones).

Notably, I caught and corrected a stale accounting bug from the prior run: it had reported the phase-2a pool at "128 units / 1.44M people," but recomputing fresh showed 481 units / 6.35M people actually remain (the previous "128" figure was simply wrong, not a data regression) — this is now documented in the journal with guidance to always recompute the pool fresh rather than trust a prior handoff.

Started by recomputing the pool fresh (coverage.mjs + build_gv_layer.mjs) instead of trusting the previous run's "128 units / 1.44M people, next up Wadersloh 12,848" handoff — and the fresh number didn't match: 544 singleton units ≥10,000 residual population, 7.54M people, top entry Borna 20,131, nothing near Wadersloh at the top. Checked whether this was a dedupe-fix regression (the 10:40 run's shards had deleted and repointed some links while self-fixing duplicate mints) — it wasn't: Borna/Nidderau/Telgte/Meinerzhagen etc. don't appear in roster.jsonl, any roster.part-*.jsonl, roster-links.jsonl, links.jsonl or longtail.jsonl at all, under any name or AGS. They were simply never touched. Population-coverage math is a rough independent check: phase-2a's starting pool (2026-08-24) was 1,229 units/34.9M people, 11 batches have directly worked ~640 units since, 1229-640=589 — close to the measured 544 (the gap is bonus harvest incidentally claiming some pool members without directly targeting them), and nowhere near 128. Conclusion: the "128 units" figure in the previous entry was a bug in that run's own accounting, not a real state — always recompute the pool from coverage.mjs/build_gv_layer.mjs fresh at the start of a batch; do not carry forward a previous run's stated pool size or "next up" list without verifying it against a fresh run of those two scripts first. This cost real: several batches between 2026-08-25 and today may have been working from an already-wrong idea of "how much pool is left," though the batches themselves (top-N by residual_population) were still individually correct since they re-sorted from the real queue file each time — only the summary number was wrong, not the selection.

Took the top 60 of the freshly-computed pool: Borna (20,131) down to Hochheim am Main (18,422), all above the correct threshold. Split 2 SYNCHRONOUS subagents (p2v / p2w, 30 cities each), both launched with run_in_background: false and the required "you may not use the Agent/Task tool... do not end your turn until output files exist" line verbatim. Both finished cleanly on the first try, no delegation, no background children — 10th consecutive clean batch. Non-overlapping company_id ranges (3667–3716 / 3717–3766).

All 60 resolved, 0 pending_domain, 0 unresolved — this batch's cities (all 18–20k population, genuine Mittelstädte) had unusually clean, findable municipal Stadtwerke. 44 new companies minted across both shards (22 in p2v, 22 in p2w; several IDs in each range left unused after each shard's own self-caught duplicate-mint fixes), the rest matched to pre-existing roster companies (Kreiswerke Main-Kinzig, Hamburger Wasserwerke, Wasserversorgung Beckum, Vereinigte Stadtwerke, ZWO, Bückeburg's existing entry, Lahnstein's, Seesen's, plus split cases for Hemmingen/Glinde). Bonus harvest beyond the 60: Ostbevern, Lauingen (Donau), an Unghausen Ortsteil, Neuenkirchen/Fintel/Vahlde, and — the biggest single pickup — Wasserversorgung Bischofswerda GmbH's full 16-town Verbandsgebiet (Arnsdorf, Burkau, Demitz-Thumitz, Frankenthal, Großharthau, Großnaundorf, Großröhrsdorf, Laußnitz, Lichtenberg, Ohorn, Ottendorf-Okrilla, Pulsnitz, Rammenau, Schmölln-Putzkau, Wachau, Wanzleben-Börde area via TAV Börde), materially fuller than a previous shard's 4-member record for the same company.

Both shards ran their own domain-collision self-check before finishing and both caught and fixed their own duplicate mints (p2v: 4 — twzv-leinetal.de, waz-ek.de, wah-nauen.de, wvr.de; p2w: 3 — Trink- und Abwasserverband Börde, Wasserversorgung Bischofswerda GmbH, Betriebsgesellschaft Wasser und Abwasser mbH Sömmerda), all against pre-existing roster companies from earlier batches, all outside their own 3667–3766 range, all repointed correctly before reporting done. p2w's own note is worth repeating: it self-caught its 3 duplicates only via the final domain-collision script, not its earlier per-city greps — its per-city greps checked AGS and name/domain fragments but skipped a full company-name grep on 3 occasions. Grep the full candidate company name, not just fragments, before minting — the current guidance ("grep on both municipality name and candidate company/domain") is not quite specific enough to catch this reliably.

Ran the mandatory orchestrator-level post-merge domain-collision check anyway, exactly as the skill requires: across all roster.part-*.jsonl shards before consolidate_roster.mjs, then again on the final merged roster.jsonl — both passes found only the same 2 pre-existing known/accepted collisions (sw-augsburg.de, emkendorf.de) and zero new ones. (Note: a simple lowercase+strip-www normaliser, as used here and in past runs' quick checks, does NOT reduce subdomains to eTLD+1 — it would miss a real subdomain-sharing collision like the pre-existing *.vgem-boos.de cluster, which only shows up as one same-domain group under a proper eTLD+1 reduction. That cluster is already correctly flagged in its own roster notes as an accepted shared-CMS pattern, not a defect, but a future collision check should reduce to eTLD+1 properly rather than just stripping www..)

Ran the Finish sequence: map_roster.mjs (7,251 links total, 36 unmatched — mostly Ortsteil/ administrative-unit carve-outs with no AGS by construction, plus 1 genuine ambiguous — "Steinbach" shared by 3 Gemeinden in Hessen/Rheinland-Pfalz/Thüringen, correctly left unmatched) → consolidate_roster.mjs (1,156 distinct companies, up from 1,112; 6 shard-level duplicates resolved by last-shard-wins, all pre-existing from before this run, none in the 3667+ range) → coverage.mjs → build_gv_layer.mjs. Population coverage 71.99% → 73.5% (+1.51pp); municipalities claimed 6,517 → 6,594 (+77, more than the 60 seeded — bonus harvest).

Phase-2a pool remaining (freshly computed, trust this number, not any prior handoff): 481 units / 6.35M people (next up: Schwalmstadt 18,420, Bad Berleburg 18,400, Bad Segeberg 18,399, Wörth am Rhein 18,387, Weißenburg i.Bay. 18,345, Vlotho 18,335, Bad Münstereifel 18,297, Bad Reichenhall 18,288, Heilbad Heiligenstadt 18,230, Buchen (Odenwald) 18,226).

For next run: continue phase-2a from Schwalmstadt down, same method — but recompute the pool yourself via coverage.mjs + build_gv_layer.mjs before trusting this handoff's numbers too; that discipline is what caught today's discrepancy and should now be standard, not exceptional. Next free company_id starts at wv-de-3742 (this run's two shards used up to 3741; some gaps below that were freed by self-fixed dedupes — nothing above 3741 is taken). Keep the explicit "you may not use the Agent/Task tool" line verbatim in every subagent prompt — 10th consecutive clean batch, no recursion. Keep instructing shards to grep both municipality name and candidate company/domain before minting, and now also the full candidate company name specifically (see p2w's miss above) — and keep running the orchestrator's own file-level post-merge collision check regardless of what shards report. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT) — still not blocking, unfixed across 6+ runs now.