Nothing to declare. mvn vidocq:dev adds the console itself, at the Vidocq version of the application’s Chappe extension — with a warning when the plugin is another version (Vidocq/vidocq#148) — the moment the application already has vidocq-runtime-chappe-webserver-extension: the console serves its page through Chappe, on a listener of its own, so without Chappe there is nothing to serve it and nothing is added. It also adds, for every runtime extension that has one, that extension’s -dev panel module (A -dev module, never packaged), so the extension’s tab is live. One INFO line lists what was added:

An application that has never served HTTP — no Chappe, so no console either — logs why instead, and starts without it:

A test that reads the console — an assertion against its /api/snapshot, say — declares it itself, together with the -dev modules it needs, at test scope: mvn test, vidocq:test and the continuous tests of vidocq:dev add none of them.

vidocq:run, vidocq:package, vidocq:jlink, vidocq:jpackage and vidocq:docker never contain the console or any -dev module: every one of their jars carries Vidocq-Dev-Only: true in its manifest, and these goals drop such a jar from what they launch or ship, even when the project declares it — a declared console, for instance, kept from before this changed. Each dropped jar logs one WARNING per goal run, never fails the build, and names what to remove:

vidocq:checkpom gives the same advice earlier, at validate: a warning, never a failure, for a dev-only dependency declared in any scope but test. See Dev tools and binaries for the full picture, companions included.

The console’s SPI, vidocq-runtime-devconsole-spi, is not marked: it is an ordinary API jar of five small types, and it ships in a binary whenever an extension that keeps the all-in-one DevConsolePanel form (A -dev module, never packaged) requires it, so that such an extension still resolves outside vidocq:dev.

Then run the application in dev mode:

The banner promises the console, and one INFO record gives its address once it listens:

Open that URL. The browser is never opened for you.

vidocq.devconsole.enabled is auto by default: the console starts when the launch mode of the boot is dev — mvn vidocq:dev, a run from an IDE, -Dvidocq.launch.mode=dev — and stays off in test and prod. true and false force it on or off, whatever the mode.

auto also turns it on for a dev read from the shape of a build tree, such as an application run from target/classes by a CI job. That is accepted: the console listens on the loopback address only, and a port that is already taken never stops the application (When the port is taken NEW).

When the console is off, its section of the startup report says why, and nothing listens:

off (vidocq.devconsole.enabled=false) when it was forced off. Every dev reload starts a new console, with a new listener; a reload whose boot fails takes the console down with it, and the page says so (The page NEW).

Like every key, they can be set with -D, an environment variable (VIDOCQ_DEVCONSOLE_PORT), vidocq.properties or a profile (%dev.vidocq.devconsole.port). On the Maven command line, mvn vidocq:dev -Dvidocq.devconsole.port=9000 reaches the application: vidocq:dev forwards the -Dvidocq.* keys to the JVM it forks, as vidocq:run does. The console declares these three keys, so the key audit reports a mistyped one as VIDOCQ-CFG-003: nothing reads a vidocq.devconsole.prot=18090, and the console listens on 8888, but the boot says so.

Without the console on the module path, nothing claims the namespace, and a configured vidocq.devconsole.* key is not audited.

The console declares its listener, dev, itself: vidocq.chappe.listeners must not list it (A listener of an extension’s own).

The page is plain HTML, one stylesheet and one JavaScript module, all served by the console: no build step, and nothing loaded from another site, not even a font. It reads one document, GET /api/snapshot, about once a second.

In a dev launch of an application that has vidocq-runtime-langchain4j-cdi-mcp-extension, the mcp tab lists the application’s tools, prompts, resources and resource templates, and can call each of them. The tab has four sub-tabs: Monitoring, with the panel’s values, charts and boot facts, then Tools, Prompts and Resources, resources and resource templates sharing the last. A sub-tab of a kind is a list to pick the item from, its description and its form under it, then its result in a block of its own, then the history of that kind’s calls; past ten items a text filter above the list narrows it. The page remembers the open sub-tab in this browser, and, until the page is reloaded, the item picked in each.

A tool’s arguments are a generated form when its input schema allows one — scalars, enums of strings, and objects of those one level down — and the JSON editor otherwise, started from its required properties, which checks and completes them against the schema. A "JSON" switch shows the same values in that editor on a form too, and switching back keeps them. A prompt’s arguments and a resource template’s variables are always a flat form, one string per argument or variable.

The call goes through the application’s own /mcp, from the console’s own JVM, in protocol 2026-07-28, with no session opened: the URL is the one the startup report prints for /mcp, a loopback one preferred when more than one listener carries it. When no listener has bound /mcp, the tab shows absent: /mcp has no bound address and offers nothing to call. The inspector sends no credentials and never goes through a proxy: when /mcp is behind authentication, every call answers HTTP 401. The console shows the first 128 actions of a panel; past that, the inspector’s line ends with (first 128 shown).

Confirmation. Before it sends a tool call, the page asks Call <name>? It runs the application’s code, and may change data. unless the tool is readOnlyHint: true and not destructiveHint: true. A prompt get or a resource read never asks.

A result shows in a block of its own under the form: a header with the outcome, ok in green, error in red, running… while the call runs, then the summary line, the round trip the page measured and the viewer’s buttons; then the body, JSON going through the JSON viewer; and, folded under "Exchange", the JSON-RPC request and response exactly as they were sent and received (or the SSE events, for a streamed answer). Each item keeps its last result while the page is open: picking it again in the list shows it. A refused call, or a console that does not answer, shows its reason in that block too, as an error. What each outcome shows:

A response body past 1 MiB fails the call as a transport failure; the panel never buffers more of it than that. The body and the details the page shows are truncated at 256 KiB regardless, as any action’s are.

A tool that asks the client for input. The inspector declares no client capability — neither elicitation, nor sampling, nor roots. A tool that checks isSupported() first, as langchain4j-cdi recommends, runs its fallback, which is how you test it. A tool that asks anyway gets the server’s missing-capability error (-32021), which the inspector reports with the refusal line above, naming the capability. Nothing is parked on the server, whatever the request-state mode: in CONTINUATION mode too, the call ends with that error before any invocation waits for an answer.

History. The panel keeps the last 20 calls of the boot, newest first, each with its time, action, outcome, duration and arguments, and a "Replay" button that picks the action in the list and fills its form with those arguments, and sends nothing until you submit. Each sub-tab shows the calls of its own kind, under the result. A dev reload clears the history along with the catalogue; an item it removed loses its result, the list falling back to the first item of its kind, and a kind left with no item sends the tab back to Monitoring.

Secrets. An argument whose name holds, ignoring case, password, passwd, secret, token, apikey, api-key, api_key, credential or authorization, at any depth, is shown as in the history, the "Exchange" details and the console’s log line; a string or number value of four characters or more that belongs to such an argument is also replaced by wherever it appears in the summary, the details and the body of an error or an input request, in case the server quotes it. The MCP server itself always receives the real value, and a result body is shown exactly as the server returned it. A masked value is left empty on a replay: type it again.

What v1 does not do. Elicitation, sampling and roots are not supported — a tool that needs one gets the refusal line above, not a dialog. There is no support for subscriptions, notifications or progress, for completion, or for calling an MCP server other than the application’s own.

Every JSON the page shows — the body of an application/json result and the details under "Exchange" — goes through a small viewer instead of plain text. Keys, strings, numbers, and true, false and null each have their colour, in the light and the dark themes. Every object and array folds under a ▾/▸ toggle; folded, it reads {…} 3 keys or […] 12 items. A click on the toggle or on that summary flips the node; Alt+click flips it and everything under it. The first two levels start open, only the first when the document holds more than 500 values.

Expand all, Collapse all and Copy sit next to what they act on: in the result’s header for the body, at the top of "Exchange" for the details. Copy writes the JSON indented, masked values as the server sent them; when the browser refuses the clipboard, the button says Clipboard refused and nothing else happens. An integer too large for a JavaScript number, such as 9007199254740993, is shown and copied as the server wrote it in a browser that gives JSON.parse the source text of a number, such as a current Chrome; elsewhere it is rounded to the nearest JavaScript number.

The viewer keeps what is folded while the page polls, and forgets it when a new result replaces the one on screen. A body that does not parse as JSON is shown as text. The tree is built with DOM calls only, never as markup, so a key or a string is never read as HTML.

A result of rows — what Query answers in a pool’s tab or in the JDQL tab of Mansart Data, a table’s columns, its first rows — is drawn as a table. Each column’s header holds its name and, dimmed under it, its type; the header stays in view while the rows scroll, and a wide table scrolls sideways inside the result. A NULL is written NULL, dimmed, and is never mistaken for an empty string, which is an empty cell. A value longer than 200 characters is cut with …, and the whole of it shows when the pointer rests on the cell. When the panel sent only the first rows, more rows not shown says so under them.

The result’s bar adds Table and JSON, which shows the same body in the JSON viewer, and Copy as CSV, which copies the rows as RFC 4180 CSV: the header first, , between fields, a field with a comma, a quote or a line end quoted, each line ended by CRLF, NULL an empty field and an empty string "". The page remembers which of the two it shows while it polls. A cell of a column named replay is a button named after the action it fills, as Tables offers Describe and Preview for each table; nothing is sent until you submit.

A panel answers rows with PanelAction.ActionResult.rows(summary, columns, rows, more): columns are ActionResult.Column(name, type) records, a name and a type of 200 characters at most; each row holds one value per column, null, a Boolean, a Number or a String, anything else written as its toString(). The body, {"columns": [{"name", "type"}…], "rows": [[…]…], "more": bool} of type application/x-rows+json (ActionResult.ROWS), stays within the 256 KiB of a result: the rows past it are left out and more set. A body of another shape is shown as any other JSON.

A json argument of an action — an MCP tool’s arguments in the MCP inspector, the arguments of a repository method in the Mansart Data tab — is typed in a small code editor written for the page, which loads nothing from elsewhere. It reads the argument’s JSON Schema as you type:

The editor reads these keywords of the schema: type (one name or a list), properties, required, additionalProperties, items (a schema, or a list for the positions of an array), enum, maxLength, format, readOnly, description, and a $ref to /$defs/… or /definitions/…. Any other $ref is not followed; what is under anyOf, oneOf, allOf, not or patternProperties is accepted as it is. A schema the editor does not understand makes it check less, never fail. What you typed is sent as you typed it. Past 100 000 characters the editor stops colouring and checking, and says past 100 000 characters: no colours, no checks; completion and Format still work.

A query argument — the query of the JDQL tab of Mansart Data, in Query, Update / Delete and Export CSV (A JDQL console for Mansart Data) — is typed in the same editor, in its query mode, five lines high, with the vocabulary its panel publishes: the entities and their attributes. The page fetches that vocabulary once, when the first form that needs it is drawn, and again after a dev reload only; until it arrives, or when it cannot be had, the editor works with the keywords alone and says why under it, no vocabulary: 404. It arrives without moving the text or the caret.

The console shows what the application is made of, so it is built to be seen by you only:

In a dev launch, the console is also an MCP server, as Quarkus’s Dev MCP is: a coding agent, such as Claude Code, asks the running application what it serves instead of guessing it from the sources. It is served by the console itself, on the console’s own listener, never the application’s, so it works whether or not the application uses MCP or langchain4j-cdi, and adds no dependency. The console prints its URL after its own:

and the devconsole section of the report shows it on its mcp row. To point Claude Code at it:

Any MCP client that speaks the Streamable HTTP transport does the same; the MCP Inspector lists the tools with npx @modelcontextprotocol/inspector --cli --transport http --server-url http://127.0.0.1:8888/mcp --method tools/list.

Each tool answers one JSON object, as structuredContent and, for a client that reads text only, indented in one text content. They are built from the very document the page polls, /api/snapshot, minus what only the page needs to act — the token of the boot and the actions — so an agent sees nothing the page does not: secrets read configured, values are masked as on the page (Security NEW).

The first four are anomalies of the console’s section of the startup report: each is one WARNING record on io.vidocq.startup.anomaly, logged the moment it is found and recalled by the report (Anomalies). The fifth comes later, from a poll, the sixth from a refused action request, and the seventh, eighth and ninth NEW from matching the live panels the -dev modules bring against the report’s sections, once per boot — all five on the console’s own logger, io.vidocq.devconsole.