If the next decision asks for the same search after reading a relevant function, model attention is not the only possible cause. Historical focused repair had an additional-context overwrite problem. A bounded investigation needs both lookup identity and the actual fragments, or it can circle back to the start.
Preserve the actual return to the same search
In the historical video-start test, an unsupported_control search was followed by an observation-function lookup and then the same search again. The repetition gate stopped the attempt before modification or installation. The record keeps that failure, and the code replacing earlier extra context became the investigation target.
Removing the repetition limit would let the same investigation continue longer. The important question was what the next decision actually received. A marker saying a search happened differs from retaining the source fragment needed to reason about its result. Those are two kinds of memory rather than interchangeable evidence.
Keep lookup identities and fragment blocks separately
Seen retains completed lookup identity while contextBlocks retains results. Extra combines both for the next prompt. The key uses kind, queries, search and referenceUrl but excludes summary, so rephrasing a summary does not turn the same request into new investigation.
Supplied ranges have another marker built from path, current hash and line interval. The same filename can legitimately have a different hash or range, while differently worded identical requests should not consume another bounded call. Lookup deduplication and fragment retention solve different problems and therefore need their own state.
This is not unlimited retention of every old fragment
RememberContext calculates available bytes from base context and the lookup ledger, truncates an oversized fragment on UTF-8 boundaries, and removes oldest blocks when the combined budget is exceeded. The complete prompt is separately checked against 42,000 bytes. Memory was repaired without removing the existing size boundary.
A test retaining two small fragments does not guarantee perpetual retention of every earlier one. The ledger can retain a lookup marker after the oldest body is evicted for budget. A narrower different range may then be needed. Explicit truncation guidance matters because bounded memory should not conceal the absence of a fragment the next decision assumes it still has.
Inspect the prompt actually received by the third call
The regression first requests a search, then a helper-symbol lookup. The third model substitute must receive hashes for both files plus the completed-lookup ledger. It finally returns a unique before/after fragment patch to exercise continuation of the flow.
This checks the transmitted string rather than guessing what a model remembered. Because replies are predetermined substitutes, it does not measure real-service reasoning success. I read the original test without rerunning historical automatic repair. Verifying data delivery and measuring natural-language judgment remain different kinds of evidence.
Check what accumulated evidence means in current investigation
The ledger belongs to the retired internal repair path. Current external Codex work does not automatically use the same implementation. The reusable principle is to verify that the next decision actually receives needed evidence while preserving duplicate-request, context-budget and uncertain-outcome protections.
The shared structural-report package implements neither a source-lookup ledger nor this memory policy. It is another small contract for describing an error without unrestricted content. I do not solve memory by sending the whole conversation. Retaining needed clues and locating a narrower clue after budget eviction remain distinct responsibilities.