TGViewer
Аналитик, который думал Аналитик, который думал @analysts_thinking · 92 subscribers
Post #185 9
Правдоподобная догадка не закрывает открытый вопрос

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

В синтетическом учебном кейсе Acme Pay документация требует использовать экспоненциальную задержку для повторной доставки вебхуков. На этом описание заканчивается. Сколько делать попыток? С какой задержки начинать? Какой установить предел? Когда считать доставку окончательно неудачной? В карте источников это пробел G01.

Агент легко достроит недостающие параметры. Например: три попытки с интервалами 1, 2 и 4 секунды, затем перенос события в отдельную очередь. Такой вариант похож на распространённую инженерную практику. Его можно аккуратно оформить, добавить схему и даже превратить в тесты.

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

Здесь полезно разделить три состояния.

Известно: провайдер требует экспоненциальную задержку.

Предложено: три попытки с интервалами 1, 2 и 4 секунды. Это вариант для обсуждения, а не часть контракта.

Открыто: точные параметры, предел ожидания и поведение после исчерпания попыток. Ответ должен дать владелец внешнего контракта или человек, уполномоченный принять риск внутри команды.

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

Для агента это тоже отдельное правило работы: он может предложить варианты и объяснить последствия каждого, но не должен менять статус вопроса с OPEN на RESOLVED. Это делает человек и оставляет след решения: кто выбрал вариант, когда, для какой версии интеграции и на каком основании.

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

Хорошая постановка показывает границу знания. В ней видно, что пришло из источника, что предложено для обсуждения и какое решение команда пока не имеет права считать принятым.
More from @analysts_thinking
  1. Oct 8, 2026Потерянный webhook остаётся открытым решением Таймаут не сообщает, произошло событие или н…
  2. Oct 7, 2026Промежуточное состояние нужно проектировать, а не скрывать processing не является неудобно…
  3. Oct 6, 2026return_url не означает payment.succeeded Возврат пользователя в интерфейс сообщает только…
  4. Oct 5, 2026Что на самом деле доказывает зелёный тест? Он показывает, что реализация соответствует зап…
  5. Oct 4, 2026«Показывать статус заявки» — так требование выглядело в начале. После уточнений оказалось,…
  6. Oct 3, 2026Позитивный сценарий обычно помещается в одну строку: оператор запускает проверку, сервис р…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →