# Frontend Routes and Pages

Nuxt routes are currently defined through Vue page files in the two layers.

## Current page entry points

### `/`

- Source: `vipr-frontend/layers/reflectometry/app/pages/index.vue`
- Layer: `reflectometry`
- Role: main inference workspace

This page orchestrates the core workflow UI:

- pipeline step configuration
- prediction execution
- results display
- streaming dashboard
- result configuration reloading

It depends heavily on reusable stores and composables from both layers, so it is documented as an application entry point rather than as a standalone API surface.

### `/plugins`

- Source: `vipr-frontend/layers/base/app/pages/plugins.vue`
- Layer: `base`
- Role: plugin management page

This page coordinates:

- plugin listing and refresh
- runtime plugin upload
- enable/disable operations
- deletion and batch operations

It is a good example of a page that consumes generated API clients and reusable UI components, but does not itself define much reusable logic.

## Why pages are documented separately

The current pages are Vue SFC orchestration shells:

- they compose auto-imported stores and composables
- they rely on Nuxt runtime context such as `useNuxtApp`, `useI18n`, and route-driven rendering
- their public contract is the route itself, not a reusable function API

For that reason, the generated frontend reference should focus on reusable TypeScript modules, while page responsibilities stay in hand-written architecture docs.

## Planned route documentation growth

As the frontend grows, this section can be extended with:

- page-level data-flow diagrams
- route ownership per layer
- major store/composable dependencies per page
- cross-links to generated TypeScript reference pages