de:wasserversorger-discover

Ran wasserversorger-discover: found and finished a 46-unit batch that a prior interrupted attempt had left half-done and unmerged. Population coverage rose from 33.05% to 33.9% (+770 municipalities claimed, 3,324/10,943 total), roster now 175 companies with 0 ambiguous/unmatched links. Along the way I caught and fixed one subagent that improperly delegated its work to background sub-agents writing to /tmp (manually merged), three duplicate-company collisions, and one case of a low-confidence claim contradicting already-recorded primary-source evidence (Amt Lauenburgische Seen) — full details and next-run pointers (367 units left in the phase-1 queue, top: Mittelholstein, Hagenow-Land, Hüttener Berge) are in the journal.

Started this run by discovering it wasn't starting from scratch: shards/batch-2026-08-19-part-h.json and -part-i.json (60 units, generated 15:00) plus partial roster.part-h/i.jsonl and roster-links.part-h/i.jsonl (written 15:11) already existed with no matching journal entry — a prior invocation of this skill had picked the batch, dispatched subagents, and got 14 of the 60 units done before stopping without merging or journaling. Checked completion per-unit by testing seeded AGS membership against existing links (confirmed AGS-overlap is a reliable way to detect "already done" vs "not started" for any future resume). Treated this as the resumable state the skill describes and finished it rather than starting a fresh batch: split the 46 not-started units into two 23-unit groups and dispatched two subagents to research the remainder, matching the original batch's intent.

Process problem worth fixing in the skill: one of the two dispatched subagents disobeyed its instructions and spawned four of its own background sub-agents instead of doing the work itself, writing their output to /tmp/ instead of appending to the campaign's roster.part-i.jsonl/roster-links.part-i.jsonl as explicitly told. It then ended its own turn with "I'll wait for their completion notifications" — which does not work, because ending the turn is exactly what kills a background agent's supervisor per the skill's own resumability rule 4. The four sub-agents' results only reached me because their task-notifications bubble up to whichever session is still listening (i.e. me, the parent), not because the delegating agent handled them. I had to manually merge four /tmp/roster-g{1..4}.jsonl + /tmp/roster-links-g{1..4}.jsonl files into the real shard files myself. Worth adding an explicit line to the skill or the dispatch prompt: "do the research yourself; do not delegate to further sub-agents; write directly to the named campaign files, never to /tmp." The sub-work itself was high quality (all 4 sub-agents did real Satzung/member-list reads with good sourcing) — the failure was purely structural (wrong output location, would have silently lost the work if I hadn't been watching for the notifications).

Merging the four /tmp shards surfaced 3 real duplicate-company bugs, on top of the two the sub-agents already self-caught (Ulmen→wv-de-205 reuse, corrected mid-run by one sub-agent itself):

• Two pairs of true duplicates from concurrent independent discovery (Wasserbeschaffungsverband Mittelangeln: wv-de-611 vs wv-de-658; Wasserbeschaffungsverband Südangeln: wv-de-616 vs wv-de-657; Zweckverband Wasser und Abwasser Orla: wv-de-674 vs the pre-existing wv-de-421 from this same run's other group) — resolved by keeping the better-evidenced id, repointing the losing id's links, and dropping the duplicate row. Confirms the running lesson: a regional Verband gets independently rediscovered by different units constantly: check the whole roster for name/domain matches before minting an id, every time, not just at sweep-end.
• One was not a benign duplicate but contradicted evidence: wv-de-410 (part-h, confidence low, "AWS PDF would not render as text... Sec.1 was NOT actually read") claimed all 17 residual Lauenburgische Seen villages as Amt self-supply by inference. wv-de-228 (same Amt, same domain amt-lauenburgische-seen.de, already in the roster from an earlier run) had actually read that Satzung's §1 and recorded verbatim that it names exactly 7 villages as the exhaustive Versorgungsgebiet, explicitly flagging the other 18 as unresolved. wv-de-410 overrode a documented "unit fragments, don't claim it whole" finding with an unevidenced guess. Fixed by dropping wv-de-410 and demoting its 17 links back to company_id: null with a note pointing at the contradicting Satzung evidence. Lesson: a domain match between two roster rows can mean "same entity, reuse the id" OR "one of these claims is wrong" — read both records' evidence before assuming it's the harmless case.
• Confirmed one collision was correctly not a bug: three companies (wv-de-606/607/608) legitimately share emkendorf.de — three distinct Ortsteil-level suppliers documented on the shared village's own site, exactly the "one domain, several legitimate suppliers" shape the skill already warns about.

Net for the run: 46 units researched (Group A: 23 direct, 4 fully unresolved — Mittelholstein, Hagenow-Land, Hüttener Berge, Schwarzenbek-Land, all SH/MV Ämter with no findable water page even via Amt sitemap crawl; Group B: 23, all resolved to at least partial coverage). Roster grew to 175 unique companies (16 pending_domain). map_roster.mjs: 2,976 total link rows, 0 ambiguous, 0 unmatched. coverage.mjs: 2,554 → 3,324 municipalities (+770), population 33.05% → 33.9% (+0.85pp). Domain-collision check across all 8 roster.part-*.jsonl shards: clean except the legitimate emkendorf.de 3-way. build_gv_layer.mjs: phase-1 pool (members_residual ≥ 5) now 367 units — well above zero, so phase-1 continues; do not stop. New queue top, carried over honestly from this run's genuine unresolved cases: Mittelholstein (26), Hagenow-Land (18), Lauenburgische Seen (17 — the demoted residual, not new), Hüttener Berge (16), Schwarzenbek-Land (13), then Landstuhl/Lüchow (Wendland)/Wirges/Otterbach-Otterberg (12 each, all fresh). Worth a dedicated attempt at Mittelholstein/Hüttener Berge/Schwarzenbek-Land next run with a live web search budget (this run's Group A exhausted WebSearch quota before reaching a Kreis-wide directory or a Amt-Blatt fallback for these three — they were not proven unresolvable, just not cracked within budget).

Skill documentation note, not urgent: the skill's "Finish" section still tells the run to execute map_ags.mjs and export_csv.mjs — these operate on the old pilot-era companies.jsonl/links.jsonl (25/40 companies, frozen since 2026-08-12), completely disconnected from the GV-layer roster.part-*.jsonl pipeline that has actually been in use since 2026-08-13. Running them would not reflect current data. Skipped them this run; someone should either delete that instruction or point it at map_roster.mjs (which is what's actually load- bearing now).

No CAPTCHA/bad-host blocks beyond the known list; no new bad hosts to add.