AnacreonUnderstand AnacreonThe concept index
Before an agent can change code, it has to learn its way around. Most do it the slow way, reading file after file until they get the picture, and they do it again every session. The concept index is the cheat sheet a senior engineer would hand a new hire, kept in the repository and updated with the code. Anacreon hands each agent the part of it that its work touches.
A cheat sheet for the code, kept in the code. Each part of the code gets a short entry: what it is for, the one rule not to break there, and which files carry it. When an agent takes a piece of work, Anacreon hands it just the entries that piece touches, so it reads a page or two instead of the whole repository.
On day one, a good senior engineer says: "This folder handles gift cards. Never change a balance except through this function. Here's the test that proves you didn't break it. Last time someone broke it, a card got charged twice." Each concept is that note, written down once, for every agent that comes after.
Every book in a library has one shelf mark, though any number of reading lists can mention it. A book with no shelf mark, or two, gets flagged. Every file has one entry responsible for it, and any number of entries can mention it.
A contractor gets a printed set of plans, dated the day they start. The plans don't change under them while they work, and the inspector checks the job against that same set. An agent's concepts are fixed the same way when it takes a piece.
An entry, called a concept, is one short file in the repository. It's written for an agent, so it skips the background and leads with the rule. Wrong is worse than missing here: an agent that trusts an entry stops checking the code, so nothing goes in that nobody has checked against the code.
A made-up example: an imaginary bookshop's code, not Anacreon's.
Every entry uses the same few headings, always in the same order, and leaves out any it doesn't need:
| Heading | Answers |
|---|---|
| What must stay true | The rules, and what breaks if you break them. |
| Change together | What else has to change with this that the code won't tell you. |
| Verify | The quickest check that proves a change is safe. |
| Traps | What has gone wrong here before. |
| In the code | Where to start reading. |
Entries form a tree. A big area such as checkout is one entry, with smaller ones like gift cards under it. Each can carry a few labels from the project's own list, such as "payments" or "security".
Like a shelf mark, ask "which entry is responsible for this file?" and you always get one answer, or a plain "nobody". Any number of entries can mention a file, the way reading lists mention a book, but only one owns it.
If two entries claim the same file, it belongs to neither, so the clash shows up instead of being settled by accident. A file nobody owns shows up as a gap as soon as a piece of work names it.
Take a made-up piece of work in the same imaginary bookshop: "Let a customer pay with two gift cards at once."
A made-up example. The steps are the ones Anacreon runs on every piece.
Nobody guesses from the piece's description which parts of the code it needs. It says so, and the same rule always gives the same list. Only the chunk's accountable person can change what a piece says it touches, and only before someone takes it.
The agent starts on the right two pages instead of the whole manual. The reviewer judges the work against what the builder was actually told. And months later, the record still says exactly what the agent was given.
The list is a starting point, not a fence. A session can look anything up.
| Like asking | Tool | What comes back |
|---|---|---|
| "Show me the table of contents." | index_outline | The tree of entries, each with its rule, and whether the index passes its checks. |
| "Tell me about gift cards." | index_concept | One entry in full, or just one of its headings. |
| "Who's responsible for this file?" | index_for_path | The entries whose code covers that file or folder. |
If an entry points at a file or function that's been moved or deleted, the check fails and says which. Every outline says whether the index passes.
No checker can tell whether an entry still describes the code. The change that moves the code updates its entry, and the reviewer checks it.
Anyone who can push wrote the index, so agents get it labelled as repository text, trimmed, and with anything that looks like a password withheld.
Anacreon reads the repository through a read-only GitHub app the project installs, never a member's own credentials.
The index is the field manual: short, rule first, for agents. People need the textbook: what the project is, why it's built this way, how to find your way around. That can live in a guide beside the index, written however the project likes, and the index's root says where. Agents aren't handed the guide, though an entry can link to it.
| What | Why it matters | Status |
|---|---|---|
| Finished work says what it changed in the index | An owner can require every submission to name the entries it updated, or say why none, checked against the submitted code | Being built |
| A sweep for broken links | Owners are told once when an entry's links stop working on the main branch | Being built |