https://pastein.ru/t/xoJ
Загрузка данных
Работаем в project-manager-tools.
Контекст:
Финальная версия SberTrack-интеграции уже проверена на реальных API.
Подтверждено:
1. API доступен:
- GET current-info: HTTP 200
- GET space TST123456: HTTP 200
2. Create работает:
- release
- epic
- story
- task
- bug
3. Links работают:
- POST /rest/api/unit/v1/link
- type=release
- type=decomposition
- type=containsbug
- HTTP 201
- HTTP 570 "already exists" корректно обрабатывается как нефатальная ситуация
4. PATCH/update работает:
- PATCH /rest/api/unit/v2/update/{code}
- проверено на TST123456-82
- HTTP 200
5. Remote search без cache работает:
- POST /rest/api/unit/v2/find
- через sbertrack_python_api.client.unit.find
- cache miss был подтвержден
- поиск по summary нашел существующий release
- запись вернулась в .sbertrack_cache/units_TST123456.json
6. Ensure без дублей работает:
- cache -> remote search -> create/update
- повторный ensure возвращает существующий code, duplicate не создается
Теперь нужно разобраться с blocker.
ВАЖНО:
Ничего не создавать и не менять.
Строго read-only / dry-run.
Запрещено:
- НЕ делать реальный POST
- НЕ делать PATCH
- НЕ делать PUT
- НЕ делать DELETE
- НЕ создавать blocker
- НЕ создавать release/epic/story/task/bug
- НЕ создавать links
- НЕ менять .env
- НЕ делать git push
- НЕ выводить секреты
- НЕ выводить полный .env
- НЕ менять рабочую create/update/search/link логику
- sbertrack_write_enabled должен остаться false
Цель:
Понять, как в SberTrack правильно реализуется blocker.
Нужно определить, blocker — это:
Вариант A: отдельный unit type, например blocker
Вариант B: bug/defect с priority=blocker
Вариант C: task с priority=blocker
Вариант D: link type между задачами, например blocks / blocked by / blocker
Вариант E: поле/атрибут внутри release/story/task/bug
Вариант F: комбинация priority + link type
Задача 1. Проверить текущий проект
Найди в project-manager-tools все места, связанные с blocker:
- blocker
- create_blocker
- build_blocker_payload
- map_blocker_yaml_to_sbertrack_payload
- blocker/create
- /rest/api/unit/v2/blocker/create
- blocks
- blocked
- blockedby
- blocker
- priority
- defect
- bug
- containsbug
Проверить файлы:
- src/sbertrack_api.py
- src/sbertrack_planner.py
- src/yaml_reader.py
- src/main.py
- src/unit_cache.py
- projects/**/*.yaml
- README / docs, если есть
Нужно понять:
- есть ли уже код blocker
- какой endpoint он предполагает
- какой payload строит
- почему раньше /rest/api/unit/v2/blocker/create мог возвращать HTTP 500
- можно ли оставить этот код только как dry-run до подтверждения модели
Задача 2. Проверить sbertrack_python_api
Найди установленный пакет:
python -c "import sbertrack_python_api; print(sbertrack_python_api.__file__)"
Затем найди директорию пакета:
python -c "import sbertrack_python_api, os; print(os.path.dirname(sbertrack_python_api.__file__))"
В исходниках пакета безопасно поискать:
- blocker
- block
- blocks
- blocked
- blockedBy
- blocked_by
- defect
- bug
- issue
- priority
- link
- link.types
- findSuits
- suits
- unit types
- taxonomy
- task_categories
- priorities
- /rest/api/unit/v2/blocker
- /rest/api/unit/v2/bug
- /rest/api/unit/v2/task
- /rest/api/unit/v1/link
- /rest/api/unit/v2/find
- /rest/api/unit/v2/update
- /rest/api/taxonomy
- /rest/api/workflow
Важно:
Поиск только по коду и документации пакета.
Не выполнять мутирующие методы.
Задача 3. Проверить доступные типы unit в TST123456
Использовать только read-only методы.
Попробовать найти безопасные методы для получения suit/unit types:
- issue.findSuits
- unit.findSuits
- client.get(...)
- sbertrack_python_api методы, которые только читают данные
- методы space/suit/taxonomy/workflow, если они есть
Нужно получить список доступных типов задач/юнитов в space TST123456.
Особенно проверить наличие:
- release
- epic
- story
- task
- bug
- defect
- blocker
- impediment
- dependency
- issue
Если отдельного типа blocker нет — это важно зафиксировать.
Задача 4. Проверить доступные link types
Использовать только read-only методы.
Найти способ получить типы связей:
- link.types
- client.get(...)
- sbertrack_python_api link methods
- документация пакета
- исходники generated API
Нужно проверить наличие типов:
- release
- decomposition
- containsbug
- blocks
- blocked
- blocked by
- blockedby
- dependency
- depends on
- is blocked by
- blocker
- relates
- parent
- child
Если есть только release/decomposition/containsbug — зафиксировать.
Задача 5. Проверить priority values
Использовать только read-only методы или исходники/документацию.
Нужно понять, какие значения priority допустимы в SberTrack:
- low
- mid
- high
- critical
- blocker
- blocking
- major
- minor
- trivial
Особенно важно:
- есть ли priority=blocker
- как оно пишется в payload: blocker / blocking / Блокирующий / code справочника
Задача 6. Проверить модель bug/defect
Так как bug уже создается через:
POST /rest/api/unit/v2/bug/create
нужно понять:
- bug и defect — одно и то же или разные unit types
- можно ли создать bug с priority=blocker
- есть ли поле defect в API/models
- есть ли отдельный endpoint defect/create
- есть ли в документации "Дефект" как SberTrack unit type
Ничего не создавать. Только анализ кода, моделей, документации и read-only справочников.
Задача 7. Добавить read-only диагностический action, если его еще нет
Можно добавить action:
sbertrack_inspect_blocker_model
Он должен быть строго read-only.
Что должен делать action:
1. Показать sbertrack_write_enabled.
2. Показать доступность API current-info и space.
3. Показать найденные unit/suit types.
4. Показать найденные link types.
5. Показать priority values, если удалось получить.
6. Показать blocker-related методы из sbertrack_python_api.
7. Показать текущий blocker-код в проекте.
8. НЕ выполнять POST/PATCH/PUT/DELETE.
9. НЕ создавать сущности.
10. НЕ создавать links.
11. НЕ менять cache, кроме возможного read-only просмотра.
Если для получения типов доступен только POST-поисковый read-only endpoint, например find, его можно использовать только если он не создает/не изменяет данные. В отчете явно написать, что это read-only search.
Задача 8. Ничего не ломать
Не менять:
- create_release
- create_epic
- create_story
- create_task
- create_bug
- create_link
- ensure_unit_by_summary
- find_unit_by_summary
- update_unit_by_code
- UnitCache
- YAML reader
Если нужно добавить код — только отдельная диагностика blocker, без влияния на основную логику.
Перед любыми изменениями создать backup изменяемых файлов:
- src/sbertrack_api.py
- src/sbertrack_planner.py
- src/main.py
- src/unit_cache.py
Задача 9. Выполнить безопасные проверки
Выполнить:
python -m py_compile src/sbertrack_api.py src/sbertrack_planner.py src/unit_cache.py src/main.py src/yaml_reader.py
Если добавлен action, выполнить его только в read-only режиме:
python src/main.py --tracker sbertrack --action sbertrack_inspect_blocker_model --project luch --service luch-pprb
Если для action нужны другие параметры space/project_key — использовать TST123456 из .env, но не выводить секреты.
Задача 10. Финальный отчет
Сделать отчет в таком формате:
## 1. Что найдено в текущем проекте
Таблица:
Файл | Метод/фрагмент | Что делает | Это реальная реализация или dry-run | Нужно менять?
## 2. Что найдено в sbertrack_python_api
Таблица:
Метод/класс | Назначение | Endpoint если найден | Подходит для blocker?
## 3. Доступные unit types / suits
Список:
- type/code
- display name, если есть
- найден ли blocker
- найден ли defect
- найден ли bug
- найден ли task
## 4. Доступные link types
Список:
- type/code
- display name, если есть
- есть ли blocks/blocked/dependency
- есть ли release/decomposition/containsbug
## 5. Priority values
Список:
- code/value
- display name
- есть ли blocker/blocking/Блокирующий
## 6. Какая модель blocker наиболее вероятна
Выбрать один вариант:
A. отдельный unit type
B. bug/defect с priority=blocker
C. task с priority=blocker
D. link type blocks/blocked
E. поле/атрибут внутри unit
F. комбинация priority + link type
Если точного подтверждения нет — честно написать "не подтверждено".
## 7. Что можно реализовать безопасно сейчас
Например:
- blocker dry-run payload
- валидация blocker YAML
- проверка наличия priority=blocker
- проверка наличия link type blocks
- запрет реального POST blocker до подтверждения endpoint/model
## 8. Что нельзя делать без наставника
Обязательно указать:
- нельзя делать POST /rest/api/unit/v2/blocker/create без подтверждения
- нельзя создавать blocker наугад
- нельзя считать blocker отдельным unit type без подтверждения
- нельзя использовать priority=blocker без подтверждения допустимого значения
- нельзя создавать link type blocks, если такого типа нет в справочнике
## 9. Безопасность
Подтвердить:
- sbertrack_write_enabled=false
- POST не выполнялся, кроме read-only search/find если он нужен и точно не мутирует
- PATCH не выполнялся
- PUT не выполнялся
- DELETE не выполнялся
- release/epic/story/task/bug не создавались
- links не создавались
- blocker не создавался
- git push не выполнялся
- секреты не выводились
- полный .env не выводился
## 10. Итог
Ответить:
- можно ли реализовать blocker прямо сейчас
- что точно известно
- что требует уточнения у наставника
- какой следующий минимальный безопасный шаг