> ## Documentation Index
> Fetch the complete documentation index at: https://prism.ntecdev.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations Console

> The Prism Administrative Console — one mode-aware interface for Local, LAN, and Cloud installs. Covers scope, auth, and all shipped console sections.

# Operations Console

The Operations Console is the administrative interface built into every Prism install. It is a single application that adapts to your deployment mode: **Local**, **LAN**, or **Cloud**.

The console reads `PRISM_MODE` at runtime and renders your authorized scope. You always see everything within your scope — nothing more, nothing less.

## Access

Navigate to `/console` in your browser after the dashboard is running.

| Mode  | URL                                             |
| ----- | ----------------------------------------------- |
| Local | `http://127.0.0.1:<dashboard_port>/console`     |
| LAN   | `http://<server_host>:<dashboard_port>/console` |
| Cloud | Your Prism Cloud URL + `/console`               |

Authentication is mode-specific: Local and LAN installs use the Prism bootstrap admin key; Cloud installs use WorkOS AuthKit. The auth seam is transparent — the console always receives a normalized `ConsoleAuthContext` regardless of how identity was resolved.

## Scope model

Your scope depends on your mode and role:

| Mode + role              | Scope                                                  |
| ------------------------ | ------------------------------------------------------ |
| Local                    | Your single install                                    |
| LAN                      | Your LAN install and all teammate accounts you invited |
| Cloud — collaborator     | Your assigned tenant                                   |
| Cloud — system superuser | The full multi-tenant system                           |

Navigation sections are gated by capabilities derived from your role. Locked sections are visible but non-interactive — your role determines what you can open, not what you can see.

## Overview

`/console` — the landing page. Shows a card for each console section within your authorized scope. Locked sections are shown with a visual indicator. Use this as the entry point to navigate to any function.

## Hierarchy

`/console/hierarchy` — manage the `Tenant → Org → Department → Project` structure within your scope.

| Level      | Read                                       | Create                                                    |
| ---------- | ------------------------------------------ | --------------------------------------------------------- |
| Tenant     | Always shown (bootstrap-seeded, read-only) | Not from the console                                      |
| Org        | List view                                  | Create via name field; slug auto-derived                  |
| Department | List view under each org                   | Create within an org                                      |
| Project    | Listed per department                      | Read-only here; use `prism create` or `bootstrap_project` |

**Capability gate:** `org.write`. Members without this capability see the section locked.

Create forms surface errors inline: `400 invalid name`, `404 parent not found`, `409 slug conflict`. The read side (full tree view) ships in a follow-on lane — until then the tree shows an "unavailable" notice but create still works against live API.

## Routing Rules

`/console/routing-rules` — view and manage [FQAI signal routing rules](/specs/spec-125-v0-1-fqai-signal-routing-rule-schema-and-evaluation-model).

Routing rules control how signals are dispatched across the `tenant:org:dept:project:agent` address space. Each rule has a pattern, a priority, an action, and an optional note.

**Reading the pattern table:** each rule shows its FQAI pattern broken into five labeled segments — tenant, org, dept, project, agent. Wildcard (`*`) segments are styled differently so you can read the scope at a glance without parsing the raw string. Higher priority wins when multiple rules match.

**Operations available:**

| Operation                     | Who can do it                        |
| ----------------------------- | ------------------------------------ |
| View all rules                | Any authenticated user               |
| Create a rule                 | `routing.write` capability, or owner |
| Edit priority / note / action | `routing.write` capability, or owner |
| Delete a rule                 | `routing.write` capability, or owner |

The backend enforces the role gate server-side; the UI reflects it by gating the create button and inline edit controls.

## Updates

`/console/updates` — check for new Prism versions.

The Prism repo is private, so the release check is mediated by the backend (`/console/updates` endpoint). The page surfaces the current version, latest available version, a changelog excerpt, and a link to the GitHub release.

**States:**

| State             | What you see                                                                                                                                       |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Up to date        | Green indicator, current version confirmed                                                                                                         |
| Update available  | Version diff, changelog, release link                                                                                                              |
| Check unavailable | Informational notice — the `/console/updates` endpoint is not live yet (ships in a follow-on lane). The page lights up automatically once it does. |

No automatic update or download is triggered from this page. Updates are operator-initiated via `prism_upgrade_lan` or manual deploy.

## Invites

`/console/invites` — invite teammates or collaborators.

The invite surface wires to three flows depending on mode:

| Mode  | Flow                                                                   |
| ----- | ---------------------------------------------------------------------- |
| Local | Informational only — no one to invite on a single-machine install      |
| LAN   | Invite a teammate onto this install (LAN teammate invite/join, Lane C) |
| Cloud | Invite a collaborator to a tenant                                      |

**Status:** The create + accept flows are actively being implemented (Lane C). The page is present in the console now and lights up as each flow ships.

## Backup & Archive

`/console/backups` — export a logical snapshot of tenant data or permanently archive a tenant. The page has two sections with different role gates.

### Backup

**Gate:** admin or owner role.

Exports orgs, departments, projects, personas, and memberships as gzip-compressed JSON. Scope is strictly tenant-isolated — no cross-tenant data is included.

**Destination:** `Local disk` (default). S3 is listed in the picker but not yet wired.

After a successful backup the result shows: timestamp, destination path on disk, total size, and a row count per table.

### Archive

**Gate:** owner only. **Irreversible.**

Archive runs a final backup then stamps `archived_at` on the tenant, sealing its lifecycle state. This cannot be undone without operator intervention.

A confirmation checkbox gates the Archive button — you must explicitly confirm the tenant name before the button activates. The page shows the warning banner and the exact tenant name so there is no ambiguity about scope.

**Error states:**

* `409` — tenant is already archived (idempotent conflict, not a failure).
* Other errors surface inline.

### Restore

`POST /console/tenant-restore` is live (SPEC-117 A8, PR #469). The UI surface for restore lands in v0.1.1.

## Agent Team

`/console/agents` — seed a default agent team for a project in one operation.

**Capability gate:** admin or owner role. Members see the section locked.

Pick a template, supply the target project PID, name each seat, and submit. The backend creates one persona per slot and returns a per-seat result.

### Templates

| Template | Seats | Slots included                                                                                        |
| -------- | ----- | ----------------------------------------------------------------------------------------------------- |
| Minimal  | 3     | Engineering, Docs, Release                                                                            |
| Default  | 5     | Engineering, Docs, Release, Governance, Install                                                       |
| Full     | 9     | Engineering, Docs, Release, Governance, Install, Security, Architecture, Product Owner, Customer Care |

Each slot carries a canonical role that the backend writes onto the created persona. You supply the identity name (free text) for each seat; the slot determines the role.

### Idempotency

Preseed is safe to run more than once. If a persona with the same identity already exists in the project, that seat is **skipped** — not overwritten, not errored. Skipped seats appear in the result alongside created seats so you can see exactly what happened.

### Result

After a successful preseed the page shows:

* Template used and target PID
* **Created** — slot, identity, and canonical role for each new persona
* **Skipped** — slot, identity, and reason for each seat that already existed

Errors surface inline. The operation is all-or-nothing except for the idempotent skip path — a non-"already exists" error on any seat aborts the whole preseed.

## Reference

* [SPEC-117](/specs/spec-117) — Administrative Console specification
* [SPEC-125](/specs/spec-125-v0-1-fqai-signal-routing-rule-schema-and-evaluation-model) — FQAI routing rule schema and evaluation model
* [SPEC-089](/specs/spec-089) — Auth strategy (bootstrap key / WorkOS seam)