Managed UX: distinguish local Hermes runtime from Company VM Hermes agents

[100yenadmin]

Parent: #1
Related generic runtime tracker: #2
Upstream adoption: #69

Observed confusion

Managed Settings → Agents → Agent runtimes shows Hermes Agent · Setup needed with Install Hermes Agent with the official installer. The registered Company VM agents are visible elsewhere and use Hermes successfully, so the row looks empty or broken even though it describes a different capability.

Current source confirms this row is the Mac-local ACP runtime catalog entry (hermes / hermes-acp). It is not the Company VM Hermes gateway or its registered agents.

Outcome

Managed Hive clearly distinguishes the optional local-Mac Hermes ACP runtime from Company VM-hosted Hermes agents without hiding native runtime truth or implying that Hive provisions Hermes.

Acceptance

• In managed mode, the runtime row is labeled or described as Local Hermes Agent.
• Missing local binaries say Not installed on this Mac and explain that Company VM agents are managed separately in the Agents catalog.
• A ready local Hermes binary still uses the normal upstream readiness/auth-handshake states.
• Company VM agent presence, profiles, responder policy, and import/discovery remain unchanged.
• Unmanaged upstream Buzz keeps its generic native runtime wording unless the clarity change is accepted upstream.
• Focused managed/unmanaged copy-state tests pass.

Non-goals

Installing or configuring Hermes, changing provider/model/memory/tools, altering the Company VM catalog, treating a VM gateway as a local runtime, or making this copy correction a blocker for the current OAuth/avatar release gate.

Upstream note

block/buzz v0.5.1 commit 6300a6b1d03e32c473c7b6568df663c8927565cf fixes local Hermes ACP startup isolation from configured MCP servers. #69 must adopt or prove that behavior present, but it does not by itself resolve this managed product-label distinction.

Exact next action

After #69 freezes the v0.5.1 runtime settings surface, make the smallest managed-copy adjustment and add focused state tests. Do not start a separate runtime or provisioning subsystem.

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #79 - Managed UX: distinguish local Hermes runtime from Company VM Hermes agents
State: open; milestone: Hive — Guarded Business Beta

Related issues/PRs: #1, #2, #69.
Existing labels: enhancement, electric-only.
Suggested labels: bug, security, tests.
Suggested owners: none.

Related context

• Epic: Hive thin adapter — Electric OAuth and VM-hosted agents #1 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• Upstream: first-class Hermes ACP runtime in Buzz #2 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• Upgrade: disposition and adopt block/buzz v0.5.1 without widening Hive #69 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: Managed UX: distinguish local Hermes runtime from Company VM Hermes agents - Parent: #1 Related generic runtime tracker: #2 Upstream adoption: #69 ## Observed confusion Managed Settings → Agents → Agent runtimes shows Hermes Agent · Setup needed with `Install Hermes Agent with the official
Product fit: Product/UX-sensitive issue; review against repo vision and user flow quality, not only technical P0/P1 risk.
Implementation wedge: Ship the smallest user-visible path or prototype that can be smoke-tested against the intended experience.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.
• Current market/product examples, capped and cited, only when they change implementation direction.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• UX/product smoke or screenshot proof when implementation changes user flow.
• Contract or degraded-mode proof before runtime promotion.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.
• Technical severity alone can miss product/UX regressions; include product-manager review framing.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [enabled] current_market_examples: Use for product/UX/market positioning issues with freshness dates.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.

[100yenadmin]

2026-07-30 disposition: still valid as a non-blocking managed copy/configuration seam after #81. Upstream Buzz BYOH now owns the local Hermes preset and readiness state; Company VM agents use buzz-acp -> hermes-acp. This issue may clarify those two locations but must not add runtime discovery, provisioning, or a second Agents surface.

[100yenadmin]

Program note (2026-08-05): the Buzz/Hive lane is superseded by the Mattermost decision (evaos-support-control#415), but this issue is not Buzz-specific — 'distinguish local Hermes runtime from Company VM' is an evaOS Agent (Lane D) UX concern and survives the substrate change. Leaving open; Lane D should pick it up or explicitly decline it rather than letting it lapse with the repo.