コード一式をリポジトリごと配るのではなく、「同じ思想のシステムを自分のAIに作らせるためのプロンプト」を配る、という方式の実験。下の「配布プロンプト本文」を、受け取った人が自分のClaude Code（や同等のコーディングAI）に渡すと、その人自身の環境（Mac/Windows/Linux）向けに合わせてシステムを構築してくれる想定。
コード配布と比べた利点：
欠点・留意点：
ブラウザから使える、自分専用のMarkdownノートアプリ。中身はただのテキストファイル群なので、Obsidianなど他のアプリに戻しても問題なく読める。ノート一覧はリスト/タイル/アルバムの3通りで見られ、画像や動画も埋め込める。色や余白などの見た目はスライダーで調整し、気に入った値をノートとして保存する仕組みも入る。「本メモ」のような自由なリストもフォルダを作るだけで増やせる。複数端末から同じサーバーに直接アクセスするので、ファイル同期の衝突は起きない。基本は自分のPC上で完結し費用はほぼゼロ。希望すれば一部のノートだけを外部公開したり、AIとチャットしながら編集する機能も足せる。
あなたにはこれから、個人用の「Web版セルフホスト・ノートアプリ」を、私の環境に合わせて一から構築してもらいます。
既存のNotionやObsidian PublishのようなSaaSは使わず、自分のマシン上で完結する自作システムです。
以下の要件・設計原則・非機能要件を守りながら、私と対話して不明点を確認しつつ、段階的に実装してください。
## ゴール
プレーンMarkdownファイルをvault（フォルダ）で管理する個人用ノートアプリを、ブラウザで閲覧・編集できる形で構築する。
目的はUI/UXを自分で自由に作り込めること。既存OSSのUIをそのまま使うのではなく、
「バックエンド（vaultの読み書きAPI）は既存OSSに乗る／薄く自作する」「フロントエンドは自作する」構成にする。
## 非機能要件（最優先で守ること）
1. **コスト**: 無料/低コストを優先する。有料SaaSへの依存を避け、自分のマシン常時稼働＋OSSの組み合わせを基本にする。
2. **軽量さ**: もたつきを避ける。ノート数が数百〜千件規模になっても一覧表示が重くならないよう設計する（仮想スクロール等）。
3. **マルチデバイス編集**: 複数端末で使う前提。ファイルコピー同士がぶつかる同期方式（Dropbox的な単純ファイル同期の競合）は避ける。
全デバイスが1つの正本（サーバー側API）を直接叩く構成にし、構造的にファイル競合が起きないようにする。
4. **開発時の即時反映**: ソースを編集したらすぐ確認できること（HMR等の標準機能を使う）。
5. **クロスプラットフォーム**: 私が使うOSは [Windows / Mac / Linux のどれか、または複数──ここは必ず私に確認すること]。
OS依存の常駐方法（Windowsならタスクスケジューラ/NSSM/サービス化、macOSならlaunchd、Linuxならsystemd）や
パス表記の違いは、実装前に私に確認してから、私の環境に合わせて選ぶこと。決め打ちしない。
6. **Obsidian互換性（既にObsidianでノートを書いている場合）**: このシステムをやめて素のMarkdownエディタや
Obsidianアプリに戻しても、vaultがそのまま問題なく機能すること。具体的には：
- frontmatterは標準YAMLの範囲内で書く（このシステム独自の構文を作らない）
- リンクは `[[wikilink]]` 記法のまま
- 添付ファイルも標準的な記法（`![[image.png]]` または `![]()`）で参照する
- このシステム独自の機能（デザイントークン等）も、専用DBや特殊ファイル形式を作らず、
普通のノート＋frontmatterだけで完結させる
- つまり「このシステムだけの機能」は全てMarkdown上の"読み方の工夫"であって"データの作り方"ではない、という原則を守る
## 個人環境のハードコード禁止（最重要の制約）
- vaultのフォルダ構造（フォルダ名・特定ファイルの存在）をコードに直書きしない。
「Design System.mdが無ければどう振る舞うか」のようなフォールバックを必ず用意する。
- パス・ホスト名・ポート・パスワード・ドメインなどはすべて環境変数か設定ファイル（`.env.example`同梱）に出し、
コードに埋め込まない。
- 実装を始める前に、以下を私に確認すること：
- 使用OS（上記5参照）
- vaultの場所（既存のObsidian vaultを使うか、新規に作るか）
- 想定ノート数・添付ファイルの規模感
- 外部公開するか（自分専用で閉じるか、一部を人に見せる公開ページも作るか）
## アーキテクチャの方針
- バックエンド：vaultフォルダを読み書きするREST API。既存の軽量OSSがあればそれを土台にしてよいが、
改造した場合は**改造差分を必ず私自身のリポジトリにコミットする**（他人のリポのclone先に未コミットのまま
残すと、環境を作り直すときに改造が消える。これは絶対に避けること）。
- フロントエンド：軽量なフレームワーク（React+Vite等）で自作。エディタはWYSIWYGを狙わず、
source-mode（Markdown記法をそのまま編集）に割り切ることで実装難易度を大きく下げられる。プレビューは別ペイン表示。
- 認証：編集は自分だけ。ログインの有無で見えるデータを変える。書き込み系APIとバイナリ（画像/動画/PDF）配信の
API系統を混同しない（誤った系統に繋ぐとデータ破損の恐れがある設計にしない。1系統に統一するのが理想）。
- 最低限、パスワードは平文保存せずハッシュ化する・総当たり対策（レート制限等）を入れる、をベースラインとして必ず満たすこと。
「後で強化すればいい」を理由に、この最低限を省略しない。
- 発展的な強化として、パスキー（WebAuthn）によるパスワードレス認証も選択肢に入れてよい。
ただしパスキーはHTTPS必須なので、ローカルでまず動かす最初のフェーズでは既定オフにし、
公開する段階（HTTPS化した後）で任意有効化するのが無難。
- 公開する場合：編集面（内部専用API）と公開面（外部向け）は完全に分離する。
内部APIをそのままインターネットに晒さず、公開対象だけを静的書き出しするか、公開専用の読み取りAPIに絞る。
## 参考：構成図（概念と汎用的な選択肢の例）
以下は「こういう構成で作った実例がある」という参考です。同じ選択肢を強制するものではなく、
あなたの環境・好みに応じて代替手段を選んでよい構成要素として示します。
[インターネット]
│
▼ 独自ドメイン（例: Cloudflare Registrar等のドメイン管理サービス）
[トンネル/リバースプロキシ層] ← 常時稼働のマシンにポートを開放せず外部公開する手法の例:
│ - Cloudflare Tunnel（無料、証明書自動）
│ - ngrok / Tailscale Funnel（同種のトンネルサービス）
│ - 自前でNginx/Caddy＋ポート開放（固定IPや契約次第では非推奨）
▼
[常時稼働するマシン: 自宅PC or 安価なVPS]
│ - バックエンド（vault読み書きAPI）をここで常駐させる
│ - 常駐方法の例:
│ macOS → launchd
│ Linux → systemd
│ Windows → タスクスケジューラ / NSSMでサービス化 / WSL2上でsystemd
│
▼ ファイル読み書き
[vaultフォルダ（Markdownファイル群）]
│ - 既存のObsidian等で使っているフォルダをそのまま指せると理想
│ - バックアップ/バージョン管理の例: Git、あるいはOS標準のバックアップ機能（Time Machine等）
[アクセス経路の考え方]
- 編集用（書き込みAPI）は基本、閉域（VPN経由や自マシンのみ）に閉じるのが安全側
VPNの例: Tailscale / WireGuard
- 一部だけ人に見せたい場合は「公開用に静的書き出ししたページ」だけを上記トンネルで公開し、
編集用APIそのものは公開経路に出さない、という分離が安全
**選択の目安（迷ったときの一般論）**：
- 個人のPCを24時間稼働させられるなら「自宅マシン＋トンネルサービス」が最も低コスト
- 24時間稼働できるマシンが無いなら、安価なVPS（月数百円〜）にDocker一式を載せる方が安定する
- Windowsで常駐させる場合、生のプロセス常駐よりDocker Desktop経由にした方が、Mac/Linux版との実装差分が小さく済む
## セキュリティ・ガードレール
- **AIエージェント（Claude Code等）をチャット機能としてアプリに組み込む場合、外部公開経路からは絶対に到達不可にする。**
ローカル/VPN限定にするか、既定で無効にして明示的なオプトインを要求する。
「認証さえ突破されればマシン上で任意コード実行される」構成を公開インターネットに置かない。
- デバッグ用のログ（Cookie・トークン等の値をログ出力する等）を本番動作に残さない。
- secrets（パスワード、APIキー、証明書、トークン）は設定ファイルに書いても、それを共有・コミットする対象からは除外する
（`.gitignore`等で確実に守る）。
- 他人のOSSコードを改造して使う場合、そのライセンスを確認し、配布・共有時は同梱・明記する。
## 実装したい機能（段階的でよい。まず最小構成を動かしてから広げる）
1. **最小限のノートアプリ**: 一覧・開く・編集・保存・プレビュー切替・添付ファイルのアップロード
2. **複数の一覧表示ビュー**: List（1カラム）／Tile（均一グリッド）／Albumを、
カードデータの正規化＋レイアウト差し替えという設計で実現し、見た目の追加を安く保つ
3. **デザイントークンによる見た目のカスタマイズ**: 色・余白・角丸・影・タイポグラフィ等をプレイグラウンドで調整し、
気に入った値をMarkdown（frontmatter）に「正本」として保存、アプリ全体に反映する。即時保存ではなく
「プレビュー→明示的に反映」の2段階にして事故を防ぐ
4. **汎用リスト機能**: 「本メモ」「気になるリンク集」のような自由なリストを、専用コードを書かずに
フォルダを作るだけで追加できるようにする（frontmatterの内容に応じて表示を動的に組み立てる）
5. **（任意）一部ノートの外部公開**: frontmatageで公開フラグを持たせ、該当ノートだけを静的書き出しして公開する
6. **（任意）AIチャット連携**: 上記セキュリティ・ガードレールを厳守した上で、ノートを見ながら会話で編集を頼める機能
## 進め方
- 一度に全部作ろうとせず、「動くものが少しずつ増える」フェーズに区切って進めてください。
各フェーズの節目で私に動作確認させ、次に進む前に合意を取ること。
- 設計判断で分岐がある場合（例: バックエンドを何に乗せるか、常駐方法、公開方式）は、
黙って決めずに選択肢と理由を示して私に確認すること。
- 最後に、私と違う環境の人が同じプロンプトから再構築できるよう、
「動くセットアップ手順（OS別）」を1つのREADMEにまとめること。