С 24 июня (минимум) publish-packages падает на каждом релизе main:
@coopenomics/sdk's prepublishOnly (pnpm run docs → generate-index-comments.ts)
читает components/controller/schema.gql, которого нет в чекауте и никто не
генерирует — ENOENT. lerna publish атомарный, поэтому НИ ОДИН пакет не
публикуется. Итог: main давно на v2026.7.9, а npm видел последний раз
2026.5.30-3 — полтора месяца фиксов (включая убранный kpp из
BankAccountDetailsInput, PR #81) не долетали до потребителей SDK.
Фикс: добавлен шаг generate-schema (изолированный, GraphQLSchemaBuilderModule,
без БД) ПОСЛЕ lerna run build — порядок важен, иначе ts-node падает на
устаревших dist соседних workspace-пакетов (проверено локально: cooptypes →
factory → inter → notifications, каждый был stale и валил компиляцию
controller'а по цепочке).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Паровоз dev→testnet→main заменён независимыми указателями: каждое окружение —
самостоятельный fast-forward-указатель на выбранный релизный тег dev. Прод и тест
катятся разным темпом и на разные версии одновременно, без диверджа и конфликтов
(оба — FF-указатели на линейную историю dev).
- promote.sh <testnet|main> [ref]: FF выбранного тега (по умолчанию — последний на
origin/dev) на ветку окружения; main больше не зависит от testnet; только вперёд.
- release.yaml: workflow_dispatch получил inputs environment+ref — откат на старую
версию / редеплой без бампа / hotfix в один контур (то, что FF не умеет). Сборка
идёт из вычекнутого ref, окружение — из inputs.environment. Авто-триггер по
изменению lerna.json сохранён.
- RELEASE.md: модель и инварианты переписаны под независимые указатели.
Принципы деплоя сохранены: бамп версии один раз на dev, образы по версии,
BUILD_MODE по окружению, webhooks per env, npm publish/доки только на main.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Релизный флоу переведён на линейную fast-forward модель — устраняет
регулярные конфликты на 20 package.json при релизе.
Корень проблемы: publish-alpha.sh/publish-prod.sh бампали версию НА КАЖДОЙ
ветке (alpha-N на testnet, чистую на main) через `git merge -X theirs` +
back-merge. Два независимых bump-коммита за цикл + merge'и плодили
расхождение веток → конфликты (особенно при гонке push/pull).
Новая модель:
- Версию бампает lerna ОДИН раз на dev (scripts/cut-release.sh).
- Тот же коммит едет вверх по FF: scripts/promote.sh testnet|main
(server-side fast-forward push, рабочее дерево не трогается).
- testnet/main не несут своих коммитов → ветки не диверджатся → конфликты
структурно невозможны.
release.yaml:
- Триггер: push в testnet/main с изменением lerna.json (вместо тега v*).
Окружение определяет ВЕТКА (main→prod, testnet→staging), не суффикс -alpha.
- Версия читается из закоммиченного lerna.json (едет с коммитом по FF).
- Гейты npm-publish/доки: branch == main (вместо !contains '-alpha').
- Образы/webhook по-прежнему версия-тегированы → playbooks/приёмник деплоя
не затрагиваются.
Удалены publish-alpha.sh/publish-prod.sh и мёртвые дубли тех же merge-X-theirs
скриптов (root sync:main, components/contracts production/testnet/docs-publish).
Документация — scripts/RELEASE.md + CLAUDE.md PR-flow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Релей переехал в отдельный репозиторий C9S/email-relay, собирается локально
плейбуком (playbooks/email-relay) — релиз mono его больше не пересобирает.
Прод-образ mono-base (prune --prod) не подходил для standalone-сервиса.
Удалено: components/email-relay, build_service в release.yaml, dev-сервис в
docker-compose. Контроллерный relay-режим (EMAIL_RELAY_URL/TOKEN в
email-channel.adapter + config) ОСТАЁТСЯ — он и активирует отправку через релей.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Хостинги коопов режут исходящий SMTP → письма controller'а уходят в timeout
(раньше хабом был Novu, его убрали). Новый компонент @coopenomics/email-relay
принимает письма по HTTPS с Bearer-токеном и форвардит по SMTP. Ставится на
сервер с открытыми портами (плейбук в playbooks/email-relay).
- components/email-relay: express + nodemailer, POST /send + GET /health,
Bearer-токен (constant-time), опц. IP-allowlist, конфиг из ENV
- controller: email-channel.adapter получил relay-режим — если задан
EMAIL_RELAY_URL, письмо уходит POST'ом на релей; иначе прямой SMTP как
раньше (opt-in, без регрессии)
- docker-compose: дев-сервисы email-relay + mailpit (SMTP-перехватчик для E2E)
- release.yaml: сборка образа dicoop/email-relay
E2E проверен локально: controller-формат письма → релей → SMTP → mailpit,
тело с <br> и заголовки целы; 401 на отсутствие/неверный токен, 400 на пустое тело.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Новый push в PR отменяет ещё бегущий typecheck той же ветки —
прежде 30-минутные прогоны копились очередью.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
При удалении publish-docs я снёс не только мёртвый gh-pages-push, но и реальную
публикацию ВТОРОЙ документации (доки mono) через DOCS_DEPLOY_WEBHOOK_URL —
она отдельная от coopenomics и должна уезжать синхронно. Возвращаю её отдельным
lean-джобом trigger-mono-docs (только webhook, без gh-pages и mkdocs-сборки —
приёмник деплоит сам).
Токен GITEA_DISPATCH_TOKEN → DOCS_DISPATCH_TOKEN: Gitea резервирует префикс
GITEA_ для имён секретов, такой секрет не создать.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Дефолтная ветка C9S/coopenomics — master; workflow_dispatch надо слать на
ref=master, иначе Gitea вернёт 404 по ветке.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
После переезда на Gitea два downstream-джоба были наследием GitHub:
- publish-docs пушил site/ в gh-pages github.com под secrets.GITHUB_TOKEN
(на Gitea — гитейный токен, невалиден) → Authentication failed. Pages
устарел, доки теперь деплоит C9S/coopenomics. Джоб удалён целиком.
- trigger-coopenomics-docs слал repository_dispatch на github.com через
peter-evans (COOPENOMICS_PAT пуст). Репо переехало в C9S/coopenomics на
Gitea, а Gitea не имеет API для repository_dispatch — только
workflow_dispatch. Заменено на curl к Gitea API workflow_dispatch с
secret GITEA_DISPATCH_TOKEN; целевой workflow получит входы mono_sha/mono_ref.
publish-packages не трогаю — там нужен лишь NPM_TOKEN в секретах (E404 на
scoped-пакетах = отсутствует npm-авторизация).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
registry-1.docker.io на runner'е изредка не резолвится (DNS-таймаут к
127.0.0.53), из-за чего push валит весь релиз уже после успешной сборки
образов. Обёртка dpush() повторяет push до 3 раз с паузой 10с во всех трёх
push-шагах (контракты, base, сервисы).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
clang-9 падал "error while loading shared libraries: libz3.so.4". Пакет cdt
объявляет только libcurl4-gnutls-dev, но бинари тулчейна (objdump -p NEEDED)
требуют libz3.so.4/libtinfo.so.6/libxml2.so.2/libz.so.1. В образе
dicoop/blockchain они были из сборки исходников, из .deb не тянутся —
ставим libz3-4 libtinfo6 libxml2 zlib1g явно.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Шаг компиляции контрактов в release.yaml падал под Gitea act_runner:
build-all.sh монтирует $(pwd):/project в sibling-контейнер, но job сам
исполняется в контейнере → хостовый демон не видит путь, /project пуст,
cmake падает "no CMakeLists.txt". Релиз не собирался зелёным (runs #144, #158).
- build_contracts_cdt.sh: чистый cmake/make без docker (общий источник флагов).
- build-all.sh: тонкая docker-обёртка над ним для локальной сборки.
- release.yaml: вместо pull образа + build-all.sh — установка cdt v4.2.0 .deb
в окружение job'а + симлинк /cdt/build → /usr/opt/cdt/4.2.0 (сводит хардкод
toolchain-путь CMakeLists без его правки) + вызов build_contracts_cdt.sh.
Компиляция в самом job-контейнере, без вложенного docker. sudo-агностично —
одинаково на GitHub-VM и Gitea-контейнере.
- Убран избыточный typecheck-гейт из release; typecheck.yaml остаётся PR-гейтом.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Trial run #148 (PR #30) упал в job controller на 37 TS2307 «Cannot find
module» для @coopenomics/{sdk,inter,notifications}. Локально маскируется
тем, что controller стартует через ts-node, который резолвит .ts напрямую
через tsconfig-paths/pnpm-симлинки и не зависит от dist/. tsc же ищет
types из package.json целевого пакета — а оно показывает на dist/index.d.ts
из unbuild.
Замена локального scoped-build на полный `pnpm lerna run build` (как в
корневом Dockerfile builder-стадии) собирает граф целиком и устойчиво
к добавлению новых workspace-пакетов. Добавляет ~2-3 мин ко времени job'а,
end-to-end оценочно ~21 мин (был 18 на сломанной версии).
build образов в release.yaml не ловит TS-ошибки: quasar build идёт через
esbuild с выключенным vueTsc в vite-plugin-checker (см. quasar.config.cjs),
а у controller'а build-скрипта вообще нет — `lerna run build` его молча
пропускает, в проде ts-node стартует и валится на типах только в рантайме.
Поэтому битый тэг мог уехать в DockerHub (кейс PR #392 / rename 1080→1020
в cooptypes — TS2551 в distribution-management проскочил именно так).
Новый reusable workflow .github/workflows/typecheck.yaml:
- desktop: build cooptypes/factory/sdk → quasar prepare → vue-tsc --noEmit --skipLibCheck
- controller: build cooptypes/factory → pnpm typecheck (tsc --noEmit)
- триггер pull_request на dev + workflow_call
В release.yaml добавлен job typecheck (uses: ./.github/workflows/typecheck.yaml),
release-job получил needs: typecheck. Downstream publish-packages /
publish-docs / trigger-coopenomics-docs через release автоматически в цепочке.
Push в dev/testnet/main НЕ триггерит — PR-гейта достаточно, тэги покрыты
через workflow_call. Если vue-tsc упрётся в OOM/таймаут на ubuntu-latest,
fallback на `pnpm --filter @coopenomics/desktop run typecheck` (без SFC).
Слияние в release.yaml через jobs+needs (последовательно):
- release (контракты+контейнеры+webhook, как раньше)
- publish-packages (если не -alpha) — был publish-packages.yaml
- publish-docs (не -alpha + main) — был publish-docs.yaml
- trigger-coopenomics-docs (не -alpha + main) — был build-contracts-docs.yaml
Удалено:
- build-contracts.yaml (ручной workflow_dispatch, сознательно вынесен из
релиз-пути после инцидента 2026-05-13, пользователем подтверждено удаление)
- publish-packages.yaml, publish-docs.yaml, build-contracts-docs.yaml
(содержимое перенесено в release.yaml как зависимые jobs)
Гейты унифицированы на !contains(github.ref, '-alpha') во всех publish-*
и trigger-* (раньше publish-docs/build-contracts-docs резали ещё
-beta/-rc/-test). IS_PROD в release-job остаётся на (alpha|beta|rc|test)
намеренно — webhook продакшна и тэг :latest должны быть строже.
Telegram-уведомления удалены из release.yaml и build-bootstrap.yaml.
Полагаемся на дефолтные email-уведомления Gitea-инстанса (mailer ENABLED=true).
Секреты TELEGRAM_BOT_TOKEN/TELEGRAM_CHAT_ID после merge можно удалить из репо.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
build-contracts.yaml — только workflow_dispatch (ручная пересборка
`dicoop/contracts:<branch>` для отладки на dev-ноде). Тэги обрабатывает
release.yaml атомарно (контракты + контейнеры + webhook), отдельная
сборка по push'у в ветку только давала вторую параллельную сборку.
publish-docs.yaml и build-contracts-docs.yaml — на push:tags v* с
gate-job'ом, пропускающим только продакшн-тэги (без -alpha/-beta/-rc/
-test) на main. Раньше docs пересобирались на каждый push в
main/testnet/dev/reports/marketplace2 — впустую.
Co-authored-by: coopops <coopos@coopenomics.world>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
build-contracts + build-containers через workflow_run упёрлись в:
(а) default-branch caveat (новая логика не активна, пока не в main),
(б) `${{ github.event.workflow_run.head_sha }}` иногда пуст в YAML-
выражениях — описание см. в шаге Resolve tag, инцидент v2026.5.14
не дёрнул PRODUCTION_WEBHOOK_URL.
Замена — один `release.yaml` на push тэга `v*`: резолвит ветку через
`git branch --contains`, собирает контракты → пушит
`dicoop/contracts:<branch>`, собирает базу + сервисные образы →
пушит `dicoop/<svc>:<tag>`, шлёт webhook. Гонок нет by construction.
`build-contracts.yaml` остаётся только на push веток для CI-
обновления `dicoop/contracts:dev|testnet|main` без релизного тэга.
Триггер `tags: ['*']` и логика резолва ветки через --contains
оттуда удалены — это теперь забота release.yaml.
Co-authored-by: coopops <coopos@coopenomics.world>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
После переключения build-containers с `push: tags` на `workflow_run`
обнаружился разрыв в миграционный период: на default-ветке (main) лежит
старый build-containers (с `push: tags`), на dev/testnet — уже новый
(с `workflow_run`). Push релизного тэга на коммит из dev/testnet НЕ
триггерит:
- старый build-containers в main: GitHub читает workflow definition
ИЗ КОММИТА тэга (где уже новая версия без `push: tags`);
- новый build-containers через workflow_run: триггер берётся из
default-ветки, где ещё старая версия без `workflow_run`.
В итоге для тэгов v2026.5.13-alpha-2/-3 build-containers не запустился
вовсе.
Фикс: workflow_dispatch с input.tag — позволяет руками запустить
сборку+деплой для любого выпущенного тэга. Логика resolve_tag
поддерживает оба источника. Это снимает блокер до мержа в main.
Использование:
gh workflow run "Build Docker Images" -f tag=v2026.5.13-alpha-3
После коммита 5735e1fc36 workflow стал триггериться на push тэгов,
но `Determine build mode and docker tag` использовал `github.ref_name`
напрямую, который для тэга = `v2026.5.13-alpha-2` → не матчит ни одну
из ветвей в `case` → workflow падает «Unsupported branch».
Фикс: для триггера по тэгу резолвим ветку через `git branch -r --contains
$SHA` (порядок: main → testnet → dev). Полная история нужна для
`--contains`, поэтому checkout с `fetch-depth: 0`. Семантику
build-режима несёт ветка, не имя тэга.
Раньше при релизе (`chore(release): publish` + git tag) запускались
параллельно `build-contracts.yaml` (push веток) и `build-containers.yaml`
(push тэгов). Поскольку контейнеры собираются ~8 минут, а контракты ~11,
build-containers финишил первым и слал webhook на тестнет за 2-3 минуты
до того, как build-contracts успевал запушить новый `dicoop/contracts:dev`
в DockerHub. Ансибл `setup-contracts.yaml` подтягивал ПРЕДЫДУЩИЙ образ
и через `cleos set contract` перетирал чейн старым wasm.
Инцидент 2026-05-13: walletop-фикс ledger2 (коммит 2e3410b830),
вручную задеплоенный 12-05, был откачен ансиблом ровно по этой
причине — ансибл подтянул контракты сборки 12-05 04:54 (sha de0f6c79,
до моего фикса).
Изменения:
- `build-contracts.yaml` дополнительно триггерится на push любого тэга
(без path-фильтра): нужен unconditional запуск, чтобы у workflow_run
всегда был upstream-завершение даже когда коммит ничего не правит
в `components/contracts/cpp/**`.
- `build-containers.yaml` переключён с `push: tags` на `workflow_run:
Build contracts container completed`. Внутри: резолв тэга через
`git describe --tags --exact-match $head_sha` — если на коммите тэга
нет (обычный push в ветку без релиза), no-op. Если есть — собирает
контейнеры и шлёт webhook ровно как раньше, но с гарантией что
`dicoop/contracts:<branch>` уже свежий.
Важно: workflow_run-триггер берёт definition из default-ветки (main),
поэтому новый build-containers.yaml начнёт работать только после мержа
этого коммита в main. До тех пор сохраняется старое поведение dev-ветки
(workflow_run от build-contracts на dev запустит build-containers из
main; если там старая версия — всё ещё через push: tags).
Без пина CI каждый раз тянул latest pnpm; на 10.4+ ignored builds
из warning стали ERR_PNPM_IGNORED_BUILDS, и `pnpm install --frozen-lockfile`
валился на electron/esbuild/@parcel/watcher и пр.
- packageManager=pnpm@10.33.0 в корневом package.json (синхронно с
publish-packages.yaml и components/boot/Dockerfile)
- pnpm.onlyBuiltDependencies — 18 пакетов из лога фейла
- Dockerfile: corepack enable вместо `npm install -g pnpm` (обе стадии)
- publish-docs.yaml: pnpm/action-setup@v4 без version + cache: pnpm
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
standards-site публикуется на gh-pages вместе с остальной докой. Чтобы
изменения стандартов из reports/marketplace2 попадали в превью на
docs.coopenomics.world/standards/, добавляем эти ветки в push-триггер.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
dicoop/mono-base тегается только под semver-релизы (build-containers.yaml
триггерится на refs/tags/*), поэтому :dev/:testnet/:main отсутствуют —
bootstrap workflow упал на pull этого тега.
Перепилил Dockerfile: COPY весь workspace из текущего checkout'а +
pnpm install --filter "@coopenomics/boot..." (тащит boot + транзитивные
cooptypes/factory). .dockerignore отрезает node_modules/dist/blockchain-data.
Workflow упростился — pull только dicoop/contracts, MONO_BASE_TAG больше
не нужен.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Цель: в соседних репозиториях (parser2, blockchain-protocol и т.д.)
для тестов и отладки нужно поднимать только цепь + контракты, без
mono-инфры (mongo/postgres/desktop). Решение — два контейнера в их
compose: dicoop/blockchain (нода) + dicoop/bootcoop (one-shot bootstrap).
Что добавлено:
- components/boot/Dockerfile — multi-stage от dicoop/contracts:<tag>
(контракты flat-layout в /contracts) + dicoop/mono-base:<tag>
(runtime с pnpm/node + workspace). ENTRYPOINT = pnpm run boot:remote.
CONTRACTS_DIR=/contracts выставлен по умолчанию.
- .github/workflows/build-bootstrap.yaml — push в dev/testnet/main
билдит и пушит dicoop/bootcoop:<branch> + :latest для main +
:<branch>-<short-sha> для пинов. Telegram нотификации.
- components/boot/README.md — раздел про sideboot с готовым compose
snippet'ом, переменными окружения и опциональными INSTALL_*_DATA.
Версионирование dicoop/bootcoop:<tag> совпадает с dicoop/contracts:<tag>
(multi-stage из того же тега) — контракты и bootstrap синхронны.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Boot — это и есть бутстрап. Дубликат через отдельный образ создаёт
второй workflow и две точки сборки там, где для testnet/prod достаточно
запустить existing pnpm -F @coopenomics/boot run boot:remote внутри
dicoop/mono-base:<tag>, который уже собирается через build-containers.yaml.
Что остаётся в dev (полезное из предыдущих коммитов):
- boot:remote команда — без dockerode, для сценария когда нода
поднята отдельным сервисом docker-compose.
- CONTRACTS_DIR env-driven path в configs/contracts.ts — позволяет
монтировать dicoop/contracts:<tag> как volume.
- "build" script в boot/package.json для unbuild.
Удалено:
- components/boot/docker/ (Dockerfile + entrypoint + bootstrap.package.json
+ bootstrap.pnpm-workspace.yaml)
- .github/workflows/build-bootstrap.yaml
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Симметрия с dicoop/contracts и остальными dicoop/* образами;
GHCR делает first-publish приватным и требует ручного visibility-toggle.
DockerHub-секреты DOCKERHUB_USERNAME / DOCKERHUB_TOKEN уже используются
build-contracts.yaml и build-containers.yaml.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Образ ghcr.io/coopenomics/bootstrap для one-shot первичного деплоя
контрактов на KE-узел в docker-compose. Соответствует решению из
project_ke_bootstrap_strategy: boot/contracts собираются в mono,
apps-catalog только потребляет готовые образы.
Состав:
- components/boot/src/index.ts — команда `boot:remote`: ждёт RPC
по CHAIN_URL, вызывает startInfra() через eosjs (без dockerode).
Опциональные initial-data/extra-data через env-флаги.
- components/boot/src/configs/contracts.ts — env-driven CONTRACTS_DIR.
Когда задан — flat layout /contracts/<name>/<name>.{wasm,abi}
(как в dicoop/contracts), иначе старые относительные пути.
- components/boot/package.json — script `build` (unbuild) +
`boot:remote` для локального запуска.
- components/boot/docker/Dockerfile — multi-stage:
deps → build (cooptypes/factory/boot) → pnpm deploy --prod →
COPY --from=dicoop/contracts:<tag> → node:20-alpine slim runtime.
- components/boot/docker/entrypoint.sh — режимы boot:remote / verify
/ shell + проверка обязательных env'ов.
- .github/workflows/build-bootstrap.yaml — публикация в GHCR по push
в dev/testnet/main + verify smoke-test после push'а.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Контракт `apps` (координационная плоскость для apps-catalog):
- 4 таблицы: packages, releases, subs, coops; ABI 21 KB, WASM 70 KB
- 11 actions: regpackage, transferpkg, setrelease, reactivate, withdraw,
cleanup, regsub, expsub, regcoop, setcoop, migrate
- subs.chain_id и coops.chain_id — каноническая идентификация подсети
- coops.signing_key — отдельный subnet-signing-key (не active),
ротация через setcoop без потери ранее выпущенных JWT
- releases с TTL retention 90 дней + inline cleanup до 50 записей
- atomic supersede в setrelease — выполняет FR8 «approve → ACTIVE»
на стороне blockchain'а
CI контейнер `dicoop/contracts`:
- упаковывает все 21 контракт (15 user + 6 system eosio.*) в alpine 10.8 MB
- список контрактов берётся из CMakeLists (single source of truth)
- триггер push на dev/testnet/main + workflow_dispatch
- маппинг ветка→tag: dev/testnet/main + sha-pinned tag для воспроизводимости
- manifest.json с sha256 каждого артефакта внутри образа
- entrypoint: copy [name] | manifest | sha256 | list | ls
- multi-stage потребление в ke-bootstrap = 0 MB на VPS
Закрывает блокер Story 6.x (KE bootstrap) для apps-catalog.
CI workflow «Publish Packages» падал на `pnpm install --frozen-lockfile`:
старая pnpm 8 не понимает lockfileVersion 9.0 (lockfile сгенерён локально
pnpm 10.33.0). На последнем production-релизе из-за этого failed check
заблокировал автомерж в main; merge пришлось делать с --admin override,
а сама публикация npm-пакетов из CI не выполнилась.
Прибиваем версию pnpm в action-setup к 10.33.0 — той же, что у user'а
локально. Комментарий обновлён: lockfileVersion 9.0 = pnpm 9/10
(старый комментарий говорил про 6.0/pnpm 8 — это уже не актуально).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
coopops
claude