메뉴
CI (GitHub Actions の Test / Build / Security job) が想定時間を大幅に超過した場合のハング検出と cancel / rerun フロー。macos-latest runner の混雑や cargo の依存取得・コンパイル stall 等、transient な GHA 側障害の典型対処。CI が想定より長く `in_progress` のまま動かない時に発動。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | core_ci_hang_recovery |
| description | CI (GitHub Actions の Test / Build / Security job) が想定時間を大幅に超過した場合のハング検出と cancel / rerun フロー。macos-latest runner の混雑や cargo の依存取得・コンパイル stall 等、transient な GHA 側障害の典型対処。CI が想定より長く `in_progress` のまま動かない時に発動。 |
CSW の CI は GitHub Actions 上で動く Rust ワークフロー群:
| Workflow | runner | 内容 | 通常の目安 |
|---|---|---|---|
| Test | macos-latest | cargo test --workspace --exclude csw-desktop (core + cli) | 数分〜十数分 (依存コンパイル含む) |
| Build | macos-latest | cargo build --workspace (desktop 含む全 crate) | 数分〜十数分 |
| Security | ubuntu-latest | gitleaks secret scan | 1〜2 分 |
これらを大幅に超えて in_progress のまま動かない場合、特定 step (toolchain setup / 依存 crate の取得・コンパイル / runner 起動待ち) でハングしている可能性が高い。
CSW で疑うべき transient 障害の典型:
queued / in_progress が長引くことがある。Updating crates.io index や Downloading で固まる。いずれも PR のコード側ではなく GHA runner 側の transient な問題。force push やブランチ切り直しでは直らない。cancel + rerun が正解 (§5 アンチパターン参照)。
放置すると:
以下のいずれかに該当する時:
in_progress のまま step が進まない注意: CSW の Test / Build は依存コンパイルで通常でも数分〜十数分かかる。「遅い」だけで即 cancel しない。step が
in_progressのまま進捗が止まっているか (§3.1 で step 名を確認) を見て判断する。
<owner>/<repo> は matsumotory/claude-desktop-switcher。<branch> は作業ブランチ。
RUN_ID=$(gh run list --repo <owner>/<repo> --branch <branch> --limit 1 --json databaseId --jq '.[0].databaseId')
# job ごとに in_progress な step 名を出す (Test / Build を見分ける)
gh run view "$RUN_ID" --repo <owner>/<repo> --json jobs \
--jq '.jobs[] | {job: .name, step: (.steps[] | select(.status=="in_progress") | .name)}'
例: Setup Rust / Build all crates / Run unit and integration tests が長時間 in_progress のまま、かつ進捗ログが止まっていればハングと判断する。gh run view "$RUN_ID" --repo <owner>/<repo> --log | tail -50 でログ末尾も確認するとよい (Downloading / Updating crates.io index で固まっていれば network stall)。
gh run cancel "$RUN_ID" --repo <owner>/<repo>
# cancel は async — completed を待ってから rerun
until [[ "$(gh run view "$RUN_ID" --repo <owner>/<repo> --json status --jq '.status')" == "completed" ]]; do
sleep 5
done
gh run rerun "$RUN_ID" --repo <owner>/<repo>
gh run rerunは cancel 中 / in_progress 中は実行できない (cannot be rerun; This workflow is already running)。必ずcompletedを待つ。
failed した job だけ再実行したい場合は gh run rerun "$RUN_ID" --repo <owner>/<repo> --failed。runner 混雑が原因の rerun はそのまま全 job で問題ない。
CSW の Test / Build はコンパイル時間が長いので、タイムアウトを長めに取る。最大 20 分タイムアウト + step 詳細出力で polling する:
START=$(date +%s)
until [[ "$(gh pr view <PR> --repo <owner>/<repo> --json statusCheckRollup --jq '[.statusCheckRollup[].status] | all(. == "COMPLETED")')" == "true" ]]; do
NOW=$(date +%s)
if (( NOW - START > 1200 )); then
echo "[WARN] CI > 20min, check for hang"
RUN_ID=$(gh run list --repo <owner>/<repo> --branch <branch> --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view "$RUN_ID" --repo <owner>/<repo> --json jobs \
--jq '.jobs[] | {job: .name, step: (.steps[] | select(.status=="in_progress") | .name)}'
break
fi
sleep 30
done
これで 20 分以上ハングしたら自動検知 → ユーザーに報告できる。
長時間 (>5 分) 待つ CI 監視は Bash の run_in_background: true でバックグラウンド化する。ただし:
statusCheckRollup を 全 check 集約 (上記 all(. == "COMPLETED")) で判定する。1 件だけ見て早合点しないgh run rerun を cancel 完了前に呼ぶ: エラーになる。completed を待つ--admin / --no-verify でゲートを飛ばしてマージ回避する: ハング回避を口実に検証を飛ばさない。CI green を待ってから gh pr merge --squash (上位ルール参照)| 症状 | 疑い | 対処 |
|---|---|---|
queued のまま長い | macos-latest runner キュー混雑 | 数分待つ。10 分超なら cancel + rerun |
Setup Rust で止まる | toolchain 取得 stall | cancel + rerun |
Updating crates.io index / Downloading で止まる | registry network stall | cancel + rerun |
| コンパイル途中で長時間無進捗 | runner リソース逼迫 | cancel + rerun |
| 特定 test が毎回同じ所で落ちる/固まる | コード側の問題 (transient ではない) | rerun せず実装を疑う (bugfix skill へ) |
最後の行が重要: rerun して同じ step で再現するならコード側の問題。transient かどうかは「1 回 rerun して直るか」で切り分ける。2 回同じ所でハング/失敗したら GHA 側ではなく実装・依存定義を疑い、cargo (CI 上) で再現させて直す。
core_pr_review_cycle (PR フロー / マージ判定), modern-rust-workflow (cargo 検証コマンド全般), core_bug_fix_protocol (rerun でも直らない = コード側のとき)core_ai_workflow の「ループの安全装置」を参照gh pr merge --squash、--admin / --no-verify は使わない。main への直接 push 禁止、作業は .claude/worktrees/<name> で隔離CSW のユーザー向け UI・コピーの正典。ユーザー向け語彙(「環境」)、共有モードの3語(共有/分離/コピー)、選択行の見せ方(塗りのみ)、メニューバーを主機構にしない、コピーの一次ソースは LP、Claude 本体の現行用語への追従、並列 UI の分量・文体、禁止記号(em-dash/※/絵文字)を定める。アプリ UI・LP・docs のラベル/モード名/説明文/マイクロコピーを作る/変える前に読む。
用語・概念・UI・コピーを1箇所変えたら、全サーフェス（アプリ UI・トレイ・docs ja/en・README ja/en・LP ja/en・スクリーンショット・OG 画像）へ同時反映し、旧表現を全リポ grep で残存ゼロ確認する。スクショ等の非テキスト派生物は grep に映らないので明示列挙して再生成する。UI・用語・コピーを変えたら発動。
PR をマージする際のレビュー・マージ実行チェックリスト (Rust + Tauri v2 / CSW)。スコープ外変更・安全装置の格下げ・テスト負債・高リスクインフラファイル改変を検出し、CI green を確認したうえで自律的に squash merge する手順を定義する。
日本語の見出し・本文の折り返し / タイポグラフィ品質ゲート。日本語 UI・LP・ドキュメントのコピーやフォントサイズ、改行、行間に触れる前に必ず読む。英語の折り返しルールをそのまま日本語に当てると崩れる(禁則・文節・字面密度が違う)ため、JP 専用の規則・モダン CSS・モジュラースケール・実機検証手順を正典化する。design-taste-frontend を補完する JP 特化スキル。
LP(website/) と人間向けドキュメント(docs/・README) と実装(crates/) が「同じ一つの事実」を語っているかを横断監査する。用語・アーキテクチャ・CLI 表面・機能主張・ja/en 整合・禁止表現を点検し、不整合を file:line と修正案つきで報告する。リリース前やドキュメント/LP/実装を変えた後に実行する read-only 監査。
CSW (Rust + Tauri v2) の QA・検証プロセスと継続的改善のルールを定義するスキル。コード変更の完了報告前、PR を出す前、機能や修正を「できた」と言う前に発動し、検証順序とエビデンス必須の原則を強制する。