proteum 2.1.2 → 2.1.6

package/docs/dev-commands.md

@@ -67,13 +67,17 @@ In `proteum dev`, the bottom profiler exposes a `Commands` tab.
 - it shows the backing class, method, scope, and source location
 - clicking `Run now` executes the command through the running dev server
 - the last result or error stays attached to that command row in the panel
+- it now adds scope, execution-duration, and status charts over the same command definitions and latest execution snapshots
 
 The profiler also exposes the shared diagnostics surfaces for humans:
 
 - `Explain` renders the same manifest-backed data as `proteum explain`
 - `Doctor` renders the same manifest diagnostics as `proteum doctor`
+- `Diagnose` renders the same owner, suspect, contract, trace-summary, and buffered-log view as `proteum diagnose`
+- `Perf` renders the same hot-path, request-waterfall, compare, and memory views as `proteum perf`
+- the other profiler tabs now add focused visual charts over the same trace, manifest, and dev-runtime contracts instead of only row lists
 
-For the shared diagnostics contract and the corresponding dev HTTP endpoints, see [diagnostics.md](diagnostics.md).
+For the shared diagnostics contract, trace-derived perf contract, and the corresponding dev HTTP endpoints, see [diagnostics.md](diagnostics.md) and [request-tracing.md](request-tracing.md).
 
 ### HTTP Endpoints
 

package/docs/dev-sessions.md

@@ -0,0 +1,90 @@
+# Dev Sessions
+
+Proteum ships a dev-only auth bootstrap command so agents, Playwright runs, and local debugging can start from an authenticated state without driving the login UI.
+
+## When To Use It
+
+Use `proteum session` when:
+
+- a protected page, controller, or manual route must be exercised in dev
+- an LLM agent or browser automation needs an authenticated cookie quickly
+- you want to reproduce role-gated behavior with a known user account
+
+Do not use it when:
+
+- the login or signup flow itself is under test
+- you are validating third-party auth redirects or callback handling
+- you do not know which user should be used for the scenario
+
+## CLI
+
+Local mode:
+
+```bash
+proteum session admin@example.com --role ADMIN
+```
+
+Remote mode against an existing dev server:
+
+```bash
+proteum session admin@example.com --role ADMIN --port 3101
+proteum session god@example.com --role GOD --url http://localhost:3102 --json
+```
+
+Behavior:
+
+- local mode refreshes generated artifacts, builds the dev output, starts a temporary local dev server, creates the session, prints the payload, and exits
+- remote mode talks to an already running `proteum dev` instance
+- the command requires an explicit email and optionally asserts a role before returning the session
+- the command is available only in dev mode
+
+## Output Contract
+
+The JSON payload includes:
+
+- `baseUrl`
+- `user`
+- `session.token`
+- `session.cookieName`
+- `session.issuedAt`
+- `session.expiresAt`
+- `browserCookie`
+- `curlCookieHeader`
+- `playwright.cookies`
+
+Playwright usage:
+
+```ts
+await browserContext.addCookies(output.playwright.cookies);
+```
+
+HTTP usage:
+
+```bash
+curl -H "$(jq -r '.curlCookieHeader' session.json)" http://localhost:3101/api/Auth/CurrentUser
+```
+
+## Agent Guidance
+
+- Prefer `proteum session` over UI login automation when the goal is to test or debug protected application behavior.
+- Use UI login automation only when the auth UX itself is the feature under test.
+- Pair it with `proteum diagnose` for a fast protected-route summary, `proteum perf request` for a one-request timing breakdown, then use `proteum trace` when you need lower-level request events.
+
+Typical flow:
+
+```bash
+proteum trace arm --capture deep --port 3101
+proteum session admin@example.com --role ADMIN --port 3101 --json > session.json
+# add the returned cookie in Playwright, then load the protected page once
+proteum diagnose /dashboard --port 3101
+proteum perf request /dashboard --port 3101
+proteum trace latest --port 3101
+```
+
+## Dev HTTP Endpoint
+
+The CLI uses the same dev-only endpoint exposed by the running app:
+
+- `POST /__proteum/session/start`
+
+This endpoint exists only in dev mode and is not available in production.

package/docs/diagnostics.md

@@ -1,26 +1,31 @@
 # Diagnostics and Explainability
 
-Proteum exposes two manifest-backed diagnostics surfaces:
+Proteum exposes two manifest-backed diagnostics surfaces plus one composite request-diagnosis surface:
 
 - `proteum explain`: inspect the generated app structure
 - `proteum doctor`: inspect manifest diagnostics
+- `proteum diagnose`: combine owner lookup, diagnostics, matching request traces, and buffered server logs for one concrete query or path
 
-These are not separate models for different tools. They share the same generated snapshot and the same diagnostics contract.
+These are not separate models for different tools. `explain` and `doctor` share the same generated manifest snapshot, while `diagnose` layers live dev-only request data on top of that same framework view.
+
+Performance inspection is a sibling surface, not a separate instrumentation stack: `proteum perf` and the profiler `Perf` tab aggregate the same dev-only request traces that back `proteum trace`.
 
 ## Shared Contract
 
 The canonical snapshot lives in `./.proteum/manifest.json`.
 
-Proteum uses that same manifest in four places:
+Proteum uses that same manifest in six places:
 
 - `proteum explain` for human-readable and `--json` output
 - `proteum doctor` for human-readable and `--json` output
-- the dev-only `__proteum/explain` and `__proteum/doctor` HTTP endpoints
-- the `Explain` and `Doctor` tabs in the bottom profiler during `proteum dev`
+- `proteum explain owner <query>` for ownership lookup over the manifest index
+- `proteum doctor --contracts` for generated-artifact and manifest-owned source validation on disk
+- the dev-only `__proteum/explain*` and `__proteum/doctor*` HTTP endpoints
+- the `Explain`, `Doctor`, and `Diagnose` tabs in the bottom profiler during `proteum dev`
 
-This means the CLI, the dev HTTP endpoints, and the profiler all describe the same manifest-backed snapshot.
+This means the CLI, the dev HTTP endpoints, and the profiler all describe the same framework-owned snapshot before any live trace or log overlays are added.
 
-If a command such as `proteum explain`, `proteum doctor`, or `proteum refresh` regenerates `.proteum/manifest.json`, the next CLI call, HTTP call, or profiler refresh will reflect that same updated snapshot.
+If a command such as `proteum explain`, `proteum doctor`, `proteum diagnose`, or `proteum refresh` regenerates `.proteum/manifest.json`, the next CLI call, HTTP call, or profiler refresh will reflect that same updated snapshot.
 
 ## CLI
 
@@ -28,12 +33,23 @@ Common usage:
 
 ```bash
 proteum explain
+proteum explain owner /api/Auth/CurrentUser
 proteum explain --routes --controllers --commands
 proteum explain --all --json
 
 proteum doctor
+proteum doctor --contracts
 proteum doctor --json
 proteum doctor --strict
+
+proteum diagnose /
+proteum diagnose /dashboard --port 3101
+proteum diagnose /api/Auth/CurrentUser --url http://127.0.0.1:3101
+
+proteum perf top --since today
+proteum perf request /dashboard --port 3101
+proteum perf compare --baseline yesterday --target today --group-by route
+proteum perf memory --since 1h --group-by controller
 ```
 
 `proteum explain --json` emits the selected manifest sections as machine-readable JSON.
@@ -45,12 +61,37 @@ proteum doctor --strict
 - `summary.strictFailed`
 - `diagnostics`
 
+`proteum diagnose` emits a composite response with:
+
+- `owner`
+- `doctor`
+- `contracts`
+- `request`
+- `attribution`
+- `suspects`
+- `serverLogs`
+
+`proteum perf` emits trace-derived performance views:
+
+- `top`: grouped hot paths with avg, p95, CPU, SQL, render, and heap deltas
+- `request`: one traced request waterfall with stage timings, CPU, SQL, render, self time, and payload sizes
+- `compare`: grouped baseline vs target deltas
+- `memory`: grouped heap and RSS drift summaries
+
 ## Dev HTTP Endpoints
 
 In `profile: dev`, the running app exposes:
 
 - `GET /__proteum/explain`
+- `GET /__proteum/explain/owner`
 - `GET /__proteum/doctor`
+- `GET /__proteum/doctor/contracts`
+- `GET /__proteum/logs`
+- `GET /__proteum/diagnose`
+- `GET /__proteum/perf/top`
+- `GET /__proteum/perf/compare`
+- `GET /__proteum/perf/memory`
+- `GET /__proteum/perf/request`
 
 `/__proteum/explain` supports optional section selection:
 
@@ -59,12 +100,28 @@ GET /__proteum/explain?sections=routes,controllers,commands
 GET /__proteum/explain?section=env&section=diagnostics
 ```
 
+`/__proteum/explain/owner` supports a single query:
+
+```text
+GET /__proteum/explain/owner?query=/api/Auth/CurrentUser
+```
+
 `/__proteum/doctor` supports optional strict mode:
 
 ```text
 GET /__proteum/doctor?strict=true
 ```
 
+`/__proteum/doctor/contracts` supports the same optional strict mode.
+
+`/__proteum/diagnose` supports a concrete query or request target:
+
+```text
+GET /__proteum/diagnose?query=/dashboard&path=/dashboard
+GET /__proteum/diagnose?requestId=<requestId>
+GET /__proteum/diagnose?query=/api/Auth/CurrentUser&logsLevel=warn&logsLimit=40
+```
+
 These endpoints are intended for local tooling and are not available in production.
 
 ## Profiler
@@ -73,8 +130,11 @@ During `proteum dev`, the bottom profiler is the human-facing UI over the same d
 
 - `Explain` calls `/__proteum/explain`
 - `Doctor` calls `/__proteum/doctor`
+- `Diagnose` calls `/__proteum/diagnose` and renders the same owner, diagnostics, suspect, and log summary that the CLI uses
+- `Perf` calls the `/__proteum/perf/*` endpoints and renders the same grouped rollups and current-request waterfall that `proteum perf` uses, plus visual charts for hot paths, time breakdowns, regression deltas, and memory drift
 - `Commands` uses the dev command endpoints
-- `Auth`, `Timeline`, `Routing`, `Controller`, `SSR`, `API`, and related panels remain request-trace views
+- `Summary`, `Auth`, `Routing`, `Controller`, `SSR`, `API`, `SQL`, `Errors`, `Diagnose`, `Explain`, `Doctor`, `Commands`, and `Cron` now layer focused charts over the same trace and diagnostics contracts instead of only showing rows
+- `Timeline` remains the primary waterfall and event-stream inspection surface
 
 Use the profiler when a human needs to browse the same data that an agent or CLI command can already inspect directly.
 
@@ -83,6 +143,9 @@ Use the profiler when a human needs to browse the same data that an agent or CLI
 For AI coding agents or automation:
 
 1. Read `./.proteum/manifest.json` or run `proteum explain --json`.
-2. Run `proteum doctor --json` to inspect framework diagnostics.
-3. For request-time behavior, use `proteum trace ...` because traces are live runtime data, not manifest snapshots.
-4. Open the profiler only when a human-readable view helps; it should agree with the CLI after refresh.
+2. Run `proteum doctor --json` and `proteum doctor --contracts --json` to inspect framework and generated-artifact diagnostics.
+3. Run `proteum explain owner <query>` when you need to map a route, controller path, or generated artifact back to source.
+4. For concrete request-time behavior, start with `proteum diagnose <path> --port <port>`.
+5. For performance, CPU, SQL, render, or memory questions, use `proteum perf top|request|compare|memory` against the same running dev server.
+6. Use `proteum trace ...` when you need lower-level event detail than `diagnose` or `perf` provides.
+7. Open the profiler only when a human-readable view helps; it should agree with the CLI after refresh.

package/docs/request-tracing.md

@@ -1,12 +1,12 @@
 # Request Tracing
 
-Proteum ships with a dev-only in-memory request trace buffer so routing, controller execution, SSR, and render behavior can be inspected without attaching a debugger or scattering temporary logs through the runtime.
+Proteum ships with a dev-only in-memory request trace buffer so routing, controller execution, SSR, API, Prisma SQL, render behavior, and request-time performance can be inspected without attaching a debugger or scattering temporary logs through the runtime.
 
 ## Scope
 
 - tracing is available only when the app runs with `profile: dev`
-- traces are exposed through `proteum trace` and the dev-only `__proteum/trace` HTTP endpoints
-- explain/doctor are separate manifest-backed diagnostics surfaces; see [diagnostics.md](diagnostics.md)
+- traces are exposed through `proteum trace`, `proteum perf`, and the dev-only `__proteum/trace` and `__proteum/perf` HTTP endpoints
+- `proteum diagnose` is a separate composite surface that reads the same framework diagnostics plus one matching request trace and buffered server logs; see [diagnostics.md](diagnostics.md)
 - production requests are not traced by this feature
 
 ## Main Commands
@@ -18,6 +18,11 @@ proteum trace show <requestId>
 proteum trace arm --capture deep
 proteum trace export <requestId>
 proteum trace latest --url http://127.0.0.1:3010
+
+proteum perf top --since today
+proteum perf request /dashboard --port 3103
+proteum perf compare --baseline yesterday --target today --group-by route
+proteum perf memory --since 1h --group-by controller
 ```
 
 Before reproducing a bug or starting a new test pass:
@@ -37,6 +42,19 @@ proteum trace show <requestId> --port 3103
 
 Use `--url http://host:port` when the dev server is reachable on a non-standard host and `--port` is not enough.
 
+If the request under test is protected and login UX is not the feature under test, mint an auth cookie with `proteum session <email> --role <role>` before reproducing the request. This keeps the trace focused on the protected behavior instead of the login flow.
+
+If you already know the failing path and want a one-shot suspect list before reading raw events, start with `proteum diagnose <path> --port <port>` and drop into `proteum trace show <requestId>` only when the lower-level event stream is still needed.
+
+Trace summaries include `sql=<count>`. Detailed trace output includes both a `Calls` section for API/fetcher activity and a `SQL` section for captured Prisma queries.
+
+`proteum perf` is a grouped view over the same trace store:
+
+- `top` ranks routes, concrete paths, or controllers by avg, p95, CPU, SQL, render, self time, and heap delta
+- `request` shows one traced request waterfall with stage timings plus the hottest calls and SQL
+- `compare` shows baseline-vs-target regressions between trace windows such as `yesterday` and `today`
+- `memory` shows grouped heap and RSS drift trends
+
 ## What Gets Recorded
 
 Depending on capture mode, traces can include:
@@ -46,12 +64,29 @@ Depending on capture mode, traces can include:
 - direct controller route matches
 - route resolution start, match, and deep-mode skip reasons
 - controller start and result shape
+- synchronous SSR fetcher calls, API batch fetchers, and async request traces
+- Prisma SQL queries with caller method/path, optional fetcher attribution, SQL text, params, kind, operation, and timing
 - created router/context keys
 - setup output keys and page data summaries
 - SSR payload shape and serialized byte size
 - render start/end timings and document output sizes
+- per-request CPU usage deltas plus heap and RSS snapshots before and after the request
 - normalized request errors
 
+## SQL Tracing
+
+Prisma query tracing covers both ORM operations and raw queries.
+
+- `kind` is recorded as `orm` or `raw`
+- `operation` records the Prisma operation such as `findFirst`, `count`, or `$queryRawUnsafe`
+- `model` is recorded when Prisma exposes one
+- `callerMethod` and `callerPath` attach the query to the request that triggered it
+- when the query runs inside an SSR fetcher or an API batch fetcher, the trace also records the fetcher id/label and call id
+- `durationMs`, `startedAt`, and `finishedAt` come from Prisma query events
+- `query`, `paramsText`, and parsed `paramsJson` are stored for inspection
+
+This currently covers SQL issued through Proteum's Prisma service, including raw helpers that flow through the same Prisma client.
+
 ## Capture Modes
 
 - `summary`: smallest capture, focused on request lifecycle and high-signal events
@@ -64,8 +99,16 @@ Use `deep` selectively. It is for one-off investigation, not continuous capture.
 
 During `proteum dev`, the bottom profiler renders the same live request traces.
 
+- `Summary` charts recent duration, workload, route frequency, and status trends for the captured sessions
 - `Timeline` shows the full request event stream
 - `Auth` filters the selected session down to auth-specific events so matched rules, tracking, and allow/deny outcomes can be inspected without scanning unrelated events
+- `Routing`, `Controller`, and `SSR` add focused charts over resolve, controller lifecycle, render, and payload data for the selected trace
+- `API` shows synchronous SSR/API fetcher calls plus async requests, with workload and status charts above the waterfall
+- `SQL` shows captured Prisma queries grouped by caller, with workload, operation, and heatmap charts plus a waterfall and detail sidebar
+- `Errors` adds grouped source and error-family charts over the captured failures
+- `Diagnose` combines the selected request summary with explain/doctor/contracts data and buffered server logs, plus visual suspect, owner, and severity charts
+- `Explain`, `Doctor`, `Commands`, and `Cron` render the same manifest and dev-runtime contracts as their CLI surfaces with matching summary charts
+- `Perf` renders the same top, request, compare, and memory rollups exposed by `proteum perf`, with visual charts for hot-path latency, time composition, regressions, and memory drift
 - expanding an auth event shows the summarized detail payload exactly as stored in the trace
 
 ## Configuration
@@ -128,5 +171,9 @@ These endpoints back the CLI:
 - `GET /__proteum/trace/latest`
 - `GET /__proteum/trace/requests/:id`
 - `POST /__proteum/trace/arm`
+- `GET /__proteum/perf/top`
+- `GET /__proteum/perf/compare`
+- `GET /__proteum/perf/memory`
+- `GET /__proteum/perf/request`
 
 The CLI should be the primary interface. Use the HTTP endpoints when you need direct machine access from another local dev tool.

package/package.json

@@ -1,7 +1,7 @@
 {
 	"name": "proteum",
 	"description": "LLM-first Opinionated Typescript Framework for web applications.",
-	"version": "2.1.2",
+	"version": "2.1.6",
 	"author": "Gaetan Le Gac (https://github.com/gaetanlegac)",
 	"repository": "git://github.com/gaetanlegac/proteum.git",
 	"license": "MIT",

package/server/app/container/config.ts

@@ -7,11 +7,9 @@
         Because it's imported by the CLI, which should be independant of the app escept for loading config
 */
 
-// Npm
-import fs from 'fs-extra';
-import yaml from 'yaml';
-
 // Types
+import type { TApplicationIdentityConfig, TApplicationSetupConfig } from '../../../common/applicationConfig';
+import { loadApplicationIdentityConfig, loadApplicationSetupConfig } from '../../../common/applicationConfigLoader';
 import { parseProteumEnvConfig, type TProteumLoadedEnvConfig } from '../../../common/env/proteumEnv';
 
 declare const PROTEUM_PORT_OVERRIDE: number | null;
@@ -27,6 +25,7 @@ declare global {
 
         type Env = TEnvConfig;
         type Identity = AppIdentityConfig;
+        type Setup = AppSetupConfig;
         interface Services {}
     }
 }
@@ -34,31 +33,10 @@ declare global {
 export type TEnvName = TEnvConfig['name'];
 export type TEnvConfig = TProteumLoadedEnvConfig;
 
-type AppIdentityConfig = {
-    name: string;
-    identifier: string;
-    description: string;
-    author: { name: string; url: string; email: string };
-
-    social: {};
-
-    locale: string;
-    language: string;
-    maincolor: string;
-    iconsPack?: string;
-
-    web: {
-        title: string;
-        titleSuffix: string;
-        fullTitle: string;
-        description: string;
-        version: string;
-        metas?: { [name: string]: string };
-        jsonld?: { [name: string]: string };
-    };
-};
+type AppIdentityConfig = TApplicationIdentityConfig;
+type AppSetupConfig = TApplicationSetupConfig;
 
-export type AppConfig = { env: Config.Env; identity: Config.Identity };
+export type AppConfig = { env: Config.Env; identity: Config.Identity; setup: Config.Setup };
 
 const debug = false;
 
@@ -77,78 +55,29 @@ export default class ConfigParser {
         public envName?: string,
     ) {}
 
-    private loadYaml(filepath: string) {
-        debug && console.info(`Loading config ${filepath}`);
-        const rawConfig = fs.readFileSync(filepath, 'utf-8');
-        return yaml.parse(rawConfig);
-    }
-
     public env(): TEnvConfig {
         debug && console.info('[app] Loading Proteum env vars from process.env');
+        const setup = this.setup();
 
         return {
             ...parseProteumEnvConfig({
                 appDir: this.appDir,
+                connectedProjects: setup.connect,
                 routerPortOverride: getRouterPortOverride(),
             }),
             version: BUILD_DATE,
         };
     }
 
-    public identity() {
-        const identityFile = this.appDir + '/identity.yaml';
+    public identity(): Config.Identity {
+        const identityFile = this.appDir + '/identity.config.ts';
         debug && console.info(`Loading identity ${identityFile}`);
-        return this.loadYaml(identityFile);
+        return loadApplicationIdentityConfig(this.appDir);
     }
-}
-
-/*const walkYaml = (dir: string, configA: any, envName: string) => {
-
-    const files = fs.readdirSync(dir);
-    for (const file of files) {
-
-        const fullpath = dir + '/' + file;
-
-        // extension .yaml
-        const isDir = fs.lstatSync(fullpath).isDirectory();
-        let key = file;
-        if (!isDir) {
-
-            if (!file.endsWith('.yaml'))
-                continue;
-
-            key = key.substring(0, key.length - 5);
-
-        }
-
-        let fileConfig = configA;
-
-        // Ciblage environnement
-        // Before: /config/services/env.<envName>.yaml
-        // After: /config/services
-        if (key.startsWith('env.')) {
-
-            // Excluding not mtching env name
-            if (key.substring(4) !== envName)
-                continue;
-
-        // Créé l'entrée dans la config, sauf si le nom du fichier est default
-        } else if (key !== 'default') {
-
-            // Init config
-            if (!(key in fileConfig))
-                fileConfig[key] = {};
-
-            fileConfig = configA[key];
-
-        }
-
-        // Recursion
-        if (isDir)
-            walk(fullpath, fileConfig, envName);
-        // Lecture fichier
-        else
-            deepExtend(fileConfig, loadYaml(fullpath));
 
+    public setup(): Config.Setup {
+        const setupFile = this.appDir + '/proteum.config.ts';
+        debug && console.info(`Loading setup ${setupFile}`);
+        return loadApplicationSetupConfig(this.appDir);
     }
-}*/
+}

package/server/app/container/console/index.ts

@@ -16,7 +16,9 @@ import Ansi2Html from 'ansi-to-html';
 // Core libs
 import type ApplicationContainer from '..';
 import context from '@server/context';
+import type { TDevConsoleLogChannel, TDevConsoleLogEntry, TDevConsoleLogLevel } from '@common/dev/console';
 import type { ServerBug, TCatchedError } from '@common/errors';
+import type { TTraceCallOrigin, TTraceSqlQueryKind } from '@common/dev/requestTrace';
 import type ServerRequest from '@server/services/router/request';
 
 /*----------------------------------
@@ -36,14 +38,9 @@ export type Services = {};
 - TYPES
 ----------------------------------*/
 
-export type ChannelInfos = {
-    channelType: 'cron' | 'master' | 'request' | 'socket';
-    channelId?: string;
-
-    method?: string;
-    path?: string;
-
-    user?: string;
+export type ChannelInfos = TDevConsoleLogChannel & {
+    traceCallOrigin?: TTraceCallOrigin;
+    prismaOperations?: Array<{ kind: TTraceSqlQueryKind; model?: string; operation: string }>;
 };
 
 export type TGuestLogs = {
@@ -233,6 +230,43 @@ export default class Console {
         return logLevels[logLevelName];
     }
 
+    private serializeLogChannel(channel: ChannelInfos): TDevConsoleLogChannel {
+        return {
+            channelType: channel.channelType,
+            ...(typeof channel.channelId === 'string' ? { channelId: channel.channelId } : {}),
+            ...(typeof channel.method === 'string' ? { method: channel.method } : {}),
+            ...(typeof channel.path === 'string' ? { path: channel.path } : {}),
+            ...(typeof channel.user === 'string' ? { user: channel.user } : {}),
+            ...(typeof channel.traceCallId === 'string' ? { traceCallId: channel.traceCallId } : {}),
+            ...(typeof channel.traceCallOrigin === 'string' ? { traceCallOrigin: channel.traceCallOrigin } : {}),
+            ...(typeof channel.traceCallLabel === 'string' ? { traceCallLabel: channel.traceCallLabel } : {}),
+            ...(typeof channel.traceCallFetcherId === 'string' ? { traceCallFetcherId: channel.traceCallFetcherId } : {}),
+            ...(Array.isArray(channel.prismaOperations)
+                ? {
+                      prismaOperations: channel.prismaOperations.map((operation) => ({
+                          kind: operation.kind,
+                          ...(typeof operation.model === 'string' ? { model: operation.model } : {}),
+                          operation: operation.operation,
+                      })),
+                  }
+                : {}),
+        };
+    }
+
+    public listLogs(limit = 100, minimumLevel: TDevConsoleLogLevel = 'log'): TDevConsoleLogEntry[] {
+        const minimumLogLevel = logLevels[minimumLevel];
+
+        return this.logs
+            .filter((entry) => logLevels[entry.level] >= minimumLogLevel)
+            .slice(-Math.max(0, limit))
+            .map((entry) => ({
+                channel: this.serializeLogChannel(entry.channel),
+                level: entry.level,
+                text: formatWithOptions({ breakLength: 120, colors: false, depth: 3 }, ...entry.args),
+                time: entry.time.toISOString(),
+            }));
+    }
+
     private clean() {
         if (this.config.debug) {
             console.log(

package/server/app/container/index.ts

@@ -29,6 +29,7 @@ export class ApplicationContainer<TServicesIndex extends StartedServicesIndex =
     public Services = Services as ServicesContainer<TServicesIndex>;
     public Environment: TEnvConfig;
     public Identity: Config.Identity;
+    public Setup: Config.Setup;
     public Console: Console;
     public Trace: Trace;
 
@@ -53,7 +54,8 @@ export class ApplicationContainer<TServicesIndex extends StartedServicesIndex =
         const configParser = new ConfigParser(this.path.root);
         this.Environment = configParser.env();
         this.Identity = configParser.identity();
-        this.Console = new Console(this, defaultConsoleConfig);
+        this.Setup = configParser.setup();
+        this.Console = new Console(this, { ...defaultConsoleConfig, enable: this.Environment.profile === 'dev' });
         this.Trace = new Trace(this, this.Environment.trace);
     }