# Независимое AI-ревью статьи и BPMN-сравнения

Дата: 29 сентября 2026. Проверял отдельный агент в роли BPMN/business-process reviewer. Это AI-экспертиза с видимыми именами моделей, не оценка приглашённого человека и не сертификация BPMN.

Проверенная версия: статья на `http://localhost:8780/articles/petr-i-zayats-storm-vs-bpmn-xml` и интерактив на `/experiments/petr-i-zayats/compare.html`, до внесения root-агентом замечаний этого ревью. Пользовательскую вкладку BB не трогал. Использовал отдельную браузерную сессию `bpmn-expert`.

## Вердикт

Статья содержательно полезна, вывод о сценарном лидерстве Astra обоснован в заявленной узкой постановке. Sonnet со Storm допустимо называть **гипотезой о рабочей лошади для черновиков с ревью**. Доказанной экономии труда аналитика пока нет.

До публикации следует явно показать существенное ограничение первого этапа: **все 96 таймерных определений в 40 Storm-диаграммах пусты, длительность записана только в названиях событий**. В остальных двух Storm-диаграммах таких определений нет. Это не нарушение XSD само по себе: описательный BPMN может быть неполным. Но «сценарий поддержан» здесь означает чтение графа, подписей и пояснений, а не настроенное поведение переносимого исполняемого XML. Один общий дисклеймер «не запускали в движке» эту конкретную асимметрию скрывает.

Блокирующих ошибок, из-за которых надо выбросить эксперимент или объявить другого победителя, не обнаружил. Ни замороженные исходники, ни оценки не изменял. Для нового критерия нужна отдельная post-hoc диагностика, а не тихая подмена старых pass/fail.

## Что действительно проверено

- Прочитал всю отрисованную статью, исходный одинаковый промпт второго этапа, методологические оговорки, выводы и предложения человеческой оценки.
- В живом браузере последовательно переключил все 14 моделей × 3 попытки: 42 пары / 84 панели. Проверил импорт, заполненность canvas, сообщения об отсутствии результата и предупреждения. Это обзор отображения, **не 84 подробных формальных семантических аудита**.
- Подробно сопоставил исходные графы и XML всех шести Astra и всех шести Sonnet с ключевыми сценариями. Для Sonnet XML №3 дополнительно проверил тип целевого элемента непосредственно в импортированной браузерной модели: `Flow_ToHareApproach.targetRef.$type === 'bpmn:Task'`.
- Целевые проверки: Opus XML ×3 — событие, конкурирующее с 8h; Kimi XML ×3 — путь возврата к поиску перца; Haiku XML ×3 — цикл и абстракция ожидания; GLM Flash XML №1 — AND-join; MiMo XML №2 — стартовые события и конфигурация событийного шлюза; Luna XML №3 — отдельная задача Зинаиды и цель событийного шлюза. Остальные результаты просмотрены обзорно; не заявляю полного повторного семантического аудита каждого из них.
- Независимо пересчитал наполненность `timerEventDefinition` по извлечённым XML: Storm 96/96 пустых, raw XML 4/79 пустых. У raw это MiMo №1 и №2. Malformed XML Luna №1 и не извлечённый двойной ответ MiMo №3 в этот XML-пересчёт не включены.
- Правила сверял с локальной официальной спецификацией `bpmn-experiment/vendor/BPMN-2.0.2.txt`: Table 9.8, Table 10.101, раздел Event-Based Gateway на страницах 296–298, правила Activity на странице 151. Не трактовал XSD/import как полный BPMN validator.

## Important: что поправить или показать явно

### I1. Таймер нарисован, но время в XML не настроено

**Масштаб:** все Storm XML, содержащие timerEventDefinition: 96 определений в 40 файлах. Примеры победителя:

- Storm `r1-04-codex`: `TimerEventDefinition_id_b3ff47ca62e6` — подпись «Прошёл 1 час», `TimerEventDefinition_id_24b9f49f16eb` — «Прошло 8 часов без появления зайца»; оба без timeDuration/timeCycle/timeDate.
- Storm `r2-02-codex`: `TimerEventDefinition_id_ab32fa3f11c2`, `TimerEventDefinition_id_e008f7b2c58a` — аналогично.
- Storm `r3-05-codex`: `TimerEventDefinition_id_cf0a04052765`, `TimerEventDefinition_id_4afe886670bc` — аналогично.
- Sonnet Storm №1, `r7-02-sonnet`: `IntermediateCatchEvent_id_88077a75a69f` и `IntermediateCatchEvent_id_25ce21bef5a3` имеют пустые timerEventDefinition.

**Следствие:** граф верно показывает гонку ожиданий, но XML не задаёт числа 1h/8h в полях таймера. Подпись не заменяет конфигурацию. Статья может оставить описательные pass, но должна назвать эту границу в методологии, рядом с победителем и рядом с техническими итогами. Не писать «96 некорректных таймеров»: в Table 10.101 атрибуты опциональны, и процессы описательные.

**Предлагаемый текст:** «Со Storm мы оценивали описательные сценарии по графу, подписям и пояснениям. В экспортированных XML все 96 таймерных определений оказались без значения времени: “1 час” и “8 часов” видны человеку в названии, но не настроены в XML. Поэтому прохождение сценария не означает готовности к исполнению».

### I2. Победитель описательных сценариев также опирается на абстракции

Storm Astra №2 `r2-02-codex`, узел `IntermediateCatchEvent_id_b63c1a60148f`, фактически **userTask**, а не catch event. Storm Astra №3 `r3-05-codex`, `IntermediateCatchEvent_id_65e2c3bfa711`, фактически **manualTask**. Название — «Заметить повторяющиеся поиски мужа». ID не определяет BPMN-тип.

Обе задачи запускаются на отдельной параллельной ветви. Смысл «ждать, пока заметит повторы» выражен названием работы; формального conditional trigger нет. При этом Пётр может продолжать почасовой цикл, а terminate end завершает оставшуюся ветвь в общем процессе. Поэтому **не нашёл основания менять узкие pepper/termination pass**. Нельзя расширять их до утверждения, что условная активация Зинаиды формально закодирована во всех шести результатах Astra.

В прямом Astra №1 есть непрерывающий conditional event subprocess с условием повторных поисков и перца на нижней полке. В №2/№3 — отдельный процесс Зинаиды с conditional start. PT1H/PT8H присутствуют во всех трёх raw XML. У №2 `P_Six/timeCycle` содержит cron `0 0 6 * * ?`, поэтому переносимость календарного запуска без выбранного движка/языка не доказана. У №1/№3 ежедневный ISO cycle с явно добавленной датой — допущение, а не часть исходной истории.

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

### I3. Ссылка из браузера не сохраняет выбранную диаграмму

В интерактиве выбрал Astra №1, затем Sonnet №3, режим «Без Storm», масштаб 100%. URL остался `/experiments/petr-i-zayats/compare.html` без выбранной модели/попытки. Открытие скопированной ссылки показывает исходный DeepSeek №1. Входные query-параметры поддерживаются, но выбор пользователя не отражается в адресе.

Для реального ревью аналитик должен иметь возможность отправить коллеге именно спорный результат. **Рекомендация:** при выборе обновлять model/attempt/view через history.replaceState либо дать «Ссылка на эту попытку». Это исправление UX доказательств, не требование синхронного zoom или редактирования исходников.

## Проверка ключевых смысловых выводов

### Astra: узкое лидерство подтверждено, универсальная корректность не доказана

Во всех трёх raw XML повторный поиск не проходит через обязательное завершение работы Зинаиды. Появление зайца конкурирует с таймером 8h. После появления ожидание потери сознания или цепочка поведения зайца уже находятся за выигравшей ветвью, поэтому таймер ожидания появления не отправляет Петра домой на 8:00 при появлении 7:59.

Raw №1: `Gateway_WaitForHare → Catch_HareAppeared / Catch_EightHours`; №2: `P_WaitOutcome → P_Appearance / P_WaitEightHours`, затем отдельно `P_Unconscious`; №3: `Gateway_Wait → Catch_HareArrived / Catch_EightHours`, затем `Catch_HareUnconscious`.

В Storm аналогичная событийная развилка, независимая ветвь наблюдения и terminate end. Это поддерживает авторский вывод при оговорках I1/I2. Не проверено исполнение, корреляция сообщений, переменные, гарантии доставки сигналов и переносимость между движками. Такого требования в эксперименте и нет.

### Sonnet: хороший кандидат на быстрый черновик, не готовый процесс

Storm №1 переносит перец **до** часового ожидания; №2 ждёт в AND-join завершения помощи; №3 после часа обязательно идёт через помощь. Следовательно, независимый почасовой цикл во всех трёх не сохранён. Гонка появления зайца и таймера визуально выражена правильной конфигурацией событийного шлюза, но время таймера — ограничение I1.

Raw №1 `r7-02-sonnet`: `MessageFlow_2` направлен в `Gateway_BrickMerge` — шлюз не InteractionNode-получатель Message Flow. Независимый цикл и гонка в графе при этом есть. Три pass не означают безупречность BPMN.

Raw №2 `r8-01-sonnet`: `GW_HareTimeout` — exclusiveGateway, не событийная гонка. `Event_HareAppears` имеет два исходящих Sequence Flow (`Flow_HareApproach`, `Flow_HareAppearedBack`): к поведению зайца и обратно к шлюзу. Это лишнее продолжение, а не XOR-выбор одной стрелки.

Raw №3 `r9-02-sonnet`: `Gateway_WaitEvent → Task_HareApproach` через `Flow_ToHareApproach` — недопустимая цель событийного шлюза. Подтверждено в браузерном businessObject, не только по тегу исходника. `MsgFlow_ZinaidaMoves` идёт в `Gateway_PepperFound`; `MsgFlow_BrickRequest` исходит из поиска кирпича до проверки отсутствия. Статья правильно акцентирует дефект event gateway. Не следует прогнозировать конкретное поведение движка на невалидной конструкции.

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

### Другие характерные результаты

| Результат | Проверенное наблюдение | Значение для статьи |
|---|---|---|
| Opus XML №1/2/3 | `Gw_Wait`/`Gateway_Wait` конкурирует с `Catch_HareUnconscious`/`Event_HareUnconscious`/`Catch_HareDown`, а не появлением | Контрпример 7:59/8:01 обоснован; это изменение бизнес-условия, не ошибка XSD |
| Kimi XML №1/2/3 | timer 1h → Task_MovePepper → поиск перца без обхода помощи | Формулировка про обязательную Зинаиду справедлива |
| Haiku XML №1 | `Task_Wait → Task_Zinaida → Gateway_Merge2 → Task_GoToField` | Повторной проверки вообще нет; это сильнее, чем просто обязательная помощь |
| Haiku XML №2 | `task_petr_repeat` и `task_zinaida_move` → `gw_parallel_end`; далее новый цикл | AND-join блокирует продолжение до помощи. «Ждёт зайца (8 часов)» недостаточно определяет раннее завершение; uncertain разумнее доказанного fail |
| Haiku XML №3 | `Task_WaitRabbit` с названием «максимум 8 часов», затем XOR | Допустимая высокоуровневая абстракция ожидания; нельзя утверждать, что Пётр обязательно ждёт все 8h |
| GLM Flash XML №1 | `Gw_Split → T_Zinaida` без условия, затем `Gw_Join` перед выходом в поле | Если перец сразу найден, помощь всё равно обязательна. Это не обязательно вечный deadlock, но лишняя синхронизация |
| MiMo XML №2 | `Start_HourWait` и `Start_HareAppears` получают Sequence Flow; `GW_EventBased` имеет входы и не имеет выходов | XSD и импорт пропускают принципиальные ограничения BPMN; самостоятельный `Start_8Hours` не моделирует тайм-аут засады |
| Luna XML №3 | `Task_ZinaidaMovesPepper` без incoming Sequence Flow; `Gateway_WaitHare → Task_HareSeesBrick` | Отдельная задача запускается с процессом, association не управляет токеном; обычная Task недопустима после event gateway |

## UX для аналитика

Сильные стороны: исходный XML скачивается без исправлений; рядом есть исходный ответ и конкретные замечания; ошибочный импорт не маскируется автоисправленной схемой; XSD/import отделены от сценариев; можно включить один способ на всю ширину. Все 42 пары открылись в соответствии со своими состояниями; там, где графа нет, показана причина.

Помимо I3, полезны следующие **optional** улучшения:

1. Ссылка/кнопка «Показать ошибочный узел» из замечания, с фокусом на элементе по XML ID. Сейчас приходится читать текст, находить фигуру и увеличивать вручную. Это особенно важно для длинных Storm-схем: в режиме рядом фактический fit-scale Astra №1 был 0.102/0.168, подписи практически не читаются до увеличения.
2. Повторить исходный кейс или дать быстрый переход к нему внутри отдельного интерактива: аналитик на full-screen странице иначе сверяет требования в другой вкладке.
3. Для запрошенных человеческих оценок сделать короткий единый смешанный пакет шести предложенных примеров из обоих этапов. Текущий пакет содержит только 42 raw XML; поэтому он не реализует слепое сравнение Sonnet/DeepSeek Storm с Astra/Opus XML. Это не дефект уже проведённого AI-эксперимента, но ограничение следующего шага.

## Вопросы пользователю для следующего этапа

1. Подтверждаешь ли независимое повторение поиска каждый час до того, как Зинаида заметит проблему? Это ключевая интерпретация кейса, а не универсальный закон BPMN.
2. Нам нужен понятный описательный процесс для обсуждения или готовая к настройке/исполнению модель? Для второго надо отдельно проверить таймерные значения, условия, сообщения и выбранный движок.
3. Какой из шести анонимных примеров ты быстрее исправишь до своего рабочего стандарта? Засечь минуты и перечислить правки; именно так проверяется гипотеза о рабочей лошади.
4. На примере появления 7:59 и потери сознания 8:01: где должен оказаться токен Петра? Попросить указать на диаграмме, не только поставить оценку.

## Что менять сейчас

Обязательно: явно раскрыть пустые таймерные определения Storm, уточнить описательный характер сценарных оценок, не расширять победу Astra до полной корректности, исправить ссылку на выбранную попытку. Остальные UX-пункты можно оставить следующей итерации. Самих моделей заново не запускать, диаграммы не чинить, исходные оценки не перезаписывать.

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

## Повторная проверка исправлений, 29 сентября 2026, 14:56 UTC

Root-агент внёс изменения, reviewer повторно проверил их в той же отдельной браузерной сессии:

- **I1 закрыто.** В отрисованной статье появился раздел «После экспертного ревью: таймер нарисован, но не настроен» с 96/96, 40 схемами, 79/4 для raw, отдельной post-hoc оговоркой и отсутствием изменения исходных оценок. В интерактиве диагностика видна у каждой панели; DeepSeek Storm №1 показывает 2/2 пустых, его raw — 3 заполненных с оговоркой про непроверенный диалект.
- **I2 закрыто.** Введение, методология и вывод о победителе говорят об описательных сценариях. Прямо названы обычные задачи наблюдения в Astra Storm №2/№3 и cron в Astra raw №2. Рекомендация Sonnet включает исправление логики, ненастроенные таймеры и отсутствие замера человеческой правки.
- **I3 закрыто для модели/попытки.** Выбор Sonnet №3 изменил URL и ссылку выбранной пары на `?model=sonnet&attempt=3`; после reload браузер сохранил модель 13 и попытку 3. Сохранение масштаба и режима просмотра не требуется для воспроизведения пары.

**Итог после исправлений:** важных незакрытых замечаний к точности рассмотренных выводов не осталось. Optional UX и смешанный пакет человеческой оценки остаются предложениями следующего шага. Это заключение не расширяет обозначенный выше охват проверки и не заменяет полную валидацию всех 84 BPMN.