Как начать кодить

Пять шагов, которые нужно пройти один раз перед тем, как открыть первый PR: разобраться с доступами, настроить git на два GitHub-аккаунта, авторизовать оба в gh, подключить Atlassian MCP и склонировать репозиторий с общими правилами. Остальное — уже про конкретный сервис, и это отдельная тема.

1. Доступы

Проверьте и запросите, если чего-то нет:

• GitHub Enterprise smartcore-pci-software — организация PCI-контура: drivers, card-manager, tokenization-service, superpos-api-gateway-kotlin.
• GitHub smartpayments-dev — всё остальное: ядро, шлюзы, фронтенды, эта база знаний.
• admin.env.smartstaging.xyz — админка окружений, через которую выдаётся тестовый стенд. Доступ даёт группа Staging Stand Constructor в Okta, выдаёт администратор.
• AWS staging (281125375263), роль AdministratorAccess — вход через d-9967022768.awsapps.com или кнопку AWS в Okta.

Без первых двух пунктов не откроются репозитории на следующем шаге — начинайте с них.

2. Git и два GitHub-аккаунта

В workspace два разных аккаунта GitHub на одном хосте github.com: один для PCI-организации, второй для всего остального. Так как хост у обоих одинаковый, разводить их приходится через SSH-алиасы, а не через штатный логин.

Сгенерируйте два SSH-ключа — по одному на каждый аккаунт:

ssh-keygen -t ed25519 -C "[email protected] (smartpayments-dev)" -f ~/.ssh/id_ed25519_general
ssh-keygen -t ed25519 -C "[email protected] (smartcore-pci)" -f ~/.ssh/id_ed25519_pci

Добавьте каждый ключ в свой аккаунт GitHub — публичную часть (.pub) в Settings → SSH and GPG keys того аккаунта, которому он принадлежит.

Пропишите оба в ~/.ssh/config — второй хост здесь фиктивный, реальный HostName у обоих один и тот же github.com, разница только в ключе:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_general
  IdentitiesOnly yes

Host github.pci
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_pci
  IdentitiesOnly yes

Для PCI-репозиториев меняйте домен в SSH-ссылке на клон. GitHub всегда показывает адрес с github.com, его нужно поправить руками:

# так даст сам GitHub, но у вас сработает только на общих репозиториях
git clone [email protected]:smartcore-pci-software/drivers.git

# а для PCI-репозитория нужно вот так
git clone [email protected]:smartcore-pci-software/drivers.git

Если репозиторий уже склонирован не под тем алиасом, git remote set-url origin [email protected]:smartcore-pci-software/drivers.git — без пере-клона.

3. Авторизация gh

gh — это отдельная авторизация от git по SSH, и её тоже нужно настроить на оба аккаунта, чтобы агент мог сам переключаться между ними и создавать PR.

gh auth login --hostname github.com   # первый аккаунт
gh auth login --hostname github.com   # второй — gh 2.40+ хранит несколько на одном хосте
gh auth status                        # проверить, что оба видны

Активный аккаунт в gh один на всю машину и не зависит от того, в каком репозитории вы находитесь, поэтому переключаться приходится вручную — либо через gh auth switch --hostname github.com --user <логин>, либо через обёртку smartpayments-skills/bin/ghr (см. следующий шаг), которая сама смотрит git remote репозитория и выбирает нужный аккаунт. Подробности и типичные ошибки — в правиле github-accounts.md.

4. Atlassian MCP для Cursor

Даёт агенту доступ к Jira и Confluence прямо из чата. Добавляется как удалённый MCP-сервер:

1. В Cursor: Settings → MCP → Add new MCP server, либо руками в mcp.json:

   {
     "mcpServers": {
       "atlassian": {
         "url": "https://mcp.atlassian.com/v2/mcp"
       }
     }
   }

2. При первом обращении Cursor откроет окно авторизации Atlassian — войдите тем же аккаунтом, что и в Jira/Confluence компании. Доступ идёт через OAuth и подчиняется вашим обычным правам, отдельно ничего не выдаётся.

5. Общие правила и скиллы

Правила разработки (разбивка на PR, ветки, описание PR), доступ к аккаунтам GitHub и скиллы для повторяющихся задач лежат отдельным репозиторием, а не внутри каждого проекта:

git clone [email protected]:smartpayments-dev/smartpayments-skills.git

Клонируйте его в корень рабочей папки с проектами — рядом с остальными репозиториями, а не внутри одного из них. Агенты в этом workspace читают эти правила автоматически перед началом работы; человеку стоит хотя бы пробежать README.md в нём, чтобы знать, что там есть.

Создание тестового стенда

Поднимать всё окружение с нуля под каждую задачу слишком накладно, а при параллельной разработке нескольких задач переключение между полными окружениями съедает больше времени, чем сама разработка. Поэтому вместо этого используется конструктор стендов — admin.env.smartstaging.xyz (доступ описан в разделе «Доступы» выше).

Конструктор разворачивает не один сервис, а целую связку — так, чтобы проверить флоу целиком, а не изолированный кусок кода. У каждого сервиса в связке можно независимо выбрать свою ветку, поэтому стенд можно собрать ровно под задачу: например, ядро с фичи-веткой и все остальные сервисы — как в проде.

Стенд создаётся с датой самоуничтожения — не нужно отдельно помнить о нём и удалять руками, когда задача закрыта. При пуше в ветку, на которой стоит сервис, стенд сам подхватывает изменения и обновляется — передеплоивать руками не требуется.