Docs vs shipped config: settings.system.json disables Claude auto-memory (autoMemoryEnabled: false), but MemorySystem.md and #1054 describe it as enabled/coexisting

[asdf8675309]

Following up on #1054, which was closed with an invitation to "open a fresh docs issue against the new release." In the v6 tree the relationship between LifeOS memory and Claude Code's harness auto-memory is now described three different ways, and they don't agree.

1. Shipped config — fully disabled

LifeOS/install/settings.system.json:

"autoMemoryEnabled": false,

…plus in permissions.deny:

"Write(~/.claude/projects/**/memory/**)",
"Edit(~/.claude/projects/**/memory/**)",

2. Memory docs — enabled and coexisting

LifeOS/install/LIFEOS/DOCUMENTATION/Memory/MemorySystem.md, section "Claude Code Auto-Memory & Auto-Dream":

Enabled by default (autoMemoryEnabled not set = true)

LifeOS coexists with Claude Code's built-in memory system rather than replacing it.

3. Maintainer's stated intent (#1054)

Closed by @danielmiessler with:

harness memory/ is intentionally bypassed for rules/preferences … the two systems coexist but PAI's is canonical.

The gap

Both #1054 and the Memory doc describe coexistence — harness auto-memory on, just not the home for rules/preferences. But the shipped config sets autoMemoryEnabled: false and denies writes to the harness memory dir, which is stricter: it disables auto-memory entirely — for general knowledge too, not only rules.

The changelog sides with the config — LifeOS/install/LIFEOS/ALGORITHM/changelog.md, v5.4.0 (2026-04-27):

Forbidden destination: harness auto-memory dir (already blocked by autoMemoryEnabled: false + permissions deny).

Effect on a fresh install

You read MemorySystem.md, expect harness auto-memory to be active and complementary, and it's silently off with writes denied. No error surfaces anywhere.

Question / suggested fix

Which is authoritative?

• If fully-disabled is intended (config + changelog): update the "Claude Code Auto-Memory & Auto-Dream" section of MemorySystem.md to state that harness auto-memory is disabled and learning is routed to LifeOS's own surfaces (per the v5.4.0 Unified Learning Router). The current "enabled by default / coexists" language then reads as stale carryover.
• If coexist / bypass-for-rules is intended (docs + Clarify intended relationship between PAI MEMORY/ and Claude Code's project-memory subdirectory #1054): the autoMemoryEnabled: false + memory deny rules in settings.system.json over-disable and should be reconsidered.

Either way, the three sources should be reconciled to a single answer.

(The same "enabled / coexists" wording also appears in Releases/v5.0.0/.claude/PAI/DOCUMENTATION/Memory/MemorySystem.md, consistent with stale carryover from before the v5.4.0 change.)