Comments 5
Для автономного агента этого мало. Что молча додумает:
Контракт/поведение
- Формат и валидация bookId (что значит "ends with 1"? строка, число, ISBN?). quantity > 0? userId формат?
- Что в ответе POST /orders/buy: тело, код (200/201?), что возвращается при REJECTED, тот же ли код что при CONFIRMED.
- Учитывается ли quantity при проверке наличия? available true, но quantity не хватает на запрошенное число что тогда? Спека про это молчит.
- "random" с каким распределением, seed-able ли для тестов.
Надёжность
- timeout сколько секунд. Retry есть или нет. Что считать "unavailable" (connection refused, 5xx, 4xx?).
- 4xx от Stock это 503 или другое?
Хранение
- Где хранятся заказы? InMemory? БД? Спека не сказала, агент выберет сам.
- Идемпотентность повторного buy.
Структура
- "Clean Architecture" агент разложит слои на свой вкус, два сервиса в одном решении или раздельно, общий контракт-проект или дублирование DTO.
- Порты, конфигурация адресов между сервисами (откуда Order знает URL Stock).
Прочее
- Тесты вообще нужны? Не сказано буду молча решать.
- Версии пакетов, .NET 9 RC vs GA.
Вывод: для happy-path демки хватит. Для автономного прогона без вмешательства нет, на каждой дырке агент примет произвольное решение, и расхождения всплывут только в готовом коде. Сюда бы такой шаблон: пусть агент сперва выпишет эти допущения и негативные примеры, и остановится.
Вместо этого вы крутите гача барабан "мне повезёт"
Посмотрел в гите, там более четко, да.
Но все же
Доменные контракты отсутствуют. "Создание заказа" и "проверка наличия" есть как фичи, но нет:
- схемы Order, OrderItem, Stock (поля, типы, обязательность)
- бизнес-правил (что при недостатке количества, статусы заказа, переходы)
- request/response DTO конкретных эндпоинтов
Это и есть мясо, его в SPEC нет совсем
Analyze — анализирует требования и превращает их в спецификацию.
Design — проектирует систему на основе утвержденной спецификации.
Develop — реализует систему согласно спецификации и архитектуре.
Review — проводит ревью кода и проверяет качество реализации.
Security — проверяет систему на уязвимости и риски.
Test Generation — создает тестовые сценарии.
Flow Orchestrator — управляет полным жизненным циклом разработки.
DocsExplorer — следит за актуальностью документации.
Вот здесь глобальный косяк в порядке пунктов.
Почему генерация тестов после разработки и ревью? Тесты тут, получается, просто для галочки? Генерим тесты из готового кода - ну отлично. Единственное, что они будут проверять - что в коде написано ровно то, что написано.
Код — больше не первая стадия: эксперимент с агентами