v6.0.0: hot-layer memory templates lack <!-- BEGIN ENTRIES --> — reads return 0 entries, writes stack orphan END markers (memory never persists)

[badosanjos]

Summary

The install templates for the two hot-layer memory files (USER/PRINCIPAL/PRINCIPAL_MEMORY.md, USER/DIGITAL_ASSISTANT/DA_MEMORY.md — see skills/LifeOS/install/USER/...) ship without the <!-- BEGIN ENTRIES --> / <!-- END ENTRIES --> marker pair that LIFEOS/TOOLS/MemoryWriter.ts requires. Result: the autonomic memory loop reports successful writes but nothing is ever readable — memory silently never persists on a fresh install.

Mechanism

• parseFile() (MemoryWriter.ts) hits its markers-missing branch → whole body becomes preEntriesBody, entries: [] → every read returns 0 entries.
• serializeFile()'s defensive branch prepends a lone END marker → every write appends entries plus one more orphan END; the next parse still finds no BEGIN, so the cycle repeats.

After a few reviewer runs our PRINCIPAL_MEMORY.md had accumulated 7 orphan <!-- END ENTRIES --> markers with unreadable entries stacked between them, while read() kept returning empty. No error surfaces anywhere — setEntries returns ok with accepted=N.

Environment

Ubuntu 24.04, LifeOS v6.0.0.

Repro

Fresh install → bun LIFEOS/TOOLS/MemoryWriter.ts test →

write 1: accepted=3, dropped_malformed=1, dropped_overlength=1, dropped_duplicates=1, evictions=0
FAIL: expected 3 entries on readback, got 0

(MemorySystem.ts test fails its "ISC-32: new entry present after curation" case for the same reason.)

Fix suggestion (two layers, both verified locally)

1. Add the marker pair to both install templates:

<!-- BEGIN ENTRIES -->
<!-- END ENTRIES -->

2. Self-heal in serializeFile() so a marker-less file converges to well-formed instead of degrading:

if (!pre.includes(BEGIN_MARKER)) {
  pre += BEGIN_MARKER + "\n";
}

With both applied, MemoryWriter test, MemorySystem test, and MemoryReviewer test all pass, and live curation persists entries. Happy to send a PR.