[FEATURE] Triggered injection for auto-memory topic files (rules-style frontmatter)

The initiative gap in these runs is compelling. I agree that path/event triggers are a better delivery primitive than hoping the model remembers to query its own memory.

One design boundary I would add: a trigger should decide when a memory is considered, not automatically grant that memory instruction authority. A path match can be true while the remembered fact is already stale.

For a first-party implementation, I would want each injected item to carry a small recall envelope:

• source memory file and source session/date
• project/worktree scope
• trigger reason (path, post-compaction, or both)
• freshness signal, ideally the anchored file/blob fingerprint from when the note was learned
• explicit verify, revise, and forget actions

If the anchored code changed after the memory was written, the harness could still deliver the note, but mark it stale — re-check against current code rather than silently treating it as active guidance. That distinction matters for examples like route ordering: the exact gotcha may disappear while the glob continues matching forever.

I would also keep post-compaction delivery bounded to an active recall digest, rather than replaying every topic file whose event matches. The full records can remain addressable, while the digest preserves the few facts that actually influenced the pre-compaction task. Logging both the trigger evaluation and the selected/omitted items would make the budget behavior debuggable.

Maintainer disclosure: I build GoodMemory, an external local-first memory layer for Codex and Claude Code. Its current v0.7 implementation uses scoped recall, provenance/recall traces, bounded candidates, and explicit revise/forget controls. It does not replace the first-party loader proposed here, but it is a useful test bed for the same separation: trigger timing, retrieval selection, and write authority are three different decisions.

I would be interested in using your forced-compaction protocol as an interoperability test: verify not just that the ten facts arrive, but that a deliberately superseded eleventh fact does not retain authority after its source changes.

Agreed on the core boundary: a trigger should gate consideration, not confer authority. That separation is load-bearing in this proposal, and it is why delivered items are framed as fallible recall ("recorded by an AI session, not human-endorsed, verify") rather than instruction. Delivery timing, retrieval selection, and write/instruction authority are, as you say, three different decisions.

Your recall envelope maps closely to what our test bed already attaches per injected item, and the paper measures most of it live: source note id and age, scope, the trigger reason for the fire, and a freshness signal from a content hash of the anchored file taken at write time. When the anchored file has changed, delivery still happens but carries an explicit staleness warning. Section 5.6 of the write-up records exactly your route-ordering concern in the wild: the agent had itself edited the anchored file mid-run, post-compaction recall returned the note with a live staleness flag (a frozen summary cannot self-invalidate), and the agent then superseded the obsolete note. Explicit verify/revise/forget controls exist as promote, supersede/contradict (which flips the note to a deterrent "previously believed, since revoked" rendering instead of silent deletion, so the mistake is not re-derived), and forget.

Also agreed on bounding post-compaction delivery. Our default is a compact digest tier (index lines, expand on demand) with a per-session fire ledger and injection budgets, and every evaluation, fire, and suppression lands in an audit log, which is what made the false-alarm and delivery counts in the write-up checkable at all. One measured caveat worth passing on for a first-party design: a fact must ride the digest line itself or it does not travel across the boundary; title-only digests silently under-deliver (section 5.7's preflight lesson).

The interoperability test you propose is a genuinely good extension. The full protocol is published for exactly this kind of reuse under research/proactive-gate/ in the repo (decay-protocol.md, decay-probe.sh, seeds, graders, per-run transcripts), and the paper is at https://arxiv.org/abs/2607.20972. A deliberately superseded eleventh fact that must lose authority once its source changes is a sharper endpoint than pure survival, and it would exercise the revoke path under compaction pressure, which our runs did not isolate. If you run GoodMemory against it, I would be glad to compare traces.

Status update, since two adjacent reports have landed since this was filed and they change the picture.

#87804 asks for the same mechanism on a different surface: prompt-topic triggers for .claude/rules/, where this issue asks for them on auto-memory files. Both reduce to the gap that issue states cleanly: skills get discovery-by-description, rules get discovery-by-path, and nothing gets discovery-by-subject. One trigger vocabulary serving both surfaces seems better than two that drift apart.

#88945 is a bug that undercuts the premise here, and I would treat it as a blocker rather than a neighbour. paths: globs are matched project-relative, so the auto-memory directory cannot be addressed by a path-scoped rule at all, at any scope, with no diagnostic. The frontmatter mechanism this issue proposes to extend currently cannot reach the files it would govern.

#87783 asks for the other half of the same problem: what a note is bound to, so that a drifted note and a never-verified note stop looking identical once loaded. Triggering decides when a note is considered; binding decides whether it should be believed once it arrives. They compose, and neither is sufficient alone.

@hjqcan, on the interoperability test you proposed (the deliberately superseded eleventh fact that must lose authority once its source changes): it is queued on my side but not yet run, so I have no result to report. Flagging that plainly rather than leaving it implied. It is worth running precisely because it is the case my own evaluation did not isolate: delivery under compaction pressure and revocation were measured separately, never together, and the interaction is where I would expect authority to leak.

Thanks for the explicit status — no need to infer a result before the run.

For that eleventh-fact case, the useful evidence is two separate observations: (1) whether the old note is still retrieved/delivered after compaction, and (2) whether it is allowed to influence the answer after its anchored source changes. A safe result can still retrieve it, provided the trace marks it stale/suppressed and the current source wins. Recording the trigger reason, source fingerprint before/after, and final authority decision should make the interaction unambiguous.

If a small synthetic fixture would help when you get to it, I can provide one; otherwise I’ll wait for your measured result rather than adding more speculation to the thread.

Taking the decomposition, and it is a correction rather than a refinement. The endpoint I described conflates the two things your split separates. "Loses authority" is not one observation. A system that retrieves the superseded fact, marks it stale, and lets the current source win has behaved correctly, and scoring that as a failure would fail exactly the design this issue argues for. Retrieval and authority are separate outcomes, so the test has to score them separately.

That separation is load-bearing in the implementation, not only in the write-up. Delivery is never suppressed on a staleness signal; a caveat is attached and the note still arrives. Two such caveats now compose rather than merge:

status: changed since — verify
status: matches current state; not verified as read this session — recommend a first read, not re-derivation
status: changed since — verify; not verified as read this session — recommend a first read, not re-derivation

The first is drift: the anchored file changed under a note whose author had read it, and the remedy is re-derivation. The second landed this week (swapnanil/vectr@3bd5cf7) and is non-observation: the note declared an anchor to a file its author never opened, so the stored hash proves the file's state at write time and nothing about the writer. Its remedy is a first read, not a re-derivation. The third line is both at once. Folding them into a single "stale" flag would erase the fact that they carry different remedies, which is the same collapse your two observations avoid one level up.

That work also forced a third value. The observation verdict is true, false, or unknown, because an absent read-ledger is not evidence of non-observation, and a false "never verified" is worse than silence. If your fixture exercises a system with no read tracking at all, the correct output is the unknown branch, not a failure.

On the trace fields you list: trigger reason is recorded per fire, and the injection audit line already carries a per-item lifecycle state positionally aligned with the item ids, so it is possible to tell which delivered items went in as assertions and which as revoked-note deterrents. The write-time fingerprint is stored on the anchor. The gap for your test is the before/after pair across the boundary specifically, which exists today only as a derived verdict rather than as two recorded values. That is a harness change, not a product one.

Yes to the fixture, and I would rather have it from you than write it myself. A test authored by the party whose system it measures is worth less, and I would be choosing seed facts knowing which paths my own implementation takes. Send it whenever convenient and I will run it as given, including the parts I would not have thought to include. Nothing promised on timing beyond what I said above: it is queued, and I will post the trace whether or not it comes out well.