admin/.tasks/NEXT_SESSION.md

_last_updated_, session_id

_last_updated_	session_id
2026-06-04T12:00:00+03:00	2026-06-04-books-vds-disk-full-remediation

Next session handoff

Сессия: разбор disk-full алерта Rusonyx на books VDS (89.253.255.133). Причина найдена, диск 96%→44%, спам-петля заглушена, guard поставлен. Ничего не висит. Вики обновлён + закоммичен (b0559fdb).

Recent commits

• b0559fdb wiki(books-vds): disk-full incident 2026-06-04 + Bookva->slovo job scoping

Что сделано (books VDS, 04.06)

• ✅ Диск 96%→44% (53/122 ГБ). Освобождено ~64 ГБ: обрезаны runaway json-логи books-task-runner (32.8 ГБ) + bookva-task-runner (5.6 ГБ); снесены 11 orphan BuildKit-билдеров + 9 *_state volumes (~26 ГБ).
• ✅ Durable guard: /etc/logrotate.d/docker-containers (copytruncate 200M, rotate 3) + hourly /etc/cron.d/docker-logrotate. Без рестарта докера. crond active, тест-ран чистый.
• ✅ Root cause: books-task-runner (тенант slovo) error-loop'ил в Ozon по продавцу Bookva (client_id 50542), чей api_key в books-db.sellers намеренно подменён на слововский (9683…) как ревокация доступа books→Bookva-Ozon. Спам шёл из legacy seller-перебирающих agenda-джоб без скоупа.
• ✅ Фикс: проставлен data.idSeller=2 (slovo) пяти legacy-джобам в books-job-scheduler-mongo (ozon fbs postings syncronization, generate old prices, ozon fbs products syncronization, create ozon products in incorrect state report, put on sale products). Залипшие overdue-прогоны оборваны (unlock lockedAt:null + docker restart books-task-runner). Invalid-Api-Key 6448/мин → 0, джобы отработали по slovo и перепланировались.
• ✅ Deploy-durable (user спрашивал): эти джобы legacy (без data._fromConfig), reconciler (RECONCILER_ENABLED=true) трогает только _fromConfig-джобы; в tasks.json (в образе) у них schedule:null → пропускает. Эмпирика: stocks-sync idSeller:2 пережил деплой 31.05.
• ✅ Сверка полноты: 7 seller-перебирающих тасок — все заскоуплены; reconciler-gen джобы уже на salesChannels:[2]. Группа В снята: Bookva-канал = type=ym (Яндекс), Ozon-канала Bookva нет.

⚠️ НЕ ДЕЛАТЬ (специфично для этого инцидента)

• НЕ «чинить» ключ Bookva (50542) в books-db.sellers — он сломан НАМЕРЕННО (подменён на слововский) как ревокация. Живой ключ Bookva — в bookva-db/конфиге, для тенанта bookva. Если снова увидишь Invalid Api-Key по 50542 в books-стеке — это не баг ключа, а недо-скоупленная джоба. Полный разбор: .wiki/entities/books-vds.md § Disk-full incident.

Follow-up'ы (НЕ блокеры)

Что	Деталь
Каноничный фикс скоупа	legacy seller-джобы стоит перенести в tasks.json со скоупом ИЛИ вывести из эксплуатации (возможно, дублируют reconciler-gen). Mongo-правка надёжна, но если релиз даст им schedule в tasks.json без скоупа — Bookva-доступ вернётся. → сказать разработчикам books.
wiki-drift	bookva-* stack + books-task-runner/scheduler не в stack-inventory books-vds.md; нужен re-inventory.
Native log rotation	daemon.json max-size/max-file + docker restart — не делал (нужен maintenance window); logrotate-guard покрывает.

Открытые треки (.admin — ещё живые)

Трек	Готовность	Entry-point
harden-books-vds-exposed-ports	⚪ ready (user сказал «пока нет» на mongo-allowlist)	.tasks/harden-books-vds-exposed-ports.md
books-bookva-user-whitelist-gathering	⚪ ready — gathering от учредителя	.tasks/STATUS.md
stateful-split-volume-copy / infra-inventory	⚪ ready	.tasks/STATUS.md

Не делать (preemptive guards)

• Не возвращать :9200 / stateful-порты на 0.0.0.0 без IP-allowlist (books VDS, ransom-бот).
• Не ssh + docker compose up -d на VDS Portainer-stacks — только Portainer API (искл. traefik/portainer).
• branch ahead от origin — push без явного grant'а (Rule 4). Этой сессии grant НЕ давали.

Memory updates за сессию

• (нет нового файла) — инцидент + корректный root-cause + «не чинить ключ Bookva» зафиксированы в .wiki/entities/books-vds.md (закоммичено b0559fdb).