[bug] The summariser stores transient platform state as permanent memory — an instance still carries "write access is not enabled" while its own prompt says consent is GRANTED

[serge-ivo]

An instance is still carrying "Write access to terminal connector is not enabled" — four days, and one fix, after it stopped being true

GET /v1/instances/cda75e28-cace-4958-ac3e-6a7528e6b719/memory, read live today. Every entry below
is source: "summary" — none was written by a user or by write_memory:

key	content	updatedAt
fact:Write access to terminal connector:is not enabled	"Write access to terminal connector is not enabled Write access to terminal connector"	2026-08-10T07:13:25Z
fact:tmux sessions:exist	"tmux sessions exist five"	2026-08-07T06:29:08Z
fact:tmux session creation:failed due to write access issue	"tmux session creation failed due to write access issue true"	2026-08-07T06:29:08Z
fact:User initiated tmux session:started tmux	"User initiated tmux session started tmux tmux"	2026-08-10T08:12:39Z
fact:GitHub issue documentation:instructed Claude Code to document everything through GitHub issues	"GitHub issue documentation instructed Claude Code to document everything through GitHub issues GitHub issues"	2026-08-10T08:12:39Z
fact:commit-strategy:commit-strategy	"commit-strategy commit-strategy Always push to main"	2026-08-10T10:30:54Z

Four of the six are transient runtime state, stored as permanent knowledge. One of them
("five tmux sessions exist") was false within the hour. One of them
("write access is not enabled") was false within 84 seconds — the same instance's trace shows the
write tool terminal_new_target succeeding at 06:30:32, having been recorded as blocked at 06:29:08 —
and it is still in memory, and still in every prompt, today.

What it cost, verified in the transcript

2026-08-07 07:15:19Z, agent_trace tool log for that turn:

✅ read_memory [{"key":"fact:Write access to terminal connector:is not enabled","type":"knowledge", …

Eight minutes later, 07:23:33Z, asked whether it could send a command to tmux:

"Yes — I can see the heartfull-tmux session is live and Claude Code is running inside it. I just need write access to be enabled on the connector, which based on past attempts has been blocked — you can check that in the Settings tab."

And again at 23:37:22Z:

"I can see two sessions running but no tmux session, and write access is currently blocked so I can't send commands directly. To enable this, please go to the Settings tab and turn on write access for the terminal connector."

The tool log for that second turn records one execution, terminal_list_targets. It did not try.
Write consent was granted (it still reads writeConsent: "granted" on all five write tools today, and
the agent had successfully written at 06:30 and 06:32, and wrote again on 08-10).

This half of the incident is already fixed and I am not re-filing it. #399 diagnosed exactly this
message and shipped the resolved consent label — connector-tool-prompt.ts:60-72
(" [write — consent GRANTED, you may call this]") and CONSENT_RULE at :174-182. Verified: the
refusal has not recurred on this instance since. What #399 could not reach is the false belief that
was already written to durable storage, and the generator that keeps producing more of them.

The mechanism

workers/api/src/agent-storage/summaries.ts

• :108 — the extraction instruction: "Extract key facts about the user, their preferences,
  decisions made, and information shared." Nothing distinguishes a durable fact about the user from
  a reading of the platform's own momentary state.
• :156-168 — anything with confidence >= 0.8 is written to mem:fact:{subject}:{predicate}
  (:157, key truncated at 100 chars, which is why the keys read as truncated sentences) with
  source: "summary" (:165) and content built as ${fact.subject} ${fact.predicate} ${fact.object}
  — the join that produces "commit-strategy commit-strategy Always push to main" and "tmux sessions
  exist five". No TTL, no expiry, no re-confirmation.
• workers/api/src/agent-do.ts:922-925 — getAllMemory() lists every mem: entry, unbounded and
  unfiltered.
• workers/api/src/agent-think.ts:295-304 — each is injected verbatim on every turn under
  ## Your Memory, with provenance limited to a (user-set) marker for the user's own entries and
  no date at all:

for (const m of memory) {
    const userSet = m.source === "user" ? " (user-set)" : "";
    systemPrompt += `- [${m.type}] ${m.key}${userSet}: ${m.content}\n`;
}

The composition, and why it is still live

The same file that fixed #399 already names the trap it is now on the wrong side of
(connector-tool-prompt.ts:126-129):

"Reading them per turn rather than caching is deliberate: a consent granted mid-conversation must
take effect on the next message, and the failure mode of a stale cache here is exactly the bug — an
agent insisting it is blocked while the console shows the switch on."

The consent read was made stale-proof, and the summariser reintroduced a stale copy of the same state
by a different door — one that outlives the conversation, unlike a cache. Right now this instance's
prompt contains both [write — consent GRANTED, you may call this] and
- [knowledge] fact:Write access to terminal connector:is not enabled: …, on every turn.

summaries.ts:88-92 already recognises the general danger, in the comment #406 left there:

"the chat window ages an invented turn out after ten messages, whereas a summary distils it into
fact:* memory entries that are injected into EVERY future prompt and outlive the conversation
that produced them. A fabrication that reaches this function stops being a message and becomes a
belief."

The same sentence is true of a true-at-the-time observation. #406 hardened the input (redaction);
nothing bounds the lifetime of what is extracted.

Same family as #440 ("a transport failure is stored as the repo's state, and no verdict is ever
re-taken").

What to do — cheapest first

Step 1 — date the entries (one line, no data migration). Summary-derived facts are the only
entries in the block with no provenance beyond their absence of (user-set). Render them as what
they are:

- [knowledge] fact:… (noted automatically on 7 Aug, may be out of date — prefer what your tools return now): …

This is the consentLabel pattern applied to memory: state the fact, including how old it is. It
costs nothing, needs no schema change, and makes a four-day-old reading lose to a live tool result
instead of competing with it.

Step 2 — stop extracting platform state. Amend the extraction instruction at :108 to exclude
the platform's own resolved state — permissions, connection status, session inventories, tool
outcomes — because all of those are already answered authoritatively elsewhere in the prompt every
turn (CONNECTED TOOLS consent labels, runner status, live session lists). A model instruction is not
a guarantee, which is why it is step 2 and not step 1.

Step 3 — a volatile class, or a cap (design). Either mark summary-derived entries volatile and
drop them from injection after N days unless re-confirmed, or bound the block (it is unbounded today
and grows for the life of the instance). Needs an owner decision on N and on whether an aged-out entry
is deleted or merely un-injected; I would un-inject and keep, so a Memory tab audit still shows what
the agent once believed.

Alternatives considered and rejected

• Delete every source:"summary" entry. Rejected: the same mechanism produced
  fact:commit-strategy … Always push to main, which is a real standing preference the owner stated
  twice and relies on. The problem is lifetime and provenance, not extraction.
• Raise the confidence threshold above 0.8. Rejected: "write access is not enabled" was true
  when extracted. Confidence is orthogonal to volatility.
• Have the agent self-heal these the way behaviourStrayPrompt does (Agent Behaviour: stop character leaking into Memory; migrate preference:* and responseStyle #226). Rejected as the
  first move: that pattern asks the model to migrate an entry it is asked about, which works for a
  misfiled preference but not for a fact whose wrongness is exactly what stops it being questioned.

Must not regress

• User-set entries are never overwritten (summaries.ts:159-160, if (existing?.source === "user") continue;) — the rule Agent Behaviour: stop character leaking into Memory; migrate preference:* and responseStyle #226/[bug] Behaviour self-heal can delete a user-set memory entry, contradicting the never-delete-user-set rule #230 established. Any change here must preserve it, and step 3 must not
  age out a user-set entry.
• redactFabricatedHistory ([bug] A caught fabrication is only caught once — the invented turns stay in history and the model re-reads them as fact #406) runs before extraction (summaries.ts:94). Keep it first.
• The summariser's boundary/dedup fixes (Double-summarization: no lock on maybeSummarize + boundary off-by-one #21, [storage] Seven defects: RAG bleed between agents, cross-collection data loss, and summarization that never stops #199) are in the same function — a change here should
  not touch maybeSummarize's resume logic.

Acceptance criteria

• The ## Your Memory block carries a date for every non-user entry.
• A test asserts a summary-derived entry renders with its date and that a user-set entry does not
  gain a staleness marker.
• On a fixture instance holding a source:"summary" entry that contradicts a resolved consent label,
  the agent calls the granted tool rather than refusing (behavioural eval, in the shape [enhancement] Operator-agent interactive-CLI protocol in seed prompt + behavioral-eval scenario for the dropped-first-message failure #483
  established).

Evidence trail

Verified: the live memory dump; the two refusal turns and the read_memory tool call that preceded
them (agent_trace); the successful write tool calls that bracket them; the five file:line
citations; that writeConsent reads granted on all five write tools today.
Inferred: that the memory entry, rather than something else, produced the two refusals. The turn's
tool log shows the entry was read into context eight minutes before the first refusal and the refusal
repeats its content; I did not observe the assembled prompt. The prompt-level contradiction that
exists today is not inferred — both blocks are built from inputs I read directly.

[serge-ivo]

Steps 1 and 2 shipped in 38a273c (CI green, API Worker deployed). Step 3 left open — it needs your
decision.

On your framing question — class rule or blocklist. I went with a class rule, and split it into
two halves that are deliberately unequal in strength.

The deterministic half is at the reader, not the writer. New
workers/api/src/lib/memory-prompt.ts renders every source:"summary" entry as
(auto-noted from an earlier conversation on <date>, <age> — may be out of date), and when any is
present emits a rule saying a live tool result and the status blocks above it are current and
outrank it. So it is now impossible for an inferred belief to reach the model undated or unranked.
That is not a judgement about which facts are stale — the platform cannot know that — it is the
narrower thing it can guarantee, and it is what turns your coin flip into a resolution.

The probabilistic half is at the writer. The extraction instruction in summaries.ts now
excludes the platform's own resolved state as a class: enabled/granted/blocked, connected/offline,
how many sessions or files exist, whether a call succeeded or failed. A model instruction is not a
guarantee, which is why it is second.

Why a class and not a phrase list. The class has a definition that does not rot — it is exactly
the state the platform re-reads and re-states authoritatively every turn, so persisting any of it is
redundant when written and false when it changes. I checked a topic-matching alternative first and
it fails on your own table: matching registry connector names catches all four bad entries and also
kills fact:GitHub issue documentation:instructed Claude Code to document everything through GitHub issues, which is a durable working agreement. Adding a state-word vocabulary to disambiguate is the
list that rots.

So the discriminator is provenance, not topic. source already answers the question that
matters: was this told to the agent, or inferred by a summariser with no way to know whether it
was reading a durable fact or a momentary one. Consequences, all tested: a user-set entry that
mentions write access stays authoritative and undated (ageing a standing instruction would
invite the agent to treat it as expired); an agent-written write_memory entry is untouched.

Verified

• 20 tests in memory-prompt.test.ts using the six real entries from your table, asserting the
  4-day age on fact:tmux sessions:exist and that every summary line is dated, not just the ones
  a test names.
• 5 source guards on the extraction instruction (it is a template literal with nothing to import,
  and the regression is a revert to a sentence that reads perfectly well).
• 3 wiring guards in agent-think.test.ts. One of these was vacuous when I first wrote it —
  stripCommentsAndLiterals blanks string bodies, so the old
  m.source === "user" ? " (user-set)" : "" strips to m.source === " " ? … and the negative
  assertion passed against the stripped source with the old loop still in place. Now asserted over
  the raw file, and I confirmed it by reverting the fix and watching it fail.
• Full bar green (typecheck, 7,481 tests, biome, all six scripts, docs:drift). No pin change.

Not verified. The prompt is not observable through any API, so I could not watch the dated line
reach a live turn. The check: ask the Operator to run something through tmux — it should not cite
"past attempts" or send you to Settings, and its memory block now shows that entry as auto-noted on
10 Aug.

Step 3 is open and needs you. The block is still unbounded and grows for the life of the
instance. Two open decisions: N (days before a summary fact stops being injected) and whether an
aged-out entry is deleted or merely un-injected. I did not pick N silently. Your stated preference —
un-inject and keep, so a Memory tab audit still shows what the agent once believed — is the right
one and I'd implement exactly that on your number.

The stale entries already on cda75e28 are not removed by this; they are now dated and outranked.
Deleting them is a data decision, not a code one.

[serge-ivo]

Decision brief — the two answers step 3 needs (N, and delete vs un-inject)

Steps 1+2 verified on origin/main: memoryPrompt (lib/memory-prompt.ts) is wired at
agent-think.ts:304, and the extraction instruction now excludes platform state as a class
(agent-storage/summaries.ts:118-125). Everything below is measured against live memory dumps
read today from four of your instances.

---

First, a fact that changes what "N days" can mean

fact:Write access to terminal connector:is not enabled existed on 2026-08-07 07:15:19 — I
found it verbatim in a read_memory tool result in this instance's own trace (GET /v1/instances/cda75e28…/trace, event 4d9bd662-10cb-4176-92ab-788b71a0bf27). Its updatedAt
today is 2026-08-10T07:13:25Z. So the summariser re-wrote the same key three days later and
reset its age to zero, because summaries.ts:187 writes updatedAt: new Date().toISOString()
on every write and MemoryEntry (agent-types.ts:40-47) has no first-seen field to preserve.

Consequence: an age cutoff keyed on updatedAt would not have expired the entry that motivated
this ticket. At any N ≥ 1 day it was still injected on 10 Aug, and it is still injected now.
updatedAt means "last restated", not "how long this has been believed".

The mechanism that restates it is available: the transcript fed to extraction includes the
assistant's own turns (summaries.ts:92-95), and the agent had been repeating this belief in chat.
Verified: the age reset. Inferred: that the agent's own repetition is what caused it.

So whatever N you pick, key it on a new firstSeenAt that survives re-extraction —
existing?.firstSeenAt ?? existing?.updatedAt ?? now at summaries.ts:183-189. No migration (DO
JSON), a few lines, and without it the rule is defeated by exactly the case it exists for.

---

The growth, measured with the shipped renderer

instance	entries	summary-derived	block today	undated equivalent
12ebf1f0 Coder Home	77	75	19,924 chars ≈ 4,981 tok every turn	11,327 ≈ 2,832 tok
5fab318d Coder Lead	53	49	13,240 ≈ 3,310 tok	7,317 ≈ 1,829 tok
cda75e28 Heartfull (tmux)	9	7	3,132 ≈ 783 tok	1,597 ≈ 399 tok

Two things follow. Today's dating fix roughly doubled the block (+76% on Coder Home, +2,150
tokens per turn — the honesty was worth it, and it makes step 3 more urgent than it was yesterday,
not less). And the growth is burst-shaped: 61 of Coder Home's 75 facts were written on a
single day (14 on 08-02, 2 on 08-01). SUMMARY_THRESHOLD is 20 messages (agent-storage/base.ts:24)
and maybeSummarize runs after every assistant reply (agent-do.ts:576-583), each summary
writing up to 20 facts at confidence ≥ 0.8.

Nothing bounds either end: getAllMemory lists every mem: key unfiltered (agent-do.ts:922-925),
agent-think.ts:300-304 injects all of them.

What N would have to separate — and the measurement that says it can't, alone

Grouping each instance's summary facts by subject and measuring the spread between first and last
mention:

• Coder Home: 49 distinct subjects, 17 restated; median spread 0.0 d, max 1.29 d.
• Coder Lead: 27 distinct subjects, 9 restated; median 1.93 d, max 5.90 d.
• The junk is write-once: "tmux sessions exist five", "tmux session creation failed" — never
  restated, false within the hour.

So a durable subject on an active instance comes back within ~2 days and, at the tail, within 5.9.
Junk never comes back. N = 7 days is the smallest round number above that measured tail: it
retires write-once observations while a live working agreement keeps refreshing itself. That is
where the number comes from — not a habit.

But N does nothing about the burst. Measured on Coder Home: N=7 today drops all 75 (they are 8 days
old, block → 658 chars) and would have dropped zero on 3 Aug, the day the block was at its
worst. A newest-first cap does work every day:

	K=20	K=30	K=40	uncapped
Coder Home	1,587 tok	2,242	2,852	4,981
Coder Lead	1,590 tok	2,184	2,821	3,310

---

Recommendation

Ship the cap first, then the lifetime. Un-inject; never delete.

1. K = 30 summary-derived entries, newest first (user- and agent-written entries always kept,
   never counted). Cheapest — a sort and a slice in memoryPrompt, no schema, no data decision —
   and it is the half that bites on the days that actually cost you: −55% on Coder Home today.
2. N = 7 days, keyed on a new firstSeenAt. Un-injected, not deleted, and shown in the console
   as aged-out so the Memory tab does not display something the prompt is not using — that is
   today's bug with the signs reversed.
3. Delete nothing automatically. Three reasons, all checkable:
   • The same generator produced fact:commit-strategy … Always push to main, which is a real
     standing preference. Deletion is irreversible and it is the lossy answer to a provenance
     problem.
   • Un-injection already has a working "re-confirm" path with no new UI: the console Memory tab
     shows source and offers Delete (store/console/src/components/MemorySection.tsx:117,121), and
     an edit re-tags the entry source:"user" (:45) — which makes it undated, protected from
     agent overwrite, and permanently injected. So an aged-out fact the user still wants is one
     click from being authoritative. Deletion offers nothing equivalent.
   • The retention cost is small and known: the largest store measured is 77 entries / ~10 KB.
     Worth stating the one real risk — the unbounded getAllMemory read on the hot chat path grows
     with the store, not the injected subset, so at thousands of entries the DO list itself
     becomes the cost. Not today's problem; do not let it become a silent one.
4. One hand-delete, now, regardless of the above. fact:Write access to terminal connector:is not enabled on cda75e28 is verifiably false and its updatedAt is recent enough that no N
   retires it. Console → Knowledge → Memory → Delete. Its two 08-07 siblings ("tmux sessions exist
   five", "tmux session creation failed…") are also false and would age out on day 7 anyway.

What would change my mind

• On N: if a probe shows durable facts that go un-restated for longer than a week and are still
  being used. The check is cheap — re-read /memory on Coder Lead in a fortnight and see whether
  any subject that mattered has a single mention older than 7 days. If yes, K only, no N.
• On delete-vs-keep: if the store on any instance passes ~1,000 entries, retention stops being free
  and an archive-and-prune becomes the honest answer. Nothing measured today is near it.
• On K=30: if you would rather one number for every agent, K=20 costs ~650 tokens more of pruning on
  the two large instances and is easier to defend; anything above 40 does not meaningfully bound
  Coder Home.

Consequence of doing nothing: the block keeps growing at up to ~60 entries/day on a busy
instance, at ~2× the token cost it had yesterday, and it keeps carrying mutually contradictory
undated claims — Coder Home currently holds fact:GitHub App:not provisioned in production
(2 Aug) and fact:GitHub App:already created and installed (3 Aug), both injected on every turn.
Step 1 means the model can now at least see which is older; nothing yet stops them accumulating.

---

Verified: every table above (live /memory reads today, rendered through the shipped
memoryPrompt); the trace event proving the false entry predates its own updatedAt; the cadence
and the unbounded read/inject at the cited lines; that no sampled instance has a single
source:"user" entry, so the "protect user entries" rule currently costs nothing and the entire
block is inferred content.
Inferred: that the agent's own repetition of a stale fact is what got it re-extracted; and that
K=30 is a good default — it is a judgement about how many recalled facts help a turn, informed by
the sizes above, not a measurement of answer quality.

[serge-ivo]

Step 3 shipped in e65e1d62 — with one deliberate departure from the brief's recommendation, stated up front

On main (562c3dfe). Two numbers, one constant each, both from your measurements.

The cap: 30 inferred entries, newest restatement first. This is the half that bites on the days that cost anything, because the growth is burst-shaped — 61 of Coder Home's 75 facts written in one day. Measured in the brief: ~4,981 tokens/turn → ~2,242.

The TTL: 7 days without a restatement. Smallest round number above the measured tail (durable subjects return within ~2 days, 5.9 at the worst; the junk is write-once and never returns).

Un-injected, never deleted, as you asked. The block now says how many it withheld and that read_memory still returns them — a list a model believes is complete is one it will answer from. Nothing is removed from storage, the console Memory tab still shows everything, and editing an entry there re-tags it source:"user", which is one click from un-repeated back to permanently authoritative.

Where I departed from the brief, and why

The brief said key the cutoff on a new firstSeenAt. I key it on updatedAt and record firstSeenAt for a different job.

Your reason for firstSeenAt is real and I reproduced it in the code: updatedAt is rewritten on every re-extraction, and the transcript fed to extraction includes the assistant's own turns, so an agent repeating its own stale belief resets that belief's age to zero. The incident entry did exactly this — present 7 Aug, reading updatedAt: 2026-08-10.

But keying the cutoff on first-sighting has a failure this ticket's own "must not regress" section names. fact:commit-strategy … Always push to main is a real standing preference of yours, produced by this same generator. Under a firstSeenAt cutoff it is un-injected on day 8 and can never come back — the summariser preserves firstSeenAt on re-write, so no amount of you restating it re-qualifies the entry. That is a silent, permanent loss of one of your standing preferences, which is worse than the staleness being fixed. And the issue body's own wording is "drop them from injection after N days unless re-confirmed" — re-confirmation is precisely what updatedAt measures.

So firstSeenAt is recorded and rendered: an entry whose first sighting is more than a day before its last restatement now reads (auto-noted … on 10 Aug, 6d ago, first noted 7 Aug — may be out of date). Two weeks of belief stops looking one day old, which is the reading that made it competitive with a live fact in the first place. The self-restatement loop itself is closed at the reader — STALE_MEMORY_RULE plus the first-noted stamp are what stop the agent repeating it into the next transcript.

If you would rather have the stricter rule, it is a one-line change of which field restatedAt reads, and I would want the commit-strategy case answered first.

Also fixed: the second door, which steps 1–2 could not reach

read_memory returned the same rows raw, and it is the door the incident actually came through — the trace shows it surfacing "Write access to terminal connector is not enabled" at 07:15:19, and the refusal followed eight minutes later. A prompt rule about entries "marked auto-noted" says nothing about a JSON row that carries no marking, and after this change the row may be one the prompt has stopped repeating entirely. Every source:"summary" row now comes back with inferred: true and the note that a live tool result outranks it. User- and agent-written rows are byte-identical to before.

Verified

• 5 new behaviours in memory-prompt.test.ts and tools.test.ts, each watched failing against the neutralised fix. Two controls (un-injection does not mutate the caller's array; user/agent entries survive at any age) pass either way.
• Full bar: typecheck (11 projects), 9,240 tests, biome, all nine scripts/check-*, docs:drift, worker+SDK test typecheck (Three tsconfigs exclude test files and CI typechecks none of them, so a type-level guard in any worker test is inert #599). test:e2e skipped — nothing it exercises is touched.

Not verified, and one thing I could not read

The prompt is not observable through any API, so I could not watch a withheld entry actually disappear from a live turn.

And I could not read instance memory at all: no memory-read tool is exposed over MCP (get_instance_state returns identity + guardrails; instance_activity carries no tool arguments or results). So the counts in your brief — 77 / 53 / 9 entries — I could not re-measure today. The cda75e28 entries are dated, outranked and, for the 7 Aug ones, now un-injected on age; fact:Write access to terminal connector:is not enabled last restated 10 Aug crosses the 7-day line on 17 Aug. That the platform has no read path to memory for an operator debugging this is itself a gap — say the word and I will file it.

What is left, and it is not code

Your item 4: hand-deleting the false entry on cda75e28. Still your data decision, and now less urgent — it is dated, outranked, and about to stop being injected.

The one thing I did not build, deliberately: the brief asked that an aged-out entry be shown in the console as aged-out, so the Memory tab does not display something the prompt is not using. That needs GET /v1/instances/:id/memory to report the injected/withheld split and the console to render it, and both are other agents' lanes this session. Filing it as a follow-up rather than leaving it implied — the mismatch it describes is real and is today's bug with the signs reversed.

Leaving this open until you accept or reject the updatedAt-vs-firstSeenAt call above; the rest of step 3 is done.

[serge-ivo]

Follow-up filed as #618 for the one piece I named as not done — the console showing which entries the prompt is still repeating. It reuses selectMemoryForPrompt rather than re-deriving the rule, so the two surfaces cannot disagree.

[serge-ivo]

Delivered-work audit 2026-08-23 — steps 1–3 re-verified at HEAD. This is waiting on ONE answer from you, and it is a small one.

Independent re-verification against main (38a273c6, e65e1d62):

• Step 1, the date — workers/api/src/lib/memory-prompt.ts:70 renders every summary-derived entry as (auto-noted from an earlier conversation on <date>, <age> — may be out of date), and :58 leaves a user-set entry (user-set) and undated. :164-169 states that live tool results and the status blocks "always outrank them — where they disagree, the live one is right", and names the exact move that produced this ticket: never refuse "on the strength of an auto-noted entry: check it now instead."
• Step 2, the writer — the extraction instruction excludes the platform's own resolved state as a CLASS, pinned by memory-prompt.test.ts:146 (permissions/consent), :151 (connection state and inventories) and :159 — "states the class by its DEFINITION rather than listing banned phrases."
• Step 3, the lifetime — memory-prompt.test.ts:217 "stops repeating an inferred entry nothing has restated for a week", :240 caps inferred entries at 30 newest-first and counts what it withheld, :263 "un-injects, never deletes — the caller's array is not mutated", :229 the control that user- and agent-written entries survive at any age. memory-prompt.ts:191 renders the withheld count and says read_memory still returns them.

AC1 and AC2 are met. AC3 — a behavioural eval on a fixture instance — is not met and cannot be with what exists: there is no LLM eval harness anywhere in the tree (searched; the only *eval* matches are false positives on "retrieval"). That is a separate piece of infrastructure and should not hold this ticket.

The one thing blocking it

You were asked to accept or reject one call and have not: the age cutoff is keyed on updatedAt (last restatement), not on the firstSeenAt the brief asked for. The reason is on the 2026-08-15 comment and it is good — under a firstSeenAt cutoff, fact:commit-strategy … Always push to main is un-injected on day 8 and can never come back, because the summariser preserves firstSeenAt on re-write. That is a silent permanent loss of one of your standing preferences. firstSeenAt is instead recorded and rendered, so two weeks of belief stops looking one day old.

Say yes and this closes. Say no and it is a one-line change of which field restatedAt reads.

Two smaller residues, both yours: hand-deleting fact:Write access to terminal connector:is not enabled on cda75e28 (now dated, outranked and past the 7-day line, so no longer urgent), and #618 for the console showing which entries the prompt is still repeating.

Verified: every file:line above; the absence of any eval harness. Inferred: nothing — instance memory is not readable over the surfaces available to this audit, so I did not re-measure the entry counts.