# Review PR #263 — ESt3 distributor: spring preload, minimum stage, releaser and AL2 timing; AI predicts the new characteristic

Autor: @pwarszawski · base: `master` (zbudowany na #187) · przyrost ponad #187: 4 pliki, ~+60/−15
https://github.com/MaSzyna-EU07/maszyna/pull/263

**Werdykt: Approve merytorycznie; przed merge — testy golden / CI i decyzja o kolejności z #264**

> Recenzja dotyczy tylko przyrostu ponad #187 (interdiff policzony lokalnie).

## Podsumowanie
Model rozrządu `TNESt3`:
- wstępny nacisk sprężyn 0.21 bar zamiast 0.05 (`dPSprezyny`), `BVM` liczone z tego samego offsetu → pełne hamowanie dalej daje `MaxBP`,
- minimalny stopień 0.28 bar (`pStopnia`), pełne odluźnienie gdy cel = 0,
- odluźniacz automatyczny: ZS 15 l z 5.0 do 0.4 bar w ~23 s (było 5.6 s),
- `dTN` 1.65 → 1.62 (literówka),
- AL2: komora impulsowa 1 l, dysze cylindra przeskalowane wg tablicy 3-9.

AI: `TNESt3::GetBrakeRatio()` zwraca rzeczywisty udział ciśnienia w cylindrze dla danego spadku w PG, więc tablice hamowania AI odpowiadają charakterystyce zaworu.

## Co sprawdziłem
- `GetBrakeRatio(1.0) == 1.0`: `spadek = MaxBP/BVM + 0.21 = HPP − LPP`, `cel = (spadek − 0.21)·BVM = MaxBP`. ✔ Dzięki temu wywołania `BrakeForceR(1.0, …)` w `DynObj.cpp` i `Train.cpp` (wskaźniki siły hamowania) się nie zmieniają.
- Nowe progi w `CheckState()` to stare progi przeskalowane do domeny ciśnienia w cylindrze (`0.01 → 0.01·BVM`) — równoważne poza nowym minimalnym stopniem. ✔
- Zmiana fizyki dotyczy każdego pojazdu z ESt3 bez zmian w `.fiz` — opis PR mówi to wprost, zgodnie z `CLAUDE.md`. ✔

## Uwagi
1. **Testy golden / CI.** Na `master` są ślady golden (`tests/unit/data/golden/consist/`, `test_consist.cpp` loguje m.in. `BrakeForceR0.25`), a także `test_brakes.cpp` / `test_brake_cycle.cpp` z pojazdami ESt3 (`401W`, `430W`…). PR nie zmienia żadnego testu, a GitHub pokazuje stan `unstable`. Proszę po rebase na master sprawdzić, które testy się zmieniły, i zaktualizować golden świadomie (z opisem w PR, co się zmieniło i dlaczego).
2. **Testy akceptacyjne jako unit testy.** W opisie jest „valve test bench that runs the acceptance procedures” (77 → 40 wyników poza tolerancją). Bardzo proszę dołożyć choć część tych prób (stopień minimalny — próby 12/22, odluźniacz — próba 27, czasy AL2 — tablica 3-9) do `tests/unit`. To najlepsza ochrona tej poprawki przed regresją.
3. **Kolejność merge.** Opis przyznaje, że sam #263 pogarsza precyzję zatrzymań (403 → 363 w oknie 8–15 m) i daje problem z ciężkim G na śliskim spadku, który naprawia dopiero #264. Proponuję merge #263 i #264 razem (albo w jednym oknie wydania), a nie #263 osobno przed 26.11.
4. **Wolniejszy odluźniacz a reszta AI.** 4× wolniejsze opróżnianie ZS wpływa też na reguły `control_releaser()` przy łączeniu/rozłączaniu i na #265 (ruszanie pod górę z odluźniaczem). Czy scenariusze manewrowe (sprzęganie/odczepianie, odhamowanie składu po połączeniu) zostały sprawdzone? Gracz używający odluźniacza na wagonach też odczuje różnicę — warto to wspomnieć w changelogu.
5. **Kod:**
   - `static double const dPSprezyny/pStopnia` → `constexpr double` (wytyczne GCC/Sonar w `CLAUDE.md`) i najlepiej w anonimowym namespace.
   - Współczynniki AL2 `0.914 / 0.885 / 0.82 / 0.8` — dopisać w komentarzu, z jakich czasów tablicy 3-9 wynikają (albo jak je wyliczono), żeby dało się je odtworzyć.
   - `0.0049` w odluźniaczu — podobnie, nazwana stała z odniesieniem do próby 27.
   - W `BrakeForceR()` `GetBrakeRatio` jest stosowane przed korektą ED (`dbrake_automatic`), rapidem i `DMU -0.3`. Wydaje się poprawne, ale proszę potwierdzić, że kolejność jest zamierzona.
6. **Konsultacja z youBy** — warto, żeby youBy zostawił w PR formalne approve części fizycznej; to jego model.