@capagents/forgeqe 2.4.0 → 2.4.2

package/HOW_TO_USE.md

@@ -120,7 +120,7 @@ Everything ForgeQE can do, by area. ForgeQE's agent answers "can you…?" questi
 | Release | **Reports you can share**: Writes up what the Orchestrator found, such as open defects across projects, release status, or pipeline health, as a page with filters (project, state, priority, assignee, …), charts, and a sortable table, plus Markdown and CSV. Every table is built from evidence: the results of the tool calls the agent made, or a read-only query ForgeQE runs itself, listed on the page's Sources with each raw result kept beside the report. | `write_report` | [docs](#reports-from-the-agent) |
 | Operations | **CI pipelines**: Writes a GitHub Actions or Azure Pipelines workflow that runs ForgeQE, stores the secrets it needs, pushes a branch, and makes the pipeline green. | `push_branch`, `set_ci_secret` | [docs](#8-pipelines) |
 | Systems | **Work with Azure DevOps, Jira, GitHub, and Confluence**: Reads anything in the configured systems (work items, issues, queries, boards, pages), makes changes the user asks for, puts run evidence (screenshots, reports) on work items and issues as attachments or comments, and builds Azure DevOps dashboards and wiki pages. | `read_confluence`, `create_ado_dashboard`, `write_ado_wiki_page`, `attach_to_work_item` | [docs](README.md#azure-devops-jira-and-other-systems) |
-| Systems | **Read any data in Azure DevOps, Jira, Xray, and Confluence**: Reads through a system's REST API what its MCP tools do not cover: pull requests and repositories, test plans and suites, classic releases, and anything else in Azure DevOps, Jira, Xray, or Confluence. Given on every turn once a system is set up, so the agent never turns to the browser or the shell to read it. | `query_api` | [docs](README.md#azure-devops-jira-and-other-systems) |
+| Systems | **Read any data in Azure DevOps, Jira, Xray, and Confluence, and open Azure DevOps pull requests**: Reads through a system's REST API what its MCP tools do not cover: pull requests and repositories, test plans and suites, classic releases, and anything else in Azure DevOps, Jira, Xray, or Confluence. Opens Azure DevOps pull requests, which the API reads cannot. Given on every turn once a system is set up, so the agent never turns to the browser or the shell for them. | `query_api`, `create_ado_pull_request` | [docs](README.md#azure-devops-jira-and-other-systems) |
 | Setup | **What ForgeQE wrote**: Says how much of the code ForgeQE wrote is still in the repository, and gives the trailer and footer that mark a commit message or pull request description covering code it wrote. Works with any repository, whatever system the team uses. | `generated_attribution` | [docs](#generated-code) |
 | Setup | **Every forgeqe command from the shell**: Runs the forgeqe commands no other tool covers when the user asks in words: the context budget, guardrails, prompts (show, diff, check, reset), the domain eval, skills on or off, session logs, saved API sets and packs, pack pipelines, the BI site, a test notification, desktop and mobile doctor and validate, and updating ForgeQE. Reading commands run at once; the others are shown and asked first. | `forgeqe_command` | [docs](#15-commands-cheat-sheet) |
 | Setup | **Setup, skills, and documentation**: Shows the model profiles and MCP servers, installs or repairs the browser engine, creates a forgeqe.yaml, manages skills, and answers any question about ForgeQE from its documentation, this list, and its own code (the prompts, skills, and source it runs). | `forgeqe_setup`, `capabilities`, `playbook`, `use_capabilities` | [docs](#2-scaffold-config) |
@@ -389,6 +389,18 @@ GitHub Models, which ForgeQE used for the engine before, was [retired by GitHub]
 
 **Prompts.** Each file has a short header (`name`, `description`, `used_by`, `kind`) and the prompt; `{{> name}}` includes another prompt (`test-rules` is included in the test, reviewer, and healing prompts, so one edit changes all three). ForgeQE looks in `prompts.dir`, then `.forgeqe/prompts/`, then `~/.forgeqe/prompts/` (for every project), then its own. Changes take effect on the next run or session.
 
+**Your team's prompts.** Instructions of your own for chosen agents go in `.forgeqe/prompts/team/<name>.md` (or `~/.forgeqe/prompts/team/` for every project; a name in the project wins). The header has `name`, `description`, and `for`: the agents' prompts it joins (`brain` for ForgeQE's agent, `test-agent` for Scribe, `browser-extra` for the browser agent, and so on). Its text is added at the end of those prompts, under "Your team's instructions", as written: it is not a template and includes nothing. The web app's Prompts page adds, edits and removes them, and shows each agent's whole prompt with them included; `forgeqe prompts show <prompt>` shows it in the terminal.
+
+```markdown
+---
+name: tag-work-items
+description: "Tests carry the work item they cover"
+for: test-agent, browser-extra
+---
+Tag every test with the Azure DevOps work item it covers.
+If the request names no work item, ask for it.
+```
+
 ```bash
 forgeqe prompts                     # every prompt, what it is for, and where it comes from
 forgeqe prompts show test-agent     # the prompt as the agent gets it (includes expanded; --raw for the file)
@@ -523,7 +535,7 @@ A card says which it did and why (*Extending PracticeTests.Flow · covers 12 of
 
 **Why a test failed.** When ForgeQE's run of Scribe's test fails, the ✗ line and the next attempt say why in the test's own words: dotnet test's Error Message, pytest's `E` lines, or the error with its Expected and Received values (Playwright, Jest, JUnit), not the runner's summary line.
 
-**Keeping Scribe's cost down.** ForgeQE reads the repository's test setup itself before Scribe starts (stack, settings files and their browser values, the test id attribute, base classes, page objects and their methods, one test command) and hands it over, so Scribe does not discover it with dozens of file reads. Each attempt after the first starts a fresh session from a summary of the job (handoff, files changed, what each attempt did, the latest failure), so later attempts cost about what the first did. The summary has a "Tried already, and did not work" list: for each failed attempt, what Scribe said it did (it reports each change in `tried`), how it failed, the locator the test was waiting for and the element that covered it and took the click, both read from the test's output, and whether an earlier attempt already failed on that locator. Scribe must not try those again in the same form and must say what it does differently. `forgeqe heal` keeps the same list across its attempts. `code.max_attempts` (default 3) and `code.max_tokens` (default 1,500,000; `0` turns it off) cap a job, and the token budget is checked during an attempt too, so one long attempt is stopped when the total passes it. The reviewer sorts its issues into correctness (the test does not test what the goal says, or not reliably) and coding standards (test data or credentials in a page object, naming, hard waits, leftovers). Coding standards never fail a test that works: it is accepted, and the coding agent gets one more round (not counted in `max_attempts`) to fix them; if that round breaks the test, ForgeQE puts back the version that passed and lists the standards issues in the notes (`code.tidy: false` skips the round). A test the reviewer rejects twice for correctness stops the job with its issues, since that usually means the test case and the page disagree. When a test passed and the reviewer sent it back, and the changes for the review then break it (or the attempts or the token budget run out first), ForgeQE puts back the version that passed: the result is passed but not approved, with the reviewer's issues in the notes, so you get a working test to finish instead of none. Under each step, the handoff shows that step's part of the page (its section and neighbours, from the replay's page snapshot) instead of whole snapshots. When a test fails, ForgeQE shows the failing element on the test's page at the failure and on the replay's page, so most failures are fixed without opening a browser. Scribe's live browser is switched on only when the same failure repeats, and it does not send a page snapshot after every click or keystroke. `code.max_steps` (default 50) caps the tool calls in one of Scribe's turns. `code.review_profile` runs the reviewer on a cheaper llms.json profile.
+**Keeping Scribe's cost down.** ForgeQE reads the repository's test setup itself before Scribe starts (stack, settings files and their browser values, the test id attribute, base classes, page objects and their methods, one test command) and hands it over, so Scribe does not discover it with dozens of file reads. Each attempt after the first starts a fresh session from a summary of the job (handoff, files changed, what each attempt did, the latest failure), so later attempts cost about what the first did. The summary has a "Tried already, and did not work" list: for each failed attempt, what Scribe said it did (it reports each change in `tried`), how it failed, the locator the test was waiting for and the element that covered it and took the click, both read from the test's output, and whether an earlier attempt already failed on that locator. Scribe must not try those again in the same form and must say what it does differently. `forgeqe heal` keeps the same list across its attempts. `code.max_attempts` (default 3) and `code.max_tokens` (default 1,500,000; `0` turns it off) cap a job, and the token budget is checked during an attempt too, so one long attempt is stopped when the total passes it. Cached input counts at its share of the profile's input price (a session re-reads its own context, and that is most of its input), and in full when no cached price is known, such as with another `code.model`. The reviewer sorts its issues into correctness (the test does not test what the goal says, or not reliably) and coding standards (test data or credentials in a page object, naming, hard waits, leftovers). Coding standards never fail a test that works: it is accepted, and the coding agent gets one more round (not counted in `max_attempts`) to fix them; if that round breaks the test, ForgeQE puts back the version that passed and lists the standards issues in the notes (`code.tidy: false` skips the round). A test the reviewer rejects twice for correctness stops the job with its issues, since that usually means the test case and the page disagree. When a test passed and the reviewer sent it back, and the changes for the review then break it (or the attempts or the token budget run out first), ForgeQE puts back the version that passed: the result is passed but not approved, with the reviewer's issues in the notes, so you get a working test to finish instead of none. Under each step, the handoff shows that step's part of the page (its section and neighbours, from the replay's page snapshot) instead of whole snapshots. When a test fails, ForgeQE shows the failing element on the test's page at the failure and on the replay's page, so most failures are fixed without opening a browser. Scribe's live browser is switched on only when the same failure repeats, and it does not send a page snapshot after every click or keystroke. `code.max_steps` (default 50) caps the tool calls in one of Scribe's turns. `code.review_profile` runs the reviewer on a cheaper llms.json profile.
 
 **Scribe's rulebook: the same mistake once.** When a job passes after a failed test run or a reviewer's change, Scribe's report gives up to three one-line rules that would have avoided the mistake ("Wait for the cart badge with toHaveText before clicking Checkout; it updates after a request"). ForgeQE keeps them in `.forgeqe/scribe-rules.json` in the repository, and every attempt of later jobs, and every healing session, starts with them. A lesson from a job that did not pass, or that passed at once, is not kept: only a fix that worked becomes a rule. The book stays small, since it is sent with each model call: at most 15 rules of one line each; a lesson learned again is merged into its rule (shown as "learned 3 times") instead of added; when it is full, the rule confirmed least and longest ago goes, and a rule not learned again for 180 days expires. The rules are the coding agent's own words, so a rule with a link, something like a token, a destructive command, or wording that tells an agent to drop its instructions is refused, and the agents are told they are hints that never override their instructions or the team's guardrails. Commit the file to share the rules with the team and see each change in review; edit or delete a rule there (the agents cannot change `.forgeqe`). ForgeQE says each new rule as it learns it (`Learned for next time: …`). `code.rulebook: false` turns it off.
 
@@ -870,6 +882,7 @@ The process opens ForgeQE's agent on the first message and keeps it for every la
 | `answer` | `id` (from an `ask`), `choice` (an option id, or `null` to cancel) | Answers the pending question |
 | `continue` | `id` (from a `wait`), `ok` (`true` = Done, continue; `false` = Cancel) | Ends the pending wait |
 | `stop` | | Stops the running turn (Esc or `/stop` in the shell). Nothing when idle |
+| `settings` | `headed` and/or `writeTests` (each `true` or `false`, nothing else) | Changes the chat's choices from now on: whether browser runs are shown (as `--headed`), and whether passed runs become tests (as `--no-code`, off). The next browser run uses them; the agent is told of a change with your next message. Answered with `settings` |
 | `close` | | Stops any turn, closes the agent, stops monitors and the containers it started, writes `closed`, exits 0 |
 
 A line that is not JSON, has an unknown `type`, or misses a field gets `error` `bad_input` with the reason and the first 200 characters of the line; the process goes on. The end of stdin is the same as `close`.
@@ -878,8 +891,9 @@ A line that is not JSON, has an unknown `type`, or misses a field gets `error` `
 
 | `type` | Fields | When |
 |--------|--------|------|
-| `ready` | `protocol` (1), `version`, `cwd`, `writeTests`, `profile` (`name` and `provider`, never a key) | Once, after the config is loaded and checked, before stdin is read |
+| `ready` | `protocol` (1), `version`, `cwd`, `writeTests`, `headed`, `profile` (`name` and `provider`, never a key) | Once, after the config is loaded and checked, before stdin is read |
 | `turn_start` | `id` | A message was accepted |
+| `settings` | `headed`, `writeTests` | After a `settings` line: the choices now in force |
 | `agent` | `id`, `event`: a `CodeEvent` (`stream`, `say`, `start`, `tool`, `plan`, `usage`, `context`, `test`, `info`, …) | While the turn runs |
 | `tool` | `id`, `event`: a `ToolEvent` (`run-start`, `run-event`, `run-done`, `suite-*`, `card`, `info`, `agent`, `code-*`, …) | While the turn runs; `id` is `null` for a background monitor between turns |
 | `ask` | `id` (`ask-N`), `turn`, `question` (`title`, `detail`, `lines`, `options[{id, label}]`) | A tool asks you to choose |
@@ -900,7 +914,7 @@ A line that is not JSON, has an unknown `type`, or misses a field gets `error` `
 A complete exchange (`→` stdout, `←` stdin; `t` left out):
 
 ```text
-→ {"v":1,"seq":1,"type":"ready","protocol":1,"version":"2.3.11","cwd":"/srv/studio/users/ana/workspace","writeTests":true,"profile":{"name":"copilot","provider":"github_copilot"}}
+→ {"v":1,"seq":1,"type":"ready","protocol":1,"version":"2.3.11","cwd":"/srv/studio/users/ana/workspace","writeTests":true,"headed":false,"profile":{"name":"copilot","provider":"github_copilot"}}
 ← {"type":"message","id":"m1","text":"Run SHOP-12 on staging"}
 → {"v":1,"seq":2,"type":"turn_start","id":"m1"}
 → {"v":1,"seq":3,"type":"agent","id":"m1","event":{"type":"code","kind":"stream","id":"p1","text":"I'll run SHOP-12"}}
@@ -1019,7 +1033,7 @@ What happens after the run passes:
 The Activities panel has one line for each verdict and attempt, and `forgeqe` commands outside the terminal UI print the same blocks.
 
    Scribe cannot edit ForgeQE's files or run folders, and cannot run `git clean`, `git reset --hard`, `git stash`, `git restore`, or `git checkout -- <path>`. If it still removes a file that existed before the job, or reverts your uncommitted edits, ForgeQE puts the file back after that attempt and tells the agent.
-8. The job is done when ForgeQE's run passes with a browser and the reviewer approves. It stops as a failure after `max_attempts` attempts, when the job passes `code.max_tokens`, when the reviewer rejects a passing test twice, if the review cannot finish, when the test fails the same way three times in a row (the same output apart from numbers such as timings and line numbers; the second time, Scribe is told its change did not change the failure and to look at the failing step before changing code), or straight away on an auth, API, or context-limit error from the model.
+8. The job is done when ForgeQE's run passes with a browser, the reviewer approves, and the test passes again unchanged until it has passed `code.confirm_runs` times in a row (default 3; `1` runs it once). A test that passes and then fails is flaky: the next attempt is told which run failed and why, and to make that step wait for the page. It stops as a failure after `max_attempts` attempts, when the job passes `code.max_tokens`, when the reviewer rejects a passing test twice, if the review cannot finish, when the test fails the same way three times in a row (the same output apart from numbers such as timings and line numbers; the second time, Scribe is told its change did not change the failure and to look at the failing step before changing code), or straight away on an auth, API, or context-limit error from the model.
 
 `blocked` is a last resort. The first time the agent reports that the app blocks it, ForgeQE sends it back to compare its browser with ForgeQE's and fix the difference; only a second blocked report, with what it compared, ends the job as blocked.
 
@@ -2726,7 +2740,14 @@ On Windows, the dependency folders are linked into worktrees as junctions (no ad
 
 When ForgeQE's agent starts, it connects to an MCP server for each system set up under `sources:`. The server settings come from the same place as everything else: the organization and project, the site URL, and the names of the environment variables that hold the tokens. You don't write MCP config for these.
 
-**Azure DevOps.** Microsoft's [Azure DevOps MCP server](https://github.com/microsoft/azure-devops-mcp), run as `npx -y @azure-devops/mcp <org> -a pat -d core work work-items pipelines`: projects and teams, iterations and boards, work items, and pipelines. Every tool's definition goes to the model with each request, so ForgeQE loads only these groups (about 19 tools, roughly 9.5K tokens, against about 18K for all of them); its own tools cover test plans, wiki pages, dashboards, and pull request reviews, and `query_api` reads anything else, such as classic releases. The organization comes from `org_url` (`https://dev.azure.com/acme` or `https://acme.visualstudio.com`). ForgeQE passes the PAT from `token_env` (default `ADO_PAT`) the way the server wants it; without a PAT it uses your `az login` session. Its tools are `azure_devops_*`. `mcp_domains` adds groups: `test-plans`, `repositories` (repos, branches, pull requests), `wiki`, `search` (code, wikis, and work items), `advanced-security`, or `[all]`. It needs Node.js. Azure DevOps Server (on-premises) isn't supported by Microsoft's server, so it uses ForgeQE's API.
+**Every tool, without paying for every tool.** Each server is started with everything it has: Azure DevOps with all its tool groups, Jira and Confluence with `TOOLSETS=all`, GitHub with every toolset. Every tool given to the model is sent with each of its requests (GitHub's are about 79K tokens, Jira's and Confluence's about 29K, Azure DevOps' about 21K), so a turn gets only the groups of tools its request needs, the way it gets ForgeQE's own capabilities:
+
+- ForgeQE asks each server for its tools when the session starts and keeps the list for a week (`~/.forgeqe/cache/mcp-tools`), then groups them by their names. No server needs a table of its own: tools named by prefix (`repo_…`, `wit_…`, `jira_…`) are grouped by prefix, and a large prefix again by what its tools are about (Jira's sprints, boards, versions); tools named verb first (`list_pull_requests`) by what they act on (pull requests, issues, Dependabot alerts). A group is named `<server>:<group>`, such as `github:pull-request` or `atlassian:jira-sprint`.
+- A turn gets a group when its request names what the group is about ("create a PR", "the current sprint", "dependabot alerts"), when its tools ran in the last turns, or when the agent asks for it with `use_capabilities`: every group is in the list of capabilities the agent has, so none is out of reach and the browser is never the way round a missing tool. A request that names a system ("the GitHub repository", "in Azure DevOps") gets that system's groups from its words, not another's.
+- A small server (under about 3K tokens) is one group, on every turn. A server ForgeQE could not ask keeps all its tools on every turn, as before.
+- `agent.capabilities.always` and `off` take group ids too: `always: [github:issue]`, `off: [github:copilot]`.
+
+**Azure DevOps.** Microsoft's [Azure DevOps MCP server](https://github.com/microsoft/azure-devops-mcp), run with every tool group it has: projects and teams (`azure-devops:core`), iterations and boards (`azure-devops:work`), work items (`azure-devops:wit`), pipelines (`azure-devops:pipeline`), repositories and pull requests (`azure-devops:repo`), wiki (`azure-devops:wiki`), test plans (`azure-devops:testplan`), search (`azure-devops:search`), and security alerts (`azure-devops:advsec`). The first four are on every turn (about 21 tools, roughly 10.7K tokens); the others come as described above. ForgeQE's own tools cover dashboards, wiki pages in a project without a wiki, and opening pull requests (`create_ado_pull_request`) and reviewing them, and `query_api` reads anything else, such as classic releases. The organization comes from `org_url` (`https://dev.azure.com/acme` or `https://acme.visualstudio.com`). ForgeQE passes the PAT from `token_env` (default `ADO_PAT`) the way the server wants it; without a PAT it uses your `az login` session. Its tools are `azure_devops_*`. `mcp_domains` says which groups are on every turn (default `[core, work, work-items, pipelines]`; `[all]` for every group, at about 21K tokens a request); `agent.capabilities.off` switches a group off for good (`[azure-devops:advsec]`). It needs Node.js. Azure DevOps Server (on-premises) isn't supported by Microsoft's server, so it uses ForgeQE's API.
 
 ```yaml
 sources:
@@ -2735,7 +2756,7 @@ sources:
     # project: Shop                       # optional: limit ForgeQE's own API calls to one project
     token_env: ADO_PAT
     mcp: true                     # false: API only
-    mcp_domains: [core, work, work-items, pipelines, repositories]   # optional: the default four, plus repos
+    mcp_domains: [core, work, work-items, pipelines, repositories]   # optional: groups on every turn; the others come when needed
 ```
 
 Microsoft's server has no dashboard tools and can't save queries. Ask for a dashboard ("create a dashboard in QI-Payments with all defects in every state and the current sprint's stories") and ForgeQE's own `create_ado_dashboard` tool does it through the REST API with `ADO_PAT`: it runs each WIQL query once to check it, saves it as a shared query under `Shared Queries/ForgeQE` (updating one of the same name), and creates a team or project dashboard with a work item list or count tile per query, plus optional markdown text. The PAT needs Work Items (read and write) and permission to edit dashboards. Chart widgets are not made through the API; for those the agent uses the browser, which has to be signed in to `dev.azure.com` (`forgeqe login <name>` with a login for it under `logins:`).

package/README.md

@@ -408,10 +408,10 @@ ForgeQE's agent connects to each system's MCP server, configured from the same `
 
 | System | MCP server | Needs |
 |--------|------------|-------|
-| Azure DevOps Services | Microsoft's [Azure DevOps MCP server](https://github.com/microsoft/azure-devops-mcp) (`npx @azure-devops/mcp`), with all its tools: work items, boards, test plans, pipelines, repos, wiki pages, search, and security alerts | Node.js, and `ADO_PAT` or `az login` |
+| Azure DevOps Services | Microsoft's [Azure DevOps MCP server](https://github.com/microsoft/azure-devops-mcp) (`npx @azure-devops/mcp`), with all its tools, each turn getting the groups it needs: work items, boards, test plans, pipelines, repos, wiki pages, search, and security alerts | Node.js, and `ADO_PAT` or `az login` |
 | Jira Cloud, Server/Data Center | [mcp-atlassian](https://github.com/sooperset/mcp-atlassian) (`uvx`), with issues, JQL search, comments, and transitions. `mcp: rovo` uses [Atlassian's hosted server](https://github.com/atlassian/atlassian-mcp-server) instead (Cloud, and an admin must allow API tokens) | uv; `JIRA_EMAIL` and `JIRA_API_TOKEN` (Cloud) or a personal access token (Server/DC) |
 | Confluence | mcp-atlassian, shared with Jira (or its own when Jira isn't set up); Atlassian's hosted server covers it on the same site | `confluence: true` on a Jira Cloud site, or `confluence.url` + tokens |
-| GitHub | GitHub's [hosted MCP server](https://github.com/github/github-mcp-server) with the repos, issues, pull requests, and Actions toolsets (`sources.github.toolsets` changes them), on in a repository with a GitHub remote or when `sources.github` is set. GitHub issues are also a test case source (`github:#12`, `github:acme/shop#12,#13`, `github:label=login`, `github:q=login in:title`): results go back as issue comments, and `sources.bugs.system: github` files bugs as issues. GitHub has no API to upload a screenshot to an issue, so a bug names the run folder instead | `GITHUB_TOKEN`, or the GitHub CLI's sign-in (`forgeqe auth login github`) |
+| GitHub | GitHub's [hosted MCP server](https://github.com/github/github-mcp-server) with every toolset, each turn getting the groups of tools it needs (`sources.github.toolsets` limits them), on in a repository with a GitHub remote or when `sources.github` is set. GitHub issues are also a test case source (`github:#12`, `github:acme/shop#12,#13`, `github:label=login`, `github:q=login in:title`): results go back as issue comments, and `sources.bugs.system: github` files bugs as issues. GitHub has no API to upload a screenshot to an issue, so a bug names the run folder instead | `GITHUB_TOKEN`, or the GitHub CLI's sign-in (`forgeqe auth login github`) |
 | Xray, TestRail, Zephyr Scale, qTest | none; ForgeQE's API | `XRAY_CLIENT_ID` / `XRAY_CLIENT_SECRET`, `TESTRAIL_EMAIL` / `TESTRAIL_API_KEY`, `ZEPHYR_API_TOKEN`, `QTEST_TOKEN` |
 | Anything else | servers you add under `mcp:` | |
 
@@ -433,6 +433,8 @@ Microsoft's Azure DevOps server can't create dashboards, so "create a dashboard
 
 Its wiki tools can only write into a wiki that already exists, so wiki pages go through ForgeQE's `write_ado_wiki_page`. If the project has no wiki yet, that tool creates the project wiki first, along with any missing parent pages. The PAT needs Wiki (read and write).
 
+Pull requests are opened with ForgeQE's `create_ado_pull_request` ("create a PR from feature/cart to main in the shop repository"), since the `repositories` tool group is not loaded by default. It checks that both branches exist, and returns an active pull request between the same branches instead of opening a second one. The PAT needs Code (read and write).
+
 Requirements work too: "write and run test cases for the checkout rules page in Confluence" makes the agent read the page, write one case per rule or acceptance criterion (with the main negative paths), show them, and run them. It saves them into a test system only when you ask.
 
 The agent creates or changes items (a bug, a comment, a status change) only when you ask it to; bugs for failed cases come from `sources.bugs`, not from the agent.