5.3 KiB
MODIFIED Requirements
Requirement: Пакет и порядок выполнения
Пакет SHALL создаваться одним вызовом с автором, заголовком и списком команд; хаб SHALL назначить seq по порядку списка
и добавить в хвост refresh по всем ключам пакета (кроме пакетов, состоящих только из refresh). Пакет с двумя и более
ensure_issue с одинаковой summary (после обрезки пробелов по краям) SHALL отвергаться (422). Очередь SHALL выдавать
команды в порядке (batch.created_at, seq), одну в полёте. Пакет и его queued команды MAY быть отменены; claimed
команда MUST NOT отменяться автоматически.
Scenario: Оценка длительности
- WHEN создаётся пакет из 3
ensure_fieldsи 2ensure_comment - THEN
estimate_seconds= сумма пауз по политике для последовательности типов + паузаrefresh
Scenario: Две задачи с одной темой
- WHEN пакет содержит
ensure_issue {temp_key: new:1, summary: "Отчёт"}иensure_issue {temp_key: new:2, summary: " Отчёт "} - THEN 422 с темой «Отчёт», пакет не создан
Requirement: Ошибки и подтверждение по состоянию
Ошибка команды SHALL записываться в error (HTTP-код, текст Jira до 1500 символов), пакет продолжается.
Повторная выдача. Агент запрашивает новую команду, только когда у него нет незавершённой (см. agent), поэтому
команда в claimed к моменту следующего claim считается не доставленной или потерянной агентом. При claim хаб SHALL
сначала выдать снова самую старую (по claimed_at, затем id) команду в claimed: тот же id и параметры,
pause_seconds по текущей политике темпа, новый claimed_at, deliveries + 1. Если у неё уже deliveries >= 3, хаб SHALL
перевести её в failed с error = "агент не отчитался после 3 выдач" и перейти к следующей (довыдача другой claimed
или следующая queued). Довыдача — доставка той же выдачи, а не повтор команды: новых команд хаб MUST NOT создавать
сам, повтор после failed — новая команда с теми же параметрами по запросу интерфейса.
Подтверждение по состоянию. Если после любого refresh желаемый результат команды в claimed виден в зеркале, хаб
SHALL перевести её в confirmed_by_state: ensure_fields — все поля совпадают; ensure_status — статус равен последнему
в пути; ensure_link — связь есть и конфликтов нет; ensure_sprint — спринт совпадает. ensure_issue, ensure_comment
и refresh по состоянию не подтверждаются: потерянный отчёт по ним закрывается повторной выдачей (агент находит
созданную задачу поиском дубля) или отменой человеком.
Scenario: Отчёт потерян, факт на месте
- WHEN
ensure_sprint {key: X, sprint: "Спринт 2"}вclaimed, после выполненногоrefreshзеркало показывает X в «Спринт 2» - THEN команда
confirmed_by_state
Scenario: Ответ на claim потерян
- WHEN команда 40 выдана (
deliveries = 1), ответ до агента не дошёл, агент снова прислалclaim - THEN
claimотдаёт команду 40,deliveries = 2; в очереди естьqueuedкоманды, но выдаётся 40
Scenario: Предел выдач
- WHEN команда 41 в
claimedсdeliveries = 3, агент снова прислалclaim, в очереди есть команда 42 - THEN 41 —
failed«агент не отчитался после 3 выдач»;claimотдаёт 42
Scenario: Потерянный отчёт о создании задачи
- WHEN
ensure_issue {temp_key: new:5, summary: "Отчёт"}выполнена агентом, отчёт не дошёл, агент прислалclaim - THEN команда выдаётся снова; агент находит созданную задачу поиском дубля и отчитывается
doneс её ключом; второй задачи нет, заметкаnew:5перенесена на ключ