Преврати требования в технический план реализации
Разбивает продуктовые требования на последовательные технические шаги по данным, backend, UI и тестам.
1 Готовый промпт
Выступи в роли ведущего разработчика и преврати требования в технический план реализации. Требование: Добавить возможность подписываться на авторов и видеть список подписок.. Архитектура: ASP.NET Core MVC, EF Core, PostgreSQL, Identity; страницы авторов уже существуют.. Ограничения: Не менять текущую модель профиля и не вводить отдельный микросервис.. Следуй структуре: 1. Определи затрагиваемые части системы. 2. Опиши изменения модели данных и миграции. 3. Распиши backend-логику и контракты. 4. Опиши изменения UI, валидацию и ошибки. 5. Учти авторизацию и безопасность. 6. Добавь тесты, порядок внедрения и риски. Не придумывай факты, данные, опыт или ограничения, которых нет во вводных. Если информации недостаточно, укажи, что нужно уточнить.
Как использовать
Заполните поля конструктора максимально конкретно. Чем точнее исходные данные, тем полезнее будет результат.
2 Настроить под себя
Заполните понятные поля ниже. Сервис автоматически соберёт новую версию промпта под вашу задачу.
3 Результат настройки
Заполните конструктор выше,
и здесь появится готовый промпт.
4 Примеры результата
Текстовый пример
1. Затрагиваемые части системы EF Core-модели и DbContext; контроллеры/сервисы авторов и подписок; страницы авторов; новая страница «Мои подписки»; авторизация через Identity. 2. Модель данных и миграция Добавить отдельную сущность, например AuthorSubscription: FollowerId; AuthorId; дата создания подписки. Создать уникальный индекс на пару FollowerId + AuthorId, чтобы исключить дубликаты. Текущую модель профиля не изменять. 3. Backend-логика Нужны операции: подписаться на автора; отписаться; проверить статус подписки; получить список подписок текущего пользователя. Backend должен запрещать повторную подписку и обрабатывать попытки подписаться на несуществующего автора. 4. UI и ошибки На странице автора добавить кнопку «Подписаться / Отписаться». Добавить страницу со списком авторов, на которых подписан пользователь. При ошибке операции показывать понятное сообщение без изменения текущего состояния интерфейса. 5. Авторизация и безопасность Изменять подписки может только авторизованный пользователь. Идентификатор подписчика должен определяться на сервере через Identity, а не приниматься от клиента. Также нужно решить, разрешена ли подписка пользователя на самого себя. 6. Тесты, внедрение и риски Проверить: создание и удаление подписки; защиту от дубликатов; доступ неавторизованных пользователей; получение корректного списка подписок; конкурентные запросы на подписку. Порядок внедрения: модель → миграция → backend → UI → тесты. Нужно уточнить: можно ли подписываться на себя, нужна ли пагинация списка и должны ли отображаться количество подписчиков/подписок.
5 Комментарии
0