2.4b3: 進捗トランスポートの統合＋実行時制約のテスト昇格（B-006 の構造的後始末）

[kumahide]

B-006（バッチのプログレスバーが実態を表さず GUI ごと固まる）の構造的な後始末。b2 で症状は直したが、その根本原因＝「単一とバッチで進捗実装が2本あること」と「実行時制約がテストで守られていないこと」が残っていた。

③④ 進捗トランスポートの統合（本丸）

単一実行とバッチが各々で持っていた「キュー＋after ポーリング」を views/progress.py の ProgressPump へ括り出した。

狙いは重複の削減ではなくライフサイクルの統一。従来バッチのポーラは __init__ で1回起動して永久に回り、単一のポーラは実行ごとに起動・停止していた。この非対称そのものが b2 の停止バグ（停止後に残った1回のポーリングが完了表示を上書きする）を生んだ。両者とも「実行のあいだだけ回す」に揃えたので、同種のバグが構造的に成立しなくなる。

2者の差はパラメータ2つに閉じた：

• 単一 latest_only=True — バーとラベルは最新の状態だけが意味を持つ。取得は1サンプルごとに push されるので全件描くと Tcl 呼び出しが取得時間そのものを支配する（B-006 で実測30倍差）
• バッチ latest_only=False — done/complete が結果を運ぶので1件も落とせない

副次的に見つかった欠陥：実行中にウィンドウを閉じると破棄済みウィジェットへ after し続けて invalid command name になる経路があった（マップ破棄と同じクラス）。閉じる側で stop し、部品側も after 失敗時は静かに止まるようにした。

パイプライン本体は統合しない。出口が対話グラフと確定成果物で異なる＝2.3 で確定した設計思想そのものが違うため（共有シナリオランナーは 2.5 の scenario.py）。

①② プリフェッチ相・地形キャッシュの設計判断

• 地形キャッシュ＝バッチにも効かせる。単一は fetch_elevations_cached を使うのにバッチだけ素通りしており、同一バッチの再実行で毎回 DEM を取り直していた（偶然の非対称）
• プリフェッチ相＝設けない。総取得量は変わらず得られるのは進捗の見え方だけで、UI と停止処理が一相増えるのは軽量哲学に反する

開発環境 C-b3（B-006 が露呈した死角）

環境は「構造の正しさ」に強く「実行時の振る舞い」に盲目、という診断への対処。

• 未強制の「禁止」コメント棚卸し：禁止/必須/してはいけない 系を全件判定し、未強制だった4件をガード化。全件ミューテーション検証済み（制約を壊すと実際に落ちる）
  • レポート描画の非並列（rcParams がプロセス共有）／DEM ロック保持中のネットワーク取得禁止／マップ破棄経路の集約（AST 静的検査）／スレッド生成規約（ThreadPoolExecutor 不使用・daemon=True、従来メモリにしか無くコードに痕跡ゼロだった）
  • 判定は二択でなく三択だと判明：coords.py の「必ず DD 正規化」は SimParams が DMS を ValueError で弾く＝構造的に強制済みでテスト不要
• phase 境界ログ：最も時間を食う区間（per-path 描画・サマリ地図）にログ行が1つも無く、B-006 で所要時間が最後まで測れなかった
• README のテスト件数表記を削除：実数と70件ずれていた。ガードを足すのではなく主張そのものを撤去してドリフト面を消した
• フル監査チェックリストに**面10「実行時の振る舞い」**を本文化

検証

• 全テスト通過（518件）・カバレッジ 95.67%（floor 85）・ruff・pyright 0・bandit・ローカル LLM レビュー NO ISSUES
• 新規ガードはすべて「壊すと落ちる」ことを確認済み
• 実機βは未実施＝進捗表示の見え方とバッチ再実行のキャッシュ効きは要確認

🤖 Generated with Claude Code