Загрузка данных


Работаем в project-manager-tools.

Контекст:
Перед исследованием blocker нужно проверить, что финальная версия проекта полностью осталась рабочей на реальных SberTrack API запросах.

Уже ранее было подтверждено:
- create release работает
- create epic работает
- create story работает
- create task работает
- create bug работает
- create links работает
- PATCH/update работает
- remote search по summary работает
- cache работает
- sbertrack_write_enabled после тестов должен возвращаться в false

Сейчас задача:
Провести полный контрольный тест финальной версии проекта на реальных запросах SberTrack, но БЕЗ blocker.

ВАЖНО:
- blocker НЕ создавать
- blocker НЕ тестировать
- blocker endpoint НЕ дергать
- DELETE не выполнять
- PUT не выполнять
- git push не выполнять
- секреты не выводить
- полный .env не выводить
- после теста обязательно вернуть sbertrack_write_enabled=false
- все реальные POST/PATCH выполнять только для нового тестового набора сущностей
- название тестового релиза сделать уникальным, чтобы не конфликтовать со старым testic

Тестовый summary:
Используй уникальный summary формата:

final-check-YYYYMMDD-HHMM

Например:
final-check-20260710-001

Не используй старый testic, чтобы не путать с уже созданным TST123456-41.

Порядок проверки:

## 1. Проверить окружение

Показать:
- текущую директорию
- что это project-manager-tools
- доступен ли API
- GET /rest/api/user/v1/current-info возвращает HTTP 200
- GET /rest/api/space/v3/TST123456 возвращает HTTP 200
- пользователь определился
- sbertrack_project_key = TST123456
- sbertrack_write_enabled в начале = false

Не выводить:
- token
- password
- username/password целиком
- полный .env

Можно показать только безопасные ключи:
- sbertrack_base_url
- sbertrack_project_key
- sbertrack_write_enabled

## 2. Проверить синтаксис

Выполнить:

python -m py_compile src/sbertrack_api.py src/sbertrack_planner.py src/unit_cache.py src/main.py src/yaml_reader.py

Если есть ошибки — остановиться, показать ошибку и НЕ выполнять реальные POST.

## 3. Подготовить тестовый YAML

Создать отдельный тестовый YAML файл в безопасном месте проекта, например:

projects/luch/services/luch-pprb/releases/release-final-check-YYYYMMDD-HHMM.yaml

В YAML должны быть заполнены все обязательные поля, чтобы release не был пустым.

Структура должна включать:

1. release:
   - summary: final-check-YYYYMMDD-HHMM
   - description: "Final integration check from project-manager-tools. Safe to delete."
   - space: TST123456
   - ci_code: CI02298102
   - priority: low
   - workflow_status: {"command": "NEW"}
   - release_kind: planned
   - uat_ground: hotfix
   - conditions_itservice: dontChange
   - without_integration: false
   - omni: false
   - uat_start_date: ISO datetime
   - introduction_start_date: ISO datetime

2. epic:
   - summary: final-check-YYYYMMDD-HHMM epic
   - description: "Final check epic"

3. stories:
   - final-check-YYYYMMDD-HHMM story 1
   - final-check-YYYYMMDD-HHMM story 2

4. tasks:
   - final-check-YYYYMMDD-HHMM task 1
   - final-check-YYYYMMDD-HHMM task 2
   - final-check-YYYYMMDD-HHMM task 3

5. bug:
   - final-check-YYYYMMDD-HHMM bug 1

Не добавлять blocker.

## 4. Dry-run перед реальным запуском

Выполнить dry-run:
- safe plan
- ensure dry-run
- cache status

Проверить:
- YAML найден
- payload полный
- обязательные поля есть
- planned сущности отображаются
- реальные POST/PATCH/DELETE на dry-run не выполнялись

Если dry-run не прошел — остановиться и НЕ включать write_enabled=true.

## 5. Реальный create full release

Только после успешного dry-run:

1. Временно установить:
   sbertrack_write_enabled=true

2. Выполнить реальный create/ensure full release по тестовому YAML.

Должно создаться:
- 1 Release
- 1 Epic
- 2 Story
- 3 Task
- 1 Bug

Для каждой сущности показать таблицу:

Тип сущности | Summary | Endpoint | HTTP status | Created code

Ожидаемые endpoints:
- POST /rest/api/unit/v2/release/create
- POST /rest/api/unit/v2/epic/create
- POST /rest/api/unit/v2/story/create
- POST /rest/api/unit/v2/task/create
- POST /rest/api/unit/v2/bug/create

Ожидаемые HTTP:
- 200 или 201

Если что-то не создалось:
- показать ошибку
- НЕ продолжать links
- вернуть sbertrack_write_enabled=false

## 6. Реальное создание links

После успешного создания всех сущностей создать связи.

Проверить, что используются актуальные created code, а не старые TST123456-41/42/...

Создать связи:
- story 1 -> release
- story 2 -> release
- task 1 -> release
- task 2 -> release
- task 3 -> release
- epic -> release
- story 1 -> epic
- story 2 -> epic
- task 1 -> story 1
- task 2 -> story 1
- task 3 -> story 2
- release -> bug

Типы связей использовать только уже подтвержденные:
- release
- decomposition
- containsbug

Endpoint:
- POST /rest/api/unit/v1/link

Показать таблицу:

Source | Destination | Link type | HTTP status | Result

Ожидаемые HTTP:
- 201
- если HTTP 570 "уже существует" — считать ожидаемым только если это повторный запуск на тех же сущностях

## 7. Проверить remote search по summary

Проверить поиск созданного release по summary без опоры только на cache.

Нужно:
1. Временно изолировать или удалить только cache-запись для нового release summary.
2. НЕ трогать остальные cache-записи.
3. Выполнить find_unit_by_summary для нового summary.
4. Убедиться, что поиск идет через SberTrack API:
   POST /rest/api/unit/v2/find
   или подтвержденный метод sbertrack_python_api.client.unit.find
5. Ожидаемый HTTP status: 200
6. Ожидаемый результат: найден code созданного release.
7. После поиска запись должна вернуться в cache.

Показать:
- cache miss был: да/нет
- endpoint поиска
- HTTP status
- найденный code
- cache после поиска содержит запись: да/нет

## 8. Проверить PATCH/update на новом release

Выполнить реальный PATCH только для созданного нового release.

Обновить только безопасное поле:
- description

Новое значение:
"Final integration check PATCH update from project-manager-tools. Existing release updated safely. Safe to delete."

Endpoint:
- PATCH /rest/api/unit/v2/update/{created_release_code}

Показать:
- code
- endpoint
- HTTP status
- старое значение description
- новое значение description
- GET после PATCH подтверждает обновление: да/нет

НЕ менять:
- summary
- type
- project/space
- issue type
- связи
- workflow/status
- даты, если это рискованно

## 9. Проверить ensure на уже существующем release

После PATCH повторно запустить ensure для того же summary.

Ожидаемое поведение:
- дубль НЕ создается
- сначала cache/search находит существующий release
- выполняется update существующего release
- возвращается тот же code
- created code не меняется

Показать:
- старый code
- code после повторного ensure
- совпадают: да/нет
- дубль создан: нет

## 10. Вернуть безопасный режим

В конце обязательно:

1. Вернуть:
   sbertrack_write_enabled=false

2. Проверить grep только безопасных ключей:
   - sbertrack_write_enabled
   - sbertrack_project_key
   - sbertrack_base_url

3. Подтвердить:
   - полный .env не выводился
   - секреты не выводились
   - git push не выполнялся
   - DELETE не выполнялся
   - PUT не выполнялся
   - blocker не создавался
   - sbertrack_write_enabled=false в конце

## 11. Финальный отчет

Вывести отчет:

# ФИНАЛЬНЫЙ ОТЧЕТ ПРОВЕРКИ ФИНАЛЬНОЙ ВЕРСИИ

## 1. Окружение
- API доступен: да/нет
- current-info HTTP:
- space HTTP:
- project key:
- пользователь:
- write_enabled в начале:
- write_enabled в конце:

## 2. Синтаксис
- py_compile: успешно/ошибка

## 3. YAML
- файл:
- summary:
- payload полный: да/нет

## 4. Dry-run
- safe plan: успешно/ошибка
- ensure dry-run: успешно/ошибка
- реальные запросы на dry-run: нет

## 5. Create
Таблица:
Тип | Summary | Endpoint | HTTP | Code

## 6. Links
Таблица:
Source | Destination | Type | HTTP | Result

## 7. Remote search без cache
- cache miss подтвержден:
- endpoint:
- HTTP:
- найден code:
- cache восстановлен:

## 8. PATCH/update
- endpoint:
- HTTP:
- обновлен code:
- GET после PATCH подтверждает обновление:

## 9. Ensure без дублей
- повторный ensure вернул тот же code:
- дубль создан:
- итог:

## 10. Безопасность
Подтвердить:
- sbertrack_write_enabled=false
- DELETE не выполнялся
- PUT не выполнялся
- blocker не создавался
- git push не выполнялся
- секреты не выводились
- полный .env не выводился

## 11. Итог
Сказать честно:
- финальная версия проекта полностью рабочая: да/нет
- что работает на реальных API:
  - create release
  - create epic
  - create story
  - create task
  - create bug
  - create links
  - remote search
  - PATCH/update
  - ensure без дублей
- что осталось отдельно:
  - blocker model/endpoint исследовать read-only следующим шагом