Update workspace_start fixtures for the link paragraph

Tests/fixtures/characterisation/gitlab-tool-workspace_start.json

@@ -1,5 +1,5 @@
 {
-  "description" : "Start a workspace and give it a task. It is a real git worktree on its own branch with its own agent, and it appears in Bloom's sidebar for the owner to watch and review.\n\nName the project to start it in with 'project', giving the name or the path that project_list reports. Bloom only starts workspaces in repositories it already has, so a project that is not on that list has to be registered with project_add first. If you are yourself running inside a Bloom workspace, leave 'project' out to start it in the project you are already in, or name another project to hand the work to that repository instead. The new workspace is still counted as one you started.\n\nUse it when a task splits into parts that do not need to see each other's edits, and you want them worked on at the same time rather than one after another.\n\nThere are two ways to start it, the two Bloom's own create window offers, and picking the wrong one is the mistake worth avoiding here.\n\n'New branch' is the default and needs nothing said. Commits land on a new branch, and merge into the branch you pick here. Name the branch to cut from with 'base_branch', or leave it out for the project's default branch.\n\n'Existing branch' is 'existing_branch'. Commits land on the branch you pick here, and merge when it does. Use it to carry on, review or fix work that is already on a branch: cutting a new branch off that branch instead gives you a workspace whose diff is empty, because it starts out identical to the branch you named. The branch has to exist already, and git allows one worktree per branch, so a branch another workspace is sitting on is refused rather than opened twice.\n\nTo review an existing GitLab merge request, use 'pull_request' with its number, '#123', or its GitLab URL. Bloom checks out the merge request itself, preserving its base and identity so the Changes, Checks and Merge controls refer to that merge request. Do not create a review branch with base_branch for this purpose.\n\nFrom the owner's own client only, 'project_checkout: true' works in the project's own folder instead of a worktree, on whatever branch it has checked out, with no new branch and no setup. Each project has one such workspace: when it already exists, the prompt starts a new chat in it rather than a second workspace. Changes made there are the owner's real working copy, so use it only when the owner asked for work in the project itself.\n\nName only one of base_branch, existing_branch, pull_request or project_checkout.\n\n'model' and 'effort' are optional. Leave either out to inherit the calling chat's setting, or Bloom's default when the caller has no chat. An explicit effort must be one the selected model supports.\n\n'terminal_chat' is optional and defaults to the app's \"Open new chats in\" setting. When true, Claude Code and Codex open in a visible CLI terminal with the task as their opening prompt. Other agents open in Bloom chat. workspace_say cannot deliver messages to a CLI chat, and notify_when_done does not report its completion. Use terminal_chat: false when you need either.\n\nIt returns as soon as the workspace exists, not when its work is done. The new agent starts on its own and keeps running while you carry on. There is no way to wait for it from here, so do not ask for one and then sit idle: say what you started and get on with your own work.\n\nPass notify_when_done: true to have Bloom tell this chat once, by itself, when the new agent's first turn comes to rest: finished (with its last message), failed (with the reason), or blocked waiting on the owner for a permission prompt or a question. With it, there is no need to tell the new agent to report back when it is done.\n\nThe task you give it is all it gets. It cannot see this conversation, so write the prompt as if to someone who has just opened the project for the first time.\n\nThis costs real money and real disk. Start one because the work genuinely divides, not to parallelise something you could do in a single pass. A workspace that was itself started this way cannot start others.",
+  "description" : "Start a workspace and give it a task. It is a real git worktree on its own branch with its own agent, and it appears in Bloom's sidebar for the owner to watch and review.\n\nName the project to start it in with 'project', giving the name or the path that project_list reports. Bloom only starts workspaces in repositories it already has, so a project that is not on that list has to be registered with project_add first. If you are yourself running inside a Bloom workspace, leave 'project' out to start it in the project you are already in, or name another project to hand the work to that repository instead. The new workspace is still counted as one you started.\n\nUse it when a task splits into parts that do not need to see each other's edits, and you want them worked on at the same time rather than one after another.\n\nThere are two ways to start it, the two Bloom's own create window offers, and picking the wrong one is the mistake worth avoiding here.\n\n'New branch' is the default and needs nothing said. Commits land on a new branch, and merge into the branch you pick here. Name the branch to cut from with 'base_branch', or leave it out for the project's default branch.\n\n'Existing branch' is 'existing_branch'. Commits land on the branch you pick here, and merge when it does. Use it to carry on, review or fix work that is already on a branch: cutting a new branch off that branch instead gives you a workspace whose diff is empty, because it starts out identical to the branch you named. The branch has to exist already, and git allows one worktree per branch, so a branch another workspace is sitting on is refused rather than opened twice.\n\nTo review an existing GitLab merge request, use 'pull_request' with its number, '#123', or its GitLab URL. Bloom checks out the merge request itself, preserving its base and identity so the Changes, Checks and Merge controls refer to that merge request. Do not create a review branch with base_branch for this purpose.\n\nFrom the owner's own client only, 'project_checkout: true' works in the project's own folder instead of a worktree, on whatever branch it has checked out, with no new branch and no setup. Each project has one such workspace: when it already exists, the prompt starts a new chat in it rather than a second workspace. Changes made there are the owner's real working copy, so use it only when the owner asked for work in the project itself.\n\nName only one of base_branch, existing_branch, pull_request or project_checkout.\n\n'model' and 'effort' are optional. Leave either out to inherit the calling chat's setting, or Bloom's default when the caller has no chat. An explicit effort must be one the selected model supports.\n\n'terminal_chat' is optional and defaults to the app's \"Open new chats in\" setting. When true, Claude Code and Codex open in a visible CLI terminal with the task as their opening prompt. Other agents open in Bloom chat. workspace_say cannot deliver messages to a CLI chat, and notify_when_done does not report its completion. Use terminal_chat: false when you need either.\n\nIt returns as soon as the workspace exists, not when its work is done. The new agent starts on its own and keeps running while you carry on. There is no way to wait for it from here, so do not ask for one and then sit idle: say what you started and get on with your own work.\n\nThe answer's 'link' opens the new workspace in Bloom. Put it in your reply, as a markdown link such as [the new workspace](link), and the owner can click straight to it. chat_create, chat_list and workspace_list answer with the same kind of link.\n\nPass notify_when_done: true to have Bloom tell this chat once, by itself, when the new agent's first turn comes to rest: finished (with its last message), failed (with the reason), or blocked waiting on the owner for a permission prompt or a question. With it, there is no need to tell the new agent to report back when it is done.\n\nThe task you give it is all it gets. It cannot see this conversation, so write the prompt as if to someone who has just opened the project for the first time.\n\nThis costs real money and real disk. Start one because the work genuinely divides, not to parallelise something you could do in a single pass. A workspace that was itself started this way cannot start others.",
   "inputSchema" : {
     "properties" : {
       "agent" : {

Tests/fixtures/characterisation/tool-workspace_start.json

@@ -1,5 +1,5 @@
 {
-  "description" : "Start a workspace and give it a task. It is a real git worktree on its own branch with its own agent, and it appears in Bloom's sidebar for the owner to watch and review.\n\nName the project to start it in with 'project', giving the name or the path that project_list reports. Bloom only starts workspaces in repositories it already has, so a project that is not on that list has to be registered with project_add first. If you are yourself running inside a Bloom workspace, leave 'project' out to start it in the project you are already in, or name another project to hand the work to that repository instead. The new workspace is still counted as one you started.\n\nUse it when a task splits into parts that do not need to see each other's edits, and you want them worked on at the same time rather than one after another.\n\nThere are two ways to start it, the two Bloom's own create window offers, and picking the wrong one is the mistake worth avoiding here.\n\n'New branch' is the default and needs nothing said. Commits land on a new branch, and merge into the branch you pick here. Name the branch to cut from with 'base_branch', or leave it out for the project's default branch.\n\n'Existing branch' is 'existing_branch'. Commits land on the branch you pick here, and merge when it does. Use it to carry on, review or fix work that is already on a branch: cutting a new branch off that branch instead gives you a workspace whose diff is empty, because it starts out identical to the branch you named. The branch has to exist already, and git allows one worktree per branch, so a branch another workspace is sitting on is refused rather than opened twice.\n\nTo review an existing GitHub pull request, use 'pull_request' with its number, '#123', or its GitHub URL. Bloom checks out the pull request itself, preserving its base and identity so the Changes, Checks and Merge controls refer to that pull request. Do not create a review branch with base_branch for this purpose.\n\nFrom the owner's own client only, 'project_checkout: true' works in the project's own folder instead of a worktree, on whatever branch it has checked out, with no new branch and no setup. Each project has one such workspace: when it already exists, the prompt starts a new chat in it rather than a second workspace. Changes made there are the owner's real working copy, so use it only when the owner asked for work in the project itself.\n\nName only one of base_branch, existing_branch, pull_request or project_checkout.\n\n'model' and 'effort' are optional. Leave either out to inherit the calling chat's setting, or Bloom's default when the caller has no chat. An explicit effort must be one the selected model supports.\n\n'terminal_chat' is optional and defaults to the app's \"Open new chats in\" setting. When true, Claude Code and Codex open in a visible CLI terminal with the task as their opening prompt. Other agents open in Bloom chat. workspace_say cannot deliver messages to a CLI chat, and notify_when_done does not report its completion. Use terminal_chat: false when you need either.\n\nIt returns as soon as the workspace exists, not when its work is done. The new agent starts on its own and keeps running while you carry on. There is no way to wait for it from here, so do not ask for one and then sit idle: say what you started and get on with your own work.\n\nPass notify_when_done: true to have Bloom tell this chat once, by itself, when the new agent's first turn comes to rest: finished (with its last message), failed (with the reason), or blocked waiting on the owner for a permission prompt or a question. With it, there is no need to tell the new agent to report back when it is done.\n\nThe task you give it is all it gets. It cannot see this conversation, so write the prompt as if to someone who has just opened the project for the first time.\n\nThis costs real money and real disk. Start one because the work genuinely divides, not to parallelise something you could do in a single pass. A workspace that was itself started this way cannot start others.",
+  "description" : "Start a workspace and give it a task. It is a real git worktree on its own branch with its own agent, and it appears in Bloom's sidebar for the owner to watch and review.\n\nName the project to start it in with 'project', giving the name or the path that project_list reports. Bloom only starts workspaces in repositories it already has, so a project that is not on that list has to be registered with project_add first. If you are yourself running inside a Bloom workspace, leave 'project' out to start it in the project you are already in, or name another project to hand the work to that repository instead. The new workspace is still counted as one you started.\n\nUse it when a task splits into parts that do not need to see each other's edits, and you want them worked on at the same time rather than one after another.\n\nThere are two ways to start it, the two Bloom's own create window offers, and picking the wrong one is the mistake worth avoiding here.\n\n'New branch' is the default and needs nothing said. Commits land on a new branch, and merge into the branch you pick here. Name the branch to cut from with 'base_branch', or leave it out for the project's default branch.\n\n'Existing branch' is 'existing_branch'. Commits land on the branch you pick here, and merge when it does. Use it to carry on, review or fix work that is already on a branch: cutting a new branch off that branch instead gives you a workspace whose diff is empty, because it starts out identical to the branch you named. The branch has to exist already, and git allows one worktree per branch, so a branch another workspace is sitting on is refused rather than opened twice.\n\nTo review an existing GitHub pull request, use 'pull_request' with its number, '#123', or its GitHub URL. Bloom checks out the pull request itself, preserving its base and identity so the Changes, Checks and Merge controls refer to that pull request. Do not create a review branch with base_branch for this purpose.\n\nFrom the owner's own client only, 'project_checkout: true' works in the project's own folder instead of a worktree, on whatever branch it has checked out, with no new branch and no setup. Each project has one such workspace: when it already exists, the prompt starts a new chat in it rather than a second workspace. Changes made there are the owner's real working copy, so use it only when the owner asked for work in the project itself.\n\nName only one of base_branch, existing_branch, pull_request or project_checkout.\n\n'model' and 'effort' are optional. Leave either out to inherit the calling chat's setting, or Bloom's default when the caller has no chat. An explicit effort must be one the selected model supports.\n\n'terminal_chat' is optional and defaults to the app's \"Open new chats in\" setting. When true, Claude Code and Codex open in a visible CLI terminal with the task as their opening prompt. Other agents open in Bloom chat. workspace_say cannot deliver messages to a CLI chat, and notify_when_done does not report its completion. Use terminal_chat: false when you need either.\n\nIt returns as soon as the workspace exists, not when its work is done. The new agent starts on its own and keeps running while you carry on. There is no way to wait for it from here, so do not ask for one and then sit idle: say what you started and get on with your own work.\n\nThe answer's 'link' opens the new workspace in Bloom. Put it in your reply, as a markdown link such as [the new workspace](link), and the owner can click straight to it. chat_create, chat_list and workspace_list answer with the same kind of link.\n\nPass notify_when_done: true to have Bloom tell this chat once, by itself, when the new agent's first turn comes to rest: finished (with its last message), failed (with the reason), or blocked waiting on the owner for a permission prompt or a question. With it, there is no need to tell the new agent to report back when it is done.\n\nThe task you give it is all it gets. It cannot see this conversation, so write the prompt as if to someone who has just opened the project for the first time.\n\nThis costs real money and real disk. Start one because the work genuinely divides, not to parallelise something you could do in a single pass. A workspace that was itself started this way cannot start others.",
   "inputSchema" : {
     "properties" : {
       "agent" : {