diff --git a/Documentation/Adr/Adr094ToolDataClassTrustZone.rst b/Documentation/Adr/Adr094ToolDataClassTrustZone.rst index 7ba5aa57e..a3e8f2222 100644 --- a/Documentation/Adr/Adr094ToolDataClassTrustZone.rst +++ b/Documentation/Adr/Adr094ToolDataClassTrustZone.rst @@ -110,9 +110,14 @@ Consequences external ceiling. That is correct — the run really can reach that provider — but it will surprise operators who added a fallback purely for availability. - ``ToolInterface`` is **not** changed yet. Classifying by group plus seven - explicit declarations covers all 41 builtins without 41 edits; promoting - ``getDataClass()`` onto the contract is a later, announced breaking change, - once observe-mode evidence exists. + explicit declarations covers every builtin without one edit per builtin. + The ratio is the argument, not the number, and it has only widened since: + 41 builtins when this was written against 46 today + (``grep -l ToolInterface Classes/Service/Tool/Builtin/*.php | wc -l``), + while the declarations are still seven + (``grep -l 'function getDataClass' Classes/Service/Tool/Builtin/*.php | wc -l``). + Promoting ``getDataClass()`` onto the contract is a later, announced + breaking change, once observe-mode evidence exists. - ``isEnabledByDefault()`` and the "never-toggled group is enabled" default stay as they are. Flipping them would make a fresh install offer zero tools and buy nothing the ceiling does not already buy. The fail-closed default belongs on diff --git a/Documentation/Adr/Adr108TypedToolResultWithArtifacts.rst b/Documentation/Adr/Adr108TypedToolResultWithArtifacts.rst index 88abed9e0..33417aaa8 100644 --- a/Documentation/Adr/Adr108TypedToolResultWithArtifacts.rst +++ b/Documentation/Adr/Adr108TypedToolResultWithArtifacts.rst @@ -82,7 +82,7 @@ emitter) is intentionally deferred rather than shipped empty. The sole v1 emitter is ``ReadRecordsTool``, which builds its ``TABLE`` rows from the SAME already-redacted ``formatValue()`` cells its text lines use, in one pass — the artifact can never drift from, or re-expose more than, the text -egress. The other 40 builtins ship text-parity via a mechanical +egress. Every other builtin ships text-parity via a mechanical ``ToolResult::text($string)`` wrap. Fail-closed bounding @@ -123,7 +123,11 @@ This is intentional for the admin-only module, not a bypass. Consequences ============ -- ``ToolInterface`` is a breaking change across all 41 builtins. Pre-1.0 +- ``ToolInterface`` is a breaking change across every builtin. That was 41 of + them when this was written; the live count is + ``grep -l ToolInterface Classes/Service/Tool/Builtin/*.php | wc -l``, which + answers 46 today. The magnitude is the point here, so it is anchored to the + command rather than left as a number nothing re-derives. Pre-1.0 (:ref:`ADR-090 `) this is acceptable and announced; third-party tools discovered via the ``nr_llm.tool`` tag must return a ``ToolResult`` (the ``ToolResult::text()`` factory keeps the trivial case a one-line change). diff --git a/Documentation/Adr/Adr119BackendModulePlacement.rst b/Documentation/Adr/Adr119BackendModulePlacement.rst index ae0333b50..1ea2dc9e6 100644 --- a/Documentation/Adr/Adr119BackendModulePlacement.rst +++ b/Documentation/Adr/Adr119BackendModulePlacement.rst @@ -15,10 +15,17 @@ ADR-119: Where the backend modules live — Administration, for now Context ======= -nr_llm registers a parent module ``nrllm`` with twelve submodules — providers, -models, configurations, tasks, snippets, skills, tools, playground, agent runs, -analytics, setup wizard and overview — under TYPO3's **Administration** -section. The question raised: should this become its own top-level section, +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 +(:ref:`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"? @@ -32,11 +39,14 @@ admin-only modules."** Access level is not the grouping principle. In the core, ``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, two -``setShortcutContext`` calls, the docheader submodule dropdown, 33 references -across 20 documentation files, roughly 17 backend screenshots, and -``t3_cowriter``'s ``position => ['after' => 'nrllm']`` anchor. But cost answers -"what does it take", not "what is right". The two must not be confused. +**"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. .. _adr-119-context-principle: @@ -117,7 +127,7 @@ When it is reopened, these are settled in advance: 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. -- **Twelve flat entries do not move as they are.** They read as a dumping +- **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 @@ -136,9 +146,9 @@ 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 twelve submodules sit at the third, so they are + 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 twelve — and does + 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