ADR-119: Where the backend modules live — Administration, for now 

Status

Accepted (deferred — the placement is not finally settled, see Revisit)

Date

2026-07-28

Authors

Netresearch DTT GmbH

Context 

nr_llm registers a parent module nrllm with fourteen submodules — overview, providers, models, configurations, tasks, snippets, use-case packs, setup wizard, skills, tools, MCP servers, playground, agent runs and analytics — under TYPO3's Administration section. grep -c "'parent' => 'nrllm'" Configuration/Backend/Modules.php answers fourteen, and is the count to re-derive rather than trust this sentence.

A fifteenth nr_llm module, nrllm_aitasks, is parented to web on purpose (ADR-131) because the menu hides a child whose parent's access check fails. It is not a submodule of this tree and must not be folded into the number by a later reader correcting it. The question raised: should this become its own top-level section, a sibling of Content, Media, Sites, Administration and System, and should it be called "LLM" or "AI"?

Two arguments were made against a section and both turned out to be worthless, which is why they are recorded here rather than quietly dropped:

"They are all admin-only modules, and Administration is the section for admin-only modules." Access level is not the grouping principle. In the core, site holds site_configuration (access => admin) next to link-management (access => user), and system is systemMaintainer — stricter than admin, not the same. Sections mix access levels, so this explains nothing.

"A move is expensive." It is — the nrllm route and its bookmarks, the setShortcutContext calls, the docheader submodule dropdown, the module identifier spread across the documentation and its backend screenshots, and t3_cowriter's position => ['after' => 'nrllm'] anchor. This record originally counted them: two calls, 33 references in 20 files, roughly 17 screenshots. Every one of those has since grown. The figures are dropped rather than maintained, because cost answers "what does it take", not "what is right". The two must not be confused.

What the sections actually are 

The core's own definitions (cms-core/Configuration/Backend/Modules.php) group by subject: content is where writing happens, media where files are worked with, site where sites are configured, system the installation itself. Administration is where the instance is administered.

The core also, in v14, added integrations — parent => 'admin', dependsOnSubmodules, showSubmoduleOverview — which is structurally the same shape as nrllm. That is the core's own answer for a cohesive group of admin-facing extension modules: a container under Administration, not a new top-level section.

The argument that actually decides it 

Everything above points at Administration — as long as nr_llm's modules stay a place where a capability is configured and inspected rather than a place where work is done.

They do not stay that, and the reason is not the editor action API. That API (see the roadmap) surfaces AI actions inside the consuming extension's UI, on the record the editor is already working on, so it argues for leaving nr_llm where it is: an editor would never open an nr_llm module.

But a consumer's UI can only ever show data in that consumer's context. An editor also needs cross-consumer answers about themselves:

  • what is my budget, and how much of it have I used?
  • which tools am I allowed to use?
  • which skills apply to me?
  • what did I run, across every consuming extension?

and a lead editor needs the same for their editors, or for a group. None of that is expressible in a consumer's UI, because it is by definition not about one consumer. It is editorial self-service, and it has no home today: the analytics module aggregates instance-wide and is admin-only, no per-user history exists, and per-user budgets have no user-facing view at all.

Once those surfaces exist, nr_llm's module tree is no longer an administration toolset, and the subject argument flips: AI becomes a place where work happens, on a par with Content and Media.

Decision 

Keep the modules under Administration for now. Do not treat this as settled.

The cross-consumer editor surfaces do not exist yet, and building a top-level section for users who cannot yet be served by it would be premature. Nothing about the current placement blocks them.

Revisit 

Reopen this the moment the first cross-consumer editor surface is planned — a personal usage-and-budget view, a personal run history, or a lead-editor view over a group. That is the trigger; not a count of modules, not a preference about menus.

When it is reopened, these are settled in advance:

  • The section is called "AI", not "LLM". It would hold tasks, skills, tools, agent runs and analytics — not just language models. Integrators look for AI.
  • The identifier is vendor-scoped (netresearch_ai), never a bare ai. Module identifiers merge last-package-wins, so a generic top-level identifier is a shared namespace with no owner: the label and icon would depend on package load order, and removing the owning extension would strip the routes of any foreign submodules parented to it.
  • Fourteen flat entries do not move as they are. They read as a dumping ground at any level. Group them by subject first — setup (provider, model, configuration), authoring (tasks, skills, snippets), operation (tools, playground, runs, analytics) — and let the section hold three or four entries.
  • Old routes keep working. Keep the submodule identifiers and explicit paths, repoint setShortcutContext from nrllm to nrllm_overview, and give that module 'aliases' => ['nrllm'] so existing bookmarks resolve — valid only once nrllm is no longer a registered identifier, since an alias is shadowed by a real module of the same name.

Consequences 

  • No code changes. The placement, identifiers, routes and documentation stay as they are.
  • The discoverability problem is real and remains: TYPO3's module menu renders two levels, and nr_llm's fourteen submodules sit at the third, so they are invisible from the main menu. That is worth fixing on its own terms — by strengthening the Overview as the hub, or by grouping the fourteen — and does not require the top level.
  • If the editor surfaces are built without reopening this ADR, they will land in an admin-only section where their users cannot reach them. The revisit trigger exists to prevent exactly that.