This fixes a genuine production pain point — WAL files growing to gigabytes silently is something we've run into with high-frequency add_drawer patterns.

The implementation is clean. A few observations:

Overhead: _wal_rotate() calls _WAL_FILE.stat() on every single write. For high-throughput workloads this is a syscall per write. Not catastrophic, but could be batched (e.g., only check every N writes or every 60 seconds). At 10 MB / ~500 bytes per entry that's ~20,000 writes between rotations, so the amortized cost is low. Fine as-is.

Single backup race: If two concurrent writers both hit _wal_rotate() just as the file crosses 10 MB, both will try to rename and one will get FileNotFoundError. This is caught by the outer except Exception and logged, so it won't blow up — but the second caller will then write to a fresh file and the backup from the first rotation will be intact. Acceptable behavior.

0o600 permissions: chmod after rename is a TOCTOU window — the file is temporarily accessible at the backup path without restricted permissions. Ideally you'd rename to a temp path, chmod, then rename to .1. Minor, but worth noting if the WAL contains sensitive memory contents (it does).

The f-string → %s logging fix is a nice bonus (avoids evaluating the format string when the log level is filtered).

Overall: the core fix is correct and the edge cases are non-fatal. LGTM.

WAL rotation is a sensible maintenance feature — unbounded growth is a real operational problem for anyone running intensive agent workloads. The 10 MB threshold is a reasonable default.

A few design notes:

Backup count: A single .jsonl.1 backup means you lose visibility into entries older than one rotation cycle. For most use cases that's fine, but if someone is using the WAL for audit purposes (e.g. replay after palace corruption), losing the .1 file on the second rotation is surprising. Worth documenting the retention policy explicitly — even a comment in _wal_rotate() saying "only the most recent backup is kept; use wal_replay before WAL grows >10 MB if you need full audit history" would set expectations correctly.

Rotation under concurrent writers: If two processes call _wal_log() near-simultaneously and both observe the size threshold, both may try to rename write_log.jsonl to write_log.jsonl.1. On POSIX, os.rename is atomic so one will win and the other will rotate an already-rotated file — resulting in some entries in .1 getting overwritten. For single-process use this is fine; for multi-process MCP server setups, worth a file lock around the rotate-then-reopen sequence. A simple fcntl.flock on the WAL file would cover it.

Missing tests: The checklist shows all four test scenarios as unchecked. These aren't hard to write — a tmp_path fixture with a pre-seeded WAL file over the threshold, assert that .1 is created and the original is reset. Would be good to have them before merge.

Configurable threshold: _WAL_MAX_BYTES as a module constant is the right approach — clean and easy to override in tests. Alternatively, expose it via mempalace.yaml config (wal_max_bytes: 10_000_000) so operators running high-throughput pipelines can tune it without patching.

Directionally right. The core logic is straightforward — the concurrent writer edge case is the main thing worth hardening before this goes to production.

[MemPalace-AGI integration — 215 tests, 710 KG entities]