ROUND 01 「Yの座標名、入れなくていい？」 ▼

初期案の前提

FKScanner_MinusX

「今Xで足りる。将来Y分割が必要になってから拡張すればいい」という実装視点の判断。

問いが追加した要件

未来の読み手が迷わないか

半年後に「Y・Zは全域の仮定？」と毎回確認し直す未来を見ていた問いだった。

命名は「今機能するか」ではなく「未来の読み手が誤解しないか」で決める。

ROUND 02 「YだけじゃなくZもか」 ▼

Unityの座標系

X=左右 / Y=高さ / Z=前後

空間分割はXとZの2次元。YはPICK/PLACE高さのフィルタ条件にすぎない。

初期案の盲点

FKScanner_PlusX_AnyY

X軸の分割は命名したが、Z軸（前後）は暗黙に全域と仮定していた。

将来のXZ4象限分割に備えて、命名が自然に拡張できる形にする。

ROUND 03 「+はダメ。AIが読みやすい命名で」 ▼

記号ベース案

FKScanner_X+

簡潔で拡張が自然。ただしファイル名への記号使用は「行儀が悪い」として即断。

確定した一次要件

ASCII互換・記号なし

ファイル名はAI・git・シェル・URL・外部サービスが全部読むデータ。最も能力の低いケースに合わせて設計する。

インターフェースは「一番能力の低いケース」に合わせて設計する。UXの基本。