chore: 清理 docs 目录冗余文档（55个→9个）

删除:
- docs/1.0/ 全部22个（旧Simple KB文档，已被替代）
- docs/2.0/ 全部2个（空文件/过时）
- docs/design/ 全部4个（旧功能设计）
- docs/plans/ 旧版5个（保留v2.0设计文档）
- docs/superpowers/ 全部4个（飞书集成文档）
- docs/根目录杂项 8个（开发规范/快速参考/调试/飞书/Git设置）
- docs/3.0/knowledge_graph_analysis.md（不相关）

保留:
- docs/3.0/ 考核工作流设计 2个
- docs/plans/ v2.0设计文档 1个
- docs/tests/ 测试文档 6个
合计: 55个 → 9个

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/1.0/VECTOR_DB_COMPARISON_JA.md

@@ -1,55 +0,0 @@
-# Elasticsearch vs Chroma 比較分析
-
-Elasticsearch と Chroma は、現在人気のあるベクトルストレージソリューションですが、その設計思想と適用シナリオには大きな違いがあります。
-
-**simple-kb** のようなナレッジベースプロジェクトにおいて、Elasticsearch (ES) を選択した主な理由は、その強力な **ハイブリッド検索 (Hybrid Search)** 能力を活用するためです。
-
-以下に、両者の詳細な長所と短所の比較を示します。
-
-## コア機能の比較まとめ
-
-| 機能 | Elasticsearch (ES) | Chroma |
-| :--- | :--- | :--- |
-| **位置付け** | 汎用検索エンジン（全文検索 + ベクトル検索） | AI ネイティブ ベクトルデータベース |
-| **コアな強み** | **ハイブリッド検索** (BM25 + kNN)、強力なメタデータフィルタリング | **軽量で使いやすい**、Python 和性が高い、LLM 専用設計 |
-| **全文検索** | 👑 **業界標準** (BM25)、形態素解析、曖昧検索などをサポート | 弱い (主にベクトルの類似度に依存、テキスト検索は限定的) |
-| **リソース消費** | 🔴 **高** (Java ヒープメモリ、起動に通常 1GB+ メモリが必要) | 🟢 **極めて低い** (軽量プロセス、インメモリ実行も可能) |
-| **デプロイ・保守** | 🔴 複雑 (Java 環境、設定項目が多い) | 🟢 簡単 (`pip install` または軽量 Docker) |
-| **拡張性** | 分散クラスタが成熟しており、PB 級のデータをサポート | シングルノードは強力だが、分散クラスタ機能は比較的新しい |
-| **エコシステム** | 非常に豊富 (Kibana 可視化, Logstash など) | AI / LangChain エコシステムに特化 |
-
----
-
-## 1. Elasticsearch の長所と短所 (なぜ simple-kb で採用したのか？)
-
-**長所:**
-
-* **ハイブリッド検索 (Hybrid Search) - 決定的な機能**: RAG システムにおける最大の課題は「専門用語が検索できない」ことです。
-  * **ベクトル検索**は、意味の理解に優れています（例：「スマホ」で「iPhone」を検索可能）。
-  * **キーワード検索 (ES)** は、正確な一致に優れています（例：エラーコード「Error 503」や特定の型番「RTX 4090」）。
-  * ES はこれらを同時に実行し、スコアを加重して統合できます。これが現在の RAG システムの精度向上の鍵となります。
-* **強力なメタデータフィルタリング**: ベクトル検索の前後に、ユーザー権限、ファイルタイプ、時間範囲などのフィールドに基づいて、非常に効率的にデータをフィルタリングできます。
-* **成熟と安定**: ビッグデータ分野で10年以上の実績があります。
-
-**短所:**
-
-* **重い**: JVM ベースであり、メモリを消費します。個人開発者の小型 VPS で ES コンテナを実行するのは少し厳しい場合があります。
-* **学習コストが高い**: DSL クエリ構文が複雑で、設定が煩雑です。
-
-## 2. Chroma の長所と短所
-
-**長所:**
-
-* **開発者体験 (DX) が最高**: 「AI Native」です。API 設計が Python 開発者の直感に非常に合っており、ES のような複雑な JSON クエリを書く必要がありません。
-* **軽量**: プロトタイプの迅速な開発 (PoC)、ローカルで動作する Agent、または中小規模のアプリケーションに最適です。
-* **Embedding 内蔵**: Chroma はシンプルな Embedding モデルを簡単に内蔵でき、すぐに使用可能です。
-
-**短所:**
-
-* **キーワード検索能力が弱い**: ユーザーが Embedding モデルにとって未知の非常に具体的な単語（例：社内のプロジェクトコード名）を検索する場合、純粋なベクトル類似度では検索が難しく、ES のような転置インデックスによる検索が必要です。
-* **機能が単一**: 基本的にベクトルストレージ専用です。システムがログ保存や通常の検索も必要とする場合、別途データベースを用意する必要があります。
-
-## 結論：simple-kb における選択
-
-* **現在のアーキテクチャ (ES)**: **本番環境レベルの正確性**を選択しました。デプロイは少し手間ですが（Docker が必要）、システムが「意味的な曖昧さ」や「キーワードの正確な検索」に直面した際に、優れたパフォーマンスを発揮することを保証します。
-* **もし Chroma に変更した場合**: システムのデプロイは非常に簡単になりますが（Docker コンテナさえ不要で、Python プロセスに組み込み可能）、特定の専門用語を扱う際に BM25 キーワード検索の補助がないため、**再現率（Recall）**が低下する可能性があります。