feat (AI): Introduce a Developer Chat behind a feature flag

[nishantmonu51]

Feature flag: developerChat

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[ericokuma]

Is this ready to test?

[ericpgreen2]

Code Review

Developed in collaboration with Claude Code and Eric.

Overview

This PR introduces a Developer Chat feature behind a developerChat feature flag, refactoring the existing chat infrastructure to support multiple agent types. The approach is sound and the abstraction via ChatConfig is a reasonable first pass.

Must Fix

1. ChatConfig location

The config lives in core/input/types.ts but is used by Messages.svelte, SidebarChat.svelte, and ChatInput.svelte. It's a chat-wide concern, not input-specific - move to core/types.ts or core/config.ts.

Consider Fixing

2. Type assertions

Replace angle-bracket assertions with satisfies in agent-contexts.ts for better type safety:

// Before
return <RuntimeServiceCompleteBody>{
  analystAgentContext,
};

// After
return {
  analystAgentContext,
} satisfies Partial<RuntimeServiceCompleteBody>;

The angle-bracket syntax (<Type>value) is a type assertion that tells TypeScript "trust me, this is this type" - it won't catch extra properties or typos in property names. The satisfies operator validates that the object conforms to the type while preserving the inferred type, catching errors at compile time.

Tech Debt / Future Work

3. ConversationManager agent-keying and conversation filtering

The ConversationManager singleton is now keyed by instanceId:agent to keep analyst and developer chat state isolated client-side (selected conversation, new conversation draft, etc.). However, listConversationsQuery() still queries with userAgentPattern: "rill%" for both surfaces - so the conversation list returned from the API is shared.

Once Platform provides a surface filtering scheme, the preferred approach is:

• Pass a surface identifier when creating conversations (e.g., rill-developer/1.0, rill-analyst/1.0)
• Filter by that surface when listing conversations
• Simplify back to instanceId-only keying and remove agent-awareness from ConversationManager entirely

The agent field would remain on Conversation (needed for the Complete API), but wouldn't be part of the manager's identity.

4. Context directory coupling (agent-contexts.ts)

The chat feature reaches into dashboard internals (useStableExploreState, createStableTimeControlStoreFromName, isExpressionEmpty). This inverts the dependency direction - if dashboard internals change, chat breaks.

A cleaner pattern would be for each feature to export its own context for chat:

• features/dashboards/chat-context.ts → exports getExploreContextForChat()
• features/editor/chat-context.ts → exports getFileContextForChat()

5. ChatConfig eager store creation

The config objects are defined at module scope:

export const dashboardChatConfig = <ChatConfig>{
  additionalContextStore: getActiveExploreContext(), // Called at import time
  ...
};

This creates derived stores even when chat isn't being used. Consider lazy initialization via a factory function.

[ericpgreen2]

Approving w/ comments to unblock the release, though I note that there's tech debt to clean up.

[AdityaHegde]

Thanks @ericpgreen2 . I have addressed your comments except ConversationManager agent-keying and conversation filtering. That is somewhat involved, lets take it as a follow up before lifting the feature flag.