Eve is a shared capability expressed through several shells. Each shell has a different identity, audience, context envelope, and action budget; visual similarity does not make the shells equivalent.
The surface selects identity, context, grants, and evidence posture. It does not promote a member invocation into builder authority or an agent report into a verified result.
Surface inventory#
| Plane | Surface | Identity | Primary job | Authority shape |
|---|---|---|---|---|
| Member | Docked assistant panel and slide-over | Lilith | Ask, navigate, understand, and continue work without leaving the current page. | Member session, page context, scoped client/server tools. |
| Member | Full-screen assistant | Lilith | Longer conversations, history, evidence review, and handoffs. | Same member policy envelope with a larger workspace. |
| Member | Voice and guided tours | Lilith | Hands-free interaction and stepwise product orientation. | Mic/speech permission, tour eligibility, and safe interruption. |
| Builder | Admin Operations Copilot drawer | Eve | Inspect operational state and propose governed workbench changes. | Operator session, workspace context, read tools, confirm-bridged mutations. |
| Builder | Studio/workbench entry points | Eve | Orient builders and connect intent to the appropriate governed work surface. | Capability-specific grants; breadth varies by workbench. |
| Agent | Workbench MCP and coding-agent harness | Eve | Lease an accepted work item, execute within scope, and report evidence. | Explicit lease, actor attribution, sandbox/process policy, no self-verification. |
The member and builder faces share infrastructure but must preserve the identity boundary.
Invocation is a governed transition#
Opening a panel is only the visual part of invocation. A supported entry point also determines:
- actor and tenant identity;
- active route, workspace, or artifact;
- the user's selection or row context when applicable;
- evidence and grounding state already visible on the page;
- permitted tool grants and mutation constraints;
- memory posture and disclosure state;
- persona and release scope;
- the focus target to restore when the assistant closes.
The invocation registry and its guards are canonical in
libs/oshun/shell-assistant. Call sites should use the typed/guarded path, not
a free-form event that bypasses eligibility or loses context.
Member entry points#
The shared shell chooses between docked and overlay presentation based on the available layout. Supported entry points include the persistent assistant trigger, contextual help, selection-based ask, empty/error states, evidence and grounding affordances, and curated tour starts. The exact released set is tracked in Assistant Experience and verified through customer walkthroughs such as assistant context handoff, memory controls, and Sophia grounded answers.
An invocation should fail closed when the route is out of scope, the persona is not released, the required capability is disabled, or the context contains an artifact the actor cannot read.
Builder entry points#
The admin shell presents Eve as an Operations Copilot with explicit workspace, operator, and memory context. Builder invocation starts with operational orientation and can lead to either:
- a read-only answer grounded in current admin/workbench state;
- a link or navigation action;
- a proposed work item, decision, feature proposal, or content brief parked for human review;
- an existing confirmation card that the operator approves or declines;
- a handoff to a specialized workspace when Eve lacks the action surface.
The drawer must not claim the whole console is read-only when a governed write tool is actually available, and it must not imply it can mutate a workspace when no such tool is in scope. The measured affordance history and remaining surface gaps live in Eve Everywhere.
Voice, tours, and proactive help#
Voice is a transport and presentation mode, not a separate trust regime. Speech input still enters the authenticated assistant path; speech output still honors persona, privacy, refusal, and crisis policy. The UI must expose listening, processing, speaking, permission-denied, unavailable-provider, and interruption states without pretending a fallback is the preferred provider.
Tours are stateful guidance, not prerecorded chat. A tour step binds a route, target, copy, eligibility rule, and recovery behavior. Member-authored tours require the review path documented by the assistant feature and walkthrough coverage. An assistant should pause or exit cleanly when the target disappears, navigation diverges, safety supersedes the tour, or the user takes control.
Proactive help must be explainable and dismissible. It should arise from a declared invocation point or product state, not from surveillance-like inference.
Contextual invocation checklist#
Before adding a new trigger, answer all of these:
- Which identity is displayed—Eve or Lilith?
- What exact actor, tenant, route, artifact, selection, and evidence fields are handed to the server?
- Which tools are permitted, and which mutations require confirmation?
- What happens when context is stale, unauthorized, or absent?
- Which memory scope is visible, and can the user pause or opt out?
- Which event records open, close, action, refusal, and error outcomes?
- How do keyboard focus, mobile layout, screen readers, and reduced motion work?
- Which unit, integration, evaluation, and Playwright tests prove the path?