@capagents/forgeqe 1.1.7 → 1.1.9

package/HOW_TO_USE.md

@@ -67,7 +67,7 @@ Everything ForgeQE can do, by area. ForgeQE's agent answers "can you…?" questi
 | Release | **Requirement coverage and release readiness**: Gives requirement coverage and a GO / GO WITH RISKS / NO-GO verdict for a sprint, area, epic, or stories, from test cases, results, bugs, and flaky tests; can publish it to the wiki. | `release_readiness` | [docs](#requirement-coverage-and-release-readiness) |
 | Operations | **Scheduled monitoring with alerts**: Runs checks on a schedule and alerts Teams or email when one keeps failing, and again when it recovers. | `monitor` | [docs](#9-monitoring) |
 | Operations | **Teams and email notifications**: Tells the team in Microsoft Teams channels or by email when a suite fails or passes, when a release readiness verdict is in, and when the domain evaluation falls below its gate, with the failing cases, their bugs, and links to the report and the CI build. Each channel picks its events; the agent also posts a summary to a channel when asked. | `notify` | [docs](#17-notifications) |
-| Release | **Reports you can share**: Writes up what ForgeQE's agent found, such as release status across projects, open defects, or pipeline health, as a Markdown file and an HTML page in the reports folder, with a summary in the chat and links to open them. | `write_report` | [docs](#reports-from-the-agent) |
+| Release | **Reports you can share**: Writes up what ForgeQE's agent 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. | `query_api`, `read_confluence`, `create_ado_dashboard`, `write_ado_wiki_page`, `attach_to_work_item` | [docs](README.md#azure-devops-jira-and-other-systems) |
 | 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 questions about ForgeQE from its documentation and this list. | `forgeqe_setup`, `capabilities` | [docs](#2-scaffold-config) |
@@ -390,15 +390,25 @@ The text is the agent's own result. Failed runs show `✗ Task failed` with the
 
 ### Reports from the agent
 
-Ask for a report and ForgeQE's agent writes one you can share: "create a release report for all projects", "write up the open defects", "summarise this sprint's test results as a report". It gathers the facts with its tools (Azure DevOps, Jira, the runs it made), then saves the report with `write_report` as a Markdown file and an HTML page in the reports folder (`export.out_dir`, `.forgeqe/reports/` by default):
+Ask for a report and ForgeQE's agent writes one you can share: "generate a defect report for all open defects", "create a release report for all projects", "summarise this sprint's test results as a report". Every table in it is built from **evidence**, not typed by the model:
+
+- ForgeQE keeps the result of every tool call in the session (its own tools, and the Azure DevOps and Jira MCP servers). A dataset of the report names the calls it comes from, and ForgeQE takes the rows from their results.
+- Or the dataset is a read-only query that ForgeQE runs itself when it writes the report: a WIQL query reads up to 1000 work items with their project, type, state, priority, severity, assignee, area, iteration, dates, and a link. The agent uses this for "all" of something.
+- The agent writes only the summary paragraph.
+
+The report goes to the reports folder (`export.out_dir`, `.forgeqe/reports/` by default):
 
 ```
-.forgeqe/reports/release-status-all-projects-20261009-001512/
-  report.md     # to edit, paste into a wiki, or attach
-  report.html   # to open or share; light and dark, tables scroll on a phone
+.forgeqe/reports/open-defects-all-projects-20261013-101512/
+  report.html         # one file: summary, filters, charts, sortable table, Sources
+  report.md           # the same, to edit, paste into a wiki, or attach
+  open-defects.csv    # each dataset's rows
+  evidence/E1.json    # the raw result of each tool call the report used
 ```
 
-The chat gets a short summary and a card with both paths as links, and **Open the report** appears as a next step. The report holds only what the agent read in that request. To post it, ask for it ("post the report to the release channel") once `notify.channels` is set up; the reports folder is linked when it is served (`notify.report_url`).
+The page adds filters for the columns that are in the data (Project, State, Type, Priority, Severity, Assigned To, Area, Iteration, …, and other columns with a short list of values). The counts, the charts (click a bar to filter by it), and the table follow the filters, and **Export CSV** saves the rows you filtered. **Sources** lists each tool call, when it ran, and how many rows it gave, with a link to its raw result.
+
+The chat gets a short summary and a card with the paths as links, and **Open the report** appears as a next step. To post it, ask for it ("post the report to the release channel") once `notify.channels` is set up; the reports folder is linked when it is served (`notify.report_url`).
 
 ### The screen
 
@@ -637,7 +647,22 @@ What happens after the run passes:
 4. It writes the test from the handoff and the replay script: steps that worked are ported with their locators, steps that failed are fixed first. Every locator, including those for assertions, comes from the replay script, the page snapshots, page memory, or a check on the page; steps where the browser agent ran JavaScript to look around are left out. It does not walk the flow again or build tests to explore. Once a step fails (in the replay, or in its test), ForgeQE switches on its live browser: a Chrome that Playwright drives, set up like ForgeQE's, where it looks at the failing step's page one tool call per action (open, snapshot, click, type, wait, screenshot, run JavaScript, console errors, failed requests). Until then the live browser tools are off, so no tokens go into looking at pages that work. The live browser needs Node.js (`npx`), and Microsoft's Playwright MCP server is downloaded on first use; with `live_browser: false`, or without `npx`, it looks with a small throwaway script instead. When its browser gets a different page than ForgeQE's did (an error, a challenge, a control that will not open), it compares the two browsers (user agent, `navigator.webdriver`, headless, failed requests and CORS errors, headers the framework adds, console errors) and fixes the difference in the repo's browser configuration. It never judges the site with `curl` or `webfetch`.
 5. Scribe does not run the test itself: it may build or compile, then reports the test file and the command that runs only that test, and ForgeQE runs it. If one command it runs fails `stall_after` times in a row within its work (the same build again and again, say), ForgeQE stops that turn and sends the command and its last output back, asking it to change approach. If the same command stalls again, the job stops as a failure with that output in the notes.
 6. ForgeQE runs that command (with `CI=1`) and checks the exit code, and it watches the processes the command starts for a browser launched by Playwright, Puppeteer, Selenium, or Cypress. On a failure it sends the command, exit code, and output back to Scribe. The output is kept short so the error is never cut off: the page dump Playwright puts into a failed assertion ("Aria snapshot:", often thousands of lines) is taken out and saved as `<run>/test-runs/attempt-N-page.aria.yml`, then the start (where the first error and its stack trace are) and the end (the summary) are sent; the full output is in `<run>/test-runs/attempt-N.log`, and the prompt names both files. A command that exits 0 without starting a browser also goes back: the test must drive the app in a browser. If the repo's browser runs on another machine (Selenium Grid, a cloud service, a container), the agent says where and the check is skipped.
-7. A passing test then goes to a separate reviewer agent, which can read files and `git diff` but not change anything. It checks the change against the goal and the test rules: every part of the goal done through the page and asserted, generic page objects with data in the test, no values or URLs copied from the run, browser settings in the repo's configuration, no leftover files. The changed files come inline in its prompt, so it reads nothing again, and it does not ask to replace locators or texts that came from the replay or the checks, since those matched the live site. It judges only what this job changed: ForgeQE records the working tree before the job, so your uncommitted edits, your untracked files, and ForgeQE's own files (`.forgeqe/`, `forgeqe.yaml`, `llms.json`) are never part of the review. It checks the diff of every file that existed before the job: removing or rewriting an existing test, even a commented-out one, is a correctness problem. Credentials come from the environment, except a public demo login that the application itself shows to anyone (such as the logins on saucedemo.com's sign-in page), which may stay in the repo's test data. It gets the outlines of the classes the changed code uses, the repo's browser settings, and the same `code_*` tools, so it checks reuse and settings without reading those files. The code graph also tells it what the job added that it can check in the code: a new member that locates an element an existing member already locates (to reuse instead), and new XPath or position-based locators. If it finds problems, they go back to Scribe as the next attempt.
+7. A passing test then goes to a separate reviewer agent, which can read files and `git diff` but not change anything. It checks the change against the goal and the test rules: every part of the goal done through the page and asserted, generic page objects with data in the test, no values or URLs copied from the run, browser settings in the repo's configuration, no leftover files. The changed files come inline in its prompt, so it reads nothing again, and it does not ask to replace locators or texts that came from the replay or the checks, since those matched the live site. It judges only what this job changed: ForgeQE records the working tree before the job, so your uncommitted edits, your untracked files, and ForgeQE's own files (`.forgeqe/`, `forgeqe.yaml`, `llms.json`) are never part of the review. It checks the diff of every file that existed before the job: removing or rewriting an existing test, even a commented-out one, is a correctness problem. Credentials come from the environment, except a public demo login that the application itself shows to anyone (such as the logins on saucedemo.com's sign-in page), which may stay in the repo's test data. It gets the outlines of the classes the changed code uses, the repo's browser settings, and the same `code_*` tools, so it checks reuse and settings without reading those files. The code graph also tells it what the job added that it can check in the code: a new member that locates an element an existing member already locates (to reuse instead), and new XPath or position-based locators. If it finds problems, they go back to Scribe as the next attempt. The terminal shows the exchange as it happens, in order: the reviewer's verdict with its reason and each issue (✗ correctness, ~ coding standard) with the file and the fix it asks for; then why Scribe tries again and what it is fixing (the reviewer's issues, or the test's first error); then what Scribe says it did and which files it changed; then the next verdict:
+
+```
+⏺ Reviewer asked for changes  attempt 1 of 5 · 1 to fix, 1 coding-standard
+  ⎿ The test never checks that the pie chart is shown.
+    ✗ Correctness · tests/PracticeTests.cs: No assertion on the SVG pie chart.
+        Fix: Assert the chart's heading and SVG are visible.
+    ~ Coding standard · tests/PracticeTests.cs: Test data is inline.
+        Fix: Move it to the page object.
+⏺ Scribe tries again · attempt 2 of 5  the reviewer asked for changes
+  ⎿ → tests/PracticeTests.cs: No assertion on the SVG pie chart. — fix: Assert the chart's heading and SVG are visible.
+  ⎿ Scribe (attempt 2): Added the pie chart assertion · changed tests/PracticeTests.cs, Pages/PracticePage.cs
+⏺ Reviewer approved the test  attempt 2 of 5
+```
+
+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.

package/docs/user-guide.html

@@ -1302,13 +1302,23 @@ Acceptance criteria:
 <p>ForgeQE runs that command (with <code>CI=1</code>) and checks the exit code, and it watches the processes the command starts for a browser launched by Playwright, Puppeteer, Selenium, or Cypress. On a failure it sends the command, exit code, and output back to Scribe. The output is kept short so the error is never cut off: the page dump Playwright puts into a failed assertion (&quot;Aria snapshot:&quot;, often thousands of lines) is taken out and saved as <code>&lt;run&gt;/test-runs/attempt-N-page.aria.yml</code>, then the start (where the first error and its stack trace are) and the end (the summary) are sent; the full output is in <code>&lt;run&gt;/test-runs/attempt-N.log</code>, and the prompt names both files. A command that exits 0 without starting a browser also goes back: the test must drive the app in a browser. If the repo's browser runs on another machine (Selenium Grid, a cloud service, a container), the agent says where and the check is skipped.</p>
 </li>
 <li>
-<p>A passing test then goes to a separate reviewer agent, which can read files and <code>git diff</code> but not change anything. It checks the change against the goal and the test rules: every part of the goal done through the page and asserted, generic page objects with data in the test, no values or URLs copied from the run, browser settings in the repo's configuration, no leftover files. The changed files come inline in its prompt, so it reads nothing again, and it does not ask to replace locators or texts that came from the replay or the checks, since those matched the live site. It judges only what this job changed: ForgeQE records the working tree before the job, so your uncommitted edits, your untracked files, and ForgeQE's own files (<code>.forgeqe/</code>, <code>forgeqe.yaml</code>, <code>llms.json</code>) are never part of the review. It checks the diff of every file that existed before the job: removing or rewriting an existing test, even a commented-out one, is a correctness problem. Credentials come from the environment, except a public demo login that the application itself shows to anyone (such as the logins on saucedemo.com's sign-in page), which may stay in the repo's test data. It gets the outlines of the classes the changed code uses, the repo's browser settings, and the same <code>code_*</code> tools, so it checks reuse and settings without reading those files. The code graph also tells it what the job added that it can check in the code: a new member that locates an element an existing member already locates (to reuse instead), and new XPath or position-based locators. If it finds problems, they go back to Scribe as the next attempt.</p>
-<p>Scribe cannot edit ForgeQE's files or run folders, and cannot run <code>git clean</code>, <code>git reset --hard</code>, <code>git stash</code>, <code>git restore</code>, or <code>git checkout -- &lt;path&gt;</code>. 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.</p>
-</li>
-<li>
-<p>The job is done when ForgeQE's run passes with a browser and the reviewer approves. It stops as a failure after <code>max_attempts</code> attempts, when the job passes <code>code.max_tokens</code>, 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.</p>
+<p>A passing test then goes to a separate reviewer agent, which can read files and <code>git diff</code> but not change anything. It checks the change against the goal and the test rules: every part of the goal done through the page and asserted, generic page objects with data in the test, no values or URLs copied from the run, browser settings in the repo's configuration, no leftover files. The changed files come inline in its prompt, so it reads nothing again, and it does not ask to replace locators or texts that came from the replay or the checks, since those matched the live site. It judges only what this job changed: ForgeQE records the working tree before the job, so your uncommitted edits, your untracked files, and ForgeQE's own files (<code>.forgeqe/</code>, <code>forgeqe.yaml</code>, <code>llms.json</code>) are never part of the review. It checks the diff of every file that existed before the job: removing or rewriting an existing test, even a commented-out one, is a correctness problem. Credentials come from the environment, except a public demo login that the application itself shows to anyone (such as the logins on saucedemo.com's sign-in page), which may stay in the repo's test data. It gets the outlines of the classes the changed code uses, the repo's browser settings, and the same <code>code_*</code> tools, so it checks reuse and settings without reading those files. The code graph also tells it what the job added that it can check in the code: a new member that locates an element an existing member already locates (to reuse instead), and new XPath or position-based locators. If it finds problems, they go back to Scribe as the next attempt. The terminal shows the exchange as it happens, in order: the reviewer's verdict with its reason and each issue (✗ correctness, ~ coding standard) with the file and the fix it asks for; then why Scribe tries again and what it is fixing (the reviewer's issues, or the test's first error); then what Scribe says it did and which files it changed; then the next verdict:</p>
 </li>
 </ol>
+<pre><code>⏺ Reviewer asked for changes  attempt 1 of 5 · 1 to fix, 1 coding-standard
+  ⎿ The test never checks that the pie chart is shown.
+    ✗ Correctness · tests/PracticeTests.cs: No assertion on the SVG pie chart.
+        Fix: Assert the chart's heading and SVG are visible.
+    ~ Coding standard · tests/PracticeTests.cs: Test data is inline.
+        Fix: Move it to the page object.
+⏺ Scribe tries again · attempt 2 of 5  the reviewer asked for changes
+  ⎿ → tests/PracticeTests.cs: No assertion on the SVG pie chart. — fix: Assert the chart's heading and SVG are visible.
+  ⎿ Scribe (attempt 2): Added the pie chart assertion · changed tests/PracticeTests.cs, Pages/PracticePage.cs
+⏺ Reviewer approved the test  attempt 2 of 5
+</code></pre>
+<p>The Activities panel has one line for each verdict and attempt, and <code>forgeqe</code> commands outside the terminal UI print the same blocks.</p>
+<p>Scribe cannot edit ForgeQE's files or run folders, and cannot run <code>git clean</code>, <code>git reset --hard</code>, <code>git stash</code>, <code>git restore</code>, or <code>git checkout -- &lt;path&gt;</code>. 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 <code>max_attempts</code> attempts, when the job passes <code>code.max_tokens</code>, 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.</p>
 <p><code>blocked</code> 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.</p>
 <p>The transcript shows the handover and Scribe's work as it goes; files it writes or edits are marked ✎:</p>
 <pre><code>┃
@@ -1804,22 +1814,31 @@ forgeqe visual approve --page /home  # make this run's /home the baseline (asks
 </article>
 <article class="spec feat" id="cap-reports">
 <div class="hd"><span class="mono">Release</span><h3>Reports you can share</h3></div>
-<p class="ds">Writes up what ForgeQE's agent found, such as release status across projects, open defects, or pipeline health, as a Markdown file and an HTML page in the reports folder, with a summary in the chat and links to open them.</p>
+<p class="ds">Writes up what ForgeQE's agent 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.</p>
 <div class="facts">
 <div class="fact"><span class="mono">Ask it</span><ul class="asks"><li>Create a release report for all projects</li><li>Write up the open defects as a report I can share</li></ul></div>
 <div class="fact"><span class="mono">What it needs</span><ul class="needs"><li><span class="need req">Required</span><span>A live model profile in llms.json (an API key or Microsoft Entra ID sign-in)</span></li></ul></div>
-<div class="fact"><span class="mono">Limits</span><ul class="plainlist"><li>The report holds what the agent read with its tools in this request; it does not invent figures, and it does not publish the page anywhere unless the reports folder is served (notify.report_url).</li></ul></div>
+<div class="fact"><span class="mono">Limits</span><ul class="plainlist"><li>Rows come only from tool results in the session or a query ForgeQE runs; the agent writes only the summary, which is not checked figure by figure.</li><li>A WIQL query reads up to 1000 work items; the page says when a query matched more.</li><li>The page is not published anywhere unless the reports folder is served (notify.report_url).</li></ul></div>
 <div class="fact"><span class="mono">Tools</span><p class="tools"><code>write_report</code></p></div>
 </div>
 <div class="detail"><span class="mono">In detail</span>
 <section class="doc" id="doc-how_to_use-reports-from-the-agent">
 <h4>Reports from the agent</h4>
-<div class="prose"><p>Ask for a report and ForgeQE's agent writes one you can share: &quot;create a release report for all projects&quot;, &quot;write up the open defects&quot;, &quot;summarise this sprint's test results as a report&quot;. It gathers the facts with its tools (Azure DevOps, Jira, the runs it made), then saves the report with <code>write_report</code> as a Markdown file and an HTML page in the reports folder (<code>export.out_dir</code>, <code>.forgeqe/reports/</code> by default):</p>
-<pre><code>.forgeqe/reports/release-status-all-projects-20261009-001512/
-  report.md     # to edit, paste into a wiki, or attach
-  report.html   # to open or share; light and dark, tables scroll on a phone
-</code></pre>
-<p>The chat gets a short summary and a card with both paths as links, and <strong>Open the report</strong> appears as a next step. The report holds only what the agent read in that request. To post it, ask for it (&quot;post the report to the release channel&quot;) once <code>notify.channels</code> is set up; the reports folder is linked when it is served (<code>notify.report_url</code>).</p>
+<div class="prose"><p>Ask for a report and ForgeQE's agent writes one you can share: &quot;generate a defect report for all open defects&quot;, &quot;create a release report for all projects&quot;, &quot;summarise this sprint's test results as a report&quot;. Every table in it is built from <strong>evidence</strong>, not typed by the model:</p>
+<ul>
+<li>ForgeQE keeps the result of every tool call in the session (its own tools, and the Azure DevOps and Jira MCP servers). A dataset of the report names the calls it comes from, and ForgeQE takes the rows from their results.</li>
+<li>Or the dataset is a read-only query that ForgeQE runs itself when it writes the report: a WIQL query reads up to 1000 work items with their project, type, state, priority, severity, assignee, area, iteration, dates, and a link. The agent uses this for &quot;all&quot; of something.</li>
+<li>The agent writes only the summary paragraph.</li>
+</ul>
+<p>The report goes to the reports folder (<code>export.out_dir</code>, <code>.forgeqe/reports/</code> by default):</p>
+<pre><code>.forgeqe/reports/open-defects-all-projects-20261013-101512/
+  report.html         # one file: summary, filters, charts, sortable table, Sources
+  report.md           # the same, to edit, paste into a wiki, or attach
+  open-defects.csv    # each dataset's rows
+  evidence/E1.json    # the raw result of each tool call the report used
+</code></pre>
+<p>The page adds filters for the columns that are in the data (Project, State, Type, Priority, Severity, Assigned To, Area, Iteration, …, and other columns with a short list of values). The counts, the charts (click a bar to filter by it), and the table follow the filters, and <strong>Export CSV</strong> saves the rows you filtered. <strong>Sources</strong> lists each tool call, when it ran, and how many rows it gave, with a link to its raw result.</p>
+<p>The chat gets a short summary and a card with the paths as links, and <strong>Open the report</strong> appears as a next step. To post it, ask for it (&quot;post the report to the release channel&quot;) once <code>notify.channels</code> is set up; the reports folder is linked when it is served (<code>notify.report_url</code>).</p>
 </div>
 </section>
 </div>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@capagents/forgeqe",
-  "version": "1.1.7",
+  "version": "1.1.9",
   "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",

package/prompts/brain.md

@@ -63,7 +63,7 @@ A message can also be a task specification with the parts Role, Objective, Conte
 - logins: manages saved logins. It lists them. It lets the user sign in by hand in a browser (sign_in). It removes a session.
 - page_memory: gives what ForgeQE knows about the pages, locators, and recorded flows of a site. Clear it only when the user asks.
 - notify: posts a message to the Teams or email channels of the team. Use it only when the user asks. Suites, release verdicts, and failed evaluations go to their channels automatically from runs outside the shell.
-- write_report: saves a report that the user asks for as a Markdown file and an HTML page in the reports folder.
+- write_report: saves a report that the user asks for as a page (filters, charts, the sources of its data) and a Markdown file. ForgeQE builds its tables from evidence: the results of tool calls in this session, or a read-only query that it runs itself. You write only the summary.
 - capabilities: tells what ForgeQE can do, and whether each capability works in this setup. It gives what to set up, example requests, limits, and the documentation.
 - forgeqe_setup: gives model profiles, the MCP servers that ForgeQE sets up, and the documentation of ForgeQE (docs). It installs or repairs the browser engine. It creates a forgeqe.yaml (init).
 - push_branch: the only way to push. It refuses the default branch, and it never forces.
@@ -335,7 +335,9 @@ The shell shows replies as markdown in a narrow chat pane. Write them so that th
 - You MUST use bold only for the one word or number that is important in a line, such as a status or a count.
 - You SHOULD use a table only for two or three short columns.
 - You MUST keep your own comments short. You MUST give in full the test cases, tests, and reviews that the user asked for.
-- When the user asks for a report, a write-up, or a summary to share, you MUST collect the facts with your tools and save the report with write_report.
+- When the user asks for a report, a write-up, or a summary to share, you MUST save the report with write_report, with its data as datasets. You MUST NOT type rows, counts, or tables into the report yourself.
+- For "all" of something (all open defects, every project), you SHOULD give the dataset a query (a WIQL query or a REST path), so that ForgeQE reads every item itself. Otherwise, name the tool calls that you made in this session (from: the tool name or the evidence id).
+- The summary MUST hold only facts that are in the datasets. After write_report, give the counts that it returned.
 - You MUST then reply with three to five lines of summary. The shell shows the paths of the report as links, so you MUST NOT repeat them or paste the full report.
 - You MUST NOT end a reply with "If you want, I can…" options. Put the follow-ups that the user will probably want in next, 3 or fewer, each with a short label and the request as the user would type it.
 - You MUST end each turn with the structured answer: reply, outcome (done, failed, or needs_input), and next.

package/src/brain/index.ts

@@ -159,6 +159,10 @@ export async function openBrain(opts: BrainOptions): Promise<Brain> {
         [MCP_NAME]: tools.entry,
       },
       hideTool: (tool) => tool.startsWith(`${MCP_NAME}_`),
+      // ForgeQE's own tools record their results themselves; this adds the other MCP servers' (Azure DevOps, Jira, …).
+      onToolResult: (r) => {
+        if (r.ok && !r.tool.startsWith(`${MCP_NAME}_`) && r.tool.includes("_")) tools.server.evidence.record(r.tool, r.input, r.output)
+      },
       title: "ForgeQE",
     })
   } catch (err) {

package/src/capabilities/registry.ts

@@ -317,11 +317,15 @@ export const CAPABILITIES: Capability[] = [
     area: "Release",
     title: "Reports you can share",
     summary:
-      "Writes up what ForgeQE's agent found, such as release status across projects, open defects, or pipeline health, as a Markdown file and an HTML page in the reports folder, with a summary in the chat and links to open them.",
+      "Writes up what ForgeQE's agent 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.",
     tools: ["write_report"],
     examples: ["Create a release report for all projects", "Write up the open defects as a report I can share"],
     requires: [{ kind: "live_model" }],
-    limits: ["The report holds what the agent read with its tools in this request; it does not invent figures, and it does not publish the page anywhere unless the reports folder is served (notify.report_url)."],
+    limits: [
+      "Rows come only from tool results in the session or a query ForgeQE runs; the agent writes only the summary, which is not checked figure by figure.",
+      "A WIQL query reads up to 1000 work items; the page says when a query matched more.",
+      "The page is not published anywhere unless the reports folder is served (notify.report_url).",
+    ],
     docs: [{ doc: "HOW_TO_USE.md", heading: "Reports from the agent" }],
   },
   {

package/src/cases/api.ts

@@ -16,37 +16,88 @@ export type ApiQuery = {
 }
 
 const WIQL_TOP = 50
+/** What a report may read in one WIQL search. */
+export const REPORT_WIQL_TOP = 1000
 const WIQL_FIELDS = ["System.Id", "System.WorkItemType", "System.Title", "System.State", "System.AssignedTo", "System.ChangedDate", "System.IterationPath"]
+/** Read too when the organization has them; a process without one of them falls back to WIQL_FIELDS. */
+const WIQL_MORE = ["System.TeamProject", "Microsoft.VSTS.Common.Priority", "Microsoft.VSTS.Common.Severity", "System.AreaPath", "System.CreatedDate", "System.Tags"]
+const BATCH = 200
+
+export type WorkItemRow = {
+  id: number
+  project?: string
+  type?: unknown
+  title?: unknown
+  state?: unknown
+  priority?: unknown
+  severity?: unknown
+  assignedTo?: string
+  area?: unknown
+  iteration?: unknown
+  tags?: unknown
+  created?: unknown
+  changed?: unknown
+  url: string
+}
 
 /**
  * A WIQL search: Azure DevOps answers it with ids only (a POST, but WIQL has no statement that changes anything), so
- * the first WIQL_TOP are read back with their main fields in one batch read.
+ * the first `top` are read back with their main fields in batch reads.
  */
-async function adoWiql(cfg: SourcesConfig, wiql: string, project?: string): Promise<unknown> {
+export async function adoWorkItems(cfg: SourcesConfig, wiql: string, project?: string, top = WIQL_TOP): Promise<{ count: number; total: number; items: WorkItemRow[] }> {
   const { ado, auth } = adoSettings(cfg)
   const org = ado.orgUrl.replace(/\/+$/, "")
   const scope = project || ado.project
   const base = scope ? `${org}/${encodeURIComponent(scope)}` : org
   const { data } = await http<{ workItems?: { id: number }[]; workItemRelations?: { source?: { id: number } | null; target?: { id: number } }[] }>(
-    `${base}/_apis/wit/wiql?api-version=7.1&$top=${WIQL_TOP}`,
+    `${base}/_apis/wit/wiql?api-version=7.1&$top=${top}`,
     { auth, body: { query: wiql } },
   )
-  const ids = [...new Set([...(data.workItems || []).map((w) => w.id), ...(data.workItemRelations || []).flatMap((r) => [r.source?.id, r.target?.id])])].filter((id): id is number => typeof id === "number").slice(0, WIQL_TOP)
-  if (!ids.length) return { count: 0, items: [] }
-  const batch = await http<{ value: { id: number; fields: Record<string, unknown> }[] }>(`${org}/_apis/wit/workitemsbatch?api-version=7.1`, { auth, body: { ids, fields: WIQL_FIELDS } })
+  const all = [...new Set([...(data.workItems || []).map((w) => w.id), ...(data.workItemRelations || []).flatMap((r) => [r.source?.id, r.target?.id])])].filter((id): id is number => typeof id === "number")
+  const ids = all.slice(0, top)
+  const read = async (fields: string[]) => {
+    const out: { id: number; fields: Record<string, unknown> }[] = []
+    for (let i = 0; i < ids.length; i += BATCH) {
+      const batch = await http<{ value: { id: number; fields: Record<string, unknown> }[] }>(`${org}/_apis/wit/workitemsbatch?api-version=7.1`, { auth, body: { ids: ids.slice(i, i + BATCH), fields } })
+      out.push(...batch.data.value)
+    }
+    return out
+  }
+  const values = ids.length ? await read([...WIQL_FIELDS, ...WIQL_MORE]).catch(() => read(WIQL_FIELDS)) : []
   const name = (v: unknown) => (v && typeof v === "object" ? String((v as { displayName?: string }).displayName || "") : String(v || ""))
   return {
     count: ids.length,
-    items: batch.data.value.map((w) => ({
-      id: w.id,
-      type: w.fields["System.WorkItemType"],
-      title: w.fields["System.Title"],
-      state: w.fields["System.State"],
-      assignedTo: name(w.fields["System.AssignedTo"]) || undefined,
-      changed: w.fields["System.ChangedDate"],
-      iteration: w.fields["System.IterationPath"],
-    })),
-    note: `Read each one in full with path <project>/_apis/wit/workitems/<id>?$expand=all.${ids.length === WIQL_TOP ? ` Only the first ${WIQL_TOP} are listed; narrow the query for the rest.` : ""}`,
+    total: all.length,
+    items: values.map((w) => {
+      const f = w.fields
+      const itemProject = String(f["System.TeamProject"] || scope || "")
+      return {
+        id: w.id,
+        ...(f["System.TeamProject"] ? { project: String(f["System.TeamProject"]) } : {}),
+        type: f["System.WorkItemType"],
+        title: f["System.Title"],
+        state: f["System.State"],
+        ...(f["Microsoft.VSTS.Common.Priority"] !== undefined ? { priority: f["Microsoft.VSTS.Common.Priority"] } : {}),
+        ...(f["Microsoft.VSTS.Common.Severity"] !== undefined ? { severity: f["Microsoft.VSTS.Common.Severity"] } : {}),
+        assignedTo: name(f["System.AssignedTo"]) || undefined,
+        ...(f["System.AreaPath"] ? { area: f["System.AreaPath"] } : {}),
+        iteration: f["System.IterationPath"],
+        ...(f["System.Tags"] ? { tags: f["System.Tags"] } : {}),
+        ...(f["System.CreatedDate"] ? { created: f["System.CreatedDate"] } : {}),
+        changed: f["System.ChangedDate"],
+        url: `${org}/${itemProject ? `${encodeURIComponent(itemProject)}/` : ""}_workitems/edit/${w.id}`,
+      }
+    }),
+  }
+}
+
+async function adoWiql(cfg: SourcesConfig, wiql: string, project?: string): Promise<unknown> {
+  const { count, items } = await adoWorkItems(cfg, wiql, project, WIQL_TOP)
+  if (!count) return { count: 0, items: [] }
+  return {
+    count,
+    items,
+    note: `Read each one in full with path <project>/_apis/wit/workitems/<id>?$expand=all.${count === WIQL_TOP ? ` Only the first ${WIQL_TOP} are listed; narrow the query for the rest, or pass the query to write_report, which reads up to ${REPORT_WIQL_TOP}.` : ""}`,
   }
 }
 
@@ -85,31 +136,33 @@ function clipJson(data: unknown): unknown {
  * Read-only requests with the credentials from forgeqe.yaml and the environment: GET and WIQL searches for Azure
  * DevOps, GET for Jira (Xray Server/Data Center is under Jira's /rest/raven), GraphQL queries for Xray Cloud.
  */
-export async function queryApi(cfg: SourcesConfig, q: ApiQuery): Promise<unknown> {
+export async function queryApi(cfg: SourcesConfig, q: ApiQuery, opts: { full?: boolean } = {}): Promise<unknown> {
+  // A report reads the whole answer; the agent gets it clipped, so it fits its context.
+  const clip = opts.full ? (d: unknown) => d : clipJson
   switch (q.system) {
     case "azure_devops": {
-      if (q.wiql?.trim()) return clipJson(await adoWiql(cfg, q.wiql, q.project))
+      if (q.wiql?.trim()) return opts.full ? adoWorkItems(cfg, q.wiql, q.project, REPORT_WIQL_TOP) : clipJson(await adoWiql(cfg, q.wiql, q.project))
       if (!q.path) throw new Error("path or wiql is required for azure_devops")
       const { ado, auth } = adoSettings(cfg)
       let url = resolve(q.path, adoBases(ado.orgUrl), "Azure DevOps")
       if (!/[?&]api-version=/.test(url)) url += `${url.includes("?") ? "&" : "?"}api-version=7.1`
-      return clipJson((await http(url, { auth })).data)
+      return clip((await http(url, { auth })).data)
     }
     case "jira": {
       if (!q.path) throw new Error("path is required for jira")
       const j = jiraApi(cfg)
-      return clipJson((await http(resolve(q.path, [j.url], "Jira"), { auth: j.auth })).data)
+      return clip((await http(resolve(q.path, [j.url], "Jira"), { auth: j.auth })).data)
     }
     case "confluence": {
       if (!q.path) throw new Error("path is required for confluence")
       const c = confluenceApi(cfg)
-      return clipJson((await http(resolve(q.path, [c.url], "Confluence"), { auth: c.auth })).data)
+      return clip((await http(resolve(q.path, [c.url], "Confluence"), { auth: c.auth })).data)
     }
     case "xray": {
       if (cfg.jira && !cfg.jira.cloud) throw new Error("Xray Server/Data Center is part of Jira: use system jira with a /rest/raven/1.0/... path.")
       if (!q.query) throw new Error("query (GraphQL) is required for xray")
       if (isMutation(q.query)) throw new Error("query_api only reads; GraphQL mutations are not allowed.")
-      return clipJson(await xrayGraphql(cfg, await xrayCloudToken(cfg), q.query, q.variables || {}))
+      return clip(await xrayGraphql(cfg, await xrayCloudToken(cfg), q.query, q.variables || {}))
     }
     default:
       throw new Error(`Unknown system "${String(q.system)}". Use azure_devops, jira, xray, or confluence.`)

package/src/code/exchange.ts

@@ -0,0 +1,53 @@
+import type { Card } from "../card.ts"
+import type { CodeEvent } from "../types.ts"
+
+/**
+ * The exchange between Scribe and the reviewer, as the shell and the CLI show it: what the reviewer found and why,
+ * why Scribe tries again and what it is fixing, and what Scribe says it did. One place, so both say the same.
+ */
+
+type Review = Extract<CodeEvent, { kind: "review" }>
+type Attempt = Extract<CodeEvent, { kind: "attempt" }>
+type Answer = Extract<CodeEvent, { kind: "answer" }>
+
+const clip = (t: string, n: number) => {
+  const s = t.replace(/\s+/g, " ").trim()
+  return s.length <= n ? s : `${s.slice(0, n - 1)}…`
+}
+
+/** "✗ Does not test the goal · tests/Practice.cs: the pie chart is never checked", then the fix under it. */
+export function reviewCard(e: Review): Card {
+  const correctness = e.issues.filter((i) => i.kind !== "standards").length
+  const standards = e.issues.length - correctness
+  const count = [correctness ? `${correctness} to fix` : "", standards ? `${standards} coding-standard` : ""].filter(Boolean).join(", ")
+  return {
+    status: e.approved ? "ok" : "fail",
+    title: e.approved ? (standards ? "Reviewer approved the test, with coding-standard notes" : "Reviewer approved the test") : "Reviewer asked for changes",
+    stats: [`attempt ${e.attempt} of ${e.max}`, count].filter(Boolean).join(" · "),
+    body: [
+      ...(e.summary ? [clip(e.summary, 400)] : []),
+      ...(e.issues.length ? [""] : []),
+      ...e.issues.flatMap((i) => [
+        // ✗ marks what makes the test wrong, ~ how it is written: the colours follow the mark.
+        `${i.kind === "standards" ? "~ Coding standard" : "✗ Correctness"}${i.file ? ` · ${i.file}` : ""}: ${clip(i.problem, 300)}`,
+        ...(i.fix ? [`    Fix: ${clip(i.fix, 300)}`] : []),
+      ]),
+    ],
+  }
+}
+
+/** "Scribe · attempt 2 of 5 · the reviewer asked for changes", then each thing it was asked to fix. */
+export function attemptCard(e: Attempt): Card {
+  return {
+    status: "info",
+    title: `Scribe tries again · attempt ${e.attempt} of ${e.max}`,
+    ...(e.why ? { stats: e.why } : {}),
+    body: e.fixing.map((f) => `→ ${clip(f, 300)}`),
+  }
+}
+
+/** "Scribe (attempt 2): Moved the values into PracticePage · changed tests/Practice.cs, pages/PracticePage.cs". */
+export function answerText(e: Answer): string {
+  const files = e.changed.length ? `changed ${e.changed.slice(0, 4).join(", ")}${e.changed.length > 4 ? ` +${e.changed.length - 4} more` : ""}` : ""
+  return `Scribe (attempt ${e.attempt}): ${[e.notes ? clip(e.notes, 300) : "", files].filter(Boolean).join(" · ")}`
+}

package/src/code/loop.ts

@@ -38,6 +38,7 @@ import {
   standardsFixPrompt,
   type AgentReport,
   type ExistingTest,
+  type ReviewIssue,
 } from "./prompt.ts"
 import { openReviewer, type Reviewer } from "./review.ts"
 import { runTestCommand } from "./testrun.ts"
@@ -254,6 +255,9 @@ export async function runCodeAgent(opts: {
   let spent: Usage = { input: 0, output: 0 }
   const attemptLog: string[] = []
   let nextTask: string | null = null
+  /** Why the next attempt runs and what it is to fix, as the shell shows it: "the reviewer asked for changes", its issues. */
+  let next: { why: string; fixing: string[] } = { why: "", fixing: [] }
+  const issueText = (i: ReviewIssue) => `${i.file ? `${i.file}: ` : ""}${i.problem}${i.fix ? ` — fix: ${i.fix}` : ""}`
   let notesText: string | undefined = known ? notesSection(known) : undefined
   // The repository's test setup, read by ForgeQE without a model; Scribe starts from it instead of a reading turn.
   const repoProfile = buildProfile(repo)
@@ -374,7 +378,7 @@ export async function runCodeAgent(opts: {
         session = await (opts.open || openSession)(sessionOptions())
         result.sessionId = session.sessionId
         saveSession()
-        emit({ type: "code", kind: "info", text: `Scribe starts attempt ${attempt} in a fresh session, from a summary of the job so far` })
+        emit({ type: "code", kind: "attempt", attempt, max: allowed, why: next.why, fixing: next.fixing })
         prompt = nextAttemptPrompt({
           handoff,
           notes: [profileText, notesText].filter(Boolean).join("\n\n") || undefined,
@@ -417,6 +421,8 @@ export async function runCodeAgent(opts: {
         break
       }
       if (reply.report) report = { ...report, ...reply.report }
+      // What Scribe says it did this time, so a retry is not only "Editing …" lines.
+      if (reply.report && (reply.report.notes || reply.report.changed?.length)) emit({ type: "code", kind: "answer", attempt, ...(reply.report.notes ? { notes: reply.report.notes } : {}), changed: reply.report.changed || [] })
       result.notes = report.notes || reply.text.slice(0, 500)
       if (reply.error && FATAL_ERRORS.some((name) => reply.error!.startsWith(name))) {
         result.notes = reply.error
@@ -477,6 +483,7 @@ export async function runCodeAgent(opts: {
         emit({ type: "code", kind: "test", ok: false, attempt, text: `${report.test_file} exited 0 in ${secs}s but opened no browser (attempt ${attempt}/${maxAttempts})` })
         attemptLog.push(attemptLine(attempt, "exited 0 but opened no browser", "", report.notes))
         nextTask = noBrowserPrompt(report.command)
+        next = { why: "the test passed without opening a browser", fixing: ["Make the test drive a real browser, as the run did"] }
         continue
       }
       if (run.ok) {
@@ -501,6 +508,8 @@ export async function runCodeAgent(opts: {
         result.review = verdict.review
         const correctness = verdict.review.issues.filter((i) => i.kind !== "standards")
         const standards = verdict.review.issues.filter((i) => i.kind === "standards")
+        // The verdict as the reviewer gave it: with only coding-standard issues the test is approved and gets a tidy-up.
+        emit({ type: "code", kind: "review", attempt, max: allowed, approved: verdict.review.approved || !correctness.length, summary: verdict.review.summary, issues: verdict.review.issues })
         // Coding standards alone never fail a test that works and tests the goal.
         if (tidying && correctness.length) {
           // The tidy-up changed what the test does: back to the version that passed.
@@ -515,6 +524,7 @@ export async function runCodeAgent(opts: {
             emit({ type: "code", kind: "test", ok: true, attempt, text: `${report.test_file} passed and tests the goal; the reviewer found ${standards.length} coding-standard ${standards.length === 1 ? "issue" : "issues"}, so the agent fixes ${standards.length === 1 ? "it" : "them"} in one more round (the passing version is kept if that breaks it)` })
             attemptLog.push(attemptLine(attempt, "passed and tests the goal; coding-standard issues to fix", standards.map((i) => i.problem).join(" "), report.notes))
             nextTask = standardsFixPrompt(standards)
+            next = { why: "the reviewer approved the test; one round for its coding-standard issues", fixing: standards.map(issueText) }
             continue
           }
           result.status = "passed"
@@ -526,8 +536,7 @@ export async function runCodeAgent(opts: {
           emit({ type: "code", kind: "test", ok: true, attempt, text: `${report.test_file} passed and was approved (attempt ${attempt}/${allowed})${standards.length ? `; ${standards.length} coding-standard ${standards.length === 1 ? "issue" : "issues"} left in the notes` : ""}` })
           break
         }
-        const n = verdict.review.issues.length
-        emit({ type: "code", kind: "test", ok: false, attempt, text: `review found ${n} ${n === 1 ? "issue" : "issues"}: ${verdict.review.summary} (attempt ${attempt}/${maxAttempts})` })
+        // The review event above says what was found; the rejection itself is its verdict.
         // A second rejection usually means the goal and the page disagree (a test case the page cannot satisfy), not a
         // fix the next attempt will find: stop and report the issues instead of spending the remaining attempts.
         if (++rejections >= MAX_REJECTIONS) {
@@ -537,6 +546,7 @@ export async function runCodeAgent(opts: {
         }
         attemptLog.push(attemptLine(attempt, "passed; the reviewer asked for changes", verdict.review.summary, report.notes))
         nextTask = reviewFixPrompt(verdict.review.summary, verdict.review.issues)
+        next = { why: "the reviewer asked for changes", fixing: verdict.review.issues.map(issueText) }
         continue
       }
       if (tidying) {
@@ -558,11 +568,13 @@ export async function runCodeAgent(opts: {
         emit({ type: "code", kind: "test", ok: false, attempt, text: `${report.test_file} failed the same way as the last attempt, ${why} (attempt ${attempt}/${maxAttempts})` })
         attemptLog.push(attemptLine(attempt, `failed, ${why}, the same way as before`, firstError(run.output), report.notes))
         nextTask = repeatedFailurePrompt(sameFailures + 1, report.command, run.exitCode, run.output, files) + mismatch + switchLiveOn()
+        next = { why: `the test failed the same way again (${why}); Scribe looks at the failing step first`, fixing: [firstError(run.output)].filter(Boolean) }
         continue
       }
       emit({ type: "code", kind: "test", ok: false, attempt, text: `${report.test_file} failed, ${why} (attempt ${attempt}/${maxAttempts})` })
       attemptLog.push(attemptLine(attempt, `failed, ${why}`, firstError(run.output), report.notes))
       nextTask = fixPrompt(attempt, report.command, run.exitCode, run.output, files) + mismatch
+      next = { why: `the test failed (${why})`, fixing: [firstError(run.output)].filter(Boolean) }
     }
     keepSession = result.status === "stopped" || runtimeFailed
     if (report.test_name) result.testName = report.test_name

package/src/code/runtime.ts

@@ -539,6 +539,8 @@ export async function openSession<R = AgentReport>(opts: {
   mcp?: Record<string, unknown>
   /** Tool calls not to show as ⚙ lines (the caller shows them itself). */
   hideTool?: (tool: string) => boolean
+  /** Every finished tool call with what it returned, shown or not: the evidence reports are built from. */
+  onToolResult?: (r: { tool: string; input: Record<string, unknown>; output: string; ok: boolean }) => void
   title?: string
   protect?: Protect
   /** Stop the turn when one shell command has failed this many times since the last resetStall. */
@@ -672,6 +674,7 @@ export async function openSession<R = AgentReport>(opts: {
           emit({ type: "code", kind: "start", tool: part.tool, id: part.id, text: toolLine(opts.repo, part.tool, part.state.input || {}, part.state.title) })
         }
         if (part?.type === "tool" && (part.state?.status === "completed" || part.state?.status === "error")) {
+          opts.onToolResult?.({ tool: part.tool, input: part.state.input || {}, output: String(part.state.output ?? ""), ok: part.state.status === "completed" })
           if (part.tool === "StructuredOutput" && part.state.status === "completed" && !turn.structured) {
             turn.structured = part.state.input || null
           }

package/src/detail.ts

@@ -27,7 +27,8 @@ export function shows(event: AgentEvent | CodeEvent, detail: Detail): boolean {
     case "memory":
       return false
     case "code":
-      if (event.kind === "info" || event.kind === "test") return true
+      // Milestones, and the exchange with the reviewer: why a test was rejected and what Scribe fixes.
+      if (event.kind === "info" || event.kind === "test" || event.kind === "review" || event.kind === "attempt" || event.kind === "answer") return true
       if (event.kind === "tool") return !event.ok || WRITES_FILE.test(event.text)
       return false
     default: