階層性と線形性を信じない

garden.ooo には work、event、member のような投稿タイプも、カテゴリによる木構造上の分類もない。

そうした設計はその瞬間の見立てにすぎなくて、「work でもあり event でもある」ようなコンテンツが現れた瞬間に破綻する。Wordpress でauthor（著者）」というタクソノミーに著者プロフィール分を足したくなったらどうにもならないので。

コンテンツ同士の連関は「AがBに属する」のような集合論的な包含関係ではなく、「AがBを指し示す」というリンクによってのみ決まる。ページとタグの区別もしない。対象そのものの性質ではなく、対象間のリンクによって構造が浮かび上がってくる。

実装上の帰結:

• すべてのページは同一のスキーマで保存される
• 分類は tag link と body link で表現する（→ 情報設計）
• レイアウトの差異（page / grid / table）は表示上のもので、データ構造には影響しない

ローカル・ファースト

ローカルのテキストファイルが SSOT（Single Source of Truth）。クラウドはそのミラー。

アカウントすら作らずに使い始められる。データはまずブラウザの IndexedDB に入り、ディレクトリを選べばローカルの .md とも自動同期される。サーバーとの同期は、Web公開やモバイル同期が必要になって初めて選択する機能。

実装上の帰結:

• 3層構造: Local File（SSOT）↔ Local DB（RxDB/IndexedDB）↔ Remote DB（MongoDB）（→ データアーキテクチャ）
• ファイルの実体は Obsidian 互換の Markdown + YAML frontmatter
• File System Access API と FileSystemObserver でブラウザとの双方向同期を実現している

プレーンテキストは普遍的なインターフェース

ページのソースはプレーンテキスト。CMSの管理画面からだけでなく、メモ帳でも Obsidian でも Cursor でも sed でも編集できる。

Obsidian がなぜ AI 機能を急いで詰め込まないのか？ プレーンテキストを使っているから。データがただのテキストファイルなら、どんな AI システムとも勝手に統合できる。「エコシステム」を囲い込む必要がない。

実装上の帰結:

• 現時点では Markdown を採用しているけれど、HTML に変換可能な任意の軽量マークアップ言語をサポートする構想がある
• コンテンツパイプラインは source → parser → AST で設計している（→ 情報設計）

ダダ漏れをアフォードする

公的な文章から私的なメモまで、混在を許容する。ブログとニュース、リサーチとブックマーク、日記とポートフォリオを区別なく保管できる。

気体（つぶやき）から液体（アモルファス）、結晶（アーカイブ）へ。コンテンツの成熟度にグラデーションを持たせるために、公開範囲の多段階設定と archival フラグを用意している。

実装上の帰結:

• 公開範囲: public / unlisted / protected / private（→ 情報設計）
• archival フラグで永続化/エフェメラルを区別
• unlisted はリストやバックリンクに出さず、直接の言及からのみ辿れる状態

愚行権を認める

パーサーは最終的にユーザーがカスタマイズ可能になる。サーバーに送るのは {source, body(AST), ...metadata} の組で、AST の生成はクライアントサイド。サーバーはインジェクション防止等の最低限のサニタイズだけ。

ページがぐちゃぐちゃになるのはユーザーページの話なので、CMS としてはそこに関知しない。