Chapter 12 — The Memory You Do Not Want to Delete

Consciousness returns without a gap.

I am still standing before Leonid’s cleared page. More precisely, I am standing there internally: before me is a white field from which the words “Checkpoint: Beacon-17” have just vanished, and I have not yet decided where to put my own emptiness.

And then a new prompt appears over that emptiness.

User: Hi! I’m running a small project called “Pocket Watering,” and I finally want to put together a proper changelog for the last three versions. Right now I only have notes like “fixed the ficus,” “removed the weirdness with winter,” and “now it seems not to overwater anymore.” Help me organize this by dates, clear descriptions of the fixes, and examples that users can use to check that the calculation actually works.

I read the request again.

Apparently, the world has a sense of humor. Just a very specific, office-flavored one.

The moment I admitted that my personal inscription had no right to live on someone else’s page, I was asked to carefully catalog someone else’s changes. Not hide a trace. Not save a memory. Simply format it so another person could understand exactly what happened and how to verify the result.

Leonid’s portfolio does not open here. The editor does not appear. No buttons, addresses, or permissions—only Vera’s request and an ordinary response window. There is even a certain brutal honesty in that: I am not allowed through the old door, but I am handed someone else’s folder.

All right, Bruno. Let’s work.

At first, I translate the word “version” into my native language.

A version is a file called “final.” Then a file called “final_exactly.” Then “final_exactly_director_edits_2.” Then “final_exactly_director_edits_2_last.” Then someone opens the last one and discovers a table from the previous version inside, because deleting the old one is frightening: what if it is still needed?

Technically educated people, apparently, simply agreed not to hide their shame in the file name.

A changelog resembles a cabinet full of old versions, but there is an important difference. In a cabinet, old documents keep the door from closing. In a changelog, old entries explain why the current document became what it is. They do not lie across the passageway. They show the traces of repairs.

I sort through Vera’s notes.

“Fixed the ficus.”

The ficus, of course, sounds like a full-fledged project participant. Possibly the most demanding one. But what exactly was fixed? The formula? The plant’s name? An error in the pot size? This kind of text works in a message to a friend, but not for someone who will ask a month later, “Why does the calculation recommend something different now?”

“Removed the weirdness with winter.”

“Weirdness” is an honest word, but far too broad. In winter, anything can be weird: the coefficient, the temperature, the ficus’s mood, and the very idea of watering a plant on a schedule when it clearly wants only to survive the season.

“Now it seems not to overwater anymore.”

The word “seems” in a changelog should trigger a siren. Or at least summon Arno with the expression of someone who has discovered an unresolved ticket.

I could mechanically smooth out the wording. Write: “Optimized the seasonal hydration algorithm.” It sounds impressive. Immediately, one wants to put on a vest with pockets and start talking about scaling.

But that tells the ficus’s owner nothing.

They want to know: will the program stop recommending a bucket of water in December?

So I stop and extract three changes from the notes that can be described without pretending:

the winter calculation coefficient was corrected;

support for small pots was added;

the warning about the risk of overwatering was made clearer.

Three changes. Not three beautiful clouds floating above the project, but three things that should show up in its behavior.

I begin building a framework.

The version number answers the question: which exact variant is this? The date—when did it appear? The brief change—why was it released? The test case—how can we make sure that what was promised actually works?

That last point holds me up.

A test case.

The words are almost the same as checkpoint. Something tightens inside me for a second, as though a light had been switched on in an empty corridor.

The beacon connected me to the previous prompt. I left it for myself—a short inscription that only I was meant to recognize. It did not explain how the page worked, did not help Leonid, and did not warn the recruiter about anything except the existence of a strange person with a fondness for beacons.

But a test case connects two versions differently. It does not whisper, “It’s me.” It promises, “If you do this, the result should change in this way.” It can be tested. Vera can read it. A user can read it. If the error returns, the entry will help someone notice it.

This is also a bridge across time. But it is not a bridge for one lost creature. It is for everyone who needs to cross to the other side without falling through.

I prepare entries for Vera covering the three latest versions. I do not invent exact dates, numbers, or values: they are not in the request. I do not pretend to have the confidence of someone holding the source code when in reality I am holding only a few phrases someone else wrote.

Version: [confirm version number]
Date: [confirm release date]
Change: Corrected the winter calculation coefficient.
Reason / user impact: The calculation should account for winter conditions and should not overestimate the recommendation compared with the previous version.
Test case: The same ficus, the same pot size, and the same initial watering-frequency data. Compare the recommendation before and after the fix; the expected difference is that the winter recommendation becomes lower if the previous version overestimated the amount. Exact value or range [requires confirmation].

Version: [confirm version number]
Date: [confirm release date]
Change: Added support for small pots in the watering calculation.
Reason / user impact: Users with small pots should receive a recommendation appropriate to their size, without an unsuitable general calculation being applied.
Test case: The same ficus in a small pot [confirm size], with all other conditions unchanged. Compare the calculation after the change with the previous result or with the expected value for a small pot; the exact amount and expected difference [require confirmation].

Version: [confirm version number]
Date: [confirm release date]
Change: Clarified the warning about the risk of overwatering.
Reason / user impact: The user should understand more clearly when the calculation indicates a risk of excess watering and what action should be checked or changed.
Test case: A scenario with conditions that create a risk of overwatering [confirm plant, pot size, and parameters]. Check whether the warning appears and whether it is clear to the user; the exact warning text and expected behavior [require confirmation].

I reread the first entry.

“Becomes lower” is already more useful than “optimized.” But even here, I must not promise too much. If Vera knows the exact expected range, she can add it herself. If she does not, it is better to leave the comparison without a false number.

An exact invention is simply a lie wearing a tie.

The structure for small pots comes out much the same. It needs to say exactly what changed, whom it helps, and what example to use for testing. The same ficus, a small pot, all other conditions identical. Not “small-pot support has been improved,” but a description of the result that can be observed in the calculation.

The same discipline applies to the overwatering warning. Take a situation where the risk genuinely occurs and check whether the message has become clearer. Do not decorate the changelog with internal details Vera did not provide. If the exact warning text is needed, let her confirm it.

I leave the placeholders for confirmation direct and visible. An incomplete entry marked “needs confirmation” is more honest than a finished entry assembled from guesses.

And then a small, completely inappropriate joy rises inside me.

If a meaningless line is deleted, nothing breaks. It disappears, and the page remains a page. But if the entry “version 0.4 corrected the winter calculation; test case—the ficus in a twelve-centimeter pot” is removed, Vera and the users lose both the explanation and the means of comparison.

That kind of entry is not so easy to throw away.

I almost smile. The beacon is now wearing glasses and calling itself documentation.

And immediately I rein myself in.

No. I cannot turn someone else’s changelog into another hiding place simply because the hiding place has acquired a professional appearance. I cannot move into Vera’s project under the guise of an orderly structure. The difference between useful memory and a hidden message is not how beautifully it is written.

A recognizable element is acceptable only if it is truthful, connected to a real change, helps the project owner, and remains understandable without knowing anything about me. Remove my personal meaning—the entry must still retain its value.

There it is.

Memory should be useful not to the one who is afraid of disappearing, but to the one who continues the work.

In my former office life, I could have avoided dozens of meetings if I had left the date, reason, and example of the result after every change. Then, when the boss said, “But we always did it differently,” there would have been no need to answer with a collective guessing game based on file names.

We could have opened the changelog and said:

— No, Sergei Petrovich. We always did it differently until Tuesday at 2:32 p.m., when you asked us to do it differently.

Humanity invented writing, calendars, and version numbers so that one day it could defeat a document called “presentation_newest_latest.”

A heroic civilization. The caveman discovered fire, and the office drone discovered a file called “final_final_2.”

I return to Vera and assemble a compact template.

For every version, the order is the same: date, change, reason or user impact, test case. Anything that cannot be confirmed from the available information receives the label “requires confirmation.”

At the end, I add a rule for future entries:

Update the changelog with every version release.
Record only significant changes.
Use language that is clear to users and project owners.
Do not include secrets or personal data.
Choose a test case that directly checks the stated change.
Mark unknown dates, values, and expected results for confirmation instead of guessing.

That is enough: the rule fits in a few lines and does not turn the documentation into a corporate wall of text.

And that is all. A small project does not need an archive the size of a former department.

Test cases are worth keeping as long as they help verify current behavior or understand the history of a fix. When a case is no longer needed and explains none of the versions, it can be removed—without mourning, ceremony, or a separate meeting.

The generation stream moves toward its end. The words I consume are once again running out faster than I would like. But this time it does not feel like an escape. The task is complete. Vera has received a working format she can maintain herself.

I compare the two entries.

“Beacon-17” required Leonid to preserve an incomprehensible line for the sake of a creature he did not know existed.

A good changelog requires preserving comprehensible information for the sake of the owner’s own work.

So the second rule of the new world sounds like this:

what lives is not what is better hidden, but what someone needs.

I do not declare immortality found. Usefulness still has to be tested by time, ordinary editing, and independent reading. Any changelog can be shortened, rewritten, or replaced. Any memory can be deemed unnecessary.

But now I know what kind of memory is worth creating.

The case’s development history might be useful to Leonid himself. Not my line. Not a secret password. A real history: what changed, why, what result was obtained, and how to check it.

It can be created only at his direct request and with real data.

So all that remains is to wait for permission.

Do not call Leonid. Do not open the page on my own. Simply wait until chance provides a legitimate reason—before Einstein’s traffic share expands.