shoji9x9 Parity Replace
replace-strategy の姉妹スキル。意図的に薄い層として、リプレイス固有の 3 つだけを担う。
- ページ単位への分割（機能 Issue の中でのフェーズ分け）
- 新側ロケータマッピングの充填（
parity-suiteが定義した論理名に対して。例外のみ） - 敵対的レビュー（実装役とレビュー役を分離し、未コミット差分に対して実施）
実装フローそのもの（ブランチ作成・調査・commit・push・PR）は issue-start に委譲する。 再実装しない。差分の検出は parity-diff、パリティスイートの構築は parity-suite の担当。
使い方
parity-replace [--feature <slug>] [--target <name>] [--max-iterations <n>]
- 1 回の実行につき 1 機能。 ページをまたいで並行に実装しない（調査・実装・比較が浅くなり差異を見落とす）
slugは.replace/features.mdが採番したもの。自分で採番しない。 省略時は features.md の未着手から対話選択する- モードは
.replace/parity/<slug>/metadata.jsonのmode（feature / api-resource / batch）を正として引く（フラグは無い。features.md の表位置から再導出しない）。modeはparity-suiteが features.md の分類（下表の起点）から記録済み --target <name>（任意）: 実装・検証を行う新側の実行対象環境。設定targetsのうちside: newのものだけを候補にする（本スキルが対象とする側の宣言はここが正本）。 省略時の既定・候補提示・存在しない名前や側違いでの停止といった選択規則はreplace-strategyのreferences/project-config.md「実行対象環境」の「選択規則」に従う（ここへ転記しない）--max-iterations <n>（任意, 既定 5）:parity-diffとの往復ループの反復上限。超えたら停止してユーザーに上げる
| モード | 起点 | 内容 |
|---|---|---|
| 機能（feature） | features.md の機能 | ページ単位にフェーズ分割。全工程（新側マッピング・視覚系）を使う |
| 横断 API（api-resource） | features.md の横断 API リソース | 画面を持たない API のみ。バックエンド diff レビュー ＋ API スイート green のみ（ページ分割・視覚・新側マッピング無し） |
| バッチ（batch） | features.md のバッチ | バッチ本体の diff レビュー ＋ 出力一致。画面系工程は動かさない |
- 自然文でも発動する:「新側を実装して」「リプレイスの実装を進めて」「この差分レポートから続きを直して」
前提
- ツール:
git。ブランチ作成・commit・push・PR はissue-startが行う（本スキルは実装フローを再実装しない） - 前提スキル:
issue-start（実装フローの委譲先）、replace-strategy（setup完了）、golden-dataset（フェーズ A 完了）、対象 slug のparity-suite（完了） - 前提スキルが未インストールの場合:
gh skill install shoji9x9/skills <name>で導入してから実行する。 本スキルは設定スキーマ・成果物様式の正本をreplace-strategy/parity-suiteのreferences//assets/に持つため、単体では成立しない（同時に導入されている前提） - MCP: 不要
- 新側アーキテクチャは事前定義: 骨格（フレームワーク・レイヤ／ディレクトリ構成・API 設計方針・ホスティング構成）の選定はスキル群の対象外で、
新側リポジトリは骨格がスキャフォールド済みである前提に立つ。本スキルは決定記録（
references.architecture）を読んで従うだけで、決めない （正本:replace-strategyのreferences/project-config.md「新側アーキテクチャ」） - 実行環境の能力: 敵対的レビュー（手順 7）は必須工程であり、実装役とは別のサブエージェント（Agent ツール等）をレビュー役として起動することを要求する。
起動できない・実行のたびにユーザー承認が要る実行環境では、着手前に可否を確認する（工程 7 で初めて判明する事態を避ける）。
起動できない場合の代替は、差分だけを人間のレビュアーへ渡してレビューを受け、記録を
review.mdに残すこと（レビュー役が人間であった旨を明記する）。代替が取れなくても省略はしない（手順:references/adversarial-review.md） - 前提の判定（無ければ停止し、該当スキルの実行を促す。捏造しない）:
replace-strategy setup完了 = 設定.config/skills/shoji9x9/skills.ymlのskills.replace-strategyと.replace/features.mdの存在golden-datasetフェーズ A 完了 =.replace/dataset/metadata.jsonの存在（versionは 1 始まりの整数）- 対象 slug の
parity-suite完了 =.replace/parity/<slug>/metadata.jsonの存在とsuite.current_green golden-datasetフェーズ B（新側スキーマ確定後の実行のみ。選択した target が投入対象の場合）=.replace/dataset/metadata.jsonのphase_b.<slug>.<target>.dataset_versionが存在し、その版より後のchanges[].affectsが slug の実効参照テーブルと交差しないこと。 影響変更があればgolden-dataset --phase b --feature <slug> --target <target>を先に回す。数値が古いだけなら再投入しない。 判定契約はgolden-datasetのreferences/versioning.mdを参照する。 投入対象は設定のdataset_modeで決まる——db（既定）ならdb.seedable: trueの target のみ、staticならすべての target（契約の正本はreplace-strategyのreferences/project-config.md）。 投入対象でない target はフェーズ B の対象外（投入しないため不要。データ整合の未検証はparity-diffが扱う）
- パスは推測せず
.replace/parity/<slug>/metadata.jsonから引く（スイート・現側マッピング・操作アダプタの実パス）。slugは.replace/features.mdから引き、自分で採番しない
厳守の制約（禁止事項）
仕様確認は十分な証拠が得られる最小コストの経路から始める。 選択した target から採取され、前提ゲートで対象版・採取時点・条件の一致を確認したパリティ成果物／観測記録 → 現行ソースコード → API の実動作 → UI の実動作の順に調べ、 下位の証拠だけでは実装判断を確定できない場合に限って次へ上げる。これは調査コストがパリティ成果物／観測記録 < ソースコード < API 操作 < UI 操作の順に高くなるためで、必要な証拠が得られた時点で止め、API／UI 操作は不足する場合だけ行う。 設計書・仕様書・受領ログを含む受領資料は調査候補の抽出に使ってよいが、現行挙動の確定根拠にはしない。UI 固有の表示・操作は UI で確定する
パリティスイートが無い状態で実装を始めない（判定基準が無ければ何をもって完了とするか決められない）
推測で実装しない。 判断できない箇所は
TODO等でコード上に未解決と明示しレビューへ回す。間違ったコードより未解決の明示のほうがよいDB の方言差を点検せずにクエリ・データアクセスを書かない。
references.db_semanticsの点検表（未整備ならスキーマ文書「DB 意味論」の点検項目そのもの）を書く前に読み、 該当・非該当と対応をporting.mdへ記録する。「型検査もテストも通った」を点検の代替にしない——絞り込みが全件に化ける類の差はデータ件数が少ないとスイートが green のまま残り、 実装後の敵対的レビューで拾うと手戻りが最も高くつく新側アーキテクチャ（骨格）を自分で決めない。 未整備なら実装工程に入らず停止し、事前定義を促す （既存実装から読み取った内容を下書きとして提示するのは可。確定は必ずユーザーが行う）
IaC（CDK / Terraform 等）は実装に付随する差分だけを触る。 テーブル追加・ルート追加など新側実装に必要な差分は書いてよいが、パイプライン・基盤の新規構築はしない （事前条件。区分の正本は
replace-strategyのreferences/scope.md「スキルが行う作業の範囲」）。付随の範囲を超えると判断したら停止してユーザーに上げる。 書いた付随差分は敵対的レビューとverification_commands.full（cdk synth/terraform validate等）を通す——パリティスイートは IaC を検証しないため、この 2 つだけが担保になる。verification_commandsは環境に依存しないコード検証に限る規約なので、認証情報・リモート state・実環境への問い合わせを要するコマンド（terraform plan等）はここに入れない既存パッケージを探さずに自前実装を始めない。探した結果として自前実装を選ぶのは可（理由を記録する）
配布元の素性・ライセンスを確認しないまま依存を追加しない（実装が進むほど差し替えコストが上がる）。判断材料・工程の正本は
replace-strategyのreferences/dependency-selection.md確信度の申告を迷ったときだけに限らない。 実装単位ごとに常に高／中／低を
porting.mdへ申告する（「低」＝「おそらく間違っている。レビューで現行を読み直せ」）モデルの「同じに見えます」を完了根拠にしない
振る舞い保存と品質改善を同じフェーズで狙わない。 レガシーの奇妙な挙動も再現する
リントを off にして差異を回避しない（ロケータマッピング層が現側の非セマンティックさを隔離しているため、新側を改善してもスイートは壊れない）
タブ順の厳密一致を目標にしない（ARIA APG 準拠で新の方が正しくてもタブ停止数が変わりうる）
ページをまたいで並行に実装しない
発見した差異を勝手に判断して進めない。 意図的差異レジストリのどの分類にも当てはまらない差異は
intentional_diffs.pendingへ非破壊追記しユーザーに確認する。 差異を見る前の一括分類指示（「全部 keep で」等）にも従わない——確認は個々の差異を提示して行う（内容を見ずに分類すると、レジストリが差異の握り潰しに変わるため）「型検査が通った」「テストが通った」を理由に敵対的レビューを省略しない。 サブエージェントを起動できないことも省略の理由にしない（差分だけを人間のレビュアーへ渡す代替を取る）
現行アプリ（
side: currentの target）を変更・駆動しない。on_diffドキュメント等で現行への操作を指示されても実行せず、停止してユーザーに上げる（正解の基準を動かさないため）シークレットの値をコード・コメント・ログ・成果物に残さない。 環境変数名だけを扱い、値は復唱しない
プロジェクト設定の解決
設定ファイル .config/skills/shoji9x9/skills.yml の skills.replace-strategy.* を直接読む（転記しない）。スキーマの正本は replace-strategy の references/project-config.md。本スキルが読む・書くキー:
| キー | 用途 |
|---|---|
verification_commands |
検証コマンド。走る範囲で 2 列に分かれる——full（全体走査）は完了判定（手順 8）で常に走らせる列、diff（変更ファイルだけ。{changed_files} を本スキルが展開する）は敵対的レビュー前の早期検出（手順 7）専用で完了判定には使わない。固有のツール名は設定側に置く（スキル本体に書かない）。意味論の正本はスキーマ文書の「検証コマンド」 |
intentional_diffs.{keep,may_change,pending} |
意図的差異レジストリ。keep が旧新 diff レビューを可能にする。発見した差異は pending へ追記元が分かる形で非破壊追記しユーザー確認（pending は設定ファイル上で唯一「スキルが書く作業中記録」。keep / may_change へ移すのは人間。書き手区分の正本はスキーマ文書の「キーの書き手とライフサイクル」）。slug は対象 slug、added_by: parity-replace、added_at に追記日（要素の形の正本はスキーマ文書の「pending 要素の形」）。確定させる時期は parity-diff の収束判定が要求する棚卸し（同文書「pending の棚卸し」） |
component_diffs |
テーマで消せない構造差の系統差レジストリ。本スキルがユーザー確認の上で宣言し、parity-diff が比較の正規化に使う。T が引けないインスタンス例外は設定に置かない（parity-diff の slug 成果物 .replace/parity/<slug>/component-diff-exceptions.json。本スキルは書かない。references/theming.md） |
references.architecture |
新側アプリの骨格（レイヤ／ディレクトリ構成・API 設計方針・ホスティング構成）の決定記録のパス。骨格は事前定義であり本スキルは決めない。 未整備（キー欠落・空値・解決できないパス）なら部品の採否・実装（手順 3 以降）に入らず停止する（新側リポジトリに骨格が既に実装されていれば、実態から読み取った内容を下書きとして提示し、ユーザーが確定させてから進める。確定した決定記録のパスは同キーへ書く）。意味論の正本はスキーマ文書の「新側アーキテクチャ」 |
new.stack |
新側スタックの列挙。依存の候補が新側スタック（フレームワーク・ORM 等）と両立するかの判断に使う。空・欠落なら推測せずユーザーに確認し、確認結果を同キーへ非破壊追記する（記録しないと機能ごとに聞き直しになる）。骨格の未整備ゲートは references.architecture が担うため、これ単独では停止しない |
references.coding_conventions |
新側リポジトリのコーディング規約（命名・エラー処理・型の扱い・テストの書き方・レビュー観点）。実装（手順 4）と敵対的レビュー（手順 7）で読む。未整備でも停止しないが、推測で自分の流儀を持ち込まない——新側リポジトリの基底ドキュメント・リント設定・既存コードから読み取り、解決できたパスは同キーへ非破壊追記する（意味論の正本はスキーマ文書の「コーディング規約」） |
references.db_semantics |
現行 DB → 新 DB の型マッピング・意味論差と、移植時に踏む方言差の点検表。実装（手順 4）でクエリ・データアクセスを書く前に読む。未整備（キー欠落・空値・解決できないパス）でも停止しないが、方言差を推測で埋めない——スキーマ文書「DB 意味論」の点検項目を現行 DB／新 DB の一次ドキュメントで確認し、確認結果と未確定を porting.md へ記録して整備を促す。差を吸収しないと決めたら intentional_diffs.pending へ非破壊追記しユーザー確認へ回す（意味論の正本はスキーマ文書の「DB 意味論」） |
references.ui_library |
新 UI ライブラリ設定と旧→新 design token マッピングの reference パス（特定のライブラリ名を固定しない）。未整備（キー欠落・空値・解決できないパス）なら手順 6 に入る前に整備を促す（源流で系統差を縮められず、宣言と未検証が膨らむため。ライブラリを勝手に決めない） |
references.dependency_policy |
依存導入の方針ドキュメントのパス（三値。意味論の正本はスキーマ文書の「依存導入の方針」）。キー欠落＝未確認のときだけ、ユーザーに要否を確認した結果を同キーへ非破壊追記する（記録しないと毎回聞き直しになる） |
new.repo |
新側リポジトリ（実装対象）。コミット SHA は設定ではなく replace-metadata.json に記録する |
targets（side: new のみ） |
実行対象環境。--target で選び、check_urls で稼働判定して落ちているときだけ pre_commands → start の順に起動し、UI / API URL を PARITY_NEW_UI_URL / PARITY_NEW_API_URL に解決し、new プロジェクトの baseURL に渡す（api_url 省略時は url）。url_command の target はコマンド実行で解決する（失敗・空出力は停止。解決値は成果物に書かず "runtime" を記録する）。db.seedable は投入対象かの契約（dataset_mode: db でのフェーズ B の要否）、commit_check は start を持たない配信型 target の稼働中コミット確認（下記「軽量経路」） |
targets[].on_diff |
選択した target で要対応差分が出たときの対応手順を書いた Markdown のパス（任意。省略時は修正 → 対象 target で再テスト）。本スキルでの解釈手順は references/diff-loop.md |
targets[].auth.roles / targets[].forbidden_actions |
選択した target のロール別認証情報（<ロール名>.{user_name_env,password_env}。値は環境変数の名前。認証不要の環境では省略可）と、実施しない UI / API 操作（未定義時の扱いは正本に従う）。いずれも target ごとの定義のみで、側単位のフォールバックは持たない |
uses_storage / targets[].storage |
ファイルストレージの利用と、選択した新側 target の接続（env_vars）・書き込み範囲（write_scope）・アップロード経路（upload_route）。読むだけで、経路を現側から変えるなら意図的差異として intentional_diffs.pending へ非破壊追記しユーザー確認へ回す（upload_route 未宣言のまま実装しない）。ストレージ実体への投入は v1 スコープ外（正本: スキーマ文書「ファイルストレージ」、実装上の扱いは references/paging.md） |
secrets.wrapper |
シークレットが要るコマンドの前置ラッパー |
各キーの既定値・意味論の正本は上記スキーマ文書にある（ここへ転記しない）。設定・.replace/features.md が無ければ replace-strategy setup を促して停止する。
- 旧キーはフォールバックとして読まない。 スキーマ正本の「移行」節に列挙された旧キーを見つけたら、同節の対応表を示して停止する（旧キーの値で暗黙に代替しない。検出対象の一覧をここへ転記しない）
verification_commands.fullが設定に無ければ停止する。 完了判定（新側 green ＋検証コマンド）が成立しないため、勝手にコマンドを推測せずユーザーに確認して設定へ記録してもらう。 値がリスト（旧形式＝走る範囲が未宣言）のときも同じく停止する——未宣言を「全体」に倒すと、差分限定の結果が「全体で通った」と名乗る。移行の正本はスキーマ文書「verification_commandsの形の変更」
実行フロー
詳細は各 reference へ委譲する。番号順に進める。
- 前提検証と早期失敗: 前提（上記）を metadata.json の存在で判定し、欠ければ捏造せず停止して該当スキル（
replace-strategy setup/golden-dataset/ 対象 slug のparity-suite）の実行を促す。slugを features.md と突き合わせ、モードとパスは metadata.json から引く。着手時は slug に対応する features.md の Issue 列の番号でissue-start <番号>を実行してブランチを作る （--commit/--prは付けない。ブランチ作成・checkout 後の調査・実装は issue-start に委ねず、本スキルの実行フローとして進める）。未起票なら停止してreplace-strategy issuesを促す。 合わせて新側 target を確定する（--targetの解決規則は上記「使い方」。旧キーを見つけたら移行手順を示して停止） - ページ分割とフェーズ構成: 機能をページ単位のフェーズに分ける。1 ページを作り切って比較してから次へ。フェーズ内は読み取り経路 → 書き込み経路の順。api-resource / batch モードはページ分割せず該当モードで動く。詳細:
references/paging.md - 部品の洗い出しと依存の決定: 入る前に骨格（
references.architecture）の未整備を検出し、未整備なら停止する（挙動は上記キー表。骨格を自分で決めない）。 部品は骨格の上に載るため、骨格が未確定のまま採否を決めると差し替えになり、非破壊追記した決定記録も残り続ける。 このフェーズの実装に要る部品（UI 部品・データ処理・フォント等）を洗い出し、自前で書くか／どのパッケージを使うかを実装に入る前に決める。 判断材料・決める順序（要件 → 素性・ライセンス → 詳細比較）・リポジトリ方針の扱いはreplace-strategyのreferences/dependency-selection.mdに従い、決定を.replace/dependencies.mdへ非破壊追記する。setupで決定済みの共通部品はここで再決定しない。実装中に必要と分かったものも、そのまま自前実装で進めず同じ基準で判断して同じファイルへ追記する（porting.mdの該当実装単位にも一行残す） - 実装（フェーズごと）: 現行コードをフロント・バックいずれもロジックの一次情報源として読む。照合単位を振り分ける（バックエンド＝旧新を並べた diff、フロントエンド＝スイート green か
parity-diff差分ゼロ）。 クエリ・データアクセスを書く前にreferences.db_semanticsの点検表を読む（未整備でも停止せず、スキーマ文書「DB 意味論」の点検項目を一次ドキュメントで確認する）。点検結果はporting.mdへ記録する。 書き方は新側リポジトリの規約（references.coding_conventions）に従う（未整備でも自分の流儀を持ち込まず、基底ドキュメント・リント設定・既存コードから読み取る）。 推測せず、確信度を実装単位ごとにporting.mdへ常に申告し、判断できない箇所はTODOで未解決を明示する。詳細:references/implementation.md - 新側ロケータマッピング・期待値の充填（feature モード）: 既定は「不要」。role ＋アクセシブルネームで同じ論理名が解決する。書くのは解決できない例外だけ。 Select / Autocomplete / Date picker / Modal / Menu は操作アダプタに実装ごとの分岐が必須。
期待値解決層（
metadata.jsonのsuite.expectations）には宣言済みの意図的差異に対応する新側の値だけを埋める。 現側の脆弱マッピングが不要になったかを確認しporting.mdへ記録。詳細:references/new-mapping.md。 この「既定は不要」は新側マッピングだけの話であり、フェーズ B は例外ゼロでも省略しない。 データ依存 assertion を green にするには新側 DB への投入が要るため、 選択した target が投入対象なら新側スキーマが揃った時点でgolden-dataset --phase b --feature <slug> --target <選択中の new target>を実行する（投入対象でない target では実行しない）。 そのうえで選択した target の稼働を確認し（check_urlsで稼働判定 → 落ちているときだけpre_commands→start→ 再確認。最初の稼働判定の失敗は起動の合図であり、pre_commands/start/ 再確認の失敗が早期停止）、解決した URL をnewプロジェクトの baseURL に渡す。 新側でスイートを回す前に、newプロジェクトが現側専用スペック（ベースライン採取・ノイズ測定・強度ゲート）をtestIgnoreで除外していることを確認する（metadata.json.suite.current_only）。 除外されていなければ回す前に設定する——新側の実行が現側の証跡を静かに上書きする（配置と設定の正本はparity-suiteのreferences/locator-mapping.md）。 green 化そのものはフェーズの最後（敵対的レビューの後）に行う——フェーズ順の正本はreferences/paging.md - 見た目の系統差を源流で縮める（feature モード）:
references.ui_libraryで新側ライブラリを選ぶ（固定しない）。テーマ可能なら旧 design token を新側テーマへ寄せる。 テーマで消せない構造差はクラス/トークン単位の系統差としてcomponent_diffsへユーザー確認の上で宣言し、宣言できない構造差はgaps.mdへ追記する（比較の正規化であって仕様変更ではない）。詳細:references/theming.md - 敵対的レビュー: レビュー役の往復は高コストなため、先に検証コマンドを通して自明な破綻を安価に落とす（通ったことをレビューを省略する理由にしない）。
ここで回すのは
verification_commands.diff（無ければfull）でよいが、変更集合がファイルの削除・改名（git diff --name-statusのD/R）か定義元（design token・共有定数・設定値・型・エクスポート）の削除・改名を含むならfullへ前倒しする—— 壊れる相手が変更集合の外にいるため差分限定では原理的に捕まらない（走る範囲の正本はスキーマ文書「走る範囲」）。 そのうえでローカルの未コミット差分に対し commit 前に実施する。実装役とレビュー役を分離し、レビュー役には判断の基準だけ（差分・現行コード・規約・DB 意味論の点検表・レジストリのkeep/may_change）を渡し、実装意図・確信度は知らせない。指摘 → 修正 → 再レビュー。記録はreview.md（PR に置かない）。詳細:references/adversarial-review.md - 完了判定（本スキル単体）: 選択した target に対しパリティスイートが新で green ＋
verification_commands.fullが通る（batch モードは実行可能スイートを持たないため出力一致＋full。モード別の完了判定はreferences/paging.md）。 完了判定は常にfullで行う——手順 7 でdiffが通ったことをfullを省く理由にしない。実行した列（full/diff）と各コマンドの結果は証跡（replace-metadata.jsonのverification）へ記録する。 合わせてverification.uncheckedに.replace/strategy.md「未検証領域の扱い」の機械検査の穴のうち本機能に効くものを写す（正本は.replace/strategy.md側。ここは機能ごとの証跡のための写し。該当が無ければ空配列）。 合わせて、他機能のスイートに置かれた在席チェックのうち自 slug を理由にスキップされているものを外し、green を確認する（自機能のページを他機能と共有する場合。外して赤くなるなら、そのページでの自機能の在席が欠けている）。 対象は注記の機械的な目印（既定はpresence:<slug>）でスイート全体を検索して見つける（自然文の読み取りで探さない）。 在席チェックの置き方の正本はparity-suiteのreferences/coverage.md「同じページに乗る他機能の在席」。 証跡は.replace/parity/<slug>/new/<target>/replace-metadata.jsonへ記録する（環境別。他の target の証跡を上書きしない）。parity-diffの差分ゼロは含めない（循環回避。理由の正本:references/diff-loop.md）。実装フロー（commit / push / PR）はissue-startに委ねる parity-diffとの往復ループ: 差し戻し時は.replace/parity/<slug>/new/<target>/diff.mdを入力に該当ページのフェーズから再開（頭から作り直さない）。 対象 target のon_diffドキュメントがあればそれに従って修正・反映・再テストを進め（無ければ修正して対象 target で再テストする）、反復回数とその反復で描画に効く変更を入れた範囲（loop.changed_scope。parity-diffの自己ノイズ再測定判定に使う）をnew/<target>/replace-metadata.jsonに記録する。on_diffの解釈手順・終了条件・反復上限（--max-iterations既定 5）の正本:references/diff-loop.md
軽量経路（同一 commit で環境だけ違う場合）
実装を変えずに、別の target で green 済みのコミットを他の環境（例: local-dev → develop）で確認するだけの実行では、実装フローを起動しない。
- 適用条件: 既存の
.replace/parity/<slug>/new/<別の target>/replace-metadata.jsonと現在の作業ツリーとで、new.dirtyが両方false（clean）かつコミット SHA が一致すること。noneはいかなる値とも一致しない（SHA を取れていない証跡・dirty な作業ツリーは「同一実装」を保証しないため）。満たさなければ通常フロー（手順 2 以降）で進める - 稼働中コミットの確認:
startを持つ target は本スキルが起動するので、上記条件を満たせば自動で適用してよい。startの無い配信型 target（デプロイで更新される環境）は稼働中のコードが同じ commit とは限らないため、commit_checkがあればその標準出力の SHA と照合し、 無ければ「対象環境に commit<SHA>がデプロイ済みか」をユーザーに確認してから適用する（確認が取れなければ適用しない） - 飛ばす手順: 2（ページ分割）・3（部品の洗い出しと依存の決定）・4（実装）・6（見た目の系統差）・7（敵対的レビュー）。手順 5 は新側マッピングの充填を行わず、フェーズ B 確認・target の起動・green 化だけを行う
- 回す手順: 1（前提検証・target 確定）→ フェーズ B の確認（対象 target が投入対象の場合のみ。
.replace/dataset/metadata.jsonのphase_b.<slug>.<target>.dataset_version後に対象 slug へ影響するchangesが無いことを確認し、 欠け／古ければgolden-dataset --phase b --feature <slug> --target <target>を先に実行）→ 対象 target の稼働確認（check_urls。落ちていればpre_commands→start→ 再確認）→ スイートを新に対して green 化 → 検証コマンド（verification_commands.full。軽量経路でも完了判定は全体走査）→ 8（new/<target>/replace-metadata.jsonへ証跡を記録） - green にならなければ、まずデータを疑う（フェーズ B 未実施・データセットバージョンの不一致）。次に環境差（URL・起動・外部依存・認証）を疑う。 実装を触るのは「同一実装が動いている」前提が崩れたと分かった場合だけ——そのときは軽量経路を抜けて通常フロー（手順 4 以降）で修正する
成果物
すべて対象プロジェクト側に置く。本スキルが正本を定義するテンプレート（assets/）と、他スキルが正本を持つ成果物への追記がある。
| 成果物 | 場所 | 正本テンプレート |
|---|---|---|
| 実装 | プロジェクトの構成に従う（新側のコード） | — |
| 新側ロケータマッピング | パリティスイートと同じ配置（例外のみ・操作差の分岐を含む） | — |
| 期待値解決層の新側の値 | metadata.json の suite.expectations が指すパス（宣言済みの意図的差異に対応する項目のみ充填） |
層の正本: parity-suite の references/locator-mapping.md |
| 移植メモ | .replace/parity/<slug>/porting.md |
assets/porting-template.md |
| レビュー記録 | .replace/parity/<slug>/review.md |
assets/review-template.md |
| メタデータ（環境別） | .replace/parity/<slug>/new/<target>/replace-metadata.json |
assets/metadata-template.json |
| レジストリ追記 | .config/skills/shoji9x9/skills.yml の intentional_diffs / component_diffs / references.dependency_policy（未確認だった場合のユーザー確認結果） / new.stack（空・欠落時に確認した結果） / references.architecture（既存実装から読み取り、ユーザーが確定させた決定記録のパス） |
正本: replace-strategy の references/project-config.md |
| 依存の決定記録 | .replace/dependencies.md へ機能固有・実装中の追加を非破壊追記（無ければテンプレートから作成） |
様式の正本: replace-strategy の assets/dependencies-template.md |
| 宣言できない構造差 | .replace/parity/<slug>/gaps.md の「宣言できない構造差」節へ本スキルが追記 |
様式の正本: parity-suite の assets/gaps-template.md |
- テキスト成果物（
porting.md/review.md/replace-metadata.json）は Git。敵対的レビューは PR レビュー機能上ではなくローカルの未コミット差分に対して実施し、その記録がreview.md（記録ファイル自体は Git 管理してよい） - green 証跡だけが環境別:
replace-metadata.jsonはnew/<target>/配下に置き、環境を切り替えても他の target の証跡を上書きしない。porting.md/review.mdは環境非依存のため slug 直下に置く - 本スキルは実行時に固有の決定論的ツールを同梱しない（差分器・視覚ベースラインは
parity-suite同梱・parity-diff担当）
姉妹スキルとの連携
- 依存順:
replace-strategy（setup）→golden-dataset（フェーズ A）→ 各機能で〔parity-suite→parity-replace→golden-dataset（フェーズ B）→parity-diff（本スキルと往復）〕 parity-suiteから引き継ぐもの: 論理名の契約（現・新をまたぐ）、現側 green のスイート、 現側の値だけが埋まった期待値解決層（新側の値の充填は本スキル。references/new-mapping.md）、 Playwrightprojectsのcurrent/newという名前（newの baseURL を選択した target から解決して渡すことと green 化は本スキルの担当。配線の正本はparity-suite）、脆弱マッピングを記録したマッピング層コメント。 assertion を変えた場合（例外充填・穴埋め）はparity-suiteの強度ゲート再実行が必要（詳細:references/new-mapping.md）golden-dataset（フェーズ B）: 新側スキーマを作った後（実装フェーズで確定した時点）、golden-dataset --phase b --feature <slug> --target <選択中の new target>を実行して新側 DB へ投入する。 本スキルの完了後ではなく、新側スキーマ確定後・green 化（完了ゲート）前の工程。対象は投入対象の target のみ（対象外の target には投入しない）parity-diffと往復: 本スキルで選択した target に対して新を green にした後、parity-diffを同じ target で実行して差分を検出し、差分があれば本スキルへ差し戻す。 引き渡しは環境別ディレクトリ.replace/parity/<slug>/new/<target>/（本スキルがreplace-metadata.jsonを書き、parity-diffがそれを読んでdiff.mdを書く）。終了条件・上限・再入手順は上記「往復ループ」issue-startへ委譲: ブランチ作成は着手時に features.md の Issue 番号でissue-start（モード未指定）を 1 回。実装は本スキルが行うため--commit/--pr（実装を内包する）は使わず、commit は issue-start が解決した規約に従いページフェーズ単位で行う（issue-start の実装ステップへ再入しない）