ss-verify

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

検証（読むだけでなく、実際に確認する）

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

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

レジストリファイルのいずれかが存在する場合は、完全かつ有効なレジストリを必須とします。上記の選択したアーティファクトのバンドルとマニフェストを読み取り、ss-resolve --artifact <artifact-id> --checkで確認してください。 不完全または無効なレジストリはエラーであり、レガシーバンドルを読み取ったり、セットアップを再開したりする許可にはなりません。影響を受ける各アーティファクトを、それぞれに必要なレンダリングと検証コントラクトに照らして検証してください。

どちらのレジストリファイルもないプロジェクトでのみ、.styleseed/effective-rules.mdと.styleseed/manifest.jsonを使用し、ss-resolve --from-lock STYLESEED.md --checkで確認してください。 許可されたビルドまたは修復中に、選択したバンドルが欠落しているか古くなっている場合は、対応するプロジェクト所有の設定から/ss-resolveまたは$ss-resolveを実行してください。検査のみのモードでは、バンドルを書き換えたり、現在の適合性を主張したりせず、その状態を報告してください。 レジストリもロックもない場合は、適合性を主張する前に対象範囲を確定してください。ピクセルはコンパイル済みの手法に照らして評価してください。 ロック値を根本的な不合格の言い訳にすることはできません。また、レシピやプロファイルで出力文法を置き換えることもできません。

/ss-scoreはコードを読み取り、採点します。しかし、最悪の「AI製らしさ」の兆候の中には、ソースに現れず、ピクセルにしか存在しないものがあります。実際には目立っていないヒーロー領域、下部3分の1に広がる無駄な余白、窮屈なカード、読み込みに失敗して気づかれないままTimesにフォールバックしたWebフォント、レンダリング後に2色のアクセントとして見えてしまう色、実際の背景上では読めないテキストなどです。人間なら一瞬で気づきますが、コードを読むだけのゲートではこれらを見逃します。

/ss-verifyはそのギャップを埋めます。UIをレンダリングしてスクリーンショットを撮り、その画像を目で確認します。その後、同じStyleSeedゲートで見た目を採点し、修正して再レンダリングします。実際のユーザーが「デザインされている」と感じるかどうかを最もよく予測するゲートです。

ビルド中は、/ss-scoreの後に最終ゲートとして実行してください。スクリーンショットやピクセルを直接検査する場合、新たにコード採点のループを行う必要はありません。コードの証拠が得られない場合は、未確認として報告してください。

検査と修復の範囲

修正も許可されていない限り、検査、検証、報告の依頼は検査のみを行います。製品のソース、設定、実際のユーザーデータを変更せず、一時的なワークスペースでレンダリングとキャプチャを行ってください。不合格であっても、確認結果を報告してください。状態の確認には既存のテスト用フィクスチャを使用してください。空状態のスクリーンショットを撮るために、稼働中のデータベースを空にしてはいけません。

許可されたビルドまたは修復では、対象範囲内の実装上の不具合のみを修正し、再レンダリングしてください。承認済みのアイデンティティを変更したり、スコアを上げるために根本的な基準を緩和したりしないでください。ツールがない場合やゲートに失敗した場合は、合格を捏造したり無関係なインストールを行ったりせず、正直に報告してください。

使用しない場合

• 視覚的な成果物を伴わない純粋なロジック／設定 → デザインスコアではなく、適切な機能／設定チェックを使用します。ホストがないレンダリング可能なコンポーネントには、以下の一時的なハーネスを使用できます。
• まったくレンダリングできない場合（ブラウザーがない、Playwright がない、ヘッドレス実行がブロックされている）→ その旨を伝え、/ss-score に切り替えて、視覚ゲートをスキップしたことをユーザーに伝えます。スクリーンショットを実際に見ていない場合、視覚的に確認したと決して主張しないでください。
• コミット前の簡易チェック → /ss-lint を使用します。/ss-verify はレンダラーを起動するため、より負荷がかかります。

コンパイル済みの空間コントラクトについては、spatial roles guide に従ってください。 設定済みの空間コントラクトについては、ガイドに従い、宣言されているすべてのロールに明示的なバインディングを指定して、インストール済みの scripts/inspect-spacing.mjs ブラウザー関数を実行してください。失敗や未対応の測定は視覚チェック合格ではなく未解決として扱い、コンテンツの観察結果も確認してください。必須の狭い／広いビューポートで、実際の間隔、インセット、トークンの解決、グループ化、繰り返しの配置、オーバーフロー、読み込み／エラー時のレイアウトを確認してください。スクリーンショットとジオメトリの両方を確認してください。数値上の適合だけでは、リズムの良さや人による評価は判断できません。修正時は、無関係な間隔を維持してください。

ステップ 1 — アクティブなアダプターでレンダリングする

social-carousel、slide-deck、document-report、または single-frame の場合は、付属のレンダラーを使用し、必要なエクスポート済みのフレーム／ページをすべて、判読できる解像度で開きます。寸法、トリミング／セーフゾーン、フォントの利用可否、アセットの配置、エクスポートマニフェストを確認してください。PIL、スライド、PDF、または画像のレンダラーに、ブラウザーのワークフローを無理に適用しないでください。

product-ui の場合は、次の優先順位で実際のスクリーンショットを取得します。

A. 実行中のプロジェクト（Next / Vite など）— 通常のケースです。

1. 開発サーバーをバックグラウンドで起動し（npm run dev / pnpm dev / フレームワークのコマンド）、起動完了の行を待ってポートを記録します。
2. Playwright 経由でヘッドレス Chromium を使い、ルートのスクリーンショットを撮ります。プロジェクトの node_modules に playwright があればそれを使用し、なければグローバルキャッシュの Chromium を使用します。最小限のスクリプト：

   import { chromium } from "playwright";           // or an absolute path into node_modules
   const b = await chromium.launch();
   const c = await b.newContext({ viewport: SURFACE, deviceScaleFactor: 2 });
   const p = await c.newPage();
   await p.goto(URL, { waitUntil: "networkidle" });
   await p.evaluate(() => document.fonts.ready);      // don't shoot before fonts load
   await p.waitForTimeout(400);
   await p.screenshot({ path: OUT, fullPage: true });
   await b.close();
   

   サーフェスのビューポート： モバイル {width:390,height:844} · デスクトップ {width:1440,height:900}。ロックの Surface または --surface から選択します。
3. 代わりにブラウザー MCP（claude-in-chrome）が利用できる場合は、それを使って移動し、スクリーンショットを撮ります。

B. 静的 HTML ファイル → file://… で直接開き、スクリーンショットを撮ります（同じスクリプトを使用）。

C. 独立したコンポーネント（ホストページなし） → コンポーネントをインポートして現実的な props を渡す、最小限の使い捨てページにレンダリングし、スクリーンショットを撮ります。

その後、スクリーンショットを実際に読み込んでください（PNG を読み込みます）。必ず目で見てください。テキストを鮮明にして判断できるよう、deviceScaleFactor: 2 で撮影します。

ステップ 2 — 目で見たものを評価する（視覚ゲート）

画像を見て、StyleSeed ゲートを知覚的に評価します。以下は、ソースだけではなく目視が必要なチェック項目です。

□ Squint test    — blur your focus / imagine it at 50%. Does it still read "AI-generated"?
                   (bland gradient, pill button + generic sans, icon-chip row, even flat grid) → FAIL
□ Focal          — does ONE element actually dominate at a glance? If your eye lands nowhere,
                   or on an all-even grid, the focal point failed regardless of what code intended
□ Balance        — dead whitespace (a lower third of empty), or cramped/colliding elements?
                   Is the visual weight distributed, or all top-left / all-centered?
□ Fonts loaded   — is the intended typeface actually rendering, or a Times/Arial fallback?
                   (a silent font-load fail is a top "looks cheap" tell — invisible in code)
□ One accent (seen) — count the hues you actually SEE. Two things competing for "the color" = FAIL,
                   even if the code named one token
□ Contrast (seen) — any text you have to strain to read on its real rendered background?
                   Light-grey-on-white labels, low-contrast on a colored/照片 panel
□ Rhythm/optics  — are edges aligned, gaps consistent, cards optically even? Off-by-a-few-px
                   misalignments that read as "sloppy" but pass a code check
□ Type scale fit — on desktop, does the body text look too small for the canvas? does the hero
                   feel undersized? (the surface-scale tell, judged by eye)
□ Grammar fit   — does the screen visually serve the selected grammar's user job, attention
                   model, composition, density, action hierarchy, and characteristic tells?
□ Recipe fit    — do geometry, containment, controls, collections, navigation, density, and
                   motion visibly match the selected recipe rather than the old universal soft-card look?
                   Would the same layout still appear if the product changed? If yes, FAIL
□ Motion (if any) — capture before/after or a mid-transition frame; is it purposeful, or the
                   "cheap fade/bounce on everything" tell? does it block the first read?

ステップ 3 — 状態やシーケンスのバリエーションもレンダリングする

正常系のスクリーンショットでは、実際によく起こる失敗、つまり空／読み込み／エラー状態がないことが見落とされます。サーフェスにデータビューがある場合は、テスト用フィクスチャ、既存のプレビュー用クエリパラメーター、または一時的なハーネスの props を使ってこれらのバリエーションをレンダリングし、それぞれのスクリーンショットを撮ります。「データなし」のときに何もない白い画面が表示される不具合は、空の状態を見ることでしか見つけられません。（データサーフェスのない静的なマーケティングページは → 該当なし。メモに記録します。）

連続する成果物については、カバー／最初のフレーム、すべてのコンテンツフレーム、最後のフレーム／CTA を一式として確認します。一貫性、展開、フレームごとのメッセージが 1 つであること、テンプレートの繰り返しによる単調さ、ソースラベル、ページ番号、安全領域が保たれていることを確認してください。ドキュメント／デッキについては、すべてのページ／スライドに加え、代表的なサムネイルまたは概要ビューも確認してください。

ステップ 4 — 修正して、再レンダリングし、繰り返す

検査のみのモードでは、編集せずに指摘事項と証拠を返します。修正が許可されている場合は、 コードを修正してから、再レンダリングしてもう一度確認します。合格した場合、修正とレンダリングを最大 3 回行った場合、または権限やツールの問題が発生した場合に停止します。スキルを切り替えても上限をリセットしないでください。 画像が利用可能な場合は最新の画像、有効なルールセット、変更内容、ゲートの状態、未解決の問題を必ず報告してください。失敗した結果をレビュー用に提示してもかまいませんが、合格と表示してはいけません。

ルール

• レンダリングされた成果物を実際に確認してください。 レンダリングしなければ、視覚的な判定はできません。/ss-score にフォールバックし、視覚ゲートをスキップしたことを伝えてください。「問題なさそうです」と捏造してはいけません。
• 修正するたびに再レンダリングしてください。 このスキルが存在する理由は、ソースとピクセルが食い違うためです。差分を読んで視覚的な修正を検証するのでは、本来の目的を果たせません。
• ビルドゲートは次の順で実施します。 まず /ss-score（コード）を実行して、構造上の問題を低コストで検出します。最後の基準として /ss-verify（ピクセル）を実行します。/ss-build はループ内でコードゲートを実行します。レンダリング可能な画面を仕上げるには、/ss-verify を完了してください。
• 後片付け： 自分が起動した開発サーバーのみを停止し、自分が作成した一時的なハーネスファイルのみを削除してください。
• 2×で撮影し、固定されたサーフェスのビューポートを使用してください。 デスクトップアプリを幅 390px の画像で評価したり（またはその逆を行ったり）すると、文字スケールとバランスのチェックが無効になります。