[FEATURE] Priority-aware memory index: let entries be marked never-truncate, and trim by priority instead of position

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

<!-- obsidian --><p>The always-loaded memory index has a hard cap (~24.4 KB / ~200 lines). Past it, content is dropped silently — the only warning lives in the system prompt. And truncation preserves the top and drops the tail, so on a roughly chronological index <strong>you lose your newest rules and findings first.</strong></p>
<p>Production numbers from my system today:</p>

  |  
-- | --
Index, loaded every session | 17.8 KB (73% of cap)
Topic files, retrieved on demand | 302
Total cold store | ~1.3 MB
Cold-to-hot ratio | ~65:1

<p>Tiering already does enormous work — 98.5% of what the system knows is out of context. The routing table alone still trends toward the cap.</p>
<p><strong>Why position is the wrong thing to truncate on.</strong> Memory splits into two categories that behave differently:</p>
<ul>
<li><strong>Facts</strong> retrieve on demand with no loss. The agent knows it needs a value and goes and gets it.</li>
<li><strong>Priors</strong> shape judgment <em>before</em> you know you need them — "this user reaches for X under pressure," "in situation Y open with A not B."</li>
</ul>
<p><strong>A prior you have to retrieve has stopped being a prior</strong>, because its whole function is firing unprompted. You cannot look up a thing you don't know to look up.</p>
<p>So priors must stay resident and facts need not — but position in the file has no relationship to which is which. Truncating by position drops load-bearing behavioral rules and retrievable trivia with equal probability. In my own index, before I reordered it by hand today, the always-on behavioral rules sat at the bottom and would have been the first thing lost.</p>
<p>The failure is silent in the general case too: prune or truncate the wrong entry and nothing errors. You get quietly worse judgment with no signal it happened.</p>
<p>Related prior art: #34776 (closed as not planned, now locked — its automation directs filing a new issue referencing it) named "priority saturation" as one of five problems. #57574 (closed as duplicate) documented the truncation direction. This issue isolates the single smallest change that addresses both.</p>

Proposed Solution

Let the index declare priority, and make truncation respect it instead of position.

1. A priority marker on index entries. Minimal version — a section or per-line marker:

## Always-loaded
- [no-scolding rule](feedback_no_scolding.md) — never frame work as task-debt

## Retrievable
- [Kajabi offer IDs](reference_kajabi.md) — program/product/group IDs

2. Truncation trims lowest-priority first, not tail-first. If the cap is hit, drop from Retrievable until it fits. Never drop Always-loaded. If always-loaded alone exceeds the cap, that deserves a hard visible error — it's genuinely unresolvable and the user needs to know.

3. A visible warning at session start when truncation occurs — one line in the UI, not system-prompt-only. Today you find out while debugging something unrelated.

Interaction: I'd mark a memory always-loaded at write time like any other frontmatter, and stop hand-ordering my index to survive a truncation rule I had to reverse-engineer from an issue thread.

Why this rather than the larger proposal in #34776: that one asked for expiry metadata, confidence ratings, a three-layer architecture, and an audit command — and was declined, plausibly on scope. This is one behavior change to an existing mechanism. No new commands, no new file format, no retrieval engine. It makes the existing cap survivable instead of hazardous.

Current workaround: I manually reordered my index so behavioral rules sit at the top. It works, and it requires knowing an undocumented truncation direction that most users never will.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

I run a multi-agent assistant against a file-based memory system: 302 memory files, ~1.3 MB, one index loaded every session.

Today I audited the index and found it at 81% of the cap. Looking into what happens at 100%, I learned — from an issue thread, not the docs — that truncation preserves the top of the file and drops the tail.

My index was organized by topic: profile, then projects, then reference, then behavioral rules at the bottom. Those bottom entries are the ones that matter most. Things like "never frame a task list as debt," "this collaborator's name is spelled X, never Y," "lead with the hard constraint, not the backlog."

Those are priors, not facts. They fire unprompted or they don't fire at all — the agent can't retrieve what it doesn't know to look for. And they were sitting in the exact position that gets dropped first. The stuff safest to lose (backlog pointers, parked projects) was sitting at the top, protected.

I fixed it by hand: reordered so behavioral rules sit at the top and retrievable pointers at the bottom, then verified nothing was lost — 136 links before, 136 after — and the file came down to 73% of cap.

The fix works. But it required reverse-engineering an undocumented truncation direction out of a closed issue, and it means my index is now ordered for machine survival rather than human readability. I read this file too.

With a priority marker, I'd have written always-loaded on eight entries and never thought about file order again.

That's the strongest thing in the whole submission — it's a real before/after with verified numbers, and it shows the workaround and what the workaround costs. Note I kept the example rules generic on purpose; nothing personal goes into a public issue.

Additional Context

Observed on: Claude Code 2.1.220, macOS (arm64). The truncation behavior described above is as of this version.

Prior art — searched before filing:

• #34776 — memory system governance for long-running users. Named "priority saturation" as one of five problems. Closed as not planned; now locked, with automation directing affected users to open a new issue referencing it. This is that issue, narrowed to a single change.
• #57574 — MEMORY.md silently truncated at ~25KB. Documented the truncation direction and the system-prompt-only warning. Closed as duplicate.
• #27298 — layered memory system with optional semantic retrieval. Open.
• #38452 — raise the 200-line cap. Open. Worth noting these are orthogonal: raising the cap moves the crossing point without removing it, since routing completeness scales with corpus size while any fixed budget doesn't. Priority-aware truncation helps at any cap.

This isn't a single-user edge case. The #34776 thread contains three practitioners who independently converged on the same workaround:

• One reported 140+ hours of autonomous use over three months, hitting every problem in that list. Their architecture: index as a pure pointer file, frontmatter on every memory for discoverability, and a hard split between "absolute rules" (always loaded) and "knowledge" (loaded on topic match).
• The issue author returned weeks later running a near-identical architecture arrived at independently — index-only file under 100 lines, behavioral rules in a separate always-loaded location, periodic audit.
• A third built a memory-manager plugin with a UI to surface which memories are indexed, orphaned, or unindexed, because auditing by grep doesn't scale.