何が起きているか

Pull Request で走るジョブのうち 3 つが ruleset の必須の検査に入っていない。
落ちても mergeStateStatus は塞がらず、マージできる。

配布（v10.12.0、PR #651 / #652）で必須の検査の一覧を引いたときに見つけた。この配布の
範囲外である（版数を直す作業とは別の話で、どちらの PR でも直していない）。

必須になっている 12 個

$ gh api repos/devbasex/ai-plugins/rulesets/22332172 \
    --jq '.rules[]|select(.type=="required_status_checks")|.parameters.required_status_checks[].context'
guard
pytest
runtime-smoke (claude)
runtime-smoke (codex)
runtime-smoke (kiro)
runtime-smoke (agy)
runtime-plugin-build-check
skill-frontmatter-check
skill-repo-assumptions-check
runtime-plugin-validate
markdown-link-check
instruction-files-check

instruction-files-check は手で足された。 突き合わせる検査は無いままで、入れ忘れの仕組みの問題は残る
（git grep -ln required_status_checks origin/develop -- scripts .github docs plugins は plugins/ndf/scripts/project_lib/measure_ci.py ほか 3 件を返すが、measure_ci.py は CI の所要を測るために必須の一覧を読むだけで、ワークフローのジョブ名との突き合わせではない。2026-10-03、develop 37f8d57）。

走るが必須になっていない 3 個（起票の時点）

いずれもジョブを足したときに ruleset の一覧へ入れていない。ワークフローの側だけを足すと、
走って赤くなるだけで塞がらない。表に出ない失敗にあたる。

後から足されて必須になっていない 3 個（2026-09-29 時点。2026-10-03 も同じで、ruleset の一覧は 12 個のまま）

gh api repos/devbasex/ai-plugins/rulesets/22332172 の必須の一覧は上の 12 個のままで、その後に足したワークフローの
ジョブも入っていない。

ジョブ名 check が 3 つのワークフローで重なっている（PR body decisions・Glossary・Script structure）。必須の一覧は
context の名前で照合するため、どれか 1 つを check として必須に入れると、どのワークフローのジョブを指すかが
名前から決まらない。

走るが必須になっていないジョブは、上の 2 つの表で計 6 つである。

なぜ問題か

赤い印は PR ページに出るが、マージの判定には入らない。人がその 3 つを目で見て判断する
運用になっている。 見落とせば、行数の基準を超えた文書・$SCRIPTS の解決を書き忘れた
Skill・決めたことの節を欠いた PR 本文がそのまま入る。

必須の検査を足す動機がそもそもこれであり、12 個は塞いで 3 個は塞がないという区別に理由が
見当たらない（意図して外しているなら、その理由をどこかへ書く必要がある）。

直し方の候補

1. 3 つを ruleset の required_status_checks へ足す
2. 意図して外しているなら、docs/ のどこかに「必須にしない検査とその理由」を書く
3. ジョブを足したときに ruleset へ入れ忘れないようにする。 走るジョブ名と必須の一覧を
   突き合わせる検査を足す（.github/workflows/*.yml の jobs の名前と、ruleset の
   context の差を出す）。これが無いと、次に足したジョブでも同じことが起きる

直した後に合わせる記述

必須の検査の数を書いた文書がある。 docs/versioning-and-distribution.md:166 は「必須の検査 12 個は
Pull Request で走るため」と書く。3 つのうち必須にしたものがあれば、この数も変わる。

起票時の受け入れ条件（下の「受け入れ条件」で置き換えた）

• 3 つのそれぞれについて、必須にするか外すかが決まっている → 6 つとも必須にすると決まった（2026-10-06、利用者の決定）。下の AC1〜AC3
• 外すものがあるなら、その理由が説明文書に書かれている → 外すものは無い。「必須にしない」とした過去の決定の記述を改める（AC8）
• ジョブを足したときの入れ忘れが機械で見つかる（または、見つけない理由が書かれている） → 見つける方を採った（AC4〜AC7）
• 必須の検査の数を書いた文書（docs/versioning-and-distribution.md:166）が、決めた後の一覧と一致している → AC9

決定（2026-10-06 利用者）

6 つとも必須にする（直し方の候補 1 と 3）。

• ジョブ名 check が重なる 3 つ（PR body decisions・Glossary・Script structure）は、一意の名前へ改名してから必須に入れる
• doc-line-limit-check・skill-shell-vars-check・3 つの改名後の名前・lint を ruleset の required_status_checks へ足す（ruleset の変更は本番系の設定変更なので承認ゲート 2 で扱う）
• ワークフローのジョブ名と ruleset の必須の一覧を突き合わせる検査を足し、次にジョブを足したときの入れ忘れを機械で見つける
• pr-body-decisions の古い失敗で止まる merge-when-green / release: 同じチェックの古い失敗と、Runner が付かずに取り消されたジョブを CI の失敗と数えて止まる #1645 は同じスプリントで直す
• docs/versioning-and-distribution.md の必須の検査の数を、決めた後の一覧に合わせる

要求と受け入れ条件

上の節（「何が起きているか」から「決定」まで）を依頼の原文として扱い、手を入れない。以下は原文と決定から導いた要求である。
語は用語集に合わせ、継続的統合のジョブが返す合否を「チェック」、ruleset の required_status_checks に載ったものを「必須のチェック」と呼ぶ
（原文の「必須の検査」と同じもの。「検査」は用語集ではフェーズの名前のため、要求の側では使わない）。

目的

• Pull Request で走るチェックが落ちたら、マージの判定がそれを塞ぐ状態にする。人が赤い印を目で拾う運用をやめる
• 次にワークフローへジョブを足したとき、必須のチェックへの入れ忘れを機械が見つける

前提

• 前提 1: 対象の ruleset は protect main and develop（id 22332172。refs/heads/main と refs/heads/develop が対象）の 1 つだけである。2026-10-05 に gh api repos/devbasex/ai-plugins/rulesets が返したのはこの 1 件だった
• 前提 2: ブランチに効く必須のチェックの一覧は gh api repos/<owner>/<repo>/rules/branches/<branch> で読める。このリポジトリは公開で、2026-10-05 に未認証の curl でも HTTP 200 が返った。CI の GITHUB_TOKEN で読める
• 前提 3: ruleset の変更（必須のチェックの追加）は、実装の Pull Request が develop へ入り、改名したジョブ名が develop で走るようになった後に、承認ゲート 2 で利用者の承認を得て行う。AI は承認なしに ruleset を変えない
• 前提 4: pr-body-decisions のチェックを必須にすると、本文の編集の前に落ちた古い実行が残った Pull Request で merge-when-green が止まる（merge-when-green / release: 同じチェックの古い失敗と、Runner が付かずに取り消されたジョブを CI の失敗と数えて止まる #1645 の現象）。merge-when-green / release: 同じチェックの古い失敗と、Runner が付かずに取り消されたジョブを CI の失敗と数えて止まる #1645 は同じスプリントで直すと決まっており、ruleset へ足すのは merge-when-green / release: 同じチェックの古い失敗と、Runner が付かずに取り消されたジョブを CI の失敗と数えて止まる #1645 の修正が develop に入った後とする。merge-when-green / release: 同じチェックの古い失敗と、Runner が付かずに取り消されたジョブを CI の失敗と数えて止まる #1645 の修正そのものはこの課題の範囲に含めない
• 前提 5: 6 つのジョブは、いずれも pull_request の起動を paths で絞っていない（2026-10-05 にワークフローの on: を読んで確かめた）。そのため必須にしても、対象外の変更で「実行されていない」のまま残ってマージを塞ぐことはない
• 前提 6: pr-body-decisions のチェックは設計の Pull Request（head が design/ で始まる）以外では成功で終わる。必須にしても、実装とリリースの Pull Request を塞がない

対象範囲

含む:

• 名前が重なる 3 つのジョブ（PR body decisions・Glossary・Script structure の check）を一意の名前へ改名する
• ワークフローのジョブから決まるチェックの名前と、ブランチの必須のチェックの一覧を突き合わせるチェックを足し、継続的統合で走らせる
• 必須にしないジョブを、理由と組で宣言できるようにする（集約される前の分割ジョブ・判定だけのジョブなど）
• 承認ゲート 2 で、6 つ（改名後の名前）と、足した突き合わせのチェックを ruleset の必須のチェックへ足す手順を承認資料に載せる
• 必須のチェックの数を持つ文書と、「必須にしない」とした過去の決定の記述を、決めた後の一覧に合わせる

含まない:

• merge-when-green / release: 同じチェックの古い失敗と、Runner が付かずに取り消されたジョブを CI の失敗と数えて止まる #1645（merge-when-green が古い失敗を数える）の修正。同じスプリントの別の課題で扱う
• ruleset のほかの規則（pull_request・deletion・non_fast_forward・strict_required_status_checks_policy）の変更
• workflow_dispatch だけで走るワークフロー（runtime-plugin-authenticated-smoke.yml）を必須にすること
• 6 つのジョブの中身（何を見て落とすか）の変更
• ほかのリポジトリの ruleset の変更

ドメインイベント

用語

受け入れ条件

• AC1: PR body decisions・Glossary・Script structure のジョブのチェックの名前が、互いにも他のワークフローのジョブとも重ならない（pull_request で走るジョブのチェックの名前の一覧に重複が無い）
• AC2: 実装の Pull Request で、改名した 3 つのジョブが新しいチェックの名前で結果を返す（gh pr checks <番号> に新しい名前が出て、check という名前が出ない）
• AC3: 承認ゲート 2 の後、gh api repos/devbasex/ai-plugins/rules/branches/develop と .../main が返す必須のチェックの一覧に、doc-line-limit-check・skill-shell-vars-check・lint・改名後の 3 つの名前・突き合わせのチェックの名前が載り、もとの 12 個も残る（計 19 個）
• AC4: 突き合わせのチェックは、pull_request で走るジョブから決まるチェックの名前のうち、宛先のブランチの必須のチェックにも必須にしないジョブにも当たらないものを 1 件ずつ名前とワークフローのパスつきで出し、1 件でもあれば失敗で終わる
• AC5: 突き合わせのチェックは、必須のチェックのうち、どのジョブのチェックの名前にも当たらないもの（改名・削除で消えた名前）も出して失敗で終わる
• AC6: 突き合わせのチェックは、ジョブの name: と matrix から決まる名前を Pull Request に載る名前と同じ形で作る。前提: 2026-10-05 の develop のワークフローと必須のチェック 12 個。操作: 必須にしないジョブの宣言だけを入れて走らせる。結果: 差に出るのは 6 つ（AC1 の改名後の名前を含む）と突き合わせのチェック自身だけで、runtime-smoke (claude) など matrix の 4 つと pytest は差に出ない
• AC7: 必須の一覧を読めないとき（API の失敗・権限不足・時間切れ）、突き合わせのチェックは成功で終わらず、読めなかった理由を出して失敗で終わる
• AC8: 「必須のチェックにしない」と書いた記述（.github/workflows/pr-body-decisions.yml の冒頭のコメントと docs/specifications/ndf-workflow-unit-and-gates.md の決定の表の「継続的統合の突き合わせは必須のチェックにしない」）が、必須にした事実と決めた日・決めた人に改まる
• AC9: 必須のチェックの数を持つ文書（docs/versioning-and-distribution.md の散文とコンソールの例の説明、ほかに git grep -n "必須のチェック" が数を伴って返す現行の文書）の数が AC3 の一覧の数と一致する。リリース済みの版の記録（docs/ndf-version-decisions*.md・docs/development-history/・docs/presentations/・docs/articles/）は書き換えない
• AC10: 既存のチェックが退行しない。もとの 12 個のチェックの名前は変わらず、実装の Pull Request でも結果を返す

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

モード: —

• 要求と受け入れ条件 — 2026-10-05 22:52
• 作業場所の用意 — 2026-10-06 00:00
• 設計 — 2026-10-05 23:01
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-10-06 00:00
• 実装 — 2026-10-06 00:01
• 構造改善 — 2026-10-06 01:59
• 実装レビュー — 2026-10-06 02:19
• 完了判定 — 2026-10-06 00:13
• Pull Request — 2026-10-06 00:18
• 確定仕様化 — 2026-10-06 03:12
• 後片付け
• 配布 — 2026-10-06 02:40
• 体裁レビュー
• リリース後テスト
• 振り返り — 2026-10-06 03:13
• 棚卸し

振り返り: #1780 (comment)