Первая же версия имени выявила более глубокую проблему. Она использовала внутренний SKU вроде SKU-001, хотя на самой этикетке люди видели и использовали Batch No: 30267-0914. Скачивание работало, но семантика данных была неверной: система выбрала технически существующий, но бесполезный в работе идентификатор.

Адрес в Production

/tools/label/

Бизнес-идентификатор в имени файла

Видимый Batch No, если он задан

Пример

30267-0914-BQ.png · 30267-0914-BQ.pdf

Физический размер

Без масштабирования; 80×80 мм остаются 80×80 мм

Проверка пагинации

Шесть размеров дали по одной странице в Chromium

Имя файла — часть модели данных

Правильным решением была не ещё одна функция именования специально для скачивания. Имя файла и видимое поле Batch No теперь берут значение из одного canonical-источника. Если на этикетке стоит 30267-0914, для PNG предлагается 30267-0914-BQ.png, а для PDF — 30267-0914-BQ.pdf. Если эти значения расходятся, как минимум одно из них уже не описывает партию, которую видит пользователь.

Для PDF действует тот же принцип, но интерфейс браузера устроен иначе. В macOS при переходе из браузерной печати к Print → Save as PDF предлагаемое имя PDF берётся из заголовка печатаемого документа. Поэтому перед печатью document.title ненадолго заменяется на имя из Batch No, а после завершения, отмены или возврата управления окну обычный заголовок надёжно восстанавливается. Это не смена SEO-заголовка, а ограниченное состояние с явными границами одного сеанса печати.

Одна страница превратилась в одну страницу и пустой лист

Когда имена стали согласованными, проявился более интересный дефект: этикетка 80×80 мм давала в предпросмотре две страницы, причём вторая была пустой.

Кажется очевидным, что лист 80×80 мм должен помещаться на странице 80×80 мм. Но движок браузера не сравнивает два целых значения в миллиметрах. CSS-миллиметры превращаются в CSS-пиксели, а печатный конвейер ещё раз переводит их в единицы устройства и пагинации. На границе страницы субпиксельное округление, стандартный строчный блок или небольшой вклад body могут вытолкнуть математически «точный» край в следующий pagination fragment.

Исходный print sheet имел размеры страницы, но всё ещё участвовал в обычной пагинации документа. Скрыть только #root было недостаточно: такой подход предполагал, что ни один другой дочерний элемент body не повлияет на печатную раскладку. Для точной границы страницы эта гарантия слишком слабая.

Исправляем пагинацию, а не размер этикетки

Правильное исправление изолирует print sheet от обычного потока пагинации. Печатные стили строго убирают все непечатные дочерние элементы body, обнуляют margin, padding и вклад строчного блока у html и body, а единственный печатаемый лист абсолютно позиционируют в начале страницы. Точное динамическое правило по текущей этикетке сохраняется:

@page { size: <width-mm> <height-mm>; margin: 0; }

Мы намеренно не использовали масштаб 99%, не вычитали по 1 мм из каждой стороны и не переносили этикетку на A4 с опцией «вписать в страницу». Такие приёмы могли бы убрать пустой лист, но одновременно нарушили бы главный контрак вывода. Этикетка 80×80 мм должна физически оставаться 80×80 мм.

Редактор и предпросмотр экспорта можно увеличить до 150%, чтобы с ними было удобнее работать, но это только способ показа. Canonical geometry и число пикселей не меняются: 100×100 мм по-прежнему экспортируются как 1000×1000 px, а 70×20 мм — как 700×200 px. Больший вид на экране не означает больший размер на бумаге.

Как отличить исправление пагинации от удачного исключения

Проверять только 80×80 мм было нельзя: специальный случай для одного размера легко создаёт убедительную, но хрупкую иллюзию. Проверка пагинации Chromium охватила 70×20, 70×40, 80×60, 80×80 и 100×100 мм, а также нестандартный размер 93×57 мм. Все шесть вариантов дали ровно одну страницу.

Автоматизированная среда не могла напрямую прочитать счётчик страниц в нативном предпросмотре печати macOS. Границу доказательств нужно формулировать точно: автоматика доказала, что печатные документы Chromium во всех шести размерах одностраничны; она не имитировала чтение недоступного значения из нативного UI.

Последний шаг произошёл за пределами браузера. После проверки print hotfix в Production содержимое проверенной ветки было сверено и возвращено в GitHub main, так что source tree и Production tree совпали. Это закрытие не позволит уже исправленной ошибке вернуться при следующем развёртывании из неполного исходного состояния.

«Скачивается» ещё не значит «готово», как и «печатается». Готово — это когда источник данных, имя файла, физические размеры, пагинация и исходники Production согласованы между собой.

Это изменение архитектуры и продуктовой стратегии, а не отказ от WEOUR OS.

Дата решения

2026-10-03

Что прекращаем

Повторно разрабатывать заказы, запасы, закупки, складской учёт и финансы — базовые функции, значительная часть которых уже покрыта зрелыми ERP-системами

Системы учёта (system of record)

ERP и маркетплейсы — там, где данные изначально принадлежат им

Чем становится WEOUR OS

Мультиплатформенные операционные данные · достоверная аналитика · поддержка решений · control tower · AI-агенты

Что это за заметка

Запись стратегического решения, а не анонс релиза

С чего мы начинали

WEOUR OS задумывалась широко: одна система, которая понимает магазины, листинги, товары, склады и остатки так, как на самом деле устроен наш бизнес на нескольких маркетплейсах. Предыдущие заметки в этом журнале описывают эту работу: магазины с общим каталогом, но раздельными запасами, реальные складские ячейки, учётный Ledger и правило, по которому неизвестный остаток никогда не превращается в ноль.

Эта работа не прошла впустую. Она показала, где на самом деле находятся сложные задачи. И нагляднее любого плана показала другое: значительная часть полноценной Commerce OS состоит из задач, которые уже хорошо изучены и решены зрелыми системами.

Что изменилось

Когда мы перешли от описания к разработке, закономерность стала очевидной. Заказы, движение запасов, закупки, склад и финансы — большие, требующие аккуратности и давно изученные области. Зрелые ERP-системы, в том числе Lingxing, уже покрывают значительную часть базовых возможностей в этих областях и накопили большой опыт обработки пограничных случаев из реальной практики.

Каждая неделя, потраченная на повторную реализацию этих функций, уходила на то, чтобы догнать уже существующий продукт. В лучшем случае мы получили бы копию того, чем и так можем пользоваться. В худшем — второй источник истины для одного и того же заказа или одного и того же остатка. А именно такую неоднозначность WEOUR OS и должна устранять.

Поэтому мы остановились. WEOUR OS не будет заново разрабатывать типовые функции ERP, если нет задокументированной причины, по которой существующая система не закрывает конкретную потребность.

Почему это правильный выбор

Время инженеров — самый дефицитный ресурс. Важно не то, что мы в принципе можем построить, а то, где разработка создаёт ценность, которую больше никто не даст.

ERP отлично фиксирует то, что произошло в её собственных границах. Маркетплейс отлично отчитывается о том, что произошло на его площадке. Но ни та, ни другая система не рассчитаны на вопросы, из которых состоит ежедневное управление мультиплатформенным бизнесом: каким цифрам можно доверять прямо сейчас, где данные площадок расходятся, какое отклонение требует внимания в первую очередь и что с этим делать.

Эти вопросы лежат между системами. Именно здесь WEOUR OS может быть по-настоящему другой.

Чем становится WEOUR OS

Меняется сама форма системы: вместо ещё одной «всё-в-одном» платформы для торговли — слой поверх систем, на которые мы уже опираемся:

ERP + маркетплейсы  →  слой аналитики и управления WEOUR OS  →  решения людей и агентов

На практике это задаёт пять направлений дальнейшей работы. Именно направлений, а не пяти уже готовых возможностей:

• Мультиплатформенные операционные данные. Данные из ERP и с каждого маркетплейса сводятся в единую нормализованную картину, при этом сохраняются исходная запись и её происхождение.
• Достоверная аналитика. У каждого показателя есть свежесть и полнота. Неполные данные помечаются как неполные, а неизвестное никогда не выдаётся за ноль.
• Поддержка решений. Прибыльность, отклонения и прогнозы подаются как решения, которые нужно принять, а не как очередные отчёты.
• Control tower. Одно место, где видно состояние бизнеса на всех площадках и что требует внимания в первую очередь.
• AI-агенты. Агенты работают на проверенных данных и действуют в явно заданных границах прав доступа и аудита. Операции с высоким риском и ключевые управленческие решения требуют разрешения человека.

ERP и маркетплейсы остаются системами учёта там, где это уместно. Подключение к ERP сейчас начинается в режиме только для чтения: WEOUR OS читает, объясняет и сверяет данные, но ничего не записывает обратно в систему, которой принадлежит запись. Это отправная точка интеграции, а не признак того, что она завершена.

Чего это не означает

Это не значит, что WEOUR OS начинается с нуля. Работа над идентификаторами, семантикой запасов, provenance данных и безопасностью релизов продолжается — именно она делает межплатформенные данные заслуживающими доверия.

Это также не значит, что новый слой уже готов. Значительная часть описанных здесь возможностей — поддержка решений, control tower, агенты — пока направление, а не функции, готовые к работе в production. Когда они появятся, мы зафиксируем их в этом журнале с тем же уровнем доказательности, что и всё остальное.

Ценность WEOUR OS не в том, чтобы иметь больше всех функций, а в том, чтобы превращать данные разных систем в решения, которым можно доверять, которые можно объяснить и на основе которых можно действовать.

WEOUR OS не нужно становиться заменой ERP. Ей нужно стать надёжным интеллектуальным слоем между ERP, платформами и людьми, которые управляют бизнесом.

До этого мультиплатформенное подключение и доказательства каталога, приём данных Yandex и единый аналитический контур продвигались разрозненно. Цель этого события — соединить их в одну цепочку: чтобы Ozon и Yandex использовали один и тот же факт заказов, а не поддерживали каждый свой контур.

Другой мотив — чётко обозначить границу. Код, связанный с планировщиком, уже вошёл в развёрнутый артефакт, но «код развёрнут» и «запущен в production по плану» — это две разные вещи. В этой записи последнее намеренно оставлено незаполненным, чтобы не описывать невключённую возможность как завершённое рабочее состояние.

Что изменилось

Изменения сосредоточены в нескольких блоках: подключение каналов, операционная аналитика и слой адаптации платформы Yandex — страницы каналов и аналитики в консоли, библиотека аналитики, библиотека каналов, слой адаптации платформы Yandex и серверная логика.

На стороне данных в каталог добавлено ограничение внешнего ключа, защищающее доказательства наблюдений и при этом не блокирующее сами строки задач — у этого ограничения есть соответствующее тестовое утверждение. На стороне каналов выполнен раунд исправлений RC, охватывающий приёмку, связанную с подключением магазинов, часовые пояса, общие ключи и список разрешённых PII.

На стороне документации зафиксированы два развёртывания: одно — развёртывание кода планировщика Yandex V1 и производственное наблюдение P5, другое — интеграция основного аналитического контура Yandex. Оба развёртывания записаны в обзорном документе.

Конкретные версии, коммиты, развёрнутые артефакты и дайджесты, количество тестов, состояние runtime и счётчики корпуса — см. facts выше.

Версия

20260926-yandex-sched-add2ba4 / 20260926-yaxan-1771e0c

Основной коммит релиза

025b05e54469a5e8ab636915322cbe478f73131e

Production provenance (коммит)

025b05e54469a5e8ab636915322cbe478f73131e

Развёрнутый артефакт

20260926-yandex-sched-add2ba4 (записано в docs/00-overview/CURRENT_STATE.md); 20260926-yaxan-1771e0c (записано в docs/00-overview/CURRENT_STATE.md)

Количество тестов

см. утверждение внешнего ключа каталога в коммите df4bb40802d4f0ee6af67d3bf7e09d74d39e7b5e

Состояние runtime

код планировщика развёрнут, не включён

Текущий авторский корпус

8 заметок / 24 variant (из них 1 ещё не опубликована)

Как мы это проверили

Проверка велась на трёх уровнях. Первый уровень — сам коммит: основной коммит релиза и коммит production provenance указывают на один и тот же SHA, что говорит о соответствии записи и развёрнутого артефакта.

Второй уровень — тесты: изменение внешнего ключа каталога сопровождается утверждением, проверяющим, что оно защищает доказательства наблюдений и при этом не запирает строки задач.

Третий уровень — документация: у каждого из двух развёртываний есть свой release id и дата записи, и они находятся в обзорном документе; архитектурный документ отдельно описывает дизайн планировщика заказов Yandex V1.

Что это не значит

Это не значит, что планировщик уже работает в production по плану. Код, вошедший в развёрнутый артефакт, и планировщик, который включён, поставлен в расписание и наблюдается как стабильно работающий, — это выводы разных уровней.

Это также не значит, что мультиплатформенное подключение завершено. Это событие подключило факты заказов Ozon и Yandex к единому контуру, но охват подключения, последующие платформы и операционные процессы не входят в эти доказательства.

Это равным образом не значит, что корпус полон. По состоянию на текущий момент в репозитории всё ещё есть неопубликованные заметки; счётчик корпуса — это состояние репозитория, зафиксированное в момент написания, и последующий рост репозитория не изменит смысл этого числа.

Область этого раунда

Производственная инфраструктура (запись о строительстве этого раунда): резервное копирование · планирование · публикация · откат

Ритм резервного копирования

Раз в 6 часов (таймер launchd)

Контракт успешного резервного копирования

Четыре шлюза: stream / decrypt / structure / durable

Градация здоровья резервного копирования

HEALTHY ≤ 7 часов · DEGRADED ≤ 12 часов · STALE > 12 часов (FAILED означает неудачу отдельной попытки, а не уровень)

Бюджет stagger планировщика

По умолчанию 30 секунд (нижняя граница 0 / верхняя граница 60), развязан с интервалом tick

Планировщик tick P50 (4 магазина)

119.5 s → 31.9 s

Планировщик tick P95 (4 магазина)

369.9 s → 55.3 s

Загрузка планировщика (duty cycle)

83.7% → 17.1%

Выборка приёмки планировщика

11 tick (4 магазина)

Первый Trial canonical-развёртывания

2026-09-23 неудача, конвейер выполнил откат

Производственная проверка этого раунда

release 20260923-rpg13-7f685ca (CANONICAL, validation / smoke PASS)

Тесты управления публикацией

123 → 157

Состояние хранения на момент наблюдения этого раунда

release 19 · кандидатов на удаление 1 · источник неизвестен 6 · защищено 5 (retention dry-run)

Коммит исправления планировщика

Anxin360/weour-os@e92b059

Коммит исправления readiness / iowait

Anxin360/weour-os@d4cbe01

Верхушка ветки trial Foundation V1.1

Anxin360/weour-os@b8cc817

Коммит управления V1.3

Anxin360/weour-os@7f685ca

Почему сначала остановили новые функции

WEOUR OS уже работает в production с реальными данными: реальные магазины, реальные циклы планировщика, реальные записи о публикациях. Чем больше функций, тем выше цена ошибки; но до этого несколько вещей не были по-настоящему замкнуты:

• неизменяемые release только накапливались, диск сам не становился чище;
• резервные копии были, но «действительно ли эта копия успешна» не проверялось автоматически, и не было сигнала здоровья, который можно было бы автоматически потреблять;
• планировщик выглядел занятым, но занят он был в основном не бизнес-работой.

Это не проблемы функций, а проблемы способа работы. Сначала их исправить — и каждая следующая функция обойдётся дешевле.

Что изменилось

1. Хранение release: неизменяемым release нужна управляемая очистка

Публикация — это неизменяемая цельная сборка: переключение делается символической ссылкой на новый каталог release, откат — переключением обратно на старый каталог. Такая схема делает откат дешёвым, но ценой постоянного роста диска — при аудите каталоги release занимали около 74% использованного диска этой машины (44.12 GB / 59.44 GB использовано), а на том же диске ещё нужно оставлять запас для сборки.

Поэтому очистка была написана как приоритет категорий, а не «удалить самое старое»:

CURRENT > IMMEDIATE_ROLLBACK > DIAGNOSTIC > FAILED_TRIAL > VALIDATED_ANCHOR
      > MIGRATION_BOUNDARY > MANUAL_PROTECT > UNKNOWN_PROVENANCE > ROUTINE

Только ROUTINE попадает в повседневную квотную очистку, остальные категории не удаляются попутно. Особенно важна одна из правил: release неудачного Trial не понижается до ROUTINE только потому, что его commit позже попал в main. Решение принимается только по доказательствам жизненного цикла, а не по имени каталога, временной метке или переписке.

2. Резервное копирование: от «есть копия» к «проверяемой копии»

Форма резервного копирования не переделывалась: хост резервного копирования сам забирает данные, production предоставляет только ограниченный поток принудительных команд, а закрытый ключ для расшифровки никогда не попадает на production-хост. Изменения произошли на стороне забора:

• Ритм и RPO: раз в 6 часов (таймер launchd), целевой RPO — 6 часов. Ритм объясним и не зависит от дрейфующего интервального таймера.
• Четыре шлюза: запуск считается успешным только после прохождения всех четырёх шлюзов — stream, decrypt, structure, durable. Код выхода pg_dump, равный 0, сам по себе никогда не является успехом.
• Неудача есть неудача: при провале любого шлюза запуск получает FAILED, last-success не обновляется, очистка не выполняется.
• Градация здоровья: HEALTHY (≤ 7 часов) / DEGRADED (≤ 12 часов) / STALE (> 12 часов) выводится из «часов с момента последнего успеха» и может потребляться мониторингом напрямую как код выхода; FAILED описывает отдельную попытку, а не уровень.
• Тесты с внедрением отказов: покрывают удалённый отказ, слишком маленький артефакт, ошибку расшифровки, недопустимую структуру, наложенный запуск, устаревшую блокировку, политику хранения и повреждённое состояние здоровья.

Последний шаг — вернуть сигнал здоровья в production: после прохождения четырёх шлюзов хост резервного копирования через ограниченную учётную запись отправляет снимок в production; эта учётная запись может писать только один фиксированный файл, не может переключать release, не может перезапускать сервисы и тем более не может читать какие-либо ключи.

3. Планировщик: разделить семантику tick и stagger

Диагностика сначала дала неудобный вывод: в интервале работы 4 магазинов 96.8% настенного времени tick уходило на детерминированный stagger-сон — из 2610 секунд 84 секунды были реальной работой. В расчёте на каждое action сам сон занимал 4150 секунд/час, почти 115% настенного времени.

Корневая причина — смешение семантики: окно stagger было привязано к интервалу tick (180 секунд), а фиксированные задержки нескольких action на одном последовательном runner складывались последовательно.

Исправление разделило две вещи: интервал tick используется только для отчётного cadence и больше не участвует в расчёте stagger; у stagger есть собственный бюджет, по умолчанию 30 секунд, допустимые значения 0 / 30 / 60, недопустимые значения откатываются к значению по умолчанию. Измерения после развёртывания:

• tick P50 119.5 секунды → 31.9 секунды, P95 369.9 секунды → 55.3 секунды;
• загрузка (duty cycle) 83.7% → 17.1%;
• запланированный сон совпадает с фактическим, остальное время — объяснимая работа с API и DB;
• timer, cadence, переключатели магазинов и бюджет параллелизма не менялись.

4. Единый canonical-конвейер публикации

Публикация — больше не цепочка ручных команд, а упорядоченный воспроизводимый конвейер:

provenance → preflight → release lock → scheduler quiet window → source
  → build backend → monitored build → immutable release + manifest
  → candidate validation → rollback readiness → atomic switch → restart
  → readiness → functional smoke → state write → history → retention dry-run

Несколько мест сделаны намеренно: сборка выполняется только в тихом окне планировщика; переключение атомарно; цель отката проверяется до и после переключения; код выхода systemctl restart явно записывается как «юнит запущен», а не «приложение готово».

5. Первый Trial провалился — и был полностью сохранён

Первый Trial canonical-развёртывания прошёл свой путь успеха, затем провалился на этапе smoke, и конвейер выполнил свой canonical-откат.

Причина не в приложении: systemctl restart при возврате означает лишь, что юнит запущен, а не что порт уже привязан. Тогдашний smoke был немедленной HTTP-проверкой без какого-либо ожидания readiness, поэтому он увидел отказ соединения и ошибку шлюза.

Важен именно способ обработки: никто не обошёл конвейер, чтобы вручную исправить этот шаг. Конвейер остановился по своему контракту отказа и выполнил откат, этот release был сохранён для диагностики, а на этапе очистки не было выполнено ни одного удаления. Production продолжал нормально обслуживаться на release до переключения.

Последовавшее исправление сделало readiness ограниченным опросом, а мониторинг сборки — реально измеряющим iowait. При повторном прогоне прежний режим отказа был корректно поглощён новой логикой как временная неготовность, а не как неудача развёртывания.

6. Управление: оставить доказательства и «кто может публиковать», и «что было опубликовано»

Правила этого раунда добавлены для будущих себя:

• canonical deploy only: повседневная публикация идёт только через конвейер; исключения должны быть явно помечены.
• deploymentMethod: каждая новая запись жизненного цикла несёт перечисление метода, исторические записи дописываются, а не переписываются; неопределимые исторические записи помечаются UNKNOWN_LEGACY и никогда не угадываются как CANONICAL.
• Классификация неудачного Trial: FAILED_TRIAL определяется по доказательствам жизненного цикла и не занимает повседневную квоту очистки.
• Приоритет диагностических доказательств: перед удалением нужно записать обратно диагностическую запись уровня KB без ключей и проверить её; если записать не удаётся — удаление отклоняется.

На точке наблюдения этого раунда (production release 20260923-rpg13-7f685ca) политика хранения представлена в dry-run: запись показывает 19 release, из них 1 кандидат на удаление, 6 с неизвестным источником, 5 защищённых. Очистка происходит только при полных доказательствах (цель подтверждена как неиспользуемая, диагностическая запись записана обратно и проверена).

Как мы это проверили

Способ проверки каждого звена по возможности опирается на перепроверяемые доказательства, а не на «выглядит нормально»:

• резервное копирование проверено тестами с внедрением отказов и реальными прогонами четырёх шлюзов, сигнал здоровья потребляется мониторингом;
• исправление планировщика сначала смоделировано в изолированной среде с измеренными offset, затем после развёртывания сравнено до и после на 11 реальных tick;
• конвейер публикации проверен тем, что ему дали самостоятельно выполнить реальную публикацию: readiness пройден, functional smoke прошёл по шести маршрутам, состояние записано конвейером, и только затем выполнен dry-run retention;
• правила управления покрыты тестами — от «неудачный Trial не понижается» до «публикатор отклоняет аномальную нагрузку».

Что это не значит

Это не выпуск функций и не означает, что инфраструктура завершена.

В записи этого раунда ограничения резервного копирования прописаны явно: ключ расшифровки существует в единственном экземпляре и находится на той же машине, что и шифротекст; нет второй копии в другом месте; нет PITR, RPO — это и есть ритм в 6 часов; у резервного копирования медиа нет политики хранения; роли и глобальные объекты не входят в dump. Это известные компромиссы, а не проигнорированные детали.

Исправление планировщика решает только вопрос «куда уходит время», это не оптимизация параллелизма или производительности.

Управление также не покрывает всю историю: на точке наблюдения этого раунда всё ещё существуют старые release с неопределимым источником, они консервативно сохранены.

Эта запись относится к раунду строительства с 2026-09-22 по 2026-09-23. Все производственные состояния в тексте — факты на точке наблюдения этого раунда, а не текущее состояние в любой последующий момент; последующие производственные изменения вне рамок этой статьи.

И наконец, это не обещание будущих версий, сроков или возможностей. Здесь записано уже произошедшее обновление инфраструктуры и доказательства, которые его подкрепляют.

Где доказательства

Каждое фактическое утверждение в этой записи указывает на объект, который можно перепроверить: соответствие коммитов, идентификаторов развёрнутых release и количества тестов зарегистрировано в таблице фактов выше, а также в evidence-записи этой статьи. Основной текст лишь объясняет смысл и не повторяет перечень идентификаторов.

До этого публикация контента Build зависела от ручного суждения: соответствие контента требованиям, полнота структуры и корректность чтения runtime после публикации не имели единых точек проверки. Как только формат контента расходился с ожиданиями runtime, проблема обычно обнаруживалась только после публикации.

Цель этого изменения — не добавить функциональность, а превратить «можно ли публиковать контент» в вопрос, на который можно ответить до публикации: контент сначала проходит проверку контракта, затем CI-шлюзы и только потом попадает в процесс публикации.

Что изменилось

Изменения сосредоточены в нескольких взаимосвязанных частях: workflow, каталог контента, документация, модуль контента runtime, скрипты и тесты.

На стороне контента введены определения schema и topics, которые делают явной связь между заметками, variant и topic; на стороне скриптов выполняется проверка контента по контракту; на стороне тестов покрываются оба пути проверки — PHP и Node; на стороне workflow предпросмотр и шлюзы связываются в цепочку, так что до публикации необходимо пройти проверки.

Сама публикация завершается одним развёртыванием в production; запись о развёртывании вносится в документацию репозитория и помечается соответствующей меткой проверки. Конкретные версии, коммиты, дайджесты артефактов, количество тестов и счётчики корпуса см. в блоке facts выше.

Как мы это проверили

Проверка состоит из двух уровней. Первый уровень — автоматические проверки: два набора проверок, PHP и Node, выполняются в CI, и настроено несколько шлюзов, продолжение возможно только после прохождения всех. Второй уровень — проверка в production: после развёртывания артефакта в production runtime сообщил о своём состоянии и объёме загруженного контента.

Нужно различать два среза корпуса на разные моменты времени:

• Производственный корпус на момент развёртывания 1.3.5 | 5 заметок / 15 variant / 13 topics
• Текущий авторский корпус | 6 заметок / 18 variant (из них 1 ещё не опубликована)

Первое — снимок runtime на момент развёртывания, второе — текущее состояние контента в репозитории. Их несовпадение нормально: в репозитории могут быть ещё не опубликованные черновики.

Версия

1.3.5

Основной коммит релиза

57bf785a0bcd6e886397de776cbe7bd7156fd64c

Production provenance (коммит)

4b4ec32a3aac70a8222ca7255f0db38fb6683200

Развёрнутый артефакт

weour-core-1.3.5.zip

SHA-256 артефакта

f660c0d9b48cbe774a3ba10d380eedfbf9a4fee5cf1a49c97c024ee7c1ee28ab

SHA-256 манифеста плагина

952f570124787702fc8c71ce6ebd5410dca3099730b212d805189f3764d2a703

Среда развёртывания

production

Состояние развёртывания

deployed

Состояние runtime

ready

Версия runtime

1.3.5

Число модулей runtime

12

Количество тестов

PHP 1100 проверок / Node 97 проверок

Число шлюзов

5

Производственный корпус на момент развёртывания

5 заметок / 15 variant / 13 topics

Текущий авторский корпус

6 заметок / 18 variant (из них 1 ещё не опубликована)

Что это не значит

Это не значит, что публикация контента с этого момента не требует ручного суждения. Конвейер проверяет контракт и структуру, а не то, уместен ли сам контент и стоит ли его публиковать.

Это не значит, что весь контент в репозитории уже опубликован. Текущее количество контента в репозитории больше, чем количество в runtime на момент развёртывания; разница — это ещё не опубликованные черновики.

Это также не значит, что данный процесс охватывает все будущие формы контента. Эта проверка относится к текущему контракту контента и пути чтения runtime; формы за пределами контракта в объём этой проверки не входят.

Наконец, это не является обещанием относительно последующих версий, сроков или возможностей. Здесь зафиксированы одна уже состоявшаяся публикация и проверка, а также подтверждающие её доказательства.

Эта запись — момент, когда это изменилось. Запись реестра №1 — первая в WEOUR OS, где реальный физический пересчёт стал записанным запасом в форме, которую можно проверить позже.

Что было до реестра

К тому моменту два реальных склада уже были смоделированы, а их активные ячейки заменены на проверенные физические — те 1 306 ячеек из предыдущей записи. Маркетплейсы и каналы сообщали то, что видели. Ничто из этого не равно тому, что WEOUR знает.

Наблюдаемые запасы — это доказательство. Это то, что источник сообщил нам, в определённый момент, со своей точки зрения. Центральный реестр — другое: это место, где WEOUR решает, чем владеет, и он заслуживает этот статус только тогда, когда его можно проследить до физического факта.

Что на самом деле меняет первый пересчёт

Пересчёт — это не синхронизация. Это человек, который стоит перед ячейкой и подтверждает, что там находится. Когда результат попадает в реестр, впервые становятся возможны три вещи:

• число существует потому, что кто-то его посчитал, и за ним стоят область, время и место;
• разница между тем, что система показывала раньше, и тем, что найдено физически, становится записываемым движением, а не загадкой;
• последующие наблюдения можно сравнивать с решением, а не друг с другом.

Реальных складов в области пересчёта

2

Активных складских ячеек

1 306

Первая запись

Входящий остаток по результатам пересчёта

Движение в реестре

OPENING_BALANCE +55

Автоматические записи запасов

Нет

Требование утверждения

Явное, по каждому классу движений

OPENING_BALANCE +55 — это бухгалтерское движение, а не сигнал спроса. Оно фиксирует, что посчитанная реальность и реестр впервые согласны по числу в этой области. Мы публикуем его потому, что именно такие движения центральный складской контур обязан уметь объяснять месяцы спустя, — и потому что придумать более опрятное число означало бы уничтожить смысл всей затеи.

Правила, которые это позволили

Пересчёт можно было внести только потому, что в системе уже действовали четыре правила:

1. NOT_INITIALIZED ≠ 0. Область, которую никогда не считали, не пуста — она неизвестна и остаётся неизвестной, пока кто-то её не посчитает.
2. NOT_REPORTED ≠ ZERO. Канал, который не отчитался, не сообщил нам ничего, и неудачный отчёт никогда не превращается в дефицит.
3. Observed Inventory ≠ Central Inventory. Каналы продолжают сообщать то, что видят. Реестр фиксирует то, что WEOUR решил после сверки.
4. Candidate ≠ Approved. Предложенное движение — это предложение. Запасом оно становится только после явного утверждения и никогда — за счёт автоматического заполнения пробела.

Чего это не означает

Это не означает, что вопрос запасов «решён». Два посчитанных склада — это два посчитанных склада. Реестр хорош ровно настолько, насколько хорош следующий пересчёт, а следующая область — та, которая ещё не инициализирована.

Это также не означает, что числа окончательны. Пересчёт — утверждение о моменте. Система должна сохранять этот момент рядом с числом, чтобы позднейшая разница была разницей между двумя известными состояниями, а не спором о том, кто прав.

Почему это первая запись реестра

Мы публикуем серию о реестре, потому что это самая негламурная и самая несущая часть торговой операционной системы. Если система не может отдельно сказать, что она знает, что наблюдала и что решила, то все числа над ней — украшение.

Запись реестра №1 — первая, где эти три вещи перестали быть одной и той же вещью.

NOT_INITIALIZED

Системе никогда не сообщали, что здесь находится

NOT_REPORTED

Источник, который обычно отчитывается, не отчитался

ZERO

Мы знаем от конкретного источника и в конкретный момент, что количество равно нулю

Наблюдаемые запасы

То, что сообщил канал или склад, сохранённое как доказательство

Центральные запасы

То, что WEOUR решил считать истиной после сверки

Это пять разных вещей. Системы, которые сжимают их в одну колонку, не проще — они просто не могут объяснить, почему число именно такое.

Почему «неизвестно» не должно становиться «нулём»

Ноль — это утверждение. Он говорит, что измеримое количество равно нулю. Когда у системы нет информации, запись нуля делает неизвестный факт похожим на известный, и каждое последующее решение наследует эту ошибку:

• Витрина помечает товар недоступным не потому, что товар закончился, а потому что сорвался отчёт.
• Правило пополнения срабатывает на несуществующем дефиците.
• Отчёт сверки показывает расхождение, которое на самом деле является отсутствующим источником, и команда тратит день на поиск проблемы, которой нет.

Ничто из этого не выглядит как баг. Это выглядит как обычные данные.

Как мы это представляем

Незаданное состояние запаса хранится как явное состояние, а не как число. Состояния — часть модели:

• NOT_INITIALIZED — запись существует, но ни один источник никогда не предоставлял значение.
• NOT_REPORTED — источник должен отчитаться, но пока не сделал этого или отчёт не прошёл.
• Числовое значение — фактическое утверждение, всегда вместе с источником и временем наблюдения.

Слой отображения может быть дружелюбным. Слой хранения не имеет права угадывать.

Наблюдаемые запасы — это не центральные запасы

Вторая половина принципа: наблюдения никогда не становятся реестром «по случайности».

Каждый маркетплейс и каждый склад что-то сообщает, и эти сообщения отвечают на разные вопросы в разные моменты. Наблюдаемые запасы — это то, что нам сообщили. Центральные запасы — это то, что WEOUR решил после сверки наблюдений, физических пересчётов и известных пробелов.

Именно явная граница между ними делает продажи через несколько магазинов честными: пять магазинов могут сообщать то, что видят, и ни один из них не переписывает молча то, чем владеет WEOUR.

Сколько это стоит и почему мы платим

Этот принцип неудобен. Он означает больше состояний, больше явной обработки и меньше мест, где значение по умолчанию может тихо закрыть дыру. Он означает, что дашборды должны говорить «неизвестно» вместо успокаивающего нуля.

Мы платим эту цену, потому что альтернатива — операционная система, которая уверенно ошибается. Commerce OS заслуживает доверия, когда знает, чего не знает, — и говорит об этом в базе данных, а не только в интерфейсе.

NOT_INITIALIZED ≠ 0. NOT_REPORTED ≠ ZERO. Наблюдаемые запасы — это не центральные запасы.

Ячейки были placeholder-значениями.

Чем плохи числа, которые всего лишь согласованы

Placeholder-ячейки легко генерировать и легко им доверять. Они подходят под схему, проходят валидацию и дают графики. Сбой проявляется только тогда, когда кому-то нужно физически взять товар, или когда два разных человека описывают одну и ту же полку двумя разными способами, а система настаивает, что это разные места.

В этом и ловушка: placeholder-данные не выглядят как отсутствующие. Они выглядят как данные.

Замена набора placeholder-значений на реальный

Мы перестроили мастер-данные складов исходя из того, как площадки работают на самом деле, и загрузили их как авторитетный набор складских ячеек.

Проверенные складские ячейки

1 306

Смоделированные площадки

Сучжоу, Шэньчжэнь

Подход

Сначала физическое место, потом запись в системе

Placeholder-ячейки

Выведены из использования, а не «отремонтированы»

Неизвестный mapping

Остаётся неизвестным, пока реальная ячейка не подтверждена

Количество здесь не главное. Главное — что каждая из этих 1 306 ячеек соответствует месту, до которого человек может дойти, и что обе площадки смоделированы по одним правилам, а не по двум локальным привычкам.

Что вскрылось при изменении

Замена placeholder-данных реальностью обнажает всё, что тихо опиралось на фальшивые данные:

• Товары, у которых была placeholder-ячейка и не было настоящего места, требовали решения, а не значения по умолчанию.
• Легаси-коды, означавшие на разных площадках разное, нужно было разобрать, а не слить.
• Любой процесс, который считал, что товар всегда где-то есть, должен был начать принимать «мы это ещё не подтвердили» как допустимое состояние.

Именно последний пункт изменил систему сильнее всего, и ему посвящена следующая запись журнала.

Почему мы это публикуем

Мастер-данные склада — самая негламурная часть торговой операции и одна из немногих, от которых зависит всё остальное. Публикация этой записи — способ зафиксировать стандарт, который мы теперь к себе применяем: складская ячейка — это физический факт, а система, которая их выдумывает, хуже системы, которая признаёт, что не знает.

Запись о ячейке, до которой никто не может дойти, — это не данные о запасах. Это украшение.

Когда магазинов два, всю картину можно держать в одной голове. Какой листинг к какому магазину относится, какая цена принадлежит какому каналу и что произойдёт, если оба магазина попытаются продать последнюю единицу, — на всё это можно ответить по памяти. На третьем магазине это перестаёт работать, а на пятом ломается очень заметно.

Изоляция магазина — это граница, а не копия

Первая реакция при добавлении магазина — дублировать: скопировать каталог, скопировать остатки, скопировать таблицу mapping и поменять идентификатор магазина. Это выглядит быстро и создаёт вторую версию истины, которая в течение недели разойдётся с первой.

Мы заняли противоположную позицию:

Принцип

Что это значит на практике

Магазин — это идентичность, а не контейнер остатков

Магазин владеет листингами, ценами и правилами канала, но не собственным реестром запасов

Листинг — это артефакт канала

Два магазина могут продавать один и тот же физический товар под разными листингами

Идентичность товара общая

Товар описывается один раз, остальные ссылаются на это описание

Остатки наблюдаются, а не копируются

Магазин сообщает то, что видит; система фиксирует наблюдение, а не изобретает баланс

Теперь добавление магазина добавляет идентичность канала. Оно не добавляет запасы.

Почему «наблюдаемые остатки» вместо баланса по каждому магазину

Маркетплейсы сообщают данные в своём темпе и своими словами. Один канал отдаёт доступное к продаже количество уже после своих резервов. Другой — то, что ему сообщили вчера вечером. Ни одно из чисел не является ошибочным, и ни одно не является полной правдой о физическом товаре.

Поэтому мы перестали требовать от каждого канала быть источником баланса. Канал сообщает наблюдение: вот что я вижу, из этого источника, в это время. Наблюдения фиксируются, сравниваются и сверяются — они не сливаются молча в одно число, которое невозможно проверить.

Именно это проектное решение делает пять магазинов управляемыми, а не пятикратной нагрузкой на поддержку.

Что пришлось построить, чтобы это держалось

Работа пяти магазинов в одной операционной модели потребовала трёх вещей, которые не были очевидны на двух:

• Единая идентичность товара, на которую ссылаются листинги, чтобы один и тот же товар не описывался заново в каждом канале.
• Слой mapping между идентичностями листингов маркетплейсов и нашими SKU, потому что артикул продавца и внутренний идентификатор — не одно и то же.
• Резолвер, который отвечает, «какие каналы могут это продавать и по какой цене», не позволяя ни одному каналу перезаписать общую запись.

Ничего экзотического. Но всё это нужно принудительно поддерживать, потому что сбой здесь тихий: продублированный остаток всё равно выглядит как корректное число.

Стоимость мультимагазина — это не пятый магазин. Это вторая копия истины, которую вы не заметили, что создали.

Что меняется по мере добавления магазинов

Когда изоляция закреплена на границе канала, добавление магазина становится операционной задачей, а не проектом по миграции данных. Следующий магазин выходит в продажу со своим набором листингов, своими правилами цен и своей отчётностью — а товары и физические остатки, на которые он ссылается, остаются там, где были.

Именно это свойство мы и покупали, когда строили модель. Не больше магазинов. Меньше неожиданностей на каждый магазин.

Мы попробовали смотреть на это именно так: сравнивали платформы, которые вмещают больше SKU, больше магазинов и больше интеграций. Каждая отвечала на свою версию вопроса. Ни одна не отвечала на наш.

Проблема была не в категории софта

ERP построена вокруг компании, которая уже знает, чем владеет: чистые мастер-данные, одно место, где живёт истина, процессы, которые в основном идут внутри одной организации. Эта модель отлично работает, когда бизнес — это один каталог и один-два канала.

Наша реальность другая. Один и тот же физический товар существует на нескольких маркетплейсах под разными листингами, приходит разными маршрутами поставки и сообщает остатки в разное время в разном формате. Закупка, листинг маркетплейса и складская ячейка — три разных объекта с тремя разными жизненными циклами. Софт, который сжимает их в одну строку, не ошибается — он просто отвечает на более простой вопрос, чем наш.

Что мы строим вместо этого

WEOUR OS — это Commerce OS: набор систем, которые описывают, как связаны товары, листинги, склады и решения, и которые поддерживают эти связи честными, пока бизнес работает.

Слой

Ответственность

Канал

Каждый магазин сохраняет свою идентичность, правила цен и жизненный цикл листингов

Запасы

Наблюдения фиксируются вместе с источником и временем, а не сливаются молча

Склад

Физические ячейки моделируются как полноценные записи

Mapping

SKU, листинги и идентичность товара связываются, а не считаются одним и тем же

Агенты

Автоматизация предлагает и выполняет действия по явным правилам системы

Каждый слой можно заменить. Связи — нельзя.

Строим в продакшене, а не в презентации

Мы публикуем это как журнал разработки, а не как анонс, потому что начинаем не с белой доски. Мы меняем системы, которые уже несут реальные магазины, реальные склады и реальные листинги. Каждое проектное решение должно выдержать проверку живой операцией в тот же день, когда оно принято.

Это ограничение неудобно и полезно. Оно отсекает изящные архитектуры, которые нельзя выкатывать постепенно, и заставляет записать правила, которые бизнес уже соблюдает по умолчанию, но никогда не формулировал.

Что это значит для магазина, который вы видите

weour.com не заменяется новым сайтом. Он и есть одна из систем. Витрина, российский и китайский рыночные каналы, процессы поставщиков и внутренний операционный слой приводятся к одной модели того, чем на самом деле являются магазин, товар и остаток.

Операционная система для глобальной торговли — это не база данных побольше, а меньшее число правил, которым можно доверять.

Что дальше

Следующие записи журнала — о самом сложном: как магазины остаются изолированными, разделяя один каталог; почему новый магазин не должен дублировать запасы; что произошло, когда placeholder-ячейки встретились с реальными; и почему неизвестный остаток никогда не превращается в ноль.

Это и есть то, что мы строим. Мы продолжим публиковать процесс.