{
  "index": 56,
  "slug": "editorial-2026-06-mechanism-multi-runtime",
  "title": "Один payload, три runtime: как сохранить смысл на границе",
  "excerpt": "Похожая структура данных не делает PHP, JavaScript и D взаимозаменяемыми. Разбираем контракт type, error и time, отрицательный путь и проверяемый критерий совместимости.",
  "contentHtml": "<p>Сервис принял заказ и вернул объект с полями <code>amount</code>, <code>currency</code> и <code>status</code>. PHP назвал статусом готовности строку <code>ready</code>. JavaScript обработал её как обычный результат. D получил тот же набор полей, но считает отсутствие кода ошибки отдельным состоянием. На границе всё выглядит одинаково. После сбоя команда видит три разных решения, а в логах остаётся один красивый JSON.</p>\n<p>Цена такой ошибки — не только неверное сообщение. Клиент может повторить уже принятый заказ, worker может пропустить отказ, а расследование свяжет события по совпадающим полям, хотя они относятся к разным состояниям. Исправление обычно начинается с догадки: добавить retry, привести значение к строке или считать пустой код успехом. Каждая такая догадка расширяет зону риска.</p>\n<p>Тезис статьи простой: общий boundary contract должен называть не только поля, но и их смысл. Для минимальной проверки достаточно разделить три независимые оси: <code>type</code> отвечает за вид значения, <code>error</code> — за режим завершения, <code>time</code> — за определённую шкалу и порядок. Если одна ось не задана или подменена другой, проверка должна остановиться.</p>\n<h2>Почему одинаковый JSON не равен общему контракту</h2>\n<p>JSON переносит форму. Он не переносит договор о поведении. Число <code>4200</code> может означать сумму в копейках, лимит, внутренний идентификатор или случайный счётчик. Строка <code>ready</code> может быть именем состояния, текстом для интерфейса или результатом нестрогого сравнения. Без названного типа consumer вынужден угадывать.</p>\n<p>Ошибки создают второй разрыв. Один runtime может вернуть объект результата с полем <code>error</code>. Другой может завершить операцию исключением. Третий может вернуть код и продолжить выполнение. Человек способен описать эти случаи одной фразой «обработка ошибки». Адаптеру такой фразы недостаточно: ему нужно знать, можно ли повторять операцию, сохранено ли значение и кто владеет решением.</p>\n<p>Время создаёт третий разрыв. Длительность из monotonic clock нельзя без оговорки сравнивать с календарным timestamp. Два числа без шкалы не доказывают latency. Даже одинаковые начало и конец могут быть только порядковыми метками внутри тестового объекта, а не наблюдением работающей системы.</p>\n<figure><img src=\"/assets/editorial/2026/multi-runtime-2026-error-type-time-matrix.svg\" alt=\"Матрица type, error и time для проверки общего контракта между тремя model labels\" loading=\"lazy\" /><figcaption>Иллюстрация разделяет три вопроса boundary. Матрица показывает структуру проверки, а не сравнительную характеристику PHP, JavaScript и D и не результат запуска в конкретной среде.</figcaption></figure>\n<h2>Три оси контракта</h2>\n<p><code>type</code> должен содержать named tag. Не выводите его из соседних полей. В примере <code>order-ready</code> — это фиксированная метка значения, а <code>amountMinor</code> и <code>currency</code> — дополнительные поля с собственной единицей и форматом. Если адаптер заменяет tag числом или оставляет его пустым, shape больше нельзя считать сохранённым.</p>\n<p><code>error</code> должен описывать режим завершения. Удобная минимальная форма — <code>semantics</code>, <code>code</code> и <code>retry</code>. Значение <code>code: null</code> означает отсутствие кода в данном envelope. Оно не означает «в системе ошибок нет». Значение <code>retry: not-requested</code> не запускает повтор и не обещает, что повтор безопасен. Для этого нужны отдельные правила идемпотентности.</p>\n<p><code>time</code> должен называть <code>basis</code> и обе границы интервала. Fixed logical ticks подходят для проверки порядка внутри заранее заданной записи. Они не являются миллисекундами. Если контракт требует наблюдаемую длительность, ему нужны источник измерения, единицы, точка начала и точка окончания. Нельзя подставить текущие часы, чтобы получить зелёный результат.</p>\n<p>Три оси проверяются отдельно. Ошибка не сообщает тип значения. Числовое поле не задаёт единицу времени. Наличие timestamp не подтверждает, что операция завершилась успешно. Такое разделение кажется избыточным только до первого неоднозначного отказа.</p>\n<h2>Учебный пример проверки</h2>\n<p>Ниже приведён ограниченный JavaScript-пример. Он проверяет только объект в памяти и возвращает причину остановки. Он не запускает PHP или D, не вызывает сеть, не читает часы, не измеряет производительность и не подтверждает поведение сервиса. Его задача — показать форму fail-closed проверки.</p>\n<pre><code>const contract = {\n  schemaVersion: 'boundary-1',\n  value: { tag: 'order-ready', amountMinor: 4200, currency: 'RUB' },\n  error: { semantics: 'named-envelope', code: null, retry: 'not-requested' },\n  time: { basis: 'fixed-logical-ticks', opened: 100, closed: 108 }\n};\n\nconst adapters = [\n  { model: 'php', version: 'boundary-1', valueTag: 'order-ready',\n    errorSemantics: 'named-envelope', timeBasis: 'fixed-logical-ticks', mapping: 'exact' },\n  { model: 'javascript', version: 'boundary-1', valueTag: 'order-ready',\n    errorSemantics: 'named-envelope', timeBasis: 'fixed-logical-ticks', mapping: 'exact' },\n  { model: 'd', version: 'boundary-1', valueTag: 'order-ready',\n    errorSemantics: 'named-envelope', timeBasis: 'fixed-logical-ticks', mapping: 'exact' }\n];\n\nfunction review(record, participants) {\n  if (!record.schemaVersion || participants.length !== 3) {\n    return 'stop-incomplete-contract';\n  }\n  if (record.time.basis !== 'fixed-logical-ticks' ||\n      record.time.closed === null || record.time.closed < record.time.opened) {\n    return 'stop-undetermined-time-boundary';\n  }\n  const valid = participants.every((item) =>\n    item.version === record.schemaVersion &&\n    item.valueTag === record.value.tag &&\n    item.errorSemantics === record.error.semantics &&\n    item.timeBasis === record.time.basis &&\n    item.mapping === 'exact'\n  );\n  return valid ? 'accepted-fixed-contract' : 'stop-incomparable-adapter';\n}\n\nconsole.log(review(contract, adapters)); // accepted-fixed-contract</code></pre>\n<p>Пример сравнивает ровно те сведения, которые записаны в объекте. Он не делает вывод о типовой системе языка по полю <code>model</code>. Подписи <code>php</code>, <code>javascript</code> и <code>d</code> здесь лишь заранее названные участники матрицы. Версия runtime, библиотека, transport и формат сериализации в этот объект не входят.</p>\n<p>В реальном коде такой boundary нужно реализовать в согласованном контракте и покрыть тестами конкретного продукта. Нельзя скопировать функцию и объявить интеграцию проверенной. Учебный объект специально маленький: он помогает увидеть missing field и смешанную семантику, но не заменяет контракт API.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Признаки потери смысла на границе и минимальная реакция</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Одинаковый shape даёт разные решения</td><td>Нет named value tag или версии схемы</td><td>Сверить tag, schemaVersion и единицу каждого поля</td><td>Добавить обязательные поля; не выводить смысл из shape</td></tr><tr><td>Один участник бросает ошибку, другие возвращают envelope</td><td>Смешаны error semantics</td><td>Сравнить режим завершения, code и retry</td><td>Выбрать один boundary mode или остановить mapping</td></tr><tr><td>Отчёт говорит «быстрее», но метрики нет</td><td>Logical ticks приняли за latency</td><td>Проверить basis, источник часов и обе границы</td><td>Удалить вывод о скорости либо завести отдельное измерение</td></tr><tr><td>Повтор после таймаута создаёт второй заказ</td><td>Retry назван, но идемпотентность не определена</td><td>Проверить operation key и эффект повторного вызова</td><td>Остановить повтор; согласовать ключ и политику отдельно</td></tr><tr><td>«Успех» появляется при неполном объекте</td><td>Проверка подставляет default вместо отказа</td><td>Удалить default и прогнать missing-case</td><td>Вернуть точную stop-причину владельцу контракта</td></tr></tbody></table></div>\n<h2>Отрицательный путь важнее зелёного примера</h2>\n<p>Положительный объект удобен, но он почти ничего не говорит о дисциплине контракта. Настоящая проверка начинается с испорченной записи. Удалите <code>schemaVersion</code>. Ожидаемый результат — <code>stop-incomplete-contract</code>. Не подставляйте текущую версию автоматически: иначе тест перестанет замечать несовместимый участник.</p>\n<p>Замените у JavaScript-участника <code>errorSemantics</code> на <code>thrown-value</code>. Ожидаемый результат — <code>stop-incomparable-adapter</code>. Проверка не должна оборачивать исключение в envelope задним числом. Такое преобразование может быть правильным решением продукта, но тогда оно должно быть отдельным адаптером с названными правилами, а не скрытой операцией review.</p>\n<p>Измените <code>time.basis</code> на <code>wall-clock</code> и оставьте <code>closed: null</code>. Ожидаемый результат — <code>stop-undetermined-time-boundary</code>. Нельзя сказать «интервал неизвестен, но примерно короткий». В этом объекте нет факта, который поддерживает такую оценку.</p>\n<p>Такой путь защищает и от незаметной нормализации. Coercion может сделать данные удобнее для одного consumer, но скрыть различие между целым числом и tagged value. Если преобразование нужно, его надо назвать, версионировать и проверить как новую границу. Молчаливое приведение не является доказательством совместимости.</p>\n<h2>Порядок действий</h2>\n<ol><li>Назовите одну операцию и владельца её смысла. Не начинайте с общего утверждения «три языка совместимы».</li><li>Запишите schema version, value tag, единицы полей и допустимые пустые значения.</li><li>Определите один error envelope или другой единый режим завершения. Отдельно назовите retry и условие его безопасности.</li><li>Выберите time basis. Для логического порядка зафиксируйте обе границы; для latency укажите источник измерения и единицы.</li><li>Составьте по одной записи для PHP, JavaScript и D. Сравнивайте каждую с контрактом, а не одну реализацию с другой.</li><li>Запустите positive-case и четыре negative-case: missing schema, mixed error, неизвестный tag и незакрытый интервал.</li><li>Для каждого отказа сохраните точную причину. Не заменяйте её общим «adapter error».</li><li>Только после успешной проверки границы подключайте конкретный transport, runtime и наблюдение. Их результаты нельзя приписывать синтетическому объекту.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Контрактная матрица не делает разные языки одинаковыми. Она не описывает сборщик мусора, правила приведения типов, исключения, ABI, сериализатор или планировщик. Эти свойства могут влиять на интеграцию и требуют отдельных источников и тестов. Матрица только не даёт спрятать их за одинаковым полем.</p>\n<p>Даже официальный документ языка отвечает на вопрос о данном языке, а не о совместимости трёх систем. Например, строгая типизация PHP может изменить момент отказа, completion record ECMAScript описывает семантику спецификации JavaScript, а D документирует собственную обработку ошибок. Ни один из этих фактов сам по себе не доказывает общий API.</p>\n<p>Матрица также не проверяет бизнес-смысл суммы, права пользователя, повторную доставку сообщения или транзакцию. Для них нужны свои поля, владельцы и отрицательные сценарии. Если boundary не может выразить важное условие, нельзя считать его достаточным только потому, что все участники прошли текущую проверку.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Граница готова к следующему техническому тесту, если другой инженер без устного пояснения может восстановить: какую операцию описывает запись, какой tag означает допустимое значение, как кодируется ошибка, что означает retry, какая шкала времени используется и какой результат даёт каждый отрицательный случай.</p>\n<p>Дополнительное условие — все три участника сохраняют contract shape без неявного приведения, а положительный результат не содержит утверждения о latency, deployment или реальном поведении среды. Если хотя бы одно поле приходится угадывать, проверка должна закончиться именованной stop-причиной. Это и есть полезный результат: команда видит границу знания до того, как похожий payload станет ошибочным действием.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://262.ecma-international.org/16.0/\" target=\"_blank\" rel=\"noopener noreferrer\">ECMAScript 2025 Language Specification, ECMA-262, 16th edition</a> — официальное описание language types и completion records JavaScript. Источник не подтверждает совместимость с PHP или D.</li><li><a href=\"https://www.php.net/manual/en/language.types.declarations.php\" target=\"_blank\" rel=\"noopener noreferrer\">PHP Manual: Type declarations</a> — официальное описание проверки типов, coercion и <code>TypeError</code> в PHP. Поведение конкретного boundary зависит от его кода и версии.</li><li><a href=\"https://dlang.org/spec/errors.html\" target=\"_blank\" rel=\"noopener noreferrer\">D Programming Language Specification: Errors</a> — официальное описание модели обработки ошибок D и stack unwinding. Источник не задаёт общий envelope для внешних систем.</li></ul>"
}