de:wasserversorger-discover

Discovery pipeline ran clean but found no fresh work: four earlier runs today (03:00/08:00/13:00/~15:52) had already worked through every real singleton candidate and marked them same-day-unresolved, and the multi-member pool is on hold pending a human decision. The useful thing this run did was fix real queue noise — build_gv_layer.mjs was excluding zero-population "gemeindefreie Gebiete" (Bavarian forests/lakes, the German-Luxembourg border strip) from nothing, so they resurfaced every batch; I added a population guard, shrinking the residual queue from 261 to 71 units (251→62 real singletons) permanently. Coverage stays at 99.87% (unchanged, no roster edits this run); the pre-existing 28-domain collision backlog was re-verified but not fixed. Journal updated with details for the next run, which should get a clean batch once the day rolls over.

Ran the standard coverage.mjs → build_gv_layer.mjs → build_batch60.mjs sequence to pull the next singleton batch. Coverage unchanged from the prior run (99.87%, 10670/10943 municipalities, 273 residual / 106.5k people) — this run made no roster/link changes, see below for why.

Applied the fix flagged (not applied) by the 13:52 run today: build_gv_layer.mjs now excludes zero-population satzart-60 units from the residual queue. batch60-input.json for this run's top-60 was 60/60 uninhabited gemeindefreies Gebiet/Gutsbezirk/Forst/Wald/See units (Bavarian state forests and lakes, plus the Gemeinsames deutsch-luxemburgisches Hoheitsgebiet) — verified zero population directly against ags-city-map.csv for all 60, not just spot-checked. These can never resolve to a real supplier and were resurfacing every batch as pure queue noise (matches the cluster flagged in the last entry: 189 of the 251 singleton-pool units were this pattern). Added a pop.get(g.ags) > 0 guard alongside the existing claimed check in the residual-counting loop (build_gv_layer.mjs:62) — same principle already applied to Ortsteile/non-municipal members in coverage.mjs's denominator. Rebuilding the queue after the fix: 261 → 71 units with residual members (251 → 62 singletons, multi-member 10→9/22→20 municipalities — one multi-member unit had a zero-pop member too). This is a permanent fix, not a per-run workaround: it changes what future build_batch60.mjs runs ever see, not just this run's output.

After the fix, build_batch60.mjs returned 0 units for this run — not a bug. Checked directly: all 62 real singleton candidates in the cleaned queue already carry a checked_at: 2026-09-01 unresolved row in roster-links.jsonl. Four batches already ran today before this one (batch60 shard files at 03:00, 08:00, 13:00, and ~15:52 — 796 checked_at:2026-09-01 rows total), and this chat-triggered run landed after all of them, so the same-day-exclusion in build_batch60.mjs correctly has nothing left to hand out until the date rolls over. The 9-unit/20-municipality multi-member pool remains on hold pending the outstanding human decision (unchanged, still untouched this run) and build_batch60.mjs deliberately excludes it regardless of date.

No subagents were dispatched — there was no batch to give them. Ran the domain-collision check for hygiene since the finish pipeline says to: official_domain-only method (per the 13:52 run's fix) found 28 collisions against a roster.jsonl unchanged since that run, vs the 30 it reported — a discrepancy worth checking next time (possibly the checked method still differs subtly) but not caused by this run, since no roster/link data was touched. Full list still: eschachwasserversorgung.de, zv-binatal.de, vg-wackersdorf.de, weitnau.de, schlicht-gruppe.de, wzvkoen-mitte.de, sw-augsburg.de, rottenbuch.de, pleystein.de, vordereifel.de, auenland-suedholstein.de, entega.ag, wbv-brokstedt.de, stadtwerke-burglengenfeld.de, amt-leezen.de (3-way), heubergwasserversorgung.de, wvv.de, zvo.com, eckental.de, vgrd.de, nog-neunburg.de, emkendorf.de (3-way), heitersheim.de, ottobeuren.de, oberbergkirchen.de (3-way), vg-rohrbach.de, vg-schoensee.de (3-way), amt-nordstormarn.de — same standing backlog as before, unresolved this run (needs the consolidation pass the last several entries have deferred).

For next run: once the date rolls over, build_batch60.mjs will draw from the now-clean 62-unit singleton pool (no forest/lake noise) plus whatever the next coverage.mjs/ build_gv_layer.mjs pass adds — should be a normal 60-unit batch again, all real candidates. Standing backlog unchanged: 28-30 domain collisions (count method itself needs re-checking), the 6 duplicate-mint name pairs, St. Peter/St. Märgen AGS-swap, wv-de-10532 hq_ags mismatch, and the 9-unit multi-member pool awaiting the human decision. _tasks/netzbetreiber-contact/german-water/ still absent from this checkout.