Skip to content

Sub-Issue (Work Package) Contract

Тип документа: Standard v2.0

(контракт для Sub-Issue / Work Package как самостоятельного проверяемого блока работы)

Purpose

Этот документ задаёт правила заполнения и ведения Sub-Issue / Work Package.

Sub-Issue / Work Package — это ограниченный блок работы внутри Epic Issue, который имеет собственный результат, acceptance tasks, delivery-связь и verification notes.

Operational Placement

Текущая операционная реализация Sub-Issue / Work Package для проектов DETai ведётся в ClickUp.

  • Sub-Issue / Work Package оформляется как подзадача Epic Issue или как связанная задача, если структура проекта требует отдельной верхнеуровневой задачи.
  • Она должна находиться в проектной папке ClickUp и в том проектном листе, который был явно передан пользователем.
  • Codex или другой агент должен использовать явно переданный пользователем ID / URL листа. Если лист не указан, агент должен запросить его у пользователя перед созданием задач.
  • Поле GitHub PR используется как URL-ссылка на Pull Request.
  • Поле GitHub Branch используется как текстовое имя ветки.
  • После завершения задача сохраняет историю выполнения через статус Complete.

GitHub остаётся code-facing delivery layer: ветка, Pull Request, review и изменения кода фиксируются там. ClickUp является operational planning layer: там фиксируются задача, статус, связи, поля и история выполнения.

1. Обязательная структура Sub-Issue / Work Package

1.1 Title

Название результата или deliverable.

1.2 Purpose

1–3 предложения:

  • какой результат появляется после завершения;
  • как это продвигает Goal родительской Epic Issue;
  • какие границы работы важны, чтобы Sub-Issue / Work Package не расползался.

1.3 Parent Epic Issue

Sub-Issue / Work Package должна быть связана с родительской Epic Issue.

Эта связь может быть выражена через:

  • ClickUp subtask relation;
  • ClickUp linked task relation;
  • явную ссылку на родительскую Epic Issue в описании, если техническая структура ClickUp не позволяет сделать связь иначе.

2. Acceptance Tasks

Внутри Sub-Issue / Work Package acceptance tasks оформляются как чекбоксы.

Каждый чекбокс представляет собой один Acceptance Task — проверяемый результат, который должен быть достигнут в рамках данного Work Package.

Правила:

  • каждый чекбокс = один Acceptance Task;
  • весь Sub-Issue / Work Package целиком = один Work Package;
  • рекомендуется 3–7 Acceptance Tasks на один Work Package;
  • внутри одного Acceptance Task рекомендуется 3–7 Implementation Steps;
  • под чекбоксом допускаются notes или короткие Implementation Steps;
  • acceptance task должен быть проверяемым, а не просто описывать активность.

2.1 Шаблон Acceptance Tasks

- [ ] <Acceptance Task #1 — проверяемый результат>
  1. <Implementation Step 1>
  2. <Implementation Step 2>

- [ ] <Acceptance Task #2 — проверяемый результат>
  1. <Implementation Step 1>
  2. <Implementation Step 2>

3. Delivery

В конце Sub-Issue / Work Package должен быть блок поставки.

## Delivery

Branch: `<branch-name>`
PR: `<PR URL>`

В ClickUp эти же значения должны быть отражены в полях:

  • GitHub Branch — текстовое имя ветки;
  • GitHub PR — URL-ссылка на Pull Request.

4. Verification Notes

Sub-Issue / Work Package считается завершённым только после финальной проверки результата.

Tip

Проверка должна отвечать на вопрос: «Привели ли выполненные Acceptance Tasks к реальному достижению заявленного результата?»