«Добавь подписку на задачу» звучит достаточно конкретно, пока не нужно выбрать получателя письма. Подписаться может любой пользователь или только участник проекта? Повторное нажатие создаёт вторую подписку? После потери доступа письма продолжают приходить? Ответы меняют реализацию сильнее, чем выбор имени сервиса.
Разберём учебную задачу для приложения с проектами и задачами. Это пример постановки, а не рассказ о выполненном заказе. Предположим, в приложении уже есть пользователи, проверка доступа и отправка уведомлений через очередь. Наличие этих механизмов агент ещё должен подтвердить по коду.
Сначала опишите изменение для пользователя
Цель можно записать так: участник проекта подписывается на конкретную задачу и получает уведомление при изменении её статуса. На той же странице он может отписаться. Здесь уже есть наблюдаемые действия и результат. Но пока нет решения о повторных запросах, смене доступа и событиях, которые должны запускать отправку.
Не заставляйте агента угадывать эти условия. Для упражнения выберем: повторная подписка не создаёт дубль; изменение заголовка не вызывает письмо; отписка исключает пользователя из последующих отправок; отсутствие доступа к проекту запрещает подписку. Проверку права получать уведомление нужно обсудить и для момента отправки: задача в очереди может выполняться позже изменения доступа.
Последний пункт показывает, зачем отделять продуктовый выбор от технического. Человек решает, что бывший участник не должен получать новые данные проекта. Агент исследует, где в существующем приложении можно обеспечить это правило.
Граница задачи должна объяснять, что вы отложили
Подписка легко разрастается в центр уведомлений с каналами, дайджестами и настройками частоты. Для выбранной задачи достаточно существующего канала писем и двух действий на странице. Остальное можно перечислить как отдельные будущие возможности, не объявляя их плохими решениями.
При этом граница не должна исключать необходимое условие. Если отписка входит в обещание пользователю, нельзя убрать её из объёма ради маленького изменения. Если текущая отправка допускает повторную доставку события, фраза «ровно одно письмо при любых обстоятельствах» потребует отдельного технического обоснования. Не обещайте это до исследования транспорта и способа учёта отправок.
Задача: подписка участника на смену статуса одной задачи.
Поведение:
— повторная подписка не создаёт вторую запись;
— отписка отключает последующие уведомления;
— изменение заголовка не отправляет письмо;
— пользователь без доступа не может подписаться и получать данные.
Используем существующий канал уведомлений.
Дайджест, новые каналы и общие настройки пользователя сейчас не добавляем.
До изменения проверь путь события и отправки, способы проверки доступа.
Отдельно назови нерешённые условия повторной доставки.Не заполняйте неизвестные места названиями будущих классов
На этом этапе не нужно требовать ровно одну миграцию, семь файлов и один тест. В репозитории может уже существовать подходящая таблица связей или сервис уведомлений. Перечень вымышленных путей заставит исполнителя подгонять проект под заранее нарисованную структуру.
Полезнее обозначить зоны исследования: модель задачи, граница доступа, обработчик смены статуса, очередь, отображение кнопки. Попросите отделить найденное от предлагаемого. «Есть обработчик» должен сопровождаться указателем на код; «понадобится таблица» остаётся предложением до проверки существующей схемы.
Если задача пока сформулирована как «подписка работает странно», сначала нужен воспроизводимый случай. Структура постановки помогает уточнять решение, но не заменяет диагностику. Не выбирайте причину заранее только ради заполненного шаблона.
Проверка описывает поведение, а не количество тестов
Для этого примера полезны разные сценарии: разрешённая подписка, повторный запрос, отписка, отказ без доступа, событие без изменения статуса. Они отвечают на разные вопросы. Один успешный тест отправки не доказывает отсутствие дублей или корректность проверки прав.
В постановке можно попросить агента показать, какие проверки уже есть в проекте и чем он дополнит их. Если отправка замещена тестовым транспортом, отчёт должен прямо говорить об этом. Запись письма в тестовый транспорт не доказывает доставку через настоящий почтовый сервер.
В результате покажи:
1. Какие условия реализованы и где.
2. Какие сценарии фактически проверены, какой командой.
3. Что осталось непроверенным и почему.
4. Какие решения потребовались сверх исходной постановки.
Не отмечай сценарий выполненным только потому, что написал для него тест.Уточнение постановки — часть работы
Агент может обнаружить, что право читать задачу и право получать уведомления сейчас расходятся. Здесь нужен выбор владельца задачи, а не более строгий промпт. Зафиксируйте решение и продолжайте уже согласованные действия без повторных разрешений на каждое чтение файла.
Для следующей задачи не обязательно копировать все блоки. Сохраните то, что предотвращает конкретную неопределённость: наблюдаемое поведение, границу изменения, открытый вопрос и способ проверки. Полезная постановка заканчивается моментом, когда вы можете отличить подходящее решение от просто убедительного ответа.
