Spike: consolidation pass for session-review memory writes

[SnowboardTechie]

Problem / Motivation

session-review aggressively saves per-correction feedback memories into harness auto-memory. Each save in isolation is reasonable — a real correction with a quotable line, captured at the right grain — but the cumulative effect over a short window is signal degradation.

Concrete case from the sgg project (worktree: /Users/bryan/.claude/projects/-Users-bryan-code-sgg/memory/):

• 11 feedback memories saved in 2 days (2026-05-20 → 2026-05-21).
• 7 of the 11 clustered on the same theme — "how to draft a teammate-facing reply" — across six files: pr-review-voice, reply-scope-discipline, drop-recap-inventory, close-read-source-material, engage-mental-model, draft-framing-not-policy. Each file spent a paragraph defending its distinctness from the others ("Distinct from [[pr-review-voice]] — this is the third axis, density", "different facet (format vs. scope)", "different failure mode"). When the notes themselves are working that hard to disambiguate, the granularity has exceeded the usefulness of the slicing.
• Manual consolidation (2026-05-21) collapsed 6 of those → 2 (teammate-reply-craft + teammate-reply-grounding) and rewrote a 7th (ship-dont-just-draft → post-approved-drafts) to fix a memory-drift error. Net: 7 files → 3, ~150 lines of feedback content cut to ~80, and the cross-link cruft disappeared. Substance preserved.

The retrieval surface is the load-bearing problem. MEMORY.md is always loaded into context; individual feedback files are conditionally loaded when relevant. When 7 of the index entries point at variants of the same principle, the model can't easily extract THE rule — it matches against 6+ overlapping memories with near-identical triggers instead of one comprehensive principle.

This is the same shape of problem #28 is solving for PR review findings (clustering, signal weighting), but for captured memories. Adjacent to #84 (a different specific session-review Step 9 fix), though that one is structural in the skill itself.

Proposed behavior

A research spike — not an implementation issue. Enumerate options for adding a consolidation step somewhere in the capture flow, with tradeoffs, so a follow-up issue can pick a direction with evidence.

Output of the spike: a short doc (in-repo or in-notes — implementer's call) that lists candidate approaches, sketches a representative example for each, names tradeoffs (cost, latency, false-merge risk, user friction, where the logic lives), and lands on a recommendation or a narrower set of options worth prototyping.

Scope

In scope

• Enumerating consolidation approaches. Starting set (not exhaustive, not pre-selected):
  • Consolidation prompt inside session-review at memory-write time — before adding a new memory, the skill reads existing MEMORY.md entries and asks "does this update or merge with an existing memory?" The user approves a merge vs. add-new at the same gate.
  • Periodic offline consolidation pass — a separate skill (e.g. /consolidate-memory) that the user invokes when they notice fragmentation; reads the whole memory directory, proposes merges, user approves.
  • Similarity-based deduplication at write time — semantic similarity check against existing memory descriptions; flags candidates as potential merges without forcing it.
  • Deferred saves — session-review collects feedback candidates but doesn't write to auto-memory until N similar corrections accumulate (or a session-end batch step looks across the run for clusters).
  • Two-tier memory — auto-memory writes go to a "fresh" tier first; a promotion step (manual or automatic) consolidates fresh-tier into the canonical tier.
  • Tag-or-cluster-based index — keep the granular files but reshape MEMORY.md so cluster entries collapse under one heading, reducing always-loaded context surface even when the underlying files stay split.
• Naming tradeoffs honestly — every approach has a failure mode (false merges that erase nuance, friction that suppresses captures, latency that makes session-review slower, etc.).
• Pointing at the manual consolidation that just happened in sgg as a worked example — what merged cleanly, what stayed separate, what signaled "these are actually the same principle."

Out of scope

• Picking the winning approach. The spike opens the design space; the follow-up issue narrows it.
• Implementing anything. No SKILL.md edits, no new skill files, no schema changes.
• Auto-merging existing memories without user approval. The capture-with-approval contract is load-bearing — any approach must preserve it.
• Touching the harness memory format itself. The frontmatter / MEMORY.md index shape is fixed by the harness; consolidation operates on the existing format.
• Cross-project consolidation. Auto-memory is per-project (~/.claude/projects/<slug>/memory/); the spike scopes to within-one-project fragmentation. Cross-project patterns are a follow-up question.

Implementation hints

• Worked example to reference: the 2026-05-20 → 2026-05-21 sgg cluster. Before/after files visible at /Users/bryan/.claude/projects/-Users-bryan-code-sgg/memory/. The seven originals were merged manually; reading the originals plus the two consolidated outputs (feedback_teammate_reply_craft.md, feedback_teammate_reply_grounding.md) shows what "obvious merge" looks like in practice.
• The teammate-reply cluster gave a clear signal that an approach should be able to detect: every file's body explicitly defended its distinctness from siblings. "Distinct from" / "different facet" / "different failure mode" recurring across N files is a tell that the writer is feeling the overlap. A consolidation approach could flag this textually, semantically, or both.
• Distinct from Add review-consolidation skill(s) to tally agent + human findings into a single signal view #28 (review-consolidation for PR findings): that's clustering across reviewers in one PR. This is clustering across sessions for one user, written by one skill, into one memory store. Same family, different domain — worth checking whether any of Add review-consolidation skill(s) to tally agent + human findings into a single signal view #28's primitives (capture format, finding-cluster-id, verification status) generalize, but don't force-fit.
• Watch for the memory drift failure mode: a memory saved after one correction can overgeneralize from that single moment (see the ship-dont-just-draft → post-approved-drafts rewrite — the original encoded "don't gate on a second approval" which was the opposite of the user's actual two-phase preference). Any consolidation approach should make drift easier to catch, not harder.
• The trigger for proposing this spike is itself in-scope as data: Bryan asked Claude (in sgg) to "review the session review memories cairn notes has been creating for this repo. are we bloating the agents with too much memory and context?" The fact that the question arose at all is signal — the fragmentation reached a level the user noticed without prompting.

Acceptance criteria

• A doc exists (location TBD by the spike author) enumerating at least the six approaches listed in "In scope" above, plus any others the author surfaces.
• Each approach has: a one-paragraph sketch, an example of what it would do on the sgg worked case, and 2–4 tradeoffs.
• The doc names which approaches preserve the user-approval contract and which would require relaxing it.
• The doc lands on either (a) a recommended approach with a follow-up implementation issue to file, or (b) a narrower set (2–3) worth prototyping with criteria for choosing among them.
• Closes this issue when the doc is linked from a comment.

Open questions

• Should the spike consider approaches that prevent fragmentation (write-time consolidation) separately from approaches that repair it (read-time / periodic consolidation), or treat them as one design space? Lean: treat as one, since the same user judgment ("is this a new memory or an update?") drives both — but flag if they diverge enough to need separate framings.
• Is there a lighter-weight signal than per-memory similarity that catches the "these files defend their distinctness from each other" pattern? E.g., counting cross-references in Related: blocks. Worth exploring as a cheap heuristic before reaching for embeddings.
• Should the spike scope include MEMORY.md index design separately from the underlying files? The always-loaded surface vs. the conditionally-loaded surface are different cost shapes — an approach could reshape one without touching the other.

[SnowboardTechie]

Spike resolution: drop the collaboration lens entirely

Coming back to this with a stronger conclusion than the spike's "enumerate approaches" framing called for.

Position: the right move isn't write-time consolidation, periodic offline passes, similarity dedup, deferred saves, two-tier memory, or index reshaping. It's removing the source: drop the collaboration lens from session-review entirely. Let Claude Code's native auto memory own user-preference state.

Why this beats consolidation approaches:

• Two systems writing to the same store on different heuristics is the root cause of the sgg fragmentation worked example. Every consolidation approach in the spike's "In scope" list keeps both systems running; they treat fragmentation as inevitable and try to repair it after. Removing the source fixes it at the cause.
• Claude Code's auto memory decides in-flight with stronger context about which moment actually mattered. The collaboration lens runs post-hoc across the whole transcript on its own heuristics (Q2-Q4 signal test, third-person declarative template). Post-hoc with weaker context can't win on signal quality.
• The capture-first reframing (Narrow plugin scope — extract engineering-workflow skills from cairn-notes #94, v0.6.0+) puts the plugin's center of gravity on the vault. User-preference memory was never vault content. The plugin is overstepping; trimming the overstep is consistent with the broader narrowing.
• Companion to Descope user-profile memory: rename identity.md → config.md, trim to config-only fields #96 (identity.md → config.md). That trims the config side of the same overstep; this trims the memory side. Together they finish the descope: cairn-notes owns the vault, Claude Code owns memory.

Implementation home: folds into #94's session-review rewrite (item 10 in the PR order). That rewrite is already touching session-review to convert the /issue-create call into a natural-language instruction; removing the collaboration lens lands as part of the same surgery. No separate issue needed.

Post-trim shape of session-review:

1. Technical lens → AGENTS.md / .notes/ (unchanged)
2. Tracked-items scan (today's daily plan) (unchanged)
3. Plugin-improvement lens → natural-language handoff per Narrow plugin scope — extract engineering-workflow skills from cairn-notes #94 Decision (2)

The collaboration lens, Step 1.5 destination-row routing matrix (degenerates to per-lens destinations with only two lenses left), Step 4 harness-memory row, Step 6 third-person declarative template, and "do not write to harness memory directly" guardrail all come out. The third-person declarative template is worth recovering from git history if a future feature wants a memory-handoff flow under a different name.

What about the sgg cluster? Not addressed by this resolution — those 11 memories were already written before any policy change. Manual consolidation (which already happened on 2026-05-21) is the right one-time fix; no skill needs to do it.

Closing as resolved.