ss-score

このワークフローの前に、セッションごとに1回実行する更新の事前確認を行ってください。

デザインスコア

レジストリ優先の成果物境界

.styleseed/project.json と .styleseed/artifacts/index.json が存在する場合は、まず要求された成果物 ID を解決してから、.styleseed/bundles/<artifact-id>.md と .styleseed/manifests/<artifact-id>.json のみを読み取ります。レジストリがあるプロジェクトでは、グローバルな旧形式のバンドルにフォールバックしないでください。旧形式のプロジェクトでは、レジストリが存在しない場合に限り、.styleseed/effective-rules.md を使用できます。

決定論的なチェック境界

機能の完成度は、このスコアとは別に扱います。宣言されたユーザーの成果に対して、任意の成果物コントラクト validation.functional.scenarios では、テストを実行して合格する必要があります。詳しくは機能チェックを参照してください。未実施またはスキップされた成果は、見た目の点数で補うことはできません。通常のスコアリングでは、ビルド／テストの実行が許可されたタスクでない限り、機能的な証拠を生成も添付もしません。機能コントラクトのない成果物は、他のゲートに合格していても、機能面では未検証です。

実行可能なコントラクトと安定した診断結果を得るには、正式なチェッカーを実行してください。

node <installed-ss-score>/scripts/styleseed-check.mjs scan \
  --project-root . --artifact <artifact-id> --format json
node <installed-ss-score>/scripts/styleseed-check.mjs scan \
  --project-root . --artifact <artifact-id> --format sarif --out .styleseed/evidence/<artifact>/<run>/deterministic.sarif

チェッカーはスキャンの前に、成果物マニフェスト、バンドル／出力ハッシュ、宣言されたソースルート、プロジェクト内への包含を再検証します。コントラクト／パス／ハッシュ／網羅性のエラーはハードエラーです。ソース検出器は、フィクスチャでの精度が測定され、メンテナーが昇格させるまでは警告のみを出します。安定した検出器 ID は、SS001 がハードコードされた色、SS002 が任意のピクセル値、SS003 が transition-all、SS004 が動きへの視差軽減設定の欠如、SS005 がフォーカスの抑制、SS006 が信頼度の高いラベルなしアイコン操作部品です。決定論的な JSON レポートには detectorRevision、inventoryHash、並べ替え済みの findings のみが含まれるため、呼び出し元が合格を主張する値を渡さなくても、証拠ゲートに添付できます。

証拠を書き込む／ビルドすることが許可されたタスクでは、他のレポートと同じ型付きゲート経由で、生成された JSON を添付します。通常のスコアリングでは、検出結果を報告しますが、証拠は添付しません。

node <installed-ss-score>/scripts/evidence-gate.mjs attach \
  --project-root . --artifact <artifact-id> --run <run-id> \
  --gate deterministic \
  --report .styleseed/evidence/<artifact-id>/<run-id>/deterministic.json

/ss-review は問題点を示します。/ss-score は全体としての品質と最初に修正すべきことを、カテゴリ別の内訳と単一の数値で示すため、テストカバレッジと同じように UI の品質を追跡できます。

使用しない場合

• コミット前に手早く合否を確認する場合 → /ss-lint を使用します
• 詳細な文章による監査と推奨事項が必要な場合 → /ss-review を使用します。修正の適用は、別途許可された実装ステップで行います
• ビジュアル成果物のないロジック／設定の場合 — スコアリングに意味はありません

ステップ 0 — 有効なルールセットを解決する

スコアリングの前に、上記のレジストリ優先の成果物境界を適用してください。レジストリのあるプロジェクトでは .styleseed/bundles/<artifact-id>.md と .styleseed/manifests/<artifact-id>.json を読み取り、ss-resolve --artifact <artifact-id> --check で確認します。不完全または無効なレジストリはエラーであり、旧形式のバンドルやソースハンドブックを使用する理由にはなりません。

レジストリのない旧形式のプロジェクトでは、.styleseed/effective-rules.md と .styleseed/manifest.json を読み取り、ss-resolve --from-lock STYLESEED.md --check を使用します。選択されたバンドルが見つからない場合や古くなっている場合、通常のスコアリングでは再生成せず、証拠の欠落を報告します。ビルド／修正が許可されたタスクでは、対応するプロジェクト所有の設定から /ss-resolve または $ss-resolve を先に呼び出してください。レジストリもロックもない場合は、プロジェクト固有の準拠を主張する前に、対象範囲をユーザーと確認して決めてください。

権威の順序に従ってスコアを付けます。まずコア不変条件、次に正確な出力文法、ドメイン／ページ、ブランドレシピ、任意の美的プロファイル、制限付きロック値の順です。ロックによって不変条件を免除することはできません。不明な値はリゾルバーエラーです。例外を独自に作らないでください。

出力には、次のように有効なルールセットを明記する必要があります。

Rule set: operations-console × SaaS × dashboard × enterprise-workbench × swiss

スコアリング対象

ファイル（またはディレクトリ内の各ファイル）を、デザイン言語に対応する8つの加重カテゴリでスコアリングします。合計は100点です。

カテゴリ	配点	参照先
色使いの規律	16	DESIGN-LANGUAGE §1、§18、§72 ＋ VISUAL-CRAFT §C4
階層とタイポグラフィ	16	§2、§3、§4、§16 ＋ Font Size table ＋ VISUAL-CRAFT §C2
レイアウトとリズム	12	§13、§14、§15、§61 ＋ VISUAL-CRAFT §C1
カードとエレベーション	10	§7、§8、§12、§1 ＋ VISUAL-CRAFT §C3
状態とアクセシビリティ	18	§11、§70、§71、§72 ＋ VISUAL-CRAFT §C3
モーションとインタラクション	6	§24、§59 ＋ engine/motion
一貫性	12	VISUAL-CRAFT §C0（各軸で選択肢を1つ）
独自性	10	Golden Rules 14–16 ＋ VISUAL-CRAFT §CC-9b（汎用的／デフォルト／テンプレート的でないこと）

各カテゴリのスコアリング方法

各カテゴリは満点から始め、コードを確認して見つかった違反ごとに減点します。根拠を明確にし、該当する行を示してください。

色使いの規律（16点） — 次の違反を減点します：構造上ハードブラックを明示的に使用するプロファイルまたは文法の契約外で、意図せず #000／text-black を使用している（1件につき−4点、最大−8点）；装飾的な強調色が競合している（−5点）；UIアイコンとして絵文字を使用している（−5点）；通常／OK／「보통」の状態をニュートラルなグレーではなくステータスカラーで表示している（−4点）；ほとんどの行またはすべての行でステータスカラーを使用している（重要度の階層がない）（−4点）；アクセント／グレーではなく装飾色（金色の星、虹色のカテゴリドットなど）を使用している（−3点）；セマンティックトークンがあるのに16進数カラーコードをハードコードしている（1件につき−2点、最大−6点）；状態を色だけで伝えている（−4点）；選択したドメインに合う色ではなく、ロック解除状態のデフォルトのインディゴ（#5E6AD2／#4F46E5）をアクセントとして使用している（−4点）。

独自性（10点） — 一貫性のある画面でも「AI生成」に見えることがあります。次の違反を減点します：アイコンチップの陳腐なパターン — 汎用的なLucideの線画アイコンを、同じ淡い色付きの角丸四角形に入れて、すべての機能／ステップで繰り返している（−4点、§CC-9b）；製品固有のアイデンティティがないまま、StyleSeedのデモレイアウトをそのままコピーしている（ヒーロー＋チャット／3ステップ／機能グリッド／料金）（−4点）；フォーカルポイントがない — すべて同じ重みで、中央揃えかつ等間隔に配置されたカードによる均一なグリッド（−3点）；ヒーローにこの製品ではなく、ストック画像／プレースホルダー画像を表示している（−3点）；逃げ道を新たなユニフォームにしている（§CC-9c） — すべてのセクションにゴースト表示の01／02／03の番号を置く、または変化のない同一の大文字のオーバーライン＋大きな数字のカードを繰り返している（−2点）；独自性はあるが古びている（§CC-9d） — ページ全体のベースカラーがベージュ／紙色、製品画面で本文にセリフ体を使う、「2026年のプロダクト」ではなく「パンフレット」のように見える濃いブロック（−3点）。最大−10点。

階層とタイポグラフィ（16点） — 次の違反を減点します：値と単位の階層が選択した文法と矛盾している（−4点。コンパクト／等幅の関係や文章的な関係が指定されている場合は有効）；書体の役割がコンパイル済みの契約から逸脱している、またはCSSによって誤ったサイズで表示されている（−5点）；すべて同じ太さで、明確な主役がない（−5点）；本文の行間が狭すぎる、または不適切である（−3点）；デスクトップ／ウェブ向けB2B画面で本文が16px未満（広い画面でモバイル向けの小さい文字サイズを使っている）（−4点。ただし、チャートの目盛り、等幅のSHA／タイムスタンプ、12～13pxのテーブルメタデータなど、密度の高いデータ表示のクロームは対象外です。また、ダッシュボードのアプリクロームにおける22～24pxのh1は適切であり、マーケティング用見出しの40～56pxスケールに反する違反ではありません）。

レイアウトとリズム（12点） — 次の違反を減点します：グルーピングが選択した文法またはレシピと矛盾している（−6点）。operations-console には明示的な機能グループが必要ですが、editorial-reading では無理にカード化しないでください。enterprise-workbench には整列したパネル／行が必要ですが、public-service にはフラットなステップフローが必要です；スケールから外れた任意のスペーシング（−3点）；目的なく同じセクションタイプを繰り返している（−4点）；近接性のリズムが見て取れない（−3点）。 カードとエレベーション（10） — 表層表現に一貫性がない場合や、タスクに適していない場合は減点します。選択した文法／プロファイルで一貫して使用されている場合に限り、ヘアライン、フラットなグルーピング、トーンの段階表現、控えめなシャドウは有効です。ボーダーとシャドウの表現が混在している場合（−4）、シャドウが明らかに濃すぎる、または方向に一貫性がない場合（−4）、文法上必要なグループ／表層の区別が欠けている場合（−5）は減点します。

状態とアクセシビリティ（18） — 次の場合に減点します。データを表示するサーフェスに空、読み込み中、エラーの状態がない（各−5、最大−10。データサーフェスのない静的なモックアップやマーケティング用ランディングページは 対象外（N/A） です。この減点は適用せず、このカテゴリで不合格にしないでください）。本文のコントラスト比が4.5:1未満／大きな文字のコントラスト比が3:1未満（−6）。タッチサーフェスのタッチターゲットが44px未満（ポインタ操作を優先するデスクトップのコントロールは36〜40pxで問題ありません）（−4）。フォーカスが視認できない／outline:none を使用している（−5）。アイコンのみのコントロールに aria-label がない（−3）。

モーションとインタラクション（6） — 次の場合に減点します。名前付きのシード／キーワードを使わず、ランダムまたは場当たり的なフェードを使用している（−3）。コンテンツの表示を遅らせたり、操作をブロックしたりするモーション（−4）。独自のモーションに prefers-reduced-motion への対応がない（−3）。スクロール連動／視差／3D／アニメーション付きグラデーションはサーフェスに依存します（§43）。 アプリ／ダッシュボード／データ／フォームのサーフェスでは禁止です（−5）。マーケティング／ランディング／ブランドページでは許可されます（Cinematic ティア）。この場合、スクロール連動のリビール、固定セクション、3Dヒーロー、アニメーション背景は減点しないでください。減点対象は、スクロールジャッキング（スクロールの乗っ取り／拘束）（−5）、スクロールするまでコンテンツを隠す、または見出し／CTAの表示を遅らせるモーション（−4）、prefers-reduced-motion の代替表示がない場合（−3）のみです。まずページの種類を判定してから採点してください。

一貫性（12） —「各軸で選択は1つ」というルール（VISUAL-CRAFT §C0）を適用します。選択したシステムから逸脱する軸ごとに減点します。レシピと矛盾する角丸の役割（−5。レシピで認められているサーフェス／コントロールの違いは減点しないでください）。強調に2色以上のアクセントカラーが競合して使われている（−4）。シャドウの表現／光源の向きが混在している（−3）。アイコンのファミリー、塗りつぶしモード、または線幅が混在している（−3）。レシピのジオメトリに反する入れ子の輪郭（−2。同心円状の角丸長方形では通常 max(0, outer − padding) を使用します）。説明のないコントロールの高さのばらつき（−2）。このカテゴリは「AI生成のように見える」かどうかを最もよく予測します。コンポーネント単体の見栄えではなく、システム全体の一貫性を示す証拠を重視してください。

各カテゴリの点数は0を下限とします。合計点を算出してください。

出力形式

## Design Score: 70 / 100   (src/app/Dashboard.tsx)
Rule set: operations-console × product-ui × SaaS × dashboard × enterprise-workbench × swiss

████████████████░░░░░░  C-

Color discipline      11/16   ▓▓▓░  competing orange+blue emphasis hues (l.28-34)
Hierarchy & typography 13/16  ▓▓▓▓  number/unit 1:1 on hero (l.18)
Layout & rhythm         9/12  ▓▓▓░  two identical KPI rows (l.22-31)
Cards & elevation       8/10  ▓▓░░  mixed border + floating-shadow language (l.22)
States & a11y          11/18  ▓▓░░  no empty/loading state; focus ring missing (l.55)
Motion & interaction    4/6   ▓▓▓░  default fade, not a named seed
Coherence               6/12  ▓▓░░  control shape drifts from enterprise-workbench (l.48); competing accents
Distinctiveness          8/10  ▓▓▓░  all-even KPI grid weakens the operational focal panel

### Fix first (highest score gain)
1. Add empty + loading states to the orders list       → +7 states (§71)
2. Restore locked control geometry and primary-action hierarchy → +9 coherence+color
3. Restore recipe-bound hairlines; remove unrelated floating shadows → +4 cards

Re-score after: ~92 / 100.

評価には次の文字を使用します。90以上：A · 80〜89：B · 70〜79：C · 60〜69：D · 60未満：F。

ゲートモード（UIをユーザーに提示する前に、品質ゲートとして使用）

ゲートモードは、許可されたビルドまたは修正タスクで適用します。通常の採点では、実装や設定を変更しません。低い点数は、編集を開始する許可を意味しません。

1. 生成直後のUIを採点します。
2. 80未満の場合、所見を許可された実装ステップに戻し、修正後に再採点します。/ss-review は所見の説明に使用できますが、読み取り専用です。編集ステップではありません。
3. 80以上に達するか、修正と再採点を最大3回行った時点で終了します。スキルを切り替えて試行回数をリセットしないでください。権限の境界に達した場合や、依存関係が利用できない場合は、それ以前に終了してください。
4. ゲートを通過できなかった場合も、実際の点数、修正内容、未解決の問題を報告します。未完了の作業は、承認済みや出荷準備完了ではなく、失敗またはブロックとして示してください。

合格基準は下限であり、上限ではありません。80以上に達したら終了し、100を追い求めないでください。ゲート不合格の報告は必須ですが、リリースの承認を意味するものではありません。総合点が合格していても、重大な問題が免除されたり、人間による承認が成立したりするわけではありません。

ルール

• ファイルを読みます — 実際の根拠（行番号）に基づいて採点し、推測はしません。
• 必須フローの破損やアクセシビリティ／コア機能の重大な問題を最初に解決し、その後、影響度と作業量に応じて残りの改善に優先順位を付けます。契約を犠牲にして数値を最適化しないでください。
• ディレクトリの場合は、ファイルごとに1行でスコアを表示し、スコアが最も低いファイルの詳細な内訳を示します。
• 通常の採点では自動編集しません。/ss-score は測定し、/ss-review は改善を提案します。Gate モードでは、編集は許可された実装ステップが担当します。
• ゲートとして、合格を主張するには80以上が必要ですが、不合格の結果を報告するためには必要ありません。必要なチェックに合格した後、95から100への引き上げを追い求めて完了を遅らせないでください。