# PHILOSOPHY（設計理念）

所有者との対話（2026-08-20、headacheapp-platform 構想フェーズ）で固まったもの。

## 1. 各アプリは「木」である（tree-engineering との統合）

- 患者アプリ一つひとつが tree-engineering の木（tree）であり、**一つの kodama が運転する**。
- 患者からの要望・不具合は mail2issue（メール→未読→Issue 自動起票）で木に届き、
  **kodama が自分で修理する**（契約を切り、実装し、批評にかけ、着地する）。
- これが本プロジェクトの面白さの核: **アプリの保守そのものが木の自律運転で回る**。

## 2. 森の観測者（platform 層のモデル）

- platform 統合層には**観測者（observer）のモデル**がいて、各木を「把握」する——
  何が変わったか、どの木でどんな要望が来て、どんな修理が起きたかを読み取り、
  **人間（所有者）に伝えてメンテナンスの判断を仰ぐ**。
- 観測者は木を直接運転しない。木の自律と、人間への正直な報告の両立が役目。
- 各患者には**少しずつ別の機能を持ったアプリを配り、改善要望からニーズを回収する**——
  差分は欠陥ではなく観測の設計。profile 駆動の載せ外し
  （例: バンド入力は no1 系のみ）で管理する。
- 観測者と同じ位置に、**ハーネス（tree-engineering の運転系）そのものを保守する
  deidara** がいる。observer がアプリ群を、deidara が運転の仕組みを見る——
  どちらも木を直接運転せず、修理は版として配布する。

## 3. LLM 3層の原則

1. **端末内層**: 患者データに触れる推論は端末内 LLM のみ
   （FoundationModels、使えない端末は規則ベースが受ける）。
   音声・文字起こし・構造化を端末の外へ送らない。
   原文は必ず残し、候補は後から直せる。診断・治療推奨は作らない。
2. **木の層（kodama）**: 開発と自己修理を担う。実行者と批評者はベンダーを分け、
   機械テスト・スクリーンショット・契約の Proof で縛る。
3. **森の層（observer）**: 横断的な把握と人間への報告。決裁は常に人間
   （OIHOTL/OOTL の関与水準は契約ヘッダで固定）。

## 4. spec が共通言語、版が変化の記録

- **PHR スキーマが全アプリの共通言語**。additionalProperties: false ＋全欄必須＋
  schema_version により、書き出しの形は常に一意に検証できる。
- **スキーマに欄が無いものは端末内のみに保存し、「スキーマ版上げ候補」として記録する**
  （随伴症状・シフトが実例）。欲しい欄の圧力が版上げ提案として自然に蓄積し、
  **版の履歴そのものがプラットフォームの変化の記録になる**。
- 各アプリのコードには写像を固定するテスト（キー集合の完全一致まで突合）を置く。
  no3 の WellbeingRecordsTests / WearableDailyFeaturesTests が手本。

## 5. 同期の理念

- 記録は患者の端末内が原本。**受診のたびに所有者の PC サーバーへ送る**（常時同期しない）。
- 入り口の仕組み（keyring の client_kind・/v1 受け口・Tailscale Funnel）は共通、
  アプリは別でよい。
- 開示は患者の同意が門。撤回は「開示停止・利用継続」であり、記録は患者の手元に残る。

## 6. 刻みの掟（運転規範）

- 新規の仕組み物は 設計提示→Go→作成→コミット前確認 の順。勢いで一気にやらない。
- 決裁カードは平易な日本語で（git 用語を並べない）。枝の開始は「実行」と言う。
- 契約に Proof（機械で判る合格条件）を必ず置き、批評者は別ベンダー。
- 既存テストの削除・skip・緩和は禁止——退役面でも検査は検査専用入口で生かす。