[aside] web デプロイ CI が使う CLOUDFLARE_API_TOKEN が scope 限定トークンではなく personal User API Token になっている。

run 26700240875 の失敗ログで判明:wrangler の `Getting User settings...` セクションが `You are logged in with an User API Token, associated with the email rail.sky@gmail.com` と出力しており、CI の deploy credential がアカウント全権相当の個人ユーザートークンになっている。今回 CI を落とした route 認証エラー(`/zones/.../workers/routes` の権限不足、code 10000)とは別軸の、credential hygiene の観点での観察。

least-privilege なら deploy 専用に scope を絞った token(Cloudflare の "Edit Cloudflare Workers" テンプレ相当 = Account Workers Scripts:Edit + Zone Workers Routes:Edit を対象 zone のみ)を mint して GH secret に置く方が望ましい。personal user token は CF アカウントの他リソースにも触れる広い権限を CI に晒している。

今回は route 認証エラーの修正方針判断(A: token に Workers Routes 権限追加 / B: wrangler.jsonc の routes 行 revert)が主タスクで、token の種別そのものは scope 外のため未着手で残す。着手トリガー = A を選ぶなら、ついでに personal token → scoped token に差し替えるのが自然な合流点。B を選んでも personal token が CI secret に残る点は別途残課題。関連:[[project_quacker_token_scope_direction]] は quacker 自身の token scope の話で別物だが、least-privilege 志向は同じ。