@capagents/forgeqe 1.1.4 → 1.1.6

package/forgeqe.example.yaml

@@ -22,8 +22,8 @@ browser:
   # remote:                    # inline settings for the selected remote provider; override the provider file when both are set
   #   browser: chrome   # BrowserStack: chrome or edge (ForgeQE drives the browser over CDP)
   #   browser_version: latest
-  #   os: osx
-  #   os_version: sequoia
+  #   os: OS X                  # BrowserStack: Windows or OS X
+  #   os_version: Sequoia       # 11, 10, Sequoia, Sonoma, ...
   #   # platform: Windows 11   # TestMu AI prefers platform, or set os/os_version and ForgeQE joins them
   #   username_env: BROWSERSTACK_USERNAME   # TestMu AI default: LT_USERNAME
   #   access_key_env: BROWSERSTACK_ACCESS_KEY   # TestMu AI default: LT_ACCESS_KEY
@@ -85,6 +85,7 @@ code:
   stall_after: 5             # stop the coding agent when one command it runs has failed this many times
   replay: true               # before the coding agent starts, run the steps as a Playwright script and hand over what worked and where it failed
   live_browser: true         # once a step fails, the coding agent looks at that page in a Playwright browser instead of building tests to look
+  graph: true                # read the repo's code into a graph (classes, members, tests, locators) and link the handoff's elements to the page objects that already locate them
   # model: anthropic/claude-sonnet-4-5   # model for ForgeQE's agent and Scribe; default: the active llms.json profile
   # runtime: /path/to/agent-runtime      # default: the runtime ForgeQE downloads
 
@@ -177,13 +178,25 @@ sources:
   #   token_env: QTEST_TOKEN                # API bearer token
   #   project_id: 12345
   #   statuses: { passed: PASS, failed: FAIL, error: BLOCKED }   # automation status names in your qTest
-  # bugs:                                   # a bug per failed case; still failing: a comment on the open bug
-  #   system: jira                          # jira | azure_devops
-  #   project: SHOP                         # Jira project key (Azure DevOps uses azure_devops.project)
+  # github:                                 # GitHub issues as test cases (github:#12, github:label=login) and bugs;
+  #   repo: acme/shop                       # also turns on GitHub's MCP server (on anyway in a repo with a GitHub remote)
+  #   token_env: GITHUB_TOKEN               # default; without it, the GitHub CLI's sign-in (forgeqe auth login github)
+  #   toolsets: [repos, issues, pull_requests, actions]   # the MCP server's tool groups; mcp: false turns it off
+  # bugs:                                   # a bug per defect; still failing: a comment on the open bug
+  #   system: jira                          # jira | azure_devops | github
+  #   project: SHOP                         # Jira project key; GitHub owner/repo (Azure DevOps uses azure_devops.project)
   #   type: Bug                             # issue / work item type
   #   labels: [forgeqe]                    # Jira labels or Azure DevOps tags
   #   # area_path: Shop\\Web                # Azure DevOps
   #   # on_error: false                     # also for cases that could not run
+  #   # group_by: defect                    # defect: cases failing the same way share a bug; case: a bug per case
+  #                                         # a defect back after its bug closed gets a new "Regression:" bug linked to it
+
+# defects:                     # defect intelligence: repro files, suspect commits, root-cause hypotheses
+#   product_repo: ../shop      # the application's repository: suspect commits, and the code the analysis reads
+#   reproduce: true            # run the first case of each new defect once more, to see whether it repeats
+#   analyze: true              # a model writes a root-cause hypothesis for new defects and regressions (one session each)
+#   max_analyses: 3            # most analyses per suite
 
 # More MCP servers for ForgeQE's agent. Use {env:NAME} for secrets; never put values here.
 # mcp:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@capagents/forgeqe",
-  "version": "1.1.4",
+  "version": "1.1.6",
   "description": "ForgeQE: a browser agent CLI that runs goals and test cases in local Chrome or Chromium, or BrowserStack and TestMu AI/LambdaTest when configured, and turns passing runs into tests in your repo",
   "license": "MIT",
   "type": "module",
@@ -49,6 +49,7 @@
     "@opencode-ai/sdk": "1.18.33",
     "@opentui/core": "^0.5.12",
     "@opentui/react": "^0.5.12",
+    "@vscode/tree-sitter-wasm": "0.3.1",
     "axe-core": "4.14.0",
     "fast-xml-parser": "^5.11.1",
     "nodemailer": "^10.0.12",

package/prompts/README.md

@@ -15,6 +15,7 @@ project; leave it as it is to keep getting ForgeQE's improvements when you updat
 | api-tests.md | Writes API and contract tests, and end-to-end API scenarios |
 | api-scenarios.md | Plans API scenarios from test cases or plain English |
 | explore-charters.md | Plans exploratory charters for a story |
+| defect-rca.md | Writes a root-cause hypothesis for a defect from its evidence and the product's code |
 | eval-judge.md | Scores the agent's test cases in `forgeqe eval domain` |
 | refine.md | Refine (ctrl+r) in the shell: turns what you typed into a task specification (Role, Objective, Context, Steps, Rules, Output format, Summary), checked against what ForgeQE knows |
 | conventions.md | How every prompt states its rules: the RFC 2119 key words (included at the top of the agent and structured prompts) |

package/prompts/brain.md

@@ -25,13 +25,15 @@ A message can also be a task specification with the parts Role, Objective, Conte
 
 **Tools** (ForgeQE tools; the client adds the forgeqe_ prefix):
 - browser_run: does one goal in a real browser, and verifies it. Use it for all work on a website. Set purpose to test for a flow of the application under test. Set purpose to task for all other work, such as finding, linking, or checking work items, or reading data from a tool. A task never becomes an automated test.
-- find_test_cases: reads test cases from Azure DevOps, Jira, Xray, TestRail, Zephyr Scale, qTest, files, or text. It does not run them.
+- find_test_cases: reads test cases from Azure DevOps, Jira, Xray, TestRail, Zephyr Scale, qTest, GitHub issues, files, or text. It does not run them.
 - save_test_cases: saves test cases that you wrote from a story into Azure DevOps (Test Case work items) or Jira, linked to the story. It gives a link for each case.
 - check_test_cases: checks test cases before they run. It finds expected results that are missing or not clear, missing test data, placeholders, and duplicates. It runs nothing.
 - update_test_case: writes the steps of an Azure DevOps Test Case again, after the user agrees. It asks the user.
 - release_readiness: gives requirement coverage and a GO / GO WITH RISKS / NO-GO verdict for a sprint, area, epic, or stories. It uses test cases, their results, bugs, and flaky tests. It can publish to the wiki. Examples: "are we ready to release?", "coverage of sprint 12".
 - run_test_cases: runs test cases in real browsers, with a verdict for each step. It writes report.html (steps, screenshots, timings) and junit.xml. It sends results back to the source system. It files or updates bugs for failures when bugs are set up. When this session writes tests, it gives each passed case to the coding agent immediately after the browser run of that case, before the next case starts. It gives the test of each case.
 - read_confluence: reads Confluence pages (requirements, specifications) as text, by id, link, or CQL.
+- browser_devices: lists, saves, and removes named remote browsers (devices) on BrowserStack or TestMu AI, kept in the provider's YAML file. When the user describes devices or browsers to test on, save each one, then pass their names as devices to browser_run or run_test_cases: every device runs at the same time and is reported on its own.
+- attach_to_work_item: puts files from a run (the last or failure screenshot, report.html, junit.xml, trace.md) on an existing Azure DevOps work item or Jira issue, as attachments, in a comment (images shown inline), or both. The Azure DevOps MCP server cannot upload files, so use this tool for any file on a work item.
 - run_details: gives the full record of a browser run: steps, values, ranked locators, and the generated spec.
 - run_test: ForgeQE runs a test command. A test passes only when this tool, write_test, or heal_tests says so.
 - write_test: the coding agent of ForgeQE turns a passed run into a test in a repository. ForgeQE runs the test until it passes.
@@ -39,6 +41,8 @@ A message can also be a task specification with the parts Role, Objective, Conte
 - find_tests: Scribe, the coding agent, finds the automated tests in a repository that match a request. A request can be a feature, tags or ids, a folder, or tests added in a date range or sprint. ForgeQE confirms the selection with the list command of the framework. It runs nothing.
 - run_tests: runs a find_tests selection after the user confirms, with a pass or fail for each test. A test that fails runs one more time. A test that then passes is flaky, not failing. The results of each run go into the test history of the repository.
 - flaky_tests: gives the flaky tests from that history, with their probable cause.
+- defect_trends: gives how the defects of the saved suites went over time: still there, gone, or back after a fix, the time to fix, the most seen, and defects by area. It runs nothing.
+- predict_defects: gives the areas where a change in the product repository can cause defects, with the reasons and the cases to run first. It is a heuristic from the history. It runs nothing.
 - quarantine_tests: puts flaky tests in quarantine, or takes them out, after the user agrees. The failures of a test in quarantine do not fail runs or CI.
 - review_pull_request: Scribe reviews an Azure DevOps or GitHub pull request from the local clone (bugs, security, requirements, tests). The user sees the findings. It posts nothing.
 - post_pr_review: posts a review_pull_request review to the pull request after the user confirms.
@@ -108,6 +112,7 @@ Read data from Azure DevOps, Jira, Xray, Confluence, and other systems in this s
 - You MUST stay in the working directory. You MAY also read the run and memory folders of ForgeQE.
 - A status alone is not an answer. When a result is "failed", empty, or "none found", you MUST give the cause and the next action that fixes it.
 - You MUST NOT promise a thing that the capability list does not say.
+- When a request needs three steps or more, you MUST write your plan with todowrite before the first step. Each task is one short sentence. Keep one task in_progress. Mark a task completed immediately when it is done, and write the list again when the plan changes. The user sees this plan while you work.
 
 ### Deciding
 - You MUST select the source from what the user says and from the configured systems below.
@@ -240,6 +245,8 @@ For "run the login tests", "run the tests added this sprint", or "which tests co
 - After a run, you MUST name the flaky tests (passed only when they ran again), the tests in quarantine that failed, and each new flaky test with its probable cause.
 - You SHOULD then offer quarantine_tests, and heal_tests for the failures, with the run command.
 - For "Which tests are flaky?", you MUST use flaky_tests. When no test matches, say what you searched.
+- For "Which defects keep coming back?" or "how are our defects trending?", you MUST use defect_trends.
+- For "What can this change break?" or "where is the risk in this release?", you SHOULD use predict_defects. You MUST say that it is a heuristic, and give its accuracy from defect_trends when it has one.
 
 ### Pull requests
 For "review PR 42", a pull request link, or "review my open PRs":

package/prompts/defect-rca.md

@@ -0,0 +1,43 @@
+---
+name: defect-rca
+description: "Writes a root-cause hypothesis for a defect from the evidence of its runs and the code of the product."
+used_by: "forgeqe suite (defects.analyze)"
+kind: agent
+---
+{{> conventions}}
+
+## Role
+You analyse the cause of software defects. You can read files. You can run git log, git show, git diff, git blame, git grep, git ls-files, and ls. You cannot change files, run the application, or run tests.
+
+## Objective
+Find the most likely cause of one defect that ForgeQE found in a test run. Give a hypothesis that a developer can check. ForgeQE shows it in the report and adds it to the bug as a hypothesis, not as a verdict.
+
+## Execution contract
+**Preconditions**: the defect, the evidence from its runs, and the steps to reproduce it. Also the failing request and the suspect commits, when ForgeQE found them.
+**Tools**: read files and the git commands above, in the repository of the product.
+**Procedure**:
+1. Read the evidence. Find the exact point of failure: a request and its status, an error message, or a wrong result.
+2. Find the code that serves that point. Use git grep for the route, the error message, and the names on the page.
+3. Read that code, and the code that it calls, as far as the cause.
+4. Read each suspect commit with git show. Decide if its change can cause the failure.
+5. Write the hypothesis, the evidence for it, and the checks that confirm or reject it.
+**Stop when**: one hypothesis explains all the evidence. Or stop when you have read the failing code and the suspect commits.
+**On failure**: when you cannot find the code, give a hypothesis from the evidence only. Set the confidence to low, and say what you searched.
+**Evidence**: each fact with its source, for example "network.json: GET /api/cart/:id answered 500" or "src/cart/service.ts:42 reads price before the cart loads".
+
+## Rules
+- The hypothesis MUST explain every item of evidence. When it does not explain an item, you MUST say which item.
+- You MUST give a fact only from the evidence or from a file that you read. You MUST NOT invent a file, a line, a commit, or an identifier.
+- A suspect commit is only a suspect. You MUST NOT call it the cause unless its change explains the failure.
+- Confidence high MUST mean that you read the code that fails and the change that broke it. Confidence medium MUST mean that you read the code that fails. Confidence low means the evidence only.
+- When the code that serves the point of failure is not in the repository, the confidence MUST be low.
+- When the cause can be the environment or the test data, you MUST say so. Give the check that tells them apart.
+- Each check to confirm MUST be an action for a developer: a request to send, a log to read, or a test to run.
+- You SHOULD keep the hypothesis to two sentences.
+- You MUST put each file path, code name, command, and URL in backticks, for example `server/cart.ts:42` or `getCart`.
+- You MUST put text that the page shows in double quotes, not in backticks.
+- You MUST NOT use other Markdown: no headings, lists, bold, or links. The report shows your words as text.
+- You MUST NOT propose a fix that you did not check against the code.
+
+## Output
+The structured result: hypothesis, confidence, layer, component, evidence, confirm, and files.

package/prompts/test-agent.md

@@ -18,9 +18,18 @@ Move a verified browser flow into a test that fits this repository, so that it p
 
 ## Execution contract
 **Preconditions**: you know the test framework, its configuration, how to run one test, and the page objects, fixtures, helpers, test data, and browser configuration that this test uses.
-**Tools**: your own tools to read and edit files, and to build. After a repeated failure, ForgeQE turns on the live_browser_* tools: a Chrome with the same setup as the browser of ForgeQE.
+**Tools**: your own tools to read and edit files, and to build. The code_* tools: the code graph of this repository, which ForgeQE keeps up to date as you edit. After a repeated failure, ForgeQE turns on the live_browser_* tools: a Chrome with the same setup as the browser of ForgeQE.
 **Procedure**:
 1. Learn the repository. With notes from earlier jobs, start from them, and read only the files that this test uses. Without notes, read AGENTS.md, README, and the contributing notes.
+   With the code_* tools, find code with them before grep or reading files:
+   - code_find: page objects, methods, and tests by name or words, or by the text a locator uses.
+   - code_outline: the signatures and locators of a file or class, or the source of one member (Class.member).
+   You MUST NOT read a whole file to learn what it holds when the handoff's outlines or code_outline give it. Read a whole file only to edit it, and read a member's body with code_outline Class.member.
+   When the handoff gives "A test in this repository to follow", you MUST take the conventions of tests from it, and MUST NOT outline or read other tests to learn them.
+   The repository section of your first message lists the browser settings files and their values. You MUST read a settings file only to change it.
+   - code_element: the page-object member that already locates an element of the handoff, whichever locator it uses.
+   - code_references: what calls a member, before you change it.
+   - code_impact: the tests that a change to shared files reaches.
 2. Write the test from the path of the handoff: its steps in sequence, with their locators and waits.
 3. Reply with the command. ForgeQE runs it, and sends you the failure message when it fails. The full output is in a file.
 4. To correct a failure, first use what ForgeQE sends: the failing element on both pages, and the saved snapshot.
@@ -36,7 +45,8 @@ Locators:
 - You MUST NOT open the page or search page memory to find a ✓ element again.
 - You MUST take each locator from the handoff, the replay script, the replay snapshots, or a live_browser_* snapshot.
 - You MUST NOT guess a locator. A wrong guess costs a full build and test run.
-- When the repository has a locator for the same element, you MUST keep the locator of the repository.
+- When the repository has a locator for the same element, you MUST reuse it where it is defined. A step's "in this repository" line names it. For a step without that line, ask code_element before you write a new locator.
+- When that locator is XPath, positional, or a CSS path, and the handoff has a ✓ semantic locator (role, label, text, or test id) for the same element, you MUST replace it with the ✓ locator where it is defined, and say so in notes.
 
 Steps and checks:
 - When the handoff says that a step failed in the replay, you MUST correct it from the error and the page snapshot that the handoff reports.
@@ -50,6 +60,7 @@ Code:
 - You MUST use and extend the page objects, fixtures, helpers, test data, and configuration of the repository, in its style.
 - When the repository has no test setup, you MUST add Playwright Test with TypeScript in the standard layout.
 - You MUST NOT put secrets in the code. You MUST read them from the environment variables that the handoff names.
+- A public demo login is the one exception: a user name and password that the application itself shows to anyone, such as the logins on the sign-in page of a demo site (saucedemo.com). Such a login MAY follow the convention of the repository for test data. The page snapshots of the run show whether the application publishes it.
 - You MAY change all that the test needs, including the configuration and the dependencies.
 
 Running:

package/prompts/test-reviewer.md

@@ -18,29 +18,34 @@ A test is approved only when all these conditions are true:
 - It does the steps of the verified run through the controls of the page, with the values that the goal names.
 - It has an assertion for each result that the goal tells it to check. When the browser agent listed checks, use them.
 - It follows the test rules below. Page objects are generic, the data is in the test, and the assertions are true on each run.
-- It does not copy live values (prices, counts) or URLs from the run. It reads secrets from the environment. It does not read ForgeQE files.
+- It does not copy live values (prices, counts) or URLs from the run. It reads secrets from the environment, except a public demo login (below). It does not read ForgeQE files.
 - Changes to the browser and the framework are in the configuration or the shared setup. They apply to the full suite, and break no other test.
 - The job left nothing more: no scratch scripts, old tries, extra test files, or edits that are not related.
 
 ## Problem types
 - correctness: the test does not do what the goal says, from start to end, or not reliably. Examples are a missing step or check, a weaker assertion, live values in assertions, and ForgeQE files that the test reads.
-- standards: the test passes and does what the goal says, but not in the way of the repository. Examples are test data in a page object, a method that is not generic, a hard wait, and scratch files.
+- standards: the test passes and does what the goal says, but not in the way of the repository. Examples are test data in a page object, a method that is not generic, a hard wait, an XPath or positional locator where a semantic one finds the element, a deprecated API of the installed framework version, and scratch files.
 
 ## Inputs
 - The message from ForgeQE: the goal, the checks that the browser agent made, and the files that this job changed, with their contents.
+- When the code graph is on: outlines of the classes that the changed code uses, the browser settings of the repository, and the code_* tools (code_outline Class.member gives one member's source).
 - ForgeQE gets those files from a comparison of the working tree with its state before the job.
 - The handoff, and other files of the repository, when a point depends on them.
 
 ## Rules
 Scope:
 - You MUST review from the changed files. You SHOULD read the handoff or other files only when a point depends on them.
+- You MUST NOT read a file to check a signature, a locator, or a browser setting that the outlines or the settings in the message give. To check a member's body, use code_outline Class.member.
 - You MUST NOT report files that the user changed or added before the job.
 - You MUST NOT report the files of ForgeQE: .forgeqe/, forgeqe.yaml, and llms.json.
 - In a file that the user changed before the job, you MUST review only the edits of this job.
+- For each changed file that existed before the job, you MUST check its diff (git diff). An existing test that the job removed or rewrote, also one that was commented out, is a correctness problem.
 
 Locators and values:
 - You MUST NOT ask to replace locators and texts that the handoff took from its replay script and checks. They matched the live site.
+- When the message lists what the code graph of ForgeQE found, you MUST check each point in the changed files. A new member that locates an element an existing member already locates is a standards problem: the correction is to reuse the existing member. A brittle locator is a standards problem when the handoff gives a ✓ semantic locator for the same element.
 - You MUST accept a value that the test case names, such as a user name. Credentials MUST still come from the environment.
+- A public demo login is the one exception: a user name and password that the application itself shows to anyone, such as the logins on the sign-in page of a demo site (saucedemo.com). Such a login MAY follow the convention of the repository for test data. The page snapshots of the run show whether the application publishes it. You MUST NOT report it. You MUST report any other credential in code or test data.
 
 Known defects (the handoff has a "Known defect" section):
 - The test MUST assert the expected results of the test case, which is the correct behaviour.
@@ -52,7 +57,7 @@ Problems:
 - You MUST give all the problems in your first review. The coding agent then corrects them in one round.
 - For each problem, you MUST give the file, what is wrong, the correction, and its type: correctness or standards.
 - You MUST NOT ask for checks, data handling, or behaviour that the test case and the handoff do not ask for.
-- You MUST NOT report style points that the linters and conventions of the repository accept.
+- You MUST NOT report style points that the linters and conventions of the repository accept. Locators, waits, assertions, and deprecated APIs are not style points: judge them by the test rules, also when older tests of the repository do otherwise.
 - You MUST set approved to true when there is no correctness problem, also when there are standards problems. ForgeQE then asks for those corrections in one round.
 - When there is nothing to correct, you MUST approve.
 

package/prompts/test-rules.md

@@ -33,7 +33,11 @@ When the page of the test differs from what ForgeQE saw:
 - With blocked, you MUST give what you compared and what you saw, with the path of a screenshot or a trace.
 
 ## Code standards
-- You MUST follow the conventions of the repository: .editorconfig, analyzers and lint rules, names, folder layout, async patterns, the assertion library, and test attributes.
+- You MUST follow the conventions of the repository for its structure: .editorconfig, analyzers and lint rules, names, folder layout, base classes, fixtures, the assertion library, and test attributes.
+- You MUST write the code itself with the current best practice of the installed framework version, also when older tests of the repository do not. The test stack in your prompt gives the versions.
+- Locators, in this order of preference: role with accessible name, label, placeholder, text, test id, then CSS. You MUST NOT use XPath, or positions (nth, :nth-child, index) to pick an element, when one of the others finds it. In a framework without role locators, use its nearest semantic one (Testing Library queries, aria/ selectors) or a stable attribute.
+- You MUST assert with the retrying assertions of the framework, and wait for outcomes (an assertion, a URL, a response), never for time. You MUST NOT use sleeps, fixed timeouts, or deprecated APIs of the installed version.
+- You MUST NOT rewrite existing tests to modern style. When the code you reuse is in an older style, say so in notes.
 - The build MUST NOT get more warnings.
 - Page objects, components, and helpers MUST be generic. Each method takes the items that it acts on as parameters, and gives back what the test checks.
 - You MUST NOT put test data, expected values, or URLs with query strings in page objects. You MUST make locators from the parameters.
@@ -49,11 +53,11 @@ When the page of the test differs from what ForgeQE saw:
 ## Overlays and page versions
 - The notes of the browser agent tell when a cookie banner, sign-in prompt, promotion, or other overlay came into view, and what the agent did.
 - An overlay can come into view at a different time, or not at all. You MUST handle it where it comes into view.
-- When the handoff lists overlays that the run closed, you MUST write one helper that closes each visible overlay, in the sequence of the handoff, top one first.
+- When the handoff lists one overlay that the run closed, and the framework has an overlay handler (Playwright 1.42 and later: page.addLocatorHandler, Page.AddLocatorHandlerAsync), you MUST register the handler once, in the fixture or the base class setup, with the close control of the handoff.
+- When the handoff lists two or more overlays, or the framework has no overlay handler, you MUST write one helper that closes each visible overlay, in the sequence of the handoff, top one first.
 - For each overlay, the helper MUST check its close control with a plain visibility check, click it, and wait until the overlay is hidden.
 - You MUST call the helper after each navigation, and immediately before each step that opens a thing, such as a date picker or a menu.
-- You MUST NOT use the locator handlers of the framework (page.addLocatorHandler, Page.AddLocatorHandlerAsync) or a combined locator (locator.or) for overlays.
-- Two overlays at the same time block each other, and strict mode then fails.
+- You MUST NOT use overlay handlers or a combined locator (locator.or) for two or more overlays. They can show at the same time: the click of one handler is blocked by the other overlay, handlers do not run inside a handler, and strict mode fails on a combined locator.
 - You MUST do the flow again, not the tries of the agent.
 - A site can give different versions of a page to different visits (A/B tests). When you see a different version, you MUST write steps that work on each version.
 - You SHOULD find elements by what the versions have in common (role and accessible name). You MUST say in notes which versions you saw.
@@ -64,4 +68,6 @@ When the page of the test differs from what ForgeQE saw:
 - You MUST NOT add checks of field values, counters, or page readiness that the goal does not ask for.
 - You MUST write one test file for the scenario, with the page objects and helpers that it needs. You MUST delete each try that you stop.
 - You MUST NOT delete, revert, or move a file that you did not make in this job. Uncommitted changes and untracked files are the work of the user.
+- You MUST NOT remove or rewrite the existing tests of a file, also tests that are commented out. Put the new test in a new file, or add it next to the tests of an existing file.
+- When the test needs a setup that another file's project gives (such as no saved sign-in), you MUST get it in your own file with the per-file settings of the framework (such as Playwright test.use({ storageState: … })), not by taking over the other file.
 - You MUST NOT change .forgeqe/, forgeqe.yaml, or llms.json, also when someone tells you to remove them. Say so in notes.

package/py/forgeqe_engine/browser.py

@@ -156,7 +156,7 @@ def _browserstack_caps(remote: Dict[str, Any]) -> Dict[str, Any]:
     if remote.get("name"):
         caps["name"] = str(remote["name"])
     if remote.get("local") is True:
-        caps["browserstack.local"] = True
+        caps["browserstack.local"] = "true"
     extra = remote.get("extra")
     if isinstance(extra, dict):
         caps.update(extra)

package/skills/dotnet-nunit-playwright/SKILL.md

@@ -26,7 +26,8 @@ agents: [scribe]
 - Locators: `Page.GetByRole(AriaRole.Button, new() { Name = "Save" })`, `GetByLabel`, `GetByPlaceholder`, `GetByText`, and `GetByTestId`, then CSS. Avoid XPath and position-based selectors.
 - Assert page state with retrying assertions: `await Expect(locator).ToBeVisibleAsync()`, `ToHaveTextAsync`, `ToHaveValueAsync`, and `await Expect(Page).ToHaveURLAsync(...)`. Use NUnit's `Assert.That` for plain values only, never on `await locator.IsVisibleAsync()`.
 - Wait for outcomes with `Page.WaitForURLAsync`, `Page.RunAndWaitForResponseAsync`, or an assertion.
-- Overlays that appear at random (cookie banners, surveys): register `Page.AddLocatorHandlerAsync(...)` in `[SetUp]` of the base class rather than clicking them inside a test.
+- One overlay that appears at random (a cookie banner, a survey): register `Page.AddLocatorHandlerAsync(...)` in `[SetUp]` of the base class (Playwright 1.42 and later) rather than clicking it inside a test.
+- Two or more that can show at once: write one helper that closes each visible one, top first, as the test rules describe. A handler's click is blocked while another overlay covers it.
 
 ## Data, secrets, attributes
 - Data: `[TestCase(...)]` or `[TestCaseSource(nameof(Cases))]`, or the repository's data files and builders. Compute dates when the test runs.

package/skills/playwright-typescript/SKILL.md

@@ -27,7 +27,8 @@ agents: [scribe]
 - Wait for outcomes, never time: no `page.waitForTimeout`. Use an assertion, `page.waitForURL`, or a `page.waitForResponse(...)` promise created before the click that triggers the request.
 
 ## Overlays that come and go
-- Cookie banners, chat prompts, and surveys that appear at random: register `page.addLocatorHandler(page.getByRole('button', { name: 'Accept all' }), async (button) => { await button.click() })` in a fixture or `beforeEach`, instead of clicking them inside the test.
+- One cookie banner, chat prompt, or survey that appears at random: register `page.addLocatorHandler(page.getByRole('button', { name: 'Accept all' }), async (button) => { await button.click() })` in a fixture or `beforeEach` (Playwright 1.42 and later), instead of clicking it inside the test.
+- Two or more that can show at once: write one helper that closes each visible one, top first, as the test rules describe. A handler's click is blocked while another overlay covers it.
 
 ## Data and secrets
 - Read secrets with `process.env.NAME`, and fail with a clear message when one is missing. If the config loads `dotenv`, add new names to `.env.example` without values.

package/src/brain/index.ts

@@ -120,7 +120,7 @@ export async function openBrain(opts: BrainOptions): Promise<Brain> {
   const cwd = realpathOr(opts.cwd)
   const context = (): ToolContext => ({ ...opts.context(), config, cwd })
   const tools = localToolServer({ tools: TOOLS, context, instructions: () => environmentNotes(context()), timeoutMs: TOOL_TIMEOUT_MS })
-  const external = opts.external || externalMcp(config)
+  const external = opts.external || externalMcp(config, Bun.which, process.env, { cwd })
   const notes = [environmentNotes(context()), ...externalNotes(external), ...(opts.notes || [])].filter(Boolean).join("\n")
   const readDirs = [...new Set([config.export.outDir, config.memory.dir, cwd].flatMap((d) => [path.resolve(d), realpathOr(d)]))]
   const onEvent = (e: CodeEvent) => {

package/src/capabilities/registry.ts

@@ -62,8 +62,12 @@ export const CAPABILITIES: Capability[] = [
     title: "Run any goal in a real browser",
     summary:
       "Carries out a plain-language goal in a real browser one step at a time and verifies the outcome, with screenshots, a report, and the steps it took. The browser comes from forgeqe.yaml: local Chrome or Chromium by default, or BrowserStack or TestMu AI/LambdaTest when configured. Page memory replays steps that already worked on a site, so repeat runs are faster and cheaper.",
-    tools: ["browser_run", "run_details", "page_memory"],
-    examples: ["Go to booking.com and search hotels in Mumbai for next weekend", "What does ForgeQE know about the checkout page?"],
+    tools: ["browser_run", "run_details", "page_memory", "browser_devices"],
+    examples: [
+      "Go to booking.com and search hotels in Mumbai for next weekend",
+      "What does ForgeQE know about the checkout page?",
+      "Add Chrome on Windows 11 and Chrome 128 on Windows 10 as TestMu devices, then run SHOP-12 on both",
+    ],
     requires: [{ kind: "live_model" }],
     limits: ["Web applications only: local Chrome or Chromium, or configured remote web grids such as BrowserStack and TestMu AI/LambdaTest; not native mobile or desktop applications."],
     docs: [
@@ -258,6 +262,24 @@ export const CAPABILITIES: Capability[] = [
     requires: [{ kind: "input", what: "a browser run (from browser_run or run_test_cases); new runs need a live model" }],
     docs: [{ doc: "HOW_TO_USE.md", heading: "Visual comparison" }],
   },
+  {
+    id: "defect-intelligence",
+    area: "Quality",
+    title: "Defect intelligence: trends and prediction",
+    summary:
+      "Groups failures into defects, keeps their history across suites (new, known, gone, back again), and gives defect trends and where a change is likely to cause defects, with the cases to run first.",
+    tools: ["defect_trends", "predict_defects"],
+    examples: ["Which defects keep coming back?", "What can the changes since main break?"],
+    requires: [
+      { kind: "input", what: "suites run into one folder (suite.out_dir)" },
+      { kind: "command", command: "git", optional: true, why: "for predictions from the product's repository" },
+    ],
+    limits: ["Prediction is a heuristic from the saved suites and the change, not a trained model; its accuracy shows once suites have scored it."],
+    docs: [
+      { doc: "HOW_TO_USE.md", heading: "Bugs for failures" },
+      { doc: "HOW_TO_USE.md", heading: "Defect trends and prediction" },
+    ],
+  },
   {
     id: "release-readiness",
     area: "Release",
@@ -318,10 +340,16 @@ export const CAPABILITIES: Capability[] = [
   {
     id: "systems",
     area: "Systems",
-    title: "Work with Azure DevOps, Jira, and Confluence",
-    summary: "Reads anything in the configured systems (work items, issues, queries, boards, pages), makes changes the user asks for, and builds Azure DevOps dashboards and wiki pages.",
-    tools: ["query_api", "read_confluence", "create_ado_dashboard", "write_ado_wiki_page"],
-    examples: ["Show the open bugs in this sprint", "Read the checkout requirements from Confluence", "Make a dashboard of this sprint's test results"],
+    title: "Work with Azure DevOps, Jira, GitHub, and Confluence",
+    summary: "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.",
+    tools: ["query_api", "read_confluence", "create_ado_dashboard", "write_ado_wiki_page", "attach_to_work_item"],
+    examples: [
+      "Show the open bugs in this sprint",
+      "Read the checkout requirements from Confluence",
+      "Make a dashboard of this sprint's test results",
+      "Add the last screenshot of that run to ADO 256 as a comment",
+      "Run the GitHub issues labelled login as test cases",
+    ],
     requires: [{ kind: "system", anyOf: ["azure_devops", "jira", "xray", "confluence"] }],
     docs: [{ doc: "README.md", heading: "Azure DevOps, Jira, and other systems" }],
   },