安定インターフェース（CLI / GitHub Actions）

River Review は OSS として成長中であり、内部実装は変更される可能性があります。一方で、利用者が安心して導入できるように 安定した契約（stable contract） を定義します。

破壊的変更（breaking change）は原則として major version bump が必要です。ただし何を破壊的変更と見なすかは、後述のコンポーネント安定性ラベルと Stable Contract の列挙で決まります。Beta / Internal のサーフェスなら、Stable Contract に載っていない要素の変更は minor 以下で入ります。

安定した契約（Stable Contract）

次の要素は「外部に公開されたインターフェース」として扱います。

• スキル定義（schemas/skill.schema.json）と、その意味論（severity/confidence など）
• --output json が出す成果物（schemas/output.schema.json）の最上位構造（issues[] / summary / decision）と各フィールドの意味
• GitHub Actions（runners/github-action/action.yml）のinputs / outputsと動作
• GitHub Action の step / job の終了コードと、gate 判定用の終了コード 0 / 1 / 2 / 3 の意味。gate: true の run では、step の終了コードがそのまま job の成否になる（runners/github-action/action.yml の gate input）。GO / GO_WITH_OBSERVATION は 0、NO_GO は 1、ESCALATE は 3 である。Action から到達するのは 0 / 1 / 3 であり、2 は CLI の --warn-on（Internal）経由でのみ到達する。4 値すべての意味が Stable である点は変わらない
• PR コメントの idempotent 更新方式（marker）

終了コードは用途で粒度を分けています。CI がゲート結果として読む上記の値だけを Stable Contract に含めます。利用者はこの終了コードへ GitHub Action 経由で到達し、step の終了コードがジョブの成否になります。usage error（引数の解釈失敗）の終了コードは含めず、CLI サーフェス全体のラベルである Internal に従います。後述の「終了コードの安定性」の表は、同じ終了コードを CLI リファレンスの文脈で宣言したものです。Stable Contract が保証するのは、そこへ GitHub Action 経由で到達する面になります。裁定の根拠も同じ節にあります。

コンポーネント安定性ラベル

各サーフェスの現在の安定性レベルを示します。

ラベル	定義
Stable	破壊的変更にはメジャーバンプが必要。本番利用推奨
Beta	マイナーバージョンで API が変わる可能性がある。非推奨化は事前通知
Experimental	予告なく変更・削除される可能性がある。評価目的での利用を推奨
Internal	リポジトリを clone した開発者向け。配布経路を持たず外部利用は想定しない

サーフェス	ラベル	備考
GitHub Action	Beta	v0.x のため breaking changes の可能性あり
CLI (river コマンド)	Internal	npm 未公開（package.json が private: true）で配布経路を持たない。リポジトリを clone した開発者向けのサーフェスにあたる。利用者向けの入口は GitHub Action と Claude Code / Codex プラグインである
Skill Schema (schemas/skill.schema.json)	Beta	CI バリデーション済み、フィールド拡張の可能性あり
Flow Schema (schemas/flow.schema.json)	Experimental	#2013 で追加した contract。実行エンジンは未実装。schemas/flow-entry-map.schema.json と flows/entry-map.json も同じ Experimental 扱い
Agent Contract (schemas/agent-contract.schema.json)	Experimental	#2014 で追加した contract。実行エンジンは未実装
Execution Manifest (schemas/execution-manifest.schema.json)	Experimental	#2015 で追加した contract。Review Artifact への連結は additive・optional。#2054 PR-4 以降、river run --save の .river/runs/*.json と river review plan / review exec（replay を含む）の artifact に executionManifest が末尾キーとして載る
Review Resolution (schemas/review-resolution.schema.json)	Experimental	#2322 / #2505 の finding 対応 sidecar contract。Review Artifact を immutable のまま維持し、source finding / review run / Execution Manifest由来の artifact hash、Author/Human response、target revision、verification state を別成果物として保持する。Disposition != Resolution を維持し、Gate / merge authority、finding discovery、canonical Feedback append は所有しない。verified_resolved は target revision + verifier + evidence を要求し、finding が次 run で消えただけの状態は not_reproduced として区別する
Review Coverage (schemas/review-coverage.schema.json / JSON・saved run reviewCoverage)	Experimental	#2212 の Experimental な実行coverage contract。既定では Gate / decision に影響しない。ただし river runs diff の loop signal は既定でも coverage を見るので、LLM 呼び出しに失敗した run は CONVERGED ではなく NO_SIGNAL になる。#2441 以降、全 unit が LLM を skip して coverage を出さない run も、saved run の llmNotExecuted: true により NO_SIGNAL になる。#2410 以降、--reviewers orchestration に加え、単一 reviewer でも LLM call を実際に試行した場合は reviewCoverage を生成する。有効な応答（NO_ISSUES 含む）は complete、transport / response / parse failure は required unit failed → not_executed、dry-run / offline / API key 未設定は観測なしとして field を省略する。#2423 以降、--reviewers でも LLM 呼び出しに失敗した role × chunk は completed ではなく failed（reviewer_error）として記録する。#2436 以降、--reviewers でも全 role × chunk が dry-run / offline / API key 未設定 / 未対応 provider で LLM を skip した run は、単一 reviewer と同じく field を省略する。skip と実行が混在した run では、skip した unit を failed（reviewer_error）として数える。RIVER_GATE_COVERAGE=1 + --gate の opt-in 時だけ partial / not_executed を NO_GO（COVERAGE_INCOMPLETE）へ倒す。review exec は engine が reviewCoverage を返すまで no-op。JSON / saved-run field と fileScope は additive・optional
Security Audit Coverage (schemas/security-audit-coverage.schema.json)	Experimental	#2267 Phase 3 の observe-only semantic coverage contract。ReviewCoverage・finding lifecycle・Gate とは分離し、自動 runtime emission と Gate integration はまだ行わない。Phase 9 で追加した sourceRevision / carriedOverFrom も optional
Security Audit Run Record (schemas/security-audit-run-record.schema.json)	Experimental	#2267 Phase 9 の structured audit artifact contract。.river/security-audit/ の machine-readable SSoT で、prose report は投影にすぎない。書き出す caller はまだ無く（runtime emission なし / writer 未配線）、Gate integration も行わない
Fast Verification Evidence (schemas/fast-verification-evidence.schema.json)	Experimental	#2275 PR-3B（Epic #2054 Phase 3）の after-change checkpoint evidence contract。observe 固定で Gate / decision / merge 権限を持たず、pass は決定論チェックが実際に走って成功した場合だけを指す。host adapter は PR #2328 で追加済み（.claude/hooks/after-change-observe.sh / .claude/hooks/after-change-observe.mjs / src/lib/after-change-adapter.mjs）。ただし .claude/settings.json へ hook 登録しておらず、opt-in の RIVER_AFTER_CHANGE_OBSERVE=1 も既定 off。よって既定では runtime emission が起きない。Gate integration も行わない
Suppression Context (schemas/suppression-context.schema.json)	Experimental	Riverbed Memory の type: suppression エントリの context 形式（#687 / Epic #650）。利用者が river suppression add で .river/memory に書く。親エントリの形式は schemas/riverbed-entry.schema.json が規定する。#2202 Phase 0 で追加した skillId / skillVersion / rulesDigest は optional の項目で、期限（expiresAt）による失効判定では読まない。rulesDigest は、設定 memory.suppressionRequireRulesMatch: true で opt-in したときだけ読む。現在のプロジェクトルールと一致しない suppression は効かなくなる（既定 off。#2202 Phase 2）。rulesDigestAlgo（v1 / v2、欠損は v1）は digest の版を示す。river suppression add はプロジェクトルールがあれば rulesDigest と rulesDigestAlgo: v2 を書く。--skill <id> を指定すると skillId も書き、その ID の skill が見つかれば skillVersion も書く
Riverbed Memory Entry (schemas/riverbed-entry.schema.json)	Experimental	.river/memory/index.json に追記される 1 エントリの形式（#474）。src/lib/riverbed-memory.mjs と src/lib/promotion-candidates.mjs が書き出す。上の Riverbed Memory 行のファイル単位の内訳
Riverbed Memory Index (schemas/riverbed-index.schema.json)	Experimental	src/lib/riverbed-memory.mjs が書き出す .river/memory/index.json 全体の形式。v1 はエントリを別ファイル参照ではなく inline で保持する（version は const "1"）
Risk Map (schemas/risk-map.schema.json)	Experimental	利用者が自分のリポジトリに置く .river/risk-map.yaml の形式。src/lib/risk-map.mjs が読み、書き方は リポジトリ全体レビュー が解説する。runtime の検証は zod（src/config/risk-map-schema.mjs）が行い、この JSON Schema は公開ドキュメント側の形式定義である
Review Intent (schemas/review-intent.schema.json)	Experimental	#2016（Epic #2011）で追加した contract。レビューを走らせる目的・判断対象・必要な evidence を宣言する。src/lib/flow-loader.mjs の Flow スキーマ 3 本組の 1 つで、flow / flow-entry-map と同じく runners/github-action/dist/schemas/ に同梱される。実行エンジンは未実装
Evaluation Rubric (schemas/eval-rubric.schema.json)	Experimental	docs/eval/rubric.yaml の形式（severity / phase / dimensions の 3 セクション。いずれも optional）。フィールド定義は 評価ルーブリック が公開している
Evaluation Ledger Entry (schemas/eval-ledger-entry.schema.json)	Experimental	評価結果台帳（scripts/compare-eval-ledger.mjs が既定で読む artifacts/evals/results.jsonl）の 1 エントリの形式。dimensionScores[].dimensionId が eval-rubric.schema.json の id に対応する。schemas/eval-failure.schema.json は本スキーマから $ref される下位フラグメントであり、独立した行は持たない
Agent Adapter Map (schemas/agent-adapter-map.schema.json)	Experimental	#2014（Epic #2011）で Agent Contract と対にして追加した binding 専用 contract。判断フィールドを持てない閉じた形式で、Claude / Codex の runtime binding だけを記述する。書き出す caller は無く、消費者は tests と設計ドキュメントのみ
Completion Assessment (schemas/completion-assessment.schema.json)	Experimental	#2019（Epic #2011 Phase 8）の「DONE の根拠」を記録する contract。mode は observe 固定で、Gate / decision / merge 権限を持たない。書き出す caller は無く、消費者は tests と設計ドキュメントのみ
Cross-Artifact Consistency (schemas/cross-artifact-consistency.schema.json)	Experimental	#2018（Epic #2011 Phase 7）の cross-artifact-review / detect-semantic-drift step の出力 contract。1 回のレビュー実行についてのレポートであり、グラフは永続化しない。書き出す caller は無く、消費者は tests と設計ドキュメントのみ
Cross-Runtime Conformance (schemas/cross-runtime-conformance.schema.json)	Experimental	#2020（Epic #2011 Phase 9）の runtime 間比較ケースの contract。read-only な観測記録で、promotion の判断は持たない。書き出す caller は無く、消費者は tests と設計ドキュメントのみ
Paired Replay (schemas/paired-replay.schema.json)	Experimental	#1574 P2 の read-only paired replay artifact。river evolve replay が出力する。acceptance.decision は常に null、writeEffects は常に空で、採否を決めない。#2409 で追加した promotionHandoff は optional であり、schemaVersion 1 の既存 artifact もそのまま valid
Replay Verification (schemas/replay-verification.schema.json)	Experimental	#1574 P3 foundation の read-only artifact。river evolve verify-replay が出力し、candidate 外から渡された trusted Ed25519 公開鍵で detached attestation を検証して、paired replay / Experiment Manifest / candidate へ厳密に binding する。decision は常に null、autoCanary / autoPromotion は常に false、writeEffects は常に空であり、暗号検証成功は Human review の証拠であって canary / adoption の許可ではない
Review Viewpoints (schemas/review-viewpoints.schema.json)	Experimental	#2252 Foundation Slice で追加した data-only contract。schema の description が宣言するとおり、routing / evaluator 選択 / policy / gate action / 実行可能な振る舞いを定義しない。production モジュール（src/lib/review-viewpoints.mjs / src/lib/review-viewpoint-stage.mjs）が配線済みである一方、reviewConfig.viewpoints.mode の既定値は off であり、既定では起動しない。有効化しても対象を組み込み skill に限り、選択された Skill と最終的な references/viewpoints.yaml の両方が配布 skills/ root 配下へ canonicalize されることを検査する（realpath による再検査で symlink 経由の脱出も塞ぐ）。利用者リポジトリ固有の Skill は v1 で明示的に拒否する
Node API (runners/node-api/)	Experimental	private: true、npm 未公開
Agent Skills bridge	Experimental	v0.9.0 で追加、成熟途上。この bridge の受け入れフロントは schemas/agent-skill-loose.schema.json であり、name / description のみ必須で未知フィールドを許容する（additionalProperties: true）。この schema は片務契約である。外部 Agent Skills の受け入れ範囲を緩める変更は非破壊にあたる。締める変更は破壊的となる
Riverbed Memory	Experimental	v1 は実装済み（#474）。ラベルは Experimental のままで、予告なく変更・削除される可能性がある。v2（外部データストア連携）は将来計画。詳細は Riverbed Memory を参照

Review Coverage execution provenance (#2481)

--reviewers orchestration は、各 reviewCoverage.units[] に optional な executionId を記録できます。 同じ reviewer task 由来の finding は、optional な sourceExecutionIds[] を保持できます。

これらは実行 provenance の観測だけです。 actor identity・署名・trust・独立検証の証明ではありません。 Gate / decision / severity / consensus の入力にもなりません。

Finding Criticのexecution-independence観測（#2543 / PR #2571）

Finding Critic を明示的に有効にすると、既存の evaluateReviewerIndependence() により実行IDの分離を観測できます。比較対象は finding の sourceExecutionIds[] と、呼び出し側が事前に割り当てた Critic の verifier execution ID です。観測結果は debug.findingCritic.executionIndependence[] に保持されます。

Critic は既定で off です。経路や実行可否によって、この観測は存在しません。Finding / Review Artifact の必須フィールドは増えません。

independent が意味するのは logical execution IDが異なることだけです。別actor、署名、trust、別モデル、prompt/context分離、検証品質、findingの正しさは証明しません。ID欠落やCritic未実行をPASSへ変換せず、この観測をFinding Criticのvalidation、severity、Gate、decision、Human approvalへ逆流させません。Reviewer Identityとより強い署名/信頼の境界は #1760 で引き続き検討します。

CLI（river）リファレンス（最小）

コマンド

• river run <path>: ローカルでレビューを実行する
• river doctor <path>: 設定/前提を診断し、ヒントを出す
• river skills <path>: skill ベースのレビューを実行する（サブコマンド river skills import / river skills export / river skills list で Agent Skills と相互変換）
• river review plan: 上流アーティファクトを解決して Review Artifact を出力する（仕様）
• river runs list: 保存済みレビュー実行（.river/runs/）の一覧を表示する
• river runs diff <id1> <id2> [<id3>...]: 保存済みレビュー実行の差分を表示する（3 件以上指定すると振動検知も行う）
• river runs summary: 保存済みレビュー実行の集計を表示する
• river suppression add: Riverbed Memory の suppression エントリを作成する
• river eval: レビュー fixtures の評価を実行する

主なオプション

• --phase <upstream|midstream|downstream>: レビューフェーズ（デフォルト: midstream）
• --planner <off|order|prune>: Planner モード（デフォルト: off）
• --dry-run: 外部 API を呼ばずに実行する
• --offline（別名 --rules-only）: API キーが設定されていても AI を呼ばず、決定論的な機械的チェックのみでレビューする（CI 不可用時に Auto-approve 判定をローカル再現する用途）
• --debug: デバッグ情報を出す
• --explain: 採用された skill / gate / config tier を人間可読で出す（stderr）
• --estimate: コスト見積もりのみ（レビューは実行しない）
• --max-cost <usd>: 見積もりが上限を超える場合に中断する
• --output <text|markdown|json|yaml|html>: 出力形式（GitHub Actions は markdown を使用、yaml は YAML 出力 を参照、html は自己完結型 HTML レポートで HTML 出力 を参照）
• --context <list>: 利用可能なコンテキスト（例: diff,fullFile）
• --dependency <list>: 利用可能な依存（例: code_search,test_runner）
• --base <ref>: 差分の基準となるブランチ / ref。run / skills / review plan|exec|route が同じ解決経路を共有し、差分を読まない面はこの flag を受理しない。どの面が受理するか、値の検証、usage error の exit code はいずれも Stable Contract の対象外であり、SSoT は Runner CLI リファレンス
• --entry <name>（Internal）: review plan と review exec が受理し、出力 artifact にレビュー Flow の pin（flow）と必須入力（evidenceRequirements）を追加する。review exec では Flow を走らせた各 step の結果（steps、Epic #2011 AC7 P2 では記録のみ）も追加する。flag と 3 フィールドは Stable Contract の対象外で、SSoT は Runner CLI リファレンス
• --baseline <path>: 過去のレビュー JSON（findings 配列）と比較して回帰を表示する
• --save: レビュー実行をプロジェクトの result store（.river/runs/）に保存する
• --reviewers <roles|auto>: レビュアーロールをカンマ区切りで指定、または auto でシグナルに基づく自動選択（詳細: runner-cli-reference.md の --reviewers セクション）

終了コード

findings に基づく exit code は --fail-on / --warn-on を指定した場合のみ 0 以外になります。--fail-on を指定しない場合、findings があっても正常終了は 0 です。 なお usage error と実行エラーは、--fail-on の指定と無関係に 1 で終了します（#1709。下表の「入力不正」行に対応）。usage error には未知オプション・余剰 positional・オプション値の欠落や不正値が含まれます。

exit code	条件	説明
0	--fail-on 未指定 / --advisory-only / max severity < warn rank	pass（常に 0）
1	--fail-on <sev> 指定かつ max severity ≥ fail rank	fail（ブロック閾値以上）
2	--warn-on <sev> 指定かつ max severity ≥ warn rank かつ fail rank 未満	warn（warn 閾値以上、fail 未満）
1	入力不正 / git 差分取得失敗 / スキル検証失敗 / --max-cost 超過など	エラー終了

severity の rank（低→高）: info=0 / minor=1 / major=2 / critical=3

自己修正ループでの停止条件・発散ガード・振動検知を含む詳細な利用契約は ループ収束コントラクト を参照してください。

終了コードの安定性

終了コードは用途で 2 段階に分けて宣言します。

用途	ラベル	変更に必要な bump
gate 判定（--fail-on / --warn-on / --gate が返す 0 / 1 / 2 / 3）	Stable	major
usage error（引数の解釈失敗）	Internal	CLI サーフェス全体のラベルに従う（minor で可）

gate 判定用の終了コードは CI のジョブ成否へ直結します。閾値の意味が黙って変わると、利用者は失敗を検知できません。そのため Stable Contract に含めます。変更には major version bump が必要です。なお --gate の 3 は ESCALATE（人間の承認が必要）を表します。river review 系では、ハンドラ層の設定エラーにも 3 を割り当てています（river review plan 仕様）。#2436 以降、--reviewers で全 role の LLM 呼び出しが失敗した run は、decision が human-review-required、gate が ESCALATE になり、--gate 指定時は exit 3 で終わります。reviewCoverage.status は not_executed です。内部の判定では「reviewer が 1 つも成功しなかった run」として扱います。この判定根拠の reviewerResults は出力には含まれません。一部の role だけが失敗した run の gate は変わりません。LLM を skip した role は失敗した role として数えません。#2441 以降、RIVER_GATE_REQUIRE_LLM=1 を設定した river run --gate では、全 unit が LLM を skip した run が ESCALATE（LLM_NOT_EXECUTED）になり exit 3 で終わります。単一 reviewer と --reviewers の両経路が対象です。未設定（既定）の gate・decision・終了コードは変わりません。dry-run は従来どおり NO_GO（NOT_EXECUTED）です。この事実は saved run に llmNotExecuted: true（additive・optional、真のときだけ出力）として残ります。river runs diff の suggestedLoopSignal は、変数の設定と無関係にこの値を読みます。最新 run が llmNotExecuted: true なら CONVERGED を NO_SIGNAL に降格します。river runs diff の終了コードは変わりません。

usage error の終了コードはレビュー結果を含みません。表すのは「引数が受理されなかった」ことだけです。誤用の検出漏れを塞ぐたびに検出層と粒度が動きます。そのため CLI サーフェス全体の Internal ラベルへ従わせます。実例として #1709 では、引数エラーを exit 0 から exit 1 へ横断統一しました。粒度はさらに、parse 層の 1 とハンドラ層の設定エラーの 3 へ整理されています。この一連の変更は v1.71.0（#1735）と v1.72.0（#1746）という minor リリースで入りました。

GitHub Actions（river-review）リファレンス（最小）

inputs（安定）

定義は runners/github-action/action.yml を参照してください。

• phase: upstream|midstream|downstream
• planner: off|order|prune
• target: レビュー対象のリポジトリパス
• comment: PR コメントを投稿するか（pull_request のみ）
• dry_run: 外部 API を呼ばずに実行するか
• debug: デバッグ情報を出すか
• estimate: コスト見積もりのみ実行するか
• max_cost: 見積もりが上限を超える場合に中断する
• node_version: Action 実行に用いる Node.js バージョン

inputs（Beta）

• entry: レビュー Flow の entry 名（flows/entry-map.json の entries キー）。指定時だけ review plan --plan-only --entry <値> を実行し、Review Artifact（flow と evidenceRequirements 付き）を出力する。未指定（既定）なら従来の run 経路のまま。値は書き換えず渡すだけで、Action 側に判断を置かない（ADR-009 D3）。entry 指定時は gate / dry_run / estimate / max_cost / comment / inline_comments を適用しない（plan-only はレビューを実行しないため、gate 対象と投稿対象のどちらも無い）。#2054 PR-5。SSoT は Runner CLI リファレンス

outputs（安定）

• comment_path: Actions runner の一時領域に出力した Markdown のパス（PR コメント投稿で使用）

PR コメントの契約（idempotent）

• 契約上の marker は <!-- river-review --> の 1 種のみである。Action が投稿するコメント本文は必ずこの marker で始まる（#2323）。
• <!-- river-review --> marker で 始まる コメントを更新し、なければ新規作成する（#2330）。本文の途中に marker を引用しただけのコメントは更新対象にならない。
• 既存コメントの探索に限り、先頭が旧 marker <!-- river-reviewer --> のコメントも受理する。v1.118.1 以前の Action が投稿したコメントを重複させず更新し続けるための移行措置であり、書き込み側が旧 marker を出すことはない。旧 marker は契約ではないため、consumer は <!-- river-review --> だけを見ること。
• コメント本文が長すぎる場合は末尾を切り詰める（上限あり）。

Claude Code プラグインの hook（Beta）

hooks/hooks.json は 2 つの lifecycle hook を配布します。PostToolUse（Write / Edit 後に consumer 側の prettier を実行）と、#2054 PR-5 で加わった Stop です。Stop は scripts/plugin-task-checkpoint-hook.sh を呼び、river review plan --plan-only --entry review-task で Review Artifact を出力します。中立 trigger task-checkpoint の Claude Code adapter で、entry 名以外の判断を持ちません（ADR-009 D3）。

• LLM 呼び出しと課金はない（plan-only）
• 所要は 1〜7 秒（river-review 本体 repo で 3 回実測 5.0〜5.4 秒、別環境で 6.7 秒。大規模 repo では timeout: 60 を超えて打ち切られうる）
• 成果物は $TMPDIR/river-review-task-checkpoint/ に書き、作業ツリーには書かない。過去分を 20 件（RIVER_TASK_CHECKPOINT_KEEP）まで残して古いものを消す（保持は書き込み前に行うため、実行後は最大 21 件）
• CLI が無い（npm 未導入かつ plugin に node_modules が無い）場合と失敗時は exit 0 で skip し、セッションを止めない。hook は CLAUDE_PLUGIN_ROOT/node_modules を要求するため、npm パッケージを導入するか plugin ディレクトリで npm ci を実行する
• 止め方: 環境変数 RIVER_TASK_CHECKPOINT_HOOK=0、または /plugin disable river-review@river-review-marketplace

バージョニング（破壊的変更の扱い）

次を変更する場合は、破壊的変更として major version bump を必要とします。

• gate 判定用の終了コード 0 / 1 / 2 / 3 の意味変更（GitHub Action では step / job の終了コードとして到達する）
• Action inputs / outputs の変更・削除
• スキルスキーマの必須フィールド変更、既存フィールドの意味変更

次は破壊的変更として扱いません。minor もしくは patch のリリースで入ります。

• usage error（引数の解釈失敗）の終了コードの変更（CLI サーフェス全体の Internal ラベルに従う）
• 値を消費しない面からのオプション受理範囲の縮小（#2065）。受理をやめた面では、その flag を付けた呼び出し自体が usage error となり exit 1 で落ちる。ただし値は一度も読まれていなかったため、呼び出しから flag を外せば従来と同じ結果が得られる。移行が呼び出し側の 1 行修正で済むことを根拠に、こちらは破壊的変更として扱わない。影響を受ける面の一覧と移行手順は Runner / CLI リファレンス にある。後置サブコマンド語の解決（#2081）は例外である。river skills --base main import は flag を外しても import/ のレビューには戻らず、--base を伴わない river skills --output json import も同じくサブコマンドとして動く。サブコマンド語と同名のディレクトリは river skills ./import と書く

Action は安定動作のため、@main ではなく リリースタグへピン留めすることを推奨します（例: @v1.22.0）。

スキーマのバージョニングポリシー

schemas/ 配下の JSON Schema は version フィールド（例: review-artifact.schema.json の "version": { "const": "1" }）でバージョンを表します。

• 後方互換な追加（任意フィールドの追加、enum 値の追加など）は同一スキーマファイル内で行う。
• 破壊的変更（必須フィールド追加、既存フィールドの型/意味変更、enum 値の削除など）は次のいずれかの方針で行う。
  1. 新しいスキーマファイルとして作成する（例: review-artifact.v2.schema.json）。version: const "2" を割り当て、旧スキーマは最低 1 メジャーバージョン以上残置する。
  2. 既存スキーマで oneOf を用いて新旧バージョンを共存させる。version フィールドの値で分岐させ、消費者が単一の $ref で複数バージョンを処理できるようにする。

新しいスキーマを schemas/ に追加した場合は、上の「コンポーネント安定性ラベル」表に行を追加してください。行を追加する契機は publish した時点 であり、production caller が付いた時点ではありません。実行エンジンや writer が未配線でも、その旨を備考に書いたうえで Experimental として登録します。先例は schemas/flow.schema.json と schemas/security-audit-run-record.schema.json です。あわせて pages/reference/_meta.json などの関連ドキュメントも更新し、ja / en 両方の表に同じ行を追加してください。