nene2-python 1.0.0__tar.gz → 1.2.0__tar.gz

{nene2_python-1.0.0 → nene2_python-1.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: nene2-python
-Version: 1.0.0
+Version: 1.2.0
 Summary: NENE2 Python — minimal API framework following NENE2's design philosophy
 Project-URL: Homepage, https://github.com/hideyukiMORI/nene2-python
 Project-URL: Repository, https://github.com/hideyukiMORI/nene2-python

nene2_python-1.2.0/docs/field-trials/2026-05-field-trial-7.md

@@ -0,0 +1,170 @@
+# Field Trial 7 — bookmark: PyPI publish フロー DX 検証
+
+## Date
+
+2026-05-20
+
+## Baseline
+
+- nene2-python v1.0.0（**PyPI 経由** `uv add nene2-python`）
+- Python 3.14（uv managed）
+- プロジェクト: **bookmark** — ブックマーク管理 JSON API
+- エンティティ: `Bookmark`（id, title, url, description）
+- 5 エンドポイント: CRUD（List / Get / Create / Update / Delete）
+- InMemory リポジトリのみ（SQLite なし）
+- **目標**: `pip install nene2-python` → ゼロ設定で動く API を構築できるか
+
+## Goal
+
+1. PyPI 公開フローの DX 検証（TestPyPI → PyPI 本番）
+2. `uv add nene2-python`（PyPI 経由）でのインストールが正常に機能するか確認
+3. 公開パッケージだけを使ってブックマーク API を構築する E2E DX 検証
+
+---
+
+## Steps Taken
+
+### 1. PyPI 公開フロー
+
+#### TestPyPI
+
+- GitHub Actions OIDC（Trusted Publishing）を設定
+- `uv publish --trusted-publishing always` を使用
+- `pypa/gh-action-pypi-publish@release/v1` は Docker コンテナ内で実行されるため、
+  GitHub Actions の Docker ネットワークで DNS 解決が失敗する問題が発生
+  → `uv publish` をランナー直接実行に切り替えて解決
+
+#### PyPI 本番
+
+- TestPyPI 確認後、同一ワークフローで本番 PyPI へ publish
+- GitHub Release を自動生成（`gh release create`）
+
+### 2. プロジェクト初期化
+
+```bash
+uv init --name bookmark --no-workspace
+uv add nene2-python   # PyPI から v1.0.0 をインストール
+```
+
+追加設定不要。`nene2-python` が FastAPI・Pydantic・SQLAlchemy・structlog をすべて束ねているため、
+依存関係の解決は `uv add nene2-python` 一行で完了。
+
+### 3. ドメイン層の実装
+
+Clean Architecture の4層（entity / exceptions / repository / use_case）を独立して記述：
+
+```python
+# entity.py
+@dataclass(frozen=True, slots=True)
+class Bookmark:
+    id: int
+    title: str
+    url: str
+    description: str
+```
+
+`nene2` からインポートが必要なのは exceptions のみ：
+```python
+from nene2.http import problem_details_response
+from nene2.middleware.domain_exception import DomainExceptionHandlerProtocol
+```
+
+UseCase・Repository・Entity は nene2 に依存しないため、フレームワーク非依存のビジネスロジックとして成立。
+
+### 4. HTTP 層の実装
+
+`handler.py` で `nene2.http`・`nene2.validation` を使用：
+
+```python
+from nene2.http import PaginationQueryParser, PaginationResponse
+from nene2.validation.exceptions import ValidationError, ValidationException
+```
+
+パターンは example/note/handler.py と完全に同じ。5分で移植可能。
+
+### 5. アプリケーションファクトリ
+
+`app.py` でミドルウェアをスタックして完成：
+
+```python
+from nene2.config import AppSettings
+from nene2.middleware import (
+    ErrorHandlerMiddleware, RequestIdMiddleware,
+    RequestLoggingMiddleware, RequestSizeLimitMiddleware,
+    SecurityHeadersMiddleware,
+)
+```
+
+ミドルウェア登録は innermost-first 順で明示的（ドキュメントにコメントあり）。
+
+### 6. 動作確認
+
+```bash
+uv run uvicorn app:app --port 8090
+```
+
+```
+POST /bookmarks  {"title":"GitHub","url":"https://github.com","description":"Code hosting"}
+→ 201  {"id":1,"title":"GitHub","url":"https://github.com","description":"Code hosting"}
+
+GET  /bookmarks?limit=10&offset=0
+→ 200  {"items":[...],"limit":10,"offset":0,"total":2}
+
+GET  /bookmarks/1
+→ 200  {"id":1,...}
+
+PUT  /bookmarks/1  {"title":"GitHub Updated","url":"https://github.com","description":"World's largest code host"}
+→ 200  {"id":1,"title":"GitHub Updated",...}
+
+DELETE /bookmarks/2
+→ 204
+
+GET  /bookmarks/99
+→ 404  {"type":"https://nene2.dev/problems/not-found","title":"Not Found","status":404,"detail":"Bookmark 99 not found."}
+
+POST /bookmarks  {"title":"   ","url":"https://example.com","description":""}
+→ 422  {"type":"https://nene2.dev/problems/validation-failed","errors":[{"field":"title","message":"Title must not be empty.","code":"required"}]}
+```
+
+全エンドポイントが期待通りに動作。Problem Details（RFC 9457）レスポンスも正常。
+
+---
+
+## Friction Points
+
+### FT7-1: Docker DNS 問題（`pypa/gh-action-pypi-publish`）
+
+- **摩擦**: `pypa/gh-action-pypi-publish@release/v1` を使用すると、Docker コンテナ内で
+  `upload.test.pypi.org` の DNS 解決に失敗する
+- **深刻度**: HIGH（公開ブロック）
+- **解決策**: `uv publish --trusted-publishing always` をランナー直接実行に切り替え
+- **所要時間**: ワークフロー修正・デバッグで約 1 時間
+
+### FT7-2: `[tool.uv] dev-dependencies` → `[dependency-groups]` 変更
+
+- **摩擦**: `uv init` が生成した `pyproject.toml` に旧形式の `[tool.uv] dev-dependencies` が含まれる場合がある（uv バージョン依存）
+- **深刻度**: LOW（警告のみ）
+- **解決策**: `[dependency-groups] dev` 形式に更新
+
+### FT7-3: `InMemoryRepository` を毎回自前実装
+
+- **摩擦**: テスト用 InMemory Repository をドメインごとにゼロから書く必要がある
+- **深刻度**: LOW（パターンが明確なため機械的に書ける）
+- **検討**: `GenericInMemoryRepository[T]` のような汎用実装をフレームワークに含めるか検討余地あり
+
+---
+
+## Summary
+
+| ID     | 摩擦                                      | 深刻度 | 種別          | Follow-up |
+|--------|-------------------------------------------|--------|---------------|-----------|
+| FT7-1  | Docker DNS で pypa action が失敗          | HIGH   | インフラ      | 解決済み（uv publish に切り替え） |
+| FT7-2  | dev-dependencies フォーマット警告         | LOW    | DX            | 解決済み（PR #154） |
+| FT7-3  | InMemory Repository を毎回書く            | LOW    | フレームワーク | 検討余地あり |
+
+FT7 の主目的（PyPI 公開 → インストール → 動く API 構築）は達成。
+`uv add nene2-python` の一行でフレームワーク全体が入り、
+Clean Architecture パターンをゼロから構築するのに要した時間は **30分以内**（ドメイン4ファイル + handler + app）。
+
+**PyPI publish パイプライン（TestPyPI → PyPI → GitHub Release）は確立済み。**
+FT8 候補：MySQL/PostgreSQL アダプターの実地検証、または親子リソース（nested REST）DX 検証。

nene2_python-1.2.0/docs/field-trials/2026-05-field-trial-8.md

@@ -0,0 +1,218 @@
+# Field Trial 8 — blog: 親子リソース (Nested REST) + datetime + SQLite 複数エンティティ
+
+## Date
+
+2026-05-20
+
+## Baseline
+
+- nene2-python v1.0.0（PyPI 経由 `uv add nene2-python`）
+- Python 3.14（uv managed）
+- プロジェクト: **blog** — ブログ API（投稿 + コメント）
+- エンティティ:
+  - `Post(id, title, body, created_at: datetime)`
+  - `Comment(id, post_id, author, body, created_at: datetime)`
+- SQLite ファイル永続化（`blog.db`）
+- 8 エンドポイント: Post CRUD + コメント List/Create/Delete（Nested REST）
+
+## Goal
+
+FT1〜FT7 で未探索のパターンを一度に検証：
+
+1. **親子リソース（Nested REST）**: `GET /posts/{id}/comments`、`POST /posts/{id}/comments`
+2. **`datetime` フィールドを持つエンティティ**: `created_at` が SQLite → entity → JSON でどう流れるか
+3. **SQLite 外部キー**: 2エンティティ間の参照整合性（`ON DELETE CASCADE`）
+4. **`DatabaseHealthCheck`** の実際の動作確認
+
+---
+
+## Steps Taken
+
+### 1. プロジェクト初期化
+
+問題なし。`uv add nene2-python` 一行で完了。
+
+### 2. エンティティに `datetime` フィールドを追加
+
+```python
+@dataclass(frozen=True, slots=True)
+class Post:
+    id: int
+    title: str
+    body: str
+    created_at: datetime   # ← FT1〜FT7 で一度も使われなかったフィールド
+```
+
+FT1〜FT7 の全エンティティ（Note, Book, Task, Snippet, Wallet, City, Bookmark）は
+`created_at` を持っていない。example の Note も schema に `created_at` カラムはあるが
+エンティティ定義には含まれていない。**datetime フィールドの扱いは前例なし。**
+
+### 3. SQLite スキーマ（外部キー + `CURRENT_TIMESTAMP`）
+
+```python
+# PRAGMA foreign_keys=ON で参照整合性を有効化
+@event.listens_for(Engine, "connect")
+def _set_sqlite_pragma(dbapi_conn, _):
+    if isinstance(dbapi_conn, sqlite3.Connection):
+        dbapi_conn.execute("PRAGMA foreign_keys=ON")
+
+# comments テーブルに外部キー
+"post_id INTEGER NOT NULL REFERENCES posts(id) ON DELETE CASCADE"
+```
+
+`PRAGMA foreign_keys=ON` は example の schema.py を参照して発見。ドキュメントには記載なし。
+
+### 4. SQLAlchemy Repository での datetime 変換
+
+```python
+def _to_post(row: dict[str, Any]) -> Post:
+    return Post(
+        id=row["id"],
+        title=row["title"],
+        body=row["body"],
+        # SQLite は DATETIME を text 型で返す: "2026-05-20 12:34:56"
+        created_at=datetime.fromisoformat(str(row["created_at"])).replace(tzinfo=timezone.utc),
+    )
+```
+
+### 5. SELECT-after-INSERT パターン（DB生成タイムスタンプを取得）
+
+```python
+def save(self, title: str, body: str) -> Post:
+    new_id = self._executor.write(
+        "INSERT INTO posts (title, body) VALUES (:title, :body)",
+        {"title": title, "body": body},
+    )
+    row = self._executor.fetch_one(
+        "SELECT id, title, body, created_at FROM posts WHERE id = :id",
+        {"id": new_id},
+    )
+    if row is None:
+        raise RuntimeError(f"Row {new_id} not found after INSERT into posts")
+    return _to_post(row)
+```
+
+INSERT → `write()` → `lastrowid` → `fetch_one()` の2往復が必要。
+
+### 6. Nested REST ハンドラー
+
+```python
+@router.get("/posts/{post_id}/comments")
+async def list_comments(post_id: int, request: Request) -> JSONResponse:
+    pagination = PaginationQueryParser.parse(request)
+    output = list_comments_use_case.execute(
+        ListCommentsInput(post_id, pagination.limit, pagination.offset)
+    )
+    ...
+
+@router.post("/posts/{post_id}/comments", status_code=201)
+async def create_comment(post_id: int, body: CreateCommentBody) -> JSONResponse:
+    ...
+```
+
+FastAPI がパスパラメータ `post_id` を UseCase に渡すため、ネストの実装自体は自然。
+
+### 7. 動作確認
+
+```
+GET  /health
+→ 200  {"status":"ok","checks":{"database":"ok"}}  ← DatabaseHealthCheck 正常
+
+POST /posts  {"title":"Hello nene2","body":"First post"}
+→ 201  {"id":1,"title":"Hello nene2","body":"First post","created_at":"2026-05-19T18:39:52+00:00"}
+
+POST /posts/1/comments  {"author":"Alice","body":"Great!"}
+→ 201  {"id":1,"post_id":1,"author":"Alice","body":"Great!","created_at":"2026-05-19T18:39:52+00:00"}
+
+GET  /posts/1/comments?limit=10
+→ 200  {"items":[...],"limit":10,"offset":0,"total":1}
+
+POST /posts/999/comments  {...}
+→ 404  {"type":"...not-found","detail":"Post 999 not found."}
+
+DELETE /posts/1
+→ 204  (cascade: comments も自動削除)
+
+GET  /posts/1/comments  (削除後)
+→ 404  Post 1 not found.
+```
+
+---
+
+## Friction Points
+
+### FT8-1: SQLite `CURRENT_TIMESTAMP` が naive datetime を返す — タイムゾーン情報が失われる
+
+- **摩擦**: `CURRENT_TIMESTAMP` は UTC 時刻だが SQLite は `"2026-05-20 12:34:56"` という文字列で格納・返却する
+- `datetime.fromisoformat("2026-05-20 12:34:56")` は **naive datetime**（tzinfo なし）を返す
+- JSON にシリアライズすると `"2026-05-20T12:34:56"` — タイムゾーンが不明な時刻として API に漏れる
+- **深刻度**: MEDIUM（API 利用者が UTC か JST か判断できない）
+- **解決策**: `.replace(tzinfo=timezone.utc)` を明示的に追加
+- **nene2 の対応**: `fetch_one` / `fetch_all` の戻り値に datetime フィールドのガイダンスがない
+
+### FT8-2: `dict[str, object]` vs `dict[str, Any]` — 型注釈の落とし穴
+
+- **摩擦**: `_to_post(row: dict[str, object])` と書くと `int(row["id"])` が mypy `call-overload` エラー
+- `# type: ignore[arg-type]` を付けると「wrong error code」で `unused-ignore` が発生（二重エラー）
+- **深刻度**: MEDIUM（mypy --strict を使う場合にブロッキング）
+- **解決策**: `dict[str, Any]` を使う（`fetch_one()` の実際の戻り値型と一致）
+- **根本原因**: nene2 の「row-to-entity 変換」サンプルに datetime フィールドがない
+
+### FT8-3: SELECT-after-INSERT のボイラープレート
+
+- **摩擦**: DB 生成の `CURRENT_TIMESTAMP` を取得するために INSERT → `lastrowid` → `fetch_one` の2往復が必要
+- 毎 `save()` メソッドに同じパターンを書く（PostRepository と CommentRepository の両方）
+- `fetch_one()` は `dict | None` を返すため、`if row is None: raise RuntimeError(...)` が必要
+  - `assert row is not None` は ruff S101（本番コードで assert 禁止）で弾かれる
+- **深刻度**: LOW（機能するが冗長）
+- **検討**: `write_and_return(sql, params, select_sql)` のようなヘルパーをフレームワークに追加するか
+
+### FT8-4: if/else で異なる実装を変数に代入すると mypy エラー
+
+- **摩擦**:
+
+  ```python
+  if cfg.db_adapter == "sqlite":
+      post_repo = SqlAlchemyPostRepository(executor)
+  else:
+      post_repo = InMemoryPostRepository()  # ← mypy: Incompatible types
+  ```
+
+- `mypy --strict` が `Incompatible types in assignment` を報告
+- **解決策**: 事前に型注釈を宣言する
+
+  ```python
+  post_repo: PostRepositoryInterface
+  ```
+
+- **深刻度**: LOW（パターンを一度知れば1行で解決）
+- example の `app.py` は `_build_repositories()` 関数で隠蔽しているため、このエラーが見えにくい
+
+### FT8-5: Nested REST の `post_id` パスパラメータが DELETE で無視される — 設計の穴
+
+- **摩擦**: `DELETE /posts/{post_id}/comments/{comment_id}` の `post_id` を DELETE ハンドラーが無視する
+- `DELETE /posts/1/comments/2` が post 2 のコメント2（別ポストのコメント）を削除できてしまう
+- REST セマンティクス的には `/posts/1/comments/2` は「post 1 に属するコメント2」を指すべき
+- **深刻度**: MEDIUM（アクセス制御がある場合はセキュリティ問題になりうる）
+- **解決策**: DELETE UseCase に `post_id` を含め、コメントの `post_id` と一致するか検証する
+- **nene2 の対応**: ネストリソースの DELETE 設計についてガイダンスなし
+
+---
+
+## Summary
+
+| ID     | 摩擦                                          | 深刻度 | 種別           | 解決策                              |
+|--------|-----------------------------------------------|--------|----------------|-------------------------------------|
+| FT8-1  | SQLite naive datetime — TZ情報が失われる      | MEDIUM | 設計/DB        | `.replace(tzinfo=timezone.utc)`    |
+| FT8-2  | `dict[str, object]` vs `Any` — mypy エラー  | MEDIUM | 型安全         | `dict[str, Any]` を使う            |
+| FT8-3  | SELECT-after-INSERT ボイラープレート          | LOW    | フレームワーク | `write_and_return()` ヘルパー検討  |
+| FT8-4  | if/else 分岐での型注釈宣言が必要             | LOW    | 型安全         | `var: InterfaceType` を先に宣言    |
+| FT8-5  | Nested DELETE で `post_id` が無視される       | MEDIUM | 設計           | UseCase に `post_id` を追加して検証 |
+
+親子リソース（Nested REST）そのものの実装は **摩擦ゼロ** — FastAPI のパスパラメータが自然に機能した。
+主な摩擦は `datetime` フィールドと `mypy --strict` 周辺に集中。
+
+FT9 候補:
+- **FT8-1/FT8-3 の改善**: nene2 フレームワークに `datetime` ユーティリティ / `write_and_return()` を追加して検証
+- **MySQL/PostgreSQL**: SQLite 以外のアダプター（`RETURNING` 句が使えるので FT8-3 が解消されるか検証）
+- **HttpxMcpClient**: HTTP モードの MCP クライアントを実地検証

nene2_python-1.2.0/docs/field-trials/2026-05-field-trial-9.md

@@ -0,0 +1,151 @@
+# Field Trial 9 — recipe: HttpxMcpClient + streamable-http トランスポート DX 検証
+
+## Date
+
+2026-05-20
+
+## Baseline
+
+- nene2-python v1.1.0（PyPI 経由）→ LocalMcpServer 修正後は local editable
+- Python 3.14（uv managed）
+- プロジェクト: **recipe** — レシピ管理 API
+- エンティティ: `Recipe(id, title, description, servings)`
+- HTTP API: ポート 8100（FastAPI + InMemory）
+- MCP サーバー: ポート 8101（`streamable-http` トランスポート）
+- MCP ツール: `HttpxMcpClient` で HTTP API を呼び出してデータ共有
+
+## Goal
+
+FT1〜FT8 で未探索のパターンを検証：
+
+1. **`LocalMcpServer.run(transport="streamable-http")`** — HTTP モード MCP の起動
+2. **`HttpxMcpClient`** — MCP ツールハンドラーから HTTP API を呼び出してデータ共有
+3. FT3-F2（MCP と HTTP API のメモリ非共有問題）の正しい解決パターンを実証
+
+---
+
+## Steps Taken
+
+### 1. HTTP API + MCP サーバーの二段構成
+
+```
+HTTP API（app.py, port 8100）
+    ↑ HTTP calls
+MCP Server（mcp_server.py, port 8101）
+    ↓ streamable-http
+Claude / MCP Client
+```
+
+MCP ツールが `HttpxMcpClient` で HTTP API を叩くため、どちらの経路から書いても同じデータが見える。
+
+### 2. HttpxMcpClient でのツール実装
+
+```python
+from nene2.mcp import LocalMcpServer
+from nene2.mcp.http_client import HttpxMcpClient
+
+client = HttpxMcpClient()
+server = LocalMcpServer("recipe-api", instructions="...", port=8101)
+
+@server.tool("List all recipes. Returns paginated results.")
+def list_recipes(limit: int = 20, offset: int = 0) -> str:
+    response = client.get(API_BASE, f"/recipes?limit={limit}&offset={offset}")
+    return response.body
+
+@server.tool("Create a new recipe.")
+def create_recipe(title: str, description: str, servings: int) -> str:
+    response = client.post(API_BASE, "/recipes",
+        {"title": title, "description": description, "servings": servings})
+    return response.body
+```
+
+### 3. 動作確認
+
+```bash
+# HTTP API で作成 → MCP ツールから見える
+curl -X POST http://localhost:8100/recipes -d '{"title":"Ramen",...}' → {"id":1,...}
+MCP: list_recipes() → {"items":[{"id":1,"title":"Ramen",...}],...}
+
+# MCP ツールで作成 → HTTP API から見える
+MCP: create_recipe("Sushi",...) → {"id":2,...}
+curl GET http://localhost:8100/recipes → [Ramen, Sushi]
+```
+
+**FT3-F2 の解決確認**: HTTP API と MCP が `HttpxMcpClient` 経由で完全にデータを共有。
+
+### 4. streamable-http プロトコルのフロー
+
+```
+POST /mcp (initialize) → Session-ID: {uuid} を取得
+POST /mcp + Mcp-Session-Id: {uuid} (tools/list, tools/call)
+```
+
+stdio と異なり、MCP セッション管理が必要。HTTP クライアントライブラリや Claude Desktop が処理するため、手動操作は検証時のみ。
+
+---
+
+## Friction Points
+
+### FT9-1: `LocalMcpServer` にポート指定がない
+
+- **摩擦**: `LocalMcpServer.run(transport="streamable-http")` のデフォルトポートが 8000 で変更不可
+- `FastMCP.__init__` は `host`/`port` を受け取るが、`LocalMcpServer.__init__` が渡していなかった
+- HTTP API（8100）と MCP（8101）を同一マシンで動かす際にポート衝突が起きる
+- **深刻度**: HIGH（2サービス構成で必ずぶつかる）
+- **解決策**: `LocalMcpServer.__init__(name, instructions, *, host, port)` に追加済み（PR #174）
+
+### FT9-2: HTTP エラー（404 等）が `isError: false` で返る
+
+- **摩擦**: MCP ツールが `return response.body` で 404 レスポンスをそのまま返すと、
+  MCP プロトコルの `isError` フラグが `false` になる
+- AI クライアントがエラーを成功として解釈する可能性がある
+- **深刻度**: MEDIUM（AI がエラーを無視して誤った操作を続けるリスク）
+- **解決策**: `McpHttpResponse.raise_for_error()` を追加 → FastMCP が例外を `isError: true` に変換（PR #174）
+
+  ```python
+  def get_recipe(recipe_id: int) -> str:
+      response = client.get(API_BASE, f"/recipes/{recipe_id}")
+      response.raise_for_error()   # ← 追加: 4xx/5xx を例外に変換
+      return response.body
+  ```
+
+### FT9-3: DELETE が 204 No Content を返し `response.body` が空
+
+- **摩擦**: DELETE エンドポイントは 204 を返すため `response.body` が空文字列 `""`
+- MCP ツールの戻り値が `""` になり、AI が「削除完了」を確認できない
+- **解決策**: 明示的に確認メッセージを組み立てる（フレームワークは解決不要、パターンとして文書化）
+
+  ```python
+  def delete_recipe(recipe_id: int) -> str:
+      response = client.delete(API_BASE, f"/recipes/{recipe_id}")
+      response.raise_for_error()
+      if response.status_code == 204:
+          return json.dumps({"deleted": True, "recipe_id": recipe_id})
+      return response.body
+  ```
+
+### FT9-4: streamable-http はセッション管理が必要（stdio より複雑）
+
+- **摩擦**: stdio はプロセス間通信で自動管理されるが、HTTP モードは `initialize` → Session ID → ツール呼び出し の2ステップ
+- Claude Desktop や MCP SDK クライアントが透過的に処理するため、**実際の利用では問題にならない**
+- ただしデバッグ時（curl で直接叩く）には手順が煩雑
+- **深刻度**: LOW（ツール側の問題ではなく、デバッグ時の利便性の問題）
+
+---
+
+## Summary
+
+| ID     | 摩擦                                            | 深刻度 | 解決策                                        |
+|--------|-------------------------------------------------|--------|-----------------------------------------------|
+| FT9-1  | LocalMcpServer にポート指定がない               | HIGH   | `host`/`port` 引数追加済み（PR #174）         |
+| FT9-2  | HTTP エラーが isError: false で返る             | MEDIUM | `raise_for_error()` 追加済み（PR #174）       |
+| FT9-3  | DELETE 204 で body が空 → AI が確認できない     | LOW    | パターンとして文書化（json.dumps で補完）      |
+| FT9-4  | streamable-http のセッション管理が手動で煩雑    | LOW    | クライアント SDK が透過処理するので運用上は問題なし |
+
+**`HttpxMcpClient` + `streamable-http` の組み合わせは FT3-F2 の正しい解決策として機能した。**
+HTTP API を中継することで、MCP と HTTP クライアントが完全にデータを共有できる。
+
+FT10 候補:
+- **MySQL/PostgreSQL アダプター**: SQLite 以外の DB を初めて FT で使用
+- **`BearerTokenMiddleware` + `HttpxMcpClient`**: 認証付き API に対して MCP から呼び出す
+- **`LocalMcpServer` の SSE トランスポート**: `streamable-http` との差異を確認