Как поставить задачу и определить готовность

Почему «сделай красиво» не помогает проверить результат

Вы просите «сделать нормальный менеджер задач». Агент добавляет категории, регистрацию и синхронизацию. Между тем вам нужен список на одном компьютере. Запрос позволил выбрать решение, но не объяснил границы задачи.

Хорошее описание соединяет пользователя, действие, наблюдаемый результат и ограничения. Начинайте с одного сценария: «Я добавляю задачу, закрываю программу и вижу её после следующего запуска». Затем укажите, как проверить этот сценарий и что сейчас делать не нужно.

Критерий приёмки — условие, по которому принимается работа. Спецификация — записанное описание поведения и ограничений. Спецификация может занимать полстраницы. Её ценность зависит от ясности, а не от длины.

Договор для нашего проекта

Пользователь: один человек на своём компьютере.
Цель: сохранять личный список задач между запусками.
Команды: add, list, done.
Хранение: выбранный JSON-файл, без сервера и аккаунта.
Добавление: название после обрезки пробелов не пустое.
Идентификатор: положительное число; задачи различимы.
Завершение: меняется только задача с указанным id.
Повреждённые данные: сообщить об ошибке, файл не менять.
Сейчас не нужны: сайт, платежи, синхронизация, удаление.

Допишите примеры. Название «Купить хлеб» принимается, строка из трёх пробелов отклоняется, завершение отсутствующей задачи не изменяет данные. Примеры переводят общие слова в конкретные случаи.

Обсудите неоднозначности до реализации. Показывать ли выполненные задачи? В курсе list показывает все задачи со статусом. Что значит завершить уже выполненную задачу? В нашем договоре это успешная операция без повторного изменения данных. Эти решения не универсальны; их нужно согласовать для конкретного продукта.

Запрос, который можно проверить

Реализуй только add в заготовке.
Название обрезается по краям; пустое название отклоняется.
Новая задача получает следующий id и done=false.
Если файл повреждён, не перезаписывай его.
Сначала назови файлы и проверки, затем сделай изменение.
Не меняй существующие критерии и тесты ради успеха.
В отчёте покажи команды, результаты и оставшиеся ограничения.

Попросите объяснить план в нескольких шагах. Если план включает сервер, остановитесь: он не связан с задачей. Небольшой план помогает увидеть неправильное понимание до появления большого diff.

При недостатке информации агент должен назвать допущение или задать вопрос. Человек тоже может разрешить допущение: «Для учебного проекта сортируй по id». Главное — сохранить решение там, где следующая сессия сможет его прочитать.

Самостоятельное задание

Создайте SPEC.md по шаблону из архива. Добавьте пять критериев приёмки: два обычных сценария, два ошибочных и один повторный запуск. Запишите минимум три функции, которые исключены из текущей работы. Пока не просите реализовать весь проект.

Критерии и разбор

Каждый критерий содержит входное действие и ожидаемый результат. «Надёжное хранение» заменено конкретным условием: например, «повреждённый JSON вызывает ошибку и сохраняется побайтно». Такой договор не покрывает сбой питания при записи; если это нужно, добавьте отдельное требование и проверку. Не расширяйте обещания за пределы описанных опытов.

Дальше: Подходы к разработке: прототип, план и маленькие шаги.