Правила Постановки Задач

Назначение

Постановка задачи в Pin является рабочим контрактом между аналитиком, архитектором, разработчиком, QA, DevOps и владельцем процесса. Документ должен быть достаточным для реализации, тестирования, выпуска и сопровождения без домыслов.

Основной Принцип

Постановка должна описывать не намерение "сделать фичу", а проверяемое изменение системы:

• что меняется;
• где меняется;
• кто имеет право это сделать;
• какие данные участвуют;
• какие ограничения и риски есть;
• как понять, что результат корректен.

Обязательные Разделы

Каждая постановка содержит:

• цель и бизнес-результат;
• scope in/out;
• actors, permissions и approval requirements;
• входные данные, источники и валидацию;
• выходные данные и masking rules;
• затрагиваемые сервисы, сущности, модели, события, фоновые процессы и внешние системы;
• подробный алгоритм;
• побочные эффекты (если есть);
• observability и audit;
• failure modes и edge cases;
• acceptance criteria;
• ссылки на общий DoR/DoD.

Обязательная Конкретика

В постановках запрещены размытые формулировки без привязки к данным и поведению.

Размытая Формулировка	Что Должно Быть Вместо Нее
проверить доступ	указать policy <policy-name>, permission <permission-name>, MFA-требование и scope
получить запись	загрузить <EntityName> по <business key> с учётом tenant и прав видимости
обновить данные	изменить поля <field list> по правилам <rule list>
выполнить валидацию	проверить <конкретные условия, диапазоны, enum values, reference ids>
отправить событие	зафиксировать событие <EventName> v<major> (ключ — <business key>)
обновить отчет	пересчитать <витрину/агрегат> по правилам <rule list>

Если шаг нельзя описать конкретно, задача не готова к реализации.

Тип Операции

Постановка должна явно указывать тип операции и что для него обязательно описать:

Тип	Что Обязательно Указать
Изменение данных	кто имеет право; какие сущности и поля меняются; какие бизнес-правила и переходы статусов применяются; что фиксируется атомарно; идемпотентность как поведение при повторе; какие события публикуются; аудит
Чтение	кто имеет право; источник данных (сущность/витрина); фильтры, сортировка, пагинация; актуальность (freshness); правила маскирования
Обработка события	какое событие потребляется; какой эффект в бизнес-терминах; поведение при повторной доставке (идемпотентность) и при сбое (retry/DLQ)
По расписанию	триггер и расписание; входные данные и размер порции; поведение при повторном запуске; сверка и наблюдаемость

Definition Of Ready И Done

Базовые правила вынесены в Definition Of Ready И Definition Of Done. В самой постановке должны быть зафиксированы только task-specific дополнения, исключения или риски сверх общего стандарта.

Acceptance Criteria

Acceptance criteria должны быть проверяемыми.

Разрешенный формат:

• при <условие> система создает <сущность/событие/запись аудита>;
• при <повторный запрос> результат <идемпотентен/отклоняется с кодом ...>;
• при <ошибка зависимости> система <fail closed/retry/puts into manual queue>;
• в dashboard <dashboard-name> появляется <metric/log/trace> с <tags>.

Запрещенный формат:

• работает корректно;
• ошибки обработаны;
• данные сохраняются;
• доступ проверяется.

Обратные ссылки

Автоссылки: где используется этот документ.

• spec-authoring-altitude-rules.md (1): Уровень изложения ТЗ (analyst altitude)