memory-consolidation

Backed by: state/bin/memory-consolidation/run.ts + state/lib/log.ts.

Cron job (daily 6 AM). The scheduled-agent dispatcher auto-runs state/bin/<loader_slug>/run.ts when that sidecar exists, so the memory-consolidation agent executes state/bin/memory-consolidation/run.ts. The sidecar audits memory markdown stores and appends state/log/memory-consolidation.ndjson on every tick so the heartbeat artery is concrete.

Steps

1. Run npx tsx state/bin/memory-consolidation/run.ts from the snappy-os repo root.
2. The sidecar reads .md files under state/log/memory, state/memory,

memory, and state/observations.

1. It counts exact duplicate candidates without rewriting files.
2. It appends one row to state/log/memory-consolidation.ndjson with

{ ok, files_audited, entries_processed, deduped, pruned, merged }.

1. Only perform destructive pruning/merging in a separate reviewed change after

proving the stale or duplicate entry is not still load-bearing.

Eval

Score 1.0 if memories were audited and a reviewed prune/merge changed files. Score 0.5 if the sidecar audited and appended the artery row with no changes. Score 0.0 if the sidecar could not read the memory roots or append the row.

Rubric

criteria:
  - name: log_entry_exists
    kind: deterministic
    check: "A log entry for 'memory-consolidation' exists in 'state/lib/log.ts' with fields {ok, deduped, pruned, merged}."
  - name: stale_entries_removed
    kind: judge
    check: "Auditor verifies that stale memory entries (referencing non-existent topics or files) have been removed from the '.md' files in the memory directory."
  - name: duplicates_removed
    kind: judge
    check: "Auditor verifies that duplicate memory entries have been removed, resulting in unique content."
  - name: related_memories_merged
    kind: judge
    check: "Auditor verifies that related memory entries covering the same topic have been merged into a single, consolidated entry."

memory-consolidation - loader

Per-turn rules for the memory-consolidation skill. Full reference: state/skills/memory-consolidation/SKILL.md. Do not skip these.

Critical Rules

• ALWAYS audit memories before claiming pass - score is 1.0 only if stale entries were actually removed
• A clean audit with no changes needed is 0.5, not 1.0 - the score asks "did the loop produce delta" not "did it run"
• Cron-scheduled (daily 6 AM); dispatcher auto-runs state/bin/<loader_slug>/run.ts when present
• Manual drift check: run npx tsx state/bin/memory-consolidation/run.ts from repo root

Commands

| ui model | live composition via compose_inline, persisted as artifact lang_body, reopened with OpenArtifact | |invoke: run npx tsx state/bin/memory-consolidation/run.ts |backed by: Node fs primitives + state/lib/log.ts append helpers |eval log: state/log/evals.ndjson (skill: "memory-consolidation") |artery log: state/log/memory-consolidation.ndjson

Known Pitfalls

• "Stale" means references to things that no longer exist - verify before pruning, deletion is destructive
• Score 0.0 only if the sidecar could not read memory roots or append the artery row; a successful read with no changes is 0.5

Self-Test

An agent reading this should correctly:

1. [ ] Score 0.5 (not 1.0) when audit completes with zero changes needed?
2. [ ] Verify a "stale" reference no longer exists before pruning?
3. [ ] Append the run to state/log/memory-consolidation.ndjson via state/bin/memory-consolidation/run.ts?

Found a gap? Edit this file. <!-- footer-injection-point -->