rs-update

RootSpec プロジェクトを最新のフレームワークバージョンにアップグレードします。まず、これから行うことを開発者に伝えます。

「プロジェクトが最新のフレームワークバージョンに対応しているか確認し、必要なものをアップグレードします。フレームワークファイル、前提条件、設定が対象です。」

モード

このスキルは、次のいずれかのモードで実行されます。

• 対話モード（デフォルト） — 計画を提示して確認を待ち、開発者とともに違反項目の調整を進めます。人間が関与する実行に適しています。
• CI モード — プロンプトを表示せずに計画を自動適用します。違反項目ごとのポリシーには「推奨」パスを使用します。実行全体はトランザクション方式で行われます（すべての事前チェックに合格した場合のみ、ファイルを変更します）。CI パイプラインでの claude -p 呼び出し、定期的なリビルド、または無人実行が必要な状況に適しています。

次のいずれかのシグナルで CI モードを検出します。

if [[ "${CI_FOCUS:-}" == "ci" || -n "${ROOTSPEC_CI:-}" || "${CI:-}" == "true" ]]; then
  CI_MODE="true"
else
  CI_MODE="false"
fi

（ここでの CI_FOCUS は、このスキルのフォーカス引数として文字列 ci が渡されたことを意味します（/rs-update ci）。ほとんどの CI ランナーでは CI=true が自動的に設定されます。ローカルで CI モードを使う場合は、ROOTSPEC_CI=1 をエクスポートします。）

CI_MODE=true の場合は、このドキュメント全体に記載された CI の動作に従い、確認プロンプトをすべて省略します。false の場合は、記載どおりに対話型フローを進めます。

ステップ 1：差分を検出する

スキャンスクリプトと差分分析スクリプトを実行します。

bash "$(dirname "$0")/../rs-shared/scripts/scan-spec.sh" .
bash "$(dirname "$0")/../rs-shared/scripts/gap-analysis.sh" .

これらのパスが解決できない場合は、skills ディレクトリ内で gap-analysis.sh を検索してスクリプトを見つけます。

出力に応じて、次のように対応します。

• GAP=no_project — .rootspec.json が見つかりません。開発者に「RootSpec プロジェクトが見つかりません。まず /rs-init を実行してください。」と伝えて終了します。
• GAP=none — すでに最新のフレームワークバージョンを使用しています。RULE_VIOLATIONS が空の場合は、開発者に「プロジェクトはバージョン X.Y.Z で、現在のフレームワークルールに適合しています。更新するものはありません。」と伝えて終了します。RULE_VIOLATIONS が空でない場合は、プロジェクトが1つ以上のフレームワークルールより古い状態です。ステップ 2～4 を省略し、ステップ 5（フレームワークルールの調整）に進みます。
• GAP=patch|minor|major — アップグレードが必要です。続行します。（アップグレード後もステップ 5 で調整を行います。）

ステップ 2：変更内容を提示する

アップデートガイドを読みます。

skills/rs-update/UPDATE.md

このスキルファイルからの相対パスで見つけます：“$(dirname "$0")/UPDATE.md”

PROJECT_VERSION（含まない）から BUNDLED_VERSION（含む）までのバージョンセクションをすべて抽出します。次の内容を提示します。

• バージョンの差分（例：「6.2.1 → 6.2.3」）
• 各バージョンの変更概要
• 手動での対応が必要な手順
• 破壊的変更の有無

ステップ 3：アップグレード計画を提示する

差分分析の出力に基づき、明確な計画を提示します。

Upgrade plan (6.2.1 → 6.2.3):

Will update:
  - rootspec/00.FRAMEWORK.md (replace with vX.Y.Z)
  - rootspec/00.AXIOMS.md (replace with latest)
  - .rootspec.json version field

Will create (new prerequisites):
  - [list from NEW_PREREQUISITES, if any]

Needs reconciliation (changed prerequisites):
  - [list from CHANGED_PREREQUISITES, if any]

Will NOT touch:
  - Spec files (01.PHILOSOPHY.md through 05.IMPLEMENTATION/)
  - CONVENTIONS/ (owned by /rs-impl)

[If HAS_BREAKING=true]
⚠ Breaking changes detected — see details above.

対話モード： 開発者の確認を待ちます。開発者は項目を除外できます（例：「dev.sh をスキップ」）。

CI モード： 確認を省略します。適用を始める前に、トランザクション方式の事前チェック（以下を参照）を実行します。事前チェックに失敗した場合は、構造化レポートを出力して実行全体を中止します。成功した場合は、計画全体を適用します。

トランザクション形式の事前チェック（CI のみ）

ファイルを書き込む前に、予定されているすべての操作を検証します。チェックに失敗した場合は、中止レポート（Step 6 の CI 形式）を出力して終了コード 1 で終了します。一部だけ適用することはありません。

RULE_VIOLATIONS の各項目について、事前チェックを実行します。

違反	事前チェック	失敗時 →
baseUrl_has_path	すべての visit: 参照を分類します。相対パス（/ で始まらないもの）は、人による判定が必要です	中止
testmode_implicit_dev	なし — 「現在の動作を維持する」を自動選択します	合格
previewServer_missing	なし — 追加のみです	合格
legacy_body_ready	cypress/support/app-ready.ts が存在し、'cy.appReady() is not implemented' を含まず、check-app-ready.sh による検証に合格すること	中止
shallow_app_ready	なし — フレームワークのルールにより自動書き換えは禁止されています	中止
dev_cmd_recursive	detect-stack.sh が空でない DEV_CMD を返すこと（プレビューも再帰的な場合は PREVIEW_CMD も返すこと）	検出できない場合は中止
viewport_missing	なし — ファイル編集は冪等です。テストファイルを削除することはありません	合格

中止メッセージには、違反トークン、チェックした内容、失敗した理由、再実行前に開発者が行う必要があることを含めてください。具体的なエラーテンプレートは次のとおりです。

• legacy_body_ready の事前チェック失敗：

  legacy_body_ready の移行を適用できません：cy.appReady() が実装されていません （または実装が不十分です）。CONVENTIONS/technical.md → App Readiness に従って cypress/support/app-ready.ts を実装し、/rs-update ci を再実行してください。

  safeVisit を例外を投げる cy.appReady() に接続することは、既知の不具合状態です。 その状態でのリリースは行いません。

• shallow_app_ready の事前チェック失敗：check-app-ready.sh のエラーをそのまま伝え、CI モードでは自動書き換えを行わないこと、および CONVENTIONS/technical.md → App Readiness に従って実装して再実行するようにという注記を加えます。

• dev_cmd_recursive の事前チェック失敗（スタックを検出できない場合）：

  dev_cmd_recursive を調整できません：detect-stack.sh でフレームワークが見つかりませんでした （astro/vite/next/nuxt などの設定ファイルまたは devDependency がありません）。scripts/dev.sh / scripts/preview.sh で DEV_CMD と PREVIEW_CMD を手動で設定してから、再実行してください。

事前チェックが1つでも失敗した場合は、何も書き込まず、中止レポートを出力して終了コード 1 で終了します。

ステップ 4：アップグレードを実行する

確認済みの計画にある各項目について、次の処理を行います。

フレームワークファイル

1. 00.FRAMEWORK.md — ../rs-shared/00.FRAMEWORK.md（このスキルからの相対パス）を読み込み、{specDirectory}/00.FRAMEWORK.md に書き込みます。
2. 00.AXIOMS.md — ../rs-shared/00.AXIOMS.md を読み込み、{specDirectory}/00.AXIOMS.md に書き込みます。

設定

3. .rootspec.json — 現在のファイルを読み込み、version フィールドのみを BUNDLED_VERSION に更新します。他のフィールド（specDirectory、prerequisites）はすべて保持します。

新しい前提条件

4. NEW_PREREQUISITES の各項目について、プロジェクト内にファイルまたは設定が存在するか確認します。存在しない場合は、/rs-init と同じロジックを使って作成します。作成方法については ../rs-shared/fragments/prerequisites.md を読み込みます。

変更された前提条件

5. CHANGED_PREREQUISITES の各項目について、前提条件は存在しますが、要件が更新されています。何が変更されたのか、なぜ変更されたのかを開発者に示します（UPDATE.md を参照）。自動で上書きしてはいけません。開発者のファイルにはプロジェクト固有のカスタマイズが含まれている可能性があります。

   テンプレートスクリプト（例：scripts/dev.sh）の場合は、プロジェクト内のファイルと同梱テンプレートとの差分を示します。どのように反映するかは開発者に判断してもらいます。

   設定の接続（例：cypress.config.ts）の場合は、必要な変更内容を説明し、適用する前に開発者の確認を得ます。

仕様のステータス

6. write-spec-status.sh を実行して、spec-status.json のバージョンを更新します。

bash "$(dirname "$0")/../rs-shared/scripts/write-spec-status.sh" {specDirectory}

破壊的変更が検出された場合（HAS_BREAKING=true）、2 番目の引数に false を渡して仕様を無効としてマークし、開発者に /rs-spec を再実行するよう伝えます。

bash "$(dirname "$0")/../rs-shared/scripts/write-spec-status.sh" {specDirectory} false

ステップ 5：フレームワークのルールとの整合性を取る

gap-analysis の RULE_VIOLATIONS が空でない場合に実行します。各トークンは、フレームワークのルールが適用される前のプロジェクトの状態を示します。

対話モード： 違反ごとに修正案を提示し、適用前に確認を求めます。これらがユーザーのコードを書き換えることはありません。CI： 以下のポリシーテーブルに従って、推奨される方法を自動的に適用します。各項目はステップ 3 の事前チェックですでに検証済みです。

CI ポリシーの概要

違反	CI の動作
baseUrl_has_path	baseUrl からパスを自動的に取り除き、プレフィックスのない visit 参照に自動的にプレフィックスを追加します（相対参照は事前チェックで中断済みです）。
testmode_implicit_dev	**「現在の動作を維持」**を自動的に選択し、"testMode": "dev" を追加します。これは保守的な選択です。preview に切り替えると、予期せず動作が変わる可能性があります。必要に応じて、後から人間が切り替えられます。
previewServer_missing	"previewServer": "./scripts/preview.sh" を自動的に追加し、存在しない場合は同梱のテンプレートをコピーします。
legacy_body_ready	常に完全移行を実施します。 cy.appReady() が実装済みであることは、事前チェックですでに検証済みです。
shallow_app_ready	自動書き換えは行いません。 事前チェックで実行がすでに中断されています。（この行はリマインダーとしてのみ存在します。この違反がある場合、CI は Apply フェーズに進みません。）
dev_cmd_recursive	detect-stack.sh から DEV_CMD／PREVIEW_CMD を自動的に設定し、ラッパーを同梱のテンプレートで上書きします（これにより、再帰ガードが適用されます）。検出に成功したことは、事前チェックですでに確認済みです。
viewport_missing	setViewport とジオメトリーアサーションを使って、cypress/support/schema.ts と steps.ts を自動的に拡張します（冪等です）。存在しない場合は、CONVENTIONS/technical.md に Test Viewports セクションを自動的に追加します。既存の .cy.ts ファイルは削除せず、開発者に再生成が必要なことを知らせるために WARN=cypress_e2e_needs_regen を出力します。

baseUrl_has_path

プロジェクトの cypress.config.ts には、baseUrl: 'http://host:port/some/path' が設定されています。フレームワークでは、baseUrl を host:port のみにする必要があります。デプロイパスは visit: のターゲットと cy.visit() の呼び出しに指定します。両方を連結すると、/some/path/some/path/ のような 404 が発生します。

開発者には次の情報を提示します。

1. 現在の baseUrl の行と、取り除く必要があるパス（例：/some/path）。
2. cypress/ と rootspec/05.IMPLEMENTATION/USER_STORIES/ を対象にした、visit: および cy.visit( 参照の grep 結果。
3. visit 参照を次のように分類します。
   • すでにプレフィックスあり（パスで始まる）— そのままにします。baseUrl からパスを取り除けば機能します。
   • プレフィックスなし（/ で始まるが、パスでは始まらない）— パスの追加を提案します。
   • 相対参照（/ で始まらない）— 手動確認が必要な項目として示します。相対パスは、以前の契約と新しい契約のどちらでも機能しません。

対話モード： 開発者が確認した項目のみを適用します。完了後、確認のために /rs-validate を再実行します。 CI： パスを自動的に取り除き、プレフィックスのない visit 参照にパスを自動的に追加します。相対参照は事前チェックですでに中断されています。

testmode_implicit_dev

このプロジェクトの scripts/test.sh は開発サーバーを起動しますが、.rootspec.json には prerequisites.testMode がありません。以前のプロジェクトでは、E2E テストは暗黙的に開発モードがデフォルトでしたが、フレームワークは現在、フレークを減らすためにプレビューモード（ビルド済みアーティファクト＋プレビューサーバー）をデフォルトにしています。

次の 2 つの方法を提示します。

• 現在の動作を維持する — .rootspec.json の prerequisites に "testMode": "dev" を追加します。それ以外の変更はありません。プロジェクトは明示的な選択により、引き続き開発モードで E2E テストを実行します。
• プレビューのデフォルトに切り替える（推奨） — バンドルから scripts/preview.sh をコピーし（下記の previewServer_missing を参照）、scripts/test.sh を testMode 対応のテンプレートに書き換えます（bootstrap-init.sh を参照）。.rootspec.json に "testMode": "preview" と "previewServer": "./scripts/preview.sh" を追加します。コミットする前に npm run build が正常に動作することを確認してください。

開発者が「切り替える」を選んだ場合、プロジェクトではアプリの準備完了状態を実装する必要があるかもしれないことを伝えてください（framework-rules.md の「App Readiness」を参照）。プレビューモードでは、開発モードで隠れていたハイドレーションのタイミングバグが表面化します。

CI： 自動的に「現在の動作を維持する」を選びます（"testMode": "dev" を追加）。プレビューへの切り替えは実行時の動作を変える可能性があります。CI の目的は安全にアップグレードすることであり、動作のデフォルトを切り替えることではありません。後から人間が切り替えられます。

legacy_body_ready

このプロジェクトの cypress/support/steps.ts は、アクセスするたびに <body data-ready="true"> を待機します（7.6.0 より前の仕様）。フレームワークは現在、cy.appReady() を想定しています。これは cypress/support/app-ready.ts でプロジェクトが定義する準備完了状態です。body レベルの準備完了状態では、アイランドごとのハイドレーションを確認できません。非同期アイランドを使うスタックでは、body の準備完了を確認した後に、テストが操作不能な DOM をクリックしてしまいます。

次の 2 つの方法を提示します。

• スタブのみ（最小限の変更） — エラーをスローするデフォルト実装で cypress/support/app-ready.ts を生成し、cypress/support/e2e.ts に import './app-ready'; を追加します。ひとまず steps.ts は変更しません。開発者は後から、ストーリーごとに cy.appReady() を導入できます。既存のテストでは引き続き body の待機を使用します。
• 全面的な移行（推奨） — スタブのみの場合と同じ変更に加え、steps.ts の safeVisit を書き換えます。cy.get('body').should('have.attr', 'data-ready', 'true') の行を cy.appReady() に置き換えます。runSetupSteps とスキーマに awaitReady ステップを追加します。その後、開発者は cy.appReady() を実装する必要があります（静的サイトでは何もしない 1 行の実装、ハイドレーションの多いサイトでは実際のチェック）。body[data-ready] を設定する既存のページは変更されません。設定を続けても停止してもかまいません。フレームワークは以後、その設定を参照しません。

全面的な移行を選んだ場合、最初の npx cypress run は「cy.appReady() is not implemented」というエラーで失敗することを開発者に伝えてください。これは仕様が表面化したものであり、リグレッションではありません。

CI： 常に全面的な移行を行います。事前チェックでは、cy.appReady() が実装済みであること（エラーをスローするスタブではなく、遅延実行の境界に対して浅いチェックでもないこと）をすでに確認しています。safeVisit をエラーをスローするスタブに接続するのは既知の不具合状態であり、事前チェックで拒否されるため、そのままリリースされることはありません。

shallow_app_ready

プロジェクトの cypress/support/app-ready.ts は、ドキュメントレベルのシグナル（document.readyState、body の存在、cy.wrap(true) など）で解決しますが、プロジェクトでは遅延実行境界（Astro の client:*、RSC の 'use client'、React.lazy/Suspense、Next.js の dynamic()、Vue の defineAsyncComponent など）、つまり初期ドキュメントの到着後にインタラクティブなコードが実行されるコンポーネントやモジュールをマウントしています。浅いチェックは、これらの境界がインタラクティブになる前に完了します。そのため、テストは断続的に成功するものの、ハイドレーションされていないコンポーネントを最初にクリックすると失敗します。これは、7.6.0 の契約が防ぐことを意図していたものと同じフレークですが、より低い層で発生します。

開発者に次の内容を示してください。

1. 現在の cypress/support/app-ready.ts の内容と、一致する浅いパターン。
2. プロジェクトで見つかった遅延実行マーカー（ファイルパスと一致したディレクティブ／インポート）。
3. 必要な修正：これらの境界が完全にアクティブになったときに発するシグナル（フレームワークまたはアプリが設定するグローバル、既知のノードの属性、ポーリングするコンポーネントの状態、イベントなど）を待つように cy.appReady() を書き換えます。選択した仕組みを CONVENTIONS/technical.md → App Readiness に記載します。記載する内容は、（a）ステップ 2 に挙げた境界、（b）各境界がアクティブ時に発するシグナルです。

app-ready.ts を自動で書き換えてはいけません。選択はアプリの実際のハイドレーションの仕組みによって異なります。まず開発者に規約のセクションを確認してもらってください。実装はそこから導かれます。

プロジェクトに scripts/check-app-ready.sh も存在しない場合は、同じルールで今後のテスト実行をゲートできるよう、同梱の rs-shared/scripts/ からコピーしてください。書き換え後、./scripts/check-app-ready.sh . を実行してゲートを通過することを確認してください。

CI： 自動で書き換えてはいけません。事前チェックでは check-app-ready.sh のエラーをそのまま表示して実行全体を中止します。CONVENTIONS/technical.md → App Readiness に従って実装し、再実行してください。

dev_cmd_recursive

プロジェクトの scripts/dev.sh および／または scripts/preview.sh で、DEV_CMD／PREVIEW_CMD に再帰パターン（npm run dev、./scripts/dev.sh など）が設定されており、かつ package.json で dev／preview スクリプトがラッパー経由になっています。誰かが npm run dev と入力すると、無限ループに陥ります。一部のプロジェクトでこれを隠していた回避策（package.json からフレームワークのバイナリを直接呼び出し、ラッパーを経由しない方法）は、ラッパーのポート処理と単一インスタンス保証を無効にしてしまいます。

detect-stack.sh を実行して、フレームワークのバイナリコマンドを特定してください。

eval "$(bash "$(dirname "$0")/../rs-shared/scripts/detect-stack.sh" .)"
echo "Detected: $STACK"
echo "DEV_CMD=$DEV_CMD"
echo "PREVIEW_CMD=$PREVIEW_CMD"

detect-stack.sh は、.rootspec.json の prerequisites.detected に記録された元の値（プロジェクトのブートストラップ前の package.json スクリプト）を優先し、次にフレームワーク設定ファイルの有無を調べ、その後 package.json の devDependency を確認します。

対話型： 検出された DEV_CMD／PREVIEW_CMD の値を開発者に示し、確認を求めます。値を編集する（例：--host 0.0.0.0 を追加する、ポートを変更する）こともできます。確認された変更のみ適用してください。STACK=unknown の場合は、フレームワークのバイナリを手動で特定する手順を案内してください。

CI： DEV_CMD が空でなければ自動で適用します（事前チェックで検証済みです）。STACK=unknown の場合は、実行を中止してください（事前チェックの失敗）。

適用フェーズ：

1. scripts/dev.sh を、同梱の ../rs-shared/scripts/dev.sh のテンプレートで上書きします（新しい再帰ガードが含まれています）。
2. scripts/preview.sh を、同梱の ../rs-shared/scripts/preview.sh のテンプレートで上書きします。
3. ラッパー内の空の DEV_CMD="" 行を DEV_CMD="<detected command>" に置き換えます。PREVIEW_CMD="" も同様に置き換えます。
4. package.json の dev／preview スクリプトがラッパー経由になっていることを確認します（この違反が検出された場合、通常はすでにそうなっています）。そうでない場合は書き換えてください。
5. CONVENTIONS/technical.md → Dev Server セクションを、選択したコマンドで更新します。

viewport_missing

プロジェクトに @journey: MOBILE_* または @journey: TABLET_* タグが付いたユーザーストーリーが少なくとも1つあり、生成済みの cypress/e2e/*.cy.ts ファイルが存在する一方で、それらのテストファイルのどれにも cy.viewport( が含まれていません。7.8.0 より前のジェネレーターはビューポートを認識しなかったため、ジャーニーに関係なく、これらのテストは Cypress のデフォルトである 1000×660 で実行されます。「375px で横スクロールが発生しない」という基準も、デスクトップ幅のビューポートでは条件を満たしたことになってしまいます。

適用フェーズ（インタラクティブモードと CI のどちらでも同じです）：

1. cypress/support/schema.ts を拡張する — Step のユニオンに setViewport を追加します（不足している場合は shouldHaveNoOverflowX／shouldFitViewport も追加します）。冪等に処理し、すでに存在する行はスキップします。

2. cypress/support/steps.ts を拡張する — runSetupSteps に else if ('setViewport' in s) cy.viewport(s.setViewport.width, s.setViewport.height); を追加し、ジオメトリアサーションの分岐を runAssertionSteps に追加します。冪等に処理します。

3. CONVENTIONS/technical.md にテスト用ビューポートを追加する — セクションがない場合は、../rs-shared/viewport-defaults.json のフレームワークのデフォルト値を使い、Testing の下に追加します。

   ### Test Viewports
   - **MOBILE_JOURNEY:** 375x667
   - **TABLET_JOURNEY:** 768x1024
   

4. 開発者に伝える — 既存の cypress/e2e/*.cy.ts ファイルはビューポート対応より前に生成されたため、再生成が必要です。

   モバイル／タブレットジャーニーのストーリーに対する既存のテストは、ビューポート対応より前に生成されました。該当する cypress/e2e/*.cy.ts ファイルを削除し、/rs-impl を再実行して、setViewport を挿入したテストを再生成してください。（ユーザー所有のテストファイルは自動では削除しません。）

インタラクティブモード： ファイルを編集する前に毎回確認します。最後にテストファイルの再生成を提案します。 CI： 手順1～3を自動適用します（冪等なファイル編集、フレームワーク所有の仕組み）。再生成の手順はスキップします（CI ではユーザーファイルを削除しないため）。次回、開発者が実行する処理で対応できるよう、構造化レポートに WARN=cypress_e2e_needs_regen を含めます。

previewServer_missing

プロジェクトの .rootspec.json に previewServer エントリーがありません。testmode_implicit_dev を「switch」パスで解決している場合は、同じ手順でこれを修正します。それ以外の場合は、前提条件を記録するため、./scripts/preview.sh を指すエントリーを追加します（同梱テンプレートがない場合はコピーします）。dev モードのままのプロジェクトでも、プレビュー用のインフラストラクチャが利用できると便利です。

レポート

各違反について、Step 6 のレポートで、調整した内容（または開発者の要望によりスキップした内容）を報告します。

Step 6: レポート

インタラクティブモード

実施した内容を要約します。

Update complete (6.2.1 → 6.2.3).

Updated:
  - rootspec/00.FRAMEWORK.md
  - rootspec/00.AXIOMS.md
  - .rootspec.json version

Created:
  - [any new prerequisites]

Flagged for review:
  - [any changed prerequisites with reconciliation notes]

Next steps:
  - [Re-run /rs-impl to update conventions if needed]
  - [Any manual instructions from UPDATE.md]

CI

CI スクリプトで検索できるよう、構造化された key=value 形式のレポートを出力します。

RESULT=success
APPLIED=baseUrl_has_path,previewServer_missing,legacy_body_ready
SKIPPED=
ABORTED_ON=
WARN=
EXIT=0

viewport_missing が APPLIED に含まれる場合は、WARN=cypress_e2e_needs_regen も出力します。これにより CI スクリプトは、次回、開発者が実行する /rs-impl でテストファイルを削除して再生成する必要があることを認識できます。複数の警告はカンマ区切りにします。

中止時：

RESULT=aborted
APPLIED=
SKIPPED=
ABORTED_ON=shallow_app_ready
EXIT=1

フィールドの意味：

• RESULT — すべての違反を解消したか違反がなければ success、事前チェックに1つ以上失敗した場合は aborted（何も適用されません。トランザクション契約に基づきます）。
• APPLIED — この実行で調整した違反を表すトークンをカンマ区切りで指定します。
• SKIPPED — 開発者が（インタラクティブモードで）適用を拒否したトークンです。CI では常に空です。
• ABORTED_ON — 事前チェックに失敗したトークンをカンマ区切りで指定します。成功時は空です。
• EXIT — 成功時は 0、中止時は 1 です。スキルはこのコードで終了します。

CI がパイプでパーサーに渡せるよう、レポートは改行のみの行から標準出力に出力してください。

フォーカス

開発者が引数を渡した場合：

• "ci" → CI モードを有効にします（Mode セクションを参照）。確認なしで、違反ごとに推奨される方法を実行し、トランザクション方式の事前チェックを行い、key=value 形式の構造化レポートを出力します。ROOTSPEC_CI=1 の設定と同等です。
• バージョン番号（例："6.2.2"）→ その特定バージョンでの変更点のみを表示します。
• "check" → ギャップ分析のみを実行し、変更は一切適用しません（ドライラン）。
• "prerequisites" → 前提条件の更新のみを処理します（フレームワークファイルはスキップします）。

対象範囲

• 読み取り可能: すべてのプロジェクトファイル、同梱されているすべてのスキルファイル
• 書き込み可能: {specDirectory}/00.FRAMEWORK.md、{specDirectory}/00.AXIOMS.md、{specDirectory}/spec-status.json、.rootspec.json、新しい前提条件ファイル
• 書き込みは避けること: 仕様ファイル（01-05）、アプリケーションのソースコード、既存のテストファイル
• 上書きは避けること: 開発者の確認なしに既存の前提条件ファイルを上書きすること