visionOS 版は .tortoise のビューワーにする（現実の平面をキャンバスに、🐢 を走らせる）

[temoki]

進捗（2026-08-18） — ブランチ visionos-viewer、Phase 0〜3 すべて完了（すべて実機確認済み）。PR は #54。
3D の 🐢 には TortoiseGraphics2 2.1.0（temoki/TortoiseGraphics2#46 / #47）が要った。
「注意」の 2 件は両方とも片付いた。 プライバシーポリシーは第 6 節を追加済み、公開タイミングは #55 で pages.yml が手動実行のみになったので、マージしてもサイトはデプロイされない。マージ前の判断は残っていない。
詳細は各フェーズのコメント（Phase 0 / Phase 0 追記 / Phase 1 / Phase 2 / 配置のやりなおし）。

背景

visionOS 対応は #11 で一度「iPad アプリ相当が動く」ところまで作り、PR #52 に退避した。
動くには動くが、それが visionOS である理由がどこにもない。同じことは Apple の
iPad 互換モードが最初からやっている。そして退避した残課題

• メインウィンドウからファイルを選び直せない（dismiss() はシステムの「書類」
  ボタンを見せるだけで、openDocument / newDocument は visionOS で unavailable）
• 表示の切り替えで前の View が背景に残る（実機のみ・アプリ全域）

は、どちらも DocumentGroup と編集 UI に由来する。回避策を探し続けるより、
その機能を持たない設計にした方が早い。

一方で、visionOS でしかできないことが一つある。**タートルグラフィックスの
タートルは、元々は床を走って紙にペンで描く実物のロボットだった。**画面の中の
三角形の方が後から出てきた代用品で、机の上を 🐢 が這って線を引くのは 3D 化の
こじつけではなく原点回帰にあたる。

そこで visionOS 版は iPad/macOS 版の移植をやめ、.tortoise のビューワーとして
作り直す。

仕様案

全体像

visionOS 版は「編集しないアプリ」。3 つの面で構成する。

面	中身
ImmersiveSpace（mixed）	現実の平面に貼りついたキャンバス。その上を 🐢 が動いて描く
ウィンドウ 1	ブロック（読み取り専用）。再生位置に合わせてハイライト
ウィンドウ 2	生成された Swift コード（Phase 3、任意）

iPad ではキャンバス／コードをトグルで切り替えているが、visionOS には面が
いくらでもある。ブロックと絵を同時に見せられるのは iPad 版より良い版であって、
機能を削った版ではない。ここが visionOS 版の存在理由になる。

ドキュメントの入口 — DocumentGroup は使わない

.fileImporter を持つ普通の WindowGroup にする。read-only なら
DocumentGroup(viewing:) という手もあるが、#52 で踏んだ「書類選択に戻れない」
問題は viewing でも同じはずなので採らない。素の fileImporter なら 1 タップで
開き直せて、あの残課題がそのまま消える。

サンプル作品をアプリに同梱する。 現状ドキュメントは iCloud ではなく
「On My iPad」のローカルフォルダに保存されるので、Vision Pro には AirDrop 等で
手で持っていくことになる。同梱しないと初回起動が空のビューワーになる。
appstore/screenshot-sources/ に既に 2 つある。

描画をどう 3D にするか — Phase 0 で実機を見て決める

• (a) テクスチャ方式 — 既存の 2D 描画をテクスチャ（TextureResource.DrawableQueue）
  にして平面エンティティに貼る。既存資産をほぼ全部再利用でき、安い。
  拡大したときの解像度が頭打ちになる。
• (b) メッシュ方式 — ストロークをリボン／チューブのジオメトリにする
  （LowLevelMesh 等）。拡大に強く「ペンを上げたら浮く」表現もできるが、
  fill の三角形分割まで自前になる。

判断材料は「テクスチャ方式で見られる絵になるか」「10,000 コマンドで毎フレーム
更新が保つか」の 2 点だけ。まずアプリ側で試作する。 upstream-first からすると
RealityKit レンダラは TortoiseGraphics2 の話に見えるが、スケールとアンカーは
アプリ固有なので、一般化できると分かってから upstream に上げる。

ハイライトは「できれば」ではなく中核

これが無いと visionOS 版は「絵が出てくるのを眺めるもの」でしかない。ブロックと
絵の対応こそがこのアプリの教育的な核で、それを一番よく見せられるのが visionOS。

実装は既存の不変条件にただ乗りする。RunnerModel.currentBlockID は
expandedBlockIDs[player.currentCommandIndex] で、これは Tortoise.apply が
入力ストリームを index 対応でそのまま記録することに依存している（Kit の
往復テストで固定済み）。

設計上の制約: CommandPlayer はタイムラインとして残し、差し替えるのは
描画側だけにする。そうすればハイライトは自動的についてくる。新レンダラが
独自のタイムラインを持つと、この対応が壊れる。

スケールと単位

キャンバスはポイント、机はメートル。描画のバウンディングボックス
（DrawingBounds.compute は public）を、検出した平面上の一定サイズ（60cm 角程度）に
収める写像を 1 箇所に置く。PNG 書き出しの exportFrameSize と同じ考え方。
この写像は UI に依存しないので Kit 側に置いてテストする。

ターゲット構成 — 増やさない

App ターゲット 1 本のまま #if os(visionOS) で Scene ツリーだけ差し替える。
別ターゲットにすると Support/Info.plist の UTType 宣言が二重になり、署名も増える。
TortoiseBlocksApp は既に #if os(iOS) で LaunchScene を出し分けている。
バンドル ID が同じなら universal purchase も自然に効く。

やること

Phase 0 の結論が出るまで Phase 1 以降の見積もりは意味を持たない。

Phase 0 — 実機スパイク（捨てる前提）

• ImmersiveSpace(.mixed) + ARKit PlaneDetectionProvider で平面を取る
• 既存の 2D 描画をテクスチャで机に貼る（上の (a)） → 不要。ViewAttachmentComponent で既存の TortoiseCanvas をそのまま置ける
• 既存スプライトを 🐢 として立てる（紙に寝ている）
• 10,000 コマンドの作品で性能を測る → 問題なし
• → (a) でも (b) でもない。スケールは定数ではなくジェスチャー（0.2〜2m）

Phase 1 — ビューワーの骨格

• WindowGroup + .fileImporter、サンプル同梱（SampleBlocks を流用、追加リソースなし）
• ImmersiveSpace に絵、再生コントロール（既存の PlaybackControls をそのまま再利用）
• NSWorldSensingUsageDescription と、平面が見つからない場合の代替表示（15 秒で諦めて目の前に浮かべる）

Phase 2 — ブロックの窓（ここまでで初めて「このアプリ」になる）

• 読み取り専用のワークスペース表示（D&D・編集・削除なし）
• 再生進捗に追従するハイライト（再生位置まで自動スクロールする）

Phase 3 — 仕上げ

• 3D の 🐢（USDZ）に差し替え
• コードの窓 — ブロックの窓とほぼ同じ構造
• SVG / PNG 書き出し → 作ったうえで外した。 安く動いたが、絵を変えられないビューワーが 2 つ目の成果物を書き出すのは、絵を作る場所（iPad / Mac）の仕事。リモコンのボタンも 6 個になっていた

3 つは互いに独立しているので着手順は自由。アセット待ちの 🐢 を後回しにするのが動かしやすい。

受け入れ条件

Phase 0:

• 実機で、机の上に置いた絵が「線として読める」品質かどうかを目視で判定できている → 読める
• 10,000 コマンドの作品でフレームレートが実用範囲か分かっている → 問題なし
• (a)/(b) の選択とスケールが決まり、この issue に追記されている → どちらでもない／サイズはジェスチャー

Phase 1–3:

• .tortoise を開くと、現実の平面の上に絵が現れ、🐢 が動いて描く
• ファイルを開き直すのに 1 タップで済む（visionOS 対応（退避・1.1.0 には入れない） #11 #52 の残課題が再現しない）
• ブロックの窓が再生位置に追従してハイライトする
• 編集操作は一切露出していない（保存もしないので、ドキュメントが汚れることがない）
• 既存 2 プラットフォームのビルド・Kit テスト（119 件）・lint が緑のまま

注意（先に潰しておくもの）

プライバシーポリシーが 1 行だけ嘘になる。（NSWorldSensingUsageDescription はブランチで追加済み。site/privacy.html と App Store の質問票はまだ） 平面検出には
NSWorldSensingUsageDescription の許諾が要る。カメラ映像がアプリに渡るわけでは
ないが、site/privacy.html は現在「位置情報、連絡先、写真、カメラ、マイクへの
アクセス」なしと書いており、App Store のプライバシー質問票も同じ申告になっている。
「端末内で完結し、送信も保存もしない」と書き足せば済む話だが、忘れると審査で
止まる種類のもの。release skill の管轄。

3D の 🐢 アセットが要る。 現状は 23×32px の 2D 画像。USDZ の用意はアイコンと
同じく手作業になるので、Phase 1 は既存スプライトのビルボードで逃げて、
アセット待ちで止まらないようにする。

検証は実機でしかできない。 シミュレータに現実の平面はない。CI はビルドまで、
目視は毎回ヘッドセット。座標写像のように Kit へ落とせるロジックは落としておく。

対象年齢が噛み合わない。 Vision Pro は Apple 自身が 13 歳以上を想定している。
visionOS 版の位置づけは「大人が見せる／教室で見せる」で、site が「保護者と先生に
向けて書く」方針なのとは合う。ストア文言を iOS からそのままコピーしない理由になる。

PR #52 の扱い

この issue は #52 を置き換えるが、#52 の成果のうちプラットフォーム基盤は
そのまま活きる。

活きるもの:

• project.pbxproj の SUPPORTED_PLATFORMS / XROS_DEPLOYMENT_TARGET /
  TARGETED_DEVICE_FAMILY = "2,7"
• 署名スコープの修正（ad-hoc を [sdk=macosx*] に限定。これは実機デバッグを
  塞いでいたバグ修正なので、この issue と切り離して main に入れてよい）
• CI の visionOS ビルド、fastlane の platform :visionos、metadata_check.rb の
  3840×2160
• ストア文言・LP の visionOS 記述（出荷するまで公開しないこと。文面は 3 つの
  リストで共有されているので、公開すると iOS/macOS のリストまで Vision Pro 対応を
  名乗ってしまう）

捨てるもの:

• 3 ペインのカラム幅調整、documentBrowserToolbar（削除済み）、コードペインの白紙化
  （コードの窓を作るなら Phase 3 で参照する）

引き継ぐ知見:

• hoverEffect と draggable を同じ View に付けると visionOS で segfault する
  （効果を ButtonStyle 側に 1 段下げると通る）
• ToolbarSpacer は visionOS に無い
• 表示切り替えの残像は実機のみ・アプリ全域。ビューワーでも踏む可能性があるので
  Phase 1 で再現するか確認し、するなら Feedback Assistant へ

Refs #11, #52

[temoki]

Phase 0 の結果

ブランチ visionos-spike（visionOS から分岐、App/Views/TableSpike.swift ほか）。実機 + visionOS 26.5 シミュレータで確認。

1. レンダラの選択 — (a) でも (b) でもなかった

本文は「テクスチャ方式 (a)」と「メッシュ方式 (b)」の二択で書いていたが、第三の答えがある。

visionOS 26 の ViewAttachmentComponent(rootView:) は、生きた SwiftUI ビューをそのまま RealityKit のシーンに置ける。つまり机の上に乗るのは既存の TortoiseCanvas そのもので、同じ CommandPlayer が駆動する。エンティティ 1 個、新規の描画コードはゼロ。テクスチャパイプラインもメッシュ生成も要らない。

これは受け入れ条件以上に重要で、コマンドストリームが一切変わらない。本文が「設計上の制約」として挙げたハイライトの index 整合（expandedBlockIDs[player.currentCommandIndex]）は、そもそも危険に晒されない。Phase 2 はほぼタダになる。

2. 「線として読めるか」 — 読める

実機で確認。

3. 「何 cm が正解か」 — 問いが間違っていた

正解のサイズは無い。座る距離と机の大きさで決まるので、サイズは定数ではなく装着者のもの。40/60/80/100cm の離散ピッカーは捨て、ピンチでサイズ、ひねりで垂直軸まわりの回転に変更した。

• 平らに寝たシートは法線がすでに垂直軸なので、3D 回転ジェスチャーは不要 — 素の 2D RotateGesture がそのまま求める回転になる
• サイズは 15cm〜2m でクランプ（無制限のピンチは 1 秒で 50m のキャンバスに達する）
• 既定は 60cm。バーが現在のサイズと角度を読み出すので、残る測定は「正解の寸法」ではなく「実際に人が落ち着く寸法」

4. 「10,000 コマンドでフレームレートが保つか」 — 問題なし

---

実装上の判明事項（Phase 1 が踏み直さないように）

• イマーシブスペースの原点は床であって目線ではない。「机の高さ＝目より下」で y = -0.4 に置くと床下に埋まり、何も描画されていないのと見分けがつかない。切り分けにはマーカーのエンティティを並べるのが早い
• @PhysicalMetric(from: .meters) がポイント↔メートルの変換。これがあって初めて「60cm」が本当に 60cm になる
• ピンチはアタッチメントではなくエンティティを拡大する。 ジェスチャー中にアタッチメントを作り直すとアンカー探索が再実行され、リサイズのたびに絵が飛ぶ。1m で 1 枚レンダリングして拡縮する方式なので、縮小側は絶対に甘くならず、拡大側は甘くなりうる — これが唯一のトレードオフで、実機で目視する価値がある
• シートは allowsHitTesting(false) にしないとジェスチャーが効かない。 SwiftUI のアタッチメントが先にピンチを飲むため。エンティティ側は InputTargetComponent + ビュー平面の CollisionComponent（エンティティと一緒に拡縮する）
• NSWorldSensingUsageDescription が要る（本文の privacy 注意事項の実物）
• 平面検出は実機のみ。 シミュレータには平面が無いので、固定配置のモードを併設しないと開発ループが回らない

シミュレータからこの spike に到達できない問題

visionOS の DocumentGroup は simctl openurl（iPadOS で書類を開く手）を無視し、simctl はタップを送れず、DocumentGroupLaunchScene は visionOS では表示されない（システムのブラウザに直行するので、.task を吊るすビューすら無い）。そのため -TBSpike YES で起動時にスペースを開く口を用意した。

なお ImmersiveSpace への defaultLaunchBehavior(.presented) は効かない。ログ上、シーンは immersiveStyle = Mixed で宣言された直後に requesting immersive or volume NO になる — DocumentGroup が起動を取るため。手前に suppressed な WindowGroup を置くと起動を取れて、そこからの openImmersiveSpace は機能する。

---

残っていること

• ジェスチャー操作そのものの実機での使い勝手（simctl は入力を送れないので未検証）
• 大きくしたとき絵が甘くなるか
• 位置（移動）をジェスチャーにするかは未決 — いまはアンカー任せ

Phase 1 に進んでよい状態。

[temoki]

Phase 0 追記（実機で詰めたぶん）

ブランチ visionos-spike を push（7 コミット）。上のコメントから変わった点と、追加で分かったこと。

ジェスチャー — サイズだけでなく回転・移動も

「正解のサイズは無い」の続きで、ピンチ＝サイズ / 手首のひねり＝垂直軸まわりの回転 / ドラッグ＝移動の3つを同時に走らせる形に落ち着いた。実機で向きも操作感も問題なし。

• 2D の RotateGesture は使えない。 visionOS では両手を要求するので片手のひねりに反応せず、両手で反応する場面ではピンチと入力を奪い合う。RotateGesture3D(constrainedToAxis: .y) が正解（minimumAngleDelta 5° でドラッグ中の誤回転を防ぐ）
• 移動量は .scene ではなくエンティティの親空間へ変換する。 平面が見つかるとシートは AnchorEntity の子になり、visionOS はそのアンカーの transform をアプリに渡さないので、シーン空間の差分はまさに効いてほしい場面でズレる
• 平面アンカー時は水平に拘束。 親の Y が平面の法線そのものなので、変換後の差分の Y を 0 にすれば机の上を滑る。固定配置のほうは自由 3D のまま（面が無く、高さが唯一まともな置き場所を決める手段なので）
• サイズは 0.2〜2.0m でクランプ

解像度 — builtSide が唯一のつまみ

ピンチはエンティティを拡大し、アタッチメントは焼き直さない（焼き直すとアンカー探索が再実行されて絵が飛ぶ）。つまり 1 枚のレンダリングを引き伸ばしている。

実測: visionOS は 1m = 1360pt。builtSide = 1.0 は 1360pt² のレンダリングで、表示 1m あたりに直すと 60cm 表示で約 2270pt / 2m 表示で 680pt — 3.3 倍の開きがある。大きくしたときの軽い甘さはここから来る。

上げれば直るがコストは二乗（2.0 で 4 倍のピクセル、2× バッキングだとテクスチャサイズの上限も視野に入る）。いまは 1.0 のまま。

⚠️ 一度 builtSide を 1.0 → 1.2 にして「見た目が変わらない」ことから「ポイントサイズは精細さのつまみではない」と結論したが、これは誤り。線解像度で 20% の変化は変わって見えないのが当然で、実験が弱すぎた。ちゃんと試すなら 2 倍動かして、表示サイズを 1 つに固定して比べること。

Phase 0 の受け入れ条件

• 線として読める（実機）
• 10,000 コマンドでフレームレート問題なし（実機）
• レンダラの選択とスケールが決まり、issue に追記されている — (a) でも (b) でもなく ViewAttachmentComponent、スケールは定数ではなくジェスチャー

Phase 1 に進む。

[temoki]

Phase 1 完了

ブランチ visionos-viewer（visionos-spike から分岐）を push。実機確認済み。

やったこと

• WindowGroup + .fileImporter、サンプル同梱
• ImmersiveSpace に絵、再生コントロール（再生/停止/速度/やり直し）
• NSWorldSensingUsageDescription と、平面が見つからない場合の代替表示

シーンツリーが visionOS だけ別の木になった。 #if os(visionOS) で WindowGroup（操作）＋ ImmersiveSpace（絵）、iPadOS と macOS は DocumentGroup のまま。これが分岐の意味そのもので、DocumentGroup を捨てると #52 が解けなかった2つが同時に消える — ブラウザに1タップで戻れないこと（dismiss() はシステムの「書類」ボタンを見せるだけ、openDocument / newDocument は visionOS で unavailable）と、表示切り替えの残像を抱えていた編集 UI そのもの。.fileImporter は「戻る」先を最初から持たないので1タップで開き直せる。実機で確認済み。

ウィンドウにキャンバスは無い。 同じ絵が2箇所にあると、このプラットフォームにアプリがある理由がなくなる。窓はリモコン（えらぶ・おく・さいせいする）で、絵は机の上にしか存在しない。

周辺で必要になった小さな変更

• PlaybackControls が WorkspaceEditor ではなく blocks を取る。 もともと workspace.blocks しか読んでおらず、トランスポートは何も編集していなかった。これでスクラバー・コマ送り・速度・4通りの中央ボタンが丸ごとビューワーで動く
• BlocksDocument.project(from:) を FileDocument から分離。importer と DocumentGroup が同じバージョンゲートを通る（別だと「未来のファイル」の判定がズレる）
• LaunchScene は #if os(iOS) へ。 DocumentGroupLaunchScene なので付く先が無くなった。ついでに記録: visionOS ではもともと表示されていなかった（システムの書類ブラウザに直行する）
• サンプルは SampleBlocks の4種を流用。同梱リソースも2つ目の名前も要らない

窓のサイズ

固定サイズをやめ、windowResizability(.contentSize) で窓＝中身に。実機で 560×520 固定にしたら操作列の下にガラスの空帯が残ったため。高さは2通り（絵なし / トランスポート付き）で、開くと伸びる。幅だけ 520 固定 — スクラバーは自前の幅を持たないので、外すと最長ラベルに合わせて縮む。

受け入れ条件

• .tortoise を開くと現実の平面の上に絵が現れ、🐢 が動いて描く
• ファイルを開き直すのに 1 タップで済む（visionOS 対応（退避・1.1.0 には入れない） #11 #52 の残課題が再現しない）
• ブロックの窓が再生位置に追従してハイライトする → Phase 2
• 編集操作は一切露出していない（保存もしないので書類が汚れない）
• 既存 2 プラットフォームのビルド・Kit テスト（119 件）・lint が緑のまま

文字列 9 件は日本語込みで手挿入（+90 / −0 の純粋な追加）。サンプル名が日本語では動詞形になる（「うずまきをかく」がタイトルにも出る）が、現状のままとする判断。

宿題

PaletteView.documentBrowserToolbar() が visionOS で死にコードになった（消えた DocumentGroup のための #52 の回避策）。Phase 2 で落とす。

Phase 2 へ。

[temoki]

Phase 2 完了

visionos-viewer に push。実機確認済み。

• 読み取り専用のワークスペース表示（D&D・編集・削除なし）
• 再生進捗に追従するハイライト

ハイライトはほぼタダだった — Phase 0 の設計判断が効いた

RunnerModel.currentBlockID は expandedBlockIDs[player.currentCommandIndex] で、机の上の絵は同じ CommandPlayer が描いている。ViewAttachmentComponent でアプリ自身の TortoiseCanvas を RealityKit シーンに置いた（差し替えなかった）ので、index の整合は絵がイマーシブ空間に移ったことに気づいていない。ハイライトは既存パラメータ BlockListView.highlightedID に1本繋いだだけ。

本文が「設計上の制約」として書いた CommandPlayer をタイムラインとして残す件は、結果的に守るまでもなく守られた。

行はエディタの行そのもの

読み取り専用の似せ物ではなく BlockListView を再利用。理由は見た目より保守で、SimpleBlockLabel が「ブロック種別を足すときのチェックリスト」に載っているのは書き漏らすと何も描画されないから。2つ目のコピーはその危険を倍にする。

読み取り専用はバインディングが担保する。 WorkspaceEditor は document 経由で書くので Binding.constant なら書き込みが捨てられる。隠し忘れたアフォーダンスがあっても壊れない。

そのうえで編集コントロールは描画自体を止めた。無効化されているだけだと ⋯ と「ここに追加」トグルが押せそうに見えて何も起きず、実機で明確に悪かった。showsBlockEditing 環境値（既定 true）を追加。読むのは2つの葉なので、BlockListView → BlockRowView → ContainerBlockRow に引数を通すより環境値が軽い。

実機で出た2件（どちらも初回実装が半分だけ正しかった）

リストが再生に追従しない → ScrollViewReader。 scrollTo はアンカー指定なしが肝。中央寄せだとループが3行を回るだけで毎コマンド動き続ける。既定アンカーは画面に入れるのに必要な最小量だけ動かし、見えていれば何もしない。アニメーションも無し（毎秒10コマンドでは自分自身を再開し続けるだけ）。

手でスクロールできない → allowsHitTesting(false) を ScrollView に掛けていたのでスクロールごと殺していた。中身側に移動。

副産物: 既存のダークモードのバグ

macOS のダークモードで ⋯ メニューのアイコンが黒地に黒だった。原因は .tint(BlockCategory.ink) がグリフではなく Menu に付いていたこと — メニューに付けた tint はポップアップの中身にも届く。

一度 foregroundStyle に移して直したが、今度は ⋯ 自体が白くなった。borderless のメニューはラベル色を tint から読み、foregroundStyle は無視するため。最終形は tint を効く場所に戻し（blockMenuInk()）、各メニューの中身で .tint(nil) してリセット。1つの固定インクが「パステルのブロック」と「macOS の暗いメニュー背景」という2つの面を同時に担わされていた、というのが問題の本当の形。

Phase 2 で入ったものではなく既存バグ。ビューワーを作ったことで初めて目が行った。

宿題も消化

documentBrowserToolbar()（#11 の visionOS 用回避策）を削除。DocumentGroup が消えて到達不能になっていた。知見（dismiss をどこから読むかで動くかどうかが決まる）は App/Views/CLAUDE.md に残っている。未使用になった "Open Another Drawing" も削除。

受け入れ条件

• .tortoise を開くと現実の平面の上に絵が現れ、🐢 が動いて描く
• ファイルを開き直すのに 1 タップで済む
• ブロックの窓が再生位置に追従してハイライトする
• 編集操作は一切露出していない
• 既存 2 プラットフォームのビルド・Kit テスト（119 件）・lint が緑のまま

残るは Phase 3（USDZ の 🐢、コードの窓、書き出し）。

[temoki]

配置のやりなおし（Phase 2 と Phase 3 のあいだ）

実機で出た3点 — ①「つくえに おく」から表示まで十数秒、その間なにも起きない ②キャンバスが視線の正面に来ない ③垂直軸まわりの向きが視線基準でない — を直した。

AnchorEntity(.plane) をやめた

3点ともシステム任せでは原理的に答えられない。AnchorEntity(.plane(...)) は1行で済む代わりに、どの面を選ぶかも、その上のどこに置くかも、いつ成功したかもアプリに教えない。PlaneDetectionProvider と WorldTrackingProvider を直接回し、シートはワールド座標の素のエンティティにした。

• どこに — 頭の姿勢から視線を取り、見つかった面の高さで 60cm 前に着地
• どの向きに — 寝かせたシートの上辺は −Z を向く（−90° の X 回転が page-up をそこへ送る）。だから −Z を視線方向に載せる yaw がそのまま「北が奥」になる。机の上の紙が誰も考えずにそう置かれる向き
• 待ち時間 — 「つくえを さがしています…」＋スピナー。15秒で諦めて目の前に浮かべ、それも言う

床ばかり検知される、の原因（2つ重なっていた）

高さ判定が、座っている人には床を通していた。 「目線から 0.25〜1.4m 下」は立っている人には正しい。しかし座ると目線は約 1.2m、そこから床はちょうど 1.2m 下 — 帯のど真ん中。机に向かって座っている人だけ除外されない、という一番まずい条件だった。

いまは2通りで判定し、互いの弱点を補う:

• 絶対高さ 0.35m 以上 — 原点は床なので床は問答無用で落ちる（原点が本当に床である限り）
• 目線から 1.1m 以内 — 原点に依存しない。座った人の床（1.2m 下）より上、立った人の机（0.85m 下）より下

そして「条件を満たした最初の面」を採用していた。 更新は順不同で届き、床は広く平らで早くマッピングされるので、参加を許されたレースはほぼ全部勝つ。いまは面を集めてから選ぶ（SurfaceCollector）: .table があれば無条件で勝ち、なければ視線の先の点に中心が最も近い面。分類なしの候補は2秒保留（本命がまだマッピング中かもしれない）。

分類は優先度であってフィルタではない。 .undetermined が普通の部屋では頻出し、フィルタにすると何も見つからない — 元のコードが分類を無視していたのはそのためで、正しい直し方は「信じ始める」ことではなく「順位付けに使う」ことだった。

ついでに踏んだ、症状が同一の罠2つ（どちらも「何も出ない」）

RealityView の update: は Observation の外。 そこでしか読まない値はビュー更新を促さないので、クロージャは一度きりしか走らない。ARKit が座標を決めても画面は変わらない。トランスフォームは body で読んでクロージャに渡す。

queryDeviceAnchor は追跡開始前に「未追跡の単位行列」を返す。 そこから測ると原点の 35cm 下＝床下。しかも isTracked だけでは足りない — シミュレータは単位行列を返しながら追跡済みと言う。目線高さ 0.8m 以上という妥当性チェックを足し、最大3秒ポーリングする。

実機確認済み。Phase 3 へ。