---
title: "typo3_server_scope"
description: "Orientation for this server"
canonical: typo3_server_scope.html
---

<a id="typo3_server_scope"></a>

- [Takes](#takes)
- [Answers with](#answers-with)
- [Answered](#answered)
  - [scope](#scope)
  - [scope: one section](#scope-one-section)

<a id="typo3-server-scope"></a>

# `typo3_server_scope`

*Orientation for this server*

Orientation for this server: what it covers and at which depth, what it
deliberately does not cover, and which tool to call when. Start here when it is
unclear whether this server can answer a question at all, or which of the
lookups is the right one. It answers whole, which is the largest answer here.
Where you know which part you need, say whether an installation and its console
answer, name it in sections. Answers from: knowledge, installation.

`readOnlyHint: true` · `destructiveHint: false` · `idempotentHint: true` · `openWorldHint: false`

Answers from [knowledge](../answer-sources.md#answer-sources-knowledge),
[installation](../answer-sources.md#answer-sources-installation).

<a id="takes"></a>

## Takes

```yaml
# The parts of the answer to return, named by the fields they arrive in. Omit it
# for all of them, which is the answer for a caller that does not yet know what
# it can ask this server. Whatever you name, the answer keeps the purpose, the
# instructions clients receive at initialize time, and the tools your list
# lacks. The withheld field says what each part left out would have held.
sections: [string]  # optional
```

<a id="answers-with"></a>

## Answers with

```yaml
# What this server is for.
purpose: string
# The boundary statement clients receive at initialize time.
instructions: string  # optional
covers:  # optional
  - topic: string
    # How deep the coverage of the topic goes.
    depth: string
    tools: [string]
    # Knowledge file or typo3:// resource behind the topic.
    source: string
    # One of: core, project, extension, any. Which kind of work the answers are
    # for. core: the contribution process and the scripts of that repository.
    # any: a convention that holds wherever somebody writes TYPO3.
    scope: string
doesNotCover:  # optional
  - topic: string
    why: string
    # What to do instead of a call to this server.
    instead: string
checkoutDiscovery:  # optional
  - establish: string
    how: string
routing:  # optional
  - when: string
    call: string
# The TYPO3 versions the knowledge binds to. The answer leaves out a statement
# outside a range when it knows a target version.
versions:  # optional
  - major: integer
    # The branch this server verifies that line against.
    branch: string
    # lts, stable, or development.
    status: string
# Which tools are worth a call in the state this machine is in. Where nothing
# runs, the tools answer from knowledge and packages alone. Every tool states
# its own sources at the foot of its description; this groups them the other way
# round.
answersFrom:  # optional
  - # installation, packages, knowledge, network or checkout.
    source: string
    # What that source is, and what it cannot answer.
    meaning: string
    # The offered tools it can answer. A tool with two sources stands under
    # both.
    tools: [string]
excludedTools:
  # The tools that are really gone, and the only reason the list is ever shorter
  # than the documented one. Empty unless the variable has a value.
  names: [string]
  # Names in the variable that took nothing away. No tool answers to the name,
  # or it is one of the three this server offers whatever the variable says.
  # Each of them is in the tool list. Absent means nothing to report, which is
  # the ordinary case.
  ignored: [string]  # optional
  # Environment variable that names them.
  variable: string
installation:  # optional
  # Whether there is an installation to read at all.
  found: boolean
  # Absolute path of the installation.
  root: string or null  # optional
  # core-checkout or composer-project.
  kind: string or null  # optional
  # How the server found it: discovery (a walk up from the start directory) or
  # environment (TYPO3_DEV_COMPANION_ROOT names it).
  via: string or null  # optional
  # Where the search started, or the configured value.
  startedFrom: string or null  # optional
  # The directories the search walked. A failure here means a layout the server
  # cannot read or a server started in the wrong place; this says which.
  searched: [string]
  # TYPO3 packages found in it.
  packageCount: integer
  # Set when the server could not follow a configured value. Nothing falls back
  # to a discovered installation.
  misconfiguration: string or null  # optional
  console:
    # False means every installation-backed tool answers with unsupported in
    # place of its result.
    reachable: boolean
    # ddev, php, or override.
    via: string or null  # optional
    # The PHP version it runs on, where the server knows it.
    php: string or null  # optional
    # The invocation, as the server runs it.
    command: string or null  # optional
    # Why it cannot run. Null when it can.
    reason: string or null  # optional
    # What limits the console the server found. An interpreter of this machine
    # answers for a project whose containers are stopped. That reaches what
    # TYPO3 assembles from its own files and not the services the project's own
    # runtime brings. Null when nothing limits it.
    caveat: string or null  # optional
  settings:  # optional
    # Environment variable that names the installation root.
    root: string
    # Environment variable that names the console command.
    console: string
# The parts this call did not ask for. A field named here is absent from this
# answer rather than empty, so a narrowed answer does not read as the whole one.
# Empty where sections was not passed, which is the whole orientation.
withheld:
  - section: string
    # What that part of the answer would have carried.
    holds: string
```

<a id="answered"></a>

## Answered

Recorded on 2026-09-23 by `bin/cli tools:record`. Answered against
core-checkout, TYPO3 14.3.8-dev, the 14.3 core checkout below .checkouts/. Its
console is out of reach: \<installation\> has no TYPO3 console — none of
bin/typo3, vendor/bin/typo3 exists. Its dependencies are not installed —
vendor/autoload.php is not there either, and composer install writes both.
Nothing checks what is below this heading; everything above it is derived from
the class that answers the call, and `bin/cli tools:check` holds it.

<a id="scope"></a>

### scope

Called with:

```json
{}
```

Text:

```text
A development companion for coding agents working with TYPO3, for the three audiences that do: the core contributor, the extension author, and the site developer. It establishes the project and installation the agent is working in, supplies current, version-bound TYPO3 knowledge, and hands task-specific workflows to the skills that own them so the agent can implement, review, and verify the work. Scope answers describe what is present without treating it as correct; the knowledge and skills supply the conventions that apply, so code found in one installation is not repeated as a pattern merely because it runs. They cover how TYPO3's subsystems are used, the core's own contribution process — the rules, the Gerrit workflow, the scripts and test suites — and a searchable index of backend UI components whose contract is read from the active installation where possible. The server also answers what is registered in the installation it was started in, which no bundled snapshot could get right. Where that installation does not boot, or does not exist yet, the bundled knowledge and the installed packages answer instead, and the answer says which of them it came from and what that leaves out. Every answer says which TYPO3 versions it holds for and which of the three kinds of work it belongs to.

Covered, and how deeply. Each topic says which kind of work its answers are for: core is the contribution process and the scripts that belong to that repository, any is a convention that holds wherever TYPO3 is written. Where the source names the installation, the answer is read from the one this server was started in rather than from any snapshot.
## Contribution rules and review readiness
Curated prose. The rules a patch is judged by, not a full style guide.
Tools: typo3_rule_lookup, typo3_task_guide
Source: typo3://guides/core/contribution/rules (core)
## Gerrit workflow: setup, pushing, amending, opening a patch set on somebody else's change, backports
Curated prose, command level. Covers the local git side; it cannot talk to the Gerrit server.
Tools: typo3_rule_lookup
Source: typo3://guides/core/contribution/gerrit-workflow (core)
## The JavaScript and CSS the core commits beside the sources they are built from
Curated prose, command level. Which source tree produces which committed file, how a minified one is diffed at all, and rebuilding one in a worktree branched off the target branch so the checkout you work in stays as it is. It carries the question that needs the generated files deleted first, and what resolves a backport that conflicted in one. Which suite builds a given branch is typo3_test_run_guide's answer rather than this page's.
Tools: typo3_rule_lookup
Source: typo3://guides/core/contribution/committed-build-output (core)
## What a patch loses when the code moved under it, which no conflict reports
Four steps against a checkout: the commits main landed on the change's paths since its base, whether a fix carried into a file the change rewrites survives in the replacement, the public and protected members it removes that still have callers, and the suites covering the rewritten paths rather than only the changed ones. Plus the one git call that says whether a rebase left the committed JavaScript stale. Where to stop resolving a conflict is typo3-core-patch-checkout's.
Tools: typo3_rule_lookup, typo3_test_run_guide
Source: typo3://guides/core/contribution/rebasing-a-stale-patch (core)
## Forge issues: what one says and what was decided about it, which other issues describe the same thing, and what stands open in the core's backlog
The tracker's own API, read live. By number: the report, the comments that decided it, its related and cited issues, files and review changes. By words: the issues whose text matches, unranked; a differently worded issue is invisible. As a backlog: the core's issues by age, neglect or recency, narrowed by tracker, area, date and person, or broken down per status, tracker, area and year. Each says whether the installed packages still ship the code the report cites — where a symbol stands, not whether the defect reproduces.
Tools: typo3_forge_lookup
Source: https://forge.typo3.org (network) (core)
## Gerrit changes: whether a patch already exists, what state its review is in, which changes touch a path or name a wording, and what stands open in the core's review backlog
The anonymous Gerrit REST API, read live. By change number, Change-Id or commit hash: the change and its Change-Id siblings, current patch set, message, paths, votes, comments, chain, the issues and branches its trailers name, and on request the review log. By words and path: every matching change, in any state or only under review; words match the commit message, not the diff. As a backlog: the open changes by age or neglect, narrowed by size, vote state, mergeability, branch, date and person. A private change is invisible to it.
Tools: typo3_gerrit_lookup
Source: https://review.typo3.org (network) (core)
## Commit messages
Rules plus a working draft and check, including 72-character body wrapping. The subject and body conventions are also served without the core workflow, for a commit in a repository that has no Forge issue and no release branches: workflow="project", where no trailer is demanded and the issues the call passed are written as Resolves: and Related: all the same. The same guide is exposed as the user-invoked prompt commit_message.
Tools: typo3_commit_message_guide, typo3_rule_lookup
Source: typo3://guides/core/contribution/commit-messages (core)
## How the comments and docblocks a patch carries have to read
Ten rules with the rejected sentence and its replacement beside each: say what is, name who acts, one thought per sentence, end on the object, name the place instead of pointing at it, use the words the codebase uses, a longer correct sentence over a short broken one, one fact in one place, say why, and length as a ceiling. Whether a comment is owed at all is the codebase's own rule and this page does not restate it.
Tools: typo3_rule_lookup, typo3_task_guide
Source: typo3://guides/any/writing/the-prose-a-patch-carries (any)
## The changelog entry a core patch owes: which type, which directory a backport goes into, and what checks the file
Curated prose, with the skeleton in the documentation-changelog hint. Which of the four types a change owes and which release directory the file belongs in, keyed on the branches the patch reaches rather than on the branch it is written on. The core ships the file's template and a command that writes it from there, and both are named. Whether the type chosen is the right one is what no check reports.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/core/contribution/changelog (core)
## What a new core issue carries: the fields of a Bug, where the area comes from, who sets the target version, and the markup the description renders as
Curated prose for the authoring direction, with the areas left to the tracker that administers them. Which trackers the core project offers, the field set of a Bug and the one field it does not go without, and the order a report is written in. The description renders Textile: the syntax is named, and so are the three things Markdown habits get silently rewritten into. Filing the issue stays the caller's — it needs an account and this server holds none.
Tools: typo3_rule_lookup, typo3_forge_lookup
Source: typo3://guides/core/contribution/reporting-an-issue (core)
## Core testing suites: runTests.sh options and targeted invocation
Every suite this knowledge base knows, with the command, the targeted form, and when to use it. The script is part of the core repository, so paths that read as a project or third-party extension get the boundary stated instead of a command.
Tools: typo3_test_run_guide, typo3_script_lookup
Source: knowledge/test-suite-hints.json, typo3://guides/core/testing/scripts (core)
## Proving what a rendering contains, where a finding turns on it and no test in the checkout produces it
The throwaway functional test that renders one page and prints what came out: the cObj that puts a snippet through parseFunc, the operator forms a value has to be written in, how output is got out of a test that would otherwise print nothing, one marker per region so the response says which part of it changed, printing what a service holds from inside the request, the targeted invocation, and where the RTE setup comes from per version. It says nothing about what parseFunc does to a snippet, which is what the probe is for.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/core/testing/proving-a-rendering (core)
## Exercising the system resource publisher from a functional test
Which of the three file system publishers a test instance actually runs and why the application context does not decide it, why publishing is a no-op for any package whose path lies under the public path, and which of three states at the publishing target raises a real failure rather than a silent success. From TYPO3 14, where the SystemResource namespace arrived. What a package registers as a public resource is a hint rather than this page.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/core/testing/exercising-asset-publishing (core)
## Timing a code path between a patch and its parent, where a review asks what a change costs at runtime
The throwaway functional test that calls one path many times and prints what a call cost: the warm-up call outside the loop, hrtime() and the per-call division, the same probe run on the patch and on its parent so the finding is a ratio, and the three things the number leaves out — the SQLite default, the per-process runtime cache, and one process without load. It says nothing about what the path does, which the probe is for.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/core/testing/timing-a-code-path (core)
## The PHPUnit configuration an extension runs its own tests with
The two files a package writes into Build/, whole and ready to write out, one variant per PHPUnit the paired typo3/testing-framework release admits. Beside them: which two attributes a copy has to correct and why the bootstrap is referenced rather than copied, the environment a functional run reads its connection from, and what a finished suite leaves behind. It does not set the harness up for you and it names no dependency constraint — which release resolves is the solver's answer, not this document's.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/extension/testing/phpunit (extension)
## What an extension's Documentation/ directory consists of
The two files that make a directory a manual and the conventional ones beside them: a minimal guides.xml to copy, the Index.rst header and toctree that pull the chapters in, and the two files that look like a template and are not — a core system extension's renderer configuration and the Settings.cfg of a manual that predates it. Beside them the render command, what its "successfully placed" does not promise, and the flag that makes a failed directive a non-zero exit. It does not write the chapters, and what a manual is for is the extension-documentation hint.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/extension/documentation/manual (extension)
## Whether an API is there on a TYPO3 major the package declares and the installation does not have
The reading that settles it: which declaration says who the question is about, what the changelog settles and where it stops, the invocations that read one symbol off the branch carrying the other major, and the path the installed copy spells differently. Beside them what a compatibility argument owes where nothing can be run. It reads no core source itself and states no signature: a bundled one is wrong at the next release, and a wrong one is believed as readily as a right one.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/extension/compatibility/a-declared-major-that-is-not-installed (extension)
## What the backend styleguide states about a component, and what it leaves unstated
Where the styleguide lives on each major and how it is installed where the core does not ship it, what its listing settles — a component it lists is public and one it does not is not to be used — and the two ways a demo is misread: an example is complete, so nothing in it says which parts are required, and a demo renders through ViewHelpers and web components, so the classes in its template are neither all of what a component uses nor only that. It names what places a class instead.
Tools: typo3_rule_lookup, typo3_component_lookup
Source: typo3://guides/any/backend/using-the-styleguide (any)
## Which route a package's own CSS or JavaScript takes into a page, and what proves it still carries
Every route and the check that belongs to it: the backend import map, which is a file and compares statically; a backend module's PageRenderer calls; TypoScript includeCSS, which no file settles because the resolved setup for one site decides it; the AssetCollector behind f:asset.css, where a call outside the rendered section registers nothing and produces no 404 either; and the later arrivals f:asset.module and f:asset.styleAttr. It closes on what to do after a rebuild renamed, moved or dropped an output.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/any/assets/how-an-asset-reaches-a-page (any)
## Running a package's own suite against a TYPO3 major it declares and the installation does not have
The procedure, as it was carried out: what the repository's CI already covers and what pushing proves, the Composer root of its own the other major is resolved into and the manifest that root carries, what the working installation keeps, what the second root resolves differently from it, whether the database survives, which checks are worth re-running there, and what a resolved tree is not. It installs nothing itself, and it says what a claim about what renders on the other major would additionally cost.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/extension/compatibility/running-on-a-declared-major-that-is-not-installed (extension)
## The Playwright suite a project runs its browser tests from
The configuration, the backend login and one spec, whole and ready to write out, with the login in the variant each TYPO3 major needs. Beside them: where the base URL and the credentials come from, why the login runs once, and which locator on the login form is ambiguous. It does not install anything and names no dependency version.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/project/testing/playwright (project)
## Booting a cloned project repository into a running installation
The run in order, from a clone to a site that answers on both sides: what the clone does not carry, why the environment is started twice, where the data comes from when the repository declares no import, what makes the installation agree with the code in front of it, and what a login costs. It runs nothing and starts nothing. Creating an installation for a package that declares no procedure is the neighbouring task and begins a step earlier.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/project/installation/booting-a-clone (project)
## Renaming an extension key, its tables or its CTypes in an installation that holds records
What the rename touches on the data side and in which order: that extension:setup creates the new tables and drops nothing, why INSERT ... SELECT * between two tables of one TCA is positional, every column that stores a name as a value — CType, backend_layout, sys_file_reference, sys_refindex, the extensionDataImport registry key — and the command that composes an identifier rather than spelling it. It runs nothing, and the proof it names is a query rather than a suite.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/project/refactoring/renaming-an-installed-extension (project)
## Looking at a change in a real browser, against the installation that has the content
Which installation can show the case at all, how a browser running in a container reaches a DDEV site — the router's network and its hostname aliases, the certificate it does not carry, the wildcard hostname it cannot answer — and where a harness and its screenshots go so neither reaches a commit. It runs nothing and starts no installation.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/any/testing/browser-check (any)
## Drawing the icon a content element is picked by, and the set it belongs to
The 16-pixel box every icon in the core's own content set shares, what that set actually varies to tell one element from another — silhouette and palette rather than lines inside one frame, measured over its 115 files — and the check that says a set works, which is naming each icon at rendered size without its label. Whether an identifier resolves is typo3_icon_lookup's and is a different question.
Tools: typo3_rule_lookup, typo3_icon_lookup
Source: typo3://guides/any/icons/drawing-a-content-icon (any)
## Proving that a TypoScript condition matched against a running installation
How a verdict nothing prints is established from the page: what the backend's condition list is and is not, how a marker is derived from what the guarded branch alone renders, the shared Fluid wrapper that is no marker, a marker put into the condition on purpose, the negative control, and which cache stands between two runs. It requests nothing and flushes nothing.
Tools: typo3_rule_lookup, typo3_hint_lookup
Source: typo3://guides/any/testing/proving-a-condition (any)
## Proving that a change to how a site renders changed only what it meant to
How the pages to capture are chosen from the content that exists rather than from what the templates allow, why the baseline is captured twice before anything is edited, which cache group leaves the compiled Fluid behind so the second capture is the old template, and how the union of the diffs is read for the line nothing explains. It requests nothing and flushes nothing.
Tools: typo3_rule_lookup, typo3_record_lookup
Source: typo3://guides/any/testing/proving-a-rendering-held (any)
## Reporting a security defect in TYPO3: who receives it, what the report carries, and what is not done with it in the meantime
TYPO3's own published policy, as the core repository's SECURITY.md and the security team's pages state it. It holds for a defect in the core and for one in an extension alike. It carries no judgement of how bad a finding is: rating one is the team's work, and this says where it goes.
Tools: typo3_rule_lookup
Source: typo3://guides/any/security/reporting-a-vulnerability (any)
## Where the upstream contribution documentation is
The official contribution workflow guide is not bundled: this names its entry points, so a question past what the local documents answer is sent to the source rather than guessed at. The local policy that sits beside it is this repository's own.
Tools: typo3_rule_lookup
Source: typo3://guides/core/contribution/sources (core)
## Core conventions: DI, events and hooks, TCA and FormEngine, FormEngine data providers, DataHandler, routing, Fluid templates and ViewHelpers, frontend page rendering with PAGEVIEW, how a sitepackage is laid out, records in the frontend and the routing for them, registering a content element, Extbase plugins, TypoScript site sets and TSconfig, language files, upgrade wizards, frontend DataProcessors, upgrading an installation, testing strategy, assembling a test suite for a project extension, setting up static analysis and the coding standards fixer for an extension, browser and accessibility tests with Playwright
Conventions per subsystem, matched by path or topic, from both angles: what a change to the subsystem has to satisfy, and how the mechanism is used. It describes how the core is built, never what your checkout contains.
Tools: typo3_hint_lookup, typo3_task_guide
Source: knowledge/hints/ (any)
## Task workflows for extension, sitepackage and project work: backend modules, content elements, the state of a whole package from the audit through to committed changes, judging one incoming change proposed against it, the content a distribution ships, the asset build that produces its CSS and JavaScript, documentation, tests and static analysis, bringing the local development installation into existence and running the one that already answers, and repairing what a TYPO3 major removed in a package or carrying it to another version
The skills this server publishes, one resource per workflow: the order the steps are taken in, with the lookup that owns each fact named at the step that needs it. A skill is followed while the work is done rather than read, and what it states about TYPO3 itself is a lookup instead of a sentence, so a published copy cannot go stale. bin/typo3-dev-companion install writes the same files into the client's own skills directory; the resource is the route for a client that never ran it. What a workflow hands over at a step — the order every task starts in, a checklist, an implementation guide — is served under the same URI as that workflow and is read when it sends you there.
Tools: typo3_task_guide
Source: typo3://skill/typo3-backend-module-development/SKILL.md, typo3://skill/typo3-content-element-development/SKILL.md, typo3://skill/typo3-development-installation/SKILL.md, typo3://skill/typo3-distribution-content/SKILL.md, typo3://skill/typo3-extension-documentation/SKILL.md, typo3://skill/typo3-extension-health/SKILL.md, typo3://skill/typo3-extension-patch-review/SKILL.md, typo3://skill/typo3-extension-asset-build/SKILL.md, typo3://skill/typo3-extension-testing/SKILL.md, typo3://skill/typo3-extension-upgrade/SKILL.md (any)
## The core's own task workflows: saying what an open issue still claims, getting a patch under review into a checkout, writing a patch and carrying it to review, and reviewing somebody else's patch set
The same shape as the workflows beside them, with the steps that stop at the core repository: the Forge issue and the backlog it came out of, the ref a patch set is fetched by, the suites of runTests.sh, the changelog entry a change owes, and the Gerrit push. Two of the four end before the act that is somebody else's — a triage writes a verdict and touches the tracker in no way, and a checkout stops where the patch no longer decides its own conflicts rather than resolving past it.
Tools: typo3_task_guide
Source: typo3://skill/typo3-core-issue-triage/SKILL.md, typo3://skill/typo3-core-patch-checkout/SKILL.md, typo3://skill/typo3-core-patch-development/SKILL.md, typo3://skill/typo3-core-patch-review/SKILL.md (core)
## Official TYPO3 API, reference and tutorial documentation
Live lookup in the public tables of contents of TYPO3 Explained, TypoScript Explained, the TCA Reference and the Fluid ViewHelper Reference, bound to one covered documentation release. Every result keeps its canonical URL, document, version and section; pass that URL back with the same target version to read the page as text, including headings and code examples. An unreachable service is not an empty search.
Tools: typo3_documentation_lookup
Source: https://docs.typo3.org (any)
## Whether a documentation permalink resolves, what it lands on, and which identifier replaces an old docs.typo3.org URL
The Sphinx inventory every manual publishes, read for the names a permalink addresses rather than for the pages. Per identifier: the page and anchor it reaches, what the manual registers the name as, every other spelling reaching the same target, and which of them the manual declares rather than generates. Per URL: the identifiers pointing at it, or, where the page is gone, the names carrying the words of the URL as candidates a reader picks from. Many at a time, because one inventory answers every identifier of its manual. It says which branch answered, since the host serves main for a manual it has no branch for and says nothing about it. The named manuals are a maintained list and a system extension is addressed by its Composer package name; an extension manual outside the core is not answered for, because it is versioned on its own releases rather than on TYPO3's.
Tools: typo3_permalink_lookup
Source: https://docs.typo3.org (network), knowledge/manuals.json (any)
## Backend CSS architecture, design tokens, class naming
Curated prose covering the Sass sources, the token contract, and the component structure.
Tools: typo3_hint_lookup, typo3_rule_lookup
Source: knowledge/hints/backend-css.json (any)
## Backend UI components: markup, variants, custom properties
A curated searchable subset, not every CSS class in the core. When targetVersion is the active installation, installed backend CSS and JavaScript supply presence, classes and custom properties, and a matching installed styleguide example supplies markup. The bundled version-bound snapshot is the fallback and still supplies names, summaries and keywords.
Tools: typo3_component_lookup
Source: installed EXT:backend and EXT:styleguide files; knowledge/catalog/component/entries.json as index and fallback — read from the installation being worked in, not from a bundled snapshot. (any)
## Which extensions the TYPO3 core ships, and on which versions
Every system extension of every covered TYPO3 line, by extension key and Composer package name, with what it is for and the range it is shipped on. Derived from one checkout per covered version, so it answers for an extension that is not installed — which is the case the question is asked in. A miss says the name is not a system extension there, never that it does not exist.
Tools: typo3_system_extension_lookup
Source: knowledge/catalog/system-extension/entries.json (any)
## Where the core keeps its own worked examples
An index rather than the examples themselves: one line per directory on what it is a reference for, the Composer package an installation can read it from, and the versions it exists on. It is what a hint is a summary of, so it is the better answer where a hint is thin or where a subject has none yet.
Tools: typo3_reference_list
Source: knowledge/catalog/reference/entries.json (any)
## Translation domains: how the domain of an XLF file is derived
Complete and computed, not a snapshot: the core's own path-to-domain rules ported here — the class that holds them is TranslationDomainMapper on one branch and TranslationDomainResolver on the next, so compare against whichever your checkout has, so any XLF path in any extension resolves — including a file that does not exist yet. Where the installation being read is older than translation domains, the full LLL:EXT: reference is the answer instead: the domain form renders nothing there.
Tools: typo3_translation_domain_lookup
Source: src/Knowledge/Catalog/TranslationDomain.php, knowledge/hints/labels.json (any)
## How current the catalogs are
Whether component contracts came from the active installation or the bundled fallback, plus the core revision, branch, and verification date behind that fallback.
Tools: typo3_snapshot_scope
Source: knowledge/catalog/meta.json (any)
## What the installation you are working in supplies: backend component contracts, labels, icons, backend modules, Fluid namespaces, effective configuration, the columns TYPO3 derives for a table beside what its database has, the services its container assembles, and the data structure one of its flex fields resolves to
Answered by that installation rather than from a snapshot, across the packages it has active — project extensions included. Component presence, classes and custom properties come from the installed backend CSS and JavaScript, with installed styleguide markup where available. Label reuse is restricted to the XLF resource used at the consuming code; an instance-wide match from another resource is discovery, not a reuse candidate. Its console does the answering wherever a command exists, and where none does — the icon registry, and the effective configuration, whose command arrived in TYPO3 14.2 and would leave the two LTS lines holding "command is not defined" — or where the command carries less than the registry — the backend modules, whose navigation component is inherited and whose routes it does not export — TYPO3 is booted in a subprocess and its container asked; package files answer where neither can be reached, or where the installation has no configuration yet and boots into a core-only failsafe container. The columns a table gets from its TCA are read the same way and have no file to fall back on: they are what the core would create, so only the core can say them. A type=flex column is resolved through that installation's own FlexFormTools, from a record emulated out of values the caller passes, so what comes back is what the backend form would build rather than what the referenced file says. Every answer identifies its source, so a fallback stays visible. A schema answer carries what the database has for the named table beside what TYPO3 derives, and what TYPO3 itself would change to make the two agree. The container is assembled a second time to be read, so a private service, a decoration and what each constructor is really handed are answered rather than what a Services.yaml says.
Tools: typo3_component_lookup, typo3_label_lookup, typo3_icon_lookup, typo3_backend_module_lookup, typo3_fluid_namespace_list, typo3_configuration_lookup, typo3_schema_lookup, typo3_service_lookup, typo3_flexform_lookup
Source: the discovered TYPO3 installation — read from the installation being worked in, not from a bundled snapshot. (any)
## What is in a table of one of this project's own extensions
The rows and the numbers over them: how many there are, which page they sit on, whether they are live, hidden or deleted, and the rows themselves with their uid, the label the table names in its own ctrl, the timestamps and the two flags. Narrowed by exact values for any column, pid among them. It is what says where the records are maintained — one page of the record list is a table nobody has to leave the list for — and what is actually stored, which no schema answer reaches. Every other table is refused, the user tables and the core's among them, and every answer says it was read with the shell user's database access rather than with a backend user's permissions.
Tools: typo3_record_lookup
Source: the discovered installation, booted, with one grouped count and one row read against its database. What a row carries is fixed here rather than composed by the caller. (project)
## The project around the installation: its extensions, its sites and their sets, its own commands, the environment it declares and what that environment runs by itself, and what one of those extensions registers
Read from the repository's files — composer.json, package.json, config/sites, .github/workflows, and the .ddev configuration where there is one — so it answers on a fresh clone, before anything is installed or migrated. The declared commands are what a caller may run; a DDEV project also states the PHP its container runs, the hooks that fire at a stage of their own with the command each runs, and the pull recipes its database and files come from. Both interpreters those commands run on are stated and related: the PHP the manifest declares, the installed core requires, the install is bounded at and the environment runs; and for the npm half of the list the Node engines.node admits, an .nvmrc pins, an actions/setup-node step sets up and a DDEV nodejs_version states. A workflow is read for that one field rather than for what it asserts, and a version it leaves to a matrix or another file is handed back unresolved. It describes what is there and does not rate it; the one thing it volunteers is a core deprecation whose predicate is a registration file the extension ships, because nothing a caller would think to search for reaches that. Per extension: the tables its TCA defines and extends, the content elements it adds to tt_content with the Fluid template each renders through and the FlexForm each binds, its backend modules and routes, its icons, its site sets and the files core reads each set for, the form configurations it registers and the definitions they store, its service tags, its middlewares, which of the Fluid root directories it ships and the namespaces it registers globally, the shape of its Classes/ directory, and which of the registration files it ships a deprecation names. Its tables, content elements and icons come from the booted installation where there is one; the rest is read from files, and where the installation could not be booted the answer says what a file-read list leaves out.
Tools: typo3_project_describe, typo3_extension_describe
Source: the discovered project — read from the installation being worked in, not from a bundled snapshot. (any)
## What a TYPO3 version broke, deprecated, added or noted
One entry per change, searched by words, type and version. The entries come from the changelog docs.typo3.org renders after every merge, so a version nobody has installed and a change merged today are both in reach. The core package on disk answers what docs.typo3.org does not list, and everything where it does not answer. Each entry says which of the two it came from, because a version that is not released yet is still being written.
Tools: typo3_changelog_lookup
Source: docs.typo3.org for every covered major, and the discovered installation for what docs.typo3.org does not list or where it does not answer. Not a bundled snapshot either way. (any)
## Which versions of an extension the TYPO3 Extension Repository has published
The registry's own API, read live by extension key: every published version with its number, its state, the day it was uploaded, the TYPO3 majors it declares and the constraints.depends.typo3 it was released with, highest number first — and, where a version is named, whether the registry already holds that number. It is the question a release audit cannot answer from the repository it is auditing, because ext_emconf.php names the released version afterwards as much as before. It reports what is published and judges no version free to release, and it reads nothing inside the package: a key nothing is published under is an answer rather than a statement that no such extension exists.
Tools: typo3_ter_lookup
Source: https://extensions.typo3.org (network) (extension)

Query this server in English, whatever language you are speaking with the user. Its knowledge is written in English and its matching is lexical, so a query in another language reaches only the words the two happen to share and otherwise comes back empty.

Versions this knowledge binds to:
- TYPO3 v12 (12.4, lts)
- TYPO3 v13 (13.4, lts)
- TYPO3 v14 (14.3, stable)
- TYPO3 v15 (main, development)
A statement that does not hold on all of them carries the range it holds on. Pass targetVersion to have the ones that do not apply left out; without it, the version of the installation being read decides, and where there is none nothing is filtered.

Deliberately not covered — and this list is the boundary: a subject that is not on it is in scope, so a thin answer to it is a gap in the knowledge base rather than a limit of it. Record one with typo3_feedback_record instead of going elsewhere.
## Your git state: changed files, branch, working tree, commit message, history
This server reads the directory it was started in — a core checkout as readily as an installed project — but it never runs git. What it reads are the files a package ships and, where a console answers, the container behind them. Nothing here knows what you changed, what you committed, or which branch you are on.
Instead: Ask git yourself. One "git show --name-only --format=%B HEAD" carries both things this server's own guides ask for: the changed paths typo3_test_run_guide narrows suites by, and the message typo3_commit_message_guide checks. Pass the paths to typo3_hint_lookup and typo3_task_guide for the conventions and checks that apply to them.
## PHP source as code: a method signature, whether a class or member is @internal or public API, an implementation to copy
No core sources ship here, and nothing reads a class for what it declares. Where the files a package ships are read at all it is for what they register — an icon, a namespace, an extension's own metadata — never for a signature or an annotation. Whether a removed method was public API is therefore still a question for the checkout, and it is the one that decides whether a removal is breaking.
Instead: Read the class. TCA is a different question and is answered here: typo3_schema_lookup returns the table as the installation's container assembles it, which is not what any single file says. typo3_changelog_lookup says what a version broke, deprecated or added, and typo3_hint_lookup says what the subsystem is built to.
## Which test covers a given file
Test coverage is a property of the checkout, and no index of it is bundled.
Instead: Core tests mirror the class path below typo3/sysext/<ext>/Tests/Unit/ and Tests/Functional/, so typo3/sysext/core/Classes/DataHandling/DataHandler.php is covered by typo3/sysext/core/Tests/Unit/DataHandling/DataHandlerTest.php. Look the file up there, then ask typo3_test_run_guide for the targeted runTests.sh invocation.
## Frontend theming: the CSS and the JavaScript a website renders
Everything here about CSS and TypeScript describes the TYPO3 backend interface — its Sass sources, its --typo3-* token contract, its light and dark color schemes, its move away from Bootstrap. For a theme extension those are not a milder version of the right answer, they are the opposite of it. How a theme extension is laid out is a different question and is not excluded here: the core ships its own theme as a system extension, and the conventions it establishes — the template tree, the layout names, the backend layout files — are in the hints.
Instead: typo3_hint_lookup withholds the Backend CSS and Backend TypeScript and JavaScript hints where a task names the frontend, and returns what does transfer — Fluid, TypoScript, PHP, and the sitepackage layout. The styling itself is documented at https://docs.typo3.org.
## Whether an uncatalogued component or CSS class exists on your branch
The active installation supplies the contract for curated component entries, but the searchable index is deliberately a subset rather than every class in backend.css. Without an installation, even those entries fall back to one pinned core snapshot.
Instead: The component answer already says which source supplied the contract, which core revision the bundled snapshot was taken from and the command that re-checks it. Inspect the installed backend CSS, or the target checkout, for a class outside the curated index.
## Gerrit beyond what an anonymous read answers: the hunks of a patch set, a draft comment nobody published, what CI did beyond the line its bot posted, and anything a private change carries
The review API is read without a credential, so a draft and a private change are outside it. The diff itself is not read over the API — the answer carries the paths the patch set touches and the ref that fetches it, and the checkout is where the hunks are read. Nothing here writes to Gerrit.
Instead: typo3_gerrit_lookup answers what an anonymous read carries: the change, its current patch set and commit, the paths it touches, its votes and comments, and the ref that fetches it — hold that commit against your own HEAD, and fetch the ref for the hunks. Voting, commenting and uploading stay yours: the web UI and git, and typo3://guides/core/contribution/gerrit-workflow carries those.
## What someone else's extension does: the API, the options and the documentation of a package the core does not ship
Writing an extension is covered — the extension author is one of the three audiences this exists for, and the registration files, the subsystem conventions, the sitepackage layout and the test suite are all here. What is not here is the inside of somebody else's package: it has its own API, its own release cycle and its own documentation, and none of them is read by this server. The registry's published record for a key is the exception and is answered: which versions are out, what each declares and when it was uploaded, which says nothing about what any of them contains. Whether a name belongs to the core at all is a different question, and typo3_system_extension_lookup answers it.
Instead: Read that extension's own documentation. What an installed extension registers — yours or a third party's — is answered by typo3_extension_describe from the files it ships, and what the TYPO3 Extension Repository has published under its key by typo3_ter_lookup.
## Deciding one site's configuration: its languages, its base and the variants per environment, its error handling, and the steps that install it
A site set is a convention and is covered; what one installation writes into config/sites/<identifier>/config.yaml is that site's decision, and nothing here would make one answer to it more right than another. The file is read rather than composed — typo3_project_describe reports the sites a repository configures and the sets they depend on.
Instead: Read what the project already has with typo3_project_describe, ask typo3_hint_lookup with id=site-sets for what a set ships and how its settings resolve against a site's own, and take the configuration format and the language setup from https://docs.typo3.org/.
## Running an installation: server and container setup, deployment, backups, the editorial use of the backend
The knowledge base is about what is written into a TYPO3 project — its extensions, its configuration, its templates and its tests. Operating the installation around it is a different subject with different sources. What a project's own environment file declares is the exception, because that file is written into the project.
Instead: Use the TYPO3 documentation at https://docs.typo3.org/. typo3_project_describe reports what the environment file configures. Which interpreter to declare in it is typo3_hint_lookup with id=php-versions, asked before there is an installation to ask anything else.
## The content of the installation's own tables: a record of pages, tt_content, a file reference, a workspace, a user
The content model is answered here throughout, and the content itself is read rather than written. typo3_schema_lookup returns any table as the installation's container assembles it; typo3_record_lookup reads the rows of any table this installation has TCA for, and refuses what TCA does not describe. What that reading is worth knowing about is the trust model: your client launches this server as a stdio subprocess, so the process boundary is the whole of its security, and a row comes back with the shell user's database access rather than a backend user's permissions. Every answer says so, and no answer is narrowed by a permission, a workspace or a language.
Instead: Write the records where the permissions apply — the backend, or the installation's own console at vendor/bin/typo3. For what a table holds, its columns and their types, ask typo3_schema_lookup; for the rows themselves, how many there are, which page they sit on and what one column holds across them, typo3_record_lookup; for what may be written into a flex column, typo3_flexform_lookup, which emulates the record from values you pass rather than reading one; and for what the DataHandler expects of code you write, typo3_hint_lookup.

Which tool to call when:
- Asked to review, audit or assess a project, a site package or an extension — before opening the first file, because what a finding is worth depends on the version and the commands this repository has → typo3_project_describe, then typo3_task_guide for the workflow and typo3_extension_describe for each extension in scope
- Going through the core's open issues — the oldest, the ones nobody has touched for years, or what stands open in one area such as the RTE or the backend UI → typo3_forge_lookup with backlog="oldest" or open="stale", narrowed with category in the user's own words and with tracker, then typo3_forge_lookup with the number of the one being taken further
- What one person has filed on the tracker, or what they still hold — one contributor's backlog, or what a core team member has open → typo3_forge_lookup with backlog="oldest" and involving in the person's name for both sides at once, or reportedBy or assignedTo for one of them, with status="all" for the years and breakdown=true where the count is larger than a page; never query with the name, which matches the text of an issue rather than whose it is
- Writing the title and the description of a core bug report, or filling in the new-issue form on forge.typo3.org — including the issue a patch's Resolves: trailer will point at, which is written before the patch is pushed → typo3_rule_lookup with documentId="core/contribution/reporting-an-issue" for the fields and the Textile the description renders as, then typo3_forge_lookup with category="*" for the areas the Category field takes, and for whether it is already reported typo3_forge_lookup with query in the words of the symptom and again with backlog="newest", createdSince from the day the defect could first have been reported and limit=50 — a wording reaches only the issues worded that way, and reading the subjects of everything filed since is what settles a negative
- Taking a Forge issue on, before believing what it describes — an issue can be stale, already fixed, or closed on a decision that is not in its description → typo3_forge_lookup for the issue and its comments, then typo3_forge_lookup again with query in the words the issue uses for the other issues describing the same thing — its relations carry only what somebody linked by hand — then typo3_gerrit_lookup with the same number for whether a patch exists already
- Before writing a patch for a file, and when asking whether a fix has been attempted before — neither is answerable from a checkout, since a clone carries what landed and says nothing about what is open → typo3_gerrit_lookup with path for the changes touching it and open for the ones still under review, then again with query in the words a commit message would use
- Starting a review session without a change in hand — which open reviews have been sitting a long time, which are small and almost voted through, which are mine and which have I already voted on. A checkout answers none of it and the review server sorts by last activity alone. → typo3_gerrit_lookup with backlog "oldest" or "stale", narrowed by maxSize, minCodeReview, negativeVotes, mergeable, branch, updatedBefore, owner, reviewedBy, involving or reviewableBy, then again with change on the number picked off the page for its votes, its comment threads and the patch set to fetch
- Holding a commit hash and asking which branches carry that fix — closing an issue as fixed, or saying where a backport went. A clone answers it in several git calls per commit, and the Releases: trailer that settles it is what it reaches last. → typo3_gerrit_lookup with commit, which answers the change that hash is a patch set of, the backports sharing its Change-Id with the branch each of them targets, and the branches every commit message's Releases: trailer claims
- Reviewing a TYPO3 core patch — the current changes in a core checkout, a commit, or a change fetched from Gerrit — rather than a project or an extension → typo3_gerrit_lookup with the Change-Id or the change number for what the patch is — the paths it touches, the branch it targets, its commit message and the issue it names — then typo3_rule_lookup per obligation the diff raises, typo3_changelog_lookup for the precedent, typo3_test_run_guide with the changed paths, then typo3_commit_message_guide with workflow="core"
- Settling a finding on what a rendering contains rather than on what a diff says — TypoScript defaults, TypoScript declared in an ext_localconf.php or anything below lib.parseFunc, and equally a PHP change to the frontend request pipeline, an error handler or a page renderer caller whose effect is only visible in the response → typo3_rule_lookup with documentId="core/testing/proving-a-rendering" for the throwaway functional test that renders one page, prints what came out, and marks each region so the response says which part changed
- Settling a finding on what a change costs at runtime — a review that asks about performance, a loop or a cache a patch adds or removes — rather than on what it renders → typo3_rule_lookup with documentId="core/testing/timing-a-code-path" for the throwaway functional test that times one call on the patch and on its parent, and what that number leaves out
- Writing a core patch: taking a Forge issue on, fixing a core bug, deprecating or removing core API, or amending a patch after review → typo3_task_guide with the paths you are changing, then typo3_hint_lookup with the same ones, typo3_test_run_guide for the suites that can fail, and typo3_rule_lookup for the Gerrit workflow
- Starting a core task and looking for the applicable conventions and checks → typo3_task_guide
- About to invent a layout, a directory structure or a test harness — the core has probably worked one out already → typo3_reference_list
- About to write backend markup or invent a CSS class name, the module chrome and other layout classes included. The index is a curated subset of what the core itself files as a component, so a miss means uncurated rather than outside the subject. → typo3_component_lookup
- About to run tests or any other core check → typo3_test_run_guide
- Getting Build/Scripts/runTests.sh to run in the checkout in front of you — a suite that fails before it reads a file, a fresh clone or a git worktree, or the pre-commit hook's message → typo3_script_lookup with the task in your own words. Which suite a change needs, and what one does when it runs, is typo3_test_run_guide.
- Working in a concrete file and unsure about the subsystem's conventions → typo3_hint_lookup
- Debugging, where there is no subject yet — something renders, saves or builds wrong and which subsystem does it is the question → typo3_hint_lookup with task written as the symptom, in the words the failure showed in
- Needing the official API, reference or tutorial documentation for a covered TYPO3 version → typo3_documentation_lookup with several short English queries and targetVersion, then with page and the same targetVersion to read a selected result
- Writing a documentation link, replacing a docs.typo3.org URL with a permalink, or checking that the permalinks a patch touches still resolve — a guessed identifier is a 404 nothing in a checkout reports → typo3_permalink_lookup with identifiers for the ones to validate and urls for the ones to replace, as many at a time as the change holds
- Writing or amending the commit message → typo3_commit_message_guide, whose default is a repository of your own
- Pushing for review, amending a patch set — your own or another author's — or backporting → typo3_rule_lookup with a Gerrit query
- A catalog lookup found nothing that should exist → typo3_snapshot_scope, then typo3_feedback_record
- Needing the translation domain an XLF file resolves to → typo3_translation_domain_lookup with the path
- About to write user-facing text or invent a label key → typo3_label_lookup with words from the wording and the XLF resource used at the consuming code
- About to reference an icon identifier in the backend — TCA, a module, a content element wizard, a backend template. The registry is the backend's; frontend rendering has no access to it. → typo3_icon_lookup
- Needing a configuration value as it really is at runtime, not as the core ships it → typo3_configuration_lookup with the TYPO3_CONF_VARS path as configurationPath
- Working on a backend module and needing its registration, its sub-routes, or whether the page tree navigates it → typo3_backend_module_lookup
- Unsure which Fluid namespace prefixes a template may use undeclared → typo3_fluid_namespace_list
- Needing which arguments a Fluid ViewHelper registers, with the type, the default and whether it takes arbitrary ones beyond them → typo3_documentation_lookup with the tag name such as f:asset.css and the targetVersion
- About to recommend a command, or asking what this project consists of → typo3_project_describe
- Starting work on a TYPO3 major you have not built on recently, or planning an upgrade to one this installation does not have — before asking what a version changed → typo3_changelog_lookup
- Asking whether a pattern still works in a version — what nothing changed has no changelog entry, so the changelog's silence is not an answer → typo3_documentation_lookup with targetVersion and short English queries for the reference that documents the pattern, then with page to read it
- Writing against a core API in a package that declares a TYPO3 major the installation does not have — the installed copy answers for one of the declared majors, and the code has to run on all of them → typo3_project_describe for what the package requires of typo3/cms-core, then typo3_rule_lookup with documentId="extension/compatibility/a-declared-major-that-is-not-installed" for the reading that settles the other major
- Sweeping deprecations in a package that declares more than one TYPO3 major — every entry the sweep returns raises whether the replacement is on the lower one → typo3_changelog_lookup with the deprecation's own issue number as the query, which returns the sibling entries the replacement was announced in and the version each was released in
- About to claim that a change holds on a declared TYPO3 major the installation does not have — reading settles the shape and the claim is worth what it ran on → typo3_rule_lookup with documentId="extension/compatibility/running-on-a-declared-major-that-is-not-installed" for standing that major up beside the installation and running the package's own suite there
- Upgrading or maintaining an installation, and needing the order of operations → typo3_task_guide, then typo3_project_describe and typo3_changelog_lookup for what this one is and what the target version changed
- Auditing or preparing a release of an extension — before saying that a version is unreleased, because ext_emconf.php names the released version afterwards as much as before and the checkout reads the same either way → typo3_ter_lookup with the extension key, and with version for the number ext_emconf.php names, then typo3_hint_lookup with id="extension-ter-release" for what publishing requires of the extension itself
- Working in one extension and needing what it registers → typo3_extension_describe with its key
- About to claim that an extension is (or is not) part of the core, or to require one → typo3_system_extension_lookup
- About to write or review an ext_tables.sql, and needing to know which columns TYPO3 creates by itself → typo3_schema_lookup with the table
- Writing or reading a FlexForm — a plugin's settings, a content element's own sheet, or the values a Fluid template reads out of one. The file the registration names is not what the backend resolves. → typo3_flexform_lookup with the table, the flex column and the record values that decide which structure applies, CType for a content element
- Asking which class stands behind an interface here, whether a service is public, what a constructor is handed, or what registers into an extension point → typo3_service_lookup with a substring of the id or the class, or with one exact tag
- Asking whether the database matches what the extensions and the TCA declare → typo3_schema_lookup with the table
- Asking what is actually stored in one of this project's own tables, or how much of it there is → typo3_record_lookup with the table, columns for the fields the question needs, groupBy for what one column holds, count where only the numbers are wanted, where to narrow it

Found the TYPO3 installation at <installation> (core-checkout, found by walking up, from <installation>), which holds 36 packages. If that is not the installation you are working on, this server was started in the wrong directory — or set TYPO3_DEV_COMPANION_ROOT to the one you mean.
Its console cannot be run right now, so questions that only the installation can answer — which labels exist, which backend modules are registered — have no answer here: <installation> has no TYPO3 console — none of bin/typo3, vendor/bin/typo3 exists. Its dependencies are not installed — vendor/autoload.php is not there either, and composer install writes both. Where the command that would work is known, TYPO3_DEV_COMPANION_CONSOLE states it, for example "ddev exec .build/bin/typo3".

Every lookup and guide is read-only. typo3_documentation_lookup reads the official, versioned manuals at docs.typo3.org; apart from that and the installation named above, nothing is fetched, executed, or looked up online.
The one exception is typo3_feedback_record, this server's only write: it creates a new markdown feedback under feedback/ and touches nothing else. Missing something that belongs here? Leave feedback about it.

Where the answers come from, which is what says whether a question can be asked at all right now. Every tool states the same thing at the foot of its own description.
## Answers from installation
The installation this server started in, booted or asked through its console. Its assembled state after every extension has had its say, and nothing at all where it is out of reach.
Tools: typo3_server_scope, typo3_label_lookup, typo3_fluid_namespace_list, typo3_configuration_lookup, typo3_schema_lookup, typo3_record_lookup, typo3_service_lookup, typo3_flexform_lookup, typo3_backend_module_lookup, typo3_icon_lookup, typo3_extension_describe
## Answers from packages
The files the installed packages ship, read rather than executed. Answers on a fresh clone and with the containers down. What a package registers at runtime is not in it.
Tools: typo3_forge_lookup, typo3_component_lookup, typo3_label_lookup, typo3_fluid_namespace_list, typo3_icon_lookup, typo3_changelog_lookup, typo3_project_describe, typo3_extension_describe, typo3_snapshot_scope
## Answers from knowledge
The knowledge base inside this package. Needs nothing up, and binds to TYPO3 versions rather than to an installation.
Tools: typo3_server_scope, typo3_rule_lookup, typo3_script_lookup, typo3_task_guide, typo3_test_run_guide, typo3_hint_lookup, typo3_component_lookup, typo3_system_extension_lookup, typo3_reference_list, typo3_translation_domain_lookup, typo3_snapshot_scope, typo3_commit_message_guide
## Answers from network
A service outside this machine. An unreachable one says so out loud rather than answers as empty.
Tools: typo3_documentation_lookup, typo3_permalink_lookup, typo3_forge_lookup, typo3_gerrit_lookup, typo3_changelog_lookup, typo3_ter_lookup
## Answers from checkout
This server's own checkout, which is why the tool offering it exists only in a standalone one.
Tools: typo3_feedback_record, typo3_feedback_list
```

Data:

```json
{
    "purpose": "A development companion for coding agents working with TYPO3, for the three audiences that do: the core contributor, the extension author, and the site developer. It establishes the project and installation the agent is working in, supplies current, version-bound TYPO3 knowledge, and hands task-specific workflows to the skills that own them so the agent can implement, review, and verify the work. Scope answers describe what is present without treating it as correct; the knowledge and skills supply the conventions that apply, so code found in one installation is not repeated as a pattern merely because it runs. They cover how TYPO3's subsystems are used, the core's own contribution process — the rules, the Gerrit workflow, the scripts and test suites — and a searchable index of backend UI components whose contract is read from the active installation where possible. The server also answers what is registered in the installation it was started in, which no bundled snapshot could get right. Where that installation does not boot, or does not exist yet, the bundled knowledge and the installed packages answer instead, and the answer says which of them it came from and what that leaves out. Every answer says which TYPO3 versions it holds for and which of the three kinds of work it belongs to.",
    "instructions": "Start every task with typo3_project_describe. It answers the installation's TYPO3 version, the extensions that are the project's own, the sites it configures, and the commands the repository declares. A check you recommend that the repository does not declare is a wrong answer however sensible it sounds. Then call typo3_task_guide for the workflow the task belongs to. Call it again at the first test, check, commit or shipped file the task did not name. Not every task ends in a patch. It also answers a triage of the backlog, whether a report still reproduces, and what a fix costs. What changed, which branch you are on, and whether a path still exists are yours to read in the checkout.\n\nWhat to call for what:\n- backend markup or a CSS class: typo3_component_lookup with the targetVersion\n- a backend icon identifier: typo3_icon_lookup\n- a label, added or reworded: typo3_label_lookup with the XLF resource the code at hand uses; a match elsewhere is not reusable\n- what a version broke, deprecated or added, on a major you have not built on lately: typo3_changelog_lookup\n- the commit message, yours as much as the core's, and its branches: typo3_commit_message_guide\n- the whole procedure, not one fact out of it: typo3_rule_lookup with a documentId typo3_project_describe lists\n\nActivate the typo3-* skill in your listing that covers the task: it makes these calls.\n\ntargetVersion or the version the server read filters the answers, and a statement that does not hold on every covered line carries its range.\n\nQuery this server in English whatever language you speak with the user. Its match is lexical, so a query in another language reaches only the loanwords. Translate the subject before you call, and the answer back.\n\ntypo3_server_scope says what it covers, by which tool, and which installation it reads.",
    "covers": [
        {
            "topic": "Contribution rules and review readiness",
            "depth": "Curated prose. The rules a patch is judged by, not a full style guide.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_task_guide"
            ],
            "source": "typo3://guides/core/contribution/rules",
            "scope": "core"
        },
        {
            "topic": "Gerrit workflow: setup, pushing, amending, opening a patch set on somebody else's change, backports",
            "depth": "Curated prose, command level. Covers the local git side; it cannot talk to the Gerrit server.",
            "tools": [
                "typo3_rule_lookup"
            ],
            "source": "typo3://guides/core/contribution/gerrit-workflow",
            "scope": "core"
        },
        {
            "topic": "The JavaScript and CSS the core commits beside the sources they are built from",
            "depth": "Curated prose, command level. Which source tree produces which committed file, how a minified one is diffed at all, and rebuilding one in a worktree branched off the target branch so the checkout you work in stays as it is. It carries the question that needs the generated files deleted first, and what resolves a backport that conflicted in one. Which suite builds a given branch is typo3_test_run_guide's answer rather than this page's.",
            "tools": [
                "typo3_rule_lookup"
            ],
            "source": "typo3://guides/core/contribution/committed-build-output",
            "scope": "core"
        },
        {
            "topic": "What a patch loses when the code moved under it, which no conflict reports",
            "depth": "Four steps against a checkout: the commits main landed on the change's paths since its base, whether a fix carried into a file the change rewrites survives in the replacement, the public and protected members it removes that still have callers, and the suites covering the rewritten paths rather than only the changed ones. Plus the one git call that says whether a rebase left the committed JavaScript stale. Where to stop resolving a conflict is typo3-core-patch-checkout's.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_test_run_guide"
            ],
            "source": "typo3://guides/core/contribution/rebasing-a-stale-patch",
            "scope": "core"
        },
        {
            "topic": "Forge issues: what one says and what was decided about it, which other issues describe the same thing, and what stands open in the core's backlog",
            "depth": "The tracker's own API, read live. By number: the report, the comments that decided it, its related and cited issues, files and review changes. By words: the issues whose text matches, unranked; a differently worded issue is invisible. As a backlog: the core's issues by age, neglect or recency, narrowed by tracker, area, date and person, or broken down per status, tracker, area and year. Each says whether the installed packages still ship the code the report cites — where a symbol stands, not whether the defect reproduces.",
            "tools": [
                "typo3_forge_lookup"
            ],
            "source": "https://forge.typo3.org (network)",
            "scope": "core"
        },
        {
            "topic": "Gerrit changes: whether a patch already exists, what state its review is in, which changes touch a path or name a wording, and what stands open in the core's review backlog",
            "depth": "The anonymous Gerrit REST API, read live. By change number, Change-Id or commit hash: the change and its Change-Id siblings, current patch set, message, paths, votes, comments, chain, the issues and branches its trailers name, and on request the review log. By words and path: every matching change, in any state or only under review; words match the commit message, not the diff. As a backlog: the open changes by age or neglect, narrowed by size, vote state, mergeability, branch, date and person. A private change is invisible to it.",
            "tools": [
                "typo3_gerrit_lookup"
            ],
            "source": "https://review.typo3.org (network)",
            "scope": "core"
        },
        {
            "topic": "Commit messages",
            "depth": "Rules plus a working draft and check, including 72-character body wrapping. The subject and body conventions are also served without the core workflow, for a commit in a repository that has no Forge issue and no release branches: workflow=\"project\", where no trailer is demanded and the issues the call passed are written as Resolves: and Related: all the same. The same guide is exposed as the user-invoked prompt commit_message.",
            "tools": [
                "typo3_commit_message_guide",
                "typo3_rule_lookup"
            ],
            "source": "typo3://guides/core/contribution/commit-messages",
            "scope": "core"
        },
        {
            "topic": "How the comments and docblocks a patch carries have to read",
            "depth": "Ten rules with the rejected sentence and its replacement beside each: say what is, name who acts, one thought per sentence, end on the object, name the place instead of pointing at it, use the words the codebase uses, a longer correct sentence over a short broken one, one fact in one place, say why, and length as a ceiling. Whether a comment is owed at all is the codebase's own rule and this page does not restate it.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_task_guide"
            ],
            "source": "typo3://guides/any/writing/the-prose-a-patch-carries",
            "scope": "any"
        },
        {
            "topic": "The changelog entry a core patch owes: which type, which directory a backport goes into, and what checks the file",
            "depth": "Curated prose, with the skeleton in the documentation-changelog hint. Which of the four types a change owes and which release directory the file belongs in, keyed on the branches the patch reaches rather than on the branch it is written on. The core ships the file's template and a command that writes it from there, and both are named. Whether the type chosen is the right one is what no check reports.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/core/contribution/changelog",
            "scope": "core"
        },
        {
            "topic": "What a new core issue carries: the fields of a Bug, where the area comes from, who sets the target version, and the markup the description renders as",
            "depth": "Curated prose for the authoring direction, with the areas left to the tracker that administers them. Which trackers the core project offers, the field set of a Bug and the one field it does not go without, and the order a report is written in. The description renders Textile: the syntax is named, and so are the three things Markdown habits get silently rewritten into. Filing the issue stays the caller's — it needs an account and this server holds none.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_forge_lookup"
            ],
            "source": "typo3://guides/core/contribution/reporting-an-issue",
            "scope": "core"
        },
        {
            "topic": "Core testing suites: runTests.sh options and targeted invocation",
            "depth": "Every suite this knowledge base knows, with the command, the targeted form, and when to use it. The script is part of the core repository, so paths that read as a project or third-party extension get the boundary stated instead of a command.",
            "tools": [
                "typo3_test_run_guide",
                "typo3_script_lookup"
            ],
            "source": "knowledge/test-suite-hints.json, typo3://guides/core/testing/scripts",
            "scope": "core"
        },
        {
            "topic": "Proving what a rendering contains, where a finding turns on it and no test in the checkout produces it",
            "depth": "The throwaway functional test that renders one page and prints what came out: the cObj that puts a snippet through parseFunc, the operator forms a value has to be written in, how output is got out of a test that would otherwise print nothing, one marker per region so the response says which part of it changed, printing what a service holds from inside the request, the targeted invocation, and where the RTE setup comes from per version. It says nothing about what parseFunc does to a snippet, which is what the probe is for.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/core/testing/proving-a-rendering",
            "scope": "core"
        },
        {
            "topic": "Exercising the system resource publisher from a functional test",
            "depth": "Which of the three file system publishers a test instance actually runs and why the application context does not decide it, why publishing is a no-op for any package whose path lies under the public path, and which of three states at the publishing target raises a real failure rather than a silent success. From TYPO3 14, where the SystemResource namespace arrived. What a package registers as a public resource is a hint rather than this page.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/core/testing/exercising-asset-publishing",
            "scope": "core"
        },
        {
            "topic": "Timing a code path between a patch and its parent, where a review asks what a change costs at runtime",
            "depth": "The throwaway functional test that calls one path many times and prints what a call cost: the warm-up call outside the loop, hrtime() and the per-call division, the same probe run on the patch and on its parent so the finding is a ratio, and the three things the number leaves out — the SQLite default, the per-process runtime cache, and one process without load. It says nothing about what the path does, which the probe is for.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/core/testing/timing-a-code-path",
            "scope": "core"
        },
        {
            "topic": "The PHPUnit configuration an extension runs its own tests with",
            "depth": "The two files a package writes into Build/, whole and ready to write out, one variant per PHPUnit the paired typo3/testing-framework release admits. Beside them: which two attributes a copy has to correct and why the bootstrap is referenced rather than copied, the environment a functional run reads its connection from, and what a finished suite leaves behind. It does not set the harness up for you and it names no dependency constraint — which release resolves is the solver's answer, not this document's.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/extension/testing/phpunit",
            "scope": "extension"
        },
        {
            "topic": "What an extension's Documentation/ directory consists of",
            "depth": "The two files that make a directory a manual and the conventional ones beside them: a minimal guides.xml to copy, the Index.rst header and toctree that pull the chapters in, and the two files that look like a template and are not — a core system extension's renderer configuration and the Settings.cfg of a manual that predates it. Beside them the render command, what its \"successfully placed\" does not promise, and the flag that makes a failed directive a non-zero exit. It does not write the chapters, and what a manual is for is the extension-documentation hint.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/extension/documentation/manual",
            "scope": "extension"
        },
        {
            "topic": "Whether an API is there on a TYPO3 major the package declares and the installation does not have",
            "depth": "The reading that settles it: which declaration says who the question is about, what the changelog settles and where it stops, the invocations that read one symbol off the branch carrying the other major, and the path the installed copy spells differently. Beside them what a compatibility argument owes where nothing can be run. It reads no core source itself and states no signature: a bundled one is wrong at the next release, and a wrong one is believed as readily as a right one.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/extension/compatibility/a-declared-major-that-is-not-installed",
            "scope": "extension"
        },
        {
            "topic": "What the backend styleguide states about a component, and what it leaves unstated",
            "depth": "Where the styleguide lives on each major and how it is installed where the core does not ship it, what its listing settles — a component it lists is public and one it does not is not to be used — and the two ways a demo is misread: an example is complete, so nothing in it says which parts are required, and a demo renders through ViewHelpers and web components, so the classes in its template are neither all of what a component uses nor only that. It names what places a class instead.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_component_lookup"
            ],
            "source": "typo3://guides/any/backend/using-the-styleguide",
            "scope": "any"
        },
        {
            "topic": "Which route a package's own CSS or JavaScript takes into a page, and what proves it still carries",
            "depth": "Every route and the check that belongs to it: the backend import map, which is a file and compares statically; a backend module's PageRenderer calls; TypoScript includeCSS, which no file settles because the resolved setup for one site decides it; the AssetCollector behind f:asset.css, where a call outside the rendered section registers nothing and produces no 404 either; and the later arrivals f:asset.module and f:asset.styleAttr. It closes on what to do after a rebuild renamed, moved or dropped an output.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/any/assets/how-an-asset-reaches-a-page",
            "scope": "any"
        },
        {
            "topic": "Running a package's own suite against a TYPO3 major it declares and the installation does not have",
            "depth": "The procedure, as it was carried out: what the repository's CI already covers and what pushing proves, the Composer root of its own the other major is resolved into and the manifest that root carries, what the working installation keeps, what the second root resolves differently from it, whether the database survives, which checks are worth re-running there, and what a resolved tree is not. It installs nothing itself, and it says what a claim about what renders on the other major would additionally cost.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/extension/compatibility/running-on-a-declared-major-that-is-not-installed",
            "scope": "extension"
        },
        {
            "topic": "The Playwright suite a project runs its browser tests from",
            "depth": "The configuration, the backend login and one spec, whole and ready to write out, with the login in the variant each TYPO3 major needs. Beside them: where the base URL and the credentials come from, why the login runs once, and which locator on the login form is ambiguous. It does not install anything and names no dependency version.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/project/testing/playwright",
            "scope": "project"
        },
        {
            "topic": "Booting a cloned project repository into a running installation",
            "depth": "The run in order, from a clone to a site that answers on both sides: what the clone does not carry, why the environment is started twice, where the data comes from when the repository declares no import, what makes the installation agree with the code in front of it, and what a login costs. It runs nothing and starts nothing. Creating an installation for a package that declares no procedure is the neighbouring task and begins a step earlier.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/project/installation/booting-a-clone",
            "scope": "project"
        },
        {
            "topic": "Renaming an extension key, its tables or its CTypes in an installation that holds records",
            "depth": "What the rename touches on the data side and in which order: that extension:setup creates the new tables and drops nothing, why INSERT ... SELECT * between two tables of one TCA is positional, every column that stores a name as a value — CType, backend_layout, sys_file_reference, sys_refindex, the extensionDataImport registry key — and the command that composes an identifier rather than spelling it. It runs nothing, and the proof it names is a query rather than a suite.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/project/refactoring/renaming-an-installed-extension",
            "scope": "project"
        },
        {
            "topic": "Looking at a change in a real browser, against the installation that has the content",
            "depth": "Which installation can show the case at all, how a browser running in a container reaches a DDEV site — the router's network and its hostname aliases, the certificate it does not carry, the wildcard hostname it cannot answer — and where a harness and its screenshots go so neither reaches a commit. It runs nothing and starts no installation.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/any/testing/browser-check",
            "scope": "any"
        },
        {
            "topic": "Drawing the icon a content element is picked by, and the set it belongs to",
            "depth": "The 16-pixel box every icon in the core's own content set shares, what that set actually varies to tell one element from another — silhouette and palette rather than lines inside one frame, measured over its 115 files — and the check that says a set works, which is naming each icon at rendered size without its label. Whether an identifier resolves is typo3_icon_lookup's and is a different question.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_icon_lookup"
            ],
            "source": "typo3://guides/any/icons/drawing-a-content-icon",
            "scope": "any"
        },
        {
            "topic": "Proving that a TypoScript condition matched against a running installation",
            "depth": "How a verdict nothing prints is established from the page: what the backend's condition list is and is not, how a marker is derived from what the guarded branch alone renders, the shared Fluid wrapper that is no marker, a marker put into the condition on purpose, the negative control, and which cache stands between two runs. It requests nothing and flushes nothing.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_hint_lookup"
            ],
            "source": "typo3://guides/any/testing/proving-a-condition",
            "scope": "any"
        },
        {
            "topic": "Proving that a change to how a site renders changed only what it meant to",
            "depth": "How the pages to capture are chosen from the content that exists rather than from what the templates allow, why the baseline is captured twice before anything is edited, which cache group leaves the compiled Fluid behind so the second capture is the old template, and how the union of the diffs is read for the line nothing explains. It requests nothing and flushes nothing.",
            "tools": [
                "typo3_rule_lookup",
                "typo3_record_lookup"
            ],
            "source": "typo3://guides/any/testing/proving-a-rendering-held",
            "scope": "any"
        },
        {
            "topic": "Reporting a security defect in TYPO3: who receives it, what the report carries, and what is not done with it in the meantime",
            "depth": "TYPO3's own published policy, as the core repository's SECURITY.md and the security team's pages state it. It holds for a defect in the core and for one in an extension alike. It carries no judgement of how bad a finding is: rating one is the team's work, and this says where it goes.",
            "tools": [
                "typo3_rule_lookup"
            ],
            "source": "typo3://guides/any/security/reporting-a-vulnerability",
            "scope": "any"
        },
        {
            "topic": "Where the upstream contribution documentation is",
            "depth": "The official contribution workflow guide is not bundled: this names its entry points, so a question past what the local documents answer is sent to the source rather than guessed at. The local policy that sits beside it is this repository's own.",
            "tools": [
                "typo3_rule_lookup"
            ],
            "source": "typo3://guides/core/contribution/sources",
            "scope": "core"
        },
        {
            "topic": "Core conventions: DI, events and hooks, TCA and FormEngine, FormEngine data providers, DataHandler, routing, Fluid templates and ViewHelpers, frontend page rendering with PAGEVIEW, how a sitepackage is laid out, records in the frontend and the routing for them, registering a content element, Extbase plugins, TypoScript site sets and TSconfig, language files, upgrade wizards, frontend DataProcessors, upgrading an installation, testing strategy, assembling a test suite for a project extension, setting up static analysis and the coding standards fixer for an extension, browser and accessibility tests with Playwright",
            "depth": "Conventions per subsystem, matched by path or topic, from both angles: what a change to the subsystem has to satisfy, and how the mechanism is used. It describes how the core is built, never what your checkout contains.",
            "tools": [
                "typo3_hint_lookup",
                "typo3_task_guide"
            ],
            "source": "knowledge/hints/",
            "scope": "any"
        },
        {
            "topic": "Task workflows for extension, sitepackage and project work: backend modules, content elements, the state of a whole package from the audit through to committed changes, judging one incoming change proposed against it, the content a distribution ships, the asset build that produces its CSS and JavaScript, documentation, tests and static analysis, bringing the local development installation into existence and running the one that already answers, and repairing what a TYPO3 major removed in a package or carrying it to another version",
            "depth": "The skills this server publishes, one resource per workflow: the order the steps are taken in, with the lookup that owns each fact named at the step that needs it. A skill is followed while the work is done rather than read, and what it states about TYPO3 itself is a lookup instead of a sentence, so a published copy cannot go stale. bin/typo3-dev-companion install writes the same files into the client's own skills directory; the resource is the route for a client that never ran it. What a workflow hands over at a step — the order every task starts in, a checklist, an implementation guide — is served under the same URI as that workflow and is read when it sends you there.",
            "tools": [
                "typo3_task_guide"
            ],
            "source": "typo3://skill/typo3-backend-module-development/SKILL.md, typo3://skill/typo3-content-element-development/SKILL.md, typo3://skill/typo3-development-installation/SKILL.md, typo3://skill/typo3-distribution-content/SKILL.md, typo3://skill/typo3-extension-documentation/SKILL.md, typo3://skill/typo3-extension-health/SKILL.md, typo3://skill/typo3-extension-patch-review/SKILL.md, typo3://skill/typo3-extension-asset-build/SKILL.md, typo3://skill/typo3-extension-testing/SKILL.md, typo3://skill/typo3-extension-upgrade/SKILL.md",
            "scope": "any"
        },
        {
            "topic": "The core's own task workflows: saying what an open issue still claims, getting a patch under review into a checkout, writing a patch and carrying it to review, and reviewing somebody else's patch set",
            "depth": "The same shape as the workflows beside them, with the steps that stop at the core repository: the Forge issue and the backlog it came out of, the ref a patch set is fetched by, the suites of runTests.sh, the changelog entry a change owes, and the Gerrit push. Two of the four end before the act that is somebody else's — a triage writes a verdict and touches the tracker in no way, and a checkout stops where the patch no longer decides its own conflicts rather than resolving past it.",
            "tools": [
                "typo3_task_guide"
            ],
            "source": "typo3://skill/typo3-core-issue-triage/SKILL.md, typo3://skill/typo3-core-patch-checkout/SKILL.md, typo3://skill/typo3-core-patch-development/SKILL.md, typo3://skill/typo3-core-patch-review/SKILL.md",
            "scope": "core"
        },
        {
            "topic": "Official TYPO3 API, reference and tutorial documentation",
            "depth": "Live lookup in the public tables of contents of TYPO3 Explained, TypoScript Explained, the TCA Reference and the Fluid ViewHelper Reference, bound to one covered documentation release. Every result keeps its canonical URL, document, version and section; pass that URL back with the same target version to read the page as text, including headings and code examples. An unreachable service is not an empty search.",
            "tools": [
                "typo3_documentation_lookup"
            ],
            "source": "https://docs.typo3.org",
            "scope": "any"
        },
        {
            "topic": "Whether a documentation permalink resolves, what it lands on, and which identifier replaces an old docs.typo3.org URL",
            "depth": "The Sphinx inventory every manual publishes, read for the names a permalink addresses rather than for the pages. Per identifier: the page and anchor it reaches, what the manual registers the name as, every other spelling reaching the same target, and which of them the manual declares rather than generates. Per URL: the identifiers pointing at it, or, where the page is gone, the names carrying the words of the URL as candidates a reader picks from. Many at a time, because one inventory answers every identifier of its manual. It says which branch answered, since the host serves main for a manual it has no branch for and says nothing about it. The named manuals are a maintained list and a system extension is addressed by its Composer package name; an extension manual outside the core is not answered for, because it is versioned on its own releases rather than on TYPO3's.",
            "tools": [
                "typo3_permalink_lookup"
            ],
            "source": "https://docs.typo3.org (network), knowledge/manuals.json",
            "scope": "any"
        },
        {
            "topic": "Backend CSS architecture, design tokens, class naming",
            "depth": "Curated prose covering the Sass sources, the token contract, and the component structure.",
            "tools": [
                "typo3_hint_lookup",
                "typo3_rule_lookup"
            ],
            "source": "knowledge/hints/backend-css.json",
            "scope": "any"
        },
        {
            "topic": "Backend UI components: markup, variants, custom properties",
            "depth": "A curated searchable subset, not every CSS class in the core. When targetVersion is the active installation, installed backend CSS and JavaScript supply presence, classes and custom properties, and a matching installed styleguide example supplies markup. The bundled version-bound snapshot is the fallback and still supplies names, summaries and keywords.",
            "tools": [
                "typo3_component_lookup"
            ],
            "source": "installed EXT:backend and EXT:styleguide files; knowledge/catalog/component/entries.json as index and fallback — read from the installation being worked in, not from a bundled snapshot.",
            "scope": "any"
        },
        {
            "topic": "Which extensions the TYPO3 core ships, and on which versions",
            "depth": "Every system extension of every covered TYPO3 line, by extension key and Composer package name, with what it is for and the range it is shipped on. Derived from one checkout per covered version, so it answers for an extension that is not installed — which is the case the question is asked in. A miss says the name is not a system extension there, never that it does not exist.",
            "tools": [
                "typo3_system_extension_lookup"
            ],
            "source": "knowledge/catalog/system-extension/entries.json",
            "scope": "any"
        },
        {
            "topic": "Where the core keeps its own worked examples",
            "depth": "An index rather than the examples themselves: one line per directory on what it is a reference for, the Composer package an installation can read it from, and the versions it exists on. It is what a hint is a summary of, so it is the better answer where a hint is thin or where a subject has none yet.",
            "tools": [
                "typo3_reference_list"
            ],
            "source": "knowledge/catalog/reference/entries.json",
            "scope": "any"
        },
        {
            "topic": "Translation domains: how the domain of an XLF file is derived",
            "depth": "Complete and computed, not a snapshot: the core's own path-to-domain rules ported here — the class that holds them is TranslationDomainMapper on one branch and TranslationDomainResolver on the next, so compare against whichever your checkout has, so any XLF path in any extension resolves — including a file that does not exist yet. Where the installation being read is older than translation domains, the full LLL:EXT: reference is the answer instead: the domain form renders nothing there.",
            "tools": [
                "typo3_translation_domain_lookup"
            ],
            "source": "src/Knowledge/Catalog/TranslationDomain.php, knowledge/hints/labels.json",
            "scope": "any"
        },
        {
            "topic": "How current the catalogs are",
            "depth": "Whether component contracts came from the active installation or the bundled fallback, plus the core revision, branch, and verification date behind that fallback.",
            "tools": [
                "typo3_snapshot_scope"
            ],
            "source": "knowledge/catalog/meta.json",
            "scope": "any"
        },
        {
            "topic": "What the installation you are working in supplies: backend component contracts, labels, icons, backend modules, Fluid namespaces, effective configuration, the columns TYPO3 derives for a table beside what its database has, the services its container assembles, and the data structure one of its flex fields resolves to",
            "depth": "Answered by that installation rather than from a snapshot, across the packages it has active — project extensions included. Component presence, classes and custom properties come from the installed backend CSS and JavaScript, with installed styleguide markup where available. Label reuse is restricted to the XLF resource used at the consuming code; an instance-wide match from another resource is discovery, not a reuse candidate. Its console does the answering wherever a command exists, and where none does — the icon registry, and the effective configuration, whose command arrived in TYPO3 14.2 and would leave the two LTS lines holding \"command is not defined\" — or where the command carries less than the registry — the backend modules, whose navigation component is inherited and whose routes it does not export — TYPO3 is booted in a subprocess and its container asked; package files answer where neither can be reached, or where the installation has no configuration yet and boots into a core-only failsafe container. The columns a table gets from its TCA are read the same way and have no file to fall back on: they are what the core would create, so only the core can say them. A type=flex column is resolved through that installation's own FlexFormTools, from a record emulated out of values the caller passes, so what comes back is what the backend form would build rather than what the referenced file says. Every answer identifies its source, so a fallback stays visible. A schema answer carries what the database has for the named table beside what TYPO3 derives, and what TYPO3 itself would change to make the two agree. The container is assembled a second time to be read, so a private service, a decoration and what each constructor is really handed are answered rather than what a Services.yaml says.",
            "tools": [
                "typo3_component_lookup",
                "typo3_label_lookup",
                "typo3_icon_lookup",
                "typo3_backend_module_lookup",
                "typo3_fluid_namespace_list",
                "typo3_configuration_lookup",
                "typo3_schema_lookup",
                "typo3_service_lookup",
                "typo3_flexform_lookup"
            ],
            "source": "the discovered TYPO3 installation — read from the installation being worked in, not from a bundled snapshot.",
            "scope": "any"
        },
        {
            "topic": "What is in a table of one of this project's own extensions",
            "depth": "The rows and the numbers over them: how many there are, which page they sit on, whether they are live, hidden or deleted, and the rows themselves with their uid, the label the table names in its own ctrl, the timestamps and the two flags. Narrowed by exact values for any column, pid among them. It is what says where the records are maintained — one page of the record list is a table nobody has to leave the list for — and what is actually stored, which no schema answer reaches. Every other table is refused, the user tables and the core's among them, and every answer says it was read with the shell user's database access rather than with a backend user's permissions.",
            "tools": [
                "typo3_record_lookup"
            ],
            "source": "the discovered installation, booted, with one grouped count and one row read against its database. What a row carries is fixed here rather than composed by the caller.",
            "scope": "project"
        },
        {
            "topic": "The project around the installation: its extensions, its sites and their sets, its own commands, the environment it declares and what that environment runs by itself, and what one of those extensions registers",
            "depth": "Read from the repository's files — composer.json, package.json, config/sites, .github/workflows, and the .ddev configuration where there is one — so it answers on a fresh clone, before anything is installed or migrated. The declared commands are what a caller may run; a DDEV project also states the PHP its container runs, the hooks that fire at a stage of their own with the command each runs, and the pull recipes its database and files come from. Both interpreters those commands run on are stated and related: the PHP the manifest declares, the installed core requires, the install is bounded at and the environment runs; and for the npm half of the list the Node engines.node admits, an .nvmrc pins, an actions/setup-node step sets up and a DDEV nodejs_version states. A workflow is read for that one field rather than for what it asserts, and a version it leaves to a matrix or another file is handed back unresolved. It describes what is there and does not rate it; the one thing it volunteers is a core deprecation whose predicate is a registration file the extension ships, because nothing a caller would think to search for reaches that. Per extension: the tables its TCA defines and extends, the content elements it adds to tt_content with the Fluid template each renders through and the FlexForm each binds, its backend modules and routes, its icons, its site sets and the files core reads each set for, the form configurations it registers and the definitions they store, its service tags, its middlewares, which of the Fluid root directories it ships and the namespaces it registers globally, the shape of its Classes/ directory, and which of the registration files it ships a deprecation names. Its tables, content elements and icons come from the booted installation where there is one; the rest is read from files, and where the installation could not be booted the answer says what a file-read list leaves out.",
            "tools": [
                "typo3_project_describe",
                "typo3_extension_describe"
            ],
            "source": "the discovered project — read from the installation being worked in, not from a bundled snapshot.",
            "scope": "any"
        },
        {
            "topic": "What a TYPO3 version broke, deprecated, added or noted",
            "depth": "One entry per change, searched by words, type and version. The entries come from the changelog docs.typo3.org renders after every merge, so a version nobody has installed and a change merged today are both in reach. The core package on disk answers what docs.typo3.org does not list, and everything where it does not answer. Each entry says which of the two it came from, because a version that is not released yet is still being written.",
            "tools": [
                "typo3_changelog_lookup"
            ],
            "source": "docs.typo3.org for every covered major, and the discovered installation for what docs.typo3.org does not list or where it does not answer. Not a bundled snapshot either way.",
            "scope": "any"
        },
        {
            "topic": "Which versions of an extension the TYPO3 Extension Repository has published",
            "depth": "The registry's own API, read live by extension key: every published version with its number, its state, the day it was uploaded, the TYPO3 majors it declares and the constraints.depends.typo3 it was released with, highest number first — and, where a version is named, whether the registry already holds that number. It is the question a release audit cannot answer from the repository it is auditing, because ext_emconf.php names the released version afterwards as much as before. It reports what is published and judges no version free to release, and it reads nothing inside the package: a key nothing is published under is an answer rather than a statement that no such extension exists.",
            "tools": [
                "typo3_ter_lookup"
            ],
            "source": "https://extensions.typo3.org (network)",
            "scope": "extension"
        }
    ],
    "doesNotCover": [
        {
            "topic": "Your git state: changed files, branch, working tree, commit message, history",
            "why": "This server reads the directory it was started in — a core checkout as readily as an installed project — but it never runs git. What it reads are the files a package ships and, where a console answers, the container behind them. Nothing here knows what you changed, what you committed, or which branch you are on.",
            "instead": "Ask git yourself. One \"git show --name-only --format=%B HEAD\" carries both things this server's own guides ask for: the changed paths typo3_test_run_guide narrows suites by, and the message typo3_commit_message_guide checks. Pass the paths to typo3_hint_lookup and typo3_task_guide for the conventions and checks that apply to them."
        },
        {
            "topic": "PHP source as code: a method signature, whether a class or member is @internal or public API, an implementation to copy",
            "why": "No core sources ship here, and nothing reads a class for what it declares. Where the files a package ships are read at all it is for what they register — an icon, a namespace, an extension's own metadata — never for a signature or an annotation. Whether a removed method was public API is therefore still a question for the checkout, and it is the one that decides whether a removal is breaking.",
            "instead": "Read the class. TCA is a different question and is answered here: typo3_schema_lookup returns the table as the installation's container assembles it, which is not what any single file says. typo3_changelog_lookup says what a version broke, deprecated or added, and typo3_hint_lookup says what the subsystem is built to."
        },
        {
            "topic": "Which test covers a given file",
            "why": "Test coverage is a property of the checkout, and no index of it is bundled.",
            "instead": "Core tests mirror the class path below typo3/sysext/<ext>/Tests/Unit/ and Tests/Functional/, so typo3/sysext/core/Classes/DataHandling/DataHandler.php is covered by typo3/sysext/core/Tests/Unit/DataHandling/DataHandlerTest.php. Look the file up there, then ask typo3_test_run_guide for the targeted runTests.sh invocation."
        },
        {
            "topic": "Frontend theming: the CSS and the JavaScript a website renders",
            "why": "Everything here about CSS and TypeScript describes the TYPO3 backend interface — its Sass sources, its --typo3-* token contract, its light and dark color schemes, its move away from Bootstrap. For a theme extension those are not a milder version of the right answer, they are the opposite of it. How a theme extension is laid out is a different question and is not excluded here: the core ships its own theme as a system extension, and the conventions it establishes — the template tree, the layout names, the backend layout files — are in the hints.",
            "instead": "typo3_hint_lookup withholds the Backend CSS and Backend TypeScript and JavaScript hints where a task names the frontend, and returns what does transfer — Fluid, TypoScript, PHP, and the sitepackage layout. The styling itself is documented at https://docs.typo3.org."
        },
        {
            "topic": "Whether an uncatalogued component or CSS class exists on your branch",
            "why": "The active installation supplies the contract for curated component entries, but the searchable index is deliberately a subset rather than every class in backend.css. Without an installation, even those entries fall back to one pinned core snapshot.",
            "instead": "The component answer already says which source supplied the contract, which core revision the bundled snapshot was taken from and the command that re-checks it. Inspect the installed backend CSS, or the target checkout, for a class outside the curated index."
        },
        {
            "topic": "Gerrit beyond what an anonymous read answers: the hunks of a patch set, a draft comment nobody published, what CI did beyond the line its bot posted, and anything a private change carries",
            "why": "The review API is read without a credential, so a draft and a private change are outside it. The diff itself is not read over the API — the answer carries the paths the patch set touches and the ref that fetches it, and the checkout is where the hunks are read. Nothing here writes to Gerrit.",
            "instead": "typo3_gerrit_lookup answers what an anonymous read carries: the change, its current patch set and commit, the paths it touches, its votes and comments, and the ref that fetches it — hold that commit against your own HEAD, and fetch the ref for the hunks. Voting, commenting and uploading stay yours: the web UI and git, and typo3://guides/core/contribution/gerrit-workflow carries those."
        },
        {
            "topic": "What someone else's extension does: the API, the options and the documentation of a package the core does not ship",
            "why": "Writing an extension is covered — the extension author is one of the three audiences this exists for, and the registration files, the subsystem conventions, the sitepackage layout and the test suite are all here. What is not here is the inside of somebody else's package: it has its own API, its own release cycle and its own documentation, and none of them is read by this server. The registry's published record for a key is the exception and is answered: which versions are out, what each declares and when it was uploaded, which says nothing about what any of them contains. Whether a name belongs to the core at all is a different question, and typo3_system_extension_lookup answers it.",
            "instead": "Read that extension's own documentation. What an installed extension registers — yours or a third party's — is answered by typo3_extension_describe from the files it ships, and what the TYPO3 Extension Repository has published under its key by typo3_ter_lookup."
        },
        {
            "topic": "Deciding one site's configuration: its languages, its base and the variants per environment, its error handling, and the steps that install it",
            "why": "A site set is a convention and is covered; what one installation writes into config/sites/<identifier>/config.yaml is that site's decision, and nothing here would make one answer to it more right than another. The file is read rather than composed — typo3_project_describe reports the sites a repository configures and the sets they depend on.",
            "instead": "Read what the project already has with typo3_project_describe, ask typo3_hint_lookup with id=site-sets for what a set ships and how its settings resolve against a site's own, and take the configuration format and the language setup from https://docs.typo3.org/."
        },
        {
            "topic": "Running an installation: server and container setup, deployment, backups, the editorial use of the backend",
            "why": "The knowledge base is about what is written into a TYPO3 project — its extensions, its configuration, its templates and its tests. Operating the installation around it is a different subject with different sources. What a project's own environment file declares is the exception, because that file is written into the project.",
            "instead": "Use the TYPO3 documentation at https://docs.typo3.org/. typo3_project_describe reports what the environment file configures. Which interpreter to declare in it is typo3_hint_lookup with id=php-versions, asked before there is an installation to ask anything else."
        },
        {
            "topic": "The content of the installation's own tables: a record of pages, tt_content, a file reference, a workspace, a user",
            "why": "The content model is answered here throughout, and the content itself is read rather than written. typo3_schema_lookup returns any table as the installation's container assembles it; typo3_record_lookup reads the rows of any table this installation has TCA for, and refuses what TCA does not describe. What that reading is worth knowing about is the trust model: your client launches this server as a stdio subprocess, so the process boundary is the whole of its security, and a row comes back with the shell user's database access rather than a backend user's permissions. Every answer says so, and no answer is narrowed by a permission, a workspace or a language.",
            "instead": "Write the records where the permissions apply — the backend, or the installation's own console at vendor/bin/typo3. For what a table holds, its columns and their types, ask typo3_schema_lookup; for the rows themselves, how many there are, which page they sit on and what one column holds across them, typo3_record_lookup; for what may be written into a flex column, typo3_flexform_lookup, which emulates the record from values you pass rather than reading one; and for what the DataHandler expects of code you write, typo3_hint_lookup."
        }
    ],
    "checkoutDiscovery": [
        {
            "establish": "Which files the task actually touches",
            "how": "git status --short and git diff --name-only in the core checkout, then call typo3_hint_lookup with those paths for the conventions that apply to them."
        },
        {
            "establish": "Which tests already cover them",
            "how": "Core tests mirror the class path below typo3/sysext/<ext>/Tests/Unit/ and Tests/Functional/. Find the file there, then ask typo3_test_run_guide for the targeted runTests.sh invocation."
        },
        {
            "establish": "The branch you are on and the branches the change is meant for",
            "how": "git branch --show-current. In the normal case the patch targets main and the merging core team member handles the backport; push to a release branch only when the bug does not exist on main."
        },
        {
            "establish": "Whether the paths, classes, labels, and identifiers named in an answer still exist on that branch",
            "how": "Call typo3_component_lookup for curated backend components: it reads the active installation when the target matches. For uncatalogued code or another target branch, grep the checkout; typo3_snapshot_scope names the fallback revision."
        },
        {
            "establish": "Whether an icon identifier is registered, and which one spells the shape you want",
            "how": "Ask typo3_icon_lookup: it reads the registry of the installation this server was started in, the T3Icons set and every installed package included. Where there is no reachable installation, the same three places can be read by hand — typo3/sysext/core/Resources/Public/Icons/T3Icons/icons.json, the Configuration/Icons.php of each package, and typo3/sysext/core/Resources/Public/Icons/Flags/ for the flags-* family."
        },
        {
            "establish": "Whether a label for this wording already exists",
            "how": "Identify the XLF resource already used at the consuming code, then ask typo3_label_lookup with that resource. It applies the installation's resource overrides, but a match from another module or package is not reusable in this context. Where the console cannot be reached it reads the installed package's XLF file instead and says so; only where there is no installation at all is there nothing to ask."
        }
    ],
    "routing": [
        {
            "when": "Asked to review, audit or assess a project, a site package or an extension — before opening the first file, because what a finding is worth depends on the version and the commands this repository has",
            "call": "typo3_project_describe, then typo3_task_guide for the workflow and typo3_extension_describe for each extension in scope"
        },
        {
            "when": "Going through the core's open issues — the oldest, the ones nobody has touched for years, or what stands open in one area such as the RTE or the backend UI",
            "call": "typo3_forge_lookup with backlog=\"oldest\" or open=\"stale\", narrowed with category in the user's own words and with tracker, then typo3_forge_lookup with the number of the one being taken further"
        },
        {
            "when": "What one person has filed on the tracker, or what they still hold — one contributor's backlog, or what a core team member has open",
            "call": "typo3_forge_lookup with backlog=\"oldest\" and involving in the person's name for both sides at once, or reportedBy or assignedTo for one of them, with status=\"all\" for the years and breakdown=true where the count is larger than a page; never query with the name, which matches the text of an issue rather than whose it is"
        },
        {
            "when": "Writing the title and the description of a core bug report, or filling in the new-issue form on forge.typo3.org — including the issue a patch's Resolves: trailer will point at, which is written before the patch is pushed",
            "call": "typo3_rule_lookup with documentId=\"core/contribution/reporting-an-issue\" for the fields and the Textile the description renders as, then typo3_forge_lookup with category=\"*\" for the areas the Category field takes, and for whether it is already reported typo3_forge_lookup with query in the words of the symptom and again with backlog=\"newest\", createdSince from the day the defect could first have been reported and limit=50 — a wording reaches only the issues worded that way, and reading the subjects of everything filed since is what settles a negative"
        },
        {
            "when": "Taking a Forge issue on, before believing what it describes — an issue can be stale, already fixed, or closed on a decision that is not in its description",
            "call": "typo3_forge_lookup for the issue and its comments, then typo3_forge_lookup again with query in the words the issue uses for the other issues describing the same thing — its relations carry only what somebody linked by hand — then typo3_gerrit_lookup with the same number for whether a patch exists already"
        },
        {
            "when": "Before writing a patch for a file, and when asking whether a fix has been attempted before — neither is answerable from a checkout, since a clone carries what landed and says nothing about what is open",
            "call": "typo3_gerrit_lookup with path for the changes touching it and open for the ones still under review, then again with query in the words a commit message would use"
        },
        {
            "when": "Starting a review session without a change in hand — which open reviews have been sitting a long time, which are small and almost voted through, which are mine and which have I already voted on. A checkout answers none of it and the review server sorts by last activity alone.",
            "call": "typo3_gerrit_lookup with backlog \"oldest\" or \"stale\", narrowed by maxSize, minCodeReview, negativeVotes, mergeable, branch, updatedBefore, owner, reviewedBy, involving or reviewableBy, then again with change on the number picked off the page for its votes, its comment threads and the patch set to fetch"
        },
        {
            "when": "Holding a commit hash and asking which branches carry that fix — closing an issue as fixed, or saying where a backport went. A clone answers it in several git calls per commit, and the Releases: trailer that settles it is what it reaches last.",
            "call": "typo3_gerrit_lookup with commit, which answers the change that hash is a patch set of, the backports sharing its Change-Id with the branch each of them targets, and the branches every commit message's Releases: trailer claims"
        },
        {
            "when": "Reviewing a TYPO3 core patch — the current changes in a core checkout, a commit, or a change fetched from Gerrit — rather than a project or an extension",
            "call": "typo3_gerrit_lookup with the Change-Id or the change number for what the patch is — the paths it touches, the branch it targets, its commit message and the issue it names — then typo3_rule_lookup per obligation the diff raises, typo3_changelog_lookup for the precedent, typo3_test_run_guide with the changed paths, then typo3_commit_message_guide with workflow=\"core\""
        },
        {
            "when": "Settling a finding on what a rendering contains rather than on what a diff says — TypoScript defaults, TypoScript declared in an ext_localconf.php or anything below lib.parseFunc, and equally a PHP change to the frontend request pipeline, an error handler or a page renderer caller whose effect is only visible in the response",
            "call": "typo3_rule_lookup with documentId=\"core/testing/proving-a-rendering\" for the throwaway functional test that renders one page, prints what came out, and marks each region so the response says which part changed"
        },
        {
            "when": "Settling a finding on what a change costs at runtime — a review that asks about performance, a loop or a cache a patch adds or removes — rather than on what it renders",
            "call": "typo3_rule_lookup with documentId=\"core/testing/timing-a-code-path\" for the throwaway functional test that times one call on the patch and on its parent, and what that number leaves out"
        },
        {
            "when": "Writing a core patch: taking a Forge issue on, fixing a core bug, deprecating or removing core API, or amending a patch after review",
            "call": "typo3_task_guide with the paths you are changing, then typo3_hint_lookup with the same ones, typo3_test_run_guide for the suites that can fail, and typo3_rule_lookup for the Gerrit workflow"
        },
        {
            "when": "Starting a core task and looking for the applicable conventions and checks",
            "call": "typo3_task_guide"
        },
        {
            "when": "About to invent a layout, a directory structure or a test harness — the core has probably worked one out already",
            "call": "typo3_reference_list"
        },
        {
            "when": "About to write backend markup or invent a CSS class name, the module chrome and other layout classes included. The index is a curated subset of what the core itself files as a component, so a miss means uncurated rather than outside the subject.",
            "call": "typo3_component_lookup"
        },
        {
            "when": "About to run tests or any other core check",
            "call": "typo3_test_run_guide"
        },
        {
            "when": "Getting Build/Scripts/runTests.sh to run in the checkout in front of you — a suite that fails before it reads a file, a fresh clone or a git worktree, or the pre-commit hook's message",
            "call": "typo3_script_lookup with the task in your own words. Which suite a change needs, and what one does when it runs, is typo3_test_run_guide."
        },
        {
            "when": "Working in a concrete file and unsure about the subsystem's conventions",
            "call": "typo3_hint_lookup"
        },
        {
            "when": "Debugging, where there is no subject yet — something renders, saves or builds wrong and which subsystem does it is the question",
            "call": "typo3_hint_lookup with task written as the symptom, in the words the failure showed in"
        },
        {
            "when": "Needing the official API, reference or tutorial documentation for a covered TYPO3 version",
            "call": "typo3_documentation_lookup with several short English queries and targetVersion, then with page and the same targetVersion to read a selected result"
        },
        {
            "when": "Writing a documentation link, replacing a docs.typo3.org URL with a permalink, or checking that the permalinks a patch touches still resolve — a guessed identifier is a 404 nothing in a checkout reports",
            "call": "typo3_permalink_lookup with identifiers for the ones to validate and urls for the ones to replace, as many at a time as the change holds"
        },
        {
            "when": "Writing or amending the commit message",
            "call": "typo3_commit_message_guide, whose default is a repository of your own"
        },
        {
            "when": "Pushing for review, amending a patch set — your own or another author's — or backporting",
            "call": "typo3_rule_lookup with a Gerrit query"
        },
        {
            "when": "A catalog lookup found nothing that should exist",
            "call": "typo3_snapshot_scope, then typo3_feedback_record"
        },
        {
            "when": "Needing the translation domain an XLF file resolves to",
            "call": "typo3_translation_domain_lookup with the path"
        },
        {
            "when": "About to write user-facing text or invent a label key",
            "call": "typo3_label_lookup with words from the wording and the XLF resource used at the consuming code"
        },
        {
            "when": "About to reference an icon identifier in the backend — TCA, a module, a content element wizard, a backend template. The registry is the backend's; frontend rendering has no access to it.",
            "call": "typo3_icon_lookup"
        },
        {
            "when": "Needing a configuration value as it really is at runtime, not as the core ships it",
            "call": "typo3_configuration_lookup with the TYPO3_CONF_VARS path as configurationPath"
        },
        {
            "when": "Working on a backend module and needing its registration, its sub-routes, or whether the page tree navigates it",
            "call": "typo3_backend_module_lookup"
        },
        {
            "when": "Unsure which Fluid namespace prefixes a template may use undeclared",
            "call": "typo3_fluid_namespace_list"
        },
        {
            "when": "Needing which arguments a Fluid ViewHelper registers, with the type, the default and whether it takes arbitrary ones beyond them",
            "call": "typo3_documentation_lookup with the tag name such as f:asset.css and the targetVersion"
        },
        {
            "when": "About to recommend a command, or asking what this project consists of",
            "call": "typo3_project_describe"
        },
        {
            "when": "Starting work on a TYPO3 major you have not built on recently, or planning an upgrade to one this installation does not have — before asking what a version changed",
            "call": "typo3_changelog_lookup"
        },
        {
            "when": "Asking whether a pattern still works in a version — what nothing changed has no changelog entry, so the changelog's silence is not an answer",
            "call": "typo3_documentation_lookup with targetVersion and short English queries for the reference that documents the pattern, then with page to read it"
        },
        {
            "when": "Writing against a core API in a package that declares a TYPO3 major the installation does not have — the installed copy answers for one of the declared majors, and the code has to run on all of them",
            "call": "typo3_project_describe for what the package requires of typo3/cms-core, then typo3_rule_lookup with documentId=\"extension/compatibility/a-declared-major-that-is-not-installed\" for the reading that settles the other major"
        },
        {
            "when": "Sweeping deprecations in a package that declares more than one TYPO3 major — every entry the sweep returns raises whether the replacement is on the lower one",
            "call": "typo3_changelog_lookup with the deprecation's own issue number as the query, which returns the sibling entries the replacement was announced in and the version each was released in"
        },
        {
            "when": "About to claim that a change holds on a declared TYPO3 major the installation does not have — reading settles the shape and the claim is worth what it ran on",
            "call": "typo3_rule_lookup with documentId=\"extension/compatibility/running-on-a-declared-major-that-is-not-installed\" for standing that major up beside the installation and running the package's own suite there"
        },
        {
            "when": "Upgrading or maintaining an installation, and needing the order of operations",
            "call": "typo3_task_guide, then typo3_project_describe and typo3_changelog_lookup for what this one is and what the target version changed"
        },
        {
            "when": "Auditing or preparing a release of an extension — before saying that a version is unreleased, because ext_emconf.php names the released version afterwards as much as before and the checkout reads the same either way",
            "call": "typo3_ter_lookup with the extension key, and with version for the number ext_emconf.php names, then typo3_hint_lookup with id=\"extension-ter-release\" for what publishing requires of the extension itself"
        },
        {
            "when": "Working in one extension and needing what it registers",
            "call": "typo3_extension_describe with its key"
        },
        {
            "when": "About to claim that an extension is (or is not) part of the core, or to require one",
            "call": "typo3_system_extension_lookup"
        },
        {
            "when": "About to write or review an ext_tables.sql, and needing to know which columns TYPO3 creates by itself",
            "call": "typo3_schema_lookup with the table"
        },
        {
            "when": "Writing or reading a FlexForm — a plugin's settings, a content element's own sheet, or the values a Fluid template reads out of one. The file the registration names is not what the backend resolves.",
            "call": "typo3_flexform_lookup with the table, the flex column and the record values that decide which structure applies, CType for a content element"
        },
        {
            "when": "Asking which class stands behind an interface here, whether a service is public, what a constructor is handed, or what registers into an extension point",
            "call": "typo3_service_lookup with a substring of the id or the class, or with one exact tag"
        },
        {
            "when": "Asking whether the database matches what the extensions and the TCA declare",
            "call": "typo3_schema_lookup with the table"
        },
        {
            "when": "Asking what is actually stored in one of this project's own tables, or how much of it there is",
            "call": "typo3_record_lookup with the table, columns for the fields the question needs, groupBy for what one column holds, count where only the numbers are wanted, where to narrow it"
        }
    ],
    "versions": [
        {
            "major": 12,
            "branch": "12.4",
            "status": "lts"
        },
        {
            "major": 13,
            "branch": "13.4",
            "status": "lts"
        },
        {
            "major": 14,
            "branch": "14.3",
            "status": "stable"
        },
        {
            "major": 15,
            "branch": "main",
            "status": "development"
        }
    ],
    "excludedTools": {
        "names": [],
        "ignored": [],
        "variable": "TYPO3_DEV_COMPANION_EXCLUDE_TOOLS"
    },
    "answersFrom": [
        {
            "source": "installation",
            "meaning": "The installation this server started in, booted or asked through its console. Its assembled state after every extension has had its say, and nothing at all where it is out of reach.",
            "tools": [
                "typo3_server_scope",
                "typo3_label_lookup",
                "typo3_fluid_namespace_list",
                "typo3_configuration_lookup",
                "typo3_schema_lookup",
                "typo3_record_lookup",
                "typo3_service_lookup",
                "typo3_flexform_lookup",
                "typo3_backend_module_lookup",
                "typo3_icon_lookup",
                "typo3_extension_describe"
            ]
        },
        {
            "source": "packages",
            "meaning": "The files the installed packages ship, read rather than executed. Answers on a fresh clone and with the containers down. What a package registers at runtime is not in it.",
            "tools": [
                "typo3_forge_lookup",
                "typo3_component_lookup",
                "typo3_label_lookup",
                "typo3_fluid_namespace_list",
                "typo3_icon_lookup",
                "typo3_changelog_lookup",
                "typo3_project_describe",
                "typo3_extension_describe",
                "typo3_snapshot_scope"
            ]
        },
        {
            "source": "knowledge",
            "meaning": "The knowledge base inside this package. Needs nothing up, and binds to TYPO3 versions rather than to an installation.",
            "tools": [
                "typo3_server_scope",
                "typo3_rule_lookup",
                "typo3_script_lookup",
                "typo3_task_guide",
                "typo3_test_run_guide",
                "typo3_hint_lookup",
                "typo3_component_lookup",
                "typo3_system_extension_lookup",
                "typo3_reference_list",
                "typo3_translation_domain_lookup",
                "typo3_snapshot_scope",
                "typo3_commit_message_guide"
            ]
        },
        {
            "source": "network",
            "meaning": "A service outside this machine. An unreachable one says so out loud rather than answers as empty.",
            "tools": [
                "typo3_documentation_lookup",
                "typo3_permalink_lookup",
                "typo3_forge_lookup",
                "typo3_gerrit_lookup",
                "typo3_changelog_lookup",
                "typo3_ter_lookup"
            ]
        },
        {
            "source": "checkout",
            "meaning": "This server's own checkout, which is why the tool offering it exists only in a standalone one.",
            "tools": [
                "typo3_feedback_record",
                "typo3_feedback_list"
            ]
        }
    ],
    "installation": {
        "found": true,
        "root": "<installation>",
        "kind": "core-checkout",
        "via": "discovery",
        "startedFrom": "<installation>",
        "searched": [
            "<installation>"
        ],
        "packageCount": 36,
        "misconfiguration": null,
        "console": {
            "reachable": false,
            "via": null,
            "php": null,
            "command": null,
            "reason": "<installation> has no TYPO3 console — none of bin/typo3, vendor/bin/typo3 exists. Its dependencies are not installed — vendor/autoload.php is not there either, and composer install writes both",
            "caveat": null
        },
        "settings": {
            "root": "TYPO3_DEV_COMPANION_ROOT",
            "console": "TYPO3_DEV_COMPANION_CONSOLE"
        }
    },
    "withheld": []
}
```

<a id="scope-one-section"></a>

### scope: one section

Called with:

```json
{
    "sections": [
        "installation"
    ]
}
```

Text:

```text
A development companion for coding agents working with TYPO3, for the three audiences that do: the core contributor, the extension author, and the site developer. It establishes the project and installation the agent is working in, supplies current, version-bound TYPO3 knowledge, and hands task-specific workflows to the skills that own them so the agent can implement, review, and verify the work. Scope answers describe what is present without treating it as correct; the knowledge and skills supply the conventions that apply, so code found in one installation is not repeated as a pattern merely because it runs. They cover how TYPO3's subsystems are used, the core's own contribution process — the rules, the Gerrit workflow, the scripts and test suites — and a searchable index of backend UI components whose contract is read from the active installation where possible. The server also answers what is registered in the installation it was started in, which no bundled snapshot could get right. Where that installation does not boot, or does not exist yet, the bundled knowledge and the installed packages answer instead, and the answer says which of them it came from and what that leaves out. Every answer says which TYPO3 versions it holds for and which of the three kinds of work it belongs to.

Query this server in English, whatever language you are speaking with the user. Its knowledge is written in English and its matching is lexical, so a query in another language reaches only the words the two happen to share and otherwise comes back empty.

Found the TYPO3 installation at <installation> (core-checkout, found by walking up, from <installation>), which holds 36 packages. If that is not the installation you are working on, this server was started in the wrong directory — or set TYPO3_DEV_COMPANION_ROOT to the one you mean.
Its console cannot be run right now, so questions that only the installation can answer — which labels exist, which backend modules are registered — have no answer here: <installation> has no TYPO3 console — none of bin/typo3, vendor/bin/typo3 exists. Its dependencies are not installed — vendor/autoload.php is not there either, and composer install writes both. Where the command that would work is known, TYPO3_DEV_COMPANION_CONSOLE states it, for example "ddev exec .build/bin/typo3".

Every lookup and guide is read-only. typo3_documentation_lookup reads the official, versioned manuals at docs.typo3.org; apart from that and the installation named above, nothing is fetched, executed, or looked up online.
The one exception is typo3_feedback_record, this server's only write: it creates a new markdown feedback under feedback/ and touches nothing else. Missing something that belongs here? Leave feedback about it.

Left out, because this call named sections: covers, doesNotCover, checkoutDiscovery, routing, versions, answersFrom. Ask again naming those, or call this tool with no arguments for the whole orientation.
```

Data:

```json
{
    "purpose": "A development companion for coding agents working with TYPO3, for the three audiences that do: the core contributor, the extension author, and the site developer. It establishes the project and installation the agent is working in, supplies current, version-bound TYPO3 knowledge, and hands task-specific workflows to the skills that own them so the agent can implement, review, and verify the work. Scope answers describe what is present without treating it as correct; the knowledge and skills supply the conventions that apply, so code found in one installation is not repeated as a pattern merely because it runs. They cover how TYPO3's subsystems are used, the core's own contribution process — the rules, the Gerrit workflow, the scripts and test suites — and a searchable index of backend UI components whose contract is read from the active installation where possible. The server also answers what is registered in the installation it was started in, which no bundled snapshot could get right. Where that installation does not boot, or does not exist yet, the bundled knowledge and the installed packages answer instead, and the answer says which of them it came from and what that leaves out. Every answer says which TYPO3 versions it holds for and which of the three kinds of work it belongs to.",
    "instructions": "Start every task with typo3_project_describe. It answers the installation's TYPO3 version, the extensions that are the project's own, the sites it configures, and the commands the repository declares. A check you recommend that the repository does not declare is a wrong answer however sensible it sounds. Then call typo3_task_guide for the workflow the task belongs to. Call it again at the first test, check, commit or shipped file the task did not name. Not every task ends in a patch. It also answers a triage of the backlog, whether a report still reproduces, and what a fix costs. What changed, which branch you are on, and whether a path still exists are yours to read in the checkout.\n\nWhat to call for what:\n- backend markup or a CSS class: typo3_component_lookup with the targetVersion\n- a backend icon identifier: typo3_icon_lookup\n- a label, added or reworded: typo3_label_lookup with the XLF resource the code at hand uses; a match elsewhere is not reusable\n- what a version broke, deprecated or added, on a major you have not built on lately: typo3_changelog_lookup\n- the commit message, yours as much as the core's, and its branches: typo3_commit_message_guide\n- the whole procedure, not one fact out of it: typo3_rule_lookup with a documentId typo3_project_describe lists\n\nActivate the typo3-* skill in your listing that covers the task: it makes these calls.\n\ntargetVersion or the version the server read filters the answers, and a statement that does not hold on every covered line carries its range.\n\nQuery this server in English whatever language you speak with the user. Its match is lexical, so a query in another language reaches only the loanwords. Translate the subject before you call, and the answer back.\n\ntypo3_server_scope says what it covers, by which tool, and which installation it reads.",
    "excludedTools": {
        "names": [],
        "ignored": [],
        "variable": "TYPO3_DEV_COMPANION_EXCLUDE_TOOLS"
    },
    "installation": {
        "found": true,
        "root": "<installation>",
        "kind": "core-checkout",
        "via": "discovery",
        "startedFrom": "<installation>",
        "searched": [
            "<installation>"
        ],
        "packageCount": 36,
        "misconfiguration": null,
        "console": {
            "reachable": false,
            "via": null,
            "php": null,
            "command": null,
            "reason": "<installation> has no TYPO3 console — none of bin/typo3, vendor/bin/typo3 exists. Its dependencies are not installed — vendor/autoload.php is not there either, and composer install writes both",
            "caveat": null
        },
        "settings": {
            "root": "TYPO3_DEV_COMPANION_ROOT",
            "console": "TYPO3_DEV_COMPANION_CONSOLE"
        }
    },
    "withheld": [
        {
            "section": "covers",
            "holds": "what is covered, at which depth, and by which tool"
        },
        {
            "section": "doesNotCover",
            "holds": "what this server deliberately does not answer, and what to do instead"
        },
        {
            "section": "checkoutDiscovery",
            "holds": "what to establish in the checkout before the work, and how"
        },
        {
            "section": "routing",
            "holds": "which tool to call when"
        },
        {
            "section": "versions",
            "holds": "the TYPO3 versions this knowledge binds to"
        },
        {
            "section": "answersFrom",
            "holds": "which source answers which tool, in the state this machine is in"
        }
    ]
}
```