キットが改善されたらコピーを更新する

1. 開始地点を記録する

更新は貼り付けではなく小さなプロジェクトとして扱います：持っているキットのリビジョンと新しいものを比較し、変更を移し、デプロイ前にブランチでテストします。これは、プロジェクトがキットリポジトリのフォーク（GitHub がソースとの接続を保つコピー）であっても、自分のアプリにコピーしたコードであっても機能します。

何よりも先に、プロジェクトに 3 つのことをメモしてください：開始したキットのコミット（SHA — 正確な 1 つのバージョンを識別する Git の短いコード）、受け取ったリポジトリ（supastack-web、supastack-mobile、supastack-desktop、または All Platforms モノレポ）、そしてすでに自分で加えた変更です。

キットリポジトリとモノレポは異なる履歴を持つため、一方のブランチを他方のフォークにマージしてはいけません。開始 SHA を記録していなかった場合は、フォークでは git merge-base で最も近い共通バージョンを見つけ、選択的導入では最後にコピーしたファイルとテストを特定してください — 正確なベースラインが不確かなときは、より広い差分を確認します。

2. 新しいリビジョンを取得してマージする

以下のコマンドは、作業を保存してコミットした状態（クリーンな作業ツリー）で、プロジェクトフォルダー内のターミナルで実行します — 中途半端なものがマージに混ざらないようにするためです。山括弧の中の言葉は置き換え用テンプレートです：<thing> 全体を自分の値で置き換えます。表示されている GitHub アドレスはプレースホルダーです。フォークしたリポジトリのアドレスを使ってください。

各行の動作：git remote add はコピーに kit-upstream（キットリポジトリ）という 2 番目のアドレスを教え、git fetch はファイルに触れずに最新の状態をダウンロードします。git switch -c は別の更新ブランチを作成し、確認中もメインブランチがそのまま保たれます。git log は取り込もうとしているコミットを列挙し、git diff --stat はどのファイルが変わったかを要約します。コミットのタイトルだけでなく、使っているモジュールの完全な差分を読んでください。git merge が新しいコードを更新ブランチに取り込みます。

Git が kit-upstream リモートがすでに存在すると報告した場合は、remote add の行をスキップして git fetch で続行します。<previous-kit-sha> は手順 1 で記録した開始 SHA です。

# Upstream is the platform repository you forked — substitute its real URL
# (supastack-web shown; use supastack-mobile or supastack-desktop as fits).
git remote add kit-upstream https://github.com/<org>/supastack-web.git
git fetch kit-upstream
git switch -c upgrade/kit-update
git log --oneline <previous-kit-sha>..kit-upstream/main
git diff --stat <previous-kit-sha>..kit-upstream/main
git merge kit-upstream/main

3. 作業を失わずに競合を解決する

競合とは両側が同じ行を変更したことを意味します：キットが進み、あなたも同じ場所をカスタマイズしました。Git はマージを一時停止してファイルに印を付けます — 損傷を報告しているのではなく、選択を求めているのです。

印の付いた各ファイルをエディターで開き、行ごとに判断します：製品独自のテキスト、名前、設定は残し、キットの修正と構造的な変更は取り込みます。カスタマイズしたファイルをキットの新しいバージョン全体で置き換えて競合を解決してはいけません — それは作業を消します。更新ブランチ内で解決し、続行前に解決した各領域のテストを実行してください。

マージがうまくいかなければ、git merge --abort がブランチをマージ前の状態に戻します。自分で更新ブランチをマージするまで、この流れの何もメインブランチやデプロイを変更しません。

4. データの更新とデプロイを正しい順序で行う

新しいキットのリビジョンはデータベースを変更することがあります。packages/db/drizzle/（マイグレーションフォルダー）の新しいファイルを読み、マイグレーションを適用する前に本番データをバックアップしてください。まず使い捨てのコピーでテストします。互換性のあるスキーマ変更は、それを必要とするコードの前にデプロイします：マイグレーションがデータを削除または再形成する場合、アプリコードだけをロールバックしても古いスキーマは復元できません。

新しい .env.example と自分の設定を比較し、新たに必要になった値をホスティングダッシュボードに追加します。.env ファイルはシークレットを含み、Git にコミットされることはありません — 各マシンとデプロイで手動で再作成し、NEXT_PUBLIC_ と EXPO_PUBLIC_ の値には入れません。

デプロイ前に、キット自体の検証ゲートを実行します。All Platforms モノレポでは、corepack pnpm check:local が有料資格情報なしで lint、型チェック、ユニットテスト、フォーマットチェックを実行し、corepack pnpm verify:local が本番ビルドとブラウザテストスイートを追加します。単一サーフェスのフォークでは、そのリポジトリ自身のテストとビルドコマンドを実行します。その後、ステージングでのスモーク確認を行います：サインインし、2 つ目のワークスペースを試し、製品の主要なユーザージャーニーを実行します。

すべてが通過したら、受け入れた対象 SHA と解決した競合を書き留めます — そのメモが次回更新の開始ベースラインになります。

corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local

5. フォークではなく一部をコピーした場合

選択的導入（既存アプリへのキットモジュールのコピー）はキットと Git 履歴を共有しないため、git merge は助けになりません。代わりに古いソース SHA と対象のソース SHA を比較し、導入した部分に触れる変更だけを移植します。

モジュールの公開型、永続化スキーマとマイグレーション、サーバー呼び出し元、設定、テスト、ドキュメントを 1 つの単位として確認します — パッケージ内の変更は他の場所での対応するルートや環境の変更を必要とする場合があり、単一のヘルパーをコピーすると残りが古いコントラクトのままになることがあります。どのキットファイルを取り、どれをスキップし、何を変えたかという短い適応メモを残してください — 次の更新であなたの選択を再現できます。

更新で実行中のコピーの何かが壊れた場合は、自分の変更を元に戻す前にトラブルシューティングガイドに取り組んでください。

• 更新後の問題を修正する