Баг, Который Прятался в Слое API

View стола загрузился. Canvas отрендерился. Стол существовал в базе данных.

Но когда front-end запросил у сервера текущее состояние стола — места, стеки, кто где сидит — сервер вернул 404. Ничего. Без мест, без данных игры, ничего, с чем мог работать renderer.

Canvas был пустым, потому что ему нечего было рисовать.

Вот техническое объяснение, как можно короче: API gateway перед table engine убирает префикс из каждого URL перед пересылкой запроса. /api/v1/tables/... приходит на table engine как /tables/.... Маршруты table engine, как написала сессия сборки, были зарегистрированы в ожидании полного префикса — то есть сервер слушал на /api/v1/tables/..., но получал /tables/.... Каждый запрос промахивался.

Не ошибка логики. Не сломанный алгоритм. Таблица маршрутизации с неправильными адресами. Тот тип проблемы, который всплывает только когда тестируешь полный стек вместе.

Сколько Времени Заняло Найти?

От старта до фикса: меньше часа.

Это быстро. Вот что сделало это быстрым: методология отладки.

Работа с AI-агентом над этим не означает спросить "что не так?" и надеяться на ответ. Это значит дать агенту правильный контекст одновременно — конфигурацию прокси, который обрабатывает префикс, файлы регистрации маршрутов в table engine, логи запросов, показывающие 404 — и попросить его проследить расхождение.

Когда эти части видны вместе, агент может делать pattern-matching по поверхности, на навигацию по которой человеку-инженеру потребовалось бы двадцать минут. Агент нашёл несоответствие между правилом rewrite прокси и регистрацией маршрута в table engine примерно за три минуты.

Баг За Багом

Нахождение бага маршрутизации обнажило следующий.

Endpoint теперь отвечал. Но данные, которые он возвращал, были в неправильном формате.

Table engine говорит на одном языке внутри: номера мест, статус-коды вроде occupied, сырые счётчики фишек как простые целые числа. Front-end renderer говорит на другом: индексы мест, форматированные строки валюты вроде $235.50, конкретные имена полей, которые он ожидает по контракту из определения типа, против которого был написан.

Никто не написал слой перевода. Сессия сборки написала endpoint, и он возвращал внутренний формат. Renderer получал данные, которые не узнавал, и молча производил ничего.

Это класс багов, для которых заведомо сложно написать тест заранее. Тебе нужно иметь обе системы запущенными, связанными и пытающимися поговорить друг с другом, чтобы увидеть это. Никакой unit test не покрывает разрыв между двумя системами, когда ни в одной из них самой по себе нет бага.

Что Это Значит для Методологии Сборки

Фаза тестирования не означает, что методология провалилась. Она означает, что методология довела нас до тестирования.

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

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

За инженерной методологией позади того, как мы строим — spec, сессии, что делает агент во время сессии, и что делает архитектор — полный текст на The Salty Korean.

Stay salty.