devboxes in Chat

In a connected Slack, Microsoft Teams, Google Chat, Discord, or Telegram channel, people mention @devboxes to ask for work, and devboxes answers there. Connect Slack, Microsoft Teams, Google Chat, Discord, or Telegram sets this up.

chat.web-post and chat.web-messages give you a web conversation with devboxes that needs no chat app. devboxes answers there as it does in a direct message, under your Organization's Chat policy. Only you read and post in your web conversation, and its work can start in every Project of your Organization. A new web conversation starts fresh and doesn't continue an earlier one. A message that names a catalogue bundle as bundle limits the work it starts to that bundle's Blueprints: devboxes chooses one of them for the Project, or asks you when none fits. It lists the work it started or continued, and devboxes can act there on any work you can reach from the CLI, except work that a Linear, Jira, or GitHub issue started or continued. You can close or erase your own web conversation with chat.close-conversation.

Conversations and threads

A reply in the thread continues the conversation. When someone mentions @devboxes in a thread that already holds messages, devboxes reads the thread's earlier messages once: the first 15 in Slack, the thread's opening post and its newest 50 in Microsoft Teams, the first 100 in Google Chat and Discord and on Linear, Jira and GitHub issues, and in Telegram the newest 100 that devboxes saw. In a longer Slack thread, it misses the messages after those 15 that came before the mention. A reply from devboxes that is too long for one message arrives whole, as consecutive messages that break between paragraphs and keep the parts of a split code block in code blocks. Linear shows it as one activity.

devboxes keeps a log of each channel with what everyone there can see: people's messages and its replies, summarized as the log grows, so every new thread in the channel answers with the channel's earlier threads in mind. What a command returned to one person's request stays out of it. A direct message keeps one log for its person. A Linear, Jira, or GitHub issue and a web conversation each keep a log of their own. Every reply also reads your Organization's memory. When a summary leaves out a detail it needs, devboxes opens the messages behind it. Erasing a conversation removes its messages from the log. Anyone in a thread can also ask devboxes to erase messages of its channel's log, and devboxes says what it erased: it forgets them and the memory entries they saved, while the posts stay in the chat. Through the CLI, owners and admins erase any message, and a member the messages they wrote.

devboxes answers in plain words by default. It names files, lines, packages, versions, commands, and error codes only when a person asks for that detail, and it makes technical choices itself instead of asking people to.

Who can act in a connected channel

Anyone who can post in a connected channel can start tasks in its Projects, including people outside your Organization and other apps. Unless the Chat policy lists the operations that Chat may use, it allows every operation that Chat can call.

When the policy allows it, people can also read and continue the tasks that the channel's threads started in those Projects, list their files, and see who asked for a task: the devboxes account name of the person, or their chat account. They can't read or continue tasks from another channel, a direct message, a web conversation, the CLI, or the dashboard until someone moves the task there, or tasks from a Linear, Jira, or GitHub issue or an erased conversation.

To move a task into a thread or a web conversation, a person asks @devboxes there, and devboxes calls sessions.handoff. Everyone the reply answers must be a member of the Organization or have asked for the task's latest work in Chat, and the thread's channel must route the task's Project. A Linear, Jira or GitHub issue can't receive a task. A move happens at once between two channels of the same Slack workspace or Discord server that everyone there can read and nobody else can: no guest belongs to them, no other workspace shares them, and no role or member is denied viewing them. A move between two of the person's own web conversations also happens at once. Any other move changes who can read the task, so devboxes asks the person to confirm. The task moves when they ask again in a later message, if it is still where it was when they first asked. The thread then holds the task: it continues there, and its results post there. Moving is off for a team's Organization and on for one person's until an owner or admin sets it with organizations.update and sessionHandoff.

A task that another open thread holds continues only in that thread, which devboxes links, or in Google Chat the Space that holds it. When the policy allows sessions.input, a person can also pass a message to a task's running work from any of those channels. When another open thread of the same channel holds the task, its results post in that thread, and a request made while its review runs waits there, where the person can see or withdraw it, and starts after the review. A task that a thread of another channel holds takes messages and requests only from that thread. When no open thread holds the task, the request starts from the person's thread once the running step ends, and its results post there. When the policy allows sessions.cancel, a person can also cancel a task from any of those channels if their own request in Chat started its latest work.

With the matching operations in the policy, people in the channel can also change a Project's workspace, hold or ask for merges, connect an issue tracker, set up ways of working that apply to every Project of your Organization, and read the pull requests of those Projects' repositories, including people outside your Organization. What the operations let Chat do lists them.

When the policy allows memory.create, memory.update or memory.erase, people can change Organization memory from a thread in a channel that everyone in the Slack workspace or Discord server can read, so they see the change. devboxes refuses in a direct message, a web conversation, a private channel, a channel that a guest belongs to or that a Discord role or member may not view, Microsoft Teams, Google Chat, Telegram, and on Linear, Jira and GitHub issues. People make those changes with the CLI. When Slack or Discord can't tell devboxes who reads the channel, devboxes changes nothing and asks you to try again.

Connect only channels whose members you trust with those Projects.

Knowing who asks

Some requests need to know who asks. Binding a Project to an issue tracker, turning merging on or off, and merging a pull request need an owner or admin of your Organization. Approving a Blueprint version and marking an integration sensitive need an owner. Any member, whatever their role, can ask to read, set up, or change a way of working. devboxes acts on them only when the chat account that asks is linked to the devboxes account of such a member. The link says which account a chat account speaks for. The role always comes from that account's current membership, so a role change applies to the next request.

Messages written while devboxes answers

When devboxes starts a reply to a person in a thread, it reads every message waiting there, and every message written while it works on that reply. Its one reply answers all the messages that need an answer. Outside a Linear agent session, devboxes posts nothing when none does, such as for thanks, an acknowledgement, or a message to someone else. A message written after devboxes finished its answer, or while devboxes posts the result of a task or checks a waiting request, gets the next reply to a person, together with the other messages written by then. A message from another app's bot informs devboxes and never starts a reply.

When you ask how a task is going, devboxes answers from what devboxes records about it and doesn't interrupt the task. When you ask for work without a pull request and every Blueprint that fits the work has a publish node, which opens a pull request, devboxes starts nothing and asks whether to start the work anyway or to set up a way of working that opens none. Before devboxes starts new work, or records work that waits for other work, it fills the Blueprint's dispatch inputs, and the issue a Blueprint works on, from your message and the thread. When required ones are missing, devboxes asks for all of them in one message, and starts the work once you answer. A follow-up to a task keeps the inputs of its latest Run. A missing input that comes from your Organization's variables needs someone who manages devboxes to set it. When you ask for a different result than a task's, such as another issue or a rewrite, devboxes starts a new task with its own pull request and links the earlier one. When the new result builds on a pull request that hasn't merged, devboxes asks whether to add it to that pull request now or to wait until that pull request is merged, and starts nothing until you answer.

When a reply answers several people, devboxes does only what all of them may do. It refuses a request that not all of them may make, and the refusal names who can ask for it in a message of their own. A task that such a reply starts records everyone whose message devboxes had read, so any of them can stop it from another thread. A request that such a reply sets to wait for other work follows the same rule when its check runs.

Images and files

devboxes sees the PNG, JPEG, GIF, and WebP images posted with the messages that it answers in Slack, Microsoft Teams, Google Chat, Discord, and Telegram, up to 20 MiB of images in one reply, when its model takes images. It sees only the names of images in earlier messages, and keeps no copy of an image it only looks at.

Work that devboxes starts from a Slack, Microsoft Teams, Google Chat, Discord, or Telegram message gets the files posted with that message, and the files of earlier messages in the thread that it names: PDFs, PNG, JPEG, GIF and WebP images, and text, CSV and Markdown files, up to 20 MB a file and 50 MB in total. The work finds them in its workspace, in .devboxes-inputs/, which a pull request never includes. devboxes says which files the work did not get and why, such as a Word or Excel file, which it asks you to send as PDF or CSV. When the work's model can't read PDFs, the work reads their text instead. Work sees only its instruction and its files, never the thread, so devboxes copies the thread messages the work needs into its instruction. devboxes keeps the files that work gets with its Session, and deletes them when the Session is deleted.

When the policy allows sessions.artifacts and chat.post-artifact, people can get the media that their work produced: images, videos, Markdown reports, slides, and documents. When work that a Slack thread started saves images, devboxes posts them into that thread by itself, the images saved at the same time together in one message, or says in the thread why it can't. devboxes posts no file whose content is already in the thread. devboxes posts other media, and shows code, a diff, or a file's contents in a reply, only when a person asks for it in their own message, such as "send me the report" or "paste the diff here". The request also holds for the reply that reports the work it started, so "send me the report when it's done" works. Everyone in the thread can open a posted file. When a person asks for the files in the Channel itself, such as "post the screenshots in the channel", devboxes posts them at the top level of the Channel as one message, with a one-line caption and a link to the thread, once per request. Chat never posts or downloads any other file, such as an archive, a binary, a data file, or a log, and says instead that the file is in the devboxes dashboard. It says the same for media larger than 50 MiB, and in Teams, Google Chat, Linear, and Jira conversations, which refuse to post files.

Workspaces set up from Chat

People in a channel can ask devboxes what a Project's workspace contains, or ask for the tools that their work needs, for example "we build an Android app with JDK 17 and Gradle". When the Chat policy allows images.inspect and images.configure, devboxes proposes the packages and services for a Project that the channel is assigned to. A change replaces the workspace's whole package and service list, so devboxes shows the complete new list and changes the workspace only after the person says yes. With only images.inspect, devboxes tells people what the workspace contains, and that an owner or admin can change it or let Chat change it. Chat can't set variables or secrets. An owner or admin sets them with secrets.set.

The new workspace takes several minutes to build. devboxes tells the person whether it is ready when they ask. Until it is ready, tasks run on the Project's current workspace. When someone asks for work that needs something the new workspace adds, such as a package the request names, devboxes holds that task until the build finishes. A newer version of a package the workspace already has, and security fixes, never hold a task. When a held task starts, devboxes says so in the task's thread. When the build fails, held tasks start on the current workspace, their agent learns what the new workspace would have added and can install it itself, and devboxes says in the thread that the task runs on the earlier workspace. devboxes doesn't build a failed new workspace again by itself. The person can ask devboxes why it failed, or to change the packages and rebuild it.

A Project's first workspace has no earlier one, so every task waits for it. When that build failed on devboxes' side, devboxes builds the workspace again by itself while tasks wait, up to three times, and once more whenever devboxes updates its image builder, and says that the task starts automatically. Once those tries are used up, it says so, and the person can ask devboxes to rebuild the workspace with the same packages now. When the image builder rejected the packages or services, devboxes says why, that it tries the same packages again after its next image builder update, and that the person can also ask devboxes to change the packages and rebuild the workspace. The task starts once an image builds. When the image builder later rejects the packages or services of a workspace that tasks wait for, devboxes says what to change in the threads of the waiting tasks.

Waiting work

When the Chat policy allows chat.add-waiting-work, chat.resolve-waiting-work, and sessions.dispatch, people can ask @devboxes to start something after other work finishes, for example "update the docs after the login fix is done". devboxes starts nothing yet. It records the request as waiting work and replies that it will start once that work finishes. A request can wait for a task that the thread can read, or for an open pull request on github.com in a repository of the channel's Projects that connects through the devboxes GitHub App. devboxes learns of no other link's progress, so for any other link devboxes asks whether to start now or to ask again once that work is done. When the pull request has already merged, devboxes starts the request right away.

A change that someone asks for while the task's work or its automatic review still runs waits the same way, because a review only reads the work. devboxes replies that it will start the change once that work and its review finish.

When a task that a request waits for is free again, because its work and review finished and nothing else is queued for it, devboxes checks the request against that result, wherever the task reports. That includes removing a runner that stopped responding, and an approved pull request starting to wait for its merge. An approved pull request doesn't merge while a change started that way still runs, so the change lands first. When the person who asked wants a waiting request started now, devboxes starts it and removes it. A check runs only while the channel is still assigned to the task's Project. A request that waits for a pull request is checked once, when that pull request closes, whether devboxes or a person merged it. The model reads the result and decides what to do:

• It can start the request. devboxes then removes the request and replies with what it started, in the thread where it was asked. The new task reports its result in that thread.
• A change to the awaited task itself starts whatever the task's result was. Other work starts only after the awaited task succeeded or the awaited pull request merged. When the task failed or was cancelled, or the pull request closed without merging, it asks in the thread what to do instead.
• When the request can't start, for example because the task kept no saved point to continue from, it says why in the thread and keeps the request.
• Otherwise it leaves the request waiting and posts nothing.

When the person who asked is no longer linked to devboxes, or the Chat policy no longer allows sessions.dispatch, the next check drops the request and says so in the thread.

chat.inspect-conversation lists a thread's waiting requests. The person who asked can withdraw one in its thread, and an owner or admin can remove one with chat.resolve-waiting-work. Waiting work exists only in chat channels. A Linear, Jira, or GitHub issue keeps what blocks it in the tracker. Erasing a conversation erases its waiting work.

Work that failed on devboxes' side

devboxes retries work that fails because of a problem on its side, as Failures on devboxes' side explains. The thread hears about retried work once, when the work's last attempt ends.

When devboxes can't do something

When work stops or devboxes can't do what someone asks, devboxes aims to say what is missing and to offer what would help, such as merging a pull request once the person approves. When it doesn't know where the missing work is, it asks. When the Chat policy doesn't allow the operation that would help, devboxes says in plain words what Chat can't do, and that an owner or admin of the named Organization can allow it. What the operations let Chat do lists the operations to allow. Posting a file also needs the operation that lists files, so when the policy allows neither, devboxes says that Chat needs both. When the person's role doesn't allow it, devboxes says that an owner or admin can do it.

When devboxes suggests an operation that became usable from Chat in the last 14 days, it also aims to say that the operation is new, with a one-line note. When the Chat policy doesn't allow that operation, devboxes also says that an owner or admin can allow it. An Organization gets the note once per operation.