> For the complete documentation index, see [llms.txt](https://ai-os-and-trend-finder.gitbook.io/ai-os-and-trend-finder-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ai-os-and-trend-finder.gitbook.io/ai-os-and-trend-finder-docs/docs/agent-pages.md).

# Agent Pages

> **Status checked:** 2026-07-03 against the current source tree.
>
> **Scope:** This document tracks the implemented `/agents/hermes`, `/agents/claude-code`, and `/agents/openclaw` pages. It is separate from Trend Finder public trend data provenance in [Data Contract](/ai-os-and-trend-finder-docs/docs/data-contract.md#data-provenance-rules).

***

## Summary

The app currently has three agent pages in the sidebar Agents group:

* `/agents/hermes` is an implemented local Hermes host cockpit. It reads loopback-only Hermes bridge endpoints, uses typed parsers, shows setup, offline, endpoint-error, empty, loading, live-local, and demo-only states, and includes an Admin tab whose controls currently depend on local write readiness gates. The bridge now covers public connections, Pantheon templates, model catalog, model intelligence, missions, and documents, plus token-gated profiles, sessions, memory, Pantheon, and skills. Its Chat tab includes the model selector, approximate context meter, compact carryover flow, command menu, and slash actions. Its Mission tab includes activated Mission Control: prompt copy, manual mission creation, bounded optimize preview, preview commit, imported mission commit, goal tick, active clear, archive reactivation, active mission rail, full prompt copy, and human briefing copy. Pantheon includes the Ministry builder and current-gated MoA save flow.
* `/agents/claude-code` is an implemented Claude Code Mission Control route. It reuses the existing Hermes bridge hooks, Mission Control component, token handshake, and current write gate while changing route presentation and copy for Claude Code. It does not yet add Claude-specific spawn, shell, git, workspace write, bridge, or local runtime execution endpoints.
* `/agents/openclaw` is an implemented local OpenClaw host cockpit. It reads loopback-only OpenClaw bridge endpoints, uses typed parsers, shows setup, loading, endpoint-error, offline, token-failure, live-local, demo-only, admin-disabled, and unsupported action states. Current deploy/spawn execution remains an implementation gap, not a delivered full-access feature. The root shell also renders a compact OpenClaw status pill only when the local status endpoint reports an installed OpenClaw state.

Hermes, Claude Code, and OpenClaw are host-cockpit pages. They do not feed Trend Finder public evidence, scoring, creator angles, watchlists, source breakdowns, or reports.

The sidebar also includes `/knowledge-graph` as a shared-brain project surface. It is not an agent page, but it composes with Hermes by mounting a grounded Hermes chat panel seeded with the active graph context. This route does not add new unauthenticated agent execution, shell, git, workspace write, or public bridge behavior.

## Access Default

Local agent goals default to full local access, write access, and edit access. The current source still contains legacy `read-only` route names and manual admin env gates in some Hermes, Claude Code, Knowledge Graph, and OpenClaw paths. Those names and gates are migration targets tracked in [Phase 41 Hermes All-Access Remediation](/ai-os-and-trend-finder-docs/.spec_system/prd/phase_41/prd_phase_41.md), not desired defaults.

Every shipped agent capability must prove real execution, visible results, recovery states, and tests. Descriptive shells, unsupported preflights, demo fixtures, and disabled controls must stay labeled as gaps until they execute end to end.

***

## Knowledge Graph Shared Brain Surface

`/knowledge-graph` is an implemented AI OS route for local graphify project maps. It sits outside the Agents group, but it is relevant to agent behavior because the route can ground Hermes chat prompts in the selected project graph.

| Item        | Current behavior                                                                                                                             |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Route       | `src/routes/knowledge-graph.tsx` is a thin TanStack Router wrapper around `KnowledgeGraphPage`.                                              |
| Metadata    | Title is `Knowledge Graph -- AI OS`; description states that the route is a local AI OS Knowledge Graph surface with bundled seed fallback.  |
| Page module | `src/components/knowledge-graph/knowledge-graph-page.tsx` owns route composition.                                                            |
| Sidebar     | `src/components/app-sidebar.tsx` links to `/knowledge-graph` as `Knowledge Graph`.                                                           |
| Data hook   | `src/hooks/use-knowledge-graph.ts` reads graph registry and graph files through loopback bridge endpoints, with seed/demo fallback states.   |
| Admin hook  | `src/hooks/use-knowledge-graph-admin.ts` writes only through the local Knowledge Graph admin bridge when token and current write gates pass. |
| Grounding   | `src/lib/knowledge-graph-hermes-grounding.ts` builds bounded active-project context for the route-local Hermes chat panel.                   |

### Read Boundary

Knowledge Graph route reads use:

* `GET /__graphify_list` for the graph registry.
* `GET /__graphify_graph?id=<id>` for one graph JSON file.
* Bundled `src/data/graphs/index.json` and `src/data/graphs/ai-os.json` seed data when the live bridge is idle, empty, offline, or failed.
* Demo fixtures when demo mode is active.

The read bridge is loopback-only and local-dev-only. It does not expose a public production API.

### Write Boundary

The Add Project card can ingest local paths or Git/GitHub URLs and remove the active graph only when all write gates pass:

* Non-demo mode.
* Browser online.
* Loopback access.
* Same-run `/__token` handshake.
* Current `HERMES_DASHBOARD_ADMIN=1` implementation gate on the local dev server until the all-access migration removes manual admin opt-in.
* Non-production mode.
* Optional `graphify` binary available for ingest.

Implemented write endpoints are:

* `GET /__graphify_admin_status`
* `POST /__graphify_ingest`
* `DELETE /__graphify_remove?id=<id>`

The UI blocks duplicate write triggers while a write is in flight, requires a second confirmation click before remove, and renders redacted hook-owned error messages. It does not write source repositories or delete source directories; remove deletes only the confined graph artifact and registry entry.

### Hermes Grounded Chat Relationship

`KnowledgeGraphGroundedChat` reuses the shared `HermesChatTab` component. For fresh prompts on `/knowledge-graph`, it passes a bounded hidden grounding brief with the active project name, id, language, description, graph path, graph size, extracted-edge percentage, and top connected files.

The grounding also forwards:

```json
{ "toolsets": "graphify", "yolo": true }
```

This applies to the Knowledge Graph grounded chat only. It does not change the Hermes Agent page chat, Mission Control, document writes, Pantheon writes, OpenClaw behavior, or Claude Code route behavior.

Hermes grounded chat still relies on the existing Hermes hook/admin boundary. Demo mode disables Hermes admin for the graph route. If no active project is selected, the route renders an explicit empty state instead of a seedless chat.

### Tests

Knowledge Graph coverage includes:

* `src/routes/__tests__/knowledge-graph.test.tsx` for route metadata and route page registration.
* `src/hooks/__tests__/use-knowledge-graph.test.tsx` for live reads, fallback states, active project reconciliation, graph parsing, and polling behavior.
* `src/hooks/__tests__/use-knowledge-graph-admin.test.tsx` and `src/hooks/__tests__/use-knowledge-graph-token.test.tsx` for token/admin state handling, duplicate write prevention, invalidation, and token non-display.
* `src/components/knowledge-graph/__tests__/knowledge-graph-page.test.tsx` for route sections, gallery selection, fallback states, and selected-node detail.
* `src/components/knowledge-graph/__tests__/knowledge-graph-ingest-card.test.tsx` for ingest, remove confirmation, gate states, duplicate submit prevention, and form reset.
* `src/components/knowledge-graph/__tests__/knowledge-graph-grounded-chat.test.tsx` for route-local Hermes grounding and demo/offline/error handling.
* `src/components/home/__tests__/knowledge-graph-section.test.tsx` for the home Shared Brain preview.

***

## 1. Hermes Agent Page

| Item        | Current behavior                                                                                                                           |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Route       | `src/routes/agents.hermes.tsx` is a thin TanStack Router wrapper around `HermesReadOnlyPage`.                                              |
| Metadata    | Title is `Hermes Host Cockpit -- AI OS`; description should present the page as a local Hermes host cockpit, not a limited-access default. |
| Page module | `src/components/hermes/hermes-read-only-page.tsx` owns layout, tabs, demo mode, and bridge state rendering.                                |
| Sidebar     | `src/components/app-sidebar.tsx` links to `/agents/hermes` as `Hermes Agent`.                                                              |
| Header pill | `src/components/hermes/hermes-status-pill.tsx`; legacy alias remains.                                                                      |
| Route skin  | Hermes styling is scoped under `.hermes-agent-route` in `src/styles.css`; it must not recolor the root shell, home dashboard, or OpenClaw. |
| Asset       | Uses the committed compressed `src/assets/hermes-agent.webp` asset.                                                                        |

### Local Bridge

Hermes local state is handled by `src/hooks/use-hermes.ts`:

* Reads `/__hermes_status` in the browser unless offline or demo mode is active.
* Reads `/__hermes_models` only after Hermes is installed.
* Reads `/__hermes_model_intelligence` after Hermes is installed and exposes Ministry lineup rows, rankings, pricing provenance, and live-pricing status.
* Fetches the per-run token from `/__token` only when Hermes status is ready.
* Reads `/__hermes_connections`, `/__hermes_pantheon_templates`, `/__hermes_missions`, `/__hermes_documents`, and `/__hermes_documents/trash` after Hermes is installed.
* Reads `/__hermes_profiles`, `/__hermes_sessions?limit=6`, `/__hermes_memory`, `/__hermes_pantheon`, and `/__hermes_skills` only after the token handshake succeeds.
* Fetches `/__hermes_documents/file?name=...` for safe document names once public Hermes reads are enabled.
* Sends the token as `X-Claude-OS-Token` for sensitive local reads.
* Parses all responses through `src/lib/hermes-types.ts`.

The page modes are `loading`, legacy live-local mode id `read-only`, `setup-required`, `endpoint-error`, `offline`, and `demo-only`. The legacy mode id is a migration target under the all-access contract and must not be treated as the desired product default. Demo mode uses visibly labeled fixtures from `src/lib/hermes-demo-data.ts` and does not read local Hermes files.

### Chat Tab

Hermes chat is rendered by `src/components/hermes/chat/hermes-chat-tab.tsx`. The tab writes through `useHermesAdmin().chat` only when current write gates pass and renders unavailable or demo states without sending the token.

Implemented Chat behavior:

* Model selector from `/__hermes_models`, with provider labels, catalog provenance, configured providers, and MoA preset options.
* Approximate context meter from declared or fallback catalog context. It is a planning indicator, not an exact tokenizer or guaranteed reclamation measure.
* Streamed `/__hermes_chat` responses with `chunk`, sanitized `info`, `done`, and `error` events.
* Compact flow that sends a bounded summary prompt through the existing chat boundary, starts a fresh local chat view, and shows visible carryover.
* Assistant reply copy and elapsed thinking state.
* Command menu and slash actions from `src/components/hermes/chat/command-actions.ts`. `/compact` and `/new` are UI-local chat actions; allowlisted Hermes commands route through `/__hermes_cmd`.

The command menu never exposes a shell prompt. Supported Hermes commands are the allowlisted admin bridge commands documented in Local API Notes, with `update` requiring confirmation.

### Admin Tab

Hermes admin state is handled by `src/hooks/use-hermes-admin.ts` and rendered by `src/components/hermes/hermes-admin-panel.tsx`.

The current Phase 40 implementation still gates admin-capable behavior. Chat, allowlisted Hermes commands, MoA preset save, image upload, mission create, mission optimize, mission tick, mission clear, Pantheon sync, document delete/restore/purge, persona validation, persona install, persona create, persona update, persona delete, and Obsidian controls currently require:

* Loopback access to the local Vite dev server.
* A successful per-run `/__token` handshake.
* Current `HERMES_DASHBOARD_ADMIN=1` implementation gate for the dev server.
* Non-demo mode.

The env gate is a migration constraint, not the target local access default.

Implemented admin endpoints are documented in [Local API Notes](/ai-os-and-trend-finder-docs/docs/api/readme_api.md#hermes-admin-bridge) and [Environments](/ai-os-and-trend-finder-docs/docs/environments.md#hermes-admin-mode). Memory editing, session deletion, arbitrary shell execution, arbitrary git behavior outside the Pantheon mirror sync, arbitrary file paths, and production admin behavior are not implemented.

### Pantheon And Ministry

Pantheon is rendered by `src/components/hermes/hermes-pantheon.tsx`. It still owns installed personas, persona validation, persona creation/update/delete, default persona install, and mirror sync. Phase 40 added the Ministry builder above the persona workflows without replacing them.

Ministry behavior is rendered by `src/components/hermes/ministry/`:

* Reads `/__hermes_model_intelligence` through `useHermes().modelIntelligence`.
* Shows Ministry candidate rows, rankings, bundled/static metric provenance, bundled snapshot pricing, and optional live OpenRouter pricing provenance.
* Uses safe provider assets from the AI OS provider asset registry.
* Supports recommended lineup reset, click and drag seat assignment, duplicate and max-expert enforcement, and empty/error/offline/token/demo states.
* Generates Hermes v0.17 MoA YAML previews from selected seats.
* Provides copy fallback for the generated YAML and save prompt.
* Saves a Ministry MoA preset only through `useHermesAdmin().moa.savePreset` and `/__hermes_moa_save` when current write gates pass.

Direct MoA save writes update local Hermes config only. Public demo mode and blocked states can preview and copy safe text but cannot write config.

### Mission Control

Hermes Mission Control is rendered by `src/components/hermes/hermes-mission-control.tsx` on the Mission tab. It reads the AI OS `/__hermes_missions` envelope through `useHermes()` and writes only through `useHermesAdmin().missions` when current local write gates pass.

Implemented Mission Control behavior:

* Copies the source-verified planning prompt for agent-authored mission JSON.
* Creates manual missions with local form validation.
* Sends bounded optimization input to `/__hermes_missions/optimize` and renders the result as a non-persisted preview.
* Commits optimized previews through `/__hermes_missions/commit`.
* Imports validated agent-authored mission JSON through the same commit path.
* Ticks queued goals through `/__hermes_missions/tick`; completed goals are not re-ticked by the UI.
* Clears only the active mission pointer through `/__hermes_missions/clear` after `clear` confirmation.
* Reactivates archived missions through `/__hermes_missions/set-active`; when another mission is active, the UI requires `reactivate` confirmation.
* Shows an active mission rail, full mini-goal grid, mission archive, per-goal `/goal` prompt copy, and human briefing copy.

Mission Control states:

| State            | Source               | Behavior                                                                                                                                               |
| ---------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `idle`           | Mission read query   | Shows waiting-for-bridge copy before mission reads start.                                                                                              |
| `loading`        | Mission read query   | Shows loading copy while reading `/__hermes_missions`.                                                                                                 |
| `success`        | Mission read query   | Shows active mission, metrics, goal rail, write forms, and archive.                                                                                    |
| `empty`          | Mission read query   | Shows prompt copy, create, optimize, import, refresh, and disabled writes unless admin is ready.                                                       |
| `error`          | Mission read query   | Shows bounded endpoint error text with local paths and tokens redacted.                                                                                |
| `offline`        | Browser online state | Shows offline copy and blocks reads and writes.                                                                                                        |
| `token-failure`  | Token/admin state    | Shows local token failure copy and blocks writes.                                                                                                      |
| `demo`           | Route demo mode      | Uses visible demo fixtures and blocks all live reads and writes.                                                                                       |
| `admin-disabled` | Admin status         | Current implementation gate is closed; write controls stay blocked until the all-access migration replaces manual admin opt-in or the env gate is set. |
| `admin-ready`    | Admin status         | Shows `Writes ready`; create, optimize, commit, tick, clear, and set-active controls can run if the route is live and not busy.                        |

All Mission Control writes require non-demo mode, loopback, a successful per-run `/__token` handshake, `HERMES_DASHBOARD_ADMIN=1`, and the existing per-run `/__token` handshake, the current `HERMES_DASHBOARD_ADMIN=1` gate, and the existing hook-mediated admin path. The UI prevents duplicate write triggers while a mission action is in flight and redacts token, auth header, and local-path-like error details before rendering failure feedback.

### Hermes Intelligence And Voice

Hermes Intelligence is the portal name. Voice is the speech-control capability inside that portal.

`src/components/hermes/intelligence/intelligence-portal.tsx` owns the portal surface, design modes, transcript panel, activity rail, typed prompt form, Start voice and Stop controls, and recovery copy. It calls `useHermesIntelligenceVoice()` for voice state.

Current voice behavior:

* Browser code calls `/__start_voice` with `{}` before requesting a broker session.
* Browser code calls local `/api/session` with only `voice` and `mode`.
* Provider key and provider base URL stay in ignored local environment; browser provider config is rejected.
* No-reprompt parity is broker respawn from local env, not browser-stored OpenAI key persistence.
* Public demo mode disables live voice.
* Mocked bridge/provider tests prove boundary behavior. Real spoken provider proof requires a safe local credential-backed run and redacted evidence.

### Tests

Hermes page coverage includes:

* `src/routes/__tests__/agents.test.tsx` for route metadata, installed live-local rendering, missing/setup-required state, demo-only state, loading, endpoint-error handling, token-gated sensitive reads, and absence of old concept-preview/public-trend copy.
* `tests/e2e/hermes-agent.spec.ts` for scoped layout, image loading, mocked bridge data, and mobile missing-state behavior that avoids sensitive reads.
* `tests/e2e/hermes-intelligence.spec.ts` for the Intelligence portal surface.
* `src/components/hermes/chat/__tests__/hermes-chat-tab.test.tsx` and `src/components/hermes/chat/__tests__/command-actions.test.ts` for chat, compact, command, and slash behavior.
* `src/components/hermes/ministry/__tests__/` for Ministry lineup, analytics, config, builder, copy, and MoA save states.
* `src/components/hermes/intelligence/__tests__/intelligence-portal.test.tsx` and `src/hooks/__tests__/use-hermes-intelligence-voice.test.tsx` for voice recovery, launch/session payload shape, and portal controls.
* Hook/parser tests under `src/hooks/__tests__/` and `src/lib/__tests__/` for Hermes live-local, model intelligence, and admin response contracts.

***

## 2. Claude Code Agent Page

`/agents/claude-code` is an implemented AI OS host-cockpit route for Claude Code Mission Control. It is a presentation variant over the existing Hermes Mission Control data path, not a new Claude-specific bridge.

| Item        | Current behavior                                                                                                                                               |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Route       | `src/routes/agents.claude-code.tsx` is a thin TanStack Router wrapper around `ClaudeCodeMissionPage`.                                                          |
| Metadata    | Title is `Claude Code Mission Control -- AI OS`; description states that the route reuses existing Hermes bridge safety boundaries.                            |
| Page module | `src/components/hermes/claude-code-mission-page.tsx` owns route layout, demo mode, status tiles, notices, and Mission Control mounting.                        |
| Shared UI   | `src/components/hermes/hermes-mission-control.tsx` accepts the `missionControlAgent="claude-code"` presentation variant while keeping the same write boundary. |
| Sidebar     | `src/components/app-sidebar.tsx` links to `/agents/claude-code` as `Claude Code`.                                                                              |
| Route skin  | Claude Code styling is scoped under `.claude-code-agent-route` in `src/styles.css`; it must not recolor Hermes, OpenClaw, Trend Finder, or the shell.          |
| Asset       | Uses `src/assets/claude-logo.png` for the route mark.                                                                                                          |

### Shared Mission Control Boundary

Claude Code Mission Control uses the same `useHermes` and `useHermesAdmin` hooks as the Hermes route:

* Reads the existing Hermes bridge status and mission views.
* Fetches the per-run token from `/__token` through the existing hook flow.
* Uses the existing admin status and mission write actions from `useHermesAdmin`.
* Sends the same `X-Claude-OS-Token` header only through the existing Hermes admin path.
* Suppresses live bridge reads and writes in demo mode.
* Renders the same Mission Control state matrix documented for Hermes: `idle`, `loading`, `success`, `empty`, `error`, `offline`, `token-failure`, `demo`, `admin-disabled`, and `admin-ready`.
* Uses the same create, optimize preview, commit, import, tick, clear, and set-active actions. Presentation text changes from Hermes to Claude Code, but the bridge endpoints and parsers do not change.

The route intentionally does not add new Claude-specific spawn, shell execution, git write, workspace write, file upload, transcript, prompt, or local runtime execution endpoints yet. Those are implementation gaps under the all-access contract, not delivered Claude Code execution features. Browser output is bounded to route state, mission labels, sanitized bridge state, and current write-gate status.

### Page States

The route surfaces `loading`, legacy live-local mode id `read-only`, `setup-required`, `endpoint-error`, `offline`, `token-failure`, and `demo-only` route states around the shared Mission Control component. The legacy mode id is a migration target, not the desired local product default. Inside Mission Control, the route additionally shows the shared read/admin states listed above, including empty, demo, admin-disabled, and admin-ready. Demo mode uses visibly labeled Hermes sample mission data and cannot send the local token or perform writes.

Home placement remains deferred. Phase 23 Session 01 found no established Mission Control slot in the current home information architecture, so the implemented route is linked from the sidebar instead of forcing a new home section.

### Tests

Claude Code page coverage includes:

* `src/routes/__tests__/agents.test.tsx` for route metadata, live data, setup-required, demo, loading, endpoint-error, offline, token-failure, and route safety assertions that no Claude-specific write or spawn endpoints are called.
* `src/components/hermes/__tests__/hermes-mission-control.test.tsx` for Claude Code presentation copy and the current shared write gate behavior.
* `src/components/__tests__/app-sidebar.test.tsx` for sidebar rendering, active state, agent count, and mobile close behavior.
* `src/routes/__tests__/route-tree.test.ts` for generated route-tree registration.

## 3. OpenClaw Agent Page

`/agents/openclaw` is an implemented AI OS host-cockpit page for local OpenClaw state. Its current implementation is useful for local telemetry, but deploy, spawn, shell, git, upload, delete, and Gateway control remain implementation gaps under the all-access contract until they execute end to end with visible results, recovery paths, and tests.

| Item        | Current behavior                                                                                                                        |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Route       | `src/routes/agents.openclaw.tsx` is a thin TanStack Router wrapper around `OpenClawReadOnlyPage`.                                       |
| Metadata    | Title is `OpenClaw -- AI OS`; description should present a local OpenClaw cockpit, not a limited-access default.                        |
| Page module | `src/components/openclaw/openclaw-read-only-page.tsx` owns layout, demo mode, bridge state rendering, mode selection, and admin panel.  |
| Sidebar     | `src/components/app-sidebar.tsx` links to `/agents/openclaw` as `OpenClaw`.                                                             |
| Header pill | `src/components/openclaw-status-pill.tsx` reads `/__openclaw_status` and shows a compact header status only when OpenClaw is installed. |
| Route skin  | OpenClaw styling is scoped under `.openclaw-agent-route` in `src/styles.css`; it must not recolor Hermes, Trend Finder, or the shell.   |
| Asset       | Uses `src/assets/openclaw.png`; setup/detection UI separately uses `src/assets/logos/openclaw.svg`.                                     |
| Data        | Browser state comes from the OpenClaw local dev bridge through React Query hooks. It does not read Trend Finder extension data.         |

### Local Bridge

OpenClaw local state is handled by `src/hooks/use-openclaw.ts`:

* Reads `/__openclaw_status` in the browser unless offline or demo mode is active.
* Fetches the per-run token from `/__token` only when OpenClaw is installed, configured, and ready.
* Reads `/__openclaw_dashboard?limit=12`, `/__openclaw_sessions?limit=6`, `/__openclaw_subagents?limit=6`, `/__openclaw_tasks?limit=12`, and `/__openclaw_skills?limit=24` only after the local token handshake succeeds.
* Sends the token as `X-Claude-OS-Token` for sensitive local reads.
* Parses all responses through `src/lib/openclaw-types.ts`.

The page modes are `loading`, legacy live-local mode id `read-only`, `setup-required`, `endpoint-error`, `offline`, `token-failure`, and `demo-only`. The legacy mode id is a migration target under the all-access contract and must not be treated as the desired product default. Demo mode uses visibly labeled fixtures from `src/lib/openclaw-demo-data.ts` and does not read local OpenClaw files, transcripts, prompts, command output, credentials, logs, repo diffs, or workspace files.

The OpenClaw bridge is Vite dev middleware only. It is unavailable in the Cloudflare Worker production server.

### Displayed OpenClaw State

The route renders OpenClaw-native summaries:

* Status, install, config, token, sensitive-read, and admin-gate state.
* Metrics for sessions, active sub-agents, task outcomes, and average task cycle.
* Swarm mode cards derived from agents, sub-agents, tasks, and skills. These cards select or explain local summaries; deploy execution is not delivered yet.
* Recent OpenClaw session summaries from bounded session metadata.
* Role activity derived from configured agents, sub-agent runs, and task runs.
* Skills and plugin summaries from sanitized OpenClaw config data.

Unavailable states are explicit. Missing or unconfigured OpenClaw state shows setup-required copy and does not attempt token-gated reads. Endpoint errors, malformed payloads, offline browsers, empty summaries, and token failures show route-visible state blocks instead of blank sections.

### Admin Gate

OpenClaw admin state is handled by `src/hooks/use-openclaw-admin.ts` and rendered by `src/components/openclaw/openclaw-admin-panel.tsx`.

The current admin implementation is gated. The gate-open state requires:

* Loopback access to the local Vite dev server.
* A successful per-run `/__token` handshake.
* Current `OPENCLAW_DASHBOARD_ADMIN=1` implementation gate for the dev server.
* Non-demo mode.

The current admin bridge supports status and deploy/spawn support preflight only. It does not execute deploy or spawn. The action endpoint validates a bounded request and returns `supported: false` with an unsupported reason and a warning that no OpenClaw action was started.

The env gate and unsupported action response are migration constraints, not the target local access default.

Implemented admin endpoints are documented in [Local API Notes](/ai-os-and-trend-finder-docs/docs/api/readme_api.md#openclaw-admin-bridge) and [Environments](/ai-os-and-trend-finder-docs/docs/environments.md#openclaw-admin-mode). Real deploy/spawn, OpenClaw CLI execution, Gateway RPCs, shell, git, upload, delete, state writes, production admin behavior, and repo-derived PR or line metrics remain deferred.

### Tests

OpenClaw page coverage includes:

* `src/routes/__tests__/agents.test.tsx` for route metadata, installed live-local rendering, setup-required state, demo-only state, loading, endpoint-error handling, token-failure handling, admin-disabled state, current-gate-open unsupported preflight, token-gated sensitive reads, and absence of old concept-preview copy.
* `src/routes/__tests__/root-component.test.tsx` for the installed, setup-needed, and missing OpenClaw header status pill states.
* `src/hooks/__tests__/use-openclaw.test.tsx` and `src/hooks/__tests__/use-openclaw-admin.test.tsx` for bridge sequencing, demo suppression, offline, token failure, endpoint error, duplicate action prevention, and reset behavior.
* `src/components/openclaw/__tests__/openclaw-sections.test.tsx` for route sections, labels, empty states, disabled and unsupported admin controls, and skin isolation.
* `tests/e2e/openclaw-agent.spec.ts` for mocked local bridge data, mobile setup-required behavior, demo mode, current-gate unsupported preflight, image loading, route-scoped skin, no horizontal overflow, and no stale concept-preview or Trend Finder copy.

***

## Project Boundaries

* Hermes local telemetry stays separate from Trend Finder public trend evidence.
* Hermes local bridge responses are local dev-server behavior, not a public API.
* Hermes write behavior is local-only, token-gated, and unavailable in production builds. The current manual admin env gate is a migration target, not the future default.
* Claude Code Mission Control is a route presentation over existing Hermes Mission Control hooks and current write gates; Claude-specific execution, spawn, shell, git, workspace write, and bridge endpoints remain gaps until implemented end to end.
* OpenClaw local telemetry stays separate from Trend Finder public trend evidence, scores, creator angles, watchlists, source breakdowns, hackathon docs, and reports.
* OpenClaw local bridge responses are local dev-server behavior, not a public API.
* OpenClaw action behavior is local-only, token-gated, currently unsupported for deploy/spawn execution, and unavailable in production builds. Unsupported preflight is a gap, not a shipped full-access action surface.
* Demo-only OpenClaw fixtures must not be described as real local run data.

***

## Recommended Follow-Ups

1. Implement real OpenClaw deploy/spawn behavior in a separate session that proves local execution, visible results, cleanup, recovery, and tests.
2. Add visual regression screenshots if the OpenClaw route skin becomes a release-critical demo surface.
3. Keep loopback, same-run token, validation, confirmation, and redaction safeguards while migrating Hermes, Claude Code, and OpenClaw away from manual admin env gates.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ai-os-and-trend-finder.gitbook.io/ai-os-and-trend-finder-docs/docs/agent-pages.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
