6.3 KiB
work_item, stage, author_agent, status, created_at, model_used, track
| work_item | stage | author_agent | status | created_at | model_used | track |
|---|---|---|---|---|---|---|
| ORCH-106 | analysis | analyst | ready-for-review | 2026-06-12 | claude-opus-4-8 | bug |
02 — ТЗ (TRZ, bug-shaped): ORCH-106 — Fix onboard_project.py: add color field for state creation
Work Item: ORCH-106 · Repo: orchestrator · Стадия: analysis · Трек: 🐞 Bug
Облегчённое ТЗ багфикс-трека: фиксирует конкретное изменение тела запроса, выведенное из bug-report (
01-brd.md) и фактического кода. Архитектурного обоснования нет (стадияarchitectureпропущена для bug-трека) — изменение точечное.
1. Сводка изменения
В PlaneClient.create_state (scripts/onboard_project.py, строки 424-428) тело запроса
POST …/projects/<id>/states/ дополняется обязательным для Plane CE полем color (валидная
непустая hex-строка). Сейчас тело — {"name": name, "group": group}; после фикса —
{"name": name, "group": group, "color": <valid-hex>}. Поведение _post, цикл онбординга,
сигнатуры и прочие методы не меняются. Добавляется обязательный регресс-тест.
2. Задействованные модули / пути
| Путь | Действие |
|---|---|
scripts/onboard_project.py |
изменить — PlaneClient.create_state: добавить color в тело POST |
tests/test_onboarding_script.py (или новый tests/test_onboard_state_color.py) |
создать/дополнить — регресс-тест на наличие валидного color в теле create_state |
Выбор файла теста — на усмотрение developer; ключевое требование — тест экзерсайзит реальный
PlaneClient.create_state(через перехват_post/httpx.post), а неFakePlaneиз существующего набора (мок не строит реальное тело и баг не ловит).
3. Функциональные требования
FR-1 — color в теле создания статуса (BR-1, BR-3)
create_state ДОЛЖЕН включать в тело POST ключ color с валидной непустой hex-строкой для
каждого создаваемого статуса. Инвариант: ни один путь create_state не отправляет тело без
color (либо с пустым/null color).
FR-2 — Сценарий STOP (BR-2)
Создание статуса с именем STOP (группа cancelled, STATE_GROUPS["STOP"]) формирует тело с
непустым валидным color; на живом Plane CE такой POST …/states/ возвращает 200/201.
FR-3 — Сохранение контракта метода (NFR-1)
Публичная сигнатура create_state(project_id, name, group) НЕ меняется (color добавляется внутри
тела). Call-site plane.create_state(project_id, name, group) (строка 773) и существующие
тест-моки (FakePlane.create_state(self, project_id, name, group)) остаются валидны без правок.
4. Изменения API
Исходящий вызов к Plane CE — тело POST /workspaces/<ws>/projects/<id>/states/ получает
дополнительное поле color. Эндпоинтов самого оркестратора (FastAPI src/**) изменение не
вводит и не меняет. Новых/изменённых orchestrator-endpoint'ов — Нет.
5. Изменения схемы БД
Нет. SQLite-схема, таблицы, миграции — не затрагиваются (правка в операторском CLI).
6. Требования к новым/изменённым QG checks
Нет. STAGE_TRANSITIONS, реестр QG_CHECKS, check_*, machine-verdict ключи
(verdict:/result:/deploy_status:/staging_status:/security_status:/coverage_status:) —
байт-в-байт прежние. Багфикс-трек срезает только аналитику/архитектуру, не гейты (NFR-1 ORCH-019).
7. Артефакты pipeline, создаваемые/обновляемые
- Создаются analysis-доки
01-brd.md,02-trz.md,03-acceptance-criteria.md,04-test-plan.yaml(этот пакет). - На дальнейших стадиях:
12-review.md(reviewer),13-test-report.md(tester),14-deploy-log.md(deployer). ADR (06-adr/) не создаётся — bug-трек,architectureпропущена. - Документация: при необходимости отметить факт в
CHANGELOG.md; правка скрипта онбординга не меняет нормативные шаги runbook'ов (LITE_SETUP/BUNDLED_SETUP/ONBOARDING) по существу — решает developer/reviewer.
8. Совместимость / регресс
- Обратная совместимость: сигнатура и call-site неизменны; существующие онбординг-тесты зелёные (NFR-1).
- Область раската: только операторский CLI
scripts/onboard_project.py; активируется лишь явным человеческим запуском (kill-switch не нужен — паттерн ORCH-009/102/103). - Self-hosting безопасность: скрипт не деплоит/не рестартит прод-контейнер/не пушит
main(NFR-2). Idempotent-семантикаapply(ensure без delete) сохраняется: повторный прогон по существующему статусу остаётсяSKIPPED. - Обратимость: изменение тривиально откатывается (одна строка тела запроса).