@jakerdy/agentica 0.0.2

package/templates/feature/FT-0000 - /320/235/320/260/320/267/320/262/320/260/320/275/320/270/320/265 /321/204/320/270/321/207/320/270 /320/270/320/273/320/270 /320/274/320/276/320/264/321/203/320/273/321/217 XXX/validation.md"

@@ -0,0 +1,31 @@
+# FT-0000 - Критерии валидации - Название фичи или модуля XXX
+
+
+## Инструментальная проверка
+
+- [ ] VAL-001: Покрытие кода юнит-тестами должно быть не менее 80%. `bun test --coverage` должен показывать покрытие не менее 80% для всех файлов.
+- [ ] VAL-002: Все юнит-тесты должны проходить успешно. `bun test` должен завершаться с кодом 0.
+- [ ] VAL-003: Проект должен компилироваться без ошибок и предупреждений. `bun typecheck` и `bun typecheck:tests` должны завершаться успешно.
+- [ ] VAL-004: Линтер не должен выдавать ошибок и предупреждений. `bun lint` должен завершаться успешно.
+- [ ] VAL-005: Форматтер не должен выдавать изменений. `bun format` должен завершаться успешно.
+- [ ] VAL-006: Все изменения должны быть закоммичены и запушены в удаленный репозиторий. `git status` должен показывать чистое рабочее дерево.
+- [ ] VAL-007: Сборка/пакетирование (если предусмотрено проектом) должно проходить успешно без ошибок. Например: `bun run build` (или эквивалентный скрипт/команда) должен завершаться с кодом 0.
+- [ ] VAL-008: Установка зависимостей должна быть воспроизводимой. `bun install --frozen-lockfile` (или эквивалент) не должен менять lockfile и должен завершаться с кодом 0.
+- [ ] VAL-009: Проверка на whitespace/merge-артефакты должна проходить успешно. `git diff --check` не должен выводить ошибок.
+- [ ] VAL-010: В репозитории не должно оставаться незакоммиченных генерируемых артефактов (build output, snapshots, codegen) и случайных изменений файлов (например, форматирование вне затронутой области), если это не является частью задачи.
+
+
+## Семантическая проверка
+
+- [ ] VAL-101: Реализованная функциональность должна соответствовать требованиям, описанным в продуктовой документации.
+- [ ] VAL-102: Все пользовательские истории должны быть реализованы и удовлетворять критериям приемки.
+- [ ] VAL-103: Все User-Stories должны быть покрыты e2e тестами, которые проверяют полный пользовательский сценарий с использованием этой фичи или модуля.
+- [ ] VAL-104: Контракты, интерфейсы и классы должны быть реализованы в соответствии с техническим заданием (из `./tech.md`). Если это не так, нужно вывести полный список расхождений между реализацией и техническим заданием.
+- [ ] VAL-105: Все таски из `./tasks.md` должны быть выполнены. Если это не так, нужно вывести полный список невыполненных тасков.
+- [ ] VAL-106: Экспортированное публичное API должно иметь документацию в виде JSDoc комментариев, с семантическим описанием назначения каждого метода, его параметров, возвращаемого значения и возможных исключений. Комментарий не должен содержать пересказ кода метода.
+- [ ] VAL-108: Изменения публичного API не должны быть breaking без явного описания. Если breaking изменения неизбежны — должна быть добавлена заметка о миграции (в документацию фичи) и тест(ы), покрывающие новый путь.
+- [ ] VAL-109: Обработка ошибок должна быть консистентной: ошибки не должны «проглатываться», сообщения об ошибках должны быть полезными, а ожидаемые исключения/ошибки — описаны в документации API.
+- [ ] VAL-110: На границах системы (CLI ввод, HTTP, чтение файлов, env, внешние интеграции) должна быть валидация входных данных. Не должно быть очевидных уязвимостей класса injection/path traversal/unsafe eval при обработке пользовательских данных.
+- [ ] VAL-111: В коде не должно оставаться временных следов разработки: отладочных логов, закомментированного кода, а также `TODO`/`FIXME` без ссылки на задачу/issue.
+- [ ] VAL-112: При изменении форматов данных/конфигов/контрактов должна быть описана совместимость и/или миграция (что меняется, как обновиться, что будет при старых данных) и добавлены проверки/тесты на критичные кейсы.
+- [ ] VAL-113: Пользовательская документация (если имеется) должна быть обновлена, если менялось поведение/CLI/конфигурация: примеры использования, описание опций, ограничения и expected behavior должны соответствовать текущей реализации.