finalize

コンテキスト： このサブスキルは、より広範な ui-craft スキルを構成する一つの視点です。ui-craft スキルもインストールされている場合は、まずその SKILL.md を読み、Discovery + Anti-Slop + Craft Test を確認してから、以下の特定の視点を適用してください。

ui-craft スキルを読み込みます。このコマンドでは検出結果のみを出力します。コードは編集しないでください。

---

ステップ 1 — ブリーフの確認（ゲート）

.ui-craft/brief.md を探します。

• 存在しない場合：停止します。次のメッセージを出力します："No brief found. Run /brief first. /finalize requires a design brief to distinguish intentional decisions from findings." 以降の手順には進まないでください。
• 存在する場合：読み込みます。原則を抽出します（番号付きで、競合解決の優先順に並べます）。これらはステップ 4〜5 の上書きレジストリになります。

---

ステップ 2 — 検出

$ARGUMENTS（引数がない場合は現在の作業対象）に対して npx ui-craft-detect を実行します。

出力をすべて記録します。検出結果の Critical はすべて、レポートで出荷をブロックする指摘に直接対応させます。検出元のラベルはそのまま保持します。

---

ステップ 3 — トークンの確認

次の 3 つの質問で簡易監査を行います（詳細な読み込みは不要です）。

1. トークンの 3 層（プリミティブ → セマンティック → コンポーネント）がすべて揃っていますか？
2. ライトモードとダークモードは、反転ではなく、どちらも明示的に定義されていますか？
3. トークンの 7 カテゴリ（色、間隔、角丸、シャドウ、タイポグラフィ、モーション、z-index）がすべて含まれていますか？

1 つでも「いいえ」がある場合は、Major として指摘します。出荷はブロックしません。次の推奨事項を追記します："Run /tokens to close the gap at [category]."

---

ステップ 3b — クラフト意図の確認（画面全体のみ）

対象が画面全体（ダッシュボード、ランディングページ、認証画面、設定シェル、ポートフォリオ）の場合にのみ適用します。単一コンポーネントの場合はスキップします。

1. シグネチャーとなる賭けはありますか？ references/craft-intent.md の §3（プロダクト／認証／マーケティングのリスト）にある、記憶に残る決定がちょうど 1 つあるか確認します。0 個 → Major（「シグネチャーがなく、画面は十分に整っているものの匿名的です。/bolder または /polish を実行してください」）。競合するものが 2 つ以上 → Major（「シグネチャーとなる賭けが積み重なっています。最も強いものを残し、ほかは削除してください」）。
2. バリエーションは画面に合っていますか？ レイアウトのリスクが、その画面の DESIGN_VARIANCE のデフォルトと明らかに一致しない場合（例：認証フォームに実験的な非対称性がある、またはランディングページが中央揃えの左右対称な 1 カラム構成である）は、ブリーフまたは仕様に逸脱の記録がない限り、Major とします。
3. Craft Read は記録されていますか？ .ui-craft/spec.md のセクションまたはセッションで Craft Read が宣言されている場合、構築された画面がその内容（テーマ、バリエーション、シグネチャー）に一致するか確認します。不一致 → 具体的な差分を示して Major とします。

これらの指摘は常に Major であり、Critical にはなりません。NOT READY の判定には影響しますが、BLOCKED にはなりません。

---

ステップ 3c — コピーの自己監査と機械的な数の確認（マーケティング画面のみ）

ランディングページ、ポートフォリオ、キャンペーンページに適用します。プロダクトシェルの場合はスキップします。

references/recipe-landing.md を読み込み、構築された画面に対して Acceptance-bar の機械的チェックを実行します。しきい値（アイブロウの数、レイアウトファミリーの予算、ヒーローの規律）はこのファイルに記載されています。このステップでは、対象となるチェックと違反の扱いのみを示します。

1. コピーの自己監査。 見える文字列（見出し、アイブロウ、ボタン、キャプション、代替テキスト、フッター）をすべて読みます。文法の破綻、指示対象が不明瞭な表現、無理に気の利いたラベル（体験談の見出しに「Field notes」を使う、「Quietly trusted by」など）、出典のない精密すぎる数字は、references/copy.md の Copy Self-Audit に従って Major とします。
2. アイブロウの数（機械的チェック） — references/recipe-landing.md の Eyebrow budget に従います。予算超過 → Major（「アイブロウが多すぎます。数が基準を満たすまでラベルを削除してください」）。
3. レイアウトファミリーの数（機械的チェック） — references/recipe-landing.md の Layout-family budget に従います。繰り返し、または連続分割の超過があれば → Major。
4. CTA の意図（機械的チェック） — references/copy.md の CTAs & Buttons に従います（意図ごとにラベルは 1 つ。デスクトップで CTA が 1 行に収まること）。違反 → Major。
5. ヒーローの規律 — references/recipe-landing.md の Hero discipline に従います。予算超過 → Major。

ステップ 4 — 仕上がり基準

references/finish-bar.md を読み込みます。文書に記載された順序で10個すべてのパスを実行します。順序を変更しないでください。

ノブの動作（実行前に適用）：

• CRAFT_LEVEL ≤ 6 かつユーザーが /finalize を明示的に実行していない場合：パス1、6、8のみを実行し、残りは N/A（ノブによる適用除外）としてマークします。
• CRAFT_LEVEL ≥ 7 またはユーザーが /finalize を明示的に実行した場合：10個すべてのパスを実行します。
• MOTION_INTENSITY ≤ 3：パス7はモーションの不足のみを監査します。導入アニメーションがないことを理由に不合格にしないでください。
• VISUAL_DENSITY ≥ 8 かつブリーフに詰めたリズムが記載されている場合：パス4では詰めた間隔の値を許容します。

各パスについて：

• 指摘事項を収集します。
• finish-bar.md の重大度マップに従って重大度（Critical / Major / Minor）を割り当てます。
• 指摘事項が brief.md に記録された原則と矛盾する場合は、「Deferred per brief」に格下げし、該当する原則を正確に引用します。該当するブリーフの原則がない場合は、指摘事項として残します。
• 可能な場合はファイル名と行番号を記録します。

---

ステップ 5 — フィードバック階層フィルター

references/review.md のフィードバック階層セクションを読み込みます。

すべての指摘事項（検出器＋トークン＋仕上がり基準）を次の3つの階層に分類します。

• 価値 — 表面はブリーフで定義された問題を解決していますか？
• 使いやすさ — ユーザーは主なタスクを達成できますか？
• 満足感 — 仕上がりは洗練されていますか？

価値に関する指摘事項がある場合は、レポートで最初に提示し、価値に関する指摘事項が解決するまで満足感に関する指摘事項への対応をすべて延期するよう、常設の推奨事項を追加します。これにより、機能の不具合が磨き込み作業で覆い隠されることを防ぎます。

---

ステップ 6 — 出力

このレポートを出力します。前置きを追加しないでください。

## Finalize report — <surface name>

**Ship verdict:** READY / NOT READY / BLOCKED

> BLOCKED = any Critical finding present.
> NOT READY = any Major finding present, no Critical.
> READY = zero Critical, zero Major (Minor explicitly accepted).

### Block-ship findings (must fix before merge)
- [Pass / detector source] — [finding] — [file:line if available]

### Major findings (fix or defer with recorded reason)
- [...]

### Minor findings (polish; ship-okay if explicitly accepted)
- [...]

### Deferred per brief
- [finding] — [principle from brief.md that defers it]

### Recommended next actions
- [ordered, 3–5 items max]

階層に指摘事項がない場合は、そのセクション見出しを省略します。

---

ステップ 6b — 収束モード（明示的なオプトインのみ）

収束モードは、ユーザーが「run in convergence mode」または「converge until the bar passes」と明示的に指示するか、--converge フラグを使用した場合にのみ有効になります。「そのまま続けて」「修正して」「合格させて」のような曖昧な指示では収束モードは有効になりません。デフォルトは指摘事項の提示のみであり、ステップ7のハードストップが適用されます。

明示的に有効化された場合：skills/ui-craft/references/loops.md を読み込み、プリセット visual-anti-slop を実行します（loops.md で定義されたデフォルトのループ予算を適用し、上限は5回です）。反復1の前に、事前コスト通知を出力します。影響が最も大きい修正を1つ適用するたびに、READYになるか予算を使い切るまで、確定のステップ2〜6（このコマンド独自のステップ）を再実行します。**注：**確定の指摘事項提示のみというハードストップ（ステップ7）は、収束モードの間に限り解除され、反復中に修正が適用されます。

---

ステップ 7 — ハードストップ

ファイルを編集しないでください。コードの変更案をインラインで提示しないでください。判定結果を出力します。ユーザーがレポートを読んだ後に修正を依頼した場合は、別のリクエストとして対応します。

**次のステップ：**出荷します。ゲートが赤の場合、指摘事項に再実行するパス（/polish、/harden、または /clarify）が記載されています。