tasks(NEXT_SESSION): handoff — 0.4.0 deployed, journalctl verify after 06:21 Sun

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

.tasks/NEXT_SESSION.md

@@ -1,53 +1,65 @@
 ---
-_last_updated_: 2026-05-29T13:30:00+03:00
+_last_updated_: 2026-05-30T15:00:00+03:00
-session_id: 2026-05-29-labtools-slow-noissue
+session_id: 2026-05-30-vehicles-loader-0.4.0-deploy
 ---
 
 # Next session handoff
 
-_Сессия: разбор «labtools.ru тормозит после переезда на RUVDS». Итог — **non-issue**:
+_Сессия: деплой `vehicles-loader 0.4.0` (progress-logging) на прод СТО Стайер. Build здесь →
-прод на RUVDS быстрый (~0.35s TTFB), «медленно» было артефактом замера с воркстейшн
+push в `docker.stostayer.ru` → на хосте клиента pull + re-tag `:latest`=0.4.0. **Деплой выполнен,
-(LAN-DNS резолвит домен в локальную stale-копию). Инфру не трогал, traefik не правил.
+осталась только live-verify** на боевом прогоне таймера — он по природе требует changed-выгрузки,
-Открытые ES-incident треки прошлой сессии перенесены ниже — ещё живые._
+а сегодняшняя уже импортнута на 0.3.0. User выбрал ждать natural 06:20 (не форсить baseline)._
+
+## ГЛАВНОЕ для след. сессии — live-verify (после 06:21 MSK Sun 2026-05-31)
+
+Таймер `vehicles-loader.timer` next trigger = **Sun 2026-05-31 06:21:36 MSK**. После него:
+
+```
+plink -ssh -P 20435 -batch victor@new.stostayer.ru -pw '<pass stostayer/client ssh_pass>' \
+  "echo '<ssh_pass>' | sudo -S journalctl -u vehicles-loader.service --since '2026-05-31 06:00' --no-pager"
+```
+(docker/journalctl на хосте — через `sudo -S`, victor не в docker/adm-группе; `-batch` чтобы plink не висел на host-key промпте — ключ уже закэширован.)
+
+**Acceptance to confirm (закрывает таску 🟢):**
+- В логе видно движение: `▶ <phase> — start`, периодический батч-прогресс (`manufacturers: 18/183 …`), `✓ <phase> — done: N rows`, per-model `delete-sweep`. **НЕ тишина** после трёх `Total …`.
+- Прогон шёл на 0.4.0 (не skipped-unchanged) — т.е. 1С перезаписала файл в 6:00 и checksum разошёлся.
+- `importRun` новый `ok`-ряд (MariaDB `stostayer`, creds `pass stostayer/client`).
+- Email-отчёт ушёл (попутно закрывает остаток email-SEND из `vehicles-loader-image-distribution`).
+
+Если прогон оказался `skipped-unchanged` (1С не обновила файл) → подождать след. суток ИЛИ обсудить с user форс baseline-reset.
 
 ## Recent commits
 
-- `063910e2` incident(books-vds-es): true RCA — ransom-бот через открытый :9200
+- `b8a07fee` tasks(vehicles-loader-progress-deploy): 0.4.0 deployed, verify pending 06:21
-- `63708fe6` tasks(NEXT_SESSION): session-close — ES restore + 2 preventive controls live
+- `7ec62009` tasks(vehicles-loader-progress-deploy): new task — deploy 0.4.0 + live-verify
-- `48a5cf39` tasks(restore-es-indices-books-vds): closed — snapshot restore + 2 controls
 
-## Что сделали в эту сессию (labtools)
+## Состояние деплоя (что уже сделано)
 
-- Жалоба: labtools.ru медленно отдаётся на RUVDS, pilorama98.ru норм.
+- Образ `docker.stostayer.ru/vehicles-loader:0.4.0` собран здесь (811MB, digest `f2e10b1f0…`), запушен.
-- **Root cause = артефакт замера, не дефект прода.** Публичный DNS labtools.ru/pilorama98.ru → RUVDS `80.64.31.36`; прод TTFB ~0.35s (curl --resolve), картинки 0.13–0.5s — быстро. Но с этой воркстейшн LAN-DNS резолвит домены в **локальную stale-копию** (home traefik :4443 → IIS :8089), которая тормозит для тенанта labtools (HTML TTFB 1.45s vs pilorama 0.25s на том же :8089).
+- На хосте: `vehicles-loader:latest` → `0f8a4dd46236` = 0.4.0; `0.3.0` (`5407c0563e44`) retained для rollback (re-tag обратно если регресс).
-- traefik-конфиги `labtools.yml` ≡ `pilorama98.yml` побайтово (оба → host.docker.internal:8089) → в traefik чинить нечего.
+- timer `enabled`, `active (waiting)`.
-- К концу сессии user подтвердил «labtools.ru стал отдаваться нормально» (видимо дорезолвился кэш на RUVDS). **Ничего не менял.**
-- Memory сохранён: `workstation-lan-dns-serves-local-cms-copy` (валидировать прод только через `curl --resolve` / не-LAN, браузер через MCP тоже бьёт в локальную копию).
 
-## Open треки (перенос из ES-incident сессии — ещё живые)
+## Открытые треки (перенос, ещё живые)
 
 | Трек | Готовность | Entry-point |
 |---|---|---|
-| `harden-books-vds-exposed-ports` | ⚪ ready — exposure-audit сделан | `.tasks/harden-books-vds-exposed-ports.md` |
+| `harden-books-vds-exposed-ports` | ⚪ ready (user сказал «пока нет» на mongo-allowlist) | `.tasks/harden-books-vds-exposed-ports.md` |
-| `books-bookva-user-whitelist-gathering` | ⚪ ready — gathering от учредителя Bookva | `.tasks/STATUS.md` |
+| `books-bookva-user-whitelist-gathering` | ⚪ ready — gathering от учредителя | `.tasks/STATUS.md` |
-| `stateful-split-volume-copy` | ⚪ ready — maintenance window 5–10 мин | `.tasks/STATUS.md` |
+| `stateful-split-volume-copy` / `infra-inventory` | ⚪ ready | `.tasks/STATUS.md` |
-| `infra-inventory` | ⚪ ready — two-tier (public + admin) | `.tasks/STATUS.md` |
-| `books-stateful-split-execution` / `books-vds-bookva-bootstrap` / `books-dns-cutover-bookva` | 🔵 blocked | `.tasks/STATUS.md` |
 
 ## Спроси user'а
 
-- **epz-поиск end-to-end не подтверждён руками** (из прошлой сессии) — починено место падения (`tenant undefined`), но аутентифицированный запрос из UI не делался. Проверить epz в обоих UI (bookseller.kzntsv.site = bookva, bookva.kzntsv.site = slovo). Downstream → логи `books-web`/`bookva-web`.
+- (deploy) Ничего блокирующего — verify автоматом по таймеру. Если хочешь форс-проверку раньше 31.05 — нужен baseline-reset (внеплановое email клиенту).
-- **harden-ports**: user сказал «пока нет» на немедленный mongo-allowlist. Не начинать без явного запроса.
 
 ## Не делать (preemptive guards)
 
-- **Не возвращать публикацию `:9200`** (и stateful-портов) на `0.0.0.0` без IP-allowlist — free-ES без auth, ransom-бот уже отметился.
+- **Не форсить baseline-reset** vehicles-loader без явного запроса — шлёт клиенту внеплановое email-письмо.
-- **Не трогать mongo/mariadb/minio порты** без подтверждения user'а.
+- **Не возвращать `:9200` / stateful-порты на `0.0.0.0`** без IP-allowlist (books VDS, ransom-бот).
-- **Не использовать `ssh + docker compose up -d`** на VDS для Portainer-stacks — только Portainer API. Исключение: traefik/portainer (management-plane).
+- **Не `ssh + docker compose up -d`** на VDS Portainer-stacks — только Portainer API (искл. traefik/portainer).
-- **Не «чинить» traefik labtools.yml вслепую** — он корректен, идентичен рабочему pilorama; медленность была локальной DNS-копией, не конфигом.
+- **branch ahead от origin** — push без явного grant'а (Rule 4). Этой сессии grant НЕ давали.
-- **branch ahead от origin** — push без явного grant'а (project-discipline Rule 4). Этой сессии grant НЕ давали.
 
 ## Memory updates за сессию
 
-- ✅ `workstation-lan-dns-serves-local-cms-copy` (новый) — мигрированные CMS-домены с воркстейшн резолвятся в локальную stale-копию, не RUVDS; валидировать прод через `curl --resolve`/off-LAN.
+- (нет нового на этом раунде) — схема деплоя и обе инфра-гочи уже в `stostayer.new/.wiki/concepts/client-infra-access.md` + `vehicles-loader-docker-deploy.md`.
-- Кандидат с прошлой сессии (НЕ сохранён): books VDS — docker port-publish обходит firewalld; stateful-сервисы наружу = vector.
+</content>
+</invoke>

.tasks/STATUS.md

@@ -1,4 +1,6 @@
 # Admin Task Board
+_Updated: 2026-05-30 — 🟡 `vehicles-loader-progress-deploy`: деплой 0.4.0 ВЫПОЛНЕН (build здесь → push `docker.stostayer.ru` → host pull + re-tag `:latest`=0.4.0, 0.3.0 retained). Acceptance #1 ✅. Verify-окно = natural (user-выбор, не форсим baseline → клиент без внепланового email). timer next trigger Sun 2026-05-31 06:21 MSK → live-verify journalctl в след. сессию. Open Q #1 (push кода) снят: `a74ef73` уже в origin/master._
+_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 +24,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:** paused — деплой выполнен, ждём боевого прогона для verify
+**Where I stopped:** 0.4.0 собран здесь + запушен в `docker.stostayer.ru` + на хосте pull+re-tag `:latest`=0.4.0 (0.3.0 retained). Acceptance #1 ✅. Verify-окно = natural (user). timer next trigger Sun 2026-05-31 06:21:36 MSK.
+**Next action (след. сессия после 06:21 MSK 31.05):** `ssh victor@new.stostayer.ru:20435` → `sudo journalctl -u vehicles-loader.service --since '2026-05-31 06:00'` — убедиться что видно ▶/батч-прогресс/✓/delete-sweep (не тишина), importRun новый `ok`-ряд, email ушёл → закрыть 🟢.
+**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,79 @@
+# 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
+
+- [x] **Build & push** на dev-машине из корня `stostayer.new` (2026-05-30): образ
+      `docker.stostayer.ru/vehicles-loader:0.4.0` собран (811MB, digest
+      `sha256:f2e10b1f090ba47f9b5de83b84f91c5ce827ecaf1e94bc0331f2d6773f85845a`),
+      `docker login` BA-кредами → `docker push` (общие слои с 0.3.0, докинуты только app-слои).
+      verdaccio-депы из `.yarn/cache` запеклись при build.
+- [x] **На хосте клиента** (ssh `victor@new.stostayer.ru:20435`, docker через `sudo -S`):
+      `docker pull …:0.4.0` (digest совпал) + `docker tag …:0.4.0 vehicles-loader:latest`.
+      `:latest` теперь `0f8a4dd46236` = 0.4.0; 0.3.0 (`5407c0563e44`) оставлен под rollback.
+- [ ] Дождаться планового прогона — **systemd timer next trigger `Sun 2026-05-31 06:21:36 MSK`**
+      (timer `enabled`, `active (waiting)`). Verify-окно выбрано user'ом = natural 06:20
+      (не форсим baseline-reset — клиент не получает внепланового email). На unchanged будет
+      `skipped-unchanged`; 1С перезапишет файл в 6:00 → 06:21 прогон на changed-выгрузке.
+- [ ] **Live-verify (СЛЕДУЮЩАЯ СЕССИЯ после 06:21 MSK 31.05):**
+      `journalctl -u vehicles-loader.service --since '2026-05-31 06:00'` — видны
+      `▶ … 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: **build+push+host-deploy выполнены.** Образ 0.4.0 собран здесь, запушен в
+  `docker.stostayer.ru`, на хосте pull + re-tag `:latest` → 0.4.0. 0.3.0 retained для rollback.
+- 2026-05-30: open question #1 (push кода) снят — `a74ef73` оказался **уже в origin/master**
+  (`git branch -r --contains a74ef73` → origin/master), дерево чистое. Билдил из чистого дерева,
+  Rule-4-вопроса нет.
+- 2026-05-30: open question #2 (verify-окно) решён user'ом = **ждём natural 06:20** (Sun 31.05),
+  НЕ форсим baseline-reset. Причина: форс = внеплановое email-письмо клиенту + спурьёзный
+  ре-импорт; natural-прогон и так = боевой acceptance. Trade-off: verify unattended, в след. сессии.
+- 2026-05-30: заведено из `stostayer.new` session по явному указанию (закрыть код-таску
+  by-inspection, live-verify вынести в .admin как deploy-follow-up).
+
+## Open questions
+
+- [x] ~~Push `stostayer.new` master нужен до build?~~ — нет, `a74ef73` уже в origin/master.
+- [x] ~~Где взять changed-выгрузку?~~ — ждём natural 06:21 Sun 31.05 (1С перезапишет файл в 6:00).
+
+## 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 -->