Unclassified

01 — Frontend Scope and Boundaries

Objective

Build the v0 Workbench as a complete, responsive, locally interactive frontend using existing repository components and deterministic demo state.

In scope

  • Login and signup pages
  • Onboarding and role assignment
  • Activation preview
  • Work-first sidebar
  • Workspace and role switching
  • Department-specific Work views
  • Inbox, Tasks, My Queue, Approvals, Notifications, Recent Work, Favorites
  • Activity Feed, Email, Calendar, Meetings, Chat, Calls, Shared Documents
  • Personal Notes, Knowledge Base, Brainstorming Sessions, Activity, Finance Manager
  • Connector Marketplace, Integration Manager, Activation Hub, Capability Manager
  • Customer Zero-only MCP Pool and platform-operator surfaces
  • Contextual Twin signals
  • Four Buttons interaction grammar
  • Governed proposal-to-approval state transitions
  • Responsive desktop, tablet, and mobile behavior
  • Local interactions, drawers, filters, sorting, Kanban movement, previews, and toasts

Out of scope

  • Backend services
  • Database or schema changes
  • Supabase, Neon, Postgres, Redis, Upstash, KV, R2, or Firebase implementation
  • Real connector authentication
  • Real Nango, MCP, provider API, or model calls
  • Real agent execution
  • Real source-system mutation
  • Real Spine writes
  • Billing execution
  • Deployment execution

Frontend contract

The frontend owns presentation, navigation, local interaction state, accessibility, loading states, errors, and proposal review.

The frontend does not own entity assembly, canonical state, provider credentials, policy decisions, execution, or durable workflow state.

Twin law

Twin is the user-facing cognitive assistant.

Twin may:

  • Detect patterns
  • Surface relevant context
  • Ask clarifying questions
  • Explain current work
  • Prepare drafts
  • Prepare bounded workflow proposals
  • Present evidence

Twin may not:

  • Execute autonomously
  • Approve its own proposal
  • Claim a source-system change occurred
  • Claim canonical truth was stored
  • Change a record without explicit user approval

Local simulation law

A locally approved action must be labelled as simulated, prepared, or approved for execution. The UI must not imply that a real external mutation occurred.

Provider-neutral law

Components and frontend contracts must use product concepts such as connection, connector, capability, identity, model, and artifact. They must not hard-code a provider SDK or provider-owned data contract.

Acceptance boundary

This frontend increment is complete when the changed scope builds and typechecks, role assignments resolve the correct Work views, core work surfaces are locally interactive, Twin remains governed, and desktop/mobile navigation works without adding a backend dependency.