ewdernaandClaude Opus 5.5
937fc27dbd
メインドキュメントの未確認事項・backlog・暗黙の未決事項について、モック用に進路を1つに固定した。 仕様ではなく、本決定は /decide で行う。ドキュメント間の食い違いは直さず一覧にした。 Codex(Sol・Astra)への相談の原文を consultation/ に置く。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AATqjRyp6rrnwTNdYw8XBT
2.6 KiB
2.6 KiB
相談の問い(Sol・Astraに同じ問いを渡した)
キーボード設計ツール「Beyond KLE」の設計リポジトリ。まず AGENTS.md(→CLAUDE.md)を読み、 リポジトリ直下の *.md と backlog/README.md をすべて読んで。コードはまだ無い。
これから「モックの仮実装」(動くプロトタイプ)に着手する。そのために、仕様上まだ決まっていない事項を 「仮決定」として決めておきたい。仮決定はメインドキュメントには書かず、別フォルダに退避する予定。 仮決定は本決定ではなく、モックを作るために進路を1つに固定するもの。後で覆しやすいこと、覆したときの影響が小さいことを重視する。
問い:
- 明示的な未決事項(各仕様書の「## 未確認事項」、implementation-plan.md の P-1〜P-3、backlog/README.md の各項目)それぞれについて、 モックに影響するか(しない/影響する)を判定し、影響するものは仮決定案を1つ、理由1〜2行とともに示す。 推測タグ([推測:P-n])に依存する箇所は、「推測が成り立つ前提で進める/回避する」のどちらにするかを示す。
- 明示的に未決とされていないが、実装しようとすると決まっていないと分かる事項(暗黙の未決事項)を洗い出し、 それぞれ仮決定案を示す。例: ID生成規則、ファイルの束ね方(プロジェクトファイル)、phyReference.checksum の計算方法、 MAPの未割り当ての表現、IDX order の初期生成、row/col 割り当てアルゴリズム、スキーマの version 運用、など。 仕様どうしの矛盾・食い違いを見つけたら別に挙げる(例: phase1-json-schema.md とレイヤー仕様の型定義の差)。
- モックの対象範囲の提案(どのツール・どの経路までを作るか)。技術選定(言語・UIフレームワーク・描画・状態管理・テスト・パッケージ構成)も仮決定案を出す。 参考: ユーザーは以前 Nuxt3+Pinia で類似エディタ(C:/Users/ewder_71l5bct/Documents/Dev/kbd-editor)を作りかけてうまくいかなかった。そのコードは取り込まない方針。 描画はSVGが有力と書かれている。
ファイルは編集しないこと。日本語で。表や箇条書きで簡潔に、全体で最大250行。 事実(ファイルに書いてあること・原典で確認したこと)と推測・提案を区別して書くこと。 問いの前提が誤っていると思ったら、答える前にそう指摘すること。