---

Ты работаешь в реальном репозитории:

/Users/23865613/IdeaProjects/untitled/project-manager-tools

Рядом уже склонирован репозиторий-пример:

/Users/23865613/IdeaProjects/untitled/ai_market/mcp/sbertrack-mcp

Контекст задачи:
Мы добавляем поддержку SberTrack в project-manager-tools для создания релизных объектов через REST API SberTrack.

У нас уже пробовали endpoint:

POST https://api.sbertrack.sberbank.ru/rest/api/unit/v2/release/create

Текущий тестовый space:
TST123456

Текущий пользователь/техучётка:
cab-sa-dvo11195

Текущая проблема:
При реальном POST получаем:

HTTP 403 Forbidden
errorType: SWTR_ACCESS_DENIED_ERROR
uiErrorMessage: "Доступ запрещен. Проверьте наличие необходимых прав"

Важно:
Поддержка SberTrack сказала, что для релизных объектов нужно пространство типа Change.
Сейчас создано пространство TST123456 типа Change.
В UI SberTrack у техучётки уже проверялись роли/привилегии, но POST всё ещё возвращает 403.
Нужно понять, совпадает ли наша реализация с реализацией в sbertrack-mcp.

Задача:
Проанализируй репозиторий sbertrack-mcp и сравни с текущей реализацией в project-manager-tools.

Что нужно сделать:

1. В репозитории sbertrack-mcp найди реализацию работы с релизами:
   - endpoint для создания релиза;
   - модель/payload для создания релиза;
   - обязательные поля;
   - как формируется base URL;
   - как формируется Basic Auth;
   - какие headers используются;
   - есть ли отдельные scopes/permissions для releases.

2. Найди в sbertrack-mcp все места, связанные с:
   - release;
   - release/create;
   - /rest/api/unit/v2/release/create;
   - SBERTRACK_LOGIN;
   - SBERTRACK_PASSWORD;
   - SBERTRACK_URL;
   - Basic Auth;
   - Authorization;
   - requests/httpx/aiohttp/client.

3. В project-manager-tools проверь текущую реализацию:
   - src/sbertrack_api.py или похожий файл;
   - src/main.py;
   - .env и .env.example;
   - action sbertrack_test_create_release_rest;
   - endpoint /rest/api/unit/v2/release/create;
   - payload;
   - write_enabled;
   - чтобы старые Jira-like endpoint и old action sbertrack_test_create_release не были затронуты.

4. Если в sbertrack-mcp есть отличия от нашей реализации, аккуратно поправь project-manager-tools так, чтобы тестовый action использовал такой же подход, как sbertrack-mcp.

5. Не делай git push.

6. Не выводи логин, пароль, токены и полный .env.

7. Не запускай plan_releases.

8. Не используй Jira-like endpoint:
   /extension/plugin/v2/rest/api/jira/rest/api/2/issue

9. Не трогай старый action:
   sbertrack_test_create_release

10. Работай только с отдельным action:
   sbertrack_test_create_release_rest

11. Сначала сделай dry-run при:
   sbertrack_write_enabled=false

12. В dry-run выведи:
   - endpoint;
   - sanitized payload;
   - space;
   - write_enabled=false;
   - подтверждение, что POST не отправлен;
   - подтверждение, что Jira-like endpoint не использовался;
   - подтверждение, что plan_releases не запускался.

13. После dry-run НЕ выполняй реальный POST без моего отдельного подтверждения.

Ожидаемый минимальный payload для релиза:

{
  "summary": "TEST project-manager-tools SberTrack release REST integration",
  "description": "Test release created by project-manager-tools SberTrack REST integration. Safe to delete.",
  "space": "TST123456",
  "attributes": {
    "release_kind": "planned",
    "priority": "low",
    "uat_ground": "hotfix"
  }
}

Ожидаемый endpoint:

POST https://api.sbertrack.sberbank.ru/rest/api/unit/v2/release/create

Ожидаемый результат:
1. Кратко покажи, что найдено в sbertrack-mcp.
2. Покажи, совпадает ли наша реализация с MCP.
3. Если есть отличия — внеси минимальные изменения.
4. Запусти только dry-run.
5. В конце дай одну команду для реального POST, но не запускай её сам.
6. Напиши короткий вывод: проблема в коде или, скорее всего, в правах пользователя cab-sa-dvo11195 в пространстве TST123456.