feat(wasserfoerderung): Förderstrecken planen — Rechner, Tab, PDF (#150, Plan A)

[DeepDiver1975]

Zusammenfassung

Plan A von #150: neuer WASSERFÖRDERUNG-Tab im Lagebuch, der Förderstrecken-Leitungen (Ltg 1, Ltg 2, …) rein offline plant. Ein hydraulischer Rechner (FörderstreckePlanner) leitet aus Länge + Höhenunterschied die B-Schlauch- und Verstärkerpumpen-Positionen ab; die Zahlen sind unveränderlich gespeichert, damit PDF, Sync und alle Clients immer dasselbe zeigen.

• Domain: FörderstreckeConfig / FörderstreckePlanner mit der B-800-Verlusttabelle (0,1 … 2,25 bar/100 m), Steigung 0,1 bar/m, flache Teilstrecke 620 m, 3 % Reserveschlauch, 1 Reservepumpe je 4 Verstärkerpumpen (Speisepumpe ausgenommen, wie abgestimmt).
• Persistenz: Migration v18 (wass_leitungen), voller Round-Trip inkl. Pumpenpositionen (JSON).
• Sync: add/removeWasserfoerderungLeitung-Kommandos, Snapshot-DTO, Applier; die Leitungsnummer und alle abgeleiteten Werte berechnet der Host.
• UI: 12. Tab „WASSERFÖRDERUNG“ mit Eingabedock und DataGrid; Abbruch beim Kappen der Steigung wird als Fehlermeldung angezeigt statt App-Crash.
• PDF: neuer Abschnitt „Wasserförderung“ (Leitung / Übergabestelle / Ansprechpartner / B-Längen / Länge / Höhenunterschied / Verstärkerpumpen / Reservepumpen).

Tests

826 Tests grün (Domain 232, AppLogic 294, Sync 60, Sync.Hosting 33, Persistence 91, Documents 25, Acceptance 89, App 2).

Screenshots

Vorher (leerer Tab):

Nachher (zwei geplante Leitungen, 2000 m/100 m und 400 m/0 m):

Planungshinweis: B-800, B-Schlauch 20 m, 8 bar Speisedruck, 1,5 bar Pumpeneingang (Config, anpassbar).

[DeepDiver1975]

Code review

Note: this branch has a real merge conflict against main (gh pr update-branch --rebase failed with RebaseConflictError), so it was reviewed at its current head without rebasing.

This is a large diff, so review ran across correctness, cleanup, and convention angles. Found 10 issues; 5 are fixed and pushed (5df4d8b), 5 are left as observations.

Fixed:

1. New Leitungen were numbered _wasserfoerderung.Count + 1, so removing a non-last Leitung then adding a new one collides with a surviving one's number (both display as e.g. "Ltg 2"). Now numbered by smallest free slot, mirroring the existing NextFreeScbaTruppNumber pattern.

lagebuch/src/LageBuch.Domain/Incident.cs

Lines 874 to 908 in 5df4d8b

	/// <summary>
	/// Plans and records one Förderstrecke-Leitung (#150). The pump/pressure figures are computed
	/// by <see cref="FörderstreckePlanner"/> at creation and stored on the Leitung — the PDF and
	/// remote clients never recompute. Silently planned (no ETB line), like tasks.
	/// </summary>
	public WasserfoerderungLeitung AddWasserfoerderungLeitung(
	string? uebergabestelle, string? ansprechpartner, double lengthM, double riseM)
	{
	EnsureOpen();
	var leitung = WasserfoerderungLeitung.Create(
	number: NextFreeWasserfoerderungLeitungNumber(),
	uebergabestelle: uebergabestelle,
	ansprechpartner: ansprechpartner,
	lengthM: lengthM,
	riseM: riseM);
	_wasserfoerderung.Add(leitung);
	return leitung;
	}
	/// <summary>
	/// Plan B (#150 phase 2): plans and records a Leitung from a route drawn on the map. The
	/// elevation profile is sampled by the caller (before this runs) so every replica stores the
	/// same computed numbers regardless of local DEM-file differences.
	/// </summary>
	public WasserfoerderungLeitung AddWasserfoerderungLeitungFromRoute(
	string? uebergabestelle,
	string? ansprechpartner,
	IReadOnlyList<GeoPoint> routePoints,
	IReadOnlyList<ElevationProfileSample> profile)
	{
	EnsureOpen();
	var leitung = WasserfoerderungLeitung.CreateFromRoute(
	number: NextFreeWasserfoerderungLeitungNumber(),
	uebergabestelle: uebergabestelle,

2. FörderstreckePlanner.PlanFromProfile threw "Die Steigung ist zu stark" for any route shorter than one 20m hose, even perfectly flat, because the "finish here" shortcut required the remaining distance to be at least one hose length before even checking the cost budget. Nothing upstream enforces a minimum length. Fixed to check budget regardless of remaining distance.

lagebuch/src/LageBuch.Domain/Wasserfoerderung/FörderstreckePlanner.cs

Lines 84 to 106 in 5df4d8b

	var positions = new List<double> { 0 };
	var pos = 0.0;
	while (pos < lengthM)
	{
	// If the rest of the route fits one leg's budget, finish here -- regardless of whether
	// what's left happens to be a whole number of hose lengths (a route shorter than one
	// hose, e.g. a trivial flat connection, is a valid input: CanAddLeitung only requires
	// length > 0).
	if (Cost(pos, lengthM) <= budgetPerLeg)
	{
	pos = lengthM;
	break;
	}
	var reach = 0.0;
	while (pos + reach + hoseLen <= lengthM && Cost(pos, pos + reach + hoseLen) <= budgetPerLeg)
	{
	reach += hoseLen;
	}
	if (reach == 0)
	{

3. RiseDisplay (grid) and the PDF's Wasserfoerderung table both rendered a downhill (negative) elevation change as "—", as if nothing were recorded — ElevationRiseMeters is a real, valid negative value for a descending route (already exercised by FörderstreckePlannerElevationTests). Now always shown.

lagebuch/src/LageBuch.AppLogic/ViewModels/WasserfoerderungViewModel.cs

Line 287 in 5df4d8b

RiseDisplay = Formatting.Meters(leitung.ElevationRiseMeters);

4. RegionPackCatalogService.GetAvailableRegionsAsync's own doc comment promises it degrades to an empty list rather than surfacing any error, but only caught HttpRequestException — an HttpClient timeout throws TaskCanceledException instead, which escaped uncaught into a fire-and-forget command's unobserved task fault, leaving the region dropdown silently empty/frozen. Now caught too (the caller's own cancellation still propagates).

lagebuch/src/LageBuch.AppLogic/Services/RegionPackCatalogService.cs

Lines 13 to 27 in 5df4d8b

	{
	public async Task<IReadOnlyList<RegionPackInfo>> GetAvailableRegionsAsync(CancellationToken ct = default)
	{
	try
	{
	var json = await httpClient.GetStringAsync(new Uri(manifestUrl), ct);
	return RegionPackCatalogJson.Parse(json);
	}
	catch (HttpRequestException)
	{
	return Array.Empty<RegionPackInfo>();
	}
	catch (OperationCanceledException) when (!ct.IsCancellationRequested)
	{
	// HttpClient's own request timeout throws this (TaskCanceledException), distinct from

5. MasterDataSet gained a top-level Einsatzgebiet field, but docs/master-data.example.json wasn't updated in this PR, as this repo's own AGENTS.md requires whenever that happens.

https://github.com/CodeForFire/lagebuch/blob/5df4d8bfe0c2a8242d93d477f7695f6baceb0f58/docs/master-data.example.json

Left as observations (design calls / larger scope, not applied):

6. EinsatzgebietSection.DownloadSelectedRegion has no try/catch around DownloadAndInstallAsync, and nothing binds to the command's fault state — a 404/corrupt zip/invalid slug becomes an unobserved task fault with the progress bar stuck and no way for the operator to know or retry short of restarting. Worth a UI-visible error/status treatment, similar to CatalogStatus.

7. (PLAUSIBLE, not confirmed) PopulateSections() rebuilds _einsatzgebiet as a fresh EinsatzgebietSection on every Load/Save/Discard, potentially orphaning an in-flight download on the previous instance if a save happens mid-download.

8. BuildRouteOverviewPngById() rebuilds the Wasserfoerderung map/tile source from scratch during PDF export instead of reusing the workspace's already-built Wasserfoerderung.TileSource — wasted I/O on every export.

9. WasserfoerderungLeitung.Create/CreateFromRoute are near-duplicate factories (~20 of ~30 lines identical) — a third planning mode would need a third copy-paste with no compiler check keeping them in sync.

10. MbTilesFileSource opens a brand-new SqliteConnection per tile call with no caching, and MapDrawing.DrawTiles() re-fetches/re-decodes every visible tile on every render tick (wired to pan/zoom) — likely to be visibly laggy with a real region pack loaded.

🤖 Generated with Claude Code