Vibe coding промпты для CRUD приложения: набор copy-paste запросов для экранов, авторизации, ролей и API на Postgres, плюс разбор сбоев.
Цель обычно простая: получить рабочее CRUD-приложение целиком, чтобы можно было зайти, создать запись, увидеть ее в списке, отредактировать, удалить и при этом не сломать права доступа и данные. Но при vibe coding многие получают не продукт, а набор красивых кусочков: экран есть, API вроде есть, база «где-то подразумевается», а вместе оно не собирается.
Главная причина: модель охотно дополняет пробелы догадками. Если вы не зафиксировали границы и правила, она сделает самое очевидное (список и форму), а то, что держит приложение в реальности, забудет: миграции Postgres, обработку ошибок, роли, проверки доступа, единый формат ответов API.
Чаще всего ломается одно из пяти:
title, а backend ждет name, и все падает.error, то 500 без объяснений, то разные структуры JSON.Симптомы проявляются быстро. На фронтенде появляются бесконечные «непонятные» баги, потому что контракт между UI и API не закреплен. В базе копятся странные значения, потому что валидация разъехалась между клиентом и сервером. А при добавлении ролей внезапно выясняется, что логика доступа размазана по коду и ее трудно собрать.
Чтобы ответы стали стабильными, лучше идти в фиксированном порядке: сначала закрепить сущности, поля и имена, затем описать контракт API, потом схему Postgres (с миграциями и сидами), и только после этого генерировать экраны и RBAC.
Если вы делаете это в TakProsto, удобно вести проект одним чатом и каждый раз возвращаться к зафиксированному словарю: стек (React + Go + Postgres) и структура проекта меньше «расползаются» между шагами. Плюс помогает режим планирования, когда модель сначала согласует спецификацию, а уже потом пишет код.
Большинство переделок в CRUD начинается не из-за кода, а из-за размытых требований в промпте. Потратьте 10 минут на короткие ответы на вопросы ниже, и результат будет заметно ровнее: правильные таблицы, экраны и права, без бесконечных уточнений.
Выберите одну главную сущность, на которой держится смысл приложения, и 2-3 связанные. Не пытайтесь охватить все сразу.
Пример: «Заявки» (главная), «Клиенты» и «Исполнители» (связанные). Опишите связи простыми словами: у заявки один клиент, один исполнитель, много комментариев, есть история статусов.
Отдельно выпишите ключевые поля для каждой сущности. Для первой версии достаточно 6-12 полей.
RBAC ломается, когда роли названы, но не описано, что им можно. Достаточно коротких правил в формате «роль -> действия -> ограничения».
Например:
Если есть чувствительные поля (телефон, паспорт, сумма), отметьте отдельно: кому можно видеть, кому нельзя.
Чтобы UI не расползался, зафиксируйте обязательные экраны: вход, список, карточка, создание, редактирование. Затем добавьте 2-3 сценария, которые проверят связность всего приложения.
Пример сценария: «Менеджер создает клиента, затем создает заявку, назначает исполнителя, переводит в статус 'В работе', исполнитель добавляет комментарий, менеджер закрывает заявку».
Большая часть багов в CRUD - это не кнопки, а правила. Укажите явно:
Если нужен «мягкий» delete, так и напишите: «удаление = archived=true, запись не исчезает из базы».
Эти пункты редко вспоминают в промпте, и потом приходится чинить основу.
Коротко задайте ожидания: пагинация в списках, поиск по 2-3 полям, сортировка, обработка ошибок (понятные сообщения для пользователя), базовое логирование на backend (ошибка + контекст запроса без секретов).
Если работаете в TakProsto, полезно заранее попросить снапшоты перед крупными изменениями и возможность отката: это помогает спокойно экспериментировать с промптами и быстро возвращаться к стабильной версии.
Этот мастер-промпт задает «правила игры»: единый словарь, пошаговую генерацию и критерии готовности. Он особенно полезен, когда вы хотите, чтобы UI, API и БД совпали по именам.
Скопируйте текст и замените значения в фигурных скобках.
Ты - ведущий инженер и редактор требований. Сгенерируй full-stack CRUD приложение.
Цель: {КРАТКО: что за система и для кого}.
Основная сущность: {СУЩНОСТЬ, напр. "Заявка"}. Доп. сущности: {СПИСОК}.
Технологии (не предлагай альтернативы):
- Frontend: React
- Backend: Go
- Database: PostgreSQL
Правила ответа:
1) Работай по шагам. Сначала выдай ПЛАН (коротко), и задай до 7 уточняющих вопросов, если есть неоднозначности.
2) После моего ответа генерируй артефакты частями. На каждый шаг:
- что делаем
- какие файлы создаем/меняем (пути)
- сам код/SQL
- как проверить (ручные шаги)
3) Никаких ссылок. Никаких длинных эссе. Короткие блоки, точные названия.
Единый словарь (используй ровно эти имена везде):
- Сущность (таблица): {table_name_snake_case}
- API base path: /api/v1
- CRUD endpoints:
- GET /{plural}
- GET /{plural}/{id}
- POST /{plural}
- PUT /{plural}/{id}
- DELETE /{plural}/{id}
- Поля таблицы (пример, замени на мои):
- id (uuid, pk)
- title (text, required)
- status (text, enum: {СПИСОК})
- created_at, updated_at (timestamptz)
Требование согласованности:
- Имена полей в БД = JSON поля в API = поля форм в UI.
- Ошибки валидации должны совпадать по смыслу в UI и API.
- Роуты UI должны соответствовать сценариям.
Генерация по шагам (последовательно):
A) Модель данных: SQL схема, миграции up/down, индексы, ограничения, seed данные.
B) Backend: модели, репозитории, handlers, роутинг, валидация, пагинация и фильтры.
C) Auth + роли (RBAC): роли {СПИСОК РОЛЕЙ}, правила доступа по endpoints и экранам.
D) Frontend: экраны списка/карточки/создания/редактирования, состояния загрузки/ошибок, формы.
E) Проверки: чеклист сценариев, тестовые запросы, типовые ошибки и как их увидеть в логах.
Критерии готовности (Definition of Done):
- CRUD работает end-to-end: UI -> API -> Postgres.
- Есть минимум 2 роли, запрет на операции подтвержден.
- Миграции применяются с нуля без ручных правок.
- Seed создает минимум {N} записей и одного пользователя на роль.
- Есть список шагов для проверки: создать, изменить, удалить, проверить запреты.
Начни с ПЛАНА и списка уточняющих вопросов.
Если хотите меньше уточняющих вопросов, заранее впишите список ролей, точные поля сущностей и 3-5 реальных сценариев. Тогда генерация обычно идет ровнее и без переименований на ходу.
Чтобы интерфейс не превратился в набор разрозненных форм, сначала зафиксируйте карту экранов и сценарии. Один хороший промпт здесь экономит часы переделок.
Вставьте промпт и замените сущности под свой проект (например: «Заявки», «Клиенты», «Счета»).
Ты - продуктовый дизайнер и UX-редактор.
Сделай структуру экранов для CRUD-приложения.
Контекст:
- Приложение: админка + кабинет пользователя
- Сущности CRUD: \u003cСущность1\u003e, \u003cСущность2\u003e
- Роли: admin, manager, viewer
- Язык UI: русский
Нужно выдать:
1) Список страниц (название, цель, кто имеет доступ)
2) Основные пользовательские сценарии по ролям (по 5-8 шагов каждый)
3) Для каждой страницы: какие данные показываем, какие действия доступны
4) Правила: где нужен поиск, фильтры, сортировка, пагинация
Важно:
- Не придумывай лишние страницы.
- Сценарии должны покрывать: создание, редактирование, просмотр, удаление, массовые действия, экспорт (если уместно).
- Укажи, где нужен "нет доступа" и что показывать.
После ответа выберите 1-2 ключевых сценария (например, менеджер создает «Заявку» и отправляет на согласование) и уже под них просите генерацию компонентов.
Этот промпт помогает не забыть про пустые состояния, ошибки и доступ по ролям.
Ты - фронтенд-разработчик (React). Спроектируй UI компоненты и поведение.
Страницы: \u003cвставь список страниц из прошлого ответа\u003e
Роли и доступ: \u003cвставь матрицу доступа\u003e
Нужно:
A) Для каждой страницы перечисли компоненты:
- таблица (колонки, форматирование, действия в строке)
- форма (поля, типы, плейсхолдеры)
- модальные окна (подтверждение удаления, просмотр деталей)
- уведомления (успех/ошибка)
B) Обязательные состояния (опиши текст и поведение на русском):
- загрузка (скелетон или спиннер)
- пусто (когда нет записей)
- ошибка (когда API недоступен или вернул ошибку)
- нет доступа (403)
C) Маршруты и навигация:
- список маршрутов
- что видно в меню для каждой роли
- редиректы: неавторизован -> /login, нет доступа -> /forbidden
D) Валидация форм:
- обязательные поля
- форматы (email, телефон, дата)
- ограничения длины
- сообщения об ошибках на русском (коротко и понятно)
Выводи результат в виде четкой спецификации, без кода.
В TakProsto в конце можно добавить одно короткое требование: «Соблюдай единый стиль компонентов и названий». Это снижает шанс, что разные страницы будут выглядеть как из разных приложений.
Небольшая проверка перед генерацией кода: у вас должны быть (1) матрица доступа по ролям, (2) список маршрутов, (3) тексты всех ошибок на русском. Если чего-то нет, модель почти всегда начнет фантазировать.
Чтобы генерация не «сломалась» на базе, попросите конкретику: ключи, типы, ограничения, откат миграций и тестовые данные для быстрой проверки.
Сгенерируй схему Postgres для приложения.
Контекст:
- Сущности: [Users, Projects, Tasks, Comments]
- Основные сценарии: [пользователь создает проект, добавляет задачи, комментирует]
Требования к схеме:
1) Для каждой таблицы явно укажи: PK, обязательные поля (NOT NULL), уникальные поля (UNIQUE), внешние ключи (FK).
2) Типы данных подбирай практично (uuid/serial, timestamptz, text/varchar, numeric) и объясни выбор в 1 строке на таблицу.
3) Добавь технические поля: created_at, updated_at.
4) Для FK укажи on delete/on update (где CASCADE, где RESTRICT, где SET NULL) и почему.
5) Добавь индексы под частые запросы (поиск по статусу, по владельцу, по дате), но без фанатизма.
Вывод:
- Сначала полный SQL DDL (CREATE TABLE, CREATE INDEX, CONSTRAINT).
- Затем короткое описание связей (1-N, N-N) и список ключевых индексов.
Важно просить не только «вперед», но и «назад». Иначе вы упретесь в невозможность отката при ошибке.
Подготовь миграции Postgres в виде двух файлов на каждую миграцию: .up.sql и .down.sql.
Миграция 001_init:
- Создает все таблицы/индексы/ограничения из текущей схемы.
Миграция 002_change:
- Изменение: [пример: добавить поле priority в tasks (int, NOT NULL, default 0), сделать title UNIQUE внутри project_id]
Требования:
- В .down.sql откатывай изменения безопасно (сначала drop constraint/index, потом столбец/таблица).
- Если откат потенциально теряет данные, явно предупреди комментарием.
- Не используй нестабильные типы и не меняй тип столбца без плана миграции.
Вывод:
- Покажи содержимое файлов: 001_init.up.sql, 001_init.down.sql, 002_change.up.sql, 002_change.down.sql.
Тестовые данные должны учитывать порядок вставки и ключи, иначе вы получите ошибки FK и «пустые экраны».
Сгенерируй тестовые данные (seeds) для Postgres: 10-20 строк на ключевые таблицы.
Требования:
- Данные должны соответствовать ограничениям (NOT NULL, UNIQUE, FK).
- Сначала вставляй родительские сущности, затем дочерние.
- Используй реалистичные значения (имена, даты, статусы).
- Если PK uuid, используй фиксированные uuid (чтобы было удобно дебажить).
Вывод:
- Один SQL-блок с INSERT для всех таблиц.
- В конце 3-5 SELECT-запросов для быстрой проверки (например, задачи по проектам, количество комментариев по задаче).
После генерации прогоните seeds и сразу проверьте базовые выборки. Если что-то не сходится, чините на уровне схемы, а не «маскируйте» в API.
Чтобы backend получился предсказуемым, сначала зафиксируйте контракт API и правила: формат ответов, ошибки, права доступа, структура слоев и логирование. Дальше проще двигаться небольшими, проверяемыми шагами.
Сгенерируй backend API на Go (net/http или chi), Postgres.
Сущность: \u003cEntityName\u003e.
Нужно:
1) Эндпоинты CRUD:
- POST /api/\u003centities\u003e
- GET /api/\u003centities\u003e (список)
- GET /api/\u003centities\u003e/{id}
- PUT /api/\u003centities\u003e/{id}
- DELETE /api/\u003centities\u003e/{id}
2) Для списка поддержи:
- фильтры: \u003cперечисли поля и типы\u003e
- сортировка: sort=field:asc|desc
- пагинация: limit, offset
3) Опиши DTO (request/response) и примеры JSON.
4) Укажи коды ответов.
5) Ответы должны быть в едином формате (зафиксируй сейчас и используй везде).
Контекст:
- Postgres таблица: \u003ctable_name\u003e
- Поля: \u003cid uuid, ...\u003e
- Временные поля created_at, updated_at
Сначала выведи спецификацию API, потом код.
Добавь единый формат ошибок для всех хендлеров.
Требования:
- Формат успеха: {"data": ..., "meta": {...}}
- Формат ошибки: {"error": {"code": "...", "message": "...", "details": {...}}}
- Проставляй request_id в meta (если есть в контексте), иначе сгенерируй.
Покрой ошибки:
- 400: неверный JSON, валидация полей
- 401: не авторизован
- 403: нет прав
- 404: не найдено
- 409: конфликт (уникальный индекс)
- 500: прочее
Сделай маппинг ошибок БД Postgres (unique violation, foreign key) в коды.
Покажи 2-3 примера ответов.
И обнови код хендлеров, чтобы они использовали один helper для ответов.
Добавь проверки прав (RBAC) в каждый эндпоинт сущности \u003cEntityName\u003e.
Роли: admin, manager, viewer.
Правила:
- CREATE/UPDATE/DELETE: admin или manager
- READ (один и список): все роли
Требования:
- Проверка должна выполняться в начале каждого хендлера.
- Если прав нет, вернуть 403 в едином формате.
- Пользователь берется из middleware (context) как user_id и role.
- Добавь защиту от IDOR: при доступе к записи проверь, что она принадлежит tenant_id пользователя, если в модели есть tenant_id.
Покажи, где именно стоит проверка (код).
Рефакторни backend по слоям, чтобы было легко менять реализацию.
Структура:
- repository: работа с Postgres (SQL запросы), интерфейс + реализация
- service: бизнес-правила, валидация, транзакции, маппинг ошибок
- handler: HTTP слой, парсинг/ответы
Требования:
- Repository не знает про HTTP.
- Handler не содержит SQL.
- Для Create/Update сделай валидацию (обязательные поля, длины).
- Для List вынеси сбор фильтров/сортировки в отдельную структуру запроса.
Выведи дерево файлов и ключевые части кода.
Добавь журналирование для API.
Нужно логировать:
- request_id, user_id, role, метод, путь, статус, длительность
- при ошибках: code, message, (без утечки паролей/токенов), stack только в debug
- для 4xx: кратко и без паники
- для 5xx: подробно, с причиной и местом
Требования:
- Логи в JSON
- Один middleware для access log
- Отдельный helper для error log
- Примеры 2 лог-сообщений: успешный запрос и 500 ошибка
Обнови код так, чтобы логирование работало во всех эндпоинтах.
Если генерация начинает «плыть» (например, модель смешивает форматы ответов или забывает проверки), не переписывайте все сразу. Сначала попросите «показать спецификацию API и точки проверок», затем применяйте промпты 2-5 строго по очереди, чтобы изменения были локальными и проверяемыми.
Чтобы авторизация и роли работали предсказуемо, задайте их как отдельный контракт: что храним в Postgres, как проверяем права в backend, какие экраны и ограничения есть в UI.
Сначала выберите один вариант. Для большинства CRUD удобнее cookie-сессии (меньше возни на фронте). JWT подойдет, если нужен мобильный клиент и простая интеграция.
Ты генерируешь full-stack проект (React + Go + PostgreSQL).
Сделай авторизацию:
- Способ: cookie-сессии (httpOnly) ИЛИ JWT (access+refresh).
- Регистрация по email+пароль, вход, выход.
- Пароли хэшировать (bcrypt/argon2), добавить защиту от перебора.
- В Postgres: таблица users (id uuid, email unique, password_hash, is_active, created_at, updated_at).
- API: POST /auth/register, POST /auth/login, POST /auth/logout, GET /auth/me.
- UI: экраны Вход, Регистрация, Профиль (покажи email и роли).
Сгенерируй модели, роуты, обработку ошибок и минимальные тестовые запросы.
RBAC проще держать явным: роли отдельно, связь user-role отдельно. Права удобнее хранить как permission keys, чтобы не плодить условные ветки по коду.
Добавь RBAC.
Требования:
- Таблицы: roles(id, key unique, name), user_roles(user_id, role_id), permissions(id, key unique, description), role_permissions(role_id, permission_id).
- Предзаполни роли и права миграцией/сидами.
- Пример сущности: projects. Права: projects.read, projects.create, projects.update, projects.delete.
- API должен возвращать роли и permissions текущего пользователя в /auth/me.
- Важно: права проверяются на backend, фронт только скрывает кнопки.
Сгенерируй миграции, сиды и примеры запросов.
Короткий стартовый набор ролей, которого обычно хватает:
Частая поломка: RBAC сделан только на уровне UI. Попросите явные правила и защиту от доступа к чужим данным.
Реализуй проверки доступа в Go.
- Сделай middleware RequireAuth и RequirePermission("\u003cpermission\u003e").
- Если нет сессии/токена: 401. Если нет прав: 403.
- Для сущностей с владельцем (owner_id) добавь проверку: пользователь может читать/править только свои записи, кроме роли admin.
- Во всех SQL-запросах добавь фильтр по owner_id там, где нужно.
- Добавь логику аудита: created_by, updated_by для projects.
Сгенерируй примеры защищенных роутов CRUD и поясни, где именно стоят проверки.
Пример сценария: админ заходит в раздел «Пользователи», находит сотрудника, назначает роль manager, и тот получает право создавать проекты.
Добавь админский UI и API для управления пользователями и ролями.
- Только role=admin может: список пользователей, активация/деактивация, назначение ролей.
- API: GET /admin/users, PATCH /admin/users/{id} (is_active), PUT /admin/users/{id}/roles.
- UI: таблица пользователей, модалка назначения ролей, уведомления об ошибках.
- Валидация: нельзя снять последнюю роль admin с единственного админа.
Сгенерируй компоненты React и обработчики Go.
Мини-чек по угрозам, который стоит проговорить явно: лимит попыток входа и задержка при ошибках, единые сообщения об ошибке (не выдавать, есть ли email), защита токена (httpOnly cookie, короткий срок жизни), запрет доступа к чужим данным через owner_id фильтры, логирование админских действий (кто кому назначил роль).
После генерации самая частая ошибка - поверить «похоже работает» и пойти дальше. Лучше за 20 минут сделать сиды, короткий ручной прогон и минимальную диагностику. Так вы поймаете большинство проблем: роли не режут доступ, валидации дырявые, списки тормозят, UI молча глотает ошибки.
Сгенерируй сидинг (seed) для Postgres и минимальные инструкции запуска.
Контекст приложения:
- Сущности: \u003cвставь свои сущности и поля\u003e
- Статусы/перечисления: \u003cdraft/active/archived или свои\u003e
- Роли (RBAC): admin, manager, user (если есть другие - добавь)
Нужно:
1) Создать 6-9 пользователей:
- 1 admin
- 2 manager
- 3-6 user
Для каждого: email, пароль (простые тестовые), роль.
2) Сгенерировать данные для CRUD:
- минимум 30 записей на основную сущность
- данные должны быть “живые”: разные статусы, даты, связи, суммы/цены, комментарии
- обязательно добавить 3-5 “пограничных” записей: пустые optional поля, длинные строки, необычные символы
3) Добавить связи между таблицами (если есть): чтобы были и “полные” связи, и случаи без связи.
4) Дать итог: файлы/скрипты для seeds и команду запуска.
Проверь, что сиды идемпотентны или объясни, как безопасно перезапускать.
После этого попросите добавить «проверочные метки»: например, один заказ с суммой 9999, один пользователь с фамилией из 40 символов, один объект в статусе archived. Это ускоряет ручную проверку.
Ручной прогон (10 шагов, без воды):
Составь 10 шагов ручной проверки приложения, чтобы за 10-15 минут понять, что CRUD + авторизация + роли работают.
Требования:
- Шаги должны использовать сидовые аккаунты admin/manager/user
- В каждом шаге укажи: кто (роль), где (экран/API), действие, ожидаемый результат
- Покрой: логин/логаут, просмотр списка, поиск/фильтр (если есть), создание, редактирование, удаление, запрет по ролям, обработку ошибок валидации
- Последний шаг: проверка, что данные реально записались в Postgres (какой признак в UI или какой endpoint/лог это подтверждает)
Тест-кейсы (простые позитивные и негативные):
Сгенерируй набор простых тест-кейсов для CRUD и RBAC.
Формат: таблица (Название, Предусловия, Действия, Ожидаемый результат).
Нужно:
- 6 позитивных кейсов (создание/чтение/обновление/удаление, поиск, пагинация если есть)
- 6 негативных кейсов (пустые поля, слишком длинные значения, неверный формат email/даты, доступ без роли, доступ без токена, попытка удалить чужую запись)
Без сложной терминологии, как для ручной проверки.
Диагностика и наблюдаемость (куда смотреть и что логировать):
Добавь диагностику для UI и API.
Нужно:
1) UI (React):
- где показывать пользователю ошибку (toast/баннер/инлайн)
- как логировать ошибку в консоль с контекстом (endpoint, статус, тело ответа)
2) API (Go):
- какие поля логировать для каждого запроса (method, path, status, latency, userId, role, requestId)
- как логировать ошибки БД отдельно (код, текст, запрос/таблица)
3) Дай чеклист: где искать причину, если UI “молчит”, а запрос падает.
Не добавляй внешние сервисы. Достаточно логов и понятных сообщений.
Если приложение начинает «тупить» на списках, используйте отдельный промпт на ограничения:
Проверь ограничения для больших списков и медленных запросов.
Нужно:
- Ввести пагинацию (limit/offset или cursor) для списков
- Добавить таймауты и понятные ошибки
- Предложить индексы для частых фильтров/сортировок
- Сформулировать 5 быстрых проверок производительности (что нажать/какой запрос сделать и что считать плохим)
Сделай предложения конкретно под мои сущности и поля: \u003cвставь сущности\u003e.
Совет: перед рискованными правками делайте snapshot, чтобы можно было быстро откатиться, если модель «починит» одно и сломает другое.
Даже хороший промпт иногда уводит генерацию в сторону: модель начинает придумывать поля, UI расходится с API, миграции забываются. Лучше работать от жесткого контракта и каждый раз возвращать модель к нему.
Перед исправлениями зафиксируйте четыре якоря и не меняйте их без отдельного решения:
Дальше правьте точечно, а не просите «переделай все заново».
Сбой 1: модель перепридумала поля. Верните ее к словарю и запретите добавления.
У нас есть утвержденный словарь сущностей (ниже). Твоя задача: обновить только код/формы/DTO под него.
Запрещено: добавлять новые поля, переименовывать поля, менять типы.
Если видишь несоответствие, составь список: (где) -> (как исправить) и затем внеси правки.
Словарь:
[вставьте таблицу полей]
Сбой 2: UI и API не совпадают (поля, валидации, статусы). Попросите синхронизацию от контракта к обоим слоям.
Синхронизируй UI и API по контракту ниже.
1) Проверь формы и таблицы на экранах: какие поля показываем/редактируем.
2) Проверь запросы: какие поля отправляем/получаем.
3) Выровняй валидации (обязательные, длины, форматы).
4) Итог: список изменений + патчи.
Контракт API:
[вставьте эндпоинты и схемы]
Сбой 3: забыты роли. Попросите матрицу прав и проверку покрытия.
Сформулируйте так: опишите роли (например, admin, manager, user), затем попросите таблицу «эндпоинт -> роли -> правило». После этого отдельно попросите пройтись по всем обработчикам и показать, где именно стоит проверка (middleware/guard), и какие ответы при запрете (401 vs 403).
Сбой 4: нет миграций или они не откатываются. Требуйте минимальный набор миграций и down-часть.
Сгенерируй минимальный набор миграций для Postgres под схему ниже.
Требования: up и down для каждой миграции, порядок выполнения, ограничения FK/unique/index.
Покажи также команду/шаги проверки: применить, накатить сиды, откатить, снова применить.
Схема:
[вставьте таблицы и связи]
Сбой 5: ошибки без объяснений. Иначе вы будете гадать.
Полезная формула: «Сначала дай диагноз: почему не компилируется/падает тест. Потом план из 3-5 шагов. Затем внеси правки и перечисли измененные файлы».
Сбой 6: слишком много кода за раз. Дробите на части и фиксируйте версии.
Просите изменения блоками: сначала схема и миграции, потом репозитории и DTO, затем хендлеры, потом UI. Между шагами делайте snapshot, чтобы откатиться, если следующий кусок сломает предыдущий.
Когда вы уже получили первые экраны и API, главная задача - быстро поймать несостыковки, пока они не размножились.
Перед запуском пройдите короткую проверку:
Дальше проверьте согласованность. Частая причина поломок: одно и то же называется по-разному в слоях. Сущность, поля и статусы должны совпадать везде: в Postgres, в DTO, в обработчиках API, в формах и в таблицах на UI. Если переименовали поле (например, ownerId в user_id), сделайте это сразу во всем проекте, иначе получите «тихие» баги.
Мини-план на 60 минут помогает не застревать в бесконечных правках:
Чтобы приложение стало «живым», добавьте одну-две реальные фичи, которые проверяются за 10 минут. Обычно это поиск с фильтрами, статусы (черновик/активно/архив), экспорт в CSV или журнал действий (кто и когда менял запись).
Если собираете это в TakProsto, удобно начинать с режима планирования, а затем фиксировать рабочие этапы снапшотами. Когда результат устраивает, можно экспортировать исходники, а деплой, хостинг и подключение домена делать уже на стабильной сборке. Для справки платформы достаточно помнить имя проекта и хоста: TakProsto, takprosto.ai.
Зафиксируйте «якоря» до генерации:
up/down, индексы, ограничения, seedПосле этого просите генерацию строго по шагам (БД → API → auth/RBAC → UI) и не меняйте имена на ходу.
Дайте модели короткую, но жесткую спецификацию:
Чем меньше «белых пятен», тем меньше фантазии и переименований.
Выберите один «единый словарь» и зафиксируйте его как правило:
snake_caseПрактичный прием: прямо написать требование «Имена полей в БД = JSON в API = поля форм в UI. Запрещено переименовывать». Если нужно переименование — делайте его отдельным шагом с перечнем файлов, где меняется.
Нормальный базовый порядок такой:
up/down + индексы + ограниченияЕсли начать с UI, модель почти всегда «дорисует» недостающие сущности и правила вместо того, чтобы согласовать их.
Просите миграции не «DDL текстом», а как артефакты:
001_init.up.sql и 001_init.down.sqlNOT NULL/UNIQUE/FK прямо в SQLИ отдельно попросите команду проверки: применить миграции с нуля → накатить seeds → откатить → снова применить. Это быстро выявляет «одноразовые» схемы.
Сформулируйте RBAC в 5–8 строках в формате «роль → действия → ограничения». Например:
Затем требуйте, чтобы проверки были на backend (middleware/guard) и выполнялись в начале каждого обработчика. UI должен только скрывать кнопки, но не «защищать».
Попросите 2 уровня защиты:
read/create/update/deletetenant_id или owner_id) при доступе к конкретной записиИ важное правило: фильтр по tenant_id/owner_id должен быть не только в UI, а в SQL-запросах на чтение/обновление/удаление. Это закрывает типичную дыру «угадай id и увидишь чужое».
Зафиксируйте единый формат и маппинг кодов:
{"data": ..., "meta": {...}}{"error": {"code": "...", "message": "...", "details": {...}}}Минимум покрыть:
Попросите обязательные «состояния» для каждой страницы:
И добавьте 2–3 пользовательских сценария на 5–8 шагов. UI тогда строится вокруг потока действий, а не вокруг набора несвязанных форм.
Используйте возможности платформы как дисциплину процесса:
Так вы снижаете шанс, что стек (React + Go + Postgres) и структура проекта «расползутся» между шагами.
Отдельно попросите маппинг ошибок Postgres (unique violation, FK violation) в 409/400, иначе получите хаос вида «200 + error текстом».