tasks(vehicles-loader-progress-deploy): new task — deploy 0.4.0 + live-verify journalctl

Handoff from stostayer.new (code task vehicles-loader-progress-logging closed
by-inspection, commit a74ef73). Ops follow-up: rebuild image 0.4.0 on the same
channel (build here -> push docker.stostayer.ru -> host pull + re-tag) and
capture journalctl from a live run to verify phase/batch/delete-sweep progress.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.tasks/STATUS.md

@@ -1,4 +1,5 @@
 # Admin Task Board
+_Updated: 2026-05-30 — заведена ⚪ `vehicles-loader-progress-deploy` (handoff из stostayer.new). Progress-logging 0.4.0 зашипан в коде (stostayer.new `a74ef73`, 24/24 теста); ops-follow-up — rebuild образа той же схемой (build здесь → push `docker.stostayer.ru` → host pull+re-tag) и снять `journalctl` с боевого прогона (закрывает не-верифицированный 5-й критерий «journalctl показывает движение»). Попутно добивает остаток email-SEND из `vehicles-loader-image-distribution`._
 _Updated: 2026-05-29 — 🟢 `vehicles-loader-image-distribution` **closed**: канал поставки = собственный registry клиента `docker.stostayer.ru`, build у нас (verdaccio-депы запекаются → клиенту verdaccio не нужен), без Portainer (oneshot + systemd-timer). Доки финализированы (stostayer.new `e55cfba`). Открытие `pass stostayer/client` показало свою инфру клиента (Portainer+registry) → развилка A/B пересмотрена. Фактический prod-деплой — follow-up, ждёт grant'а._
 _Updated: 2026-05-29 — **РЕЦИДИВ того же инцидента, диагноз сменён.** Вчерашняя гипотеза «оператор в cutover» **опровергнута**. Истинная причина: ES публиковал `0.0.0.0:9200` мимо traefik (free-ES без auth) → **ransom-бот** удалял индексы by-name (мимо Control #1), оставлял `read_me` с BTC-выкупом. accessLog (Control #2) пуст — бот шёл прямо в порт. **Control #3 (fix):** убрана публикация host-порта (Portainer PUT stack 33) → дыра закрыта; `epz/products/artmone` restore из `daily-2026-05-25`. Второй, отдельный баг: epz-поиск падал у ОБОИХ тенантов — `config.get("tenant")` (node-config) не задан ни в `default.json`, ни в env-маппинге, `TENANT` env был мёртвым грузом → добавил `tenant` в overlay `default.json` (slovo/bookva), резолвится, ошибки прекратились (products работал — другой код-путь). accessLog откатан (сторожил не ту дверь). Exposure-audit → ⚪ `harden-books-vds-exposed-ports`. См. `.wiki/concepts/es-destructive-delete-incident-2026-05-26.md` § «Рецидив 2026-05-29»._
 _Updated: 2026-05-28 (вечер) — 🟢 `restore-elasticsearch-indices-books-vds` **closed** в ту же сессию через snapshot restore (46 сек) из `daily-2026-05-25` (полные данные, ~2ч после оригинального reindex'а). RCA: 5 индексов (включая system `.tasks`) удалены через ES API `DELETE _all` за 1 сек на 2026-05-26 10:21 UTC, **1ч 11мин после создания bookva-es** — оператор в cutover-prep попал на canonical вместо internal-only bookva-es. Caller identity не восстановим (audit log = X-Pack платный, traefik accessLog был выключен, Portainer audit = enterprise). 2 preventive фикса applied + verified: (1) ES env `action.destructive_requires_name=true` — `DELETE _all` / wildcard теперь 400; (2) traefik JSON accessLog в `/letsencrypt/access.log` — будущие DELETE оставят forensic след. См. таску + `.wiki/concepts/es-destructive-delete-incident-2026-05-26.md`._
@@ -22,6 +23,17 @@ _Updated: 2026-05-26 — заведена `bookva-tenant-cutover-prep` ⚪ (7-st
 
 _Updated: 2026-05-25 (`iis-migration-to-ruvds` 🟢 closed Phase 1 per user decision — 9/24 hostnames live на RUVDS, source IIS оставлен running. `migrate-elasticsearch-to-books-vds` 🟢 closed ранее сегодня. 16 IIS hostnames + LE renewal pipeline + decommission — descoped в Closure note, не отдельные tracker tasks.)_
 
+## ⚪ [vehicles-loader-progress-deploy] — задеплоить vehicles-loader **0.4.0** (прогресс-логирование) на прод клиента + live-verify journalctl. Handoff из stostayer.new (код-таска `vehicles-loader-progress-logging` 🟢 closed by-inspection, commit `a74ef73`). См. [vehicles-loader-progress-deploy.md](vehicles-loader-progress-deploy.md).
+
+**Status:** ready
+**Where I stopped:** (not started) — код 0.4.0 на master stostayer.new (НЕ запушен, Rule 4); образ 0.3.0 на проде, нужен rebuild.
+**Next action:** build здесь → push `docker.stostayer.ru/vehicles-loader:0.4.0` → host pull + re-tag `:latest` → дождаться/прогнать sync на changed-выгрузке → `journalctl -u vehicles-loader.service` показывает фазы+батчи+delete-sweep.
+**Blocker (soft):** push stostayer.new master ИЛИ build из локального дерева (commit `a74ef73` пока локальный).
+**Branch:** n/a
+<!-- created-by: vitya@stostayer.new-session / 2026-05-30 / handoff: stostayer.new/.tasks/vehicles-loader-progress-logging.md -->
+
+---
+
 ## 🟢 [restore-elasticsearch-indices-books-vds] — closed 2026-05-28 — snapshot restore из `kreknin:daily-2026-05-25` за 46 сек (epz=820604, products=105922, artmone=2621, counts == source). Forensics: 5 индексов удалены через ES API `DELETE _all` 26.05 10:21 UTC, через 1ч 11мин после создания `bookva-es` — оператор в cutover-prep попал на canonical вместо internal-only bookva. Caller identity unrecoverable (audit log = X-Pack платный, traefik accessLog был выключен). 2 preventive фикса applied: ES env `action.destructive_requires_name=true` + traefik JSON accessLog в `/letsencrypt/access.log`. См. [restore-elasticsearch-indices-books-vds.md](restore-elasticsearch-indices-books-vds.md) § Closure + `.wiki/concepts/es-destructive-delete-incident-2026-05-26.md`.
 **Branch:** n/a
 <!-- created-by: vitya@books-session / 2026-05-28 / trigger: prod 404 index_not_found_exception на /api/epz/search + /api/products/search -->

.tasks/vehicles-loader-progress-deploy.md

@@ -0,0 +1,71 @@
+# 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 -->