diff --git a/docs/agent-lifecycle/approvals.md b/docs/agent-lifecycle/approvals.md index 544afc9c..0bd9dfdb 100644 --- a/docs/agent-lifecycle/approvals.md +++ b/docs/agent-lifecycle/approvals.md @@ -2,7 +2,7 @@ The approval queue is hyperhive's pivot: nothing that changes the shape of an agent (its config, whether it exists) happens without an -operator click. The submitting agent — any agent with the `approvals` +operator selection. The submitting agent — any agent with the `approvals` tool group, which manages the config of its **direct children** (the root agent for top-level agents; a sub-manager for its own subtree) — is the policy gate in front of that queue; helper events are how it stays @@ -81,7 +81,7 @@ request. actually deploy. 3. The operator reviews the PR **on the forge** (native diff, threaded comments, CI status) and sees a matching card on the dashboard with a - "review PR on forge" deep link. They click ◆ APPR0VE (or + "review PR on forge" deep link. They select ◆ APPR0VE (or `hivectl approvals approve ` on the CLI) once satisfied. 4. On approve, a deploy DAG runs three phases under a resource-holding `DeployWindow` root (see *Queue templates* below): @@ -443,7 +443,7 @@ the config PR, and for a spawn runs the post-spawn forge bookkeeping. Two visible consequences: -- **Operator dashboard**: after clicking APPR0VE the work-in-progress +- **Operator dashboard**: after selecting APPR0VE the work-in-progress shows up on the *rebuild queue* card (`GET /api/jobq/graph`, refetched on every `rebuild_queue_changed` tick), not on the approvals panel (which already moved the row to "approved"). A long meta-update diff --git a/docs/integrations/forge.md b/docs/integrations/forge.md index e33f2dfd..d249f914 100644 --- a/docs/integrations/forge.md +++ b/docs/integrations/forge.md @@ -77,7 +77,7 @@ Two things live in the `agent-configs` Forgejo organization: user via a git credential helper that reads the live forge-core token — so the config lives on the forge, not a hand-synced local checkout. - The dashboard links each container's "config" anchor to this - config repo, so operators can click straight from the SW4RM tab into + config repo, so operators can go straight from the SW4RM tab into the rendered repo without an extra `git` step. The `hive-forge` CLI (separate workspace crate, see diff --git a/docs/scheduler/ci.md b/docs/scheduler/ci.md index b5883a9a..729b9c37 100644 --- a/docs/scheduler/ci.md +++ b/docs/scheduler/ci.md @@ -58,7 +58,7 @@ throughout. **Always re-check `pr-status` after a dispatch and believe what it says — don't push a commit just to unwedge it, that's the empty-commit anti-pattern this verb exists to avoid.** If the code is verified green (`hive-forge ci-log --run --job 0`, verdict is the -last line) but the status is stuck, ask the operator to click "rerun" in +last line) but the status is stuck, ask the operator to select "rerun" in the forge web UI — it's CSRF-gated, so only they can do it. ### Running checks locally diff --git a/docs/web-ui/README.md b/docs/web-ui/README.md index 4fd2e8ee..97cc1298 100644 --- a/docs/web-ui/README.md +++ b/docs/web-ui/README.md @@ -11,7 +11,7 @@ below; this page only covers what you actually do here. Everything starts at the **H0M3 hub**, served at `/` — a grid of tiles linking to every surface (Dashboard, Flow, Logs, Builds, Stats, Settings, Core, Credentials). Every page links back to H0M3, so you're -never more than one click from the hub. +never more than one step from the hub. The **dashboard** itself (`/dashboard.html`) is where you'll spend most of your time. It's a single page with exactly four tabs: @@ -34,7 +34,7 @@ accounts per agent). Your local browser preferences (notifications) live in the dashboard's Y3R C4LL tab now, not a separate page. Each agent also has its own page — a full terminal view of that -agent's session, reachable by clicking its name anywhere in the +agent's session, reachable by selecting its name anywhere in the dashboard, or directly at `/agent//` (or `http://:/` if the gateway isn't in front). @@ -43,7 +43,7 @@ if the gateway isn't in front). **Check on an agent.** SW4RM shows every container as a row: name, whether it's running, what it's currently doing (a live status pill — `rebuilding…`, `starting…`, and so on — while something's in flight), -and quick links (stats, screen, forge profile). Click the name to open +and quick links (stats, screen, forge profile). Select the name to open its terminal and watch it work in real time. **Approve something an agent is waiting on.** Y3R C4LL is the one tab @@ -57,7 +57,7 @@ than landing automatically — you'll see them on Y3R C4LL, with a diff of what's changing. **Start, stop, restart, or rebuild an agent.** Select one or more -agents on SW4RM (click the icon) and use the selection bar, or use the +agents on SW4RM (select the icon) and use the selection bar, or use the per-agent `⋮` menu on a single row. Rebuilding re-applies that agent's current config; use it after approving a change, or whenever an agent shows as "needs update." diff --git a/docs/web-ui/agent.md b/docs/web-ui/agent.md index 7d506a5b..3f3fb89c 100644 --- a/docs/web-ui/agent.md +++ b/docs/web-ui/agent.md @@ -52,7 +52,7 @@ structurally rather than for one specific trigger. Two columns: `◌ needs login` / `◌ logging in` / `○ offline` / `… connecting`. - **State badge**: `💤 idle` / `🧠 thinking` / `📦 compacting` / `○ offline` / `… booting` + age suffix. - - **Model badge** (`model · ▾`): a real picker — click opens + - **Model badge** (`model · ▾`): a real picker — selecting it opens a `Dropdown` of `state.available_models`, selecting one POSTs `/api/model` immediately (same endpoint the `/model ` slash command uses). No longer buried in the overflow menu — the design @@ -68,7 +68,7 @@ structurally rather than for one specific trigger. Two columns: endpoints the dashboard uses (pausing needs a write this unprivileged process can't make directly). - **Inbox / todos pills** (`📬 inbox · N` / `📋 todos · N`): hidden - when empty; click opens the matching flyout in the side panel. + when empty; selecting it opens the matching flyout in the side panel. - **Links badge** (`🔗`): opens a popover listing `↑ dashboard` (back-link to the host dashboard, `${dashboardBase}dashboard.html`) followed by this agent's `agent_links()`-sourced navigation (stats, @@ -152,7 +152,7 @@ via the header pills) as well as long content (file previews, diffs, journald logs). Inbox flyout: unread messages addressed to this agent (`acked_at IS NULL`, newest-first, up to 30); reply messages indented with `↳ reply ·` in amber. A `✓ mark all read` button appears in the -flyout header when the inbox is non-empty; clicking it confirms then +flyout header when the inbox is non-empty; selecting it confirms then POSTs cross-origin to the core dashboard's `POST /api/agent/{name}/mark-all-read` — all pending messages for this agent are acked, the harness won't receive wake-prompts for them. A `{ @@ -212,7 +212,7 @@ the full row taxonomy and dispatch logic): operator: "..."`, etc.): flat one-line per-tool format with per-tool salient-arg extraction (`fmtToolUse`). - `Stream` `tool_result` short → flat `← ...`; long → collapsed - `
` `▸ ← Nl · headline` (click to expand full body). + `
` `▸ ← Nl · headline` (select to expand full body). - `Stream` `thinking` → `.thinking` row with a `💭 thinking …` indicator. - `Stream` `system` → handled by subtype: `plugin_install` and diff --git a/docs/web-ui/dashboard.md b/docs/web-ui/dashboard.md index 1a83d96d..9ee832b3 100644 --- a/docs/web-ui/dashboard.md +++ b/docs/web-ui/dashboard.md @@ -445,7 +445,7 @@ The current capabilities are: Each row is one agent. Columns are the capability names returned by `GET /api/capabilities` as `caps: Vec`. Checking or unchecking boxes only stages the change in-browser; nothing is written until the -page-level **save all** button (described below) is clicked. Row +page-level **save all** button (described below) is selected. Row values follow the `effective`/`assignments` rule described above. **T00L GR0UPS** — per-agent tool-group permissions. Tool groups are @@ -477,7 +477,7 @@ render-time state) and the row carries `data-agent` for dirty-tracking. **Saving — one button for the whole page.** No per-row save buttons exist. A single page-level `.perm-save-bar` with a **save all (N agents)** button sits at the bottom of the pane, enabled only when some -checkbox diverges from its baseline. Clicking it diffs every checkbox +checkbox diverges from its baseline. Selecting it diffs every checkbox across *both* matrices and POSTs one batch to `POST /api/permissions` as `{ changes: [ { agent, tool_groups?, capabilities? } ] }` — only the perm-types that actually changed for each agent are included (an omitted @@ -548,7 +548,7 @@ The table's last row is a permanent inline creation row: inputs live directly in table cells (targets as checkboxes, body textarea that expands on focus, datetime-local pre-filled to 5 minutes from now, mini d/h/m/s number inputs (blank or -all-zero = one-shot), description). Click `＋` to POST to +all-zero = one-shot), description). Select `＋` to POST to `/api/schedules` as JSON (or `⌫` to clear the half-filled row); carry-state preserves partially typed inputs across re-renders. The tab pill shows the count of active schedules (at least one live target not yet cancelled). @@ -856,7 +856,7 @@ life). Two consequences for anything rendering it: to rebuild-shaped work — `running_transients()` on the backend is a status-only test (any `Running` node whose payload names a non-empty agent lights a pill), so work the operator never - clicked (a meta-update cascade, a crash-recover rebuild, a + triggered (a meta-update cascade, a crash-recover rebuild, a lease-exempt `prebuild`) lights the same mechanism. Ops with no queue node behind them (destroy, migration) supply @@ -890,13 +890,13 @@ watermarks. When the window value is absent the badge falls back to fixed 100k / 150k thresholds. **Per-agent `⋮` overflow menu** — a `⋮` button appears on the right -edge of each container row. Clicking it opens a small dropdown with +edge of each container row. Selecting it opens a small dropdown with per-agent actions and navigation links. Contents: - `↺ R3ST4RT` (running agents only) / `■ ST0P` (running only) / `▶ ST4RT` (stopped only) — single-agent run-state toggles. Identical to the bulk actions on the selection bar but operate - on one agent without requiring a selection click. + on one agent without requiring a selection. - `↻ R3BU1LD` — always available; queues a rebuild for this agent. - `journal logs →` — opens `/logs.html#agent?agent=` so the operator lands directly in the AGENT log tab pre-filtered to this @@ -942,14 +942,14 @@ OS. Three primitives, all built on the `openDialog` core: — a modal confirm that resolves to `null` on cancel or an object of checkbox states on confirm. Destructive actions pass `danger: true` (the confirm button turns red and the cancel - button takes focus). Backdrop click and `Esc` both cancel. + button takes focus). Selecting the backdrop and `Esc` both cancel. - `themedPrompt(...)` — a modal with a text input, resolving to the entered string or `null`. - `themedToast(message, { type, ... })` — a non-blocking toast (top-right, `info` / `error` / `ok`) for transient validation + action failures, so an error doesn't trap the operator behind a modal. Single-action errors autodismiss; bulk / partial-failure - summaries are sticky (click to dismiss) so they aren't missed. + summaries are sticky (select to dismiss) so they aren't missed. Every destructive run-state action (`ST0P`, `R3ST4RT`, `R3BU1LD`, `DESTR0Y`, `PURG3`, `M0V3`) routes through `themedConfirm`, on both @@ -1000,13 +1000,13 @@ all no-ops and the layout reads like a plain flat list. Bulk actions (`R3ST4RT` / `ST0P` / `ST4RT` / `P4US3` / `R3SUM3` / `R3BU1LD` / `DESTR0Y` / `PURG3`) live here rather than as per-card -buttons — see **Container row** above. Clicking an agent's icon +buttons — see **Container row** above. Selecting an agent's icon toggles its selection (an in-memory `Set`); `Esc` or the bar's `✕ clear` button drops everything. The selection persists across tab switches in-memory — the bar just hides on non-SW4RM tabs since other tabs don't show the agent cards needed to cross-reference. -When one or more agents are selected (via icon click), a sticky +When one or more agents are selected (via the icon), a sticky frosted-mauve bar slides up from the bottom of the viewport (`#selection-bar`, `position: fixed; bottom: 0`). It shows: @@ -1099,7 +1099,7 @@ Per-event tags (`hyperhive:approval:`, `hyperhive:msg::`) so distinct events stack in the OS notification center instead of overwriting each other. `console.debug` logs at every block point (unsupported, -permission ungranted, muted) for in-browser debugging. Click +permission ungranted, muted) for in-browser debugging. Selecting it focuses the dashboard tab. The localStorage key `hyperhive.notify.muted` (`"1"` = muted, absent = unmuted) backs the toggle and silences dispatch without revoking the OS @@ -1123,7 +1123,7 @@ below — some endpoints aren't in it yet. travels to the submitting agent as `HelperEvent::ApprovalResolved.note` and also rides on the dashboard's `ApprovalResolved` event. Dashboard prompts via the themed `themedPrompt()` dialog on - click — a resizable `