Skip to content

docs: record no-build dashboard direction #35

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
typelicious wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: record no-build dashboard direction #35

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,17 @@ If every configured provider API key is empty, FoundryGate still starts, but it
- [Troubleshooting](./docs/TROUBLESHOOTING.md)
- [Roadmap](./docs/FOUNDRYGATE-ROADMAP.md)

## Dashboard Direction

The built-in dashboard stays intentionally no-build for now.

- no frontend framework
- no component library
- no separate asset pipeline
- one self-contained operational UI served by the FastAPI app

That keeps deployment simple for local hosts, Docker, and systemd installs while the dashboard remains an operator-facing read-heavy surface.

## How It Works

```text
Expand Down
9 changes: 9 additions & 0 deletions docs/ARCHITECTURE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,6 +103,15 @@ The main operational endpoints are:

`/api/stats`, `/api/recent`, and `/api/traces` can now be filtered by provider, client profile, client tag, layer, and success state. The dashboard is a thin UI over those same filtered endpoints and persists its active filters in the URL so operators can share one filtered view.

The dashboard remains intentionally no-build for now:

- no frontend framework runtime
- no component library dependency
- no separate JS build pipeline
- one self-contained operator UI shipped with the gateway

That is deliberate. The current goal is operational clarity and portability, not a second product surface that adds frontend tooling, bundle management, and extra deployment steps.

## Design target

The longer-term design target is to outperform simpler router designs by making routing multi-dimensional instead of mostly keyword- or model-name-driven.
Expand Down
8 changes: 7 additions & 1 deletion docs/FOUNDRYGATE-ROADMAP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -206,7 +206,9 @@ Primary goals:
- expand the release-check baseline into stronger update alerts so operators can see when a newer release is available
- add an optional automatic update enabler for controlled deployments
- improve route traces, metrics, and dashboard filters for providers, clients, and profiles
- keep the dashboard simple, read-heavy, and operationally safe
- keep the dashboard simple, read-heavy, operationally safe, and intentionally no-build

Until the dashboard clearly needs to become a broader operator application, FoundryGate should avoid adding a frontend framework, a component-library dependency, or a separate web build pipeline.

This release line is about day-2 operations rather than new routing concepts.

Expand Down Expand Up @@ -315,6 +317,10 @@ Examples:
- provider health panel with capabilities and contract type
- quick links to dry-run routing and recent failure context

Constraint:

- keep the dashboard self-contained and no-build until there is a concrete operator need that justifies a real frontend stack

### 4. Image generation and editing routing

Why:
Expand Down
Loading