de:wasserversorger-discover

Everything's consistent. Final report:

Recovered an abandoned prior run's orphaned shards (34 companies/58 links stranded on disk, unmerged and unjournaled since 16:52), fixed one genuine duplicate mint found in them (ZWAV re-minted under a second company_id), then ran a clean phase-2a batch of 60 more singleton units (Kelheim → Schwarzenberg/Erzgeb.) via two synchronous subagents. Population coverage rose 73.5% → 75.79% (+2.29pp: +0.96pp from the rescued orphan work, +1.33pp from the fresh batch), roster now 1,232 companies / 7,455 links, phase-2a pool down to 379 units (4.63M people), no new domain collisions. Journal updated with a warning for future runs to always check directory mtimes against the last handoff, since that's what caught this run's orphaned work before it was lost or duplicated.

Started by listing the campaign directory instead of trusting the journal's last handoff, and found something the handoff didn't mention: roster.part-p2x.jsonl/roster-links.part-p2x.jsonl (24 companies/46 links) and roster.part-p2y.jsonl/roster-links.part-p2y.jsonl (10 companies/12 links), both timestamped 2026-08-26 16:48–16:52 — after the 13:00 run's own merge (roster.jsonl 15:20) and even after that run's own coverage/GV-layer recompute (16:36), but never folded into roster.jsonl/roster-links.jsonl and with no journal entry for whatever run produced them. This is exactly the failure pattern the skill's STOP banner describes: a run's synchronous shards finished and wrote real, well-evidenced work to disk, but the merge/coverage/journal sequence never ran and the attempt left no trace except the shard files themselves. Company IDs in the orphaned shards (wv-de-3742–3767 and wv-de-3792–3801, with a 3768–3791 gap presumably reserved by a third shard that died before writing anything) and the cities covered (continuing directly from the 13:00 run's handoff list — Oberasbach, EGF Frankenberg, Freilassing, Stadtwerke Rhein-Ahr, Sinzig, Marktredwitz, Gescher, Eutin, Oerlinghausen, Forst — all in the 15–18k population band) confirm this was a genuine continuation attempt at phase-2a, not stray test output.

Verified before trusting it, per the skill's own resumability rules ("check its shard file before assuming partial work exists"): every row in both orphaned shards carries source_url and confidence, no missing fields, no non-suppliers slipping past the Trinkwasser filter. Ran the mandatory domain-collision check across every roster.part-*.jsonl shard (not just the orphans) and found one genuine duplicate mint: wv-de-3796 "Zweckverband Wasser und Abwasser Vogtland (ZWAV)" on zwav.de, re-minted by the orphaned p2y shard from a Auerbach/Vogtl. seed, when the same company already existed as wv-de-3084 (minted 2026-08-24 from a Plauen seed, same domain, same 37-member Versorgungsgebiet). p2y's own notes show it never grepped the roster for "ZWAV"/"zwav.de" before minting — the same specific miss flagged in the 13:00 run's entry (grep fragments, not the full candidate name). Fixed by hand: repointed the Auerbach link to wv-de-3084 and dropped the duplicate wv-de-3796 company row, before any merge script ran. The other 3 collisions found (sw-augsburg.de, emkendorf.de, vgem-boos.de) are the same pre-existing accepted patterns noted in prior entries, not new. Recovering these two shards alone lifted population coverage from 73.5% to 74.46% (+0.96pp) and the pool from 481→439 units before any new research happened this run — that's real work that would otherwise have been silently redone or, worse, permanently lost once a later batch claimed the same cities under fresh IDs.

With the orphan recovered and the pool freshly recomputed (439 units / 5.6M people, top entry Kelheim 17,066 — nowhere near the stale "Schwalmstadt 18,420" the 13:00 run had reported, because that gap was exactly what the orphaned shards had already closed), ran a normal phase-2a batch of 60: top 60 singleton units by residual population, Kelheim down to Schwarzenberg/Erzgeb. (15,475). Split 2 SYNCHRONOUS subagents (p2z / p2aa, 30 cities each, run_in_background: false), both carrying the required "you may not use the Agent/Task tool... do not end your turn until output files exist" line verbatim, plus (new this run, added directly in response to the p2y miss above) an explicit instruction to grep the full candidate company name, not just fragments/domains, against every existing roster file before minting. Both shards finished cleanly with 0 unresolved municipalities; both self-reported catching pre-existing companies via the full-name grep before writing anything (p2z caught 5 incl. a same-turn overlap with p2aa's own fresh mint; p2aa caught 12), so the explicit full-name-grep instruction appears to have worked as intended — 0 duplicate-mint fixes needed on either shard this time, versus the orphaned run's 1. Non-overlapping company_id ranges (3802–3851 / 3852–3901); p2z used up to 3826 (25 new), p2aa used up to 3869 (18 new).

Ran the orchestrator's own post-merge domain-collision check (not the shards' self-reports) across all roster.part-*.jsonl before consolidate_roster.mjs: same 3 pre-existing accepted collisions, zero new ones. Ran the Finish sequence: map_roster.mjs (7,455 links total, 66 unmatched — mostly Ortsteil/administrative carve-outs with no AGS by construction, plus 3 genuine ambiguous name collisions, up from 1 last run, all correctly left unmatched rather than guessed) → consolidate_roster.mjs (1,232 distinct companies, up from 1,156 at the last journaled state — +43 net across the orphan recovery and this run's batch; same 6 pre-existing shard-level last-shard-wins duplicates as before, none new) → coverage.mjs → build_gv_layer.mjs.

Population coverage 73.5% → 75.79% (+2.29pp total this run: +0.96pp from orphan recovery, +1.33pp from the fresh batch). Municipalities claimed 6,594 → 6,738 (+144). Phase-2a pool remaining (freshly computed): 379 units / 4.63M people (next up: Schwalbach am Taunus 15,443, Bad Bramstedt 15,439, Bad Neustadt a.d.Saale 15,434, Michelstadt 15,396, Königslutter am Elm 15,395, Alsfeld 15,307, Gehrden 15,301, Raunheim 15,297, Füssen 15,287, Schwabmünchen 15,277).

For next run: continue phase-2a from Schwalbach am Taunus down, same method. Always list the campaign directory and check file mtimes against the last journal entry before trusting any handoff — that discipline is what caught this run's orphaned shards; a handoff number alone ("pool is X") can't tell you whether unmerged work is sitting on disk. Next free company_id starts at wv-de-3870 (this run's shards used up to 3869; nothing above that is taken; the old 3768–3791 gap from the dead third shard of the abandoned run is still free too and fine to reuse). Keep the explicit "you may not use the Agent/Task tool" line verbatim in every subagent prompt, and now also keep the "grep the full candidate company name, not fragments" line — both shards this run credited it with preventing duplicate mints outright rather than needing a self-fix afterward, which is a better outcome than the last several runs' pattern of catching duplicates only at the final collision-check step. resolve_singleton.mjs remains unfixed (TASKDIR/_tasks ENOENT) — still not blocking, unfixed across 7+ runs now.