Integration review без интеграции: evidence и точка stop

Evidence до обсуждения интеграции

Самая дорогая ошибка на межъязыковой границе — назвать integration success там, где есть только три похожих описания. Тогда команда тратит время на согласование вывода, а не на проверку условия. Цена растёт ещё сильнее, когда review использует реальные логи, окружение или устные сведения, но не может показать, какой факт поддерживает решение.

Этот field protocol намеренно не тестирует интеграцию. Его positive path — только synthetic integration review hand-off. Пакет берёт named fixed JS literal, формулирует один question и либо возвращает hand-off, либо останавливается с причиной. Ни PHP, ни JavaScript, ни D не запускаются; model names не дают права говорить о сервисе, deploy или production effect.

Что составляет evidence packet

Packet не является сертификатом. Он состоит из input record, review question, requested outcome и boundary. Вопрос узкий: «внутренне сопоставим ли fixed contract record». Outcome заранее ограничен. Boundary говорит, что запрещены network, filesystem, clock, telemetry, service, runtime, trace, profile, PII и deployment. Эти поля делают отрицание части данных, а не скрытым соглашением.

Такой пакет полезен тем, что другой рецензент может запустить тот же public export и получить тот же status. Ему не нужен доступ к панели, секрету или репозиторию чужого адаптера. Если для вывода всё же нужен внешний контекст, значит он не относится к этому package и не должен пробраться в формулировку hand-off.

Последовательность review

1. Взять ровно один packet, созданный public export, и не дополнять его внешними фактами.
2. Сверить requested outcome: разрешён только synthetic multi-runtime review hand-off.
3. Проверить, что boundary явно запрещает внешнее наблюдение.
4. Передать input в contract reviewer и сохранить его status без редакторской замены.
5. При stop вернуть точную named reason владельцу record.
6. При accepted status передать packet на review, не объявляя интеграцию выполненной.

Исполняемый hand-off

import { createFixedEvidencePacket, reviewFixedEvidencePacket } from './upgrade-2026-06.mjs';

const packet = createFixedEvidencePacket('named-contract-v1');
const outcome = reviewFixedEvidencePacket(packet);

console.log({
  status: outcome.status,
  nextAction: outcome.nextAction,
  effect: outcome.effect,
});
// synthetic-integration-review-hand-off, hand-off-fixed-synthetic-review, no-system-change

Слово integration в status описывает предмет обсуждения, а не осуществлённое действие. В accepted literal evidence показывает лишь следующее: fixed data полностью соответствует rules, а внешний эффект не предпринимался. Правильный ответ на вопрос «значит ли это, что системы связаны?» — нет. Пакет специально не имеет возможности вернуть такой вывод.

Причины stop не должны быть декоративными

Если packet содержит incomplete contract, review возвращает stop-incomplete-contract с указанием, что нужно назвать schema, operation и tag. Если adapters смешивают envelope и thrown value, причина adapter-does-not-preserve-contract-shape не даёт им слиться в удобное «ошибок нет». Если mapping coerced, reason остаётся отдельным: перенос shape не доказан.

Если closed tick отсутствует или basis не fixed logical, status stop-undetermined-time-boundary не позволяет написать «быстро» или «медленно». Он не требует получить clock прямо сейчас. Он просто завершает эту проверку с именованным отсутствующим фактом. Такой stop можно переслать владельцу без толкования и без расширения scope.

Как вести разговор после отказа

Отказ — хороший hand-off только тогда, когда следующий шаг меньше исходной задачи. Вместо «исследовать все runtime» причина предлагает назвать одно поле или удалить coercion. Следующий literal можно подготовить в памяти и снова пропустить через те же exports. Это дисциплинирует обсуждение: изменение фиксируется как данные, а не как воспоминание о том, что якобы произошло на стенде.

Важен и обратный запрет. Нельзя использовать accepted packet как доказательство, что следующая реальная интеграция безопасна. У record нет host, transport, retry policy конкретного клиента, доступов, версии зависимостей или данных пользователя. Неявно добавив хотя бы одно из них, автор превратит synthetic review в неподтверждённый operational claim.

Минимальный журнал решения

Для review достаточно сохранить packetId, input id, status, reasons или nextAction и effect. Этого достаточно, чтобы повторить логику. Не надо добавлять timestamp запуска, trace id или ссылку на реальный incident: таких фактов в данной модели не существует. Короткий журнал лучше длинного, если он не создаёт ложный след наблюдения.

Такой подход отражает зрелый T-shaped навык: автор умеет соединить contract design, type reasoning и review discipline, но удерживает границу между моделью и эксплуатацией. Текст не заменяет специалиста по PHP, JavaScript или D. Он делает видно, какой именно вопрос ещё не подтверждён специалистом и почему.

Кому и что передаёт hand-off

Hand-off не назначает владельца интеграции и не открывает change request. Он передаёт рецензенту ограниченный артефакт: packetId, вопрос, фиксированный input, status и запрет production effect. Этого достаточно, чтобы другой человек проверил процедуру. Этого недостаточно, чтобы кто-либо подключил endpoint, изменил конфигурацию или решил, что реальный contract уже согласован.

Для автора hand-off снимает соблазн дописать уверенный итог. Его работа завершена, когда stop или accepted status воспроизводимы. Для владельца boundary это означает более ясную очередь: он видит, нужно ли назвать field, выровнять semantics или остановить инициативу. Для domain reviewer это означает, что business interpretation value tag остаётся отдельным вопросом, не смешанным с формой record.

Важно, что evidence packet не передаёт доверие по цепочке. Новый reviewer не обязан верить предыдущему: он повторяет public export над тем же literal. Если результат отличается, проблема в коде или input, а не в комментарии к pull request. Такая проверяемость полезнее истории переписки, потому что не зависит от доступа к ушедшему сотруднику или внешней панели.

Пять вопросов перед словом integration

Эта таблица нужна не для ритуала. Она отсекает язык, который легко проскальзывает в заголовки: «проверили интеграцию», «совместимость подтверждена», «адаптер работает». Ни одна из этих фраз не поддержана packet. Чем ярче обещание, тем важнее вернуть его к наблюдаемому объекту. Если объектом остаётся literal, то и итог должен оставаться про literal.

Как выглядит корректное продолжение

Допустимое продолжение не добавляет сетевой тест. Оно создаёт новый packet, в котором одна version не совпадает, и проверяет named stop. Можно также удалить retry из envelope и убедиться, что result становится incomplete contract. Эти изменения изолированы, обратимы и не требуют представлять, что реальная система доступна. Они развивают protocol, не подменяя его эксплуатацией.

Недопустимое продолжение начинается словами «давайте просто посмотрим логи» или «позовём сервис на тестовом адресе». Возможно, это полезное действие в другом task, но здесь оно меняет authority и доказательную модель. Правильный ответ — остановиться и завести новую границу. P100 честно заканчивается до этого порога, поэтому его accepted path можно безопасно читать как review artifact, а не как operational decision.

Пример контрфакта

Возьмём literal undetermined-time-v1. В нём названия model records и value tag сохранены, но time basis — wall-clock, а closed отсутствует. Если функция всё равно вернёт hand-off, она будет утверждать сравнимость без основания. Fixture требует другой результат. Так negative case проверяет не реализацию трёх языков, а честность самого review protocol.

Аналогично mixed-error-semantics-v1 не доказывает, что какой-то runtime бросает исключение. Он хранит строку thrown-value в fixed literal, чтобы показать: один contract cannot silently mix it with named envelope. Эта разница критична для процедуры, даже когда реальная система вообще не рассматривается.

Ограничения и следующий шаг

P100 не запускает real runtime, не вызывает service, не читает сеть или диск, не использует clock, не получает telemetry, не содержит PII и не проверяет production effect. В нём нет profile, trace, certificate, deployment или утверждения о фактической совместимости. Это не недостающие шаги сборки, а условия корректности изолированного draft.

Следующий шаг внутри этой же границы — добавить один fail-closed packet с несовпадающей версией adapter и буквально выполнить export. Если нужен реальный integration test, нужно остановиться: потребуется новое разрешение, другой scope и отдельные доказательства. Данный draft не пытается незаметно перейти эту черту.

Проверяемые источники

• D compiler: annotated tag v2.111.0 — версия: annotated tag v2.111.0, tag object 6ae81e26cedc8f792d0074186e38974542f1a3cc, 31 March 2025; release 1 April 2025, immutable commit pin. Используется как dated pin одной из трёх языковых линий. Граница: Не является доказательством интеграции с каким-либо сервисом.
• PHP source: annotated tag php-8.4.0 — версия: annotated tag php-8.4.0, tag object 501fc4ce253940b58a8744b1083951327e07f00e, 19 November 2024, immutable commit pin. Используется как dated pin второй языковой линии. Граница: Не подтверждает deploy, I/O, ошибку или время исполнения.
• ECMA-262, 16th edition: ECMAScript 2025 Language Specification — версия: 16th edition, June 2025, edition-specific publication. Используется для строгого различения значения и completion в названии review-вопроса. Граница: Не превращает synthetic review в сертификат совместимости.