de:wasserversorger-discover

Journal entry appended. The run is complete — final report:

Phase 2b VG grind continued: dispatched 2 synchronous subagents against the top 60 multi-member Gemeindeverband units (60 units, 240 residual municipalities). Population coverage rose 82.81% → 83.28% (+0.47pp), municipalities claimed 7,559 → 7,768 (+209), roster grew to 1,685 companies (+72). Notably, all 9 units that had failed two prior research passes were resolved this time by searching the supplier's own page instead of the administrative-unit umbrella site. Domain-collision check found only the same 5 pre-existing collisions (no new ones); 3 units (Oberviechtach, Gera-Aue, Kindelbrück) and 1 hard case (Auenland Südholstein) remain unresolved and are now atop the freshly rebuilt queue for the next run, with WebSearch-quota exhaustion flagged as a recurring throughput constraint at 30-unit shard sizes.

Scheduled run. Continuation of phase 2b's multi-member-unit grind. build_gv_layer.mjs was re-run fresh first (top of queue: the same 9 twice-failed units the 2026-08-27 18:00 run left — Emlichheim, Uchte, Unkel, Gellersen, Rochlitz, Olbersdorf, GVV Neckargerach-Waldbrunn, Dänischenhagen, Laage — plus Mittelholstein's remaining 5 were no longer at the very top since its residual is now < 4). Took the top 60 units, split into 2 fresh 30-unit shards (phase2b-vg3-shardA/B-input.json, cross-referenced against links.jsonl+longtail.jsonl+ roster-links.jsonl for claimed, matching the standard method), and dispatched 2 synchronous subagents (the hard cap), IDs wv-de-5001+ (shard A) and wv-de-5501+ (shard B), each with the full skill guidance plus the explicit "may not use Agent/Task tool" line.

Shard A was given the 9 previously-failed units explicitly and told not to repeat identical searches — this worked. All 9 resolved this pass by going to the supplier's own page (Versorgungsgebiet/Mitglieder pages, WWA Ansbach/Weilheim Kreis-level Trinkwasser registers) instead of re-crawling the VG/Amt umbrella site that had failed twice before. Worth remembering as a pattern: a twice-failed unit is not necessarily a genuine dead end — it may just need a different entry point than "go to the administrative unit's own site," which is the default and therefore the thing already tried twice. Shard A: 24/30 fully resolved, 5 partial, 1 fully unresolved (Auenland Südholstein, all 4 members — now a documented hard case, do not re-attempt with the same method a 4th time). See shard A's own journal entry just above for full detail (35 new companies, 12 unresolved markers).

Shard B (30 units, mostly Bayern/Niedersachsen/MV/Thüringen/Brandenburg singleton-adjacent 4-member units): 19/30 fully resolved, 8 partial, 3 fully unresolved (Oberviechtach, Gera-Aue, Kindelbrück — all hit after the shard's WebSearch quota (200) ran out mid-batch, so treat these as under-searched rather than genuinely absent; a fresh-quota pass may do better). 37 new companies minted (wv-de-5501-5538, one range gap from a self-caught duplicate). Reused 10 existing roster companies correctly instead of re-minting (Fernwasser Franken, Steinwaldgruppe, Müritz-Wasser-/Abwasserzweckverband, ZWA Eberswalde, etc.) — cross-shard reuse of shard A's own fresh mints (wv-de-5001/5004/5015) also worked, meaning the two shards' outputs were at least partially consistent with each other despite running in separate contexts.

Self-caught and fixed by shard B before reporting: minted wv-de-5526 for "ZWA Eberswalde" without noticing it already existed as wv-de-1122 — deleted the dup row, remapped its 4 links to the canonical ID. Also caught and fixed an AGS bug of its own (Steinkirchen unit's links used the wrong Landkreis's AGS prefix). Confirms the pattern noted in prior runs: shards that self-check before reporting catch their own mistakes reliably; this is now several runs in a row of that holding.

New host traps (shard B): fernwasser-franken.de re-confirmed as the known hard-ban host (shared-IP trap, documented in SKILL.md) — avoided via cache/government sources instead of direct fetches this time, so no ban incurred. kindelbrueck.de / walschleben.de are parked/for-sale domains, not live municipal sites — contributed to Kindelbrück staying unresolved. Several *.rhoen-saale.net LIS subdomains (Thüringen VG sites) DNS-fail entirely.

Merge/finish (done by me, orchestrator, after both shards reported):

• Domain-collision check across both new shard roster files + existing roster.jsonl before merging (per the skill's explicit last-step requirement): 0 duplicate company_ids, 5 collisions — all 5 the same known pre-existing set (sw-augsburg.de, wvv.de, zvo.com, vgrd.de, emkendorf.de). No new collisions from this batch.
• map_roster.mjs: 8859 total link rows, 8083 preresolved + 579 exact_norm + 61 land_scoped + 3 expanded_qualifier + 3 ambiguous + 126 unmatched. The 126 unmatched/3 ambiguous count matches the prior run's reported pre-existing leftover exactly — confirms this batch introduced no new unmatched names needing review.
• consolidate_roster.mjs: 1699 shard rows → 1685 distinct companies (+72 net vs. the 1613 going in — 35 shard A + 37 shard B, 0 lost to accidental collapse).
• coverage.mjs: population 82.81% → 83.28% (+0.47pp, +388k people). Municipalities claimed 7,559 → 7,768 (+209). Residual: 3,384 → 3,175 municipalities, 14.36M → 13.98M people.
• build_gv_layer.mjs (fresh queue for next run): multi-member units 564 → 512 (covering 1,287 municipalities, was 1,501), singletons 1,880 → 1,888. New top of queue: Auenland Südholstein (the one unit shard A couldn't crack), Oberviechtach, Gera-Aue, Kindelbrück, Gerolzhofen — i.e. this run's own leftovers plus one shard-A hard case are now what's next.
• Final domain-collision check across roster.jsonl + companies.jsonl (skill Finish step 2): same 5 known collisions, nothing new.

For next run: gemeindeverband-queue.csv/gemeindeverband-members.csv freshly rebuilt as of this run. Top of queue is now genuinely hard cases (Auenland Südholstein — 3 methods tried across 2 runs, still 0/4; Oberviechtach/Gera-Aue/Kindelbrück — under-searched due to WebSearch quota exhaustion, worth a real fresh-quota attempt before writing them off). 512 multi-member units / 1,287 municipalities still ahead of 1,888 singletons — multi-member-first ordering continues to hold. company_id max on disk after this run: 5538 (shard B's range); check roster.jsonl before minting next time. Tooling note for future batch sizing: both shards hit or came close to the ~200-call WebSearch session cap again (shard B exhausted it around unit 26 of 30) — this is now the third run in a row to hit this ceiling at 30 units/shard; consider either smaller shards or explicitly budgeting WebSearch calls per unit if throughput on the harder residual keeps degrading near the end of a shard.