Background
Context
Bricks channels and threads support conversational interactions, but there is currently no way to associate a persistent code project with a channel. Users who want to build software collaboratively through conversation — for example, creating a stickman game with character definitions, style specs, and project scaffolding — have no shared workspace to ground those files and code across turns.
Problem
Without a channel-bound workspace, code and file artifacts produced in conversation are ephemeral and unstructured. There is nowhere to persist the project scaffold, asset definitions, or source files that span multiple threads and multiple turns.
Motivation
Binding a Code Project workspace to a channel mirrors the mental model of tools like Replit, where a project is the durable context around which conversations, files, environment variables, and databases are organized. This unlocks a new product category: conversational software development — where users describe what they want and the agent builds, iterates, and runs it within the channel.
Requirement
Users can bind a Code Project workspace to a channel. The workspace persists file and code entities (e.g., scaffolding, asset definitions, style specs) that are accessible and editable from both the channel view and any thread under that channel. Conversations in the channel or a thread can create, read, update, and delete files in the workspace through natural language.
The initial target scenario is a user creating a browser-based stickman game: the workspace holds stickman character definitions, visual style specs, and project scaffolding; the agent incrementally builds the game through conversation.
Non-goals
- Environment variable and database binding (Replit-style runtime environment) are out of scope for this issue but should be designed as future extension points in the data model.
- Code execution / live preview is out of scope for this issue.
Acceptance Criteria
- Given a channel, when the user binds a Code Project workspace to it, then the workspace is associated with that channel and visible in the channel settings.
- Given a channel with a bound workspace, when the user sends a message asking the agent to create a project file (e.g., "create a stickman character definition"), then the file is created and persisted in the workspace.
- Given a channel with a bound workspace, when the user opens a thread under that channel, then the thread can also read and write files in the same workspace.
- Given a channel with a bound workspace, when the user asks to list project files, then the agent returns the current file tree of the workspace.
- Given a channel with a bound workspace, when the user asks to update a file, then the updated content is persisted and subsequent reads reflect the change.
- Given a channel without a bound workspace, when the user views channel settings, then there is an option to bind or create a Code Project workspace.
Background
Context
Bricks channels and threads support conversational interactions, but there is currently no way to associate a persistent code project with a channel. Users who want to build software collaboratively through conversation — for example, creating a stickman game with character definitions, style specs, and project scaffolding — have no shared workspace to ground those files and code across turns.
Problem
Without a channel-bound workspace, code and file artifacts produced in conversation are ephemeral and unstructured. There is nowhere to persist the project scaffold, asset definitions, or source files that span multiple threads and multiple turns.
Motivation
Binding a Code Project workspace to a channel mirrors the mental model of tools like Replit, where a project is the durable context around which conversations, files, environment variables, and databases are organized. This unlocks a new product category: conversational software development — where users describe what they want and the agent builds, iterates, and runs it within the channel.
Requirement
Users can bind a Code Project workspace to a channel. The workspace persists file and code entities (e.g., scaffolding, asset definitions, style specs) that are accessible and editable from both the channel view and any thread under that channel. Conversations in the channel or a thread can create, read, update, and delete files in the workspace through natural language.
The initial target scenario is a user creating a browser-based stickman game: the workspace holds stickman character definitions, visual style specs, and project scaffolding; the agent incrementally builds the game through conversation.
Non-goals
Acceptance Criteria