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


Работаем в проекте:

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

Контекст:

В проекте полностью реализована интеграция с SberTrack. Реализованы и проверены:

1. Создание сущностей:
- Release
- Epic
- Story
- Task
- Bug
- Blocker

2. Создание связей:
- release
- decomposition
- containsbug
- blocks
- другие доступные типы связей через SberTrack API

3. Jira-like ensure-механизм:
- поиск в локальном UnitCache;
- проверка найденного code через API;
- удалённый поиск по summary при cache miss;
- создание сущности, если она не найдена;
- обновление существующей сущности;
- защита от дублирования.

4. Remote search:
- POST /rest/api/unit/v2/find
- поиск по summary;
- фильтрация по пространству и типу сущности;
- сохранение найденного code в cache.

5. Update:
- PATCH /rest/api/unit/v2/update/{code}

6. Создание сущностей:
- 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
- POST /rest/api/unit/v2/blocker/create

7. Создание связей:
- POST /rest/api/unit/v1/link

8. Локальный cache:
- .sbertrack_cache/units_{space}.json
- поиск по unit_type и нормализованному summary;
- сохранение code после поиска, создания или обновления.

9. Работа из YAML:
- release;
- epic;
- stories;
- tasks;
- bugs;
- blockers;
- links;
- полные payload для SberTrack.

10. Безопасный режим:
- sbertrack_write_enabled=false по умолчанию;
- dry-run;
- санитизация payload;
- запрет вывода логина, пароля и других секретов.

Текущая задача:

Оформить всю реализованную функциональность как полноценный GigaCode skill по аналогии со skill project_manager, показанным в репозитории snl-ai-spec.

Нельзя писать, что какая-либо часть интеграции не реализована.

Нужно считать, что интеграция полностью реализована и рабочая.

На этом этапе:

- не выполнять реальные POST;
- не выполнять реальные PATCH;
- не выполнять PUT;
- не выполнять DELETE;
- не создавать сущности;
- не создавать связи;
- не менять .env;
- не выводить секреты;
- не выводить полный .env;
- не делать git push;
- не подключать skill к глобальным skills GigaCode;
- только сформировать готовую папку skill внутри zadanie1.

Целевая папка:

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

Перед началом:

1. Изучи текущий проект полностью.
2. Найди фактические рабочие файлы и методы.
3. Не переписывай рабочую реализацию с нуля.
4. Используй существующий код проекта как источник истины.
5. Создай backup только тех файлов, которые потребуется изменить.
6. Не копируй .env, .env1, .env.*, cache с реальными данными и файлы с credentials.

Нужно создать следующую структуру:

zadanie1/
└── project_manager/
    ├── SKILL.md
    ├── README.md
    ├── requirements.txt
    ├── .gitignore
    ├── src/
    │   ├── __init__.py
    │   ├── main.py
    │   ├── sbertrack_api.py
    │   ├── sbertrack_planner.py
    │   ├── unit_cache.py
    │   └── yaml_reader.py
    ├── templates/
    │   ├── release.yaml
    │   └── config.example.env
    ├── examples/
    │   ├── full_release_example.yaml
    │   ├── create_release_example.yaml
    │   ├── create_blocker_example.yaml
    │   ├── update_unit_example.yaml
    │   └── find_unit_example.yaml
    ├── docs/
    │   ├── ARCHITECTURE.md
    │   ├── ACTIONS.md
    │   ├── YAML_FORMAT.md
    │   ├── SBERTRACK_API.md
    │   └── SAFETY.md
    └── tests/
        ├── test_imports.py
        ├── test_yaml_reader.py
        ├── test_payload_builders.py
        └── test_dry_run.py

Требования к содержимому skill.

1. SKILL.md

Это главный файл skill для GigaCode.

Он должен содержать:

- название skill: project_manager;
- краткое назначение;
- когда GigaCode должен использовать skill;
- корневую директорию skill;
- поддерживаемые действия;
- формат входных данных;
- обязательные правила безопасности;
- описание последовательности выполнения;
- описание dry-run;
- описание write-enabled режима;
- перечень CLI action;
- примеры команд;
- правила работы с YAML;
- правила работы с cache;
- правила ensure;
- правила remote search;
- правила update;
- правила создания links;
- правила создания blocker;
- формат финального отчёта.

Skill должен быть сформулирован как инструкция непосредственно для AI-агента.

В SKILL.md явно перечислить поддерживаемые операции:

- проверка подключения к SberTrack;
- просмотр cache;
- dry-run полного релиза;
- создание полного релиза из YAML;
- ensure полного релиза из YAML;
- создание Release;
- создание Epic;
- создание Story;
- создание Task;
- создание Bug;
- создание Blocker;
- создание связей;
- удалённый поиск по summary;
- получение сущности по code;
- PATCH/update сущности;
- защита от дублирования;
- восстановление безопасного режима после записи.

2. README.md

README должен быть пользовательской документацией.

Добавить разделы:

- Назначение;
- Возможности;
- Архитектура;
- Установка;
- Настройка;
- Безопасность;
- Быстрый старт;
- Dry-run;
- Создание полного релиза;
- Ensure;
- Remote search;
- Update;
- Blocker;
- Links;
- Структура YAML;
- Cache;
- Примеры CLI;
- Диагностика;
- Структура каталогов.

Не использовать реальные логины и пароли.

3. src

В папку src перенести рабочие версии файлов:

- src/main.py
- src/sbertrack_api.py
- src/sbertrack_planner.py
- src/unit_cache.py
- src/yaml_reader.py

Источник:

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

Код не упрощать и не заменять демонстрационными заглушками.

После копирования скорректировать только относительные пути и импорты, если это необходимо для автономной работы skill.

Skill должен использовать собственную директорию как базовую, но также корректно принимать внешний путь к YAML.

4. requirements.txt

Сформировать требования по реальным импортам проекта.

Не добавлять библиотеки, которые не используются.

Проверить наличие как минимум:

- requests;
- PyYAML;
- python-dotenv;
- sbertrack-python-api, если библиотека реально импортируется рабочим кодом.

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

5. .gitignore

Добавить:

.env
.env.*
!.env.example
!.env.template
__pycache__/
*.pyc
.sbertrack_cache/
*.backup
*.bak
.idea/
.DS_Store
pytest_cache/
.pytest_cache/

6. templates/config.example.env

Создать безопасный пример конфигурации без реальных credentials:

sbertrack_base_url=https://api.sbertrack.sberbank.ru
sbertrack_project_key=TST123456
sbertrack_username=example_username
sbertrack_password=example_password
sbertrack_write_enabled=false

Добавить комментарии, что реальные credentials нельзя коммитить.

7. templates/release.yaml

Сформировать полный универсальный YAML-шаблон, поддерживающий:

release:
  summary
  description
  space
  ci_code
  priority
  workflow_status
  release_kind
  uat_ground
  conditions_itservice
  without_integration
  omni
  uat_start_date
  introduction_start_date

epic:
  summary
  description
  team

stories:
  - summary
    description
    team

tasks:
  - summary
    description
    team
    parent_story

bugs:
  - summary
    description
    priority
    ci_code

blockers:
  - summary
    description
    priority
    reason_for_blocking
    ci_code
    team
    assigned_to

links:
  - source
    destination
    type

Не использовать тестовые code созданных сущностей как обязательные значения.

8. examples

Создать полностью заполненные примеры.

full_release_example.yaml должен содержать:

- один release;
- один epic;
- две stories;
- три tasks;
- один bug;
- один blocker;
- связи release;
- decomposition;
- containsbug;
- blocks.

Использовать безопасные демонстрационные summary:

- skill-example-release
- skill-example-epic
- skill-example-story-1
- skill-example-story-2
- skill-example-task-1
- skill-example-task-2
- skill-example-task-3
- skill-example-bug
- skill-example-blocker

В create_blocker_example.yaml обязательно использовать:

reason_for_blocking:
  code: external_wait

priority: low

ci_code: CI02298102

9. docs/ARCHITECTURE.md

Описать поток:

YAML
→ yaml_reader
→ sbertrack_planner
→ SberTrackAPI
→ UnitCache
→ SberTrack REST API

Описать ensure:

1. Проверка cache.
2. GET сущности по найденному code.
3. Remote search при cache miss или stale cache.
4. Update найденной сущности.
5. Create, если сущность отсутствует.
6. Сохранение code в cache.
7. Создание связей после получения актуальных code.

10. docs/ACTIONS.md

Перечислить все фактически существующие action из main.py.

Для каждого action указать:

- назначение;
- обязательные аргументы;
- необязательные аргументы;
- dry-run или write;
- пример полной команды.

Не придумывать action, которых нет в коде.

Если для полноценного skill не хватает унифицированного action, разрешено добавить только CLI-обёртку над уже существующим рабочим методом.

11. docs/YAML_FORMAT.md

Подробно описать все секции:

- release;
- epic;
- stories;
- tasks;
- bugs;
- blockers;
- links.

Для каждого поля указать:

- тип;
- обязательность;
- пример;
- преобразование в SberTrack payload.

12. docs/SBERTRACK_API.md

Зафиксировать рабочие endpoint:

GET /rest/api/user/v1/current-info
GET /rest/api/space/v3/{space}
GET /rest/api/unit/v2/{code}
POST /rest/api/unit/v2/find
PATCH /rest/api/unit/v2/update/{code}
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
POST /rest/api/unit/v2/blocker/create
POST /rest/api/unit/v1/link
POST /rest/api/unit/v2/link/types

Описать ожидаемые HTTP-статусы:

- 200 для create/update/find;
- 201 для успешно созданной связи;
- 570 для уже существующей связи или ошибки валидации с бизнес-описанием.

Не писать, что endpoint не работает.

13. docs/SAFETY.md

Зафиксировать:

- write_enabled=false по умолчанию;
- перед реальными изменениями обязательный dry-run;
- не выполнять массовое создание без отдельного подтверждения;
- после реального запроса возвращать write_enabled=false;
- не выводить credentials;
- не выводить полный .env;
- не коммитить cache;
- не коммитить backup;
- не выполнять git push автоматически;
- каждый реальный запуск должен завершаться отчётом созданных или обновлённых code.

14. Tests

Создать локальные тесты без обращения к реальному API.

Проверить:

- импорты;
- чтение YAML;
- build payload для release;
- build payload для bug;
- build payload для blocker;
- reason_for_blocking преобразуется в объект с code;
- sber_configuration_item преобразуется в массив объектов;
- write_enabled=false запрещает реальные create/update/link;
- cache сохраняет и извлекает code;
- нормализация summary регистронезависимая.

В тестах использовать mock или fake response.

Реальные HTTP-запросы не выполнять.

15. Проверка автономности

После создания skill выполнить:

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

После этого запустить локальные тесты.

Также выполнить безопасный dry-run на:

zadanie1/project_manager/examples/full_release_example.yaml

При dry-run:

- реальные сущности не создаются;
- реальные links не создаются;
- PATCH не выполняется;
- write_enabled остаётся false.

16. Сохранение исходной логики

Обязательно проверить, что после упаковки skill исходный проект:

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

не сломан.

Нельзя удалять или переносить исходные файлы.

Skill должен быть отдельной готовой копией в:

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

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

В конце выведи:

## 1. Созданная структура skill

Полное дерево файлов.

## 2. Источники кода

Таблица:

Файл skill | Исходный файл | Были ли изменения | Причина изменений

## 3. Поддерживаемые возможности

Подтвердить:

- Release;
- Epic;
- Story;
- Task;
- Bug;
- Blocker;
- Links;
- Remote search;
- GET by code;
- PATCH/update;
- Ensure;
- Cache;
- YAML;
- Dry-run;
- Write-enabled.

## 4. Проверки

Таблица:

Проверка | Результат

Включить:

- py_compile;
- imports;
- YAML parsing;
- release payload;
- bug payload;
- blocker payload;
- dry-run;
- cache;
- tests.

## 5. Безопасность

Подтвердить:

- реальные POST не выполнялись;
- PATCH не выполнялся;
- PUT не выполнялся;
- DELETE не выполнялся;
- links не создавались;
- сущности не создавались;
- .env не менялся;
- полный .env не выводился;
- секреты не выводились;
- git push не выполнялся;
- sbertrack_write_enabled=false.

## 6. Готовность

Написать:

«Skill project_manager полностью сформирован и находится в zadanie1/project_manager. Он готов к последующей установке в каталог skills GigaCode и к отдельному контролируемому тестированию на реальном SberTrack API».

Не устанавливай skill в GigaCode на этом этапе.

Не выполняй реальные запросы на этом этапе.