Bound import memory with staged streaming

2 files changed, 11 insertions, 3 deletions

diff --git a/docs/Design.md b/docs/Design.md
index 3485a73..152f6ae 100644
--- a/docs/Design.md
+++ b/docs/Design.md
@@ -157,6 +157,9 @@ importはJSONLを行単位で読み、JSON stringをUTF-8へ完全decodeして�
 整数は小数・指数表記を許可せず、timestamp/updated_atは0～INT64_MAX、revisionは
 1～INT32_MAX、importanceは0～100とする。1行はcontent上限+4096 bytes、100,000 record、
 decode後合計4 GiBが上限である。file exportはtemporary fileのflush/close成功後だけ原子的に置換する。
+importは通常storeをロードせずlockだけを取得する。第1 passはcompact ID indexで全件と参照を検証し、
+第2 passは選択recordをstaging logへ直接書く。stagingのflush成功後だけactive logを原子的に置換し、
+失敗時は旧logを維持する。
 
 ## 8. I/O 予算
 
diff --git a/docs/Review.md b/docs/Review.md
index b4d351a..ed9f60c 100644
--- a/docs/Review.md
+++ b/docs/Review.md
@@ -12,7 +12,7 @@ bounded line streaming、atomic export、memory estimate、セキュリティ運
 - 比較基準: commit `1efecaef1f867cb218366e2b4ab4b901fdd2835f` 以降
 - 対象: domain、storage、MCP tools、CLI、system abstraction、tests、docs
 - 実行: Windows VS2026 Debug と ASan の build/CTest
-- 対応後結果: Debug、Release、ASanはいずれも17/17 pass
+- 対応後結果: Debug、Release、ASanはいずれも20/20 pass
 
 復旧したprotocol workflowは各構成で検索1,000回、MCP lifecycle、rebuild、restartまで成功した。
 
@@ -21,8 +21,8 @@ Release import/export benchmark（2026-07-04、同一開発機）の結果は次
 | records | import | export | round-trip import |
 |---:|---:|---:|---:|
 | 10,000 | 0.277 s | 0.165 s | 0.284 s |
-| 50,000 | 4.668 s | 4.226 s | 4.794 s |
-| 100,000 | 19.725 s | 18.465 s | 19.644 s |
+| 50,000 | 0.854 s / 12,500,992 bytes peak | 4.327 s | 0.875 s / 11,616,256 bytes peak |
+| 100,000 | 1.605 s / 16,285,696 bytes peak | 19.107 s | 1.774 s / 16,203,776 bytes peak |
 
 既存のMCP workload計測では10,000件が18,960,384 bytes、50,000件が51,240,960 bytesの
 peak working setだった。100,000件はCLI上限とround-tripを確認し、実プロセスの継続監視には
@@ -79,6 +79,11 @@ commit `2861118` で `tests/mcp_protocol_test.py` が削除されたが、`tests
 
 ### R3 — Medium: import size guard が約1 TiBで全体を一括確保する
 
+対応済み。2-pass readerは最大1行とcompact ID indexだけを保持し、第2 passで選択recordを
+`active.import.tmp`へ直接serializeする。flush後のatomic replaceまでは旧logを変更しない。
+100,001件、decoded上限±1、allocation全点、open/read/write/flush/replace失敗、dangling参照、
+truncated/長行を専用testで検証した。
+
 `IMPORT_MAX_LINE * 1024 * 1024` は約1 TiBとなる。実際には `ftell` と address space が先に制限するが、入力ファイル全体を `malloc` し、さらに parse 済み Message を保持する。
 
 影響: