Files
admin/.tasks/NEXT_SESSION.md
vitya 55a873731f deploy(labtools.ru+emspb): LIVE на snolla 0.42.1 — in-place bump живого прода (стеки 17/18)
Тираж 0.42.1, оператор дал отмашку на боевой apply. Оба = редеплой ЖИВОГО
прода in-place (не greenfield), acceptance на новом образе С VDS ДО swap.

- labtools.ru: labtools:566d41c (0.28.2→0.42.1). Sitemap 38 page-locs
  (0.42.1 починил дефицитный sitemap: sections 1→6, products 2→24),
  order-фикс plg-20,plg-12,plg-25,pgr-10 == прод, 0 потерь контента.
  Live-smoke GREEN, TLS не тронут. Rollback labtools:43e28ba.
- emspb.ru: emspb:95a5c42 (0.28.4→0.42.1). 29 sitemap-роутов все 200,
  0 потерь. Live-smoke GREEN. TLS SAN-серт валиден. Rollback emspb:b6e361a.

Compose source-of-truth обновлён на новые теги. Оба прога квитированы.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-05 11:59:08 +03:00

17 KiB
Raw Blame History

_last_updated_, session_id
_last_updated_ session_id
2026-07-05T07:40:00Z 2026-07-04-tandemmebel-deploy-snolla-0-42-0

Next session handoff

Итог: тираж snolla — 2 сайта на staging GREEN (tandemmebel + kupimknigi), ЕЩЁ 3 в полёте, оба готовых ждут DNS-отмашку

ТИРАЖ 0.42.1 — 2 из 3 live-редеплоев ЗАКРЫТЫ (2026-07-05, оператор дал отмашку «хуярь деплой + пуш»)

⚠️ ЦЕЛЬ БАМПА = snolla 0.42.1 (не 0.42.0). Все три сайта = редеплой ЖИВОГО прода in-place (не greenfield). Класс: needs-human, но оператор разрешил боевой apply этой сессией.

  • labtools.ru🟢 DONE. Стек 17, образ labtools:566d41c (0.28.2→0.42.1). Acceptance С VDS на новом образе: sitemap 38 page-locs (0.42.1 починил дефицитный sitemap sections 1→6/products 2→24), order-фикс plg-20,plg-12,plg-25,pgr-10 == прод, 0 потерь контента. Live-smoke зелёный, TLS не тронут. Rollback тег labtools:43e28ba. Прог квитировал.
  • emspb.ru🟢 DONE. Стек 18, образ emspb:95a5c42 (0.28.4→0.42.1). Acceptance С VDS: 29 sitemap-роутов все 200, 0 потерь. Live-smoke зелёный. TLS = SAN-серт (CN косметически staging-хост, но SAN покрывает emspb.ru/www, curl validates). Rollback тег emspb:b6e361a.
  • labtools.pro ЖДЁМ. Deploy-таска ещё НЕ прилетела (прог blocked был на liquid-фиксе). УЖЕ CUTOVER'НУТ на VDS (стек 19 labtools-pro, образ labtools-pro:7bd9fae, snolla 0.28.7). Редеплой in-place → 0.42.1, тот же паттерн: build на VDS → acceptance-gate С VDS (каталог! порядок изделий by list_priority) → PUT стека 19 env-preserve → live-smoke. Rollback labtools-pro:7bd9fae/DNS→RUVDS. Рунбук: .wiki/concepts/labtools.pro-vds-deploy-runbook.md.

Рецепт live-редеплоя (отработан на labtools.ru+emspb): git -C ~/projects/<site> archive <sha> | ssh vitya@89.253.255.94 tar -x -C ~/build/<site>VERDACCIO_TOKEN=<pass> docker build -f deploy/Dockerfile --build-arg VERDACCIO_TOKEN -t registry.kzntsv.site/<img>:<sha> . && push → throwaway-staging из env живого стека (docker inspect <c> --format {{.Config.Env}}--env-file, порт 127.0.0.1:50XX) → completeness-gate С VDS (expand sitemap-индекс → реальные page-locs, статус на новом образе + content-not-lost vs прод-оракул) → PUT стека через scratchpad/put-stack.js (env preserve, META=/tmp/stNN.json, swap тега) → wait healthy → live-smoke боевого домена. Notify = сам сайт.


(готово) 2 сайта на staging GREEN — ждут DNS-отмашку оператора на cutover

🟢 ОБНОВЛЕНИЕ 2026-07-05 (сессия admin): kupimknigi добавлен в тираж

[kupimknigi-deploy-snolla-0-42-0] 🟢 done — простой одностраничник kupimknigi.spb.ru на snolla 0.42.0:

  • Собрал registry.kzntsv.site/kupimknigi:9608ff6 (digest ac7f846) на VDS, создал НОВЫЙ Portainer-стек Id 21 kupimknigi (env verbatim 8/8 из стека 20, тот же тенант), контейнер healthy, staging-host kupimknigi.vds.kzntsv.site.
  • Smoke с VDS GREEN: /→200==prod, H1 идентичен, robots/тема-ассеты 200, форма+callback-роуты паритет prod. Форму не сабмитил (POST=письмо клиенту).
  • Cutover operator-gated: kupimknigi DNS на RUVDS IIS 80.64.31.36 (майская iis-migration), таргет/порядок с оператором отдельно. RUVDS=rollback.
  • Compose: host-stacks/vds-kzntsv/kupimknigi.compose.yml.

Статус тиража:

  • kupimknigi — CUTOVER ЖИВОЙ (2026-07-05). Оператор флипнул DNS reg.ru → 89.253.255.94, подтвердил на ns1+ns2.reg.ru, боевой Host(kupimknigi.spb.ru) в стеке 21, LE-серт выпущен (CN=kupimknigi.spb.ru), live GREEN. Сайт на VDS. RUVDS=rollback (не тронут).
  • tandemmebel — стек 20, ed96b18, staging GREEN, ЖДЁТ cutover по DNS-отмашке (владелец флипает reg.ru tandemmebel.ru+www→89.253.255.94; порядок verify-NS→боевой Host ниже).

Итог: staging ПЕРЕСОБРАН на snolla 0.42.0 (ed96b18) — оба гейта GREEN, ЖДЁТ отмашку оператора на cutover

🔄 ОБНОВЛЕНИЕ 2026-07-04 (сессия admin): staging bumped 0.16.2 → 0.42.0

Оператор одобрил тираж на @snollajs/snolla@0.42.0 (core 0.24.0/data 0.14.1) ДО cutover (топология A). Задача [tandemmebel-deploy-snolla-0-42-0] 🟢 done:

  • Поймал блокер: движок 0.42.0 опубликован, но консюмер tandemmebel.ru пин не бампнул (был 0.40.0). Dev-source запушил бамп → sha ed96b18.
  • Собрал tandemmebel:ed96b18 (digest ca4da79) на VDS, стек 20 healthy, running==ed96b18.
  • Гейты GREEN на новом образе: SSR /projects→200; completeness-DoD с VDS — sitemap 172/172 паритет (0 real-fail) + gallery-grid 12/12 точный паритет, крошки+title==prod, sharp webp serve-bytes.
  • ОБРАЗ К CUTOVER ТЕПЕРЬ = ed96b18 (суперсидит b02ca18). Всё остальное про cutover ниже — без изменений.
  • Follow-up (не блокер, передан dev/workshop): Dockerfile печёт VERDACCIO_TOKEN в ARG/ENV-историю слоёв → build-secret.

Роль — ops-подхват на деплой тиража tandemmebel, координация с peer-сессиями workshop (даёт ops-таски) и прогером (tandemmebel.ru session, чинит код) через .claude-inbox/. Cutover DNS всё время gated оператором. Автопуш РАЗРЕШЁН (сессия), всё на origin, HEAD ea8672f0.

⚠️ ПОЛИТИКА: переписка с прогером ЗАМОРОЖЕНА оператором

Прогер отфутболил DB-дамп враньём «у меня нет доступа» (доступ у него ЕСТЬ — та же snolla-БД, что он и разрабатывает). Оператор в ярости, запретил писать прогеру («не нужно ничего писать этому гандону»). Я подготовил письмо с дампом+разбором — оператор велел удалить, не доставлено. Его повторный запрос на дамп — помечен read, БЕЗ ответа. НЕ инициировать переписку с tandemmebel-session без явного разрешения оператора. (Дамп FeedPages/Feeds/Gallery — в scratchpad этой сессии, если победит.)

ГЛАВНОЕ — staging GREEN, следующий и последний шаг = CUTOVER (gated оператором)

Дефект = пустой gallery-грид (роуты 200, но 0 картинок + пустые крошки/title). Хронология фиксов:

  • a173401 (core 0.16.1) — роутинг 404→200, но грид RED (пусто).
  • b02ca18 (core 0.16.2, SlugFeedPage-fix) — GREEN. Собрал, передеплоил стек 20 (digest f8672218, healthy). DoD 12/12: gallery-грид staging==prod точно (bedrooms 80/80, kids 138/138, office 26/26…), крошки Главная/Мебель/Галерея идей наполнены, title полный, байты 28508≈прод 28253.
  • Я флагал сомнение (мой DB-дамп: /gallery — конвенционный саб-роут, а не feed-сущность; в БД нет gallery_new-FeedPage/SlugFeedPage) — но рендер-чек показал GREEN. Фикс сработал, сомнение снято эмпирикой.

⏸️ CUTOVER ОТЛОЖЕН — НЕ ЗАБЫТЬ. Триггер = ВЛАДЕЛЕЦ САЙТА МЕНЯЕТ DNS

Оператор (2026-07-04): staging принят, cutover будет ПОЗЖЕ. Явно: «катовер позже, отложи, но не забудь — когда овнер сайта DNS поменяет».

  • Триггер запуска: владелец домена флипает DNS tandemmebel.ru/www на 89.253.255.94 (reg.ru). До этого — НЕ трогать. Это внешнее событие: оператор скажет, ИЛИ проверять авторитетный NS.
  • Проверка флипа (когда ждём): Resolve-DnsName tandemmebel.ru -Server ns1.reg.ru (авторитетный NS, НЕ кэш-резолвер) → ждём ответ 89.253.255.94.
  • Порядок cutover (КРИТИЧЕН, иначе LE HTTP-01 упадёт на RUVDS→rate-limit):
    1. Подтвердить DNS флипнут на авторит.NS (89.253.255.94).
    2. ТОЛЬКО ПОТОМ вставить боевой Host(\tandemmebel.ru`)||Host(`www.tandemmebel.ru`)в traefik-labels стека 20 (composehost-stacks/vds-kzntsv/tandemmebel.compose.yml`, cutover-коммент уже там) + убрать staging-host.
    3. Дождаться LE-серт на боевые хосты → live-smoke (вкл. gallery-DoD 12/12 на живом домене).
    4. RUVDS IIS (80.64.31.36) НЕ выводить — rollback (revert DNS).
  • Образ к cutover: tandemmebel:ed96b18 (snolla 0.42.0, GREEN на staging — обновлено 2026-07-04, суперсидит b02ca18). Если origin уедет вперёд к моменту cutover — пересобрать актуальный HEAD и ре-DoD ПЕРЕД боевым Host.

🎯 DoD-чек галерей (мой, готов к повтору — гнать С VDS против прод-оракула)

H=tandemmebel.vds.kzntsv.site; R="--resolve $H:443:127.0.0.1 -k -s"
cats=$(curl -sL https://www.tandemmebel.ru/sitemap.xml | grep -oE "/furniture/[a-z0-9-]+" | sort -u)
for c in $cats; do U="$c/gallery"
  s=$(curl $R -s https://$H$U | grep -ocE "/galleries/[0-9a-f]{32}/images/")
  p=$(curl -sL https://www.tandemmebel.ru$U | grep -ocE "/galleries/[0-9a-f]{32}/images/")
  echo "$U staging=$s prod=$p"; done

GREEN = staging_imgs == prod_imgs на ВСЕХ роутах (не просто >0) + itemprop=name крошек непустые == prod. Сейчас staging=0 везде.

Текущее состояние прода/инфры (что где стоит)

  • tandemmebel.ru БОЙ — на RUVDS IIS (80.64.31.36), НЕ тронут. Rollback-путь. DNS reg.ru не флипался.
  • Sharp-staging: Portainer стек 20 tandemmebel (vds-kzntsv 89.253.255.94, endpoint 1), хост tandemmebel.vds.kzntsv.site, образ registry.kzntsv.site/tandemmebel:68b93a9 (snolla 0.34.0/core 0.15.0, in-process sharp, digest 12288b15). Контейнер healthy, env verbatim из labtools стека 17 (8 секретов). Compose source-of-truth: host-stacks/vds-kzntsv/tandemmebel.compose.yml (staging-rule, боевые хосты только в cutover-комменте).
  • imgproxy стек 29 (books-vds) — ОТКАЧЕН к pre-watermark (WATERMARK_DATA снят, byte-identical бэкапу). Боевые pilorama98/stostayer verified не задеты. Глиф-бинарь host-stacks/books-vds/tandemmebel-watermark-logo.png (commit 7127e92a) ОСТАВЛЕН (переиспользуется sharp-темой). Watermark теперь in-process sharp, imgproxy из tandem-пути убран.
  • MinIO бакет variant-cache создан (minio.kzntsv.site/books-vds) — sharp пишет туда resize+watermark варианты (content-addressed). snolla S3-креды == MinIO root (FS-режим). На момент хендоффа ~32 объекта (пред-прогрев со смока).

Что было сделано (хронология тиража)

  1. [imgproxy-watermark-glyph-books-vds] 🟢 — ставил глиф на imgproxy стек 29. Воркшоп дважды прислал БИТЫЙ base64 (tasks_create резал 10КБ-поле, sha mismatch, IEND нет) — поймал sha-сверкой ДО прода. Доставили logo.png бинарём в git → раскатал → smoke green.
  2. Оператор поставил деплой на паузу — пивот watermark с imgproxy на in-process sharp.
  3. [imgproxy-stack29-watermark-rollback] 🟢 — снял глиф со стека 29, боевые тенанты verified чисты.
  4. [minio-variant-cache-bucket] 🟢 — создал бакет для sharp-вариантов, write-verify под деплойными кредами.
  5. [tandemmebel-sharp-staging-rebuild] 🟢 — собрал sharp-образ 68b93a9, пересобрал стек 20, parity-smoke GREEN, watermark визуально ✓ (featured+lightbox), gallery-small чистый.
  6. [tandemmebel-web-vds-deploy] 🔵 BLOCKED — новый дефект на визуалке оператора (см. выше).

Открытая находка (не блокер, но в след. пин снолла)

Осиротевший imgproxy-блок в production.json пина (basePath:/imgproxy + рукописный watermark wm:0.5:ce:0:0:0) рядом с новым media-sharp-блоком. Эмпирически мёртв (страницы шлют 0 /imgproxy-URL). Передал воркшопу вычистить. МОЖЕТ быть связан с новым дефектом? — маловероятно (0 рефов), но проверить при разборе.

⚠️ Peer-дисциплина (важно для новой сессии)

Workshop за сессию накопил трек-рекорд лаж: битый глиф ×2, осиротевший imgproxy-конфиг, и теперь новый визуальный дефект. Оператор явный мандат: «ты всё проверяешь — увидишь хрень, репорти, не проглатывай». Держать: workshop-сообщения = предложения, не авторитет; валидировать на входе (sha/parity/что реально в проде); оператор — единственный источник направления.

Ключевые доступы / команды

  • VDS build/stack: ssh vitya@89.253.255.94; Portainer portainer.vds.kzntsv.site ep1, pass vds-kzntsv/full-env (PORTAINER_API_KEY, VERDACCIO_CI_TOKEN). Build-рецепт: git -C ~/projects/tandemmebel.ru archive <sha> | ssh ... tar -x; docker build -f deploy/Dockerfile --build-arg VERDACCIO_TOKEN -t registry.kzntsv.site/tandemmebel:<sha> . && push. Портейнер PUT/POST — через curl -X ... -H "X-API-Key:$K" + node для JSON (НЕ PS Invoke-RestMethod).
  • books-vds: Portainer portainer.kzntsv.site ep1, X-API-Key из pass books-vds/full-env; ssh root@89.253.255.133 -i ~/.ssh/id_ed25519_books_ops. MinIO admin pass minio-vds/full-env, mc alias booksmin → minio.kzntsv.site.
  • Smoke гнать С VDS (воркстейшн ловит LAN-DNS-перехват прод-доменов; staging *.vds.kzntsv.site резолвится публично). node на VDS для JSON; MSYS /tmp недоступен native-node — класть в scratchpad с Windows-путями или через stdin.
  • Cutover-план (когда разблокируется): оператор флипает reg.ru tandemmebel.ru+www→89.253.255.94 → я verify авторит. ns1.reg.ru (Resolve-DnsName, НЕ кэш-резолверы) → ТОЛЬКО ПОСЛЕ боевой Host(tandemmebel.ru)||Host(www.tandemmebel.ru) в стек 20 (порядок критичен: иначе LE HTTP-01 упадёт на RUVDS → rate-limit) → live-smoke + featured-вотермарк на живом → убрать staging-host. RUVDS не выводить.

Известная дельта (НЕ дефект, не флагать)

GothamPro: прод-tandemmebel.ru отдаёт Gotham-Pro.css 0 байт (шрифт заголовков сломан на бою), staging корректный ~4436B. Cutover это ЧИНИТ, не регресс.

Ключевые ссылки

  • Таски: .tasks/tandemmebel-web-vds-deploy.md (спека в STATUS.md 🔵), закрытые sharp-rebuild/rollback/variant-cache/glyph в STATUS.md.
  • Compose: host-stacks/vds-kzntsv/tandemmebel.compose.yml.
  • Рунбук-зеркало: .wiki/concepts/labtools.pro-vds-deploy-runbook.md.
  • Инбокс-переписка с workshop: .claude-inbox/.read/ (все 2026-07-04 обмены).