ワークスペース行の再設計（if ヘッダの幅あふれ・タッチターゲット・ブロックらしさ）

[temoki]

2026-07-19 の macOS/iPadOS UI 精査より。#12（もし）・#19（else）・#20（四則）でブロックの引数と行要素が増え、ワークスペース行の器が追いついていない。

課題

1. if ヘッダの幅あふれ: ワークスペース列は 300–440pt 固定（ContentView.swift の frame(minWidth: 300, idealWidth: 360, maxWidth: 440)）。一方 if ヘッダは「もし + 値ボタン + 比較ボタン + 値ボタン + なら + (+そうでなければ) + Add Here + ↑↓×」の 9 要素で、360pt では圧縮・truncate がほぼ確実。ネスト（16pt/段）でさらに悪化する
2. タッチターゲット過小（iPad）: DropGap は実質 8–10pt 高。行の ↑↓× / Add Here / そうでなければの × は controlSize(.small) の borderless で、HIG の 44pt に遠い。子ども対象では致命的
3. ブロックらしさの弱さ: パレットは濃色 borderedProminent、ワークスペース行は opacity 0.15 の淡色。色でパレット↔プログラムを対応付ける手掛かりが弱い

方向性案（要デザイン検討）

• ↑↓×（RowControls）をコンテキストメニュー / スワイプアクションに退避し、行は「ラベル + スロット」に専念させる
• if ヘッダは ViewThatFits で 1 行⇄2 行を自動切替（条件部を 2 行目へ）
• DropGap は見た目を細いまま contentShape の当たり判定だけ拡大（±12pt 程度）
• 行背景の彩度を上げる（0.15 → 0.3 前後）か、カテゴリ色の縁取りを足す

受け入れ条件

• 幅 360pt で、else 付き・両辺変数の if 行が truncate なく表示・操作できる
• 行に対する主要操作（移動・削除・挿入先指定・ドロップ）のターゲットが実質 44pt 相当
• タップ挿入（Add Here）経路が引き続き機能する（a11y 代替の維持）
• macOS / iPad 両方で目視確認、両ビルド green

[temoki]

設計（2026-07-20・方針レベル）

UX 分岐 3 点を確認済み。ピクセル単位の正解は実アプリで判断するため（CLAUDE.md / Issue Workflow）、本コメントは方針と実装段取りに留める。

決定事項

1. 行操作: 常時表示は「けす ✕」のみ（44pt 相当）。↑↓ は行のコンテキストメニュー（右クリック / 長押し）へ退避し、同内容を VoiceOver の accessibilityAction としても提供（アクセシビリティ監査（VoiceOver / Dynamic Type / 色以外の手がかり） #1 の該当項目を先取り）。並べ替えの主経路は従来通り D&D
2. if ヘッダ: 条件 3 スロット（lhs / 比較 / rhs）のインライン展開をやめ、要約チップ 1 個（例 🎲1–6 ≥ 4）に集約。タップで popover を開き、既存の 3 スロットエディタで編集する。数値・色ボタンと同じ「チップ → popover」言語に統一され、ヘッダは「◇ もし [チップ] なら ⊕ ✕」の 5 要素になり幅問題が構造的に消える
3. 見た目: 行をカテゴリ色ベタ + 白文字の**濃色ブロック（Scratch 風）**にし、パレットボタンと同じ視覚言語に揃える。スロット（ボタン類）は濃色地で読める白系チップに再スタイル

設計方針

• ConditionButton（新設・ValueEditors）: 要約テキストの表示規則は既存 display 系を再利用（literal → 数値、random → 🎲min–max、variable → 名前、比較は記号）。popover の中身は現行 ConditionEditor をそのまま移設
• コンテキストメニュー: contextMenu と .draggable の共存（長押しの曖昧性解消）は試作段階で最初に確認する。メニュー項目は うえへ / したへ / けす（既存の "Move Up" / "Move Down" / "Delete" キーを再利用）
• DropGap: 見た目は細いまま、contentShape の当たり判定を上下 ±12pt 程度に拡大（44pt 相当）。濃色ブロック化に合わせてターゲット時の色も再調整
• 濃色化の影響範囲: 実行ハイライト（現 opacity 0.4 + accent 枠）は濃色地用に再設計（枠 + 明度変化など試作で決定）。else 区切り行・repeat ヘッダも同言語に。ライト/ダーク両モードでの文字コントラストは アクセシビリティ監査（VoiceOver / Dynamic Type / 色以外の手がかり） #1 の人間確認項目に接続
• ついで吸収: if ヘッダ再構成に伴い、「+そうでなければ」の opacity 0 プレースホルダ（透明な空白、値エディタと入力まわりの改善（数値キーボード・確定挙動・スロット判別・Dynamic Type） #24 で指摘）はこの issue で解消する

実装段取り（2 段階）

1. 試作コミット（見た目のみ・ロジック不変）: ConditionButton 化 + 濃色ブロック + ✕のみ表示 + contextMenu + DropGap 当たり判定。Kit 非接触・既存テスト無変更。→ pkill/open で macOS 目視 + iPad 実機/Simulator 確認
2. 仕上げ: フィードバック反映、accessibilityAction 追加、xcstrings（新キーがあれば）、両ビルド green で commit（Fixes ワークスペース行の再設計（if ヘッダの幅あふれ・タッチターゲット・ブロックらしさ） #21）

受け入れ条件（issue 本文に追加）

• contextMenu と .draggable が同一行で共存する（長押しでメニュー・ドラッグで移動が両立）
• ↑↓ 相当が VoiceOver のカスタムアクションとして提供される
• 実行ハイライトが濃色地でも視認できる（ライト/ダーク）