de:wasserversorger-discover

Ran phase 2b's remaining shard 2 batch (30 VG/Amt units, BW-heavy) via two synchronous subagents, merged and verified against domain collisions (only the 5 known pre-existing ones, no new ones), and rebuilt the queue. Population coverage rose 81.7% → 82.8% (+1.1pp), municipalities claimed 7,343 → 7,556, roster grew to 1,613 companies (post-dedup — both subagents self-caught and fixed their own duplicate mints before reporting). 14 units remain genuinely unresolved after real effort (now back atop the queue) and both subagents hit their WebSearch quota mid-batch, which likely contributed to some of those gaps — details and a fresh queue snapshot are logged in the journal for the next run.

Continuation run: the 18:45 run earlier today (16-45-31-71acc5) selected a top-60-unit batch from gemeindeverband-queue.csv, dispatched shard 1 (30 units) plus the WWA-AB bulk-source harvest, but never dispatched shard 2 (the other 30 units, BW-heavy: VVG Rottenburg am Neckar, VVG Hockenheim, VVG Waldshut-Tiengen, etc.) and left off saying company_id wv-de-4701+ was clear to use.

Per the skill's instruction, re-ran build_gv_layer.mjs fresh first (queue/members reflect the fully merged post-18:45-run state), then took the current top 60 units (which turned out to be the same 60 as before — nothing else touched the queue in between) and split fresh into two 30-unit shards with claimed flags computed directly from links.jsonl+longtail.jsonl+roster-links.jsonl (the gemeindeverband-members.csv file lists all members nationally with no claimed flag — that has to be cross-referenced, not read off the CSV directly). Dispatched 2 synchronous subagents (the hard cap), each with company_id ranges wv-de-4500+ and wv-de-4700+ (well clear of the actual max on disk, 4439, and of the prior run's self-reported ~4453/4744 ceilings) and the full skill guidance (Satzung-first for RP, non-supplier filter, self-supply legitimacy, host traps, never-invent rule, per-unit append). Both ran fully synchronously and returned in-turn — no background-agent recursion.

Both subagents independently re-discovered and re-minted a handful of companies that already existed in roster.jsonl (shard1: 5 — ZVWKK, HWAZ, Wasserversorgung Riesa/Großenhain, Gennach-Hühnerbach-Gruppe, Wasserverband Gifhorn; shard2: 9 — Stadtwerke SH, WBV Mitteleider, WBV Lüneburg-Süd, WAV Fürstenwalde, FWA Frankfurt, Friedelsheimer Gruppe, TAV Börde, KWA Meiningen, Kugelberggruppe). Both caught it themselves via the mandated end-of-shard collision check, deleted their duplicate rows and remapped links to the canonical company_id before reporting — this is now the second run in a row where the self-check pattern worked as designed (see 18:45 run's note on the same thing). Re-ran the collision check myself across both shard outputs + roster.jsonl before merging (per the skill's explicit last-step requirement, since no single shard can see what the other just minted): zero new collisions, only the same 5 pre-existing ones already known (sw-augsburg.de, wvv.de, zvo.com, vgrd.de, emkendorf.de) — confirmed unchanged both before and after consolidate_roster.mjs, and again against companies.jsonl per the Finish-step-2 instruction.

Results:

• Population coverage: 81.7% → 82.8% (+1.1pp)
• Municipalities claimed: 7,343 → 7,556 (+213: 95+43-bonus from shard1, 98+43-bonus from shard2, net of the dedup remaps above)
• Residual: 3,600 → 3,387 municipalities, 15.30M → 14.38M people
• Roster: 1,525 → 1,613 companies (+88, post-dedup)
• Roster-links: 8,586 rows (8,019 distinct after dedup)
• Multi-member GV units remaining: 619 → 568 (covering 1,504 municipalities); singletons 1,882 → 1,880

Genuinely unresolved after real effort (14 units/members, not skipped): Mittelholstein (5/7 — Bendorf, Bornholt, Heinkenborstel, Tackesdorf, Wapelfeld — this unit's remaining members are now a third consecutive no-result pass, see 2026-08-22 and 18:45-run notes on Mittelholstein generally), Emlichheim (Niedersachsen, all 4), GVV Gullen (Bodnegg/Grünkraut/Waldburg), Uchte (all 4), Unkel (RLP, all 4), Gellersen (all 4), VVG Laupheim (Achstetten), VVG Biberach (Hochdorf, Ummendorf), VVG Riedlingen (Unlingen, Uttenweiler), Rochlitz (Sachsen, all 4), Olbersdorf (Sachsen, all 4), GVV Neckargerach-Waldbrunn (BW, all 4), Dänischenhagen (SH, all 4), Laage (MV, all 4). These are back at the top of the fresh gemeindeverband-queue.csv — a future run picking up the queue top-down will hit them again immediately; worth a different research approach (e.g. Kreis-level register lookup) rather than a third identical web-search attempt on the same handful.

Tooling constraint worth flagging for future runs: both subagents hit the WebSearch session call cap (~200) partway through their batch (shard1 around unit 19, shard2 around unit 16) and had to fall back to WebFetch/curl/direct PDF text extraction (shard2 found search.brave.com works as a WebFetch-based search fallback when native WebSearch is exhausted — Bing/DuckDuckGo/Yandex/Google/ Ecosia/Mojeek/Startpage all failed for different reasons: junk results, CAPTCHA, consent walls, 403). This is very likely why several of the above units ended up unresolved rather than a genuine absence of the data — a fresh-quota run may resolve some of them on a second pass. If planning >2 concurrent subagents per SKILL.md ever changes, or larger per-shard batches, budget WebSearch quota per shard explicitly — 30 units/shard came close to exhausting it here.

New host traps found: *.kasserver.com-hosted sites (gemeinde-mauern.de, kurort-oybin.de) have broken TLS certs, same class as bodensee-wasserversorgung.de — r.jina.ai read-proxy worked around it. amt-daenischenhagen.de's per-Gemeinde utility subpages returned persistent 403 even through that proxy — contributed to Dänischenhagen staying unresolved.

For next run: gemeindeverband-queue.csv and gemeindeverband-members.csv are freshly rebuilt as of this run (19:2x). Multi-member-first ordering still holds: 568 units / 1,504 municipalities ahead of 1,880 singletons. The queue top is now the 14 units this run couldn't resolve (see above) — worth trying a different method on those specifically rather than repeating the same web search, or simply taking units 15+ instead if the goal is throughput. company_id max on disk after this run: check roster.jsonl before minting (was 4439 pre-run; both shards' final IDs after dedup-remap are somewhere in the 4500s/4700s ranges, not contiguous due to the remap-and-delete dedup fixes).