Как выстроить рабочий процесс вайбкодинга на реальном проекте?

# Стек
- Python 3.11, FastAPI 0.104, SQLAlchemy 2.0 async
- PostgreSQL, Alembic для миграций
- Pytest + pytest-asyncio для тестов
- Pydantic v2 для валидации

# Соглашения по коду
- async/await везде где есть I/O
- типизация обязательна, mypy в strict режиме
- исключения через кастомные классы из app/exceptions.py
- логирование через structlog, print() запрещён
- переменные, комментарии, docstring — на английском

# Структура
- роутеры в app/routers/, один файл — один домен
- бизнес-логика в app/services/, не в роутерах
- модели SQLAlchemy в app/models/
- Pydantic-схемы в app/schemas/

# Запреты
- не хардкодить конфиг, только os.getenv()
- не смешивать бизнес-логику с HTTP-слоем
- не использовать select * в запросах

я делаю API для таск-менеджера.
стек: Python 3.11, FastAPI, PostgreSQL, Redis.
пользователи могут создавать проекты, добавлять задачи,
назначать исполнителей, получать уведомления.

помоги спроектировать:
1. структуру папок
2. модели базы данных (таблицы и связи)
3. список API endpoints
4. какие части стоит кэшировать в Redis

дай схему и объясни решения

# Вместо одного огромного промпта:
"сделай авторизацию"

# Разбейте:
1. "создай модель User: id, email, hashed_password, is_active, created_at"
2. "напиши UserService.create() и UserService.get_by_email()"
3. "напиши POST /auth/register с валидацией через Pydantic"
4. "напиши POST /auth/login, возвращает JWT через python-jose"
5. "напиши depends get_current_user для проверки JWT"
6. "напиши тесты для всех endpoint'ов"

# После каждого шага:
git add .
git commit -m "feat: add User model and UserService"

git add .
git commit -m "feat: add POST /auth/register endpoint"

git add .
git commit -m "feat: add JWT authentication"

git diff  # посмотреть что изменилось
git checkout -- app/services/auth.py  # откатить один файл
# или
git reset --hard HEAD~1  # откатить последний коммит

вот мои изменения:

[вывод git diff]

проверь:
- нет ли SQL-инъекций или уязвимостей
- нет ли необработанных исключений
- соответствует ли код rules-файлу
- что я мог забыть

напиши endpoint PATCH /tasks/{task_id} для обновления задачи.

модель Task:
class Task(Base):
    id: int
    title: str
    description: str | None
    status: str  # "todo", "in_progress", "done"
    assignee_id: int | None
    project_id: int
    created_by: int

требования:
- только автор задачи или assignee могут её обновлять
- нельзя менять project_id и created_by
- при смене статуса на "done" записывать completed_at
- возвращать обновлённую задачу в формате TaskResponse
- если задача не найдена — 404
- если нет прав — 403

этот сервис разросся до 400 строк, нарушает SRP.
вот код: [код]

покажи план разбивки на модули:
- каждый модуль — одна ответственность
- публичный интерфейс не должен измениться
- не меняй логику, только структуру

сначала только план, код после моего ок

напиши docstring для каждой публичной функции в этом файле.
стиль: Google docstring.
включай: описание, Args с типами, Returns, Raises:

[код файла]

напиши README для этого проекта.
разделы: что делает, быстрый старт, переменные окружения, API endpoints.
аудитория: разработчик который видит проект впервые.
добавь примеры curl-запросов для основных endpoints