Problem or Use Case

Hermes profiles are useful as isolation boundaries: different configs, sessions, credentials, tools, models, memory, and runtime policies can live under separate profiles.

The web dashboard should reflect that same profile boundary. Today, dashboard UI/customization is effectively shared at the application/code level, so a custom dashboard design or org-chart view can feel global even when the underlying runtime data is profile-specific.

This is especially important when profiles represent different operating modes or teams, for example:

• a main AI development team profile with an org chart and role-execution evidence
• a production/release profile with stronger warnings and deployment-oriented UI
• a reviewer/read-only profile with validation-focused dashboards
• an upstream-contribution profile with clean/default branding
• a low-latency VS Code profile with reduced dashboard surface area

Users should be able to tell immediately which profile they are looking at and should be able to give each profile its own dashboard identity without maintaining separate dashboard forks or custom code branches.

Related existing issues:

• [Feature]: Add profile support to the Hermes Dashboard. #13547 — Add profile support to the Hermes Dashboard
• Web Dashboard: multi-profile switching support (analysis, root causes, and recommended design) #10674 — Web Dashboard: multi-profile switching support

This request is specifically for profile-scoped dashboard design/identity/customization, not only profile switching or data scoping.

Proposed Solution

Add first-class profile-specific dashboard customization, driven by profile config rather than hardcoded dashboard source edits.

Suggested profile config shape:

dashboard:
  title: "Kinni Team"
  subtitle: "AI development control room"
  theme: "kinni-dark"
  logo: "kinni-logo.svg"
  accent_color: "#FA4E4A"
  org_chart_registry: "kinni-org-chart.registry.yaml"
  default_route: "/org-chart"
  visible_nav:
    - overview
    - sessions
    - analytics
    - org-chart
    - config

Expected behavior:

1. Dashboard launched under a profile reads that profile's dashboard config.

   • Example: hermes --profile kinni-team dashboard --port 9119
   • Example: hermes --profile reviewer dashboard --port 9120

2. The active profile is always visible in the dashboard header.

   • Include profile name, config path, and optionally whether this is the default/sticky profile.
   • Make production/release profiles visually distinct enough to prevent mistakes.

3. Branding/theme/logo are profile-scoped.

   • A profile can set a title, logo, default theme, accent palette, and dashboard metadata.
   • This should not require editing shared dashboard source files.

4. Org-chart and role-team metadata can be profile-scoped.

   • A profile can point to a profile-specific org chart registry.
   • If omitted, dashboard falls back to the built-in/default org chart.
   • This lets one profile have a Kinni/NoblePro role-team view while another stays generic Hermes.

5. Dashboard APIs should expose profile identity and profile-scoped metadata.

   • /api/dashboard/profile or similar could return active profile, profile home, config path, theme/branding config, and dashboard capabilities.
   • Existing dashboard endpoints should remain scoped to the active profile's state/config.

6. Support both approaches:

   • running separate dashboard instances per profile on different ports
   • optional future multi-profile dashboard switcher/overview

7. Avoid dashboard forks.

   • The intended pattern is one shared dashboard codebase that renders differently from profile config.

Alternatives Considered

• Keep one shared dashboard design for all profiles. This is simpler, but makes profiles less useful as distinct operational contexts and increases the risk of confusing production/release/reviewer/team dashboards.
• Maintain separate dashboard code branches per profile. This would work visually but would drift quickly and make updates harder.
• Only add a profile switcher. Useful, but insufficient unless each profile can also define its own identity/theme/registry.

Feature Type

Configuration option; Dashboard / UI improvement; Developer experience.

Scope

Medium to large.

A phased implementation could be:

1. expose active profile identity in the dashboard header and API
2. add profile-scoped dashboard title/theme/logo config
3. add profile-scoped org-chart registry path
4. add optional profile switcher / multi-profile overview

Acceptance Criteria

• Running hermes --profile <name> dashboard clearly shows the active profile in the dashboard header.
• Dashboard reads branding/theme/title/logo from the active profile config.
• Profile-specific dashboard customization does not require source-code edits or dashboard forks.
• Profile A and Profile B can run dashboards on different ports with different branding and profile-scoped data.
• Dashboard session/config/analytics endpoints remain scoped to the active profile.
• A profile can optionally specify a custom org-chart registry; otherwise the built-in/default registry is used.
• hermes profile show <name> or hermes config check reports the dashboard customization source and warns on missing logo/registry files.
• Documentation explains how to configure per-profile dashboard identity and how this relates to multi-profile switching.