mindforge-memory 6.4.2__tar.gz → 6.4.3__tar.gz

{mindforge_memory-6.4.2/mindforge_memory.egg-info → mindforge_memory-6.4.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mindforge-memory
-Version: 6.4.2
+Version: 6.4.3
 Summary: AI Agent 终身记忆系统 - 四层记忆架构 · 知识图谱 · 多模态支持
 License: MIT
 Project-URL: Homepage, https://github.com/opok-ops/MindForge
@@ -36,11 +36,11 @@ Dynamic: license-file
 
 MindForge gives AI agents a persistent, structured long-term memory: a four-tier lifecycle model, knowledge graphs, hybrid retrieval, end-to-end encryption, and MCP / CLI / REST interfaces. All data stays on your machine.
 
-> **The story** — one developer, seven months, from v1.0 (March 2026) to v6.4.2: no team, no funding, 1,224 passing tests. [Read the journey →](https://opok-ops.github.io/MindForge/#developer)
+> **The story** — one developer, seven months, from v1.0 (March 2026) to v6.4.3: no team, no funding, 1,227 passing tests. [Read the journey →](https://opok-ops.github.io/MindForge/#developer)
 
 [![Python 3.10+](https://img.shields.io/badge/python-3.10+-blue.svg)](https://www.python.org/downloads/)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-6.4.2-green.svg)](https://github.com/opok-ops/MindForge/releases)
+[![Version](https://img.shields.io/badge/version-6.4.3-green.svg)](https://github.com/opok-ops/MindForge/releases)
 [![Stars](https://img.shields.io/github/stars/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/stargazers)
 [![Forks](https://img.shields.io/github/forks/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/forks)
 [![Open Issues](https://img.shields.io/github/issues/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/issues)
@@ -96,9 +96,10 @@ MindForge stats
 
 ## What's New
 
-v6.1.3 – v6.4.2 shipped in nine days (2026-11-01 → 11-09), guarded by **1,224 tests** (all passing).
+v6.1.3 – v6.4.3 shipped in ten days (2026-11-01 → 11-10), guarded by **1,228 tests** (1,227 passing, 1 environment-skipped).
 
-- **v6.4.2 — tens-of-thousands-chars latency: another 2×** (2026-11-09). Same-machine A/B benchmark (400 memories / ~47k chars, 3 runs each): **search p50 6.3→3.0ms (2.1×), p95 11.7→4.2ms (2.8×)**; 24k-char library p50 2.5ms; fast machine state 1.8ms. Five surgical cuts: WAL + `synchronous=NORMAL` (commits skip per-write fsync), enum-downgrade memo, `row.keys()` set reuse, first-visit access-count batching merged into one `flush_access()` transaction per search, and search-audit INSERT folded into the same commit. The v5.6.3 throttle contract and v5.5.4 `recently_accessed` semantics are pinned by 23 contract tests — all green. Compliance-grade audits still commit immediately.
+- **v6.4.3 — documentation-code consistency fix** (2026-11-10). Pre-release audit found that v6.4.2's claimed first cut — WAL + `synchronous=NORMAL` — **never landed in code**: `_get_conn()` set only `journal_mode=WAL`, leaving `synchronous` at SQLite's default FULL. The 2.1× search gain was real, but carried entirely by the other four cuts — real numbers, misattributed cause. This release adds `PRAGMA synchronous=NORMAL` on the WAL branch (per-connection, cross-thread; network-FS DELETE fallback stays FULL by design). Same-machine A/B on SSD shows no statistically significant latency delta (search p50 1.8 → 1.8ms — fsync is ~0.1ms-scale here); the benefit targets slow disks and IO-saturated containers, and more importantly makes the documented power-loss semantics (un-checkpointed access counts / search audits may be lost; compliance audits still commit immediately) actually hold. 4 new guard tests in `tests/test_v643_fixes.py`.
+- **v6.4.2 — tens-of-thousands-chars latency: another 2×** (2026-11-09). Same-machine A/B benchmark (400 memories / ~47k chars, 3 runs each): **search p50 6.3→3.0ms (2.1×), p95 11.7→4.2ms (2.8×)**; 24k-char library p50 2.5ms; fast machine state 1.8ms. Five surgical cuts: WAL + `synchronous=NORMAL` (commits skip per-write fsync), enum-downgrade memo, `row.keys()` set reuse, first-visit access-count batching merged into one `flush_access()` transaction per search, and search-audit INSERT folded into the same commit. The v5.6.3 throttle contract and v5.5.4 `recently_accessed` semantics are pinned by 23 contract tests — all green. Compliance-grade audits still commit immediately. *(Note: the `synchronous=NORMAL` cut landed in v6.4.3 — see above.)*
 - **v6.4.1 — million-character millisecond search** (2026-11-09). Scale benchmark (8,000 memories / ~990k chars) exposed a fuzzy-fallback long tail: search p95 881ms. Root causes: SequenceMatcher wasted on mathematically-impossible matches (ratio = 2M/(m+n), M ≤ m, so n ≥ 4m can never pass 0.4) + a ~50μs/entry Python full-scan tax. Fixed with a math-capped prune + SQLite-level candidate pre-filtering: **search p95 881→30.7ms (28×)**, add p50 2.6ms flat at 10k-scale. New `scripts/bench_scale.py` + CI scale guard (3000 memories, millisecond contract) + 4 behavior-level regression tests pin the semantics.
 
 - **v6.4.0 — resident daemon & performance guards** (2026-11-08). New `mindforge daemon` subcommand: line-JSON over stdio, engine resident in a long-lived process — per-request p50 2.5ms vs 400–700ms for CLI subprocess spawning (two orders of magnitude; 2026-11-09 quiet-machine re-bench: 2.5ms vs 401ms p50, ~160×). CI now guards latency (engine in-process thresholds) and daemon 13-step E2E alongside the 16-step CLI E2E guard.
@@ -166,7 +167,7 @@ v6.1.3 – v6.4.2 shipped in nine days (2026-11-01 → 11-09), guarded by **1,22
 
 ```
 ┌──────────────────────────────────────────────────────┐
-│           MindForge v6.4.2            │
+│           MindForge v6.4.3            │
 │  Cognitive Layer  Personality · KnowledgeGraph       │
 │                   MemoryEvolution · FederatedMemory  │
 ├──────────────────────────────────────────────────────┤

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/README.md

@@ -6,11 +6,11 @@
 
 MindForge gives AI agents a persistent, structured long-term memory: a four-tier lifecycle model, knowledge graphs, hybrid retrieval, end-to-end encryption, and MCP / CLI / REST interfaces. All data stays on your machine.
 
-> **The story** — one developer, seven months, from v1.0 (March 2026) to v6.4.2: no team, no funding, 1,224 passing tests. [Read the journey →](https://opok-ops.github.io/MindForge/#developer)
+> **The story** — one developer, seven months, from v1.0 (March 2026) to v6.4.3: no team, no funding, 1,227 passing tests. [Read the journey →](https://opok-ops.github.io/MindForge/#developer)
 
 [![Python 3.10+](https://img.shields.io/badge/python-3.10+-blue.svg)](https://www.python.org/downloads/)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-6.4.2-green.svg)](https://github.com/opok-ops/MindForge/releases)
+[![Version](https://img.shields.io/badge/version-6.4.3-green.svg)](https://github.com/opok-ops/MindForge/releases)
 [![Stars](https://img.shields.io/github/stars/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/stargazers)
 [![Forks](https://img.shields.io/github/forks/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/forks)
 [![Open Issues](https://img.shields.io/github/issues/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/issues)
@@ -66,9 +66,10 @@ MindForge stats
 
 ## What's New
 
-v6.1.3 – v6.4.2 shipped in nine days (2026-11-01 → 11-09), guarded by **1,224 tests** (all passing).
+v6.1.3 – v6.4.3 shipped in ten days (2026-11-01 → 11-10), guarded by **1,228 tests** (1,227 passing, 1 environment-skipped).
 
-- **v6.4.2 — tens-of-thousands-chars latency: another 2×** (2026-11-09). Same-machine A/B benchmark (400 memories / ~47k chars, 3 runs each): **search p50 6.3→3.0ms (2.1×), p95 11.7→4.2ms (2.8×)**; 24k-char library p50 2.5ms; fast machine state 1.8ms. Five surgical cuts: WAL + `synchronous=NORMAL` (commits skip per-write fsync), enum-downgrade memo, `row.keys()` set reuse, first-visit access-count batching merged into one `flush_access()` transaction per search, and search-audit INSERT folded into the same commit. The v5.6.3 throttle contract and v5.5.4 `recently_accessed` semantics are pinned by 23 contract tests — all green. Compliance-grade audits still commit immediately.
+- **v6.4.3 — documentation-code consistency fix** (2026-11-10). Pre-release audit found that v6.4.2's claimed first cut — WAL + `synchronous=NORMAL` — **never landed in code**: `_get_conn()` set only `journal_mode=WAL`, leaving `synchronous` at SQLite's default FULL. The 2.1× search gain was real, but carried entirely by the other four cuts — real numbers, misattributed cause. This release adds `PRAGMA synchronous=NORMAL` on the WAL branch (per-connection, cross-thread; network-FS DELETE fallback stays FULL by design). Same-machine A/B on SSD shows no statistically significant latency delta (search p50 1.8 → 1.8ms — fsync is ~0.1ms-scale here); the benefit targets slow disks and IO-saturated containers, and more importantly makes the documented power-loss semantics (un-checkpointed access counts / search audits may be lost; compliance audits still commit immediately) actually hold. 4 new guard tests in `tests/test_v643_fixes.py`.
+- **v6.4.2 — tens-of-thousands-chars latency: another 2×** (2026-11-09). Same-machine A/B benchmark (400 memories / ~47k chars, 3 runs each): **search p50 6.3→3.0ms (2.1×), p95 11.7→4.2ms (2.8×)**; 24k-char library p50 2.5ms; fast machine state 1.8ms. Five surgical cuts: WAL + `synchronous=NORMAL` (commits skip per-write fsync), enum-downgrade memo, `row.keys()` set reuse, first-visit access-count batching merged into one `flush_access()` transaction per search, and search-audit INSERT folded into the same commit. The v5.6.3 throttle contract and v5.5.4 `recently_accessed` semantics are pinned by 23 contract tests — all green. Compliance-grade audits still commit immediately. *(Note: the `synchronous=NORMAL` cut landed in v6.4.3 — see above.)*
 - **v6.4.1 — million-character millisecond search** (2026-11-09). Scale benchmark (8,000 memories / ~990k chars) exposed a fuzzy-fallback long tail: search p95 881ms. Root causes: SequenceMatcher wasted on mathematically-impossible matches (ratio = 2M/(m+n), M ≤ m, so n ≥ 4m can never pass 0.4) + a ~50μs/entry Python full-scan tax. Fixed with a math-capped prune + SQLite-level candidate pre-filtering: **search p95 881→30.7ms (28×)**, add p50 2.6ms flat at 10k-scale. New `scripts/bench_scale.py` + CI scale guard (3000 memories, millisecond contract) + 4 behavior-level regression tests pin the semantics.
 
 - **v6.4.0 — resident daemon & performance guards** (2026-11-08). New `mindforge daemon` subcommand: line-JSON over stdio, engine resident in a long-lived process — per-request p50 2.5ms vs 400–700ms for CLI subprocess spawning (two orders of magnitude; 2026-11-09 quiet-machine re-bench: 2.5ms vs 401ms p50, ~160×). CI now guards latency (engine in-process thresholds) and daemon 13-step E2E alongside the 16-step CLI E2E guard.
@@ -136,7 +137,7 @@ v6.1.3 – v6.4.2 shipped in nine days (2026-11-01 → 11-09), guarded by **1,22
 
 ```
 ┌──────────────────────────────────────────────────────┐
-│           MindForge v6.4.2            │
+│           MindForge v6.4.3            │
 │  Cognitive Layer  Personality · KnowledgeGraph       │
 │                   MemoryEvolution · FederatedMemory  │
 ├──────────────────────────────────────────────────────┤

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/mindforge/core/storage.py

@@ -757,6 +757,15 @@ class StorageEngine:
                 conn.execute("PRAGMA journal_mode=DELETE")
             else:
                 conn.execute("PRAGMA journal_mode=WAL")
+                # v6.4.3 fix: WAL 配套 synchronous=NORMAL（SQLite 官方推荐
+                # 组合）。v6.4.2 文档宣称了该优化但代码从未落地——本补丁
+                # 将其补齐：WAL+NORMAL 下 commit 免逐次 fsync，挂账批量
+                # 落库（search 尾事务）不再付 fsync 代价。
+                # 注意：synchronous 是 per-connection 参数，必须在每个
+                # 新连接创建时设置，仅在 WAL 分支生效；网络 FS 降级
+                # DELETE journal 的分支维持默认 FULL（远程盘耐久性语义
+                # 从严，不做削弱）。
+                conn.execute("PRAGMA synchronous=NORMAL")
             conn.execute("PRAGMA foreign_keys=ON")
             conn.execute("PRAGMA busy_timeout=5000")
             self._conn_local.conn = conn

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/mindforge/core/version.py

@@ -20,10 +20,10 @@ core/mindforge.py、cli/main.py、mcp/server.py），每处都带一份硬编码
 from typing import Tuple
 
 #: 当前发布版本（唯一真值）
-__version__: str = "6.4.2"
+__version__: str = "6.4.3"
 
 #: 结构化版本元组，便于比较（如 `VERSION_INFO >= (6, 1, 0)`）
-VERSION_INFO: Tuple[int, int, int] = (6, 4, 2)
+VERSION_INFO: Tuple[int, int, int] = (6, 4, 3)
 
 #: 下一个大版本的目标版本号（供 v6 端口预留引用）
 NEXT_MAJOR_TARGET: str = "7.0.0"

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3/mindforge_memory.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mindforge-memory
-Version: 6.4.2
+Version: 6.4.3
 Summary: AI Agent 终身记忆系统 - 四层记忆架构 · 知识图谱 · 多模态支持
 License: MIT
 Project-URL: Homepage, https://github.com/opok-ops/MindForge
@@ -36,11 +36,11 @@ Dynamic: license-file
 
 MindForge gives AI agents a persistent, structured long-term memory: a four-tier lifecycle model, knowledge graphs, hybrid retrieval, end-to-end encryption, and MCP / CLI / REST interfaces. All data stays on your machine.
 
-> **The story** — one developer, seven months, from v1.0 (March 2026) to v6.4.2: no team, no funding, 1,224 passing tests. [Read the journey →](https://opok-ops.github.io/MindForge/#developer)
+> **The story** — one developer, seven months, from v1.0 (March 2026) to v6.4.3: no team, no funding, 1,227 passing tests. [Read the journey →](https://opok-ops.github.io/MindForge/#developer)
 
 [![Python 3.10+](https://img.shields.io/badge/python-3.10+-blue.svg)](https://www.python.org/downloads/)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-6.4.2-green.svg)](https://github.com/opok-ops/MindForge/releases)
+[![Version](https://img.shields.io/badge/version-6.4.3-green.svg)](https://github.com/opok-ops/MindForge/releases)
 [![Stars](https://img.shields.io/github/stars/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/stargazers)
 [![Forks](https://img.shields.io/github/forks/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/forks)
 [![Open Issues](https://img.shields.io/github/issues/opok-ops/MindForge.svg)](https://github.com/opok-ops/MindForge/issues)
@@ -96,9 +96,10 @@ MindForge stats
 
 ## What's New
 
-v6.1.3 – v6.4.2 shipped in nine days (2026-11-01 → 11-09), guarded by **1,224 tests** (all passing).
+v6.1.3 – v6.4.3 shipped in ten days (2026-11-01 → 11-10), guarded by **1,228 tests** (1,227 passing, 1 environment-skipped).
 
-- **v6.4.2 — tens-of-thousands-chars latency: another 2×** (2026-11-09). Same-machine A/B benchmark (400 memories / ~47k chars, 3 runs each): **search p50 6.3→3.0ms (2.1×), p95 11.7→4.2ms (2.8×)**; 24k-char library p50 2.5ms; fast machine state 1.8ms. Five surgical cuts: WAL + `synchronous=NORMAL` (commits skip per-write fsync), enum-downgrade memo, `row.keys()` set reuse, first-visit access-count batching merged into one `flush_access()` transaction per search, and search-audit INSERT folded into the same commit. The v5.6.3 throttle contract and v5.5.4 `recently_accessed` semantics are pinned by 23 contract tests — all green. Compliance-grade audits still commit immediately.
+- **v6.4.3 — documentation-code consistency fix** (2026-11-10). Pre-release audit found that v6.4.2's claimed first cut — WAL + `synchronous=NORMAL` — **never landed in code**: `_get_conn()` set only `journal_mode=WAL`, leaving `synchronous` at SQLite's default FULL. The 2.1× search gain was real, but carried entirely by the other four cuts — real numbers, misattributed cause. This release adds `PRAGMA synchronous=NORMAL` on the WAL branch (per-connection, cross-thread; network-FS DELETE fallback stays FULL by design). Same-machine A/B on SSD shows no statistically significant latency delta (search p50 1.8 → 1.8ms — fsync is ~0.1ms-scale here); the benefit targets slow disks and IO-saturated containers, and more importantly makes the documented power-loss semantics (un-checkpointed access counts / search audits may be lost; compliance audits still commit immediately) actually hold. 4 new guard tests in `tests/test_v643_fixes.py`.
+- **v6.4.2 — tens-of-thousands-chars latency: another 2×** (2026-11-09). Same-machine A/B benchmark (400 memories / ~47k chars, 3 runs each): **search p50 6.3→3.0ms (2.1×), p95 11.7→4.2ms (2.8×)**; 24k-char library p50 2.5ms; fast machine state 1.8ms. Five surgical cuts: WAL + `synchronous=NORMAL` (commits skip per-write fsync), enum-downgrade memo, `row.keys()` set reuse, first-visit access-count batching merged into one `flush_access()` transaction per search, and search-audit INSERT folded into the same commit. The v5.6.3 throttle contract and v5.5.4 `recently_accessed` semantics are pinned by 23 contract tests — all green. Compliance-grade audits still commit immediately. *(Note: the `synchronous=NORMAL` cut landed in v6.4.3 — see above.)*
 - **v6.4.1 — million-character millisecond search** (2026-11-09). Scale benchmark (8,000 memories / ~990k chars) exposed a fuzzy-fallback long tail: search p95 881ms. Root causes: SequenceMatcher wasted on mathematically-impossible matches (ratio = 2M/(m+n), M ≤ m, so n ≥ 4m can never pass 0.4) + a ~50μs/entry Python full-scan tax. Fixed with a math-capped prune + SQLite-level candidate pre-filtering: **search p95 881→30.7ms (28×)**, add p50 2.6ms flat at 10k-scale. New `scripts/bench_scale.py` + CI scale guard (3000 memories, millisecond contract) + 4 behavior-level regression tests pin the semantics.
 
 - **v6.4.0 — resident daemon & performance guards** (2026-11-08). New `mindforge daemon` subcommand: line-JSON over stdio, engine resident in a long-lived process — per-request p50 2.5ms vs 400–700ms for CLI subprocess spawning (two orders of magnitude; 2026-11-09 quiet-machine re-bench: 2.5ms vs 401ms p50, ~160×). CI now guards latency (engine in-process thresholds) and daemon 13-step E2E alongside the 16-step CLI E2E guard.
@@ -166,7 +167,7 @@ v6.1.3 – v6.4.2 shipped in nine days (2026-11-01 → 11-09), guarded by **1,22
 
 ```
 ┌──────────────────────────────────────────────────────┐
-│           MindForge v6.4.2            │
+│           MindForge v6.4.3            │
 │  Cognitive Layer  Personality · KnowledgeGraph       │
 │                   MemoryEvolution · FederatedMemory  │
 ├──────────────────────────────────────────────────────┤

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/mindforge_memory.egg-info/SOURCES.txt

@@ -131,4 +131,5 @@ tests/test_v632_explain_interfaces.py
 tests/test_v635_features.py
 tests/test_v635_integration.py
 tests/test_v636_fixes.py
+tests/test_v643_fixes.py
 tests/test_v6_ports.py

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/tests/test_v568_fixes.py

@@ -39,7 +39,7 @@ import mindforge.core.version as core_version
 
 
 _REPO = Path(__file__).resolve().parent.parent
-_EXPECTED_VERSION = "6.4.2"
+_EXPECTED_VERSION = "6.4.3"
 
 # 本轮修复涉及的、必须与 mindforge/core/version.py 保持一致的源码文件
 _VERSION_TRUTH_FILES = (

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/tests/test_v575_release_consistency.py

@@ -40,8 +40,8 @@ class TestVersionTruth(unittest.TestCase):
     def test_core_version_matches_release(self):
         # 版本推进时必须一并更新此处的钉值（与 test_v568_fixes 的
         # _EXPECTED_VERSION 同一约定：让「忘记 bump 版本」在测试里显形）。
-        self.assertEqual(core_version.__version__, "6.4.2")
-        self.assertEqual(core_version.VERSION_INFO, (6, 4, 2))
+        self.assertEqual(core_version.__version__, "6.4.3")
+        self.assertEqual(core_version.VERSION_INFO, (6, 4, 3))
 
     def test_pyproject_matches_core_version(self):
         # v5.8.13 起 pyproject 不再写死静态版本：

{mindforge_memory-6.4.2 → mindforge_memory-6.4.3}/tests/test_v612_fixes.py

@@ -662,8 +662,8 @@ class TestVersionConsistency(unittest.TestCase):
     def test_version_is_612(self):
         from mindforge.core.version import VERSION_INFO, __version__
         # v6.1.3：版本钉值随发版推进更新（历史方法名保留）
-        self.assertEqual(__version__, "6.4.2")
-        self.assertEqual(VERSION_INFO, (6, 4, 2))
+        self.assertEqual(__version__, "6.4.3")
+        self.assertEqual(VERSION_INFO, (6, 4, 3))
 
     def test_json_round_trip_safety_of_preview(self):
         """save_evolution 的预览序列化不得抛（不可 json 化的对象走 str 兜底）。"""

mindforge_memory-6.4.3/tests/test_v643_fixes.py

@@ -0,0 +1,99 @@
+"""
+MindForge v6.4.3 回归测试
+
+覆盖测试过程中发现的 1 个文档-代码不一致缺陷（2026-11-10）：
+
+  - Bug-A（P0）: v6.4.2 宣称的「WAL + synchronous=NORMAL」五刀第一刀
+    从未落地——CHANGELOG/README/website 与 commit message 均宣称该
+    组合已上线，但 _get_conn() 仅设置了 journal_mode=WAL，
+    synchronous 维持 SQLite 默认 FULL（WAL 下逐 commit fsync）。
+    修复：WAL 分支补 PRAGMA synchronous=NORMAL（per-connection，
+    每连接创建时设置；网络 FS 降级 DELETE 分支维持 FULL 从严）。
+
+守卫目标：让「PRAGMA 只在部分连接生效」「优化宣称了但没落地」
+这两类回归在测试里显形。
+"""
+
+import os
+import sys
+import tempfile
+import threading
+import unittest
+from pathlib import Path
+
+sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
+
+from mindforge.core import storage as core_storage
+from mindforge.core.version import __version__
+
+
+class _WALCase(unittest.TestCase):
+    """本地盘临时库（走 WAL 分支）公共脚手架。"""
+
+    def setUp(self):
+        self.tmpdir = tempfile.TemporaryDirectory(prefix="mf_v643_fix_")
+        self.db = os.path.join(self.tmpdir.name, "memory.db")
+        self.storage = core_storage.StorageEngine(
+            db_path=self.db, encrypted=False
+        )
+
+    def tearDown(self):
+        try:
+            self.storage.close()
+        finally:
+            self.tmpdir.cleanup()
+
+
+class TestSynchronousNormalGuard(_WALCase):
+    """Bug-A 守卫：WAL + synchronous=NORMAL 必须真实生效。"""
+
+    def test_synchronous_normal_on_local_wal(self):
+        # SQLite PRAGMA synchronous 返回值：0=OFF, 1=NORMAL, 2=FULL。
+        # v6.4.2 缺陷形态即此值恒为 2（FULL）。
+        conn = self.storage._get_conn()
+        mode = conn.execute("PRAGMA synchronous").fetchone()[0]
+        self.assertEqual(
+            mode, 1,
+            f"synchronous 应为 NORMAL(1)，实际 {mode}——"
+            "v6.4.3 的 WAL+synchronous=NORMAL 修复未生效或被回退",
+        )
+
+    def test_journal_mode_wal_on_local_disk(self):
+        conn = self.storage._get_conn()
+        journal = conn.execute("PRAGMA journal_mode").fetchone()[0]
+        self.assertEqual(
+            str(journal).lower(), "wal",
+            f"本地盘 journal_mode 应为 wal，实际 {journal}",
+        )
+
+    def test_synchronous_is_per_connection(self):
+        # synchronous 是 per-connection 参数：StorageEngine 用
+        # threading.local 维护连接，新线程的连接也必须带上 NORMAL，
+        # 否则只保护了首线程（REST/daemon 多线程场景将静默回退 FULL）。
+        results = {}
+
+        def probe():
+            try:
+                conn = self.storage._get_conn()
+                results["mode"] = conn.execute(
+                    "PRAGMA synchronous"
+                ).fetchone()[0]
+            except Exception as exc:  # pragma: no cover - 显形优先
+                results["error"] = repr(exc)
+
+        t = threading.Thread(target=probe)
+        t.start()
+        t.join(timeout=10)
+        self.assertNotIn("error", results, results.get("error", ""))
+        self.assertEqual(results.get("mode"), 1)
+
+
+class TestVersionBump(unittest.TestCase):
+    """版本钉值：忘记 bump 时在此显形（与 v568/v575/v612 守卫同一约定）。"""
+
+    def test_version_is_643(self):
+        self.assertEqual(__version__, "6.4.3")
+
+
+if __name__ == "__main__":
+    unittest.main()