@anchrd/intel 0.59.0

package/dist/tools/tool-servers/tool-servers.d.ts

@@ -0,0 +1,46 @@
+import { type ToolServer } from "../../contract/tool.js";
+/**
+ * The portal's own directory tool. It is an ordinary entry in `tools/list`, so it is reached the
+ * same way every other tool is: `tools/call` with the asking user's portal token.
+ *
+ * ⚠️ Its presence in the live list is also the permission check. A deployment whose portal does not
+ * offer it, or a user whose Access policies hide it, gets no server list at all — and therefore
+ * cannot delegate anything. That is deliberate: the alternative would be inventing the server list
+ * out of tool names, which is exactly the guess this module exists to avoid.
+ */
+export declare const ServerDirectoryTool = "portal_list_servers";
+export interface ToolServerDirectoryAnswer {
+    isError: boolean;
+    content: unknown[];
+    structuredContent?: unknown;
+}
+/**
+ * The servers this user reaches: the portal's directory, confirmed against the portal's live tool
+ * list.
+ *
+ * Two sets come out of one answer, and keeping them apart is the whole of this function:
+ *
+ * - **`declared`** — every identifier the directory mentions at all, disabled rows included. It is
+ *   the universe `serverOf` attributes against, and it must be as WIDE as possible. ⚠️ Narrowing it
+ *   widens the delegation: drop `wiki_extra` because the portal marked it disabled, and the live
+ *   tool `wiki_extra__read` falls back onto `wiki` — a tool of a server nobody delegated, handed to
+ *   an agent that was given `wiki`. Filtering therefore happens after attribution, never before it.
+ * - **the returned list** — what may actually be delegated: enabled, and confirmed by at least one
+ *   live tool. Intel cannot prove that a directory identifier is the same string the namespace uses,
+ *   so it only ever offers handles it has just seen work.
+ *
+ * ⚠️ What remains outside Intel's reach: a directory that omits a server whose tools ARE in
+ * `tools/list`. Nothing in the answer distinguishes that from a tool of the enclosing namespace, and
+ * the portal is the authority on its own servers — so an incomplete directory widens by exactly one
+ * namespace level, and it is a portal defect rather than something this code can detect.
+ */
+export interface ToolServerDirectory {
+    /** Every identifier the directory mentioned. Attribute against this, never against `servers`. */
+    declared: string[];
+    /** What may be offered and delegated: enabled, and confirmed by a live tool. */
+    servers: ToolServer[];
+}
+export declare function toolServersFrom(input: {
+    directory: ToolServerDirectoryAnswer;
+    toolNames: string[];
+}): ToolServerDirectory | null;

package/dist/tools/tool-servers/tool-servers.js

@@ -0,0 +1,177 @@
+import { z } from "zod";
+import { serverOf } from "../../contract/tool.js";
+/**
+ * The portal's own directory tool. It is an ordinary entry in `tools/list`, so it is reached the
+ * same way every other tool is: `tools/call` with the asking user's portal token.
+ *
+ * ⚠️ Its presence in the live list is also the permission check. A deployment whose portal does not
+ * offer it, or a user whose Access policies hide it, gets no server list at all — and therefore
+ * cannot delegate anything. That is deliberate: the alternative would be inventing the server list
+ * out of tool names, which is exactly the guess this module exists to avoid.
+ */
+export const ServerDirectoryTool = "portal_list_servers";
+/**
+ * What the portal answers about one server, read as tolerantly as possible.
+ *
+ * ⚠️ Only the shape is assumed, never the vocabulary. The portal is somebody else's product and its
+ * payload is not part of any contract Intel owns, so every field is optional and the answer is
+ * accepted from `structuredContent`, from `{ servers: [...] }`, from a JSON text block, or — the
+ * form the live portal actually uses — from the prose block `proseRows` reads. What makes a row
+ * usable is not that it parsed but that its identifier is confirmed against the live tool list
+ * below.
+ */
+const DirectoryRow = z.looseObject({
+    id: z.string().optional(),
+    name: z.string().optional(),
+    enabled: z.boolean().optional(),
+});
+const DirectoryRows = z.array(DirectoryRow);
+const DirectoryEnvelope = z.looseObject({ servers: DirectoryRows });
+/** A line the portal meant as a directory entry: `- <display name> (<handle>): <state>`. */
+const ProseRow = /^\s*[-*•]\s+(.+?)\s*\(([^()\s]+)\)\s*:\s*(.*)$/;
+/** What claims to be an entry at all. Everything else in the block is a heading or a hint. */
+const ProseBullet = /^\s*[-*•]\s/;
+/**
+ * ⚠️ Never the ✓. A tick is decoration: a different locale, a plain-text client or a later version
+ * of the portal writes the same fact another way, and a reading that hangs on one code point would
+ * silently switch every server off. What is read is the word, and the word alone.
+ *
+ * It has to be the WHOLE state, not a word inside it, because "disabled" contains "enabled" and
+ * "not enabled" is built from it — a substring test would read both as switched on, and that is the
+ * one direction this must never get wrong. Anything else the portal might write ("aktiviert",
+ * "enabled (3 tools)") is therefore not offerable, and stays declared.
+ */
+function readsAsEnabled(state) {
+    const words = state.toLowerCase().match(/\p{L}+/gu);
+    return words !== null && words.length === 1 && words[0] === "enabled";
+}
+/**
+ * The portal's prose form: a heading, one bullet per server, a closing hint. It is what the live
+ * portal actually answers (#233), and it is read only after every JSON reading in `rows` has failed.
+ *
+ * ⚠️ This reading hangs on somebody else's wording and can break without warning. The portal owes
+ * Intel no format at all, so a reworded state, a translated page or a changed layout is a normal
+ * event here rather than a defect. Two things keep that from becoming a quiet widening:
+ *
+ * - **A bullet that does not read as a row refuses the whole answer.** Skipping it would hand back
+ *   a directory with one server missing, and a missing row is not a smaller list — it lets that
+ *   server's tools fall back onto the shorter handle that encloses them, which is exactly the
+ *   widening the split between `declared` and `servers` exists to prevent. The price is that a
+ *   portal which one day bullets its closing hint fails loudly with the same closed
+ *   `tool_servers_unavailable` that #233 found; that is the intended direction.
+ * - **Nothing read here can invent a server.** A handle no live tool confirms is never offered, so
+ *   a misread line costs an offer, never a delegation.
+ */
+function proseRows(answer) {
+    const parsed = [];
+    for (const block of answer.content) {
+        if (typeof block !== "object" || block === null || !("text" in block))
+            continue;
+        const text = block.text;
+        if (typeof text !== "string")
+            continue;
+        for (const line of text.split("\n")) {
+            if (!ProseBullet.test(line))
+                continue;
+            const [, name, handle, state] = ProseRow.exec(line) ?? [];
+            if (name === undefined || handle === undefined)
+                return null;
+            // `id` carries the handle and `name` the display name, but neither is believed on its own:
+            // both stay candidates in `toolServersFrom`, and the live tool list decides which one
+            // actually namespaces.
+            parsed.push({ id: handle, name, enabled: readsAsEnabled(state ?? "") });
+        }
+    }
+    return parsed.length > 0 ? parsed : null;
+}
+/**
+ * Every place the portal could reasonably have put its list, tried in order. An MCP tool result is
+ * either structured or text, and a server that answers with `{ servers: [...] }` is as likely as
+ * one that answers with a bare array.
+ *
+ * ⚠️ The prose reading comes last and is ADDITIONAL, never replacing. The portal is somebody else's
+ * product: it answers in prose today and may answer structured tomorrow, and a structured answer
+ * must keep winning on the day it arrives beside a human sentence.
+ */
+function rows(answer) {
+    const candidates = [answer.structuredContent];
+    for (const block of answer.content) {
+        if (typeof block === "object" && block !== null && "text" in block) {
+            const text = block.text;
+            if (typeof text !== "string")
+                continue;
+            try {
+                candidates.push(JSON.parse(text));
+            }
+            catch {
+                // A text block that is not JSON may still be the directory — see `proseRows` above. It is
+                // not fed to the JSON readings here, and it does not make them fail either: the portal may
+                // well add a human sentence beside the payload.
+            }
+        }
+    }
+    for (const candidate of candidates) {
+        const bare = DirectoryRows.safeParse(candidate);
+        if (bare.success)
+            return bare.data;
+        const wrapped = DirectoryEnvelope.safeParse(candidate);
+        if (wrapped.success)
+            return wrapped.data.servers;
+    }
+    return proseRows(answer);
+}
+/**
+ * ⚠️ The rule itself — longest match against declared handles, never a cut at an underscore — is
+ * `serverOf` in the contract (`src/contract`), because the tools screen has to read a name exactly the
+ * way the delegation does (#212). What stays here is what the rule is USED for: a tool whose prefix
+ * matches no declared handle belongs to no server and can never be delegated, which is what keeps
+ * the portal's own management tools (`portal_list_servers`, `portal_toggle_servers`) out of an
+ * agent's reach — the portal does not list itself as an upstream server.
+ */
+/**
+ * ⚠️ A handle that would carry the portal's OWN tools is never a server anybody can be given.
+ *
+ * The portal does not list itself as an upstream, so in practice `portal` never appears in the
+ * directory — but "in practice" is not a guard. One row called `portal` (an upstream a customer
+ * happens to name that way, a future portal that describes itself) would make `portal_toggle_servers`
+ * a delegable tool, and an agent could then switch its delegator's MCP servers on and off. The rule
+ * is written as a question about reach rather than as a blocklist of one string: if delegating this
+ * handle would hand over `portal_list_servers`, the handle is refused.
+ */
+function ownsTheDirectory(handle) {
+    return ServerDirectoryTool.startsWith(`${handle}_`);
+}
+export function toolServersFrom(input) {
+    const parsed = rows(input.directory);
+    if (parsed === null)
+        return null;
+    // `id` and `name` are both offered as candidates because the portal's directory names them
+    // separately and only one of them is the namespace. The live list decides which.
+    const display = new Map();
+    const offerable = new Set();
+    for (const row of parsed) {
+        for (const candidate of [row.name, row.id]) {
+            if (candidate === undefined || candidate.length === 0)
+                continue;
+            if (ownsTheDirectory(candidate))
+                continue;
+            if (!display.has(candidate))
+                display.set(candidate, row.name ?? row.id ?? candidate);
+            if (row.enabled !== false)
+                offerable.add(candidate);
+        }
+    }
+    const counts = new Map();
+    for (const toolName of input.toolNames) {
+        const handle = serverOf(toolName, display.keys());
+        if (handle === null || !offerable.has(handle))
+            continue;
+        counts.set(handle, (counts.get(handle) ?? 0) + 1);
+    }
+    return {
+        declared: [...display.keys()],
+        servers: [...counts.entries()]
+            .map(([handle, toolCount]) => ({ handle, name: display.get(handle) ?? handle, toolCount }))
+            .sort((a, b) => a.handle.localeCompare(b.handle)),
+    };
+}

package/dist/tools/tools.d.ts

@@ -0,0 +1,2 @@
+import type { ToolDeps, ToolService } from "./tools.types.js";
+export declare function createTools(deps: ToolDeps): ToolService;

package/dist/tools/tools.js

@@ -0,0 +1,207 @@
+import { IntelError } from "../shared/intel-error/intel-error.js";
+import { reportUnexpectedError } from "../shared/report-unexpected-error/report-unexpected-error.js";
+import { ServerDirectoryTool, toolServersFrom, } from "./tool-servers/tool-servers.js";
+const CallTimeoutMs = 15_000;
+const MaxTools = 1_000;
+const MaxResultBytes = 1_000_000;
+// Refresh slightly early so a call cannot start with a token that expires mid-flight.
+const RefreshWindowMs = 30_000;
+/*
+ * ⚠️ Until #390 this file answered two kinds of caller: a person, and an agent acting on somebody
+ * else's portal connection (D30). The second one is gone with the agents, and with it the
+ * delegation lookup, the cut against the portal's server directory, and the audit row that named
+ * both principals. What is left is the rule the delegation was an exception to: the token is read
+ * per actor and never shared — one operator token for everybody would make every catalog the same
+ * one and the portal's Access policies decorative (ADR-0003).
+ */
+export function createTools(deps) {
+    function portal() {
+        if (!deps.portalUrl || !deps.sourceAllowed(deps.portalUrl)) {
+            throw new IntelError(503, "portal_not_configured", "No MCP portal is configured for this deployment");
+        }
+        return deps.portalUrl;
+    }
+    // Authorization for tools lives entirely in the portal, so "may this user act" reduces to "does
+    // this user have a usable portal token".
+    async function accessToken(actor) {
+        const stored = await deps.tokens.read(actor.id);
+        if (!stored) {
+            throw new IntelError(401, "portal_not_connected", "The portal has not signed this user in yet");
+        }
+        if (stored.expiresAt > deps.now().getTime() + RefreshWindowMs)
+            return stored.accessToken;
+        const refreshed = stored.refreshToken ? await deps.refresh(stored) : null;
+        if (!refreshed) {
+            // Losing a connection is a visible event for the person and an invisible one for everybody
+            // else: the screen simply asks them to sign in again, and no trace says why. The two reasons
+            // need telling apart — a portal that issues no refresh token at all is a configuration
+            // problem, a refresh that gets rejected is a different one (#97).
+            reportUnexpectedError(new Error(`portal token dropped: ${stored.refreshToken ? "refresh was rejected" : "no refresh token was ever issued"}`));
+            // A token that cannot be renewed is dropped: leaving it would keep failing every call with a
+            // stale credential. The browser answers this by signing in silently again (#60); an MCP
+            // client sees the code and repeats its own authorization.
+            await deps.tokens.clear(actor.id);
+            throw new IntelError(401, "portal_reconnect_required", "The portal sign-in for this user has expired");
+        }
+        await deps.tokens.write(actor.id, refreshed);
+        return refreshed.accessToken;
+    }
+    /**
+     * ⚠️ Whatever the portal answers, the caller hears which side is at fault — never a bare 500.
+     *
+     * Measured against the live installation (#308): adding ONE server to the portal made
+     * `/api/v1/tools` answer `500 internal_error`, and with it every tool of every OTHER server
+     * disappeared — an empty tools screen, an agent profile that can offer nothing, and no hint
+     * anywhere which of the four servers caused it. The failure is total by nature (there is one
+     * `tools/list` for the whole portal, and the MCP client either parses it or does not), but the
+     * SILENCE was ours: the throw travelled up unhandled.
+     *
+     * `tool_catalog_unreadable` is therefore not a nicer word for the same outage. It is the
+     * difference between "Intel is broken" and "the portal answered something Intel could not read,
+     * and the reason is in the log" — the same rule `adapters/json-schema` learned the hard way in
+     * #229, where a catch-all that renamed the failure hid it for weeks.
+     */
+    async function remoteTools(actor) {
+        const token = await accessToken(actor);
+        const remote = await deps.remote
+            .list(portal(), token, AbortSignal.timeout(CallTimeoutMs))
+            .catch((error) => {
+            // An IntelError on this path is a decision somebody already made (an expired sign-in, a
+            // refusal). Renaming it would throw away the one message that names the actual cause.
+            if (error instanceof IntelError)
+                throw error;
+            reportUnexpectedError(error);
+            // ⚠️ Deliberately says nothing about WHY. This one catch covers a portal that answered
+            // something unparseable, a portal that did not answer at all (the deadline above), and a
+            // portal that refused — and a message naming one of them would be wrong for the other two.
+            // That is the #229 mistake in miniature: a sentence more specific than the evidence sends
+            // the reader looking in the wrong place. The evidence is in the log.
+            throw new IntelError(502, "tool_catalog_unreadable", "The MCP portal's tool list could not be read; the reason was logged");
+        });
+        if (remote.length > MaxTools) {
+            throw new IntelError(502, "tool_catalog_too_large", "The portal returned too many tools");
+        }
+        return remote;
+    }
+    /**
+     * The servers the portal says this connection reaches, confirmed against its live tool list.
+     *
+     * ⚠️ Fails rather than answering "none" when the portal keeps no directory. An empty list would
+     * be indistinguishable from "you have no servers", and the difference decides whether a screen
+     * says "connect something" or "this portal cannot be delegated from".
+     */
+    async function serverList(actor, toolNames) {
+        if (!toolNames.includes(ServerDirectoryTool)) {
+            throw new IntelError(502, "tool_servers_unavailable", `The portal does not offer ${ServerDirectoryTool}, so its servers cannot be listed`);
+        }
+        const answer = await deps.remote.call({
+            url: portal(),
+            accessToken: await accessToken(actor),
+            name: ServerDirectoryTool,
+            arguments: {},
+            signal: AbortSignal.timeout(CallTimeoutMs),
+        });
+        const directory = answer.isError ? null : toolServersFrom({ directory: answer, toolNames });
+        if (directory === null) {
+            throw new IntelError(502, "tool_servers_unavailable", "The portal did not answer with a server list this Intel can read");
+        }
+        return directory;
+    }
+    /**
+     * One live tools/list is both the catalog and the authorization answer: the portal only returns
+     * what this user may reach. Nothing here is cached as a permission.
+     */
+    async function capabilities(actor) {
+        const remote = await remoteTools(actor);
+        const items = [];
+        for (const tool of remote) {
+            items.push({
+                ...tool,
+                fingerprint: await deps.fingerprint({
+                    name: tool.name,
+                    inputSchema: tool.inputSchema,
+                    outputSchema: tool.outputSchema,
+                    annotations: tool.annotations,
+                }),
+            });
+        }
+        return items;
+    }
+    async function requireCapability(actor, name) {
+        const found = (await capabilities(actor)).find((capability) => capability.name === name);
+        if (!found) {
+            throw new IntelError(404, "tool_not_available", `Tool ${name} is not available to you`);
+        }
+        return found;
+    }
+    async function call(actor, input) {
+        if (!actor.canExecute) {
+            throw new IntelError(403, "tool_execute_forbidden", "Tool execution permission is required");
+        }
+        const capability = await requireCapability(actor, input.name);
+        const validation = deps.validate(capability.inputSchema, input.arguments);
+        if (!validation.valid) {
+            throw new IntelError(400, "tool_arguments_invalid", validation.detail ?? "Invalid arguments");
+        }
+        const result = await deps.remote.call({
+            url: portal(),
+            accessToken: await accessToken(actor),
+            name: capability.name,
+            arguments: input.arguments,
+            signal: AbortSignal.timeout(CallTimeoutMs),
+        });
+        if (new TextEncoder().encode(JSON.stringify(result)).byteLength > MaxResultBytes) {
+            throw new IntelError(502, "tool_result_too_large", "Tool result exceeded the Intel limit");
+        }
+        return result;
+    }
+    // A token that is gone or beyond renewal is the same answer as never having signed in, so reading
+    // a catalog reports it as a state. Only a portal that does not answer stays an error — the view
+    // has to tell "sign in again" apart from "the portal failed", and a 401 here would otherwise look
+    // like an expired Intel session to the browser.
+    function disconnected(error) {
+        return (error instanceof IntelError &&
+            (error.code === "portal_not_connected" || error.code === "portal_reconnect_required"));
+    }
+    return {
+        async catalog(actor) {
+            const stored = await deps.tokens.read(actor.id);
+            // No portal sign-in yet is a normal state, not an error: the browser answers it by running
+            // the silent sign-in and asking again (#60).
+            if (!stored)
+                return { portalConnected: false, items: [] };
+            try {
+                return { portalConnected: true, items: await capabilities(actor) };
+            }
+            catch (error) {
+                if (disconnected(error))
+                    return { portalConnected: false, items: [] };
+                throw error;
+            }
+        },
+        async servers(actor) {
+            const stored = await deps.tokens.read(actor.id);
+            if (!stored)
+                return { portalConnected: false, items: [] };
+            try {
+                const remote = await remoteTools(actor);
+                const { servers } = await serverList(actor, remote.map((tool) => tool.name));
+                return { portalConnected: true, items: servers };
+            }
+            catch (error) {
+                if (disconnected(error))
+                    return { portalConnected: false, items: [] };
+                throw error;
+            }
+        },
+        execute: async (actor, input) => await call(actor, input),
+        async test(actor, input) {
+            const capability = await requireCapability(actor, input.name);
+            if (capability.annotations.readOnlyHint !== true ||
+                capability.annotations.destructiveHint === true) {
+                throw new IntelError(409, "tool_test_unsafe", "Only explicitly read-only, non-destructive tools can run in the test surface");
+            }
+            return await call(actor, input);
+        },
+    };
+}

package/dist/tools/tools.types.d.ts

@@ -0,0 +1,56 @@
+import type { ExecuteToolInput, TestToolInput, ToolCapability, ToolCatalog, ToolServerCatalog, ToolTestResult } from "../contract/tool.js";
+export interface ToolActor {
+    id: string;
+    email: string;
+    canExecute: boolean;
+}
+export interface PortalToken {
+    accessToken: string;
+    refreshToken: string | null;
+    expiresAt: number;
+    issuer: string;
+    clientId: string;
+    resource: string;
+}
+export interface PortalTokenStore {
+    read(userId: string): Promise<PortalToken | null>;
+    write(userId: string, token: PortalToken): Promise<void>;
+    clear(userId: string): Promise<void>;
+}
+export interface RemoteTool {
+    name: string;
+    title: string | null;
+    description: string | null;
+    inputSchema: Record<string, unknown>;
+    outputSchema: Record<string, unknown> | null;
+    annotations: ToolCapability["annotations"];
+}
+export interface RemoteTools {
+    list(url: string, accessToken: string, signal: AbortSignal): Promise<RemoteTool[]>;
+    call(input: {
+        url: string;
+        accessToken: string;
+        name: string;
+        arguments: Record<string, unknown>;
+        signal: AbortSignal;
+    }): Promise<ToolTestResult>;
+}
+export interface ToolDeps {
+    portalUrl: string | null;
+    remote: RemoteTools;
+    tokens: PortalTokenStore;
+    refresh(token: PortalToken): Promise<PortalToken | null>;
+    now(): Date;
+    fingerprint(value: unknown): Promise<string>;
+    sourceAllowed(url: string): boolean;
+    validate(schema: Record<string, unknown>, value: unknown): {
+        valid: boolean;
+        detail?: string;
+    };
+}
+export interface ToolService {
+    catalog(actor: ToolActor): Promise<ToolCatalog>;
+    servers(actor: ToolActor): Promise<ToolServerCatalog>;
+    execute(actor: ToolActor, input: ExecuteToolInput): Promise<ToolTestResult>;
+    test(actor: ToolActor, input: TestToolInput): Promise<ToolTestResult>;
+}

package/dist/tools/tools.types.js

@@ -0,0 +1 @@
+export {};

package/examples/branding/favicon.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
+  <title>Customer Intel</title>
+  <rect width="32" height="32" rx="8" fill="oklch(0.5 0.18 250)"/>
+  <path d="M10 10h12v12H10zM7 14h3m12 0h3M14 7v3m4-3v3M14 22v3m4-3v3" fill="none" stroke="white" stroke-width="2" stroke-linecap="round"/>
+</svg>

package/examples/branding/logo.svg

@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
+  <title>Customer Intel</title>
+  <rect width="32" height="32" rx="8" fill="oklch(0.5 0.18 250)"/>
+  <path d="M10 10h12v12H10zM7 14h3m12 0h3M14 7v3m4-3v3M14 22v3m4-3v3" fill="none" stroke="white" stroke-width="2" stroke-linecap="round"/>
+</svg>

package/examples/branding/theme.css

@@ -0,0 +1,16 @@
+:root {
+  --radius: 0.75rem;
+  --primary: oklch(0.5 0.18 250);
+  --primary-foreground: oklch(0.98 0.01 250);
+  --sidebar-primary: oklch(0.5 0.18 250);
+  --sidebar-primary-foreground: oklch(0.98 0.01 250);
+  --ring: oklch(0.62 0.14 250);
+}
+
+.dark {
+  --primary: oklch(0.72 0.14 250);
+  --primary-foreground: oklch(0.16 0.03 250);
+  --sidebar-primary: oklch(0.72 0.14 250);
+  --sidebar-primary-foreground: oklch(0.16 0.03 250);
+  --ring: oklch(0.68 0.13 250);
+}

package/examples/dev.vars.example

@@ -0,0 +1,7 @@
+GATE_URL=http://localhost:8787
+INTEL_URL=http://localhost:8788
+MCP_PORTAL_URL=https://portal.example.com/mcp
+TOOL_SOURCE_ORIGINS=https://portal.example.com
+ALLOW_INSECURE_OAUTH=true
+GATE_SERVICE_KEY=replace-with-local-gate-service-key
+INTEL_SESSION_SECRET=replace-with-at-least-32-random-bytes

package/examples/intel.json

@@ -0,0 +1,9 @@
+{
+  "ui": {
+    "theme": "./branding/theme.css",
+    "logo": "./branding/logo.svg",
+    "favicon": "./branding/favicon.svg",
+    "defaultLanguage": "en",
+    "languages": {}
+  }
+}