Павел Булкин – Вайб-кодинг. Практический курс (страница 5)

какие есть риски.

Вот как выглядит план, который проходит проверку. Это и есть ваш будущий артефакт PLAN_CREATE_TASK.md:

# PLAN_CREATE_TASK.md

## Задача

Добавить создание задачи (entity Task) в модуль tasks.

## Что НЕ входит в задачу

- комментарии;

- вложения;

- назначение задачи (assign);

- уведомления.

## Будут созданы

- src/tasks/dto/create-task.dto.ts

- src/tasks/task.entity.ts

- src/tasks/tasks.controller.ts

- src/tasks/tasks.service.ts

- src/tasks/tasks.repository.ts

- src/migrations/*-create-task.ts

- test/tasks/create-task.e2e-spec.ts

## Будут изменены

- src/tasks/tasks.module.ts (регистрация провайдеров)

## НЕ будут затронуты

- src/users/*

- src/auth/* (используем существующий guard только для аутентификации)

## Где бизнес-логика

- TasksService.createTask(): валидация, выбор teamId создателя и запись;

- бизнес-решения доступа — через TaskAccessPolicy/TaskAccessService, если такой слой уже есть; если нет — не создавать его в этой главе, а только не дублировать будущие правила.

## Модель данных

Task { id, title, description, status, createdById, teamId, assigneeId: uuid | null, archivedAt: Date | null, createdAt }

status: 'todo' | 'in_progress' | 'done' (default 'todo')

archivedAt != null означает архивную задачу; это не то же самое, что status='done'.

CreateTaskDto: title, description. assigneeId и archivedAt не принимать на этом этапе.

Лишние поля в DTO запрещаются через ValidationPipe whitelist + forbidNonWhitelisted или явно игнорируются и покрываются тестом.

## Тесты

- member может создать задачу;

- созданная задача принадлежит создателю (createdById);

- задача получает teamId создателя;

- статус по умолчанию 'todo';

- archivedAt по умолчанию null;

- неавторизованный запрос отклоняется;

- попытка передать assigneeId или archivedAt при создании не приводит к назначению или архивации.

## Риски

- дублирование проверки прав, если не использовать общий policy layer;

- расширение DTO лишними полями, особенно assigneeId до отдельной фичи assign.

## Rollback

- удалить новые файлы, откатить миграцию task.

## Порядок реализации

1. entity + DTO + миграция;

2. repository + service;

3. controller + маршрут POST /tasks;

4. тесты.

Когда перед глазами такой документ, ваш мозг переключается из режима «поиск опечаток» в режим «стратегический обзор». Кривой план правится одной фразой; кривой код после генерации — это часы отладки. Исправлять текст плана в сто раз дешевле, чем переписывать пятьсот сгенерированных строк.

Ошибки плана: красные флаги

Чаще проверять план придётся не на полноту, а на самодеятельность агента. Верните план на доработку, если видите хотя бы один из признаков:

КРАСНЫЕ ФЛАГИ

• агент хочет переписать архитектуру ради одной фичи;

• в плане нет тестов;

• нет списка файлов или нет раздела «что не делаем»;

• нет rollback;

• безопасность вынесена «на потом»;

• добавляется библиотека без объяснения причины;

• в плане фигурируют unrelated-файлы, не связанные с задачей.

Реакция на красный флаг — не «перепиши всё», а точечная правка. Например: «План слишком широкий. Убери изменения в src/users/. Не трогай auth — используй существующий guard. Сократи список файлов до минимально необходимого». Вы правите план, а не код.

Выполнение после утверждения

Только когда план вас устраивает, вы разрешаете писать код. Введите для себя жёсткое правило, которое мы пронесём через всю книгу:

ПРАВИЛО УТВЕРЖДЕНИЯ