GitHub remote操作前の認証preflightをつくる

原因調査では、GitHub CLIの認証が無効であることと、Git HTTPSがCLIのcredential helperを使う設定になっていないことを分けて確認した。再認証後にcredential helperを設定すると、remote mainの直接読み取りが成功した。この確認を毎回の手作業にしないため、repository rootへscripts/ensure-github-git-authを追加した。

wrapperは引数を受け付けず、GitHub CLIの認証、Gitが使うcredential helperの設定、remote mainの実読みに必要な3段階を順に確認する。認証確認とremote readの出力は破棄し、tokenやcredentialを表示しない。失敗時は終了code 1で停止して復旧手順を示し、引数が渡された場合は終了code 2で拒否する。wrapper自身は再ログインを自動実行せず、運用者が復旧後にpreflightを再実行する境界とした。

#!/usr/bin/env bash
set -euo pipefail

if [ "$#" -ne 0 ]; then
  echo "usage: scripts/ensure-github-git-auth" >&2
  exit 2
fi

if ! gh auth status --hostname github.com >/dev/null 2>&1; then
  echo "error: GitHub CLI authentication is missing or invalid." >&2
  exit 1
fi

gh auth setup-git --hostname github.com >/dev/null

if ! git ls-remote --exit-code origin refs/heads/main >/dev/null 2>&1; then
  echo "error: git cannot read origin/main with the current GitHub credentials." >&2
  exit 1
fi

echo "GitHub CLI and git remote authentication are ready."

実装では、wrapperのfailure messageに再認証とcredential helper再設定の手順も記載した。git fetch、git pull、git push、git ls-remote、gh prの前にpreflightを実行し、失敗した場合はcached origin/mainを根拠に進めず、再認証後にpreflightをやり直す運用とした。

• AGENTS.mdとdocs/operating-model.mdでは、GitHub Auth Preflightをsoftware deliveryの工程へ追加した。
• .agents/skills/software-delivery/SKILL.mdでは、remote操作の前にpreflightを実行し、失敗時は再認証まで完了してからbranch作成やdeliveryを続けるgateを追加した。
• .agents/skills/pr-review/SKILL.mdでは、connectorを使えずCLIへfallbackするreviewでもpreflightを必須とし、失敗時はcached tracking情報からreviewせずblockerとして扱うようにした。
• .codex/agents/full-stack-engineer.tomlと.codex/agents/pr-reviewer.tomlには、実装とreviewそれぞれの責務に合わせて同じfailure boundaryを追加した。
• .codex/rules/organization.rulesでは、引数なしwrapper、read-onlyの認証状態確認、credential helperの再設定だけを通常のpreflightと修復操作として許可するentryを追加した。
• .codex/rules/README.mdとdocs/setup.mdには、wrapperの処理、再認証手順、古いtracking情報を使わない制約を同期した。

検証では、OSのcredential storeを利用できないrestricted sandboxでwrapperが認証failureとして停止することを確認した。credential storeへアクセスできる実行境界では同じwrapperが成功し、認証済みのCLIとGitからremote mainを読めることを確認した。あわせてshell構文、すべてのCustom Agent TOMLのparse、差分の空白errorを検査した。

この作業では、CEOが認証確認と再認証を運用へ組み込む範囲を示し、汎用のメインAIが原因調査、再認証、10ファイルの実装と検証を行った。Full-Stack EngineerとPR Reviewerは設定変更の対象であり、このActivityの実作業には参加していない。