---

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

Контекст:
Раньше в этом проекте реальные POST-запросы в SberTrack успешно выполнялись:
- Release был создан
- Epic был создан
- Story были созданы
- Task были созданы
- Bug был создан
- Links были созданы
- были HTTP 200/201
- известные успешные ID: TST123456-29, TST123456-30, TST123456-31, TST123456-32, TST123456-33, TST123456-34, TST123456-35, TST123456-36

Сейчас при попытке создать release testic через action sbertrack_create_release получаем:

POST /rest/api/unit/v2/release/create
HTTP 403 Forbidden
Response body: html 403 Forbidden nginx

Важно:
Раньше POST работал, значит нужно найти, что изменилось между успешным сценарием и текущим сценарием.

Жёсткие ограничения безопасности:
- НЕ выводить токены, пароль, username и полный .env.
- НЕ делать новые POST/PATCH/PUT/DELETE.
- НЕ выполнять git push.
- Оставить sbertrack_write_enabled=false.
- Можно делать только чтение файлов, grep, сравнение кода, py_compile и безопасные GET, если они уже есть в проекте.
- Если нужно показать auth, выводить только имена переменных и факт SET/MISSING, без значений.

Задача:
Найти, почему раньше POST работал, а сейчас POST /release/create возвращает 403.

Проверь и сравни:

## 1. Какие action использовались раньше при успешном POST

Найди в коде и истории вывода, какие action использовались для успешного создания:
- sbertrack_plan_full_release
- sbertrack_create_full_release_from_yaml
- sbertrack_create_full_release_from_yaml_ensure
- sbertrack_create_release
- другие похожие action

Нужно понять:
- какой action раньше реально создал TST123456-29;
- какой action сейчас вернул 403;
- отличаются ли они по пути к методу API.

Ответь таблицей:

Action | Использовался раньше успешно? | Используется сейчас? | Какой метод вызывает | Endpoint

## 2. Сравнить методы создания release

Найди в коде все методы:
- create_release
- create_full_release_from_yaml
- create_full_release_from_yaml_ensure
- plan_full_release_safe
- build_release_payload
- map_release_yaml_to_sbertrack_payload

Проверь:
- одинаковый ли payload используется;
- одинаковый ли endpoint используется;
- одинаковые ли headers/auth используются;
- одинаковый ли client/session используется;
- одинаково ли читается .env.

Ответь:

Метод | Endpoint | Auth берётся откуда | Payload полный? | Может ли дать 403?

## 3. Проверить auth без вывода секретов

Найди, какие env-переменные реально читает код для SberTrack API:

grep -R "sbertrack_.*username\|sbertrack_.*password\|sbertrack_.*token\|SBERTRACK.*TOKEN\|Authorization\|Bearer\|auth" -n src | head -150

Потом выполни безопасную проверку наличия ключей без значений:

python - <<'PY'
import os

keys = [
    "sbertrack_username",
    "sbertrack_password",
    "sbertrack_token",
    "SBERTRACK_TOKEN",
    "SBERTRACK_USERNAME",
    "SBERTRACK_PASSWORD",
    "sbertrack_base_url",
    "sbertrack_project_key",
    "sbertrack_write_enabled",
]

for key in keys:
    value = os.getenv(key)
    if key.lower().endswith(("password", "token", "username")):
        print(key, "SET" if value else "MISSING")
    else:
        print(key, value if value else "MISSING")
PY

Не выводить секретные значения.

## 4. Проверить, не сломался ли base_url или endpoint

Проверь:
- какой base_url использовался при успешном POST;
- какой base_url сейчас;
- нет ли отличий api.sbertrack.sberbank.ru / sbertrack.sberbank.ru / swtr / mapp / другое;
- нет ли двойного /rest/api или неправильного пути.

Найди все места:

grep -R "api.sbertrack\|sbertrack_base_url\|/rest/api/unit/v2/release/create\|release/create" -n . | head -200

Ответь:
- текущий endpoint полный;
- endpoint совпадает со старым рабочим или нет.

## 5. Проверить, не изменился ли create_release после доработок

Посмотри backup-файлы, которые создавались ранее:

find . -name "*sbertrack_api*.backup" -o -name "*sbertrack_planner*.backup" -o -name "*main.py*.backup"

Сравни текущий `src/sbertrack_api.py` с последним backup:
- create_release
- request/post метод
- headers
- auth
- timeout/session
- payload
- обработка response

Если git недоступен — сравни через diff с backup-файлом.

Нужно ответить:
- изменился ли create_release;
- изменился ли auth;
- изменился ли endpoint;
- могло ли это вызвать 403.

## 6. Проверить GET-доступ к API

Если в проекте уже есть read-only методы:
- test_auth
- current user
- get_unit_by_code
- space info

Выполни только GET/read-only:
- GET current user, если есть
- GET /rest/api/space/v3/TST123456, если есть
- GET /rest/api/unit/v2/TST123456-29, если есть

Не делать POST/PATCH/PUT/DELETE.

Нужно понять:
- API вообще пускает текущие credentials;
- есть ли read-доступ;
- доступен ли space;
- читается ли старый созданный unit.

Ответь таблицей:

Проверка | Endpoint | HTTP status | Вывод

Интерпретация:
- если GET тоже 403: проблема auth/network/credentials;
- если GET 200, но POST 403: нет write/create прав;
- если GET unit 200 для TST123456-29: старые сущности действительно есть и читаются.

## 7. Проверить, почему “No YAML release files found”

В отчёте было:
No YAML release files found

Но потом файл нашёлся:
projects/luch/services/luch-pprb/releases/release-testic.yaml

Проверь:
- какой glob используется в yaml_reader.py;
- почему recursive=True не сработал;
- какой путь реально передаётся в planner;
- не запускается ли команда из другой директории;
- одинаково ли ищутся YAML в safe plan и в create action.

Не меняй код без отдельного подтверждения. Только дай причину.

## 8. Проверить, не отличается ли payload старого успешного release от testic

Найди старый рабочий YAML:
- release-1.0.0.yaml
- release-testic.yaml
- другие release*.yaml

Сравни поля:
- summary
- description
- space
- ci_code
- sber_configuration_item
- priority
- workflow_status
- release_kind
- uat_ground
- conditions_itservice
- without_integration
- omni
- dates

Ответь:
- есть ли отличие, которое могло привести к 403;
- или payload не при чём, потому что 403 gateway/auth.

## 9. Финальный отчёт

Дай отчёт строго в формате:

# ФИНАЛЬНЫЙ ОТЧЁТ: ПОЧЕМУ РАНЬШЕ POST РАБОТАЛ, А СЕЙЧАС 403

## 1. Раньше рабочий сценарий
- Action:
- Метод:
- Endpoint:
- Payload:
- Auth:
- Результат:

## 2. Сейчас нерабочий сценарий
- Action:
- Метод:
- Endpoint:
- Payload:
- Auth:
- Результат: HTTP 403

## 3. Главное отличие
Напиши конкретно, что отличается:
- action;
- endpoint;
- auth;
- base_url;
- payload;
- рабочая директория;
- YAML search;
- права/API.

## 4. Что 403 означает в нашем случае
Выбери наиболее вероятную причину:
- сломался auth в коде;
- credentials не подхватились;
- изменился способ вызова;
- нет прав на create release;
- API/gateway режет запрос;
- другое.

## 5. Что можно исправить в коде
Если найдена ошибка в коде — предложи точное исправление, но НЕ вноси без подтверждения.

## 6. Что нужно спросить у наставника
Если это права/API, сформулируй коротко:
1. Раньше POST работал, сейчас POST /rest/api/unit/v2/release/create возвращает 403.
2. Могли ли измениться права техучётки?
3. Есть ли ограничение по IP/VPN?
4. Какой auth должен использоваться для release/create?
5. Есть ли отдельная роль на CREATE Release в TST123456?

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