TYPO3 Dev Companion

It answers from three sources. Almost everything comes from the bundled knowledge/ files, which are bound to versions. Broad API, reference and tutorial questions are searched in the official live TYPO3 documentation instead, with the requested release and canonical source on every result. And some questions have no bundled answer that could be right — which labels exist, which icons are registered, what a configuration value is after every extension has had its say. Those are properties of an installation, so the server finds the one you are working in and asks it, through its own console or by booting it in a subprocess of its own.

It answers before the installation does. The bundled knowledge needs nothing running, and that is the state much of it is asked in: a project that does not exist yet, an upgrade that left the site unbootable, a core checkout with no database. Where the installation itself is the question it is booted through its own interpreter, in its own container where it runs in one. Where it comes up without its essential configuration, every registry in it answers with a subset that looks like the whole — so that state is named rather than passed on as an answer. Where it does not come up at all, the packages are read instead, and every answer carries which of the two it came from and what that leaves out.

The five sources an answer can come from, and what each one needs running before it can answer, are the server's source table.

An agent gets a real task in a real checkout and works under one rule: whatever it would otherwise search for, it asks this server first. Where the server answers, that answer is what the task is done from. Where it does not, the agent solves the task on its own — and that is the half worth something, because the agent now holds an answer the knowledge base did not have. So the session ends by handing it back, and a gap found that way arrives with its answer attached.

Handing it back is one call. typo3_feedback_record writes one markdown file per subject into this server's own checkout, never into the project the session ran in, and it carries the query that exposed the gap, so a later version can be asked the same question rather than read about it. What that becomes is judged against everything else that arrived: one report is a report, and thirty of them out of one kind of checkout is a domain that has been asking for something since the first.

What outlives the session is written down. A requirement states what must be true from now on and names the test that holds it there, a decision states what the change rested on and what would show it wrong, and the queue carries the order of the work. The change is then met again by a session that was never told about it, which is what a forward review is, and the commit that closed a feedback is what the agent who filed it reads back.

That is also what decides what gets built next. What this server does not answer yet is mostly what no session has handed back yet, and a boundary is the other thing and is stated as one in typo3_server_scope. Every step above is a page in records/.