sb-ship

sb-ship — 履歴を保持して昇格させる

Explore のイテレーションが昇格条件を満たしたときにイベントトリガーされます。重要なルールは 1つだけです。実験を保持すること — cp を使い、git mv は使わないでください。 Explore のストーリーは設計履歴として残します。 ここでの git mv は、propagate-workflow.md が防ぐために存在する破壊的なバグです。Ship のアクションを実行する前に references/propagate-workflow.md を読み込んでください — このスキルで必要なリファレンスはこれだけです。Ship では sb-wrappers/sb-audit のリファレンス（ライフサイクル、ギャラリー、構成）は読み込まないでください。

パスを決める（自分に問いかける）

• Explore で独自のコンポーネントファイルを定義しましたか。それとも既存のものを反復しましたか。 → パス A とパス B のどちらかです。
• パス B：その場で進化させますか（B1）、それとも V1 を _legacy/ に残しますか（B2）。 B2 を選ぶのは、移行期間が必要な現行の呼び出し元が V1 にまだある場合だけです。
• インポートパスは変わりましたか。 変わった場合 → 呼び出し元を ast-grep で検索します。変わっていない場合 → スキップします。
• 切り替えるべき、ほかのタグ付きストーリーはありますか。 （Compare の decision:pending を decision:chosen + 採用案に変更するなど。）

実行する

• パス A — 新規コンポーネント。 コンポーネントを Explore から components に cp し、記録されている storiesLocation（.storybook/audit/status.md。ルールは CONTEXT.md §STORIES LOCATION に記載されています — 分散させないでください）に新しい本番用ストーリーファイルを作成します — Explore のストーリーを cp しないでください（本番には異なる要件があります。autodocs、decision メタデータなし）。その後、検証し、パスが変わった場合に限り呼び出し元を ast-grep で検索します。
• パス B — 既存のものを更新。 Explore での差分を、本番用コンポーネントとストーリーにその場で反映します。インポートパスが変わった場合に限り ast-grep を実行します。
• どちらのパスでも — その場で一連の作業を完了する（git mv は使わないでください）： tags: ['explore','decision:chosen','archived','!autodocs','!test'] + parameters.decision = { status, winner, date, shippedTo }。find-stories-by-tag.sh decision:chosen で確認します。

ゲートと次の手順

新しい本番用ストーリーに、同梱の scripts/validate-stories.sh を実行します（バンドル内： ${CLAUDE_PLUGIN_ROOT}/scripts/validate-stories.sh または ${CLAUDE_PLUGIN_ROOT}/scripts/）。scripts/find-stories-by-tag.sh decision:chosen で切り替わったことを確認します。決定を台帳（templates/design-decisions.md）に追記します。昇格した実験はそのまま残します。

使用状況のフローに戻ります。 昇格したコンポーネントは src/ に追加されたばかりです — まだレンダリング済みの JSON には含まれていないため、Docs の「実際の使用状況」セクションと storyCoverage は空欄です。1コマンドで使用状況を更新する処理（refresh-usage.sh。sb-audit/sb-inventory が管理）を実行し、新しいコンポーネントを component-usage.json / project-inventory.json に追加します。Storybook を再ビルドすると、実際の使用状況が表示されます。その後、/sb-hub を実行します。