Findings summary

The daily-notes system is not currently an always-on session harvester. The live system is a mixed model: manual or ad hoc writes to canonical day files like [memory/2026-04-07.md](file:///Users/vinny/.openclaw/workspace/memory/2026-04-07.md), plus an enabled OpenClaw [session-memory hook](file:///opt/homebrew/lib/node_modules/openclaw/dist/bundled/session-memory/HOOK.md) that writes separate session-summary files like memory/YYYY-MM-DD-slug.md only on /new or /reset, not continuously.

Recommendation: do not build a full autopilot harvester next. First, make one canonical append path for sanitized daily notes in memory/YYYY-MM-DD.md, keep MEMORY.md promotion manual or explicitly reviewed, and move or disable raw session-summary capture so it is no longer mixed into the searchable memory/*.md corpus. This is the smallest viable path that improves capture quality and reduces privacy leakage risk.

Current state

Intended design, documented

The intended model is documented in [workspace/AGENTS.md](file:///Users/vinny/.openclaw/workspace/AGENTS.md):

• Daily notes are the first stop for raw capture, see [AGENTS.md lines 3-11](file:///Users/vinny/.openclaw/workspace/AGENTS.md).
• MEMORY.md is the distilled layer for durable preferences and rules, see [MEMORY.md](file:///Users/vinny/.openclaw/workspace/MEMORY.md).
• Heartbeats are supposed to track checks in memory/heartbeat-state.json and periodically synthesize daily notes into MEMORY.md, see [AGENTS.md lines 455-459](file:///Users/vinny/.openclaw/workspace/AGENTS.md).
• Raw daily notes are treated as private and should not be surfaced in non-private contexts, see [AGENTS.md lines 67-75](file:///Users/vinny/.openclaw/workspace/AGENTS.md).

Live behavior, confirmed

1. The only built-in automation touching memory is session snapshots on /new or /reset

OpenClaw's bundled [session-memory hook](file:///opt/homebrew/lib/node_modules/openclaw/dist/bundled/session-memory/HOOK.md) is enabled in [~/.openclaw/openclaw.json](file:///Users/vinny/.openclaw/openclaw.json). Its handler writes a new file named memory/YYYY-MM-DD-slug.md with session metadata and a conversation summary, see [handler.js lines 121-193](file:///opt/homebrew/lib/node_modules/openclaw/dist/bundled/session-memory/handler.js). The hook documentation is explicit that it runs only on /new and /reset, see [HOOK.md](file:///opt/homebrew/lib/node_modules/openclaw/dist/bundled/session-memory/HOOK.md).

This means the live automation is session-end snapshotting, not continuous capture and not canonical-day append.

2. The memory directory shows a mixed manual plus hook-driven model

Observed top-level memory/ state during this audit:

• 16 canonical date-only files such as 2026-04-03.md, 2026-04-04.md, 2026-04-07.md
• 22 hook-style session files with Session Key metadata
• 2 manual topic-specific dated files without session metadata, 2026-03-13-agents.md and 2026-04-02-late.md
• 1 project subdirectory, memory/lantronix/
• 0 memory/heartbeat-state.json file present

The file mix matches the task description: conceptually one system, operationally multiple behaviors.

3. Canonical daily notes exist, but structure is inconsistent

Canonical day files are real and active, but they are not produced by one deterministic writer:

• [memory/2026-04-03.md](file:///Users/vinny/.openclaw/workspace/memory/2026-04-03.md) contains multiple top-level day headers in one file, including a second # 2026-04-03 Daily Notes block starting at line 140.
• [memory/2026-03-11.md](file:///Users/vinny/.openclaw/workspace/memory/2026-03-11.md) is a flush-shaped note with no standard top-level day heading.
• [memory/2026-04-07.md](file:///Users/vinny/.openclaw/workspace/memory/2026-04-07.md) is very sparse compared with nearby hook-generated session files from the same date.
• At audit time, there was no [memory/2026-04-08.md](file:///Users/vinny/.openclaw/workspace/memory/) yet.

Summary stats from the current corpus:

4. Heartbeat does not currently implement daily-note synthesis

The main heartbeat is configured for every 30 minutes in [~/.openclaw/openclaw.json](file:///Users/vinny/.openclaw/openclaw.json), but the active [workspace/HEARTBEAT.md](file:///Users/vinny/.openclaw/workspace/HEARTBEAT.md) contains only a Mission Control health check. It does not include daily-note synthesis, memory promotion, or heartbeat-state tracking. The expected state file, memory/heartbeat-state.json, does not exist.

So the documented heartbeat-based curation loop is aspirational, not live.

5. There is no dedicated daily-note append script in the workspace

A targeted audit of [workspace/scripts/](file:///Users/vinny/.openclaw/workspace/scripts/) found no deterministic script for:

• appending sanitized notes into memory/YYYY-MM-DD.md
• deduping repeated flushes
• promoting resolved facts into MEMORY.md
• separating raw session capture from searchable memory

The only related operational script is [scripts/workspace-commit.sh](file:///Users/vinny/.openclaw/workspace/scripts/workspace-commit.sh), which stages everything with git add -A, commits, and pushes.

6. Raw memory is in the searchable memory corpus today

Current memory search is enabled in [~/.openclaw/openclaw.json](file:///Users/vinny/.openclaw/openclaw.json). Existing architecture docs say the current recall path indexes MEMORY.md plus memory/*.md, see [artifacts/plan-memory-artifacts-upgrade.md](file:///Users/vinny/.openclaw/workspace/artifacts/plan-memory-artifacts-upgrade.md) and [artifacts/memory_qmd_migration_plan.md](file:///Users/vinny/.openclaw/workspace/artifacts/memory_qmd_migration_plan.md).

Because hook-generated session summaries land in memory/*.md, rawer session material is mixed into the same searchable corpus as curated daily notes and durable memory. That conflicts with the privacy stance in [AGENTS.md](file:///Users/vinny/.openclaw/workspace/AGENTS.md), which treats daily notes as raw and non-shareable in group contexts.

Gaps

Live now

• Canonical date files in memory/YYYY-MM-DD.md
• Manual or ad hoc memory flushes into those files
• Manual promotion of some durable facts into [MEMORY.md](file:///Users/vinny/.openclaw/workspace/MEMORY.md)
• Session-end hook snapshots on /new or /reset
• Auto-commit infrastructure that persists file changes

Partially manual or ad hoc

• Deciding what gets written into the canonical day file
• Choosing when a topic gets its own dated file
• Merging multiple sessions into one day file cleanly
• Promoting resolved facts from daily notes into MEMORY.md
• Commit messaging after flushes, per [AGENTS.md lines 433-435](file:///Users/vinny/.openclaw/workspace/AGENTS.md)

Aspirational, not live

• Continuous session harvesting into canonical daily notes
• Heartbeat-driven synthesis from daily notes into MEMORY.md
• Tracking heartbeat checks in memory/heartbeat-state.json
• A privacy-safe split between raw session archive and searchable curated memory
• One deterministic append format with dedupe rules

Recommendation

Use a two-tier capture model and implement it in this order:

1. Canonical searchable daily notes stay in memory/YYYY-MM-DD.md.

• These should contain only sanitized, structured summaries.
• They should be append-only and deterministic.
• They become the only daily-note surface that agents are expected to consult.

1. Raw session capture should either be disabled or moved out of memory/*.md into a non-default-search location.

• Keep it only if Pete wants transcript recovery.
• If kept, store it in a path that is not treated as normal searchable memory.

1. MEMORY.md promotion should remain explicit and reviewed for now.

• Do not automate promotion inside heartbeat yet.
• First stabilize capture shape, then revisit promotion rules.

This keeps the good part of the current design, markdown as source of record, while removing the biggest current problem: raw and curated material are mixed together.

Smallest viable implementation path

Recommended path

Step 1. Create one deterministic append tool for canonical daily notes

Add a single script, for example workspace/scripts/daily-notes-append.mjs, that:

• resolves the canonical file name for the local date, memory/YYYY-MM-DD.md
• creates the file if missing
• appends a structured block under fixed sections like Decisions, Tasks, Notes, Follow-ups
• supports idempotency or dedupe via content hash or source-session key
• refuses to write obvious secrets or raw transcript dumps

The key is not sophistication. The key is one writer, one format, one destination.

Step 2. Change flush behavior to call that script, not write freeform markdown directly

Use the script only for explicit flush moments first:

• pre-compaction memory flushes
• explicit “capture this” or memory-flush prompts
• possibly end-of-task summaries for work that changed state

Do not wire full automatic harvesting yet.

Step 3. Remove raw session summaries from the searchable memory path

After Step 1 is working:

• either disable the bundled session-memory hook
• or reroute its output to a private archive path outside memory/*.md

If transcript recovery matters, keep the archive, but do not mix it with curated searchable memory.

Step 4. Reassess heartbeat only after the append path is stable

If daily-note capture quality is good after a few days, then consider adding a light heartbeat reminder or end-of-day sweep. Do not start with heartbeat-driven synthesis. Current heartbeat instructions do not define safe promotion behavior.

Implementation options

Risks

Privacy risk

This is the main risk. Today, rawer session summaries are stored in memory/*.md, and current memory search treats that directory as recall material. That makes it easier for private raw content to be recalled or surfaced in the wrong context.

Drift and duplication risk

Without one append path, the same day can accumulate multiple headings, sparse summaries, and separate topic files with overlapping scope. [memory/2026-04-03.md](file:///Users/vinny/.openclaw/workspace/memory/2026-04-03.md) is the clearest example.

Runtime complexity risk

Trying to fix this via heartbeat, hooks, prompts, and cron at the same time would touch multiple runtime pathways without a tight spec. That is the wrong first move.

Adjacent cron and logging conflict

[scripts/workspace-commit.sh](file:///Users/vinny/.openclaw/workspace/scripts/workspace-commit.sh) stages everything with git add -A. Also, adjacent task [JAM-32](file:///Users/vinny/.openclaw/workspace/mission-control/data/tasks.json) already flags auto-commit log routing and half-hour auth failures. If daily-note capture becomes more automatic before JAM-32 is handled, commit churn and notification noise will get worse.

Adjacent stale-config conflict

Adjacent task [JAM-31](file:///Users/vinny/.openclaw/workspace/mission-control/data/tasks.json) is about live stale references, including Wendy-era cron ownership. That does not block the daily-notes design decision, but it may matter before changing cron ownership or delivery wiring.

Open questions

1. Should raw session capture exist at all once canonical daily-note append is stable?
2. If raw session capture stays, what path should be explicitly excluded from searchable memory?
3. What is the minimum redaction policy for canonical daily notes, emails, phone numbers, tokens, dollar amounts, medical details, contact details?
4. When should MEMORY.md promotion happen: manual review only, end-of-day review, or task-close review?
5. Should project-specific note folders like memory/lantronix/ remain in memory, or move into artifacts when they are work product rather than durable recall?

Review note captured after delivery

Pete confirmed this task should move to review and explicitly reinforced a workflow preference: when sharing artifacts with him, always provide the HTTP artifact URL, preferably the Tailscale artifact link, not just a local file path. This should be treated as a durable workflow rule for future handoffs.

Suggested next action

Create a small implementation spec for Option A only:

• one append-only canonical daily-note script
• one sanitized section schema
• one dedupe rule
• one decision on what happens to the existing session-memory hook output

Do not implement heartbeat synthesis or full auto-harvest until that spec is reviewed.

ready for review: yes