de:wasserversorger-discover

Ran phase-2a batch 14 of the wasserversorger discovery campaign: two synchronous subagents researched 60 singleton-unit municipalities (Bovenden 14,078 down to Südliches Anhalt 12,857), harvesting 82 bonus municipalities from Verband member lists along the way. Population coverage rose from 77.02% to 78.21% (6,815 → 6,915 municipalities claimed), with 1,334 distinct companies in the roster and zero new domain collisions after fixing 3 duplicate mints caught by the mandatory cross-shard check.

One notable catch: I mislabeled the vkey column as AGS when building the batch list, which would have silently under-counted all 60 researched municipalities as still-unclaimed. I caught this via the population-delta sanity check, derived and verified the correct AGS values, repaired the affected records, and reran the full merge pipeline — recovering the missing ~1pp before finalizing. Next run should continue from Wadersloh (pool now 252 units / 2.86M people); journal updated with the vkey/AGS pitfall so it isn't repeated.

Started by listing the campaign directory and checking file mtimes against the last journal entry (2026-08-27 03:00): newest shards (p3a/p3b) predated roster.jsonl's merge timestamp, confirming that run's own merge completed cleanly — no orphaned shards this time. Recomputed the pool fresh via coverage.mjs + build_gv_layer.mjs anyway (77.02%, 6,815 claimed — matched the handoff exactly).

Own bug, caught and fixed before it reached the final numbers: when building this run's batch list from gemeindeverband-queue.csv, filtered correctly on members_total===1 (per the 03:00 run's hard-won lesson) but then mislabeled the vkey column (col 1) as "AGS" when handing the batch to the two subagents — vkey and ags share a 5-digit Kreis prefix but differ after that (vkey inserts a literal 0 then the Gemeinde's 3-digit suffix as 4 digits; ags is prefix+suffix directly, e.g. Bovenden vkey 031590007 vs real ags 03159007). Both shards used the seeded value verbatim, exactly as instructed ("use the seeded AGS given above verbatim") — correct shard behavior, wrong input. map_roster.mjs's preresolved path trusts a non-null ags without validating it against the real Gemeinde list, so all 60 seeded links (63 rows counting 3 municipalities with paired/split links) silently carried an unmatchable 9-digit value — coverage.mjs recomputed after the first merge showed only +40 municipalities/+0.23pp instead of the expected 60/1.2pp, which is what surfaced it (the pool after recompute still listed all 60 batch cities at the top, meaning they'd never actually been claimed despite being fully researched). Verified the derivation rule (ags = vkey[0:5] + vkey[6:9]) against gemeindeverband-members.csv's own vkey→ags column for all 60 entries (0 mismatches) before applying it, then repaired the ags field in both roster-links.part-p4a.jsonl and roster-links.part-p4b.jsonl directly (63 rows fixed) and reran the whole Finish sequence from map_roster.mjs onward. For any future run building a batch straight from gemeindeverband-queue.csv: column 1 is vkey, NOT the municipality's AGS — pull the real AGS from gemeindeverband-members.csv (vkey→ags mapping, one row per member) instead, or derive it with the rule above only after confirming it holds for that batch. This is a different, more consequential mistake than the 03:00 run's residual-vs-total filter bug: that one misordered the queue, this one would have permanently under-counted 60 correctly-researched municipalities as still-residual, likely triggering redundant re-research of the same cities in a later run.

Batch itself: top 60 of the freshly-computed pool (members_total===1, residual_population>=10000, descending), Bovenden (14,078) down to Südliches Anhalt (12,857). Split 2 SYNCHRONOUS subagents (p4a / p4b, 30 cities each, run_in_background: false, dispatched together in one message), both carrying the "you may not use the Agent/Task tool... do not end your turn until output files exist" line and the "grep the full candidate company name" line verbatim. Both finished cleanly, no delegation, no background children — 12th consecutive clean batch, no recursion. Non-overlapping company_id ranges (3942–3971 / 3972–4001); p4a used up to 3968 (27 new, 3 pre-existing companies reused via the grep check), p4b used up to 4001 (30 minted, later corrected to 27 — see below).

Domain-collision check (mandatory, across all roster.part-*.jsonl + roster.jsonl) caught 3 genuine duplicate mints by p4b, all bonus-harvest member-list entries that re-minted a company already in the roster despite the shard's own pre-mint grep: wv-de-3994 "Heidewasser GmbH" (duplicate of pre-existing wv-de-1118, same domain heidewasser.de), wv-de-4000 "Wasser- und Abwasserzweckverband Gotha und Landkreisgemeinden" (duplicate of wv-de-943, wazv-gotha.de), and wv-de-3985 "Zweckverband KÜHLUNG" (duplicate of wv-de-970, zvk-dbr.de) — all three read as partial/re-crawled member lists of Verbände already in the roster from 2026-08-20 sweeps (parts l/m/o), where the grep evidently missed the exact name string used this run. Fixed by hand: dropped the 3 duplicate company rows from roster.part-p4b.jsonl and repointed all 45 link rows referencing them to the existing company_ids, before any merge script ran. The other 2 collisions found (sw-augsburg.de, emkendorf.de) are the same pre-existing accepted patterns as every prior run.

All 60 seeded municipalities resolved (0 unresolved). Bonus harvest: 31 (p4a: TAV Bourtanger Moor, Zweckverband Naab-Donau-Regen) + 51 (p4b: Zweckverband KÜHLUNG 26, WAZV Gotha 16, Zweckverband Aschafftalgemeinden 6, WAZV Jüterbog-Fläming 3) = 82 bonus link rows, though several overlapped municipalities already claimed by the same or other Verbände (net new claimed municipalities this run was 100, not 60+82 — dedup happens in consolidate_roster.mjs/coverage.mjs). Notable finds: Frankenberg/Sa. name-collision with an unrelated "EGF EnergieGesellschaft Frankenberg" (Hessen) — caught via raw-HTML curl after WebFetch's summarizer silently dropped the real supplier row (the known truncation caveat, still live). Erbach (Odenwaldkreis, Hessen) vs. the already-rostered Erbach (Donau), Baden-Württemberg — correctly kept distinct. stadtwerke-neustadt.de is a domain-collision trap unrelated to Neustadt a.d.Aisch (resolves to Neustadt a. Rbge., Niedersachsen instead) — correct domain neustadtwerke.de. New host traps: stadtwerke-solms.de (refused/timed out on every attempt), stadtwerke-winterberg.de and stadt-badlaasphe.de (JS bot-challenge under curl and WebFetch), zwa-aschafftal.de (>10 redirects under WebFetch, raw curl worked). rzv-glauchau.de reconfirmed as a standing ECONNREFUSED trap. No PDF tooling (pdftotext/poppler) available in the subagent sandbox — blocked one Beteiligungsbericht PDF extraction, noted as a gap rather than guessed.

Ran the mandatory orchestrator-level post-merge domain-collision check (not shard self-reports) twice — once before the AGS fix, once after the full Finish rerun — both times finding only the 2 pre-existing accepted collisions and nothing new. Ran the Finish sequence twice (once before discovering the AGS bug, once after fixing it): map_roster.mjs (final: 7,681 links total, 79 unmatched + 3 ambiguous — same shape as prior runs, mostly Ortsteil/administrative carve-outs with no AGS by construction) → consolidate_roster.mjs (1,334 distinct companies, up from 1,280; 6 shard-level last-shard-wins duplicates, all pre-existing, none new) → coverage.mjs → build_gv_layer.mjs.

Population coverage 77.02% → 78.21% (+1.19pp); municipalities claimed 6,815 → 6,915 (+100). (The pre-fix intermediate run had shown only 77.25%/+40 municipalities — the AGS fix alone recovered the missing +0.96pp/+60 municipalities.)

Phase-2a pool remaining (freshly computed): 252 units / 2.86M people (next up: Wadersloh 12,848, Kaufungen 12,838, Herzberg am Harz 12,792, Bad Fallingbostel 12,783, Hettstedt 12,783, Weeze 12,766, Altenstadt 12,764, Pfarrkirchen 12,764, Hungen 12,754, Fuldatal 12,752, Wächtersbach 12,731, Velten 12,727).

For next run: continue phase-2a from Wadersloh down, same method. When building the batch list from gemeindeverband-queue.csv, column 1 is vkey, not AGS — read the real per-municipality AGS from gemeindeverband-members.csv (vkey→ags) instead of assuming the queue's own key is usable directly. A future run should spot-check a handful of seeded AGS values against gemeindeverband-members.csv before dispatching subagents, the same way the 03:00 run learned to cross-check the pool's filter column. Next free company_id starts at wv-de-4002 (this run's shards used up to 3968 in p4a and 4001 in p4b before the 3 dedup fixes freed 3994/4000/3985 — those three IDs are also free to reuse, along with the older 3768–3791 gap). Keep the explicit "you may not use the Agent/Task tool" line and the "grep the full candidate company name" line verbatim in every subagent prompt — 12th consecutive clean batch, no recursion — though this run shows the grep alone isn't sufficient against every bonus-harvest re-crawl of an already-rostered Verband; the orchestrator- level post-merge collision check remains the real backstop and caught all 3 this time. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT) — still not blocking, unfixed across 9+ runs now.