@adonis-agora/agent/dist/providers/dashboard_provider.d.ts

Governed, durable-backed AI agent (chat + tool-calling + governance) for AdonisJS — part of the Agora ecosystem.

import type { ApplicationService } from '@adonisjs/core/types';
/**
 * Serves the `@adonis-agora/agent-dashboard` governance SPA **from this package's own build** — no
 * separate install, no separate provider registration. `node ace configure @adonis-agora/agent`
 * registers this provider alongside `agent_provider`, and the SPA it serves is bundled straight into
 * `@adonis-agora/agent`'s own `dist/` at build time (`package.json`'s `copy:stubs` copies
 * `../dashboard/dist/spa`, the `@adonis-agora/agent-dashboard` package's `vite build` output, into
 * `dist/assets/spa`) — mirrors `@adonis-agora/durable`'s `dashboard_provider.ts` /
 * `src/dashboard/spa.ts` split, which does the identical thing for its own dashboard.
 *
 * The routing/gating logic here is BYTE-FOR-BYTE the same as `@adonis-agora/agent-dashboard`'s own
 * `agent_dashboard_provider.ts` — both call the SAME shared helpers from `../src/dashboard/index.js`
 * (`decideDashboardMount`, `evaluateDashboardGate`, the path/content-type helpers). The two providers
 * differ only in WHERE they read the built `index.html`/assets from: this one reads its own
 * `dist/assets/spa` (copied in at build time); the standalone provider reads
 * `@adonis-agora/agent-dashboard`'s own `dist/spa`.
 *
 * Why the logic lives HERE rather than in `@adonis-agora/agent-dashboard` (which would let this
 * provider stay a one-line re-export): `@adonis-agora/agent-dashboard` already depends on
 * `@adonis-agora/agent` (its provider imports `AgentConfig`/`ActorResolver`), so a dependency the
 * other way — this package depending on the dashboard package's code at runtime — would be circular,
 * and in this monorepo it would ALSO be a real `turbo`/pnpm build cycle (the dashboard package's own
 * build needs `@adonis-agora/agent` built first, to typecheck its provider against it). Keeping the
 * shared logic in `src/dashboard/` (owned by this package) avoids the cycle exactly the way
 * `@adonis-agora/durable` avoids it — by owning its `spa.ts` serving helpers directly rather than
 * depending on `@adonis-agora/durable-dashboard` for anything but the BUILT ASSET FILES (a
 * build-time-only, one-directional filesystem copy in `copy:stubs`, no package.json dependency at
 * all — see that script for how the dashboard's SPA output is located: a plain relative path,
 * `../dashboard/dist/spa`, resolved by directory layout, not by module resolution).
 *
 * `@adonis-agora/agent-dashboard`'s own provider keeps working entirely unchanged for apps that
 * already install and register it directly (e.g. on an older `@adonis-agora/agent` version, or where
 * an app wants the standalone package's independent versioning/release cadence) — this provider is
 * purely additive. An app that registers BOTH providers with the same mount path will hit AdonisJS's
 * "duplicate route" error at boot; pick one (this is the intended migration signal, not a bug).
 *
 * Routes (mount = `<agentPath>/dashboard`, default `/agent/dashboard`) — identical to the standalone
 * provider's:
 * - `GET <mount>`   → the SPA shell (`index.html`, with the resolved API base + `<base href>` injected)
 * - `GET <mount>/*` → a built asset, or the SPA shell as a fallback (client-rendered console)
 *
 * Nothing mounts unless the agent config carries a `governanceAuthorize` gate: without it the
 * `/agent/governance/*` routes the console reads do not exist, so the console would load and fail on
 * every panel but Quota. The provider declines and logs why (see `decideDashboardMount`).
 *
 * Enable/disable and override the mount via the optional `config('agent').dashboard` block — the SAME
 * block the standalone provider reads.
 */
export default class DashboardProvider {
    #private;
    protected app: ApplicationService;
    constructor(app: ApplicationService);
    boot(): Promise<void>;
}
//# sourceMappingURL=dashboard_provider.d.ts.map