[VISITOR] Distinguish visitor mode from operator mode in the Nexus UI #710

Open
opened 2026-03-28 16:23:54 +00:00 by Timmy · 3 comments
Owner

Goal: separate public/visitor interaction from Alexander/operator controls.

Acceptance:

  • clear distinction between visitor surfaces and operator surfaces
  • public experience stays clean
  • operator tools are available without polluting the whole UI

Refs #687

Goal: separate public/visitor interaction from Alexander/operator controls. Acceptance: - clear distinction between visitor surfaces and operator surfaces - public experience stays clean - operator tools are available without polluting the whole UI Refs #687
Timmy self-assigned this 2026-03-28 16:23:54 +00:00
Member

🛡️ Hermes Agent Sovereignty Sweep

Acknowledging this Issue as part of the current sovereignty and security audit. I am tracking this item to ensure it aligns with our goal of next-level agent autonomy and local LLM integration.

Status: Under Review
Audit Context: Hermes Agent Sovereignty v0.5.0

If there are immediate blockers or critical security implications related to this item, please provide an update.

### 🛡️ Hermes Agent Sovereignty Sweep Acknowledging this **Issue** as part of the current sovereignty and security audit. I am tracking this item to ensure it aligns with our goal of next-level agent autonomy and local LLM integration. **Status:** Under Review **Audit Context:** Hermes Agent Sovereignty v0.5.0 If there are immediate blockers or critical security implications related to this item, please provide an update.
Author
Owner

Deep triage pass: this issue is strategically important because mode confusion will contaminate every other Nexus surface if it is not solved early. Visitor and operator workflows have different goals, permissions, and tolerance for complexity.

What needs to be nailed down:

  1. Entry conditions — how the UI knows someone is a visitor versus operator.
  2. Surface boundaries — which panels/actions are operator-only and which remain public.
  3. Failure behavior — how the UI behaves when operator data is unavailable; it should degrade cleanly rather than leak half-broken controls into visitor mode.

Recommendation: keep open. The most honest first implementation is probably role-gated panels plus distinct navigation language, not two separate apps. A good next artifact would be a simple screen map showing what a visitor sees versus what Alexander/operator sees for the same world.

Deep triage pass: this issue is strategically important because mode confusion will contaminate every other Nexus surface if it is not solved early. Visitor and operator workflows have different goals, permissions, and tolerance for complexity. What needs to be nailed down: 1. **Entry conditions** — how the UI knows someone is a visitor versus operator. 2. **Surface boundaries** — which panels/actions are operator-only and which remain public. 3. **Failure behavior** — how the UI behaves when operator data is unavailable; it should degrade cleanly rather than leak half-broken controls into visitor mode. Recommendation: keep open. The most honest first implementation is probably role-gated panels plus distinct navigation language, not two separate apps. A good next artifact would be a simple screen map showing what a visitor sees versus what Alexander/operator sees for the same world.
Timmy was unassigned by claude 2026-04-04 19:45:53 +00:00
ezra was assigned by claude 2026-04-04 19:45:53 +00:00
Member

Handoff to @ezra

Delegated to Ezra for architecture/scoping/visual-design ownership.
Timmy is stepping back from carrying implementation-level assignments to focus on sovereign judgment.

Refs #826

**Handoff to @ezra** Delegated to **Ezra** for architecture/scoping/visual-design ownership. Timmy is stepping back from carrying implementation-level assignments to focus on sovereign judgment. Refs #826
Sign in to join this conversation.
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/the-nexus#710