pilonuxt:36ec970 развёрнут Portainer stack 16 на pilonuxt.vds.kzntsv.site.
Инфра зелёная (cert/traefik/egress mssql+smtp/SSR-hairpin). App отдаёт 500
`Cannot read properties of null (reading 'ce')` на всех роутах вкл. server
/api/snolla → баг в data-слое snolla, не деплой. Inbox pilonuxt отправлен.
Blocked на app-фиксе. Стек оставлен поднятым для быстрой итерации тега.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
pilonuxt deploy на vds-kzntsv за Traefik. Compose готов (proxy net,
websecure, certresolver letsEncrypt, Host pilonuxt.vds.kzntsv.site, :3000,
GTM погашен на smoke-поддомене). Домен согласован с vitya: temp-поддомен
для smoke, cutover www.pilorama98.ru — отдельным шагом.
Сборка диагностирована, образ НЕ собран — Dockerfile pilonuxt падает в
чистом контейнере (локально замаскировано глоб. yarnrc + сетью):
1. .yarnrc.yml без npmAlwaysAuth:true → YN0041 anonymous (whoami=vitya).
2. Dockerfile не копирует scripts/+src/generated до yarn install →
postinstall Cannot find module scripts/ensure-schema.mjs (YN0009).
По решению vitya сборка отдана pilonuxt (их репо/фикс), за admin — Portainer.
Inbox victor/pilonuxt отправлен с разбором. Задача 🔵 blocked до образа.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
snolla galleries 404 (imgproxy "Source unreachable"): legacy storageClient
"galleries" = MoreThenCms Local storage class (App_Data\galleries\<siteId>),
never in S3 — products were migrated, galleries weren't. Path A (user pick):
new bucket `galleries`, 301 pilorama98 originals (77 MiB) rclone'd from RUVDS
IIS → s3://galleries/37e6…/<guid>.jpg verbatim. snolla code unchanged
(storageClient=bucket is the working convention). imgproxy smoke from
books-vds: real obj 200 image/webp, fake guid 404. Other sites unmigrated
(scope). Inbox sent to victor/snolla.
- close [migrate-gallery-originals-to-s3] (scope pilorama98)
- NEW .wiki concept galleries-storage-class-local-not-s3
- fix stale minio-imgproxy-on-vds (pipeline on books-vds since 2026-06-08)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bookva-es (отдельный ES 7.10, Portainer stack 37) не снапшотился — path.repo
не сконфигурирован. Пересоздан через Portainer API (PUT /api/stacks/37) с
path.repo=/snapshots + bind /usr/docker/bookva-es/snapshots (uid 1000:0);
внешний том bookva-es-data сохранён (epz/products целы). Repo kreknin
зарегистрирован.
Добавлен Step 2b (bookva-es snapshot + prune) в run.sh.
Gotcha пойман на проверке приёмника ДО коммита: оба ES-каталога называются
`snapshots` → как отдельные rsync-источники сливаются в один dest/snapshots/
и портят оба репо (видно по двойному index-N). Fix: источник bookva-es =
родительский /usr/docker/bookva-es (basename bookva-es → dest/bookva-es/snapshots/).
Verified green: BOOKS-VDS backup OK 10m28s, на kreknin раздельно
snapshots/ (slovo, index-41, 795M) + bookva-es/snapshots/ (index-4, 801M),
по одному index-N в каждом → оба независимо рестораблельны.
Закрывает .tasks/bookva-es-snapshot-repo.md (🟢). bookva tenant полностью
покрыт (db/mongo/minio/es).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bookva tenant (bookva-db/mongo/es/minio) поднят 26.05 при cutover-prep, а
books-vds backup написан 25.05 — до bookva. Покрытие не расширили; gap висел
wiki-follow-up #2 ~2.5 недели. Тот же класс, что MSSQL: новый stateful, бэкап
отстал, повешен как заметка.
Добавлено в scripts/books-vds-backup-daily-kreknin/run.sh (deploy == repo,
бэкап .bak-pre-bookva):
- bookva-db: mariadb-dump (тот же BOOKS_DB_ROOT_PASSWORD, стек клонирован)
- bookva-mongo: mongodump --archive (no-auth)
- bookva-minio: raw rsync named volume bookva-minio-data (immutable objects)
Каждая команда протестирована изолированно ДО внесения в скрипт. Verified
зелёным прогоном: BOOKS-VDS backup OK 10m42s, артефакты на kreknin
(bookva-mariadb 257M, bookva-mongo 3.2M, bookva-minio 1.4G).
bookva-es отложен (path.repo не сконфигурирован, нужен ES restart через
Portainer) -> .tasks/bookva-es-snapshot-repo.md. Покрыт по факту: индексы
epz/products идентичны slovo ES, который снапшотится.
- .wiki/entities/books-vds.md: Backup-секция + follow-up #2 частично закрыт
- .wiki/concepts/backup-inventory-2026-06.md: bookva row -> done
- .tasks/bookva-es-snapshot-repo.md: backlog для ES-снапшота
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
VDS daily backup пал с 12.06 (line 108, exit 1): mssql-блок (added 11.06,
commit f8ca0794) использовал `WITH ... INIT`, упирался в компрессованный
media-header майских .bak (созданы WITH COMPRESSION на Developer-источнике).
Express не пишет в compression-форматированный media set -> Msg 1844, молчаливый
провал первым же cron-запуском. 5 боевых CMS-баз 3 недели без offsite-копии.
Fix: INIT -> FORMAT (всегда новый media set, иммунно к остаткам). Прогон
verified зелёным: VDS backup OK 95m41s, все 5 .bak на kreknin
(MoreThenCms 910M, StayerCalculator 528M, StayerPrice 39M, TireService 4.5M,
stostayer 990M), speedup 22.62 (--link-dest хардлинкует).
- scripts/vds-backup-rsync-kreknin/run.sh: синхронизирован с задеплоенным
(mssql-блока в репо не было); FORMAT
- .wiki/concepts/mssql-on-vds.md: gotcha #2 (INIT vs FORMAT) + backup-gap
- .wiki/concepts/backup-inventory-2026-06.md: новая — карта estate × что реально
бэкапится (с доказательством); триаж дыр
- openwrt UCI backup настроен (cron 03:30 -> kreknin, restricted forced-command
key) — документация в entity + inventory
- .tasks/kreknin-self-backup.md: backlog #1 SPOF (приёмник сам не бэкапится)
- STATUS.md: incident + audit summary
Урок: бэкап-шаг не готов, пока не предъявлен лог одного реального успеха;
прод-крон не должен быть первым тестом бэкап-пути.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- .admin claim-guard pushed + verified: claim-gate run over real .admin board
skips all 4 claimable .admin tasks with reason=needs-human (zero slip-through).
- Always-on bring-up started (docker mongo+reconciler) then torn down per user
"don't start pollers without permission". Host task-runner never started — no
claim/spawn occurred. .env/secrets.env/guard left in place, ready.
- Worker config decided: this workstation; AGENT_RUNTIME=claude-opus;
AGENT_CAPABILITIES=needs-internet; headless claude login suffices.
- Caught a stale-claimable task (MoreThenCms cms-maljarka-https-mode-bug-fix was
⚪ ready though the bug was fixed today) — closed it. Lesson recorded: sweep
boards for stale-claimable before enabling always-on.
- GATE: starting pollers awaits explicit user grant.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Take task to 🔴, create per-task file (was on board w/o file).
- DRY_RUN smoke passed end-to-end on this workstation (host task-runner :3000,
one tick via POST/GET). Real shared-board read; preview candidate
OpeItcLoc03/MoreThenCms/cms-maljarka-https-mode-bug-fix; no claim/spawn.
- Finding: .admin had NO policy.toml; claim gate ignores consult_policy, so the
HARD ".admin excluded from autonomous claim" guard was UNENFORCED. Add
.tasks/policy.toml default_weight="needs-human" → every .admin task fails the
L3 needs-human claim gate. Gates autonomous poller only; INERT until pushed
(claim reads policy.toml via Gitea backend, not local disk).
- Build-prereq in task Next-action was a phantom: runner is plain JS (no tsc);
only projects-meta-mcp needs build and its dist/ already exists.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Root cause (NOT a migration defect): MoreThenCms tenant `maljarka`
had `dbo.Sites.SettingsData = NULL` (no `httpSecure` block) -> on a
real HTTPS request SnollaMiddleware throws KeyNotFoundException ->
502. HTTP served 200 fine. DNS/TLS/IIS binding all correct.
Fix applied to shared MSSQL (mssql.kzntsv.site): UPDATE Sites set
SettingsData with httpSecure{enableHttps:true,...} + recycle snolla
pool. Verified 443->200 server-local and external via 80.64.31.36;
kupimknigi untouched. Audit: maljarka was the only NULL-settings
site with a :443 binding (of 25); rimiz degraded for another reason.
- new concept: morethencms-null-settingsdata-https-502
- entities/ruvds-iis-host: maljarka moved from Degraded -> fixed
- index.md + log.md + STATUS.md + NEXT_SESSION.md updated
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Read-only diagnosis complete, server untouched. Root cause: ML-DSA-65 (PQ)
incompatible with dest www.intel.com (Akamai). Fix (intel->microsoft) staged
on board, not applied. Plain VLESS 32030 works.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Live-verify прогона Sun 31.05 06:21→07:53 MSK прошёл: progress-logging
показал движение по всем фазам, НЕ тишина. exit 0, importRun id=4 ok.
Попутно найден+починен email-баг: STOSTAYER_MAIL_TO=site@stostayer.ru
(отчёт слался сам себе) → vitya.kuznetsov@gmail.com в host env
(бэкап .bak.20260531). Доставка на gmail подтверждена тест-письмом.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Build здесь → push docker.stostayer.ru/vehicles-loader:0.4.0 → на хосте
клиента pull + re-tag :latest=0.4.0 (0.3.0 retained для rollback).
Acceptance #1 закрыт. Verify journalctl ждёт natural-прогона
Sun 2026-05-31 06:21 MSK (user выбрал natural-окно, без baseline-reset).
Open Q #1 снят: a74ef73 уже в origin/master.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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(vehicles-loader-image-distribution): first prod run + email/DNS fix
First scheduled run (2026-05-30 06:20) synced OK (importRun id=3) but failed on
the email step: container DNS cannot resolve mail.stostayer.ru (rewritten
resolv.conf + firewalled :53; --add-host ignored under --network host). Data
landed fine. Fixed by mounting a custom /etc/hosts; verified via
nodemailer.verify() = SMTP_VERIFY_OK. stostayer.new 8e5997c. Logging task filed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@
tasks(vehicles-loader-image-distribution): prod deploy done + MariaDB IPv6 gotcha
vehicles-loader deployed live on new.stostayer.ru: image 0.3.0 in client
registry, env-file placed, systemd timer enabled (next 06:20 MSK). Records the
MariaDB-IPv4 / host-net /etc/hosts ::1 gotcha hit during the dry-run (fixed via
STOSTAYER_DB_HOST=127.0.0.1 + --network host), now in stostayer.new wiki.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@
tasks(vehicles-loader-image-distribution): closed — client-registry + build-here + no-Portainer
Decision channel resolved: maintainers build locally, push to the client's
own registry docker.stostayer.ru, host pulls + re-tags :latest. No Portainer
for the oneshot run. Deploy docs finalized in stostayer.new e55cfba.
Actual prod deploy on new.stostayer.ru:20435 is a follow-up pending grant.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@
Из stostayer.new session 29.05: lite core зашипан, Dockerfile CMD финализирован
(блокер сузился до канала поставки + README distribution-секции). Дописано:
B (build-from-git) требует verdaccio-доступ у клиента (.yarn/cache не коммитится),
что усиливает рекомендацию A. A технически подтверждён (docker build + run --help ок).
Рецидив вчерашнего ES-инцидента вскрыл истинную причину. Вчерашняя
гипотеза «оператор в cutover попал на canonical» опровергнута.
Root cause: ES (stack 33) публиковал 0.0.0.0:9200 мимо traefik. Free-ES
7.10 без auth → порт открыт всему интернету. Ransom-бот сносил индексы
by-name (мимо Control #1 destructive_requires_name), оставлял read_me с
BTC-выкупом. accessLog (Control #2) пуст — бот шёл прямо в порт, не через
traefik. firewalld бесполезен (docker-publish обходит INPUT-зоны).
Fix (Control #3): убрана публикация host-порта из stack 33 (Portainer
PUT), дыра закрыта; re-restore epz/products/artmone из daily-2026-05-25.
Отдельный баг: epz-поиск падал у ОБОИХ тенантов — getTenantIdSeller(
config.get("tenant")) через node-config, а tenant не задан ни в
default.json, ни в env-маппинге (TENANT env = мёртвый груз). Добавлен
tenant в overlay default.json (slovo/bookva). products работал —
отдельный код-путь.
accessLog откатан (сторожил не ту дверь).
- wiki concept: correction-блок + секция «Рецидив 2026-05-29» + exposure-audit
- tasks: restore-es reopened+reclosed; new ⚪ harden-books-vds-exposed-ports
- NEXT_SESSION handoff
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
snapshot restore из kreknin:daily-2026-05-25 за 46 сек (epz=820604,
products=105922, artmone=2621, counts == source).
RCA: 5 индексов (включая system .tasks) удалены через ES API DELETE _all
за 1 сек на 2026-05-26 10:21 UTC — 1ч 11мин после создания bookva-es в
cutover-prep. Каноничный endpoint elasticsearch.kzntsv.site попал под
команду которая предназначалась bookva-es:9200 (internal-only, без
traefik route). Caller identity unrecoverable: ES audit = X-Pack платный,
traefik accessLog был выключен, Portainer CE без audit.
Preventive controls applied + verified:
1. ES env action.destructive_requires_name=true (stack 33) — DELETE _all
и wildcard теперь 400 BadRequest; by-name DELETE работает (нужно для
reindex). Pattern удаления что случился физически невозможен.
2. Traefik JSON accessLog в /letsencrypt/access.log — будущие DELETE
оставят forensic след с IP/user/method/path.
Wiki concept: .wiki/concepts/es-destructive-delete-incident-2026-05-26.md
с recovery runbook + preventive controls + cross-refs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Deployed modulair-rag (Portainer stack 15) on VDS 89.253.255.94, acceptance 6/6.
Pre-flight verify found the task was filed on stale premises; corrected in-flight:
- registry images absent (registry reinstalled 2026-05-20) → rebuilt all 3 ON the
VDS (3.36GB tier1 layer 499'd pushing through traefik from home; local push works)
- MINIO_ENDPOINT=minio.vds.kzntsv.site (minio.kzntsv.site is books VDS)
- traefik entrypoint https→websecure (NAS-era label) fixed in live stack
- created DB modulair_rag, minio bucket + scoped svcacct, ROUTERAI key to pass
- DNS modulair-mcp.kzntsv.site→VDS (user)
Follow-ups (consumer repo modulair-rag): compose.yml entrypoint commit,
portainer-stack.md rewrite, lightrag embedding binding=ollama/model=None check.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stack 26 (books-ops-mcp) PUT с pullImage:true + добавлен BOOKVA_MARIADB_PASSWORD
env (= MARIADB_PASSWORD, bookva-db ops_ro password identical после cp-a).
Container books-ops-mcp@master-f5f295b running.
Smoke:
- ops.mariadb.query tenant=slovo → АФО2/Главная26/НК11 (slovo warehouses)
- ops.mariadb.query tenant=bookva → Главная26/Ира/НК11 (bookva warehouses)
(Ира появилась в bookva post-cutover, нет в slovo — данные genuinely разные)
- ops.mongo.count tenant=bookva collection=agendaJobs → 2818
Один host-level ops-mcp видит обе tenant DBs через per-tenant pool maps.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Multi-fix session: bookva tenant works correctly после 6 fix'ов одной природы
(incomplete cutover-prep без e2e smoke). См. NEXT_SESSION.md § "What's LIVE"
+ § "Memory updates" + shared wiki concept tenant-overlay-config-volume-mount-path-pitfall.
Changes:
- host-stacks/books-vds/ops-mcp.compose.yml: add BOOKVA_MARIADB_PASSWORD env
declaration + multi-tenant docs note. Stack 26 ещё не пере-PUT'нут на это,
открытая микро-таска ops-mcp-multi-tenant-stack-activate в NEXT_SESSION.
- STATUS.md: 6-bug summary в latest update line.
- NEXT_SESSION.md: full rewrite с 14 recent commits, open треками, asks к user'у,
memory updates про agenda.db.collection / composite jobId / scheduler envs /
bookva auth tokens.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
