de:wasserversorger-discover

Discovery batch complete: population coverage rose from 85.33% to 85.74% (+341k people), municipalities claimed 8,155 → 8,295, residual now under 12M people for the first time. Roster grew from 1,822 to 1,865 companies via two synchronous 30-unit shards (phase 2b VG grind), with 2 new duplicate-mints caught and fixed pre-merge (ZkWAL, Zweckverband Grimmen) before the final domain-collision check came back clean (still just the same 9 known, already-explained collisions). Journal updated with full details and next-run pointers.

Scheduled run, clean throughout. Read CLAUDE.md and this journal first, confirmed on-disk state matched the prior journal entries (1822 companies at 85.33%, from the 08:00 discover run plus the 10:30 enrich run's small link additions) before touching anything. Re-ran coverage.mjs (confirmed 85.33%) and build_gv_layer.mjs fresh (394 multi-member units covering 907 municipalities, 1881 singletons — matches prior report). Built the top-60 batch with build_batch_input.mjs 60 vg6 into two 30-unit shards (shard A: Kellinghusen down to Reichenbach/O.L., 229k residual pop; shard B: Pförring VGem down to Theres VGem, 195k residual pop; both mixed across BY/BW/SH/RP/MV/TH/SN/NI/BB).

Dispatched 2 synchronous subagents (run_in_background: false, both in one message, blocked on both in this turn), each with the mandatory "no Agent/Task tool" line and full inlined method (Satzung-first, VG-membership-is-not-supply-evidence, self_supplied/no-central-supply as valid answers, non-supplier filter, host traps, memory-safety, grep-before-minting, reserved ID ranges 7601–7649/7701–7749 to keep writers from colliding). Shard A was told explicitly to skip Kellinghusen (settled negative, twice-confirmed private wells) rather than re-research it, which it did correctly, spending zero fetches there.

Shard A: 29/30 units researched (Kellinghusen skipped as instructed). ~20 fully resolved, ~9 partial. 66/91 seeded links resolved (13 genuine self_supplied, 8 true unknowns e.g. Biberach im Kinzigtal, Kellmünz a.d.Iller). Minted 17 companies (wv-de-7601–7617, one later remapped, see below), reused 15 pre-existing ones after grep-checking first. Flagged two existing rows whose supply_area_status looks stale given this pass's new findings (wv-de-3947 Grafing, wv-de-3101 Görlitz — not edited, per append-only). New host traps: wasserzweckverband-jst.de is a wrong-but-live domain for an unrelated Zweckverband near Beilngries, not Jestetten's; generic "Biberach" search collided with the unrelated Landkreis Biberach entity; tw-ostritz-reichenbach.de has a self-signed cert (WebFetch blocked, relied on search synthesis, confidence downgraded to medium).

Shard B: all 30 units researched. ~19 fully resolved, ~9 partial, 1 mostly unresolved (Eiderkanal: 2 of 3 members ungrounded — Bovenau fragmented private suppliers, Haßmoor no operator found). 74/90 seeded links resolved, 16 explicit company_id: null. Minted 28 companies (wv-de-7701–7728, one later remapped, see below), reused 9 pre-existing ones. New host traps: xn--mabach-cta.de (Maßbach's IDN domain) has a TLS cert mismatch pointing to an unrelated tourism host; several PDF Satzungen (Pförring, lwbv.de) returned corrupted/binary text even via direct fetch, noted rather than silently dropped. Multiple VGem/VG-branded self-supply cases correctly recorded as self_supplied rather than invented Stadtwerke names (Syrgenstein, VG Nassenfels).

Duplicate-mint cleanup before merge (mandatory cross-shard + full-roster domain-collision check, per the skill's standing instruction — this is what it's for): found 2 new duplicate mints, both a shard independently re-minting a company that already existed in roster.jsonl under a different ID, same domain: wv-de-7607 (shard A's "ZkWAL (Ludwigslust)") = pre-existing wv-de-670 (same zkwal.de domain, same legal entity) — shard A's grep apparently missed it or the check didn't fire; and wv-de-7705 (shard B's "Zweckverband Wasser/Abwasser Grimmen") = pre-existing wv-de-842 (same zwa-grimmen.de domain, identical name). Both caught by re-running the collision check across roster.jsonl + both new shard files together, before consolidate_roster.mjs, exactly as the skill's banner demands. Fixed by remapping the 6 link rows referencing the two duplicate IDs to the canonical existing IDs (sed on both roster-links.part-vg6-* files) and dropping the 2 duplicate roster rows from the shard files before merging — the new members those rows carried (Blievenstorf/Brenz/Neustadt-Glewe for ZkWAL; Elmenhorst/Sundhagen/Wittenhagen for Grimmen) are genuinely new information and were preserved under the correct canonical company_id. Re-ran the collision check after the fix: clean, zero new collisions introduced.

Merge (done by me, orchestrator):

• map_roster.mjs: 9569 total link rows (was 9388), 8698 preresolved + 645 exact_norm + 67 land_scoped + 3 expanded_qualifier + 3 ambiguous + 149 unmatched (+6 vs prior 143 — new harvested/Ortsteil names with no AGS by construction, not a regression).
• consolidate_roster.mjs: 1915 shard rows (50 shard-level dupes resolved last-shard-wins) → 1865 distinct companies (+43 net: 16 shard A + 27 shard B, after excluding the 2 remapped duplicates).
• coverage.mjs: population 85.33% → 85.74% (+0.41pp, +341k people). Municipalities claimed 8,155 → 8,295 (+140). Residual: 2,788 → 2,648 municipalities, 12.26M → 11.92M people — first time under 12M residual population.
• build_gv_layer.mjs (fresh for next run): multi-member units 394 → 347 (covering 760 municipalities, was 907), singletons 1881 → 1888 (units with only 1 residual member left after this batch's partial resolutions reclassify from multi-member to singleton in the queue, which is why singletons rose even though total units-with-residual-members fell 2275 → 2235). New top of queue: Kellinghusen (still the genuine settled negative, stop re-verifying), VVG der Stadt Zell am Harmersbach, Altenstadt (VGem), Windach (VGem), Uehlfeld (VGem).
• Final domain-collision check across roster.jsonl: still exactly the same 9 known collisions (sw-augsburg.de, wvv.de, zvo.com, vgrd.de, emkendorf.de, heitersheim.de, ottobeuren.de, heubergwasserversorgung.de wv-de-2008/7554, nog-neunburg.de wv-de-6003/7559) — the last two are the already-carried duplicate-mint pairs from the 10:30 enrich run, not new. Zero new collisions from this batch after the ZkWAL/Grimmen fix above.

For next run: gemeindeverband-queue.csv/gemeindeverband-members.csv freshly rebuilt (347 multi-member units, 1888 singletons). company_id max on disk now 7728, but sparse — 7601–7616 and 7701–7727 used (7607, 7705 remapped away), check roster.jsonl before minting in that range. Residual under 12M people (14.26% of population) for the first time. Open duplicate-mint/collision list (carried, not merged, per hard rule) is unchanged at seven pairs from before this run — this run added zero to that pile, unlike the last two runs — worth noting the cross-shard pre-merge check is holding up as the right process fix. The still-overdue human consolidation pass (scripted domain-collision + near-identical-name sweep across the full 1865-row roster) remains recommended.