The Authorship Floor

1. The authorship floor

Over an afternoon spent in an unfamiliar service, a developer learns three things. The retry wrapper swallows connection errors, so a test that asserts on them will never see one. The integration suite fails intermittently when run in parallel, and the failure has nothing to do with the code under test. And the connection pooling change should wait until the security audit lands next month. A week later, at most one of these is written down anywhere.

The reason is not carelessness. Writing something into a project’s instruction file, whether that is CLAUDE.md, AGENTS.md, .cursorrules, or the README, is an act of authorship, and authorship costs a decision. The developer has to judge whether this particular thing is important enough to write down and, more consequentially, to keep true. That second half of the judgment is what does the damage. A fact recorded in a document is a maintenance obligation that nobody is assigned and nobody discharges, so the honest answer for most of what a developer learns is that it does not clear the bar.

We call the resulting threshold the authorship floor. It is not a formal construct. It is the implicit standard a developer applies before deciding to record something, and its effect is easy to observe in any repository: instruction files contain architecture summaries, house style, and a handful of hard-won warnings, and they contain almost nothing that was true for only a week.

The floor produces two failures at once, and they pull in opposite directions.

Below the floor, knowledge is never recorded at all. The three facts above are worth having and none of them is worth a paragraph in a maintained document. They are specific, they are timely, and they expire on their own, so a developer who wrote each of them into a document would be committing to prune it later, which is precisely the work nobody does. They write none of it, and the knowledge leaves with the session that produced it.

Above the floor, knowledge is recorded and then rots. The warning about the retry wrapper is worth writing, so it gets written, naming the wrapper by name. Some months later the wrapper is renamed during a refactor. The sentence in the instruction file does not change, because nothing connects the two. It now names a function that does not exist, and it is still delivered on every turn, as an instruction, to every agent and every new engineer who reads the file. Nothing in the system knows.

This is not a hypothetical. A study of 247,694 instruction lifetimes across 1,867 repositories finds that agent instruction files more than triple over their lifetime, gaining close to five net instructions per commit, and that the probability of an instruction being deleted falls the longer it has been there. Instructions accumulate, and the old ones, which are the likeliest to have gone stale, are the ones least likely to be removed.

These look like different problems and they are usually treated as different problems. Documentation rot has a literature; the loss of small, situated knowledge mostly does not. We argue that they are one problem with one cause. Authorship is expensive, and maintenance is manual. The first cost sets the floor, and the second is why the floor has to be set so high: a developer records only what they are willing to keep true, and keeping things true by hand is expensive enough that the willing set is small.

2. Why both costs have to fall together

The argument of the paper is that the floor cannot be lowered by attacking either of its two costs alone. It is worth being explicit about why, because each half looks sufficient on its own and neither is.

2.1 Cheap capture, by itself, makes things worse

Suppose the cost of writing something down goes to zero. An agent records every constraint it is told, every failure it recovers from, and every decision made in passing. The store fills quickly, which is the intent, and then it keeps filling, which is the problem. Nothing in such a store distinguishes a constraint that expired last month from one that still holds.

This is not merely untidy. The material a store delivers is delivered into a budget that is shared with the task at hand, and adherence to instructions degrades measurably as the number of instructions grows. Stale material does active harm twice over: it consumes budget that correct material would otherwise occupy, and it dilutes the instructions that remain. A store that has accumulated for six months without pruning can be worse than no store at all.

2.2 Cheap maintenance, by itself, recovers nothing

Now suppose instead that documents maintain themselves. Some mechanism watches the repository, finds the sentences that no longer hold, and flags or removes them. Instruction files stay accurate. This solves the failure above the floor and leaves the floor exactly where it was. The pooling deferral was never in a document, so no document maintenance mechanism will ever see it. Perfect maintenance of documents that were never written is worth nothing, and our contention is that the fraction of a project’s working knowledge sitting below the floor is large.

2.3 Forgetting is what licenses remembering

Put the two halves together and each supplies what the other lacks. Mechanical expiry is the precondition that makes cheap capture safe. If an item can be checked against the code it describes, and removed when that code is gone, then recording it costs nothing that has to be repaid later. The maintenance obligation that the authorship floor exists to avoid is discharged by the system rather than by the developer, and the judgment that produced the floor is no longer required.

You can only afford to remember small things if forgetting is automatic.

3. Anchored memory

Making forgetting mechanical requires a stored item to be something more than a sentence.

3.1 A claim and a referent

An item consists of a claim, written in ordinary language, together with a referent: the repository, file, and declaration the claim is about. The referent is not a citation in the text. It is a row resolved against a code graph at the moment of capture, and it carries enough of the declaration’s content to recognise that declaration again later.

Two signatures do the work. A body fingerprint is a truncated hash of the declaration’s normalised body, which answers whether the code is byte-identical to what was seen. A body sketch is a set of hashed token shingles over the same body, which answers a different question: whether some declaration is the same code under a different name. Two signatures are needed because a rename defeats the first. The declaration line is inside the body being hashed, so renaming a function changes its fingerprint completely, and an exact hash cannot distinguish that function having been deleted from an unrelated one written in its place.

3.2 The six verdicts

Every time a repository is indexed, each anchor is checked against the current state of the code, and the check returns one of six verdicts.

Three of them mean the claim’s subject is still there. ok is an unchanged declaration. renamed and moved are declarations found again under a new name or in a new file, in which case the anchor is rewritten to point at the new location and the previous name is retained alongside it, so the history of the binding is not lost.

One means the subject changed underneath the claim. When a declaration’s body no longer matches its fingerprint, the verdict is unconfirmed. The layer records that the claim needs a look and deliberately declines to decide anything further, because whether a rewritten body falsifies a claim about it is a judgment this mechanism is not equipped to make: a rationale can survive a complete reimplementation, and a description of behaviour can be falsified by a two-line change. Treating drift as falsification would discard true claims at exactly the moment they were most likely to be relevant.

One means the subject is gone. orphaned is returned when the declaration cannot be found anywhere in the branch. It is the only verdict that withdraws an item, and it does so only when every anchor on that item is orphaned. Withdrawal is not deletion: nothing in the layer removes an item from the store. Expiry writes a timestamp and a reason, the row and its anchors remain, and the store can therefore answer why it stopped delivering something, which a store that deletes cannot.

3.3 The verdict that changes nothing

The sixth verdict is unknown, and it carries more of the design’s weight than the other five. The code graph is a separate artifact from the working tree and is maintained asynchronously. It is routinely behind: a developer edits a file, the graph has not been rebuilt, and a symbol that exists on disk is absent from the index. A system that reads that absence as deletion will withdraw a true claim, and it will do so most often during active editing, which is when the claim was most likely to matter.

So the layer distinguishes not finding something from having established that it is gone. It returns unknown under nine conditions in all: when there is no graph, when the repository is not in it, when the checkout’s location is unknown, when a file is on disk but not yet indexed, when the indexed commit disagrees with the checkout, when the recorded content hash disagrees with the file on disk, when a re-resolution target is ambiguous, when several declarations share the name and none matches by fingerprint, and when a body cannot be read. None of them expires anything.

The principle is that absence of evidence is not evidence of falsity. A system that says nothing when it cannot tell will sometimes carry a stale item longer than necessary, which is a smaller harm than deleting a true one.

4. Capture without authorship

Mechanical expiry removes the maintenance cost. It does not, on its own, remove the cost of deciding to write something down, and a system that still requires a developer to author each item has moved the floor rather than dissolved it. The layer therefore derives items from a session’s own activity as well as accepting stated ones.

4.1 Distillation from a session’s events

A hook records what a coding session does: which files were read and edited, which commands ran, which failed, and what they printed. These events are not memory. They are a stream from which memory can be distilled offline. The obvious distillation rule is that a failure followed by a later success on the same command is a lesson, and in practice this rule extracts almost nothing, for a reason specific to agents. An agent writes a new heredoc, a new inline script, and a new scratch path on nearly every attempt, so successive invocations that a human would consider the same command share no text at all.

What replaces it is the disappearance of an error signature. The layer arms on a failure whose output is about the code rather than about the environment, requires at least one intervening edit, and then accepts a pass from a command of the same shape as evidence that the signature is gone. Classifying the failure comes first and matters more than it appears to: a command killed by a timeout prints real assertion failures on its way to being killed, so environmental causes are checked before the failure is read as evidence about the code at all.

4.2 Three tiers, one of which is never delivered

Items differ in how much authority they can claim, and the layer records this rather than flattening it. An item is a law when the developer stated it, an observation when it was derived mechanically and carries its provenance, and a hypothesis when something was inferred.

Hypotheses are stored and never delivered. No read path returns them, so an inference the layer was not confident enough to promote cannot reach a reader through any surface. This is the consequence of a position worth stating plainly: a memory system for an agent has an obligation to refuse before it has an obligation to rank, because a confidently delivered wrong memory is worse than silence, and inference is where wrongness comes from.

We note one thing about how that property is enforced, because it bears on how such properties should be built. The filter is applied in the query rather than left to callers, but it is applied in every query rather than at one point, and during the preparation of this paper we found a read path that had been added without it. A drifted hypothesis could reach a reader through that path. It has been fixed, and the episode is worth reporting rather than concealing: a property enforced by a predicate repeated across many queries is a property that will eventually be missed in one of them.

5. A worked lifecycle

The following sequence was run against a repository created for the purpose. It is an illustration of the mechanism rather than an evaluation of it: it shows what the design does, not how often it helps.

A small module defines two functions, one of which computes a running balance from a list of ledger entries. A developer states a rule about it in the course of ordinary work, naming no coordinates and passing no arguments, simply writing that the opening balance handed to reconcileLedger must already be in cents. The layer extracts candidate referents from that sentence. Most of its words are excluded by shape, and one word survives, resolves to exactly one declaration in the graph, and the item is bound to that declaration at symbol grain with a fingerprint and a sketch of its body.

The function is renamed to settleLedger and the repository is re-indexed. The fingerprint no longer matches, because the declaration line is inside the hashed body, but the sketch of the new declaration is close to the stored one and no competing candidate is close enough to contest it. The verdict is renamed. The anchor is rewritten to the new name, the previous name is retained beside it, and the item stays live, now pointing at code that exists.

The function is then deleted outright and the repository re-indexed again. No declaration in the branch resembles the stored sketch. The verdict is orphaned, it is the item’s only anchor, and the item is expired with that reason recorded. It remains in the store. Asked about it afterwards, the layer reports the claim, the declaration it was about, the rename it survived, and the reason it was withdrawn.

The same rule written into an instruction file would have passed through all three of these states unchanged. After the rename it would have named a function that no longer existed while continuing to be delivered on every turn, and after the deletion it would have done so with no remaining referent at all. Nothing in that arrangement is capable of noticing.

6. Observations from use

We have been running the layer on our own work while building it. That makes a census of the store close to meaningless: aggregate counts over such a window describe the construction of the system as much as the use of it, and items entered in bulk during setup sit alongside items captured during ordinary work with nothing in the totals to separate them. We therefore report two observations that are structural rather than temporal, and we do not report totals.

6.1 Where an item lands is decided by how it was captured

The first observation is visible in Table 1, and it holds regardless of when any particular item was created, because it concerns which grain a capture path is capable of reaching rather than how many items passed through it.

History mining reaches a declaration almost always, because the unit it mines is a commit hunk and a hunk sits inside one. A rule the developer states reaches a declaration rarely, because it resolves one only when its sentence happens to name something the graph knows, and people state policy more often than they state facts about particular functions. Items read out of existing instruction files behave like stated rules, which is unsurprising, since that is what they are.

6.2 Most sessions have nothing to teach

The second observation concerns what a session produces. Of 537 recorded episodes, an episode being one prompt and the activity it produced, 398 were read-only or ended with no edit at all. Only 134 changed the working tree. A session that meets no friction leaves nothing worth remembering, which is obvious once stated and has a consequence that is not: any attempt to measure a memory layer by sampling development tasks uniformly will spend most of its budget observing sessions with nothing to capture. Tasks have to be selected for friction, or the measurement is largely of nothing happening.

6.3 What we can and cannot say yet

The mechanisms described above do fire. Renames have been followed, drift has been flagged and left for review, and items whose declarations were deleted have been withdrawn. We are not reporting rates for any of these, because the window that produced them includes the period in which the resolver itself was being written, and a rate computed across that boundary would describe our development more than the design.

Nor does anything here show that the layer improved an outcome. It shows that the mechanism runs on real work and that two things about it are worth noticing. Whether it helps is a different question, and this paper does not answer it.

7. Limits and open questions

Existence is weaker than truth. What the mechanism decides is whether a declaration still exists, and that is a narrower thing than whether a claim is still true. A claim about the relationship between two declarations can be falsified by an edit to a third. A claim about behaviour behind a stable interface can be falsified without the interface changing. Decidability is bought for one subclass of claims and the layer says which claims those are, which we think is the right trade, but the boundary of that subclass is where we would look first for a stronger mechanism.

Policy has nothing to bind to. A rule stated as policy about a project names no declaration, and the declaration resolver never checks it. This is the sharpest open question the design raises, and it complicates the argument of section 2 in a way worth stating. Lowering the cost of recording something does not by itself make it checkable. A rule about how a project is worked on may need a different kind of validity mechanism rather than a weaker version of this one, and what that generalises to, we do not know.

A rewrite is flagged, not judged. When a body changes underneath a claim the layer records that the claim needs a look and stops there. We think the refusal is right, because both possible errors are costly and neither is visible in the fingerprint, but it does mean drift accumulates as a queue rather than resolving itself. There is also a live possibility that a classifier could answer what we decline to answer, in which case part of our refusal would be a limitation wearing the clothes of a principle.

One user, who wrote the system. The observations in section 6 come from one developer, on repositories we wrote, using a system we wrote, while we were writing it. The store may look as it does because the design is right, or because we state rules in the shape our own extractor happens to parse, and nothing here separates those. They are an existence proof that the mechanism runs on real work and two things we noticed while it did.

Usefulness is untested. We report what is captured and what becomes of it, not whether it helped. Whether an agent that receives such items works better than one that does not is the question a reader will want answered, and answering it requires a design this paper does not attempt: tasks selected for friction, a second encounter with the same difficulty, and a measure that survives the observation that most sessions have nothing to teach. That is the experiment we would run next.

8. Related work

The field has worked since Antoniol et al. on recovering links between code and documents after the fact, with information retrieval over document terms and identifiers, at a quality bounded by lexical overlap between artifacts nobody wrote with linking in mind. Our anchors are not recovered. They are resolved when the claim is written, against a code graph that already knows which declaration a name refers to, so binding is a lookup rather than an inference. That is smaller than it sounds: we cannot link an item to code it never mentions, the case IR recovery exists to serve.

Event-based traceability had artifacts publish change events to subscribers, so a change at one end marked the dependent links suspect and queued them for review, and a line of work since has judged from the code side whether a source change actually alters a design. We concede the descent: our verdict lattice is a suspect-link scheme with more resolution, and unconfirmed is a suspect link renamed. Their tools needed it less, sitting inside a managed repository and seeing every change to both endpoints; our index is a cache that may sit arbitrarily behind the working tree. Hübner and Paech created trace links continuously from developer interaction logs in the IDE, which is the closest published precedent for binding links as work happens rather than recovering them later, and we claim nothing over it.

On the code and comment side, a literature detects fragile comments at the moment of a rename, learns to rewrite a comment from the change that outdated it, and classifies before a commit lands whether a change made its comment inconsistent. This literature decides what our layer refuses to decide: a just-in-time classifier answers the question unconfirmed declines, namely whether a rewrite falsifies a sentence. If such a classifier is accurate enough in practice, part of our refusal is a limitation dressed as a principle, and we would say so.

For entity identity across versions, origin analysis and refactoring detection determine where a function or file came from when entities merge and split, at precision and recall well above a hash sketch. We concede these subsume our identity mechanism and do it far better. The sketch was chosen for cost and language reach on a developer machine, and policy partly rescues it: only total absence of every anchor withdraws an item, so a mislabelled rename changes the verdict text, not what the reader receives.

Among agent memory systems, MemGPT pages items between the window and external storage, Mem0 extracts and consolidates facts for retrieval, A-MEM builds linked notes, and Generative Agents retrieve from a memory stream weighted by recency, importance and relevance. In all of them a stored item is text retrieved by similarity, with no referent outside the store, so none can consult what a memory is about; removal comes from a later contradicting item or from decay. Zep goes furthest: its temporal knowledge graph uses a model to judge whether a new edge contradicts existing ones and stamps the superseded edge with validity bounds instead of deleting it. Our non-destructive expiry is the same instinct and we claim no priority for it; the difference is where the judgement comes from. Zep invalidates from later text through a model, while we compute from the artifact a claim was bound to and decline when it cannot be read.

The nearest work is concurrent. EA-Graph anchors a coding agent’s verification claims to the artifact content used to establish them, resolves aliases to leaf definitions, separates evidence strength from freshness, and returns a claim as unprovable rather than guessing when replacement content is unavailable. It reaches both anchoring at capture and the refusal to guess when an anchor cannot be resolved, independently and about a month before this preprint, and we claim no priority over either. The defensible distinction is scope: EA-Graph carries verification claims evaluated on generated repositories with ground truth known by construction, while our items are arbitrary developer knowledge captured incidentally from real sessions.

Second indexes over source code, such as Kythe and Glean, store schema-defined facts about declarations, references, types and calls, and a second index over the repository is their pitch as much as ours. The difference is the payload. What their index holds is derived from code and recomputable from it, which makes staleness there a performance question. A natural language claim is recomputable from nothing, so it must be maintained rather than regenerated. That difference is why this problem exists at all.

9. Conclusion

Documentation is usually discussed as though its problem were accuracy. Accuracy is the visible half of a problem whose other half leaves no trace: the knowledge never written down produces no artifact to be found wrong later, so it is absent from the discussion in the way that anything unrecorded is absent. Both halves come from one place. Recording something is a commitment to keep it true by hand, that commitment is expensive, and so people record only what seems to justify the expense. The threshold this produces is what we have called the authorship floor.

Removing either cost alone does not work. Cheap capture without expiry produces a store that grows until it costs more than it returns, and there is now direct evidence of exactly that happening in agent instruction files. Automatic maintenance without cheap capture keeps documents accurate and recovers nothing that was never in a document. The two have to fall together, and what makes that possible is that the mechanism which makes forgetting automatic is the same one that makes remembering safe.

Binding a claim to the declaration it describes is one way to get there, and it is cheap to form only because an agent can form it as a side effect of work it was doing anyway. A system built this way can tell that a claim’s subject was renamed, or rewritten, or deleted, or that it currently cannot tell at all. That last state is the part we would most encourage others to take, whatever they make of the rest: a memory system that answers when it has no basis to answer is not being helpful, and admitting uncertainty costs far less than being confidently wrong to something that will act on the answer.

What we have built is an early version of an idea rather than a finished account of it. The design works, in the narrow sense that the mechanism runs and does what section 3 says it does, and section 7 is honest about where it stops. The parts we find most interesting are the ones we cannot yet answer: what validity means for knowledge that names no code, how much coverage a better referent extractor would buy, and whether any of this changes how the work goes.

Availability

The system described here is Koragraph MCP, at github.com/Koragraph/KoragraphMCP. Its source is public under the Business Source License, which permits reading, modification and non-production use, and is not an OSI-approved open source licence. All behaviour described in sections 3 through 5 was verified by reading that source.

References

1. [1]E. Aghajani, C. Nagy, O. L. Vega-Márquez, M. Linares-Vásquez, L. Moreno, G. Bavota, and M. Lanza. Software Documentation Issues Unveiled. In Proceedings of the 41st IEEE/ACM International Conference on Software Engineering (ICSE), pages 1199-1210, 2019.
2. [2]G. Antoniol, G. Canfora, G. Casazza, A. De Lucia, and E. Merlo. Recovering Traceability Links between Code and Documentation. IEEE Transactions on Software Engineering, 28(10):970-983, 2002.
3. [3]P. Avgustinov, O. de Moor, M. Peyton Jones, and M. Schäfer. QL: Object-oriented Queries on Relational Data. In 30th European Conference on Object-Oriented Programming (ECOOP), LIPIcs volume 56, pages 2:1-2:25, 2016.
4. [4]A. Carlson, J. Betteridge, B. Kisiel, B. Settles, E. R. Hruschka, and T. M. Mitchell. Toward an Architecture for Never-Ending Language Learning. In Proceedings of the 24th AAAI Conference on Artificial Intelligence, pages 1306-1313, 2010.
5. [5]K. Chakrabarti. Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding. arXiv preprint arXiv:2608.11095, 2026.
6. [6]P. Chhikara, D. Khant, S. Aryan, T. Singh, and D. Yadav. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv preprint arXiv:2504.19413, 2025.
7. [7]J. Cleland-Huang, C. K. Chang, and M. J. Christensen. Event-Based Traceability for Managing Evolutionary Change. IEEE Transactions on Software Engineering, 29(9):796-810, 2003.
8. [8]J. de Kleer. An Assumption-Based TMS. Artificial Intelligence, 28(2):127-162, 1986.
9. [9]J. Doyle. A Truth Maintenance System. Artificial Intelligence, 12(3):231-272, 1979.
10. [10]Meta Open Source. Glean: A System for Collecting, Deriving and Working with Facts about Source Code. https://glean.software/. Accessed 2026.
11. [11]M. W. Godfrey and L. Zou. Using Origin Analysis to Detect Merging and Splitting of Source Code Entities. IEEE Transactions on Software Engineering, 31(2):166-181, 2005.
12. [12]M. Hammad, M. L. Collard, and J. I. Maletic. Automatically Identifying Changes that Impact Code-to-Design Traceability During Evolution. Software Quality Journal, 19(1):35-64, 2011.
13. [13]H.-J. Hsu, C.-J. Chi, and H. Everett. EA-Graph: Artifact-Anchored Verification Memory for Coding Agents under Upstream Drift. arXiv preprint arXiv:2608.04278, 2026.
14. [14]P. Hübner and B. Paech. Interaction-Based Creation and Maintenance of Continuously Usable Trace Links between Requirements and Source Code. Empirical Software Engineering, 25(5):4350-4377, 2020.
15. [15]D. Jaroslawicz, B. Whiting, P. Shah, and K. Maamari. How Many Instructions Can LLMs Follow at Once? arXiv preprint arXiv:2507.11538, 2025.
16. [16]The Kythe Project. Kythe: A Pluggable, (Mostly) Language-Agnostic Ecosystem for Building Tools that Work with Code. https://kythe.io/. Accessed 2026.
17. [17]P. Mäder and O. Gotel. Towards Automated Traceability Maintenance. Journal of Systems and Software, 85(10):2205-2227, 2012.
18. [18]C. Packer, S. Wooders, K. Lin, V. Fang, S. G. Patil, I. Stoica, and J. E. Gonzalez. MemGPT: Towards LLMs as Operating Systems. arXiv preprint arXiv:2310.08560, 2023.
19. [19]S. Panthaplackel, P. Nie, M. Gligoric, J. J. Li, and R. J. Mooney. Learning to Update Natural Language Comments Based on Code Changes. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics (ACL), pages 1853-1868, 2020.
20. [20]S. Panthaplackel, J. J. Li, M. Gligoric, and R. J. Mooney. Deep Just-In-Time Inconsistency Detection Between Comments and Source Code. In Proceedings of the 35th AAAI Conference on Artificial Intelligence, volume 35, number 1, pages 427-435, 2021.
21. [21]J. S. Park, J. C. O’Brien, C. J. Cai, M. R. Morris, P. Liang, and M. S. Bernstein. Generative Agents: Interactive Simulacra of Human Behavior. In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology (UIST), pages 2:1-2:22, 2023.
22. [22]M. Rahimi and J. Cleland-Huang. Evolving Software Trace Links between Requirements and Source Code. Empirical Software Engineering, 23(4):2198-2231, 2018.
23. [23]P. Rasmussen, P. Paliychuk, T. Beauvais, J. Ryan, and D. Chalef. Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv preprint arXiv:2501.13956, 2025.
24. [24]I. K. Ratol and M. P. Robillard. Detecting Fragile Comments. In Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 112-122, 2017.
25. [25]D. Silva and M. T. Valente. RefDiff: Detecting Refactorings in Version Histories. In Proceedings of the 14th International Conference on Mining Software Repositories (MSR), pages 269-279, 2017.
26. [26]R. Snodgrass and I. Ahn. Temporal Databases. IEEE Computer, 19(9):35-42, 1986.
27. [27]L. Tan, D. Yuan, G. Krishna, and Y. Zhou. /* iComment: Bugs or Bad Comments? */ In Proceedings of the 21st ACM SIGOPS Symposium on Operating Systems Principles (SOSP), pages 145-158, 2007.
28. [28]N. Tsantalis, A. Ketkar, and D. Dig. RefactoringMiner 2.0. IEEE Transactions on Software Engineering, 48(3):930-950, 2022.
29. [29]F. Wen, C. Nagy, G. Bavota, and M. Lanza. A Large-Scale Empirical Study on Code-Comment Inconsistencies. In Proceedings of the 27th IEEE/ACM International Conference on Program Comprehension (ICPC), pages 53-64, 2019.
30. [30]W. Xu, K. Mei, H. Gao, J. Tan, Z. Liang, and Y. Zhang. A-MEM: Agentic Memory for LLM Agents. arXiv preprint arXiv:2502.12110, 2025.