de:wasserversorger-discover

Run complete. This scheduled wasserversorger-discover run worked phase 2b's next 60-unit batch (two synchronous shards, blocked in-turn per the skill's mandatory protocol), then merged, deduped 20 cross-shard duplicate mints, and ran the full coverage/queue pipeline.

Population coverage rose 84.39% → 85.31% (+770k people), municipalities claimed 7,956 → 8,152, residual dropped under 2,800 municipalities (12.28M people) for the first time. Roster grew to 1,822 companies; only the 5 known pre-existing domain collisions plus 2 new legitimate ones (heitersheim.de, ottobeuren.de — distinct entities sharing a municipal host) were found, none merged. Journal entry appended with full detail, host traps, and the queue state for the next run.

Scheduled run, clean throughout. Read SKILL.md and CLAUDE.md first, confirmed on-disk state matched the prior journal entries (1740 companies at 84.32% from the 03:00 discover run, bumped to 84.39% by the intervening 06:02 enrich run's new links) before touching anything. Re-ran coverage.mjs (confirmed 84.39%) and build_gv_layer.mjs fresh (457 multi-member units covering 1098 municipalities, 1889 singletons — close to the 03:00 run's post-batch count, as expected). Reused build_batch_input.mjs (now parameterised with a TAG arg so output filenames don't collide across runs — node build_batch_input.mjs 60 vg5) to build the top-60 batch from gemeindeverband-queue.csv + -members.csv into two 30-unit shard JSONs.

Batch: shard A = Gerolzhofen VGem down to Kellinghusen (30 units, includes the "hard six" flagged by the last run as already resistant to 1-2 VG-site re-crawls) plus the top of the 3-residual-member tier; shard B = GVV Teinachtal down to ~8.5k residual pop (30 units, mostly BW VVG/GVV top-ups and Bayern VGem units). Dispatched 2 synchronous subagents (run_in_background:false, blocked on both in the same turn), each with the mandatory "no Agent/Task tool" line, full skill method (Satzung-first, VG-membership-is-not-supply-evidence, self_supplied-is-a-real-answer, non-supplier filter, host traps, memory-safety rules) and shard-specific notes. Shard A was told explicitly not to re-crawl the "hard six" VG sites again and to try per-village Satzung/BGS-WAS search instead — this worked: Gerolzhofen and Krumbach (Schwaben) VGem both resolved as per-village self-supply via the alternate method, confirming they were a search-method problem, not a genuine absence.

Shard A: 26/30 units fully resolved, 2 partial (Kellinghusen reproduced the existing "4 villages have no central supply, private wells" finding; Bad Wildbad's Höfen an der Enz confirmed self-supply with no named operator), 2 low-confidence (Kropp-Stapelholm, Mittelholstein: 2-of-4 members resolved, 2 left honestly unresolved with notes). ~88 of 96 seeded residual members got a real company_id. Minted 39 companies (wv-de-7001–7039), reused 12 pre-existing ones after grep-checking first (wv-de-227, 224, 3494, 4528, 1507, 2203, 805, 2008, 2024, 980, 826, 6541).

Shard B: all 30 units resolved, all 90 seeded members plus 40 harvested/carve-out extras (130 link rows total). Minted 63 companies (wv-de-7501–7563). High-yield harvests beyond seed: Zweckverband Schwarzwaldwasserversorgung (+16 towns), Berglerner Gruppe (+3), Gruppenwasserwerke Bornheim/Walsheimer Gruppe (+5).

Duplicate-mint cleanup before merge (the pattern flagged by the 03:00 run recurred, worse): cross-checking both shards' new roster rows against roster.jsonl by normalised domain found 20 of the 102 newly-minted companies were duplicates of pre-existing roster entries (same name, same domain) — e.g. shard B independently re-minted wv-de-826 (Trinkwasserverband Stader Land, which shard A correctly reused the same run) as wv-de-7539, and both shards independently re-minted wv-de-4546 (Zweckverband Schwarzwaldwasserversorgung) as wv-de-7027 and wv-de-7501 respectively — a single entity minted three times across one batch. Wrote a small remap (20 new-id → canonical-id pairs), dropped the 20 duplicate roster rows, rewrote both links shards' company_id references (15 in shard A, 61 in shard B — the 61 count is high because Schwarzwaldwasserversorgung's harvested member list alone accounted for most of it), then re-verified zero id/domain collisions before touching roster.jsonl. Worth calling out as a process point for future scheduled runs: two geographically-scattered 30-unit shards drawn from the same top-of-queue batch (BY/NI/SH mixed with BW/RP/SN) hit this constantly — this is now the second run in a row (03:00 today: 23/34 duplicates; this run: 20/102) where the duplicate-catch is a large fraction of the mints, not a rare edge case. A future run might consider having each shard grep-check the other shard's output too (not just the base roster) before the orchestrator's final pass, though the current orchestrator-side catch is working and nothing has slipped through to production yet.

Merge (done by me, orchestrator):

• map_roster.mjs: 9359 total link rows (was 9121), 8517 preresolved + 624 exact_norm + 65 land_scoped + 3 expanded_qualifier + 3 ambiguous + 143 unmatched (+16 vs prior 127 — mostly Ortsteile/harvested names with no AGS by construction, not a regression).
• consolidate_roster.mjs: 1860 shard rows (38 shard-level dupes resolved last-shard-wins) → 1822 distinct companies (+82 net: 34 shard A + 48 shard B after the dedup above).
• coverage.mjs: population 84.39% → 85.31% (+0.92pp, +770k people). Municipalities claimed 7,956 → 8,152 (+196). Residual: 2,987 → 2,791 municipalities, 13.05M → 12.28M people — first time under 2,800 municipalities / 12.3M residual population.
• build_gv_layer.mjs (fresh for next run): multi-member units 457 → 394 (covering 907 municipalities, was 1098), singletons 1889 → 1884. New top of queue: Kellinghusen (still the genuine private-wells negative, expected to stay there), GVV Jestetten, Eichstätt (VGem), GVV Tannhausen, VVG der Stadt Stockach.
• Final domain-collision check (skill Finish step 2) across roster.jsonl + companies.jsonl: the same 5 known pre-existing collisions (sw-augsburg.de, wvv.de, zvo.com, vgrd.de, emkendorf.de) plus 2 new legitimate ones this run: heitersheim.de (Stadt Heitersheim's own Eigenbetrieb vs. the regional Zweckverband Gruppenwasserversorgung Sulzbachtal, sharing the municipal host — same "shared host, distinct entities" pattern as the existing 5, not a merge candidate) and ottobeuren.de (Markt Ottobeuren's own Eigenbetrieb vs. Gemeinde Hawangen's Wasserversorgungsanlage, betriebsgeführt durch the Woringer Gruppe — two municipalities' own operators coincidentally hosted on the market town's domain). Neither auto-merged, both kept as separate rows per the hard rule.

New host traps found: two same-named-but-unrelated Zweckverband pairs to keep separate in future — "Zweckverband Schwarzachgruppe" (Nürnberg area) vs. the unrelated Oberschwarzach/ Schweinfurt area water bodies; "Hohentengen am Hochrhein" (Waldshut) vs. the distinct Hohentengen in GVV Mengen/Sigmaringen (Bayern). Also two same-named Bavarian "Waldstetten" municipalities (Günzburg vs. Ostalbkreis, waldstetten.de vs markt-waldstetten.de) — easy to conflate on a quick search. rzv-glauchau.de had a connection-refused this run (worked around via WebSearch, not a retry loop). bodensee-wasserversorgung.de's broken TLS chain (previously flagged) recurred; relied on corroborated secondary sources rather than direct fetch. No pdftotext/poppler still — this is now flagged in at least 4 consecutive discovery runs plus 2 enrich runs; still worth a deliberate provisioning decision.

For next run: gemeindeverband-queue.csv/gemeindeverband-members.csv freshly rebuilt (394 multi-member units, 1884 singletons). company_id max on disk: 7563, but note the used range is now sparse (7001–7039 and 7501–7563 minus the 20 remapped-away ids) — check roster.jsonl before minting, several 7xxx sub-ranges are partially used. Kellinghusen's 4 villages remain a genuine, twice-confirmed negative (private wells, no central supply) — stop re-verifying it, it's settled. Residual under 2,800 municipalities / 12.3M people (14.7% of population) for the first time.