# vehicles-loader-progress-deploy

## Goal

Доставить `@stostayer/vehicles-loader` **0.4.0** (прогресс-логирование) на прод клиента и
верифицировать, что `journalctl` во время боевого `sync` показывает движение, а не ~2ч тишины.

Код-сайд готов: progress-logging зашипан в `stostayer.new` master (commit `a74ef73`, bump
0.3.0 → 0.4.0, 24/24 теста зелёные). Это чисто ops-handoff: rebuild образа на той же
схеме, что и 0.3.0 (build здесь → push в registry клиента `docker.stostayer.ru` → host
pull + re-tag), затем дождаться/прогнать sync и снять лог.

Закрывает единственный не-верифицированный acceptance-критерий исходной таски
`stostayer.new/.tasks/vehicles-loader-progress-logging.md` — «journalctl показывает движение»
(остальные 4/5 покрыты unit-тестами; этот по природе требует живого прод-прогона).

## Что нового в 0.4.0 (что должно появиться в логе)

- Фазовые строки: `▶ <phase> — start` / `✓ <phase> — done: N rows, <dur>` для
  branches / vehicles / units / delete-sweep.
- Батч-прогресс: `  manufacturers: 18/183 (12s)`, `  units: 5/26 (…)` — авто-шаг ≈ total/10.
- delete-sweep per-model: `  delete-sweep <model>: N disabled` / `0 — выгрузка полная` /
  `skip (пустой seen-set)`.

## Pending ops actions

- [ ] **Build & push** на dev-машине из корня `stostayer.new` (та же схема, что 0.3.0,
      см. `vehicles-loader-image-distribution` closed-блок):
      `docker build -f packages/vehicles-loader/Dockerfile -t docker.stostayer.ru/vehicles-loader:0.4.0 .`
      `docker push docker.stostayer.ru/vehicles-loader:0.4.0`
      (verdaccio-депы запекаются при build здесь — клиенту verdaccio не нужен.)
- [ ] **На хосте клиента:** `docker pull docker.stostayer.ru/vehicles-loader:0.4.0` +
      re-tag `:latest` (systemd-юнит запускает `:latest`).
- [ ] Дождаться планового прогона (systemd timer 06:20 MSK) **или** прогнать вручную
      `systemctl start vehicles-loader.service` на changed-выгрузке (на unchanged будет
      `skipped-unchanged`, прогресса не будет — нужен изменённый zip или сброс baseline).
- [ ] **Live-verify:** `journalctl -u vehicles-loader.service -f` (или `--since`) — видны
      `▶ … start`, периодический батч-прогресс, `✓ … done`, per-model delete-sweep.

## Acceptance criteria

- Образ `docker.stostayer.ru/vehicles-loader:0.4.0` собран здесь и доступен на хосте клиента,
  `:latest` указывает на 0.4.0.
- В `journalctl -u vehicles-loader.service` боевого прогона видно движение по фазам +
  батч-прогресс + per-model delete-sweep counts (не тишина после трёх `Total …`).
- Данные залились корректно (`importRun` новый `ok`-ряд), email-отчёт ушёл (попутно
  закрывает остаток «живой email-SEND в составе sync» из `vehicles-loader-image-distribution`).

## Decisions log

- 2026-05-30: заведено из `stostayer.new` session по явному указанию (закрыть код-таску
  by-inspection, live-verify вынести в .admin как deploy-follow-up). Push кода НЕ сделан
  (Rule 4) — деплою предшествует push master или build из локального дерева.

## Open questions

- [ ] Push `stostayer.new` master нужен до build, или билдим из локального рабочего дерева?
      (commit `a74ef73` пока только локально.)
- [ ] Где взять changed-выгрузку для немедленной проверки, или ждём естественного изменения
      `units.json` к ближайшему 06:20?

## Notes

- Схема деплоя 0.3.0 + обе инфра-гочи (IPv4 DB host; custom `/etc/hosts` для mail-DNS) —
  `stostayer.new/.wiki/concepts/client-infra-access.md` + `vehicles-loader-docker-deploy.md`.
- Источник: `stostayer.new/.tasks/vehicles-loader-progress-logging.md` (🟢 closed by-inspection),
  commit `a74ef73`.
- Предшественник: `.admin vehicles-loader-image-distribution` (🟢 closed 2026-05-29) — канал
  поставки + первый боевой прогон 0.3.0.

<!-- created-by: vitya@stostayer.new-session / 2026-05-30 / handoff: stostayer.new/.tasks/vehicles-loader-progress-logging.md -->