DevTime: как найти неработающие вебхуки в коде без ИИ

DevTime: локальный сканер, который говорит правду

Представьте: вы ищете в чужом репозитории обработчик вебхуков Stripe, находите файл stripe/webhook.ts — и думаете, что всё ясно. Но что, если этот файл — заглушка? DevTime — это CLI-инструмент, который сканирует код локально и оценивает уверенность в каждой концепции. Он не использует облако, телеметрию или ИИ. В этой статье мы разберём, как DevTime обнаружил заглушку вебхуков в Cal.com и почему отказ от лжи — это фича.

Запуск сканирования Cal.com

Cal.com — популярное open-source решение для планирования встреч. Большой TypeScript-монолит с Next.js, NestJS и Stripe. Я запустил DevTime на свежем клоне репозитория:

pipx install devtime-ei
git clone --depth 1 https://github.com/calcom/cal.com
cd cal.com
dtc init
dtc scan

Результат за 4.2 секунды:

Scan complete. Scanned 5736 files, 24516 signals, 3 concepts in 4.2s.

Что нашёл DevTime

Сканер обнаружил три концепции:

• Authentication — уверенность высокая, долг средний
• Billing Webhooks — уверенность низкая, долг высокий
• Background Jobs — уверенность низкая, долг высокий

Аутентификация подтверждена реальными маршрутами. А вот вебхуки — с низкой уверенностью. Как так? Cal.com — это SaaS со Stripe. Там точно есть вебхуки для биллинга. Я решил проверить вручную.

Отказ сканера: заглушка вместо обработчика

DevTime сообщил:

- Possible Billing Webhooks signals detected. Billing Webhooks behavior
  is not established from current evidence.
  confidence: 0.45

Uncertainty:
  - Only dependency or manifest evidence was found for Billing Webhooks;
    presence is not confirmed behavior.

Я нашёл файл apps/web/pages/api/stripe/webhook.ts. Выглядит как настоящий обработчик. Но вот его содержимое:

export default function handler(_req: NextApiRequest, res: NextApiResponse) {
  res.status(404).json({ message: "Billing webhooks are not available in community edition" });
}

Это заглушка. В community-версии Cal.com вебхуки биллинга не работают — они есть только в enterprise. DevTime не нашёл поведенческих доказательств, потому что их не существует. Отказ был верным решением.

Любой разработчик, grep-нувший репозиторий, сказал бы: «Вот обработчик». Любой ИИ-агент, читающий пути файлов, принял бы это за факт. DevTime промолчал — и оказался прав.

Где DevTime ошибся на самом деле

Я обещал найти промахи, и они есть.

Background Jobs: недооценка

Cal.com имеет полноценную систему задач: пакет Tasker с внутренним и Redis-бэкендом, процессор задач и cron-маршруты. Это реальное поведение очередей и воркеров. DevTime показал только низкую уверенность на основе зависимостей и тестов. Защита от ложных срабатываний (подавление сигналов от календарных чисток) сработала как гиперкоррекция.

Admin Permissions: полный пропуск

В репозитории есть настоящие админские интерфейсы: API-маршруты и настройки. DevTime ничего не обнаружил. Оба промаха станут регрессионными тестами, чтобы такое молчание не повторилось.

Забавная деталь: два старых теста в наборе были созданы из-за ложных срабатываний на Cal.com — подписки на календари ошибочно принимались за биллинг. Тогда мы исправили излишнюю уверенность. Сегодня Cal.com показал обратную крайность — излишнюю осторожность.

Честность о слепых зонах

Во время сканирования DevTime сам вывел предупреждение:

Framework coverage warning: NestJS controller parsing is not supported in V0;
backend route coverage may be incomplete.

API v2 Cal.com использует NestJS. Инструмент сам сообщил о своей слепой зоне до того, как я её нашёл.

Почему этот паттерн важен

Каждый современный инструмент оптимизирован под уверенность: саммаризаторы, автокомплиты, агенты — уверенность продаётся. Но заглушка вебхука в Cal.com — идеальный пример того, где уверенные инструменты ошибаются. История «этот репозиторий обрабатывает вебхуки Stripe» правдоподобна, подтверждена именами файлов — и ложна. Если бы ИИ-агент поверил, он мог бы модифицировать платёжную логику, которой нет в этой редакции.

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

Практический вывод

Попробуйте DevTime на своём репозитории прямо сейчас:

pipx install devtime-ei
cd your-repo
dtc init
dtc scan
dtc concepts

Есть также read-only MCP-сервер (dtc mcp start), чтобы кодинг-агенты могли запрашивать те же доказательства вместо догадок.

Если DevTime ошибётся на вашем коде — это не проблема, а вклад. Неверные результаты становятся тестами, а тесты — это то, как инструмент заслуживает доверие.