ndf v10.17.27

• Docs: 用語集に「チェイン」を足す（#1163）
• Fix: 書き込み先の案内が ~ で始まるパスを主ディレクトリの中と見なす（#1165）
• cross-review と cross-refactoring の文書とプロンプトは、エンジニアになじむ業界の用語で書かれています（#1167）
• design・refactoring・release の Skill の文書を、エンジニアになじむ用語で記述（#1168）
• external-ai・issue-upkeep・markdown-writing・requirements-design・worktree の各 Skill の文書は、エンジニアになじみのある用語で書かれています（#1169）
• requirements-design の Skill では、仕様を写したものを「仕様のコピー」と呼びます（#1169）
• Skill・エージェント・README の説明は、エンジニアになじみのある語で書かれています。（#1170）
• 仕様・README・AGENTS.md などの文書は、エンジニアになじむ用語（承認ゲート・カットポイント・ラウンドテスト・ラッパーなど）で書かれている（#1171）
• 仕様の文では、直訳の語（器・束・入れ物・段）を使わない（#1171）
• development-workflow の文書は、業界で通じる語で書かれている。例はセッション・シグナルファイル・アイドル・プラン・キュー・進捗ログ。（#1172）
• 用語集の「廃止した語」で、使わなくなった語に対応する今の語を引ける。（#1172）
• 工程表の行名は stage の値として読める。（#1172）
• 無し（検査の修正だけ）（#1173）
• release・refactoring・design の Skill の説明と参照文書は、ユビキタス言語の用語で書かれている（#1175）
• worktree の Skill の文書では、「設定」「worktree レジストリ」「開発 worktree」など用語集の語を使う（#1176）
• issue-upkeep の Skill の文書では、「再検討条件」「修正方針」「課題グループ」など用語集の語を使う（#1176）
• external-ai・document-systems・document-drafting・requirements-design の Skill の文書では、用語集の語を使う（#1176）
• cross-review と cross-refactoring の文書・プロンプトの語が、用語集のユビキタス言語に揃っている（#1177）
• Skill と README の文書は用語集の語で書かれている。（#1178）
• 用語集には、Skill と README で使う語が載っている。（#1178）
• development-workflow の SKILL と references は、用語集に載った語で書かれている（#1179）
• 用語集に判断表の語とコンテキストが載っている（#1179）
• 仕様の文書・CLAUDE.md・AGENTS.md・README で、同じものを同じ語で呼ぶ（例: リリース済み版・@インポート・worktree レジストリ・進捗記録・ミッション課題）（#1180）
• 仕様に出てくる語は用語集で意味を引ける（#1180）
• Fix: doc-lint が用語集の生成物を調べ、直しのステップが生成物を手で直す（#1181）
• 無し（検査の修正だけ）（#1182）
• 用語集の語ごとに、コードで使う識別子を code で持たせられる（#1185）
• 廃止した識別子は deprecated_code に書き、言い換え先の識別子と並べて示せる（#1185）
• NDF の用語集の語に識別子が入り、語からコード上の名前を引ける（#1185）
• 無し（検査の修正だけ）（#1186）
• 駆動が pause したとき、直しの worker は pause に載った作業ディレクトリで動く（#1189）
• 即時修正するかどうかは pace に関わらず、行数ではなく 4 条件（原因・契約・方針・revert）で決まる（#1189）
• worker は手段を自分で選べる。置き場所は変えない（#1189）
• 無し（検査の修正だけ）（#1190）
• プランの起動にも文脈量のガードが掛かります（#1195）
• Agent で supervisor を起動すると、ガードがプランを使うよう案内します（#1195）
• フェーズをプランで流すか supervisor で回すかを、agent-layers.md の表で引ける（#1196）
• 判定結果の手順 3 に次に打つコマンドが載り、そのまま実行できる（#1196）
• normal のミッションを流すコマンドは waiting.md に 1 か所で載っている（#1196）
• 中断と再開の手順は interrupt-resume.md にまとまっている（#1196）
• new mission は、プラグインでないリポジトリ（リリースの雛形が無いリポジトリ）でも使える（#1197）
• new mission は、用語集の無いリポジトリでも使える（#1197）
• new mission の help が、種別ごとに説明を示す（#1197）
• 無し（検査の修正だけ）（#1198）

ndf v10.17.26

• Fix: 中身の変わらない版を入れると複製の版の記録が古いまま残る（#1149）
• Docs: 複数 PR のマージ順の提示物に、strict の保護での取り込みの段を足す（#1150）
• mcp-serena の hook は grep や読み込みが続いてもツールの実行を拒否せず、案内だけを出します。拒否で 1 手番を失うことはありません（#1151）
• 設計: #821（#1152）
• Fix: 設計の計画で cross-review の直しに追いつかずに push が拒まれる（#1153）
• Fix: 設計の計画が決定の節を同期せず、利用者の承認で再開すると approve が止まる（#1154）
• Slack 通知は、回答待ち・承認待ちになったときだけ届く（#1155）
• Claude Code と Codex の hook は、どちらも待ちの通知を送る入口を使う（#1155）
• Kiro の導入スクリプトと導入時の確かめは、待ちの通知を前提にしている（#1155）
• plugins/ndf/README.md と Kiro の文書は、待ちの通知の使い方を説明している（#1155）
• 無し（検査の修正だけ）（#1156）
• Fix: 用語集の語の正本を確定仕様に限り、確定前は pending_source に置く（#1157）
• Fix: sleep の hook の案内を NDF の待ちとマージのスクリプトへ向ける（#1158）
• 用語集の仕組みの確定仕様を docs/specifications/ndf-ubiquitous-language.md で読める（#1159）
• 無し（検査の修正だけ）（#1160）

ndf v10.17.25

• cross-refactoring の検証は、テストのコメントの中の値の減少を期待値の変更として扱わず、改善項目を取り消さない（#1130）
• テストを整理する改善項目で値の出現数が減っても、期待値の変更として扱わず、改善項目を取り消さない（#1130）
• 機械で判定できない変化は、最終ゲートのレビューで確認する（#1130）
• 利用者の環境は変わらない。devbase のコンテナで NDF のテストを走らせても、中継の読み込みファイル（~/.shellrc.d/ndf-relay.sh）が消えなくなる。（#1131）
• 設計の工程を持つモードでは、プロジェクトの用語集の宣言 .ndf/glossary.json が無いと設計へ進まず、用語集を作る手順を示す（#1135）
• glossary.py で用語集の生成・語のチェック・差分の確認ができる（#1135）
• 要求の仕様は課題の本文を正とし、spec-copy.py が写しと本文の食い違いを返す（#1135）
• 設計 PR のレビューはモデルの段、詳細の段の順に 2 段で進む（#1135）
• pace: fast で進めると、開発版を出す前に毎回、前回のレビューからの差分へ cross-review が 1 回通る。構造改善（cross-refactoring）は今までどおりトリガーが立ったときだけ流れ、レビューを通しても構造改善のトリガーは数え直しにならない。（#1137）
• 無し（検査の修正だけ）（#1138）
• pace: fast の実装レビューと検査は、前回の検査で見終えた位置から数える。レビューを通らずに配布された変更も、次のレビューで必ず見る。初めて使うリポジトリでは new check --since-last --since-ref <ref> で起点を渡せる。（#1139）
• pace: fast の検査と実装レビューの途中に別の Pull Request がマージされても、検査の Pull Request が衝突で閉じられなくなる。（#1143）
• 無し（テストだけ）。（#1144）

ndf v10.17.24

• Skill と文書の用語が、用語集に載る 1 語 1 意味の語に揃いました。主な語は、ラッパー、ボード、静止、チェイン、カットポイント、スイッチポイント、範囲テスト、ステップ、ステージ、チェックです。（#1123）
• 計画の単位はステップ、--then の段と波はステージと呼びます。（#1123）
• 目的の違う語は、それぞれ別の語で書き分けます。（#1123）
• 印: 合図・承認ラベル・危険フラグ・目印（#1123）
• 写し: 複製・抜粋（#1123）
• 判定: issue-upkeep の区分・MVV 判定（#1123）
• 用語集には、今使う語とその意味を載せています。（#1123）
• 無し（検査の修正だけ）（#1124）
• mission-state.py update が、init で渡さなかった計画も done から表へ載せる（#1121）
• 配布の説明（CHANGELOG・README の更新案内・本番承認の提示物の「配る中身」）に、マージされていない PR が載らなくなる（#1121）
• マージ後の後片付けが、主ディレクトリに残った設計の写し（取り込む内容と同じもの）で止まらなくなる（#1125）
• 検査の計画が、PR のマージの後に落ちず、検査の記録を残してチェインの後ろ（開発版・本番）へ進む（#1126）

ndf v10.17.23

• supervise.py は、段ごとの想定時間より遅れた段を見つけます。その段を一次の調査にかけ、介入します。（#1115）
• 遅れの見張りの挙動は設定で変えられます。（#1115）
• merged-steps.py probe で、PR の検査が進まない理由を調べられます。理由は「取り残し」「ランナー待ち」「失敗」の 3 つに分けて示します。（#1115）
• 設計: #1102（#1109）
• runtime-smoke が落ちたとき、継続的統合のログで失敗の理由を読める（成果物の generated-tree.txt も失敗時に残る）（#1106）
• Python 3.14 で NDF のスクリプトを動かしても SyntaxWarning が出ない（#1106）
• issue-upkeep の候補に、前の配布からのコミットの件名が指す課題が commit-subject の経路で上がる。閉じ忘れを拾える（#1108）
• 開発ワークフローの語の意味と正本を 1 か所で引ける（plugins/ndf/skills/development-workflow/references/glossary.md。SKILL.md と docs/ndf-plugin-reference.md から案内する）（#1110）
• 作業ツリーの中から merged-steps.py cleanup / merge-when-green を打っても、その作業ツリーを消した後に止まらない（設計と実装の計画の merge のステップが完了で終わる）（#1112）
• issue-body.py set が、GitHub から読めない参照を持つ本文を書き込む前に止める（試行。既定の振る舞いは変わらない）（#1116）

ndf v10.17.22

• cross-review と cross-refactoring の判定は、同じ名前の検査ジョブを最新の実行の結論で見る。後で成功した検査より前の失敗では、修正のラウンドを回さない（#1098）
• レビュー本文の指摘を見送った場合も、スレッドの決着と修正のまとめが投稿される（#1098）
• pace: fast を選ぶと、MVV の判定が従うときに関門 1・2 を止まらずに通り、構造改善と実装レビューは check-trigger.py のトリガーが立ったときだけ次の開発版の前に 1 回通る。確定仕様化・受け入れ条件の確認・振り返りはミッションの終わりに new close の計画で流れる（#1099）
• 配布の PR の CI の待ちに上限（3600 秒）が付く（#1101）
• 実行が終わってジョブに結論があれば、チェックの表示が pending のままでも待たずにその結論で扱う。success なら通し、failure なら失敗で止める。結論の無い取り残しだけを 1 度再実行する（#1101）
• 配布のブランチ（release/**）への push では、Runtime plugin validation と Runtime plugin smoke が走らない。PR 側の実行が同じコミットを見る（#1101）

ndf v10.17.21

• cross-review を修正待ちから再開しても、PR の head より先にある未 push のコミットは残る（#1093）
• issue-upkeep の candidates --limit は、指定した件数を超える候補を items に載せない（#1093）
• mission-state.py init は、既存の mission.json が別の形のときは上書きせずに止まる（#1093）
• supervise.py の計画は、テスト・同期・起点・配布を .ndf/ の宣言か引数から読むため、他のプロジェクトでもそのまま使える（#1094）
• doc-lint.py の起点の既定は .ndf/worktree.json の base_branch から読む（#1094）

ndf v10.17.20

• 試行のため既定の振る舞いは変わらない。呼んだときだけ働く。（#1080）
• 課題を複数まとめた実装の計画で、担当がすべての課題を読むようになる。（#1084）
• 継続的統合が無関係な揺れで落ちにくくなり、再実行の待ちが減る（#1085）
• PR の情報や本文の節の差し替えを Skill が 1 行の部品で呼べるので、LLM が gh の手順を組み立てずに済む（#1086）
• 課題の棚卸では、候補の収集と反映（照合と待ち行列を含む）をスクリプトが行い、LLM は判定だけを受け持つ（#1087）

ndf v10.17.19

• skill-stats --agents と token-usage.py の層ごとの集計で、conductor の件数と固定費が実際より多く出なくなる。（#1073）
• 収束ループ（cross-review / cross-refactoring）を回す supervisor は、1 時間のキャッシュの定義で起動します。（#1074）
• supervisor は文脈が膨らむと、長い待ちの前にフェーズの中で区切ります。待ちの後に文脈の全体を書き直す費用がかかりません。（#1074）
• token-usage.py で、待ちの後の書き直しと読み込みの量を、定義の名前ごとに集計できます。（#1074）
• supervise.py new mission で作ったミッションの検査と配布が、LLM に Skill を丸ごと回させずにスクリプトで進む。（#1076）

ndf v10.17.18

• 新しい文脈（CLI・サブエージェント・会話）で始めるか続けるかを、費用の式で判断できる（#1064）
• conductor は区間の切れ目で、引継ぎ文書の表と次のコマンドを手で書き直さずに、mission-state.py の update → render → next で生成できる（#1065）
• bg-wait.sh が plugins/ndf/scripts/lib/ に置かれ、cross-review 以外の Skill からも使える（#1066）
• cross-review と cross-refactoring の収束ループの待ちは、共通層の bg-wait.sh を使う（#1066）
• 配布の計画の CHANGELOG と説明で、PR が番号の順に並ぶ。（#1067）
• 止まった計画を --from で途中の段から再開できるようになる。（#1069）