admin/.tasks/NEXT_SESSION.md

_last_updated_, session_id

_last_updated_	session_id
2026-07-04T08:55:00Z	2026-07-04-tandemmebel-tirage-deploy-sharp-pivot

Next session handoff

Итог сессии — тираж tandemmebel доведён до sharp-staging-green, но ЗАБЛОКИРОВАН новым дефектом на визуальной проверке оператора

Роль всю сессию — ops-подхват на деплой тиража tandemmebel, координация с peer-сессией workshop через .claude-inbox/. Cutover DNS всё время gated оператором. Автопуш был разрешён — всё закоммичено+запушено (origin/master чист, HEAD 5be6662c + 2 доска-коммита сверху).

⛔ ГЛАВНОЕ ДЛЯ НОВОЙ СЕССИИ — новый дефект, специфики НЕТ

После того как я дал оператору staging-URL https://tandemmebel.vds.kzntsv.site на визуальную проверку sharp-сборки, оператор сказал: «они опять налажали, но уже в другом» — нашёл НОВЫЙ визуальный дефект (иной, чем прошлые), специфику не назвал, велел завершить сессию и чинить в новой.

• Первым делом в новой сессии: спросить оператора, ЧТО именно за дефект он увидел (какая страница/элемент). Не гадать.
• Мои автоматические curl-гейты по sharp-staging были green (media/watermark/variant-cache/parity/redirects/sitemap) → значит дефект визуальный, не ловится смоком (вёрстка/CSS/шрифт/раскладка/поведение JS). Sharp-staging жив на стеке 20 для разбора.
• Cutover DNS НЕ делать — held до фикса И до явной отмашки оператора.

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

• 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 обмены).