ss-build

このワークフローを始める前に、セッションごとに一度だけ更新の事前確認を実行してください。

合成された StyleSeed メソッドで構築する

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

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

ビルドメソッドこそが成果物です。スコアやスクリーンショットは補助的な根拠であり、デザイン判断の根拠ではありません。

ステップ 1 — コードを書く前にルールセットを確定する

.styleseed/project.json または .styleseed/artifacts/index.json のいずれかが存在する場合は、完全で有効なレジストリを必須とし、インストール済みリゾルバーの scripts/resolve-context.mjs --project-root . --artifact <artifact-id> --agent <agent> を使って要求されたアーティファクトを解決してください。 .styleseed/bundles/<artifact-id>.md を読み込み、.styleseed/manifests/<artifact-id>.json を出所情報として保持してください。レジストリが不完全または無効である、あるいはコンパイル済みの出力がないという理由で、STYLESEED.md を作成したり、セットアップを再開したり、レガシーバンドルを使用したりしないでください。不足しているスコープはユーザーに確認してください。複数のアーティファクトにまたがる変更では、影響を受ける各アーティファクトを個別に解決して確認してください。

どちらのレジストリファイルも存在しない場合に限り、レガシーの手順を使用します。STYLESEED.md がない場合は、UI コードを書く前に /ss-setup を実行してください。存在する場合はそのまま保持してください。--from-lock STYLESEED.md --agent <agent> を指定して /ss-resolve（Claude Code）または $ss-resolve（Codex）を呼び出し、.styleseed/effective-rules.md を読み込み、.styleseed/manifest.json を保持してください。

提示されたビジュアルリファレンスが選択したグラマーに反映されていない場合は、選択したプロジェクトの境界内で /ss-reference を使用してください。不慣れなリファレンスを単なるパレットの差し替えに矮小化したり、人の承認なしに承認済みのプロジェクト設定を置き換えたりしないでください。解決が成功した後に llms-full.txt を読み込まないでください。

ステップ 2 — 即興せずに組み合わせる

コンパイル済みバンドルでは、すでに権限の順序が構成されています。コア不変条件 → 選択したグラマー → サーフェスアダプター → ドメイン／ページ → ブランドレシピ → 任意のプロファイル → 範囲が制限されたロック → クラフトのベースライン、の順です。マニフェストの選択内容とソースハッシュを使ってドリフトを検出してください。バンドルで実質的な曖昧さが示されている場合に限り、完全なソースドキュメントを開いてください。ハンドブックをその場しのぎで再構成しないでください。

コードを書く前に、次の例のように、有効なルールセットを 1 行で示してください。

operations-console × SaaS × dashboard × enterprise-workbench × swiss × locked brand tokens

矛盾は権限の優先順位に従って解決してください。プロファイルやロックで、タスクへの適合性、一貫性、アクセシビリティを免除することはできません。

ステップ 3 — デザイン判断を活かして構築する

• 最初のビューポートで、グラマーにおけるユーザーの目的と主要な判断が分かるようにします。
• 1 つの焦点を設け、同じ重みのテンプレートグリッドは避けます。
• グラマーの構成、密度、タイポグラフィ、色、サーフェス、画像／データ、アクション、状態、レスポンシブ、モーションの各契約を使用します。
• レシピの包含、形状、コントロール、コレクション、ナビゲーションの形態を使用します。バンドルされたパターンコンポーネントを使用する場合は、アーティファクトのルートに data-styleseed-recipe="<id>" を設定します。
• プロダクト固有のコンテンツと根拠を使用します。StyleSeed のデモやリファレンス画面をコピーしないでください。
• 関連する箇所には、読み込み中、空、エラー、フォーカス、モーション低減、レスポンシブの各動作を実装します。

スペーシング作業では、リゾルバーの空間ロールガイドを使用してください。間隔を選ぶ前に、コンパイル済みの spacing セクションがあれば必ず読み込んでください。そのスコープ付き変数を既存のコンポーネントに割り当て、宣言されていないロールは保持してください。関連するコンテンツを意図的にグループ化し、ネストされたインセットを重ねたり、密度を上げるために文字を小さくしたりしないでください。実装では変数を実際に使用する必要があります。設定だけでは、レンダリングされるレイアウトは変わりません。

ステップ 4 — コードゲートループ

対話型の作業では、テストの前にユーザーが達成すべき結果を明示します。たとえば、保存した設定が再読み込み後も保持される、保存に失敗しても下書きが保持される、または閲覧者が編集者向けの操作を実行できない、といった結果です。プロジェクトの実際の実装とテストツールを再利用してください。切り離されたデモやソーステキストのアサーションでは、その操作が機能することを証明できません。

レジストリビルドでは、該当する結果を成果物内の validation.functional.scenarios として記録し、テストとその実装依存関係を implementation.sourceRoots で対象にします。インストール済みの ss-score のリファレンス references/functional-checks.md を使用して、エビデンスを取得し、保持してください。必須シナリオが失敗、スキップ、未設定、または未実行の場合、コードスコアが高くても完了とはみなされません。利用可能なランナーでプロジェクトを実行できない場合は、未検証の結果を正確に報告してください。合格を得るために、その要件を省略してはなりません。静的な成果物では、該当しないことを明示して、機能シナリオを省略できます。

実際の実装に対して /ss-score を実行します。スコアには有効なルールセットを明記し、コア不変条件と文法固有の特徴の両方をチェックする必要があります。効果の大きい不合格項目から修正し、修正パスは最大 3 回まで再採点します。ただし、80 以上に達した場合は、それより前に終了します。任意のスコア向上よりも、壊れたフローとコアの不合格項目を優先してください。合格できない場合は、実際のスコアと残りの不合格項目を報告します。別のスキルを呼び出して、パスの上限をリセットしてはなりません。

ステップ 5 — ピクセルゲートループ

描画可能なすべての成果物に対して /ss-verify を呼び出します。アダプターレンダラーを使用し、必須のすべてのビューポート／フレーム／ページと関連する状態を確認し、視覚的な不具合を修正して再レンダリングします。利用可能なレンダラーがない場合は、ビジュアルゲートをスキップしたと明記してください。合格したと示唆してはなりません。

ステップ 6 — エビデンスを添えて提示

以下を報告します。

• 有効なルールセットと、それが適している理由
• 最終的なコードスコア
• ビジュアル検証の状態とビューポート
• ゲートで行った重要な修正
• プロジェクト／成果物の設定パス（またはレガシーな STYLESEED.md）と、コンパイル済みの文法パス

ルール

• コードより先に文法を定めます。ビルド後にコードゲートを実行し、最後にピクセルゲートを実行します。
• 出力文法は機能的なものです。ブランドレシピは形態的なものです。美的プロファイルは任意です。いずれも文法の代わりにはならず、ブランドのクローンを許可するものでもありません。
• 主なアクションは識別可能な状態を維持する必要があります。追加の色を使えるのは、文法によって安定した意味上または分類上の意味が与えられている場合に限ります。
• UI を変更するたびに、ロックと文法を読み直してください。