- 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>
Acceptance:
- 3 scripts (VDS bash + RUVDS ps1 + windows-host ps1) синхронизированы под
unified push + email format (commit 73ad6dd0).
- VDS deployed + smoke ntfy+email ✓.
- RUVDS deployed + smoke ntfy+email ✓.
- windows-host smoke + deploy — closed-by-inspection per user direction
«все ок»: parser-check достаточно, deploy.ps1 готов для self-deploy
elevated PS у user'а. Без deploy сегодня ночью 03:00 MSK прогон в
STAROM format'е (cosmetic, не functional regression).
Также атомарный revert (`.bak-pre-unify` на каждом хосте) задокументирован
в .tasks/unify-backup-notifications.md § Closed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 host-pipelines (VDS bash, RUVDS+windows-host ps1) had drifted formats:
ntfy title `VDS backup OK $D` vs `RUVDS backup OK ($D)`, tags
`white_check_mark` vs `green_circle`, email subject `[VDS] backup OK` vs
`RUVDS backup -- SUCCESS`. Phone-side фильтрация и desktop reading
ломались за счёт inconsistency.
Unified to:
- ntfy push: title `<HOST> backup OK <date>`, body
`<duration_human>, size=<>, snapshots=<>, dest=kreknin:<>`,
tags `green_circle` (OK) / `red_circle` (FAILED).
- email: subject `[<HOST>] backup <STATUS> <date>` (STATUS=OK|FAILED),
body — structured Date/Duration/Size/Snapshots/Source/Dest/Components/Log.
Failure body extends with `Tail (last 40 lines)`.
Also imports VDS `run.sh` into repo as `scripts/vds-backup-rsync-kreknin/`
— closes drift из общего `scripts/<slug>/` pattern (RUVDS+windows-host
уже жили там; VDS жил только на /opt/stacks/backup/scripts/).
Deploy status:
- VDS: deployed via scp + sudo install, sha256=27b09ca272bb, smoke ntfy+email ✓
- RUVDS: deployed via scp + Move-Item, sha256=f3bb57a86af5, smoke ntfy+email ✓
- windows-host: deploy.ps1 + smoke-notify.ps1 готовы в scripts/, **pending
elevated PS у user'а** (ACL=SYSTEM+Administrators, не пишется без UAC).
Spec + decisions + completed: .tasks/unify-backup-notifications.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
STATUS.md cleanup:
- 25 🟢 closed task blocks moved to new .tasks/ARCHIVE.md (append-only
history; per-task <slug>.md остаются in-place в .tasks/ root).
- STATUS.md now 6 KB instead of 78 KB — board показывает только active
(🔴/🟡), ready (⚪), blocked (🔵).
- Header refreshed с current scope summary.
Re-scope: cms-stopgap-backup-daily → windows-host-fallback-backup-daily
- Original spec: "временный stop-gap до migration MSSQL/MinIO на VDS"
- Reality (2026-05-24): MSSQL+sites уже мигрированы и прикрыты backup'ами
(vds-backup-rsync-kreknin 🟢 + ruvds-backup-daily-kreknin 🟢)
- New purpose (user-decision): windows-host остаётся warm-standby для DR
(failover при потере VDS/RUVDS), backup pipeline нужен чтобы failover не
возвращал stale state.
- Also: CMS image-rendering хардкодит imgproxy.kzntsv.site через DLL →
windows-host MinIO/imgproxy — active dependency даже после primary
cutover, не "standby". Backup критично для image-pipeline DR.
- Tool: rclone same pattern как ruvds-backup-daily-kreknin 🟢
iis-migration-to-ruvds scope narrow:
- tandemmebel.ru + www.tandemmebel.ru EXCLUDED из cutover (user-decision)
- Остаются на windows-IIS:8089 неопределённо
- Cert на RUVDS уже импортирован, HTTPS binding existing — idle, traffic
не пойдёт пока DNS не flipped. Source IIS snolla site нельзя
decommission'ить полностью пока tandemmebel на нём же (catch-all).
- Scope теперь 24 hostnames для migration (вместо 26).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Создаю задачу пока [iis-migration-to-ruvds] в soak window. Закрывает
Open-question "Backup strategy для RUVDS IIS" из migration task.
Pattern параллель [vds-backup-rsync-kreknin] 🟢 — daily backup → kreknin
synology, 7 daily snapshots retention, ntfy на vds-backup topic.
Differences vs VDS:
- Win Server 2025 Core → rclone single-binary, не rsync (no cygwin/WSL)
- Task Scheduler SYSTEM-account, не cron-root
- 04:30 MSK (за 30 мин до VDS backup чтобы не пересекать uplink)
- Backup scope: C:\sites\snolla + applicationHost.config + IIS native
Backup-WebConfiguration + cert store PFX export + sshd config
Decisions log в task file: tool=rclone (rejected restic encrypted-dedupe
как overkill для transitional setup, robocopy-over-SMB fragile);
SYSTEM-principal mirrors VDS root-cron pattern; PFX export pass=temp
'pfximport' (TODO: pass-equivalent на Windows когда найдём).
Open questions для решения user'а: when to start (recommend сейчас, не
ждать full cutover), kreknin SSH ACL add pubkey to authorized_keys
(требует user action).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Session 2026-05-23 evening → 2026-05-24: full snolla site migration
windows-recovery-host → RUVDS Win Server 2025 Core, partial DNS cutover для
1 prod hostname (kupimknigi.spb.ru), оставшиеся 24 hostnames pending.
What's live on RUVDS:
- snolla IIS site catch-all *:80: + 25 HTTPS SNI bindings (1 per hostname,
LE certs от 2026-04-23 / valid до 2026-07-22)
- 8.66 GB / 44725 files transferred via scp после ISP-block discovery
- ApplicationPoolIdentity + ACL grant verified
- HTTP/2 auto-negotiated, MSSQL/imgproxy/MinIO connectivity OK from RUVDS
Findings (Decisions log в task file для деталей):
1. Outbound 445 блокирует home ISP (не RUVDS FW) — `windows-server-2025-core-bootstrap.md`
SMB-section deprecated, SSH/scp = canonical transfer-метод.
2. Home network HTTP-middlebox mangles Host header в outbound external HTTP —
тест с source даёт garbled response; тест с VDS (третья сеть) даёт корректный.
3. traefik acme.json → IIS PFX recipe: extract base64 cert+key per cert →
openssl pkcs12 -export → Import-PfxCertificate + AddSslCertificate by
thumbprint with SslFlags=1 (SNI). Reusable, потенциально новый concept.
4. IIS 10 на Win Server 2025 говорит HTTP/2 by default через TLS.
5. 4 hostnames (maljarka.tandemmebel.ru + 3 rimiz) → 502/404 на RUVDS;
на source IIS:8089 возвращают 200 default-page. Pre-existing CMS-tenant
config gap, не migration defect.
Scripts added:
- scripts/iis-migration-to-ruvds/01-ruvds-bootstrap.ps1 (idempotent)
- scripts/iis-migration-to-ruvds/02-source-transfer.ps1 (не использовался —
SMB не работает; оставлен как reference)
- scripts/iis-migration-to-ruvds/README.md
Cleanup done:
- Plaintext PFX/PEM keys в C:\Users\vitya\iis-backup-pre-ruvds\certs\ удалены
(PFX import на RUVDS уже сделан, source-of-truth = traefik acme.json).
- `.secrets/` уже удалён ранее в этой session (см. предыдущий commit).
Source state: IIS:8089 + traefik routes ALIVE — rollback ready. Decommission
после 1-week soak с RUVDS как live prod.
Не push'нуто — ждёт user grant per project-discipline Rule 4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
