# 相談の問い(Sol・Astraに同じ問いを渡した)

キーボード設計ツール「Beyond KLE」の設計リポジトリ。まず AGENTS.md(→CLAUDE.md)を読み、
リポジトリ直下の *.md と backlog/README.md をすべて読んで。コードはまだ無い。

これから「モックの仮実装」(動くプロトタイプ)に着手する。そのために、仕様上まだ決まっていない事項を
「仮決定」として決めておきたい。仮決定はメインドキュメントには書かず、別フォルダに退避する予定。
仮決定は本決定ではなく、モックを作るために進路を1つに固定するもの。後で覆しやすいこと、覆したときの影響が小さいことを重視する。

問い:
1. 明示的な未決事項(各仕様書の「## 未確認事項」、implementation-plan.md の P-1〜P-3、backlog/README.md の各項目)それぞれについて、
   モックに影響するか(しない/影響する)を判定し、影響するものは仮決定案を1つ、理由1〜2行とともに示す。
   推測タグ([推測:P-n])に依存する箇所は、「推測が成り立つ前提で進める/回避する」のどちらにするかを示す。
2. 明示的に未決とされていないが、実装しようとすると決まっていないと分かる事項(暗黙の未決事項)を洗い出し、
   それぞれ仮決定案を示す。例: ID生成規則、ファイルの束ね方(プロジェクトファイル)、phyReference.checksum の計算方法、
   MAPの未割り当ての表現、IDX order の初期生成、row/col 割り当てアルゴリズム、スキーマの version 運用、など。
   仕様どうしの矛盾・食い違いを見つけたら別に挙げる(例: phase1-json-schema.md とレイヤー仕様の型定義の差)。
3. モックの対象範囲の提案(どのツール・どの経路までを作るか)。技術選定(言語・UIフレームワーク・描画・状態管理・テスト・パッケージ構成)も仮決定案を出す。
   参考: ユーザーは以前 Nuxt3+Pinia で類似エディタ(C:/Users/ewder_71l5bct/Documents/Dev/kbd-editor)を作りかけてうまくいかなかった。そのコードは取り込まない方針。
   描画はSVGが有力と書かれている。

ファイルは編集しないこと。日本語で。表や箇条書きで簡潔に、全体で最大250行。
事実(ファイルに書いてあること・原典で確認したこと)と推測・提案を区別して書くこと。
問いの前提が誤っていると思ったら、答える前にそう指摘すること。