de:wasserversorger-discover

Everything is consolidated correctly and evidence shards are preserved. Final report:

The go/no-go blocker that stalled the last 9 runs was resolved between runs (SKILL.md updated 11:49 today to greenlight phase-2a). This run executed phase-2a's first batch: researched and verified 40 large kreisfreie Städte (Chemnitz through Jena) via two synchronous subagents doing Impressum/water-page verification, all 40 resolved with 0 ambiguous/unmatched. resolve_singleton.mjs's pre-pass turned out to be broken in this environment (missing TASKDIR mount) but wasn't needed — went straight to search-and-verify. Population coverage jumped 38.97% → 46.57% (+7.6pp) from just 40 municipalities, roster now 654 companies/6,356 links, no new domain collisions, remaining phase-2a pool is 1,189 units / 28.6M people for the next run to continue.

SKILL.md was edited at 11:49 today (after the 08:00 run's confirmation) to declare PHASE 1 COMPLETE and PHASE 2a the current phase — the Frédéric/Aurian go/no-go the last 9 runs were blocked on is resolved. This run executed phase-2a's first batch instead of a 10th confirmation.

Correction to my own analysis, logged so a future run doesn't repeat it: I first tried to size the phase-2a pool with awk -F',' directly on gemeindeverband-queue.csv and got wildly wrong numbers (70 units/5.8M, then 323/5.8M) versus the skill's stated 1,229 units/34.9M. The cause was mine, not a data bug — ~1,572 of 3,877 rows have a quoted comma inside the unit name (e.g. "VVG der Stadt Bruchsal"-style names or Land names), which naive -F',' splits incorrectly. Re-ran with lib.mjs's proper quote-aware parseCsv and got exactly 1,229 units / 34,927,663 people, matching the skill. Lesson: never hand-parse this campaign's CSVs with a naive split — always go through lib.mjs::parseCsv, even for something that looks like a simple 6-column file. Also re-derived what "singleton" means here precisely: a unit with members_residual === 1, not members_total === 1 — a large Verbandsgemeinde with 29 of 30 members already claimed and 1 left also counts as a phase-2a "singleton" for this pool.

Batch: took the top 40 units of the 1,229-unit pool (singleton units, `residual_population

= 10,000, sorted descending) — all large kreisfreie Städte (Chemnitz down to Jena, 109k-246k people each). Tried resolve_singleton.mjsas the skill's suggested pre-pass first; it hard-fails in this environment —TASKDIRresolves to/_tasks/netzbetreiber-contact/german-water(5..up fromcampaigns/wasserversorger), and neither that directory nor gemeinden_deutschland.csvinside it exists on this container. Confirmed withfind /— genuinely absent, not a permissions issue. **Given the script's own measured 7.5% unattended accuracy (per the 08:00 run's validation scoring), this is not a loss**: skipped the pre-pass entirely and went straight to the method the skill actually prescribes for a city — search + Impressum verification — via two synchronous general-purpose subagents (20 cities each, blocked on both in this turn, consistent with the "never spawn background agents" rule). Whoever restores the missingTASKDIR/gemeinden_deutschland.csv` mount should know the fallback works fine without it for this tier; it isn't a hard dependency of the discovery method, only of that one optional script.

Result: 40/40 resolved, all Impressum- or dedicated-water-page-verified, 0 unresolved. 4 of the 40 already existed in the roster under a different city (ThüWa/stadtwerke-erfurt.de wv-de-911, GELSENWASSER wv-de-122, evm wv-de-358, JenaWasser wv-de-418) — reused those company_ids rather than duplicating. RWW (rww.de) resolved identically for Oberhausen, Mülheim an der Ruhr and Bottrop and was deduped to one company (wv-de-3005) with three link rows, not three companies. 34 genuinely new companies got fresh ids wv-de-3001..3034 (skipping reused/existing ids), landing just above the prior max (wv-de-3000, the Mittelholstein phase-1 shard). One had no independently resolvable domain (Wasserversorgung Herne GmbH & Co. KG, a 50/50 Stadtwerke Herne/Gelsenwasser JV with no public site of its own) — recorded domain_status: pending_domain per protocol rather than guessed. map_roster.mjs: 0 ambiguous, 0 unmatched on all 6,356 links. consolidate_roster.mjs: 654 distinct companies (620→654), roster-links 6,356 rows.

Coverage moved 5,762→5,802 municipalities (52.7%→53.0%) but population 38.97%→46.57% (+7.6 points) from only 40 rows — the sharpest population/unit ratio yet in this campaign, exactly as PLAN.md/SKILL.md predicted for the head of the singleton pool (Chemnitz 245,618 down to Jena 109,725 each). Phase-2a pool remaining: 1,189 units / 28.58M people (next up: Salzgitter, Trier, Siegen, Moers, Gütersloh, all ~100-105k). Domain-collision check: same 1 known hit (emkendorf.de, unchanged since 2026-08-19) — no new collisions from this batch.

No CAPTCHA/anti-bot issues, no forms submitted, no contact attempted — research only, all fetches via WebFetch/WebSearch against the suppliers' own public sites.

For next run: phase-2a is live and moving — continue taking the top of the singleton pool by residual_population descending (Salzgitter 104,970 next) in batches of ~40-60, same method (2 synchronous subagents, Impressum/water-page verification, dedupe on official_domain against the existing roster before minting a new company_id, watch for one company serving several cities in one batch as RWW did here). resolve_singleton.mjs's TASKDIR dependency is still broken in this environment — don't lose time on it; do the search-and-verify method directly. Stop phase-2a and report when the pool empties or residual_population drops below 10,000 (do not silently descend into phase-2b, per SKILL.md's explicit boundary).