scholia-changelisted

# scholia-change — 変更を評価して取り込む（Case 1: Tag / Case 2: Transition / Case 3: 設計・横断 decision） ## これは何のためか **対応方針の判定は [scholia-triage スキル](../scholia-triage/SKILL.md) が担う**——input（修正指示・要望・レビュー コメント）を既存 spec に照らして **A是正／B精緻化／C矛盾／D新規／E却下** に分類し、方針＋WHY＋（B/D なら） decision 下書きを出す判断層。本スキルはその先、**方針が出た後に変更を scholia レコードへ着地させる実行手順そのもの** を担当する（役割分担: 判断＝scholia-triage、実行＝本スキル。判定基準・分類ロジックは本スキルで繰り返さず triage を 参照するだけに留め、二重記述を避ける）。 **2 つのフローが使える**（landed した評価コックピット・DESIGN §7）: - **CLI フロー**: 端末でコメントを集め、**コピーして本スキルを AI に貼り付ける**。以降は既存 CLI （`diff`/`rules`/`list`/`decide`/`decision add-commit`/`review`）とコメントの copy-paste で完結する。 - **viewer インライン評価フロー**: `scholia view` のコメントドロワーで、pending diff（作業ツリー vs `main`）を **差分カード付きの提案**として見ながら評価する。**提案＝変更を持つレコードのコメント・本文＝why**。 AI は変更本体と対で `scholia review add` で**提案コメントを配送**（`.scholia/reviews/`・read-only オーバーレイ）、 人は語彙ピッカーで手直し（vocab-only）し、ドロワーの **Adopt** で採用（`POST /api/decision`）＝why を decision へ昇格する。 どちらのフローでも**着地の正本は decision（append-only）**で、判定材料と結着ルールは同じ。以下の手順は CLI を軸に書くが、viewer を使う場合も同じ順序（提案 → コメント/手直し → 評価 → decide → commit → 結線）で進む。 **提案レビューは必ず `scholia view` で行い、AI（提案者）は対象を開いた状態の深リンク URL をレビュアに渡す。** チャットに decision/transition 本文を貼るだけの軽い確認や静的 `export --html` はレビュー提示としては 不十分——`export --html` は hash ベースの深リンク自体は file:// でも動くが（DESIGN §7.3）、file:// パスは 共有可能な URL にならず、Adopt/Reject の書込 API（`POST /api/decision` 等）は server-mode 限定で export では使えない（DESIGN §7.2）。対象タグ・関連 transition・decision 履歴の文脈込みで人が理解してから adopt/reject できることが目的。深リンクの route 一覧は [scholia スキル](..