An extension that serves something apart from the application, as the dev console does, declares its own listener from its onStart, between priority 100 and 10000, then mounts on it by name like on any other:

ListenerOptions.DEFAULTS starts the listener like one of the configuration. ChappeListener.httpUrl(address) turns the address onBound receives into the URL the log line shows.

A listener name has one owner. The extensions' listeners start first, then those of vidocq.chappe.listeners, which must not list a name an extension declared: the boot fails with listener 'dev' is declared by an extension (DevConsoleExtension); remove it from vidocq.chappe.listeners. The listener named default is always the application’s.

Other extensions follow comparable scheduling logic with their own priorities.

The dev console shows the section as the rest panel, with the boot facts above, and one card per mount below it, sampled about once a second from the counters each Cassini stack keeps (Reading live request figures):

A request is timed from the moment Chappe hands it to Cassini to the moment Cassini has written its response: filters, the resource method, exception mappers and serialisation, not the network. A request no resource matches counts as the 404 it gets. The figures are totals for the whole mount: there is no breakdown per route.

Sampling sums a few counters and creates nothing. The counters are on in every stack Vidocq builds; they cost about 25 ns per request and allocate nothing, as Cassini’s BENCH.md measures. A stack built without them shows requests absent, counters off, never a zero.

The summary line counts the metrics of each registry, gauges included: 3 application metrics, 13 base, 0 vendor. The base registry holds the gauges Dirac reads from the JVM. The detailed report then writes:

A metric name is not a valid key of the console, so the panel derives one, always the same for the same registry: the name, then each tag in the order of the tag names as .name-value; lowercased, every character other than a letter, a digit, a dot or a hyphen replaced with a hyphen, and m- in front when it does not start with a letter; cut to 40 characters, less 5 for a timer, whose mean needs .mean; and when two metrics end up with the same key, the second gets -2, the third -3. com.acme.Shop.placeOrder with the tag shop=EU is com.acme.shop.placeorder.shop-eu.

One card per registry, application first, then base and vendor, sampled about once a second:

What is never shown:

The section and the panel read the registries of the MetricRegistryProducerBean instance the application already has: the bean is resolved once when the extension starts, and each sample asks its context for the existing instance, which never creates one. Before anything asked Dirac for a registry or a metric, the section’s summary is registries not created yet and the panel shows a single registries value, absent, not created yet. A container with no Dirac producer, or with a second copy of Dirac loaded by the application layer, which the extension cannot read, shows no Dirac registry in this container.

The summary line counts the checks of each probe: 3 checks: 1 liveness, 2 readiness, 0 startup. Then:

One card per probe that has at least one check, liveness, then readiness and startup, sampled about once a second. A check with two probe qualifiers is in both cards: Knock runs it, and records its answer, for each.

The key of a check is derived from its name, always the same for the same checks: its words hyphenated and lowercased, AppLivenessCheck is app-liveness-check; every character other than a letter, a digit, a dot or a hyphen replaced with a hyphen, and c- in front when it does not start with a letter; cut to 37 characters, to leave room for .at; and when two checks end up with the same key, the second gets -2, the third -3.

What is never shown:

The section and the panel read Knock’s HealthCheckRegistry bean, resolved once when the extension starts: each sample asks its context for the existing instance, which never creates one. Knock creates the registry when it registers the first check; a container whose registry was never created has no check, and the section’s summary is no health check (registry not created yet), the panel a single checks value, absent, registry not created yet. A container without Knock shows no Knock registry in this container.

The summary names the pools and their total size: 2 pools (@Default, audit), 12 connections max, or idle: no vidocq.pool[.<name>].url when no pool is configured. The detailed report, which the console always has, adds for each pool:

A URL loses its user info (//user:password@, Oracle’s user/password@) and every parameter or setting whose key holds password, passwd, pwd, secret, token or credential: jdbc:postgresql://audit:s3cret@db.example:5432/audit?sslpassword=k3y&ssl=true shows as jdbc:postgresql://db.example:5432/audit?ssl=true. The user info runs to the last @ before the first ? or ;, whatever the password holds, a /, a //, a `, an `=` or an `@`: `jdbc:oracle:thin:scott/Xy7//Qp4==@db:1521:orcl shows as jdbc:oracle:thin:@db:1521:orcl. A URL that cannot be read shows as jdbc:<sub-protocol>:…, and so does one whose password holds a ? or a ; — with one known exception: when what follows that ? or ; reads as a parameter whose key names a user, a mail or a secret (pa;pwd=x@host), the redactor takes it for a parameter and the first part of the password stays visible. Failing closed there would also hide ordinary URLs such as ;password=P@ss, so it is left as it is and documented. The error of xa=true for a URL whose XADataSource cannot be guessed quotes the URL the same way.

One group per pool, read from the pool’s own counters, without a lock and without I/O:

Two charts per pool: Connections — active, idle stacked on it, waiting, under the dashed maxSize — and Throughput — borrows and timeouts per second.

Two readings of the gauges would be wrong:

Under mvn vidocq:dev, each pool also has a tab of the Mansart pools panel, named after it — @Default first, then the named pools in name order — whose list offers five actions. They answer in the dev console’s table of rows.

The form has two fields: sql, the statement, in the dev console’s query editor with the pool’s language (SQL), and params, its named parameters as a JSON object, whose schema follows the statement. A :name outside a string, a quoted name and a comment is bound with the member name of params, as setObject: a string, a number (an integer as a long), a boolean or null, and a list as a SQL array where the driver makes one (WHERE id = ANY(:ids)); a cast such as due::text is no parameter. On PostgreSQL a string is bound untyped, so that the database types it from where it is: {"day": "2026-10-01"} is a date in due_date < :day, and a time with its offset, a UUID or an enum constant work the same way; a parameter PostgreSQL cannot type, such as :p in :p IS NULL, makes the statement run again with its strings and its nulls bound as text. A … or E'…' string is read as a string, as '…' is. A parameter with no member is refused before anything runs, missing parameter id, and so is a text of two statements, one statement at a time; a last ; is fine.

Values. A number is shown as a number, but a numeric and an integer past 2^53 as their text, so that nothing is rounded; a date, a time or a timestamp as ISO text, with its offset when it has a zone (2026-10-01T12:00+02:00); binary as 0x and the hex of its first 64 bytes, … after when there are more; an array as the JSON of its elements; a text past 10 000 characters cut with …; anything else, a json, an interval, as the driver writes it.

Failures. A statement runs at most 30 seconds, then is cancelled: the statement ran past 30 s and was cancelled. A failing statement shows the database’s message, on one line, with the pool’s URL, its password and its user after the word user masked; Exchange holds the statement, its parameters, the transaction, the SQLState and the vendor code. A pool with no connection to lend answers once its acquireTimeout has passed. Every call takes a connection from the pool and gives it back as it was, its auto-commit and read-only flag restored, whatever happened.

The sql language. What the editor knows of the pool is read once per boot from DatabaseMetaData and offered as the language sql-<pool> — sql-default for @Default, a named pool’s name in lower case: SQL-92’s keywords and the product’s (getSQLKeywords()), the common functions, the database’s identifier quote and how it stores a name written without quotes; each table and view, bare in the current schema and schema.name in another, with its columns, their JSON type and <SQL type> · column, and a column of a single-column foreign key leading to the table it refers to. Past 1 MiB it is written without the details, then without the types; past it still, the pool has no language, which a WARNING says, and the editor colours the keywords it knows alone. A pool whose tables cannot be read at boot gets no language, no Describe and no Preview, which a WARNING says without its URL; Tables, Query and Execute still work. A table created later is listed by Tables but known to the editor, Describe and Preview after the next dev reload only.

A pool whose minIdle asks for connections at boot opened none of them. The pool gives up its pre-fill at the first failure, without a word, and opens connections on demand only, so the first requests pay for them, and fail if the cause is still there:

Check the URL, the credentials and the JDBC driver of that pool.

A named pool is open, but no @Named("<name>") DataSource bean serves it: the bean is generated at compile time by vidocq-runtime-mansart-pool-datasources-codegen, which the application’s annotation processor paths lack. An injection or a repository routed to that pool fails on its first use:

When the container cannot say which beans it has, no pool is flagged: the report never guesses.

Mansart could not build the model of a repository’s primary entity: its generated metamodel failed, or the entity has no id field, no no-arg constructor, or a package Mansart cannot open. The entity keeps its place in the catalogue, without its columns, and its card says unavailable: with the class of the exception. The exception’s message is never shown. The boot goes on, but the repositories of that entity will likely fail on their first call:

Check the entity’s jakarta.persistence annotations, its id and its constructor, and that its package is open to io.vidocq.mansart.data.core.

The extension’s module, io.vidocq.runtime.extensions.essentials.langchain4jcdi.mcp, is kept in the boot layer like every io.vidocq.runtime.extensions module, and it reads dev.langchain4j.cdi.mcp.server and the invoker. A module kept in the boot layer keeps what it reads, so the MCP server lives in the boot layer in every launch shape: vidocq:dev, vidocq:run, the generated launcher and a @VidocqMain trampoline started from the IDE. The application layer holds the application’s modules only, and the report’s layer section shows it.

The extension’s manifest asks the application’s vidocq:generate to scan the langchain4j-cdi jars it brings (Vidocq-Scan-Dependencies: dev.langchain4j.cdi.mcp:*) NEW: the server’s beans run generated code — created, injected and called by a _VaubanComponents in their own packages, behind build-time client proxies — instead of reflection, from an enriched copy of the jars that every launch uses. The JAX-RS providers among them carry @Provider alone and are beans only through Cassini’s build-compatible extension; vidocq:generate runs it too, so they are covered like the rest. See the vidocq:generate goal.

Two hand-made layouts break this:

With no key set, the extension adds nothing and the server keeps its defaults, or the application’s own @Named("mcp-server") McpServerConfig producer. With one key or more, the extension publishes the whole configuration as that bean; when the application produces one as well, the keys win (VIDOCQ-MCP-004 — keys and an application producer NEW). A value a key does not accept stops the boot with an error that names the key and what it accepts, never the value. A misspelled key under vidocq.mcp. is reported as VIDOCQ-CFG-003.

The summary line counts what the server serves, and the detailed report describes it. Without an McpEndpoint bean the summary reads not deployed; with langchain4j-cdi loaded twice, loaded twice and nothing else.

server says where the configuration comes from: vidocq.mcp.*, application bean or defaults. The request-state secret is only ever printed as configured or not configured; session ids, tool descriptions, schemas and headers are never printed. The section reads what the server holds in memory and creates none of its session beans; at the detailed level it also reads the configuration resolver.

The mcp section is also a panel of the dev console: its boot facts stay, and seven values are read again on every poll, about once a second, from the counters the MCP server already keeps in memory — no lock, no I/O, nothing logged, and no bean created.

The three invoker.* values come from one bean, so they are absent together, with the same reason: reflection when no invoker provider bean exists at all — the optional CDI 4.1 invoker module registered none, and the whole server invokes by reflection — and built at the first call when the bean exists but the container has not built it yet. When the MCP server is not in this container, every value is absent with no MCP server in this container, as the summary reads not deployed (VIDOCQ-MCP-002 — the server is not deployed NEW). A twin server (VIDOCQ-MCP-003 — the server is loaded twice NEW) leaves the panel inert: it samples nothing at all, as its section shows nothing.

Two charts: Connections — sessions as an area, streams and listens as lines — and Server-to-client requests — pending as a line. The three invoker values get no chart on purpose: they grow once per method and then stop, so a curve of them would read as traffic.

Here is a real server read through api/snapshot, once before it had served anything and once after six calls over four MCP methods:

Two traits of this panel are worth knowing, because both read as bugs until they are explained.

It never creates a bean. sample() holds the Bean metadata resolved once at onStart, and asks the bean’s Context for the instance it already has, with the single-argument Context.get, which returns null rather than creating one. Holding a client proxy obtained at boot and calling it on every poll would create the bean on the first poll of the page: for McpSessionManager that means starting its mcp-session-cleanup thread, once a second, on an application that has served no request and asked for nothing. A panel measures; it does not change what it measures.

A missing instance is absent with a reason, never a zero. A bean with no instance has no number to give, and a zero would claim a measure the panel does not have — "no session open" and "nobody has ever asked" are not the same fact. The reasons above are what the page shows in place of the number, greyed.

What reaches the page is a key, a kind, a number and a unit: no session id, no tool name, no header, and never the request-state secret, which stays what the report writes as configured or not configured.

The anomalies below are each one WARNING record on io.vidocq.startup.anomaly, logged at every level of the report (Anomalies). They cover what the extension makes possible or alone can see; langchain4j-cdi’s own failures stay in its logs.

The descriptor of dev.langchain4j.cdi.mcp.server does not declare provides org.mcpjava.server.spi.McpServerSPI, or the module is not open. In the boot layer the JDK ignores META-INF/services, so every tool or prompt that builds a ToolResponse, a PromptResponse or a TextContent fails:

Use a langchain4j-cdi version that declares both.

The extension is present but no McpEndpoint bean exists, so /mcp answers 404. The bean list names the classes of the langchain4j-cdi version the extension was built with: an application that forces another langchain4j-cdi version can lose them. The section reads not deployed:

-Dvidocq.app.modules put a dev.langchain4j.cdi.mcp.* module in the application layer, so langchain4j-cdi is loaded twice: its beans come from the application layer while the extension reads the boot-layer copy. The calls still work; the section reads loaded twice and shows nothing else:

vidocq.mcp.* keys are set and the application also produces a @Named("mcp-server") McpServerConfig. The keys win:

Keep one of the two.

A tool, prompt or resource template argument has no explicit name and its class was compiled without -parameters: clients see it as arg0, and its value is never bound. One record names every method concerned:

The extension declares these keys, so a mistyped one, such as vidocq.migration.location, is reported as read by nothing NEW (VIDOCQ-CFG-003).

vidocq:dev, vidocq:run and the launcher vidocq:package writes by default boot the application in a module layer of its own. Its class loader serves a script by name, but lists no directory. The backends used to scan classpath:db/migration with a loader, and found nothing there: Flyway logged No migrations found. Are your locations set up correctly?, the boot went on with an empty schema, and the first query failed with Table "…" not found. Liquibase stopped the boot, the changelog not found.

The backends now list classpath: locations from the application’s own modules, through ApplicationLayer (Listing the application’s files), and read each file by name:

A @VidocqMain trampoline re-layers the application in Vidocq.run(), so its IDE and flat launches take this path too. A launch that leaves the application module in the JVM’s boot layer keeps the backend’s own scanning: -Dvidocq.dev.layer=false or vidocq.package.layer=false for an application without a trampoline, a class-path launch, and the tests. Flyway locations that mix classpath: with filesystem: are left to Flyway’s scanner, which cannot list the classpath: ones in the application layer. The migration logs a warning saying so: keep the locations all classpath: or all filesystem:.

Since 4.30, Liquibase sends usage data to Liquibase by default for open-source users (liquibase.analytics.enabled, with its settings fetched from config.liquibase.com). The extension runs every migration, listing and clean with that option off, unless a value is configured where Liquibase reads its configuration: -Dliquibase.analytics.enabled=true, LIQUIBASE_ANALYTICS_ENABLED, or a defaults file. A configured value, true or false, is kept as it is.

The section migration, Schema migration, says what each datasource’s migration did:

A datasource’s migration found no migration at its locations, and its schema history records none: the schema was not migrated at all, and the first query on it will fail. It is a warning in every launch mode:

Check the key the hint names, and that the scripts are packaged with the application under that path. In a launch that leaves the application module in the boot layer (Scripts in the application layer NEW), also check that module-info.java opens their package (opens db.migration;). A schema whose history holds a migration, a repeatable one included, is never flagged, so an up-to-date restart is not an anomaly. vidocq.migration.failOnMissingLocations=true turns an empty Flyway location into a boot failure instead.

The dev console shows the section as the migration panel, with the boot facts above and one card per migrated datasource below:

The migrations are listed once after the boot’s migration, in a dev launch only, and again after each action: listing opens a connection, and the page’s polls never do.

In a dev launch the panel offers two actions (the console runs them for its own page only), each on one migrated datasource, picked from a list:

Actions on one datasource run one after the other. An action runs while the application runs: a query on the datasource at the same time may fail, which the developer who clicked accepts. The answer and the log line name the datasource and counts, never its URL or password. A backend written for an older SPI, without info or clean, shows its tables absent, flyway cannot list the migrations for instance, and answers clean-and-migrate with default: flyway cannot clean a schema, nothing dropped.