ss-update

このワークフローを開始する前に、セッションごとに1回の更新前チェックを実行してください。

StyleSeed の更新

レジストリ優先のアーティファクト境界

.styleseed/project.json と .styleseed/artifacts/index.json が存在する場合は、まず要求されたアーティファクト ID を解決し、その後 .styleseed/bundles/<artifact-id>.md と .styleseed/manifests/<artifact-id>.json のみを読み取ってください。レジストリを持つプロジェクトでは、グローバルなレガシーバンドルにフォールバックしてはいけません。レガシープロジェクトでは、レジストリが存在しない場合に限り .styleseed/effective-rules.md を使用できます。

ユーザー向けの製品 UI ではなく、エンジンのペイロードを更新してください。リリースバージョンは公開済みの系列を示し、engineRevision は保守対象のルール、スキル、エントリードキュメント、パレットエンジンを正確に特定します。リビジョンが一致するまでは、同じリリースバージョンの2つのインストールが同一であるとは確認できません。

チェッカーは、アクティブなインストールチャネルのペイロードを検証します。リポジトリ／プラグインのチェックアウトでは完全な core インベントリを使用し、プロジェクトローカルの Agent Skills インストールでは実行可能な skills インベントリを使用します。公開エンドポイントには、エンジンの revision と、skills のみのインストールの場合は skillsRevision の両方を公開する必要があります。プロジェクトマニフェストには引き続き、メソッドバンドルのコンパイルに使用したエンジンリビジョンを記録します。

バンドルされたカタログには distributionSource.channel も記録されています。edge は変化する公開リポジトリの状態を参照し、stable は最新の公開リリースマニフェストを参照します。ユーザーが明示的にチャネルの切り替えを要求しない限り、stable アーカイブを edge の main と直接比較しないでください。

使用しない場合

• 初回インストール → /ss-setup または $ss-setup。
• 新しい画面またはコンポーネントを1つ作成する場合 → /ss-build、/ss-page、または /ss-component。
• 古い UI を再設計する場合 → まず更新し、その後、以下の任意のレトロフィット手順を提案してください。
• 大幅にフォークされた StyleSeed ペイロード → ドライランのレポートを提示した時点で停止し、手動での差分確認を依頼してください。

所有範囲

StyleSeed が所有するのは、インストール済みの ss-* スキルペイロードと、コンパイル済みの .styleseed/effective-rules.md です。プロジェクトが所有するのは、STYLESEED.md、アプリケーションコード、コンポーネント、トークン、アセット、および既存の AGENTS.md、CLAUDE.md、Cursor の指示です。StyleSeed の更新だけを目的として、プロジェクト所有のファイルを上書きしてはいけません。

更新によって、特にメジャーバージョン間では、デザインメソッドの動作が変わる場合があります。ユーザーのバージョン管理を通じて元に戻すことはできますが、すべての更新が追加的、または非破壊的であると約束するのは適切ではありません。

Step 1 — 読み取り専用のリビジョン確認

ユーザーのプロジェクトルートから、インストール済みのパスを指定して同梱チェッカーを実行します。

node <installed-ss-update>/scripts/check-update.mjs --project-root . --json

結果を正確に解釈します。

• current — インストール済みリビジョン、公開済みリビジョン、既存のレジストリアーティファクトが一致しています。ユーザーが明示的に再インストールを希望していない限り、ここで終了します。これはビジュアル／エビデンスの確認ではありません。
• update-available — セマンティックバージョンが一致していても、インストール済みペイロードを更新します。
• project-bundle-stale — スキルは最新です。再インストールはスキップし、プロジェクトを再解決します。
• legacy-skill-conflict — 廃止済みのスタンドアロンの7カテゴリレビュアーが、正規スキルと並存しています。そのパスとハッシュを提示し、プロジェクトによって変更されたスキルではないと確認してから削除します。
• remote-check-unavailable — リモートリクエストに失敗しました。「最新」ではなく、不明と報告します。
• project-config-invalid — 最新であると主張する前に、不完全または無効なレジストリを修復します。
• installed-revision-unverified / installed-revision-tampered — ローカルのペイロードを調査します。フォークを確認せずに上書きしてはいけません。
• remote-revision-unavailable — バージョンだけのエビデンスでは最新であると証明できません。確認可能な範囲を報告し、「最新」とは言わないでください。

レジストリプロジェクトでは、ソート済みの artifacts 配列も読み取ります。そのステータスは、現在のアーティファクト契約、マニフェスト、宣言された出力バイト、インストール済みカタログに基づいて、その都度算出されます。

• current — メソッド、検証契約、出力バイトが引き続き一致しています。
• corrupt — 宣言されたバンドル／パレットが欠落しているか、そのバイトが一致しません。
• method-changed — 再コンパイルし、すべての実装／レンダリングのエビデンスゲートを再実行します。
• validation-changed — 報告された場合に限り再コンパイルし、stale とマークされたゲートを再実行します。
• metadata-changed — インストール済みエンジンのメタデータに合わせて再コンパイルします。メタデータのみの変更では、変更されていないビジュアルエビデンスは無効になりません。
• legacy — アーティファクトレベルで最新であると主張する前に、アーティファクトを移行します。

changedInputs には、現在の正規化済みバイトがマニフェストと異なるプロジェクト所有の入力が示されます。以前の検証詳細を利用できない場合、チェッカーは影響を受ける可能性のあるすべてのゲートを stale とマークして安全側に倒します。ダイジェストから正確なフィールドレベルの履歴を推測することはありません。

git status --short も確認します。この手順ではファイルを変更しないでください。

Step 2 — 更新範囲を報告する

何かを変更する前に、次の内容を報告します。

StyleSeed update report
- Installed: <version> @ <revision>
- Installed channel: <stable|edge|legacy-edge>
- Installed payload: <core|skills> @ <distribution revision>
- Published: <version> @ <revision>
- Project bundle: <version/revision or not resolved>
- Project worktree: clean | has existing changes
- Will refresh: canonical ss-* skill payloads
- Will preserve: STYLESEED.md, app code, components, tokens, assets, project instructions
- Requires review: compiled rule-bundle diff and any copied legacy engine docs

ワークツリーに無関係な変更がある場合は保持します。メソッドの更新前にコミットまたはバックアップを推奨しますが、破壊的な reset/checkout コマンドを更新方法として使用しないでください。

Step 3 — 元のインストール経路で更新する

StyleSeed のインストールに使用したものと同じ経路を使用します。

• Edge Agent Skills CLI でのインストール：返された installed.install コマンド（通常は npx skills add bitjaru/styleseed）を実行し、同じプロジェクト／プロバイダースコープを選択します。
• Stable Agent Skills CLI でのインストール：チェッカーから返された正確な最新公開アーカイブ URL を使い、npx skills add <remote.archiveUrl> --agent codex --yes --copy を実行します。
• Claude／プラグイン、または別のプロバイダーマーケットプレイス：そのプロバイダーの通常の更新操作を使用します。
• ベンダー提供のソースチェックアウト：対象のタグまたはコミットを取得し、差分を確認して、正規エンジン全体をまとめて更新します。異なる2つのリビジョンのファイルを混在させないでください。

既存のスキルディレクトリへの無条件な再帰コピーで更新してはいけません。インストーラーによって管理対象ペイロードを調整する必要があります。プロジェクト所有のファイルは、その操作の対象外にします。更新時に stable を edge に、または edge を stable に黙って切り替えないでください。

このスキルが利用可能状況の確認だけを目的に呼び出された場合は、外部更新を行う前に停止し、レポートを提示します。

Step 4 — インストール済みリビジョンを証明する

新しいチェッカーのパスを再度実行します。エンジンを最新と説明する前に、インストール済みと公開済みの engineRevision の値が一致することを確認します。バージョン文字列が一致するだけでは証明になりません。

インストール済みペイロードが古いリビジョンを報告する場合は、停止します。混在している、または未検証のインストールからプロジェクトを再コンパイルしてはいけません。

Step 5 — プロジェクトコンテキストを再コンパイルする

レジストリプロジェクト（.styleseed/project.json と .styleseed/artifacts/index.json）の場合：

1. 結果に bundleRecompileRequired:true が含まれる各アーティファクトを、resolve-context.mjs --project-root . --artifact <id> --agent <agent> で再解決します。
2. 同じコマンドを --check を付けて実行し、終了ステータスが 0 であることを確認します。
3. current と報告されたアーティファクトは保持します。1 つのアーティファクトを更新するために、すべてのバンドルを上書きしないでください。

レガシープロジェクトで STYLESEED.md が存在する場合：

1. インストール済みの ss-resolve/scripts/resolve-context.mjs を、--project-root . --from-lock STYLESEED.md --agent <agent> を付けて実行します。
2. .styleseed/effective-rules.md、.styleseed/manifest.json、生成されたパレットファイルの差分を確認します。マニフェストには新しい engineRevision が記録されている必要があります。
3. 同じコマンドを --check を付けて実行し、終了ステータスが 0 であることを確認します。
4. 古いバンドルと新しいバンドルのハッシュを報告します。プロジェクトコンテキストとして llms-full.txt を使用しないでください。

デザインロックは選択内容を保持しますが、新しいエンジンリビジョンによって、選択内容を反映するコンパイル済みの手法が適切に変更される場合があります。その差分を隠さず提示してください。

Step 6 — コピーされたレガシードキュメントを確認する

古いプロジェクトには、コピーされた DESIGN-LANGUAGE.md、PRODUCT-PRINCIPLES.md、RULESETS.md、またはプロバイダーのエントリファイルが含まれている場合があります。検出して報告してください。プロジェクトの AGENTS.md、CLAUDE.md、.cursorrules は上書きせず、レビュー後に、StyleSeed が管理していると特定できるブロックだけを置き換えるか、古くなった重複メソッドファイルを削除するよう推奨してください。

任意のレトロフィット

エンジンを更新しても、既存の画面が再設計されることはありません。ユーザーがレトロフィットを希望する場合：

1. レジストリプロジェクトでは、選択されたアーティファクトとプロジェクト所有の設定を解決します。レジストリファイルがどちらも存在しない場合に限り、レガシーの STYLESEED.md を確認または作成します。不完全または無効なレジストリはエラーであり、フォールバックではありません。
2. 最もトラフィックの多い画面を、新しい有効なバンドルに照らして再採点します。
3. 読み取り専用の所見には /ss-review または $ss-review を使用し、承認済みの修正は許可された実装ステップで適用します。
4. /ss-verify または $ss-verify を使ってレンダリングし、確認します。
5. 旧スコアが実測されていないのに測定済みだと主張せず、変更前後の証拠を報告します。

合格した時点、または各ゲートにつき修正を 3 回行った時点で停止します。委任した修正も回数に含めます。残っている失敗と実際の証拠を報告してください。別のスキルを呼び出しても、この回数はリセットされません。

完了レポート

以下の状態を分けて報告してください。

• インストール済みリビジョン：検証済み | 未検証；
• プロジェクトバンドル：再コンパイル済みでハッシュ確認済み | 古い | 存在しない；
• アプリケーションコード：変更なし | 明示的にレトロフィット済み；
• コードゲート：合格 | 未実行；
• ビジュアルゲート：レンダリングを確認して合格 | 未実行。

インストール、コンパイル、ビルド、またはスコアをビジュアル検証と呼ばないでください。