Skip to content

Phase 1H: Implement Chat/Cowork/Code desktop shell #54

Description

@mdheller

Objective

Implement the first real Noetica desktop shell around the three invariant top-level modes:

Chat
Cowork
Code

This is the product spine. The goal is not to clone Claude branding or assets, but to match the interaction architecture: native desktop app shell, left rail, mode switcher, mode-specific primary action, recents, bottom composer, model/status affordances, and clear empty states.

Current prerequisite

PR #30 adds the first Tauri feasibility shell. Before this issue is fully complete, the Tauri shell must open a native window locally.

Current branch:

phase-1h-tauri-shell

Current validation target:

cd ~/dev/Noetica
git checkout phase-1h-tauri-shell
git pull
npm run tauri:dev

Product rule

We are not building a web app with a desktop wrapper.
We are building a governed desktop workstation.

The desktop shell must make that visible on first launch.

Command semantics

Target command contract:

noetica app        # primary desktop app UX
noetica start      # operational foreground local service/server mode
noetica open       # browser fallback/admin web mode
noetica service    # OS-native background service lifecycle
noetica dev        # developer-only Next dev server

noetica app is primary.

noetica dev is the only command that should expose raw Next.js output.

noetica start must be operational mode, not the primary product entrypoint.

Required app routes

Create or stabilize these top-level routes/views:

/chat
/cowork
/code

Optional future routes:

/chat/:conversationId
/cowork/:taskId
/code/:sessionId
/settings
/status

Component build sheet

Implement reusable shell components instead of three one-off pages.

Suggested structure:

components/desktop/AppShell.tsx
components/desktop/Sidebar.tsx
components/desktop/ModeSwitcher.tsx
components/desktop/PrimaryActionButton.tsx
components/desktop/NavSection.tsx
components/desktop/RecentsSection.tsx
components/desktop/AccountFooter.tsx
components/desktop/MainPanel.tsx
components/desktop/HeaderBar.tsx
components/desktop/ComposerBar.tsx
components/desktop/StatusChip.tsx
components/desktop/RuntimeStatusBar.tsx
components/desktop/EmptyState.tsx
components/desktop/cards/AdminCard.tsx
components/desktop/cards/WorkflowCard.tsx
components/desktop/cards/RuntimeCard.tsx

Suggested views:

components/modes/ChatView.tsx
components/modes/CoworkView.tsx
components/modes/CodeView.tsx

Suggested config/types:

lib/desktop/modes.ts
lib/desktop/runtime-status.ts
lib/desktop/nav.ts

Shell mode config

Use config-driven mode definitions.

type ModeKey = 'chat' | 'cowork' | 'code'

type ShellModeConfig = {
  key: ModeKey
  label: string
  primaryActionLabel: string
  navItems: Array<{
    id: string
    label: string
    icon?: string
    disabled?: boolean
    badge?: string
  }>
  recentsTitle?: string
  emptyState: {
    title: string
    subtitle?: string
  }
}

Runtime status model

Expose a minimal runtime status object from the UI state layer.

type RuntimeStatus = {
  provider: 'missing' | 'configured' | 'disabled' | 'deferred'
  sourceos: 'disabled' | 'pending' | 'available' | 'unavailable'
  agentMachine: 'not_detected' | 'bootstrap_only' | 'available' | 'error'
  prophetMesh: 'deferred' | 'available'
}

This should drive status chips in the shell.

Visual standard

The target is Claude-class desktop polish, but with Noetica identity.

Must preserve interaction structure:

  • native desktop feeling;
  • dark, low-contrast shell;
  • left rail with stable navigation hierarchy;
  • mode switcher near top;
  • mode-specific primary action;
  • recents list;
  • account/org area at bottom;
  • large main workspace;
  • bottom composer/action bar;
  • model/effort/runtime status affordances.

Must not copy:

  • Claude name;
  • Claude logo;
  • proprietary iconography;
  • exact branded wording;
  • final visual assets.

Noetica must use its own product language:

Noetica
SourceOS
Agent Machine
Prophet Mesh
Governed workstation UI
Route status
Policy status
Memory scope
Execution receipt

Mode 1: Chat

Purpose: everyday conversational agent mode.

Left rail requirements:

Chat active
New chat
Projects
Artifacts
Ask Socioprophet
Customize
Recents
Account/org footer

Main panel requirements:

welcome heading or active conversation
conversation content area
bottom composer
attachment affordance
model/status selector
runtime/provider status chips

Noetica-specific status:

Provider: configured/missing/disabled/deferred
SourceOS route: disabled/pending/available
Agent Machine: not detected/bootstrap/available
Prophet Mesh: deferred

Acceptance:

  • user can understand where to type;
  • recents and projects are obvious;
  • runtime/provider state is visible but unobtrusive;
  • no browser/dev-server UX leaks into the visible app.

Mode 2: Cowork

Purpose: task execution, office/admin work, project workflows.

Left rail requirements:

Cowork active
New task
Projects
Scheduled
Live artifacts
Dispatch
Customize
Recents
Account/org footer

Main panel requirements:

large centered task composer
project/workspace selector
action selector: ask / execute / dispatch
model/effort selector
suggested workflow cards

First-class office/admin modules to reserve now:

Today / Agenda
Inbox / Attention
Documents / Artifacts
Tasks / Commitments
Meetings / Follow-up
Admin Routines

Noetica-specific overlays:

SourceOS route state
AgentPlane/evidence placeholder
policy admission status
memory scope status
dispatch capability status

Acceptance:

  • Cowork feels like an agentic office/admin workbench;
  • it is not just Chat with a different title;
  • office/admin cards are visible or structurally reserved.

Mode 3: Code

Purpose: local coding/operator workflow.

Left rail requirements:

Code active
New session
Routines
Customize
More
Recents
Account/org footer

Main panel requirements:

greeting/status area
overview/models/stats card placeholder
local/project folder selector
bottom code/task composer
accept edits control row
model/effort/local route indicator

Noetica-specific overlays:

local workspace binding
Agent Machine coding readiness
SourceOS local runtime awareness
future Git/GitHub placeholder
audit/receipt placeholder

Acceptance:

  • Code mode feels local-first and operator-ready;
  • not merely a generic chat box;
  • project/folder binding is visible even if initially placeholder.

Office/admin object model

Reserve these first-class objects:

Person
Meeting
Task
Project
Document
Thread
Decision
Artifact
Workflow
Brief

Do not bury these in generic tool menus. They are central to Cowork and Chat.

OS-first SourceOS layer

Reserve shell/status affordances for:

OS status
SourceOS services
Agent Machine
Local providers/models
Permissions
Notifications / scheduled actions

Future OS actions must be:

explicit
permission-gated
auditable
status-visible

No hidden broad shell power.

First implementation order

  1. Unblock Tauri native window from PR Add Tauri desktop feasibility shell #30.
  2. Add desktop shell component directory.
  3. Add AppShell and left rail.
  4. Add ModeSwitcher with Chat/Cowork/Code.
  5. Add mode configs.
  6. Add ChatView, CoworkView, CodeView stubs.
  7. Add ComposerBar.
  8. Add RuntimeStatusBar and status chips.
  9. Add office/admin placeholder cards in Cowork.
  10. Add project/folder placeholder affordance in Code.
  11. Add route wiring for /chat, /cowork, /code.
  12. Add basic visual tokens if needed.

Acceptance criteria

This issue is complete when:

  • native Tauri window can host the Noetica shell;
  • Chat/Cowork/Code exist as top-level modes;
  • left rail, mode switcher, recents, account footer, main panel, and composer exist;
  • runtime status chips exist;
  • Cowork visibly reserves office/admin workflows;
  • Code visibly reserves local/project workflow;
  • Noetica uses its own identity and SourceOS language;
  • browser/dev-server behavior is not presented as primary UX.

Non-goals

  • Do not implement full SourceOS routing here.
  • Do not implement Agent Machine execution here.
  • Do not implement real calendar/mail/docs connectors here.
  • Do not implement final branding/iconography here.
  • Do not choose Electron unless Tauri fails the explicit feasibility gate.

Related

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions