onboarding-core

目的

新しいスレッドや新しいエージェントが来ても、最短で開発状況に追いつける導線を固定する。

重要: STATUS.md は人間が書いた「意図」であり、実際のコードと乖離している可能性がある。必ず実装状況を検証すること。

オンボード手順（固定）

Phase 1: ドキュメント読み込み（5分）

•
docs/design/STATUS.md
- •進捗サマリ、正本一覧、次のタスク
- •⚠️ これはあくまで「記録」であり実態と異なる可能性あり
•
docs/design/START_HERE.md
- •不変条件・座標系・基本ルール
- •Right-Handed (X=East, Y=North, Z=Up), 1 unit = 1mm
•
docs/design/phase1-implementation-review.md (769行)
- •Phase 1 の詳細設計と実装状況
- •GPT-5.1 承認済みのレビュー文書

Phase 2: 実装状況の検証（3分）

必須検証コマンド:

bash

# ファイル数と行数を確認
find src -name "*.rs" | wc -l
wc -l src/**/*.rs 2>/dev/null | tail -1

# 主要モジュールの規模
wc -l src/floorplan/*.rs src/projection/*.rs src/ui/*.rs

# 重要な関数/構造体の存在確認
grep -r "pub fn remove_space" src/
grep -r "pub struct FloorplanPalette" src/
grep -r "IntersectionResolver" src/

確認すべきポイント:

チェック項目	確認方法
Space 削除	`grep -r "remove_space" src/`
Undo/Redo	`grep -r "FloorplanHistory" src/`
壁投影	`src/projection/wall_projector.rs` の存在
交差処理	`src/projection/intersection_resolver.rs` の行数
建具	`src/opening/mod.rs` の存在

Phase 3: 乖離発見時の対応

STATUS.md と実コードに乖離がある場合:

•STATUS.md を更新する (コードが正)
•更新内容をコミットする
•ユーザーに報告する

オンボード出力フォーマット

新規参加者やユーザーに見せる説明文（1分で読める）：

markdown

## このプロジェクトは何をしているか（1分）

住宅設計 CAD を Rust で開発中。
日本の木造住宅（在来工法）を対象に、図面を A→F Model Chain で成立させることが目標。

## 実装進捗（検証済み）

| Phase | 進捗 | 状態 |
|-------|------|------|
| Phase 0 (Core) | 100% | ✅ 完了 |
| Phase 1 (Floorplan UX) | 90% | ✅ ほぼ完了 |
| Phase 2 (Drawing View) | 60% | 🔄 基盤あり |
| Phase 3 (Auto Gen) | 40% | 🔄 壁生成ロジックあり |

## 正本の状態（A–F 層）

| 層 | 状態 |
|----|------|
| A (Axiom) | 🔒 凍結 |
| B (Boundary) | ✅ 成立 (floorplan/) |
| C (Composition) | ✅ 成立 (composition/) |
| D (Disposition) | 🔒 凍結 |
| E (Expression) | ✅ 成立 (expression/) |
| F (Figure) | ✅ 成立 (projection/) |

## 次の最小 Permit

→ STATUS.md を参照

主要ファイルの規模目安（参考値）

ファイル	行数	内容
`main.rs`	~3,000	アプリエントリ
`app.rs`	~1,300	App 状態管理
`floorplan/mod.rs`	~900	Space/Zone/Level
`projection/intersection_resolver.rs`	~1,000	壁交差処理
`opening/mod.rs`	~700	建具モデル

注意

•STATUS.md が「意図」、コードが「実態」
•乖離があればコードを信じ、STATUS.md を更新する
•推測せず、検証コマンドを実行する