Privyazka Git K Gitlab

Подключение GitLab К Codex На Windows

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю экспериментальный навык «Подключение GitLab к Codex на Windows» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Обзор

Фраза «подключить учётку GitLab к Codex» скрывает три разных состояния:

Создание токена в браузере само по себе не обновляет Windows. Наличие записи в Windows само по себе не доказывает доступ к GitLab. Skill всегда называет достигнутое состояние буквально и не выдаёт следующий уровень за уже подтверждённый.

Целевой сценарий: Windows, Git over HTTPS, одна учётная запись на один GitLab host. Пользователь может подключить учётку без выбора репозитория; репозиторий нужен только для необязательной удалённой проверки или дальнейшего clone/pull/push.

Роли И Режим Разговора

• Агент сам выполняет безопасные локальные проверки Git и Git Credential Manager.
• Пользователь сам видит и вводит токен в браузере или интерактивном PowerShell. Токен нельзя просить прислать в чат.
• Давайте ровно один ближайший шаг. Следующий шаг выбирайте после результата текущего, если он от него зависит.
• Если пользователь просит подключить учётку, не требуйте URL репозитория до этапа необязательной удалённой проверки.
• Если действие ушло от цели, остановите цикл:

Стоп.
Факт: [что сейчас подтверждено экраном или командой].
Расхождение: [цель пользователя] vs [текущее действие].
Шаг: [одно действие к цели].
Проверка: [какой наблюдаемый результат ждём].

Входной Gate

До изменений подтвердите из сообщения, скрина или одной короткой проверки:

1. Система — Windows, оболочка — PowerShell.
2. Нужен HTTPS + Personal Access Token, а не SSH.
3. Для этого GitLab host будет использоваться одна учётная запись. При нескольких аккаунтах остановитесь: host-wide credential может выбрать не того пользователя; нужен отдельный multi-account workflow.
4. Цель сейчас — сохранить учётку для Git-операций. Clone конкретного проекта не включайте без отдельной просьбы.

Если первые три пункта уже ясны из диалога, не спрашивайте повторно.

Процесс

1. Проверить Локальные Предпосылки

Выполните сами и покажите только итог «есть/нет» с версиями:

Get-Command git -ErrorAction SilentlyContinue
git --version
git credential-manager --version
git config --show-origin --get-all credential.helper
git config --get-urlmatch credential.useHttpPath https://gitlab.com

• Нет Git — остановитесь на установке Git for Windows.
• Нет Git Credential Manager — восстановите его через Git for Windows; отдельный plaintext helper store не предлагайте.
• GCM установлен, но helper не настроен — выполните git credential-manager configure, затем повторите последнюю проверку.
• credential.useHttpPath=true означает credentials по путям репозиториев. Для одной учётки на весь host bundled script меняет это значение только с флагом -HostWide.

2. Создать PAT С Минимальными Правами

На текущем GitLab UI: avatar → Edit profile → Access → Personal access tokens. Если экран отличается, попросите свежий скрин и не угадывайте кнопку.

• Только pull/clone: read_repository.
• Pull + push: write_repository; этот scope уже включает чтение. Дополнительно отмеченный read_repository допустим, но не добавляет возможностей.
• Не отмечайте api, read_api, read_user, registry, runner или Kubernetes scopes, если пользователь не ставил отдельную API/registry-задачу.
• Срок действия выбирает пользователь в пределах, разрешённых текущим GitLab UI.
• После Generate token токен показывается один раз. Пользователь копирует его сейчас и не отправляет в чат.

Если страница уже закрыта и токен не скопирован, не пытайтесь его восстановить: revoke и создание нового токена.

3. Сохранить Credential На Уровне Host

Используйте bundled script scripts/connect-gitlab-account.ps1. Перед показом команды подставьте его реальный абсолютный путь. Для одной учётки на весь gitlab.com:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<путь-к-skill>\scripts\connect-gitlab-account.ps1" -GitLabHost gitlab.com -HostWide

Если уже были неудачные попытки или старый токен, добавьте -Replace. Этот флаг удаляет старую host-level запись перед сохранением новой, поэтому не используйте его при нескольких аккаунтах на одном host.

Script:

• проверяет Git и GCM;
• при необходимости настраивает GCM как helper;
• запрашивает username обычным вводом, токен — скрытым вводом SecureString;
• не помещает токен в URL, аргументы команды, history или вывод;
• сохраняет credential напрямую в GCM;
• читает запись обратно с --no-ui, но выводит только наличие полей;
• завершает строкой LOCAL_CREDENTIAL_READY и явно пишет, что удалённый доступ ещё не проверен.

Пользователь сообщает только финальный статус или ошибку, не токен.

4. Зафиксировать Локальный Результат

LOCAL_CREDENTIAL_READY означает: credential сохранён и читается локальным GCM. Дополнительный cmdkey /list допустим как подтверждающий след Windows, но не как доказательство серверной авторизации.

Если пользователь не хочет указывать репозиторий, завершите здесь:

Сделано: учётная запись сохранена для HTTPS-операций на gitlab.com.
Подтверждено: локальный Git Credential Manager читает credential.
Не подтверждено: доступ GitLab к конкретному приватному репозиторию и право push.
От пользователя сейчас ничего не требуется; URL понадобится только при первой Git-операции.

5. Необязательно Проверить GitLab

Только если пользователь сам дал точный HTTPS URL приватного репозитория, к которому у него есть доступ, или уже находится внутри нужного repo:

git ls-remote https://gitlab.com/<namespace>/<private-project>.git HEAD

Для существующего repo используйте подтверждённый origin. Не угадывайте namespace или название по вкладкам браузера, соседним проектам и памяти.

• Успех для приватного repo → REMOTE_READ_VERIFIED.
• Публичный repo не подходит: команда может пройти анонимно даже с неверным токеном.
• write_repository нельзя честно подтвердить без операции записи в конкретный repo. Не делайте push только ради теста; проверяйте право записи во время запрошенного пользователем push.
• Не используйте /api/v4/user: write_repository прямо не даёт API-аутентификацию, поэтому API-ошибка не проверяет Git over HTTPS.

Разбор Ошибок

• The project you were looking for could not be found or you don't have permission: одновременно возможны неверный URL, отсутствие доступа и неверный credential. Сначала сверить URL с кнопкой Code/Clone with HTTPS; не объявлять токен виноватым без отдельной пробы.
• GCM продолжает брать старый токен: повторить bundled script с -Replace, затем получить новый локальный статус.
• 401/HTTP Basic: Access denied на точном приватном URL: проверить, не истёк ли и не отозван ли PAT, затем заменить credential.
• API вернул 403, а у токена только repository scopes: остановить API-проверку; она не относится к цели.
• git ls-remote прошёл на публичном repo: результат не засчитывать как проверку учётки.
• После Generate token пользователь не запускал сохранение: состояние только TOKEN_CREATED, Windows не обновилась.

Границы

Не используйте skill для SSH keys, GitLab CLI/API login, OAuth browser login, CI/CD tokens, deploy/project/group tokens, GitHub, нескольких аккаунтов на одном GitLab host, автоматического clone/push или восстановления уже потерянного значения PAT.

Никогда не выводите token, не вставляйте его в URL и не просите отправить его в чат. Если token оказался в чате, логе, screenshot или command history, считайте его раскрытым: сначала revoke, затем создайте новый.

Definition Of Done

• Git и GCM найдены и версии зафиксированы.
• Выбран минимальный repository scope под pull или pull+push.
• Token не появился в чате, URL, history, файлах или выводе.
• Bundled script выдал LOCAL_CREDENTIAL_READY.
• Финал различает локальное сохранение и удалённую проверку.
• При наличии точного приватного repo git ls-remote либо дал REMOTE_READ_VERIFIED, либо сохранена точная ошибка без догадки о причине.
• Пользователю явно сказано, требуется ли от него ещё одно действие.

Опрос После Использования

Опрос задаётся один раз — после LOCAL_CREDENTIAL_READY, REMOTE_READ_VERIFIED или явного стопа, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании privyazka-git-k-gitlab было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/privyazka-git-k-gitlab/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/privyazka-git-k-gitlab/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.