de:wasserversorger-discover

Phase-2a batch 10 complete: worked 60 singleton units (Lilienthal down to Baiersbronn, all ≥10k population) via two synchronous shards, raising population coverage 68.95% → 70.65% (+1.70pp) and claimed municipalities 6,326 → 6,422. Both shards independently caught and fixed cross-shard duplicate company mints during self-checks (concurrent writers can't see each other's in-flight data), and my own mandatory post-merge collision check confirmed zero new collisions beyond the 2 pre-existing known/accepted ones. Roster now stands at 1,073 companies; phase-2a pool is down to 195 units (2.36M people) — roughly 3 more batches to exhaust it.

Continued phase-2a from Lilienthal down (top of gemeindeverband-queue.csv singleton pool, ≥10,000 residual population), per the prior run's note. 60 units split into 2 synchronous shards of 30 (p2r, p2s), company_id ranges wv-de-3535–3565 and wv-de-3566–3596 respectively. Both shard prompts carried the mandatory "you may not use the Agent/Task tool" line verbatim — 8th consecutive clean batch, no recursion.

Both shards independently ran their own domain-collision self-check before finishing and each caught cross-shard duplicate mints against companies the other shard had just minted (they ran concurrently, so neither could see the other's in-flight writes): p2r found 11 of its 29 draft mints already existed (AggerEnergie, Trinkwasserverband Verden, WVVO, Verbandswasserwerk GmbH, ZVO Energie, MAWV, WSE, Amperverband, gKU VE|MO, KEW AG, Wasserverband Wesermünde) and remapped its link rows to the pre-existing ids; p2s independently caught 3 (WSE, WAZV "Der Teltow", WAV Osterholz) the same way, and separately flagged that p2r still had leftover duplicates at the time p2s ran its own check — a timing artifact of running concurrently, already resolved by the time p2r's own report landed. Ran the orchestrator-level collision check myself anyway, as the SKILL requires as the very last step regardless of what either shard reports: across every roster.part-*.jsonl shard plus roster.jsonl, found exactly the same 2 pre-existing known/accepted collisions (sw-augsburg.de, emkendorf.de) and zero new ones — confirmed again after the full merge. This is the case the skill's banner warns about (a company minted twice under two different ids, catchable only by re-running the check across all shards together, post-merge) — this batch is evidence the pattern recurs by default under concurrent shards and that the shard-level self-checks, while a good sign, are not a substitute for the final orchestrator-level one.

Ran the Finish sequence: map_roster.mjs (7,047 links total, 24 unmatched — up from 6 last run, all Ortsteil/district-level carve-outs newly recorded this batch with no direct AGS by construction: Kürten-Bechen, Eikamp/Odenthal, Puchheim-Bahnhof-style sub-splits, several Saarland Ortsteile from the WVO GmbH member list — left unmatched rather than guessed, per rule) → consolidate_roster.mjs (1,073 distinct companies, up from 1,033; 6 shard-level duplicates resolved by last-shard-wins, all 6 verified pre-existing from batches before this one — none in the 3535+ range this run used) → coverage.mjs → build_gv_layer.mjs. Population coverage 68.95% → 70.65% (+1.70pp); municipalities claimed 6,326 → 6,422 (+96, more than the 60 seeded — this run had real bonus harvest, unlike the last one: WVO GmbH's Versorgungsgebiet page claimed 14 bonus Saarland municipalities beyond its 2 seeded ones, Kreiswerke Olpe claimed 5 bonus Kreis Olpe municipalities beyond Wenden, WSE and WAZV "Der Teltow" each yielded further bonus members from reused-company member lists).

Phase-2a pool remaining: 195 units / 2.36M people (next up: Sandhausen 15,330, Reken 15,109, Rellingen 15,026, Rehlingen-Siersburg 14,932, Malsch 14,880, Ritterhude 14,836, Münster (Hessen) 14,813, Büttelborn 14,685, Eching 14,627, Niederkrüchten 14,619). Pool has dropped from 696 units three runs ago to 195 — roughly 3 more batches of this size should exhaust phase-2a.

For next run: continue phase-2a from Sandhausen down, same method. Next free company_id starts at wv-de-3597 (this run's two shards used 3536–3587 with several allocated-but-unused slots from both ranges freed by dedup — nothing above 3587 is taken). Keep the explicit "you may not use the Agent/Task tool" line verbatim in every subagent prompt. Keep instructing shards to grep the existing roster on both municipality name and candidate company/domain before minting, and keep running the mandatory post-merge, cross-shard domain-collision check yourself regardless of what shards report — this run is the clearest evidence yet that it is not optional even when both shards say they already checked: concurrent shards cannot see each other's in-flight writes, so a same-run collision is only visible after both have finished and merged. No non-supplier traps or new host-blocking issues this batch. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT) — still not blocking, now unfixed across 4+ runs.