このリポジトリの runtime-plugin-validate.yml の 9 ジョブがテストの宣言に無く、cross-refactoring の項目が壊しても手元で拾えない #1694

依頼（原文）

このリポジトリの継続的統合の runtime-plugin-validate.yml の 9 ジョブ（生成物の同期・frontmatter・リポジトリの前提・手順書の変数・
リンク・文書の行数・指示書・必須チェックの設定・claude plugin validate）は、テストの宣言（.ndf/project.json の test.suites）に無い。
cross-refactoring の項目がこれらを壊しても、項目の検証と手元の最終ゲートは拾わない。

#464 の実装（PR #1697）の後の今の宣言で refactor_lib.ci_coverage.compare_jobs を打つと、ジョブ 24 件のうち宣言に無いものは次の 11 件である（2026-11-04、develop 252ddf8）。

• runtime-plugin-validate.yml の 10 件: doc-line-limit-check・instruction-files-check・markdown-link-check・
  required-checks-check・runtime-plugin-build-check・runtime-plugin-validate・service-boundary-check・skill-frontmatter-check・
  skill-repo-assumptions-check・skill-shell-vars-check
• runtime-plugin-smoke-latest.yml の runtime-smoke-latest

宣言の ci_jobs・ci_exempt はワークフローのファイル（.github/workflows/<名前>.yml）の単位で書く。

受け入れ条件（案）

• 上の 11 件のそれぞれが、宣言の suite の ci_jobs か test.ci_exempt（理由つき）のどちらかに載る
• cross-refactoring の init がこのリポジトリで宣言に無いジョブを知らせない

（書き手: 起票者、日付: 2026-10-03 起票・2026-11-04 更新。#464 の設計の途中で範囲外として起票した記録で、利用者の指示の原文は無い）

人へ問わずに進め、決められない点は前提か未決として課題の本文へ書く。

（書き手: AI の起動指示、日付: 2026-11-05）

起票者の推定

目的

cross-refactoring の項目が、このリポジトリの継続的統合で検査している内容（生成物の同期・Skill の frontmatter・リンク・文書の行数・指示書など）を壊したとき、Pull Request を出す前の手元の検証で気づけるようにする。手元で走らせられない検査は、走らせない理由を宣言に残し、init が毎回「宣言に無いジョブ」を知らせる状態を無くす。

前提

• 前提 1: 変更の対象は、このリポジトリのプロジェクトの宣言（.ndf/project.json の test）だけである。突き合わせの処理（ci_coverage.py）・宣言のスキーマ・ワークフローは変えない
• 前提 2: ジョブの識別子は、1 つのファイルのジョブがすべて同じ扱いになるときはファイルの単位（<パス>）、扱いが分かれるときはジョブの単位（<パス>#<ジョブ id>）で書く
• 前提 3: ジョブを suite にする条件は、次の 3 つをすべて満たすことである。満たさないジョブは除外にする
  • 秘密・ネットワーク・Pull Request の文脈（宛先のブランチ・本文）を使わずに、手元で判定が決まる
  • 継続的統合のジョブと同じスクリプトを同じ引数で走らせる
  • 1 回の実行が 60 秒以内に終わる（2026-11-05 の手元の実測で最長は validate-runtime-plugins.sh の 12.2 秒）
• 前提 4: 前提 3 の判定の材料は下の「現状の実測」の表である。どのジョブをどちらに載せるか・suite の分け方（ジョブごとか、まとめるか）・paths は設計で決める
• 前提 5: claude plugin validate を走らせるジョブ（runtime-plugin-validate）は、手元に claude の CLI があることを要る。cross-refactoring のホストは Claude Code か Codex であり、Codex のホストでは CLI が無いことがある。suite にするか除外するかは設計で決め、決めた理由を宣言か設計に残す

現状の実測

2026-11-05、develop d511591、このリポジトリの worktree で各ジョブの run の行を走らせた結果。

手元の所要は 1 回の実測で、ばらつきは測っていない。上の 9 本の検査スクリプトは、どれも対象のファイルのパスを引数に受けない（各スクリプトの argparse の定義を確かめた）。

対象範囲

含む:

• 宣言に無いジョブ 11 件を、suite の ci_jobs か test.ci_exempt に載せる
• suite にするジョブのために、静的解析の suite（kind: lint）を宣言へ足す
• 除外にするジョブの理由を書く

含まない:

• 検査スクリプトに、対象のファイルのパスを受ける引数（範囲テストの形）を足すこと
• 突き合わせの処理・宣言のスキーマ・ワークフローの変更
• このリポジトリ以外のプロジェクトの宣言
• 宣言の再解析（project-decl.py check が古いと判定する件。宣言の analysis.inputs の更新を含む）

ドメインイベント

E3・E4 の振る舞いは既存の処理（lint_verdict）が持ち、この課題では変えない。

用語

受け入れ条件

• 1. 宣言に無いジョブ 11 件（上の「現状の実測」の表の行）のそれぞれが、suite の ci_jobs か test.ci_exempt の job のどちらか一方だけに、ファイルの単位かジョブの単位の識別子で当たる
• 2. test.ci_exempt に足した行は、reason が空でなく、手元で判定が決まらない要因（「現状の実測」の表の最後の列に当たるもの）か、走らせない理由を書いている
• 3. このリポジトリの宣言と作業ディレクトリで compare_jobs を打つと、status が compared で undeclared が 0 件になる（init が「宣言に無いもの」の行を出さない）
• 4. 足した suite のそれぞれは、command を作業ディレクトリの根で走らせると終了コード 0 で終わり、そのコマンドは ci_jobs に書いたジョブの run の行と同じスクリプトを同じ引数で呼ぶ（継続的統合だけで要る準備の手順は除く）
• 5. project-decl.py check --root . が 3（壊れている）を返さない
• 6. 既存の suite（pytest・factory・script-structure・ndf-contracts・lint）と既存の除外 5 件は、名前・コマンド・ci_jobs・理由が変わらない

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

進行

モード: — / 進め方: auto

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

人の判断待ち（開発ループ lroot3）

• 判定: unknown（承認ゲート 1）
• 理由: 設計の中身は Mission と Vision に沿う。継続的統合の 11 件を宣言へ載せ、壊れたことを手元の最終ゲートで止められるようにする。ほかのリポジトリで変わるものは設定の値で受け、配布物・スキーマ・処理は変えない（Value 6）。案は 9 件を静的解析、2 件を理由つきの除外に分けるだけにとどめ、仕組みを足さない（Value 3・Value 5）。ジョブ 1 件に suite を 1 本置き、既存失敗と変更起因を分けて判定できるようにする（Value 7）／コマンド 9 本は書く前に実行し、終了コードと所要時間（合計 19.6 秒）を実測している。採らなかった案とその理由も決定の記録に残している（Value 4・Value 8）／要求の確認（requirements-check）が終了コード 2 で止まった。要求の文書 issues/issue-1694-requirements.md を読めず、原因も確かめていない。PR 本文はこの検査を「済んでいない扱い」と正直に記録しているが、設計の承認の対象である要求の文書の検査が終わっていない。配布の前に取れる確認が欠けたまま関門 1 を自動で通すかは決められない（Value 1：確かめていないものを済んだと記録しない、Value 2）／claude plugin validate が通信するかは確かめられていない。通信するなら、不変条件 I4（秘密とネットワークを使わずに走る）に反した suite を宣言へ載せることになる。この点を実装の検証へ持ち越すことの是非は、材料からは決められない／変更が触るのは文書だけで、利用者の設定（.ndf/）はまだ書き換えていない。ただし設計の結果として、実装で .ndf/project.json の test を手で書き換える。これは C7（利用者の設定の書き換え）に当たり、設計の承認ではなく本番への配布の承認（関門 2）で人が見る必要がある。PR 本文はモードを light、設計文書は standard と書いており、食い違っている
• 根拠の項目: Mission, Vision, Value 1, Value 2, Value 3, Value 4, Value 5, Value 6, Value 7, Value 8, C7
• 設計 Pull Request: このリポジトリのテストの宣言: 継続的統合のジョブ 11 件を、手元で走らせる静的解析か理由つきの除外として載せる（#1694） #2573
• 答え: approved
• 答え方: python3 /persistent/ai/.claude/plugins/cache/ai-plugins/ndf/10.27.21/scripts/sprint-state.py loop answer lroot3 1694 --approved|--rejected|--revise --note <指摘ファイル>

振り返り: #2631 (comment)