feat: update manual and UI components to reflect changes in roles and tabs, add mechanisms component for policy management

Author: stephenwhitmarsh

MANUAL.md

@@ -3,13 +3,16 @@
 ## The app, tab by tab
 The app is a set of tabs across the top, each with its own audience and job. Which tabs appear depends on the role you are viewing as. The [policy](POLICY.md) sets out the allocation model behind the controls.
 
-A **Viewing as** switcher in the header sets the current role, since the proof of concept has no real sign-in. There are four roles, each with a coloured chip. A viewer sees everything and changes nothing. A project lead plans and books for the projects they run, raising requests and holding their own reservations. A team lead divides their team's pool across its projects and raises requests across the team. Operations sets the policy, sizes the pools, configures the connectors, approves requests, and is the only role that writes to the scheduler. Operations sees every tab and lands on Analytics. The other roles land on My view, and the app hides the operations-only tabs from them.
+A **Viewing as** switcher in the header sets the current role, since the proof of concept has no real sign-in. There are four roles, each with a coloured chip. A viewer sees everything and changes nothing. A project lead plans and books for the projects they run, raising requests and holding their own reservations. A team lead divides their team's pool across its projects and raises requests across the team. Operations sets the policy, sizes the pools, configures the connectors, approves requests, and is the only role that writes to the scheduler. Operations sees every tab and lands on the Overview. The other roles land on My view, and the app hides the operations-only tabs from them.
+
+### Overview
+The tab operations and direction land on. Operational tiles and a short list of what needs attention sit at the top, each tile linking to the tab behind it. Below, the app computes the longer-run indicators per period from the jobs themselves and charts them past and forecast over a configurable horizon, with policy changes marked on the trend. A resource outlook frames the acquisition decision, setting realised demand and committed entitlement against capacity, with a runway to the threshold.
 
 ### My view
 A person's own projects and jobs. Tiles across the top count the projects they are on, the GPUs their running jobs hold, how many jobs are queued, and their wait times. The Projects table shows each project's budget, use and budget status, with a role chip marking the ones they lead. Where the project's team is at a phase that does not enforce that budget, the status reads "target only", since the number is a target rather than a cap there. An "Only mine" toggle is on by default. Below, the Jobs table lists what is running and queued, with wait times per lane when priced lanes are on.
 
 ### Team
-For team leads and operations. Operations see a Policy card that sets the roll-out phase for this one team, ahead of or behind the organisation default, with the mechanisms it turns on shown as chips. Operations also see a Team pool card that sizes this team's pool within the total the teams share. The team lead sees Distribution across projects, splitting the pool across active projects, each allocation capped so the running total never exceeds the pool. Every change here is staged and applied explicitly.
+For team leads and operations. A Policy card shows the mechanisms in force for the team as read-only switches, the same set the Policy tab carries. Operations additionally set the team's roll-out phase here, ahead of or behind the organisation default. The team lead sees Distribution across projects, splitting the team pool across active projects, each allocation capped so the running total never exceeds the pool. The size of the team pool itself is set by operations on the Budgets tab. Every change here is staged and applied explicitly.
 
 ### Queue
 The live picture of jobs waiting to run and the order they will run in, which is what the allocation policies shape. Where cross-team standing is on, the ordering reflects each team's standing.
@@ -21,19 +24,16 @@ The load on the cluster over time, built from individual jobs the way it comes f
 The register of team projects, one row each with its team, start, budget, consumed, a pace bar against an even spend, and a budget outlook. As in My view, a project whose team does not enforce project budgets reads "target only". Viewers get an "Only mine" default, and a toggle folds finished projects in. Selecting a row opens the full record: the leads to contact, the members, and the recent jobs.
 
 ### Budgets
-The two pools and how they are divided. A bar at the top shows committed budgets against the capacity the cluster offers over the period, with an uncommitted tail below full or an over-committed overflow past it. The Team pools section lists each team's share, with its phase where that differs from the default, and the projects inside each. The Person pool section shows each person's equal allowance, their use against it, and the gap.
+The two pools and how they are divided. A bar at the top shows committed budgets against the capacity the cluster offers over the period, with an uncommitted tail below full or an over-committed overflow past it. The Team pools section lists each team's share of the teams pool, with its phase where that differs from the default, and the projects inside each. Operations size each team's pool here, capped so the running total stays within the teams pool, with the remainder left unallocated. Team leads then split each pool across projects on the Team tab. The Person pool section shows each person's equal allowance, their use against it, and the gap.
 
 ### Directory
 People, teams and projects as imported from Notion, browsable by person, team or project. This is where operations checks the imported structure against Notion and keeps it in step.
 
 ### Requests
 A short form raises a change: a new project, a change to a project's or a team's budget, a priority change, an extension, or a reservation. Each type routes to the right approver, and a person sees an approve or decline control only on the requests that are theirs. The board shows only the people involved. A planner charts the demand that granting the pending requests would add on top of the forecast baseline, against capacity, so a request that would push demand past the hardware shows before approval.
 
-### Analytics
-For operations and direction. The operations overview sits at the top: the operational tiles and a short list of what needs attention. Below, the app computes the longer-run indicators per period from the jobs themselves and charts them past and forecast over a configurable horizon, with policy changes marked on the trend. A resource outlook frames the acquisition decision, setting realised demand and committed entitlement against capacity, with a runway to the threshold.
-
 ### Policy
-Operations only: the mechanisms and values that drive allocation. The mechanisms are switches for whether budgets are enforced at the person, project and team level, whether priced lanes and time-of-use weighting apply, and whether teams carry standing between one another. The values are the numbers behind them: the person pool's share of capacity, the over-subscription factor, the lane prices, and the priority weights. Selecting a roll-out phase loads its preset, which operations can then adjust. Changes stay staged and take effect only on apply, when the app writes them to the scheduler and shows the commands.
+Visible to everyone and read-only for all but operations: the mechanisms and values that drive allocation. The mechanisms are switches for whether budgets are enforced at the person, project and team level, whether priced lanes and time-of-use weighting apply, and whether teams carry standing between one another. The values are the numbers behind them: the person pool's share of capacity, the over-subscription factor, the lane prices, and the priority weights. Selecting a roll-out phase loads its preset, which operations can then adjust. Changes stay staged and take effect only on apply, when the app writes them to the scheduler and shows the commands.
 
 ### Connectors
 Operations only: the systems the app reads from and writes to. SLURM is the scheduler it reads use from and writes budgets and reservations to. Notion supplies people and projects. Slack carries approvals, reminders and budget alerts, with email as a fallback. Single sign-on supplies identity, and object storage holds exports. Operations enables and configures each here.

frontend/src/App.jsx

@@ -17,6 +17,7 @@ import { period, leads, opsPeople, members, projectLeads, projectsLedBy, project
 import { SessionProvider, useSession, actorFor, RoleChip } from './session.jsx'
 
 const TABS = [
+  { id: 'analytics', label: 'Overview', component: Analytics, opsOnly: true },
   { id: 'me', label: 'My view', component: Me },
   { id: 'team', label: 'Team', component: Team, teamRole: true },
   { id: 'queue', label: 'Queue', component: Queue },
@@ -25,12 +26,11 @@ const TABS = [
   { id: 'budgets', label: 'Budgets', component: Budgets },
   { id: 'people', label: 'Directory', component: People },
   { id: 'requests', label: 'Requests', component: Requests },
-  { id: 'analytics', label: 'Analytics', component: Analytics, opsOnly: true },
-  { id: 'policy', label: 'Policy', component: PolicyParameters, opsOnly: true },
+  { id: 'policy', label: 'Policy', component: PolicyParameters },
   { id: 'connectors', label: 'Connectors', component: Connectors, opsOnly: true },
 ]
 
-// where each role lands by default: ops on Analytics, everyone else on My view
+// where each role lands by default: ops on the Overview, everyone else on My view
 const defaultTabFor = (role) => (role === 'ops' ? 'analytics' : 'me')
 
 // every demo actor (bar the anonymous viewer and ops) takes part in an active project,

frontend/src/components/Mechanisms.jsx

@@ -0,0 +1,32 @@
+// The allocation mechanisms as labelled on/off toggle rows, in one place so the
+// Policy tab (editable by operations) and the Team tab (read-only, reflecting
+// the team's phase) show the same switches. Pass onToggle to make them editable.
+import Toggle from './Toggle.jsx'
+
+const ROWS = [
+  ['enfPerson', 'Person budgets', 'cap each person at their budget'],
+  ['enfProject', 'Project budgets', 'cap each project at its budget'],
+  ['enfTeam', 'Team budgets', 'cap each team pool'],
+  ['lanes', 'Priced urgency (lanes)', 'fast and bulk lanes available to jobs'],
+  ['timeOfUse', 'Time-of-use weighting', 'office/off-hours weight on budget drawn'],
+  ['teamStanding', 'Cross-team standing', 'team-level standing in the queue'],
+]
+
+export default function Mechanisms({ flags = {}, editable = false, onToggle }) {
+  return (
+    <table className="data">
+      <tbody>
+        {ROWS.map(([k, name, note]) => (
+          <tr key={k}>
+            <td style={{ width: '26%' }}>{name}</td>
+            <td style={{ color: 'var(--ink-2)' }}>{note}</td>
+            <td style={{ width: 60, textAlign: 'right' }}>
+              <Toggle checked={!!flags[k]} label={name} disabled={!editable}
+                onChange={(v) => editable && onToggle && onToggle(k, v)} />
+            </td>
+          </tr>
+        ))}
+      </tbody>
+    </table>
+  )
+}

frontend/src/views/Analytics.jsx

@@ -1,4 +1,4 @@
-// Analytics tab: operations overview, indicator explorer, resource outlook, and scorecard.
+// Overview tab: operations dashboard, indicator explorer, resource outlook, and scorecard.
 import { useState, useEffect, useMemo } from 'react'
 import {
   LineChart, Line, Area, ComposedChart, XAxis, YAxis, CartesianGrid, Tooltip, ResponsiveContainer, ReferenceLine,