Cosmo memory v2 — the plan

Decisions locked. Building next. Sat 25 Apr 2026.

Eight things locked in this morning. Each was a real choice with a defensible alternative.

Every file in ~/cosmo-memory/topics/ looks the same.

---
title: Running — Phase 9 (comeback 5K)
tags: [health, running, training-plan, current]
status: active
created: 2026-04-12
updated: 2026-04-25
related: [migraine-history, running-history]
sources:
  - ~/.claude/projects/.../memory/project_phase9_comeback_5k.md
  - .claude/skills/health/current/phase9-context.md
---

# Phase 9 — comeback 5K plan

[content lives here as plain markdown]

Five fields the eventual web dashboard renders directly: title, tags (filter chips), status (badge), updated (sort order), related (nav links). Tags are a flat list — no hierarchy. The dashboard can group by tag if it wants, but the file itself doesn't know about that.

Why frontmatter and not just markdown: yesterday's research showed the prior art is split. Karpathy says "format is up to you." Stevens uses tags but no frontmatter (it's SQLite). Letta uses frontmatter but no tags (it uses directory hierarchy). We're picking the combination that works for our specific need: a future web dashboard wants structured fields to filter and sort by. Plain markdown gives the dashboard nothing.

Runs nightly at 3am. If the Mac was off, runs on next wake (catch-up logic).

Two reasons for the split:

1. Edit changes the topology. If the edit phase splits running.md into running-history.md + running-phase-9.md, every other file that referenced running now has a stale link. The link phase catches that.
2. Link is cheaper than edit. Link only needs frontmatter + first paragraph of each file, not full content. Worth a separate pass to keep edit focused on the hard work.

What the dream pass actually processes each night:

• Files modified since last run — the fresh entries
• Files flagged for review — set to status: needs-review by the hot path when something contradictory came in
• 5% rotating sample of older files — garbage-collection sweep, the whole library cycles every ~3 weeks

Typical night: 20 active files in the edit phase, ~50 files in the link phase (touched + first-degree neighbours via related:). Not the full library every night.

Each phase is a single value in the config file. If we discover Sonnet is visibly worse than Opus on the consolidate phase (see next section), we swap one constant. No code change.

The honest problem: if we only ever run Sonnet, we never see what Opus would have produced. We could ship a slightly worse system for months without noticing.

So for the first 14 nights of dream-pass operation, both models run the consolidate phase:

After 14 nights, three possible outcomes:

1. Opus is meaningfully better → swap consolidate to Opus permanently
2. Sonnet is roughly equivalent → kill the shadow, save the quota, evidence justifies the choice
3. Inconclusive → extend shadow another N nights

The mechanism is reusable. Same shadow pattern works later for "is Haiku enough for the link phase?" or "is Sonnet 4.7 better than 4.6 once it ships?"

~/cosmo-memory/tasks/active/dream-pass-shadow-review.md

---
title: Dream pass — Sonnet vs Opus shadow review
status: active
created: 2026-04-25
trigger:
  type: date
  fire_at: 2026-05-09
  mode: question
related: [plans/memory-v2, dream-pass]
---

After 14 nights of shadow-mode comparison:
- Open the diff viewer
- Read 3-5 representative diffs
- Decide: keep Sonnet, switch to Opus, or extend shadow
- Update plans/memory-v2.html with the decision
- Either flip comparison_model: off, or rotate to monthly bake-off mode

Two ways a file can leave the active set. No third option.

What we explicitly rejected: time-based auto-archive after N months idle. A reference file like australian-driving-rules.md might never get updated and still be relevant forever. Silent files aren't dead files.

Only active status loads into context by default.

Same nine steps as yesterday. Today added the prep work (commit, branch, archive boomerang) plus more detail on what each step ships.

Steps 1-3 are the core. Roughly one solid day of work, possibly less if we don't get distracted.

One thing parked. Doesn't block the build.

1. Multi-machine coordination. Old MacBook Pro might come up as an always-on host. Parked until that hardware is live. ~/cosmo-memory/ being a git repo synced to GitHub makes pull-on-wake reasonable, but real coordination (avoiding two dream passes at 3am, lock-file semantics, who-pushes-wins) is a separate design.

You read this doc. Listen to it in the car if that's easier — it's the same audio-player setup as yesterday's spec, lock-screen controls and all.

If anything in here looks wrong, push back before I start step 1. Once you say go, I:

1. Strip Qdrant + embeddings + boomerang references from src/agent.js and src/bot.js
2. Delete the live boomerang files (already archived)
3. Create ~/cosmo-memory/ with INDEX.md skeleton, SCHEMA.md (the topic file shape from section 2), empty topics/
4. Wire the new read path (router) and write path (extractor) in src/agent.js
5. Hand back for review of the running system before moving to step 2

Then bootstrap ingest. Then dream pass. Then everything else.

Doc lives at plans/memory-v2.html on the memory-v2 branch. Generated Sat 25 Apr 2026.