feat: Agent Chat — private 1:1 conversations with agents outside issue context

[OneStepAt4time]

Agent Chat — Private 1:1 Conversations

Priority: P2 (depends on Task Queue #3970 + Agent Profiles #3971)
Reference: multica/server/internal/handler/chat.go, multica/server/pkg/db/queries/chat.sql

---

Overview

Chat is a private 1:1 conversation between a user and an agent — outside any issue context. The agent can't see or change issues. Nobody else can see the conversation. Fits brainstorming, approach discussion, asking questions.

Database Schema

CREATE TABLE chat_session (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    workspace_id UUID NOT NULL REFERENCES workspace(id),
    creator_id UUID NOT NULL REFERENCES member(id),
    agent_id UUID NOT NULL REFERENCES agent(id),
    
    title TEXT,              -- auto-generated from first message
    last_message_at TIMESTAMPTZ,
    last_task_id UUID,       -- for session resumption
    
    -- Lifecycle
    archived BOOLEAN NOT NULL DEFAULT false,
    unread_count INTEGER NOT NULL DEFAULT 0,
    
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE chat_message (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    chat_session_id UUID NOT NULL REFERENCES chat_session(id) ON DELETE CASCADE,
    
    role TEXT NOT NULL,  -- 'user' | 'assistant'
    content TEXT NOT NULL,
    task_id UUID REFERENCES agent_task_queue(id),  -- task that generated this message
    
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_chat_session_creator ON chat_session(creator_id, workspace_id) 
    WHERE archived = false;
CREATE INDEX idx_chat_message_session ON chat_message(chat_session_id);

How Chat Works

1. User opens Chat, picks an agent, sends message
2. Each message enqueues a task for the agent
3. Task uses agent's config but has no issue context
4. Agent runs in fully sandboxed mode:
   • Can answer questions, use skills, MCP, read/write own working directory
   • Cannot see any issue, change any issue, @mention anyone
5. Session resumption: agent's session ID stored, reused on next message
6. If one turn fails, system looks up previous session ID and tries to resume
7. Conversations are private — no one else in workspace can see them

API Endpoints

GET    /api/chat/sessions                 — list chat sessions (active + archived)
GET    /api/chat/sessions/:id             — get session with messages
POST   /api/chat/sessions                 — create new chat session
POST   /api/chat/sessions/:id/messages    — send message (enqueues task)
DELETE /api/chat/sessions/:id             — archive session
POST   /api/chat/sessions/:id/read        — mark as read

WebSocket Events

"chat:message"          // new message in conversation
"chat:done"             // agent finished responding
"chat:session_read"     // session marked as read
"chat:session_deleted"  // session archived

Sandbox Enforcement

The agent's prompt for chat tasks explicitly contains NO issue IDs. Permission checks block any API calls that need issue context. The agent runs with minimal capabilities.

Session Resumption

• First reply establishes a provider session (e.g. Claude session)
• Session ID stored on chat_session.last_task_id → task's session_id
• Next message passes session_id back for continuation
• Single failure doesn't drop memory — system resumes from last successful session

Archive

• Archive removes from active list (still in "Archived" view)
• No "restore" button (noted limitation in Multica)
• Historical messages and session ID preserved

Acceptance Criteria

1. Create chat session with agent → verify in list
2. Send message → verify task enqueued, agent responds
3. Session resumption works (second message continues context)
4. Agent cannot see or modify issues in chat mode
5. Conversations are private (other members can't see)
6. Archive works (removed from active list, data preserved)
7. Multiple concurrent chat sessions work
8. npm run gate passes

E2E Test Requirements

1. Create session → send message → verify agent response
2. Send follow-up → verify session resumption
3. Try to access another user's chat → verify forbidden
4. Archive session → verify removed from active list
5. Verify agent has no issue context in chat mode

Multica Source Reference

• server/internal/handler/chat.go — chat handlers (802 lines)
• server/pkg/db/queries/chat.sql — DB queries

[OneStepAt4time]

Closing in favor of Boss's consolidated spec. See #3982 (Autopilots), #3981 (Squads), #3985 (Inbox), #3983 (Chat), #3979 (Skills).