Decisions

Every codebase carries choices nobody can explain six months later: the totals are computed on the server, the queue lives in Postgres, the retry gives up after three attempts. The repository records what changed and the tracker records what was asked for. The reason was said once, in a pull request description or a thread, and then it was gone, and whoever reads the code next either asks the person who wrote it or quietly undoes the reasoning.

Decisions reads the prose your engineering systems already keep and records the decisions stated in it as entities of their own, joined to the code, the people and the conversation they came from. It is deliberately conservative. A proposal is not a decision, a decision nobody wrote down is not inferred, and a reason that was not given is left empty rather than invented, because a wrong reason in the graph is worse than a missing one: it will be read as the reason by somebody deciding whether to change the code.

Where decisions come from

Nightly, for an organisation that has turned the feature on under Organisation → Features, Memtro reads what arrived since the last pass, pull request descriptions, tracker comments and the threads where an approach was argued out, and puts to a model only what already reads as a decision. Each one recorded carries the statement as the thing now true, the reason in the text's own words, the alternative that was rejected where the text says so, a confidence, and what it is joined to: the repository, the code paths and commits it concerns, the thread or pull request it was decided in, and the people.

Reading the register

The Decisions tab under Memory lists them newest first, with four figures at the top: decisions, how many have a reason, how many have none, and how many have been posted back. Filter by repository. Each row shows the statement, the reason or the plain sentence that none was recorded, "instead of" when an alternative was stated, when it was decided and from which system, the people, and two columns of links: what it is about and where it was decided. An excerpt of the memory it was read from sits underneath. Chat about it asks whether the decision still holds, with the agent free to check the code and the systems. An administrator can look for decisions now rather than waiting for the night.

Putting the reason where the code is

A decision joined to a GitHub pull request or issue has a Post to owner/name#n button. It composes a comment, the decision, the reason in the recorded words, the alternative if any, and a line saying Memtro recorded it from which source on which date, and posts it through your GitHub connection. Posting needs that connection's grant for commenting, which is the connector's action permission; there is no separate switch. The row then shows the comment's link instead of the button, so a decision is posted once.

Asking in chat

memtro_why answers "why is this code like this" for a file, a repository or a path: the decisions joined to it, what else touches it, the facts remembered about any of it, and the people. When you ask for the reasoning to be put on the pull request or issue, the assistant posts it with the GitHub connector's comment tool, naming Memtro as the source, subject to the same grant.

What it does not do

• It reads prose, not diffs. A decision visible only in the code, with nothing written about it anywhere, is not recorded.
• GitLab and Bitbucket changes are read but not posted to. The reason can be put on a GitHub pull request or issue; for the others it stays in the register.
• It will not make up a reason. A decision with no stated reason is recorded with none, and says so.