@capagents/forgeqe 2.3.9 → 2.3.10

package/docs/user-guide.html

@@ -725,6 +725,9 @@ Add a GitHub Actions workflow that runs tests/cases.yaml on every PR, and make i
 <tr><td><code>/env [name]</code></td><td>The test environments in <code>env.yaml</code> and their apps, or switch to one</td></tr>
 <tr><td><code>/logs [shots]</code></td><td>Save this session's log and runs in one archive to share (<code>shots</code>: with screenshots)</td></tr>
 <tr><td><code>/features</code></td><td>What ForgeQE can do, and what each capability still needs here</td></tr>
+<tr><td><code>/runs</code>, <code>/reports</code></td><td>The runs and reports in the reports folder, newest first</td></tr>
+<tr><td><code>/jobs</code></td><td>The scheduled jobs: when each runs next, and how its last run ended</td></tr>
+<tr><td><code>/knowledge</code></td><td>The product knowledge the agents read (<code>.forgeqe/knowledge</code>)</td></tr>
 <tr><td><code>/generated</code></td><td>How much of this repository's code ForgeQE wrote, and how much is still there</td></tr>
 <tr><td><code>/init</code></td><td>Set ForgeQE up in this folder: <code>forgeqe.yaml</code>, <code>llms.json</code>, editable prompts, skills, knowledge</td></tr>
 <tr><td><code>/skills [name]</code></td><td>The skills each agent can use, or one skill's instructions</td></tr>
@@ -823,7 +826,8 @@ Add a GitHub Actions workflow that runs tests/cases.yaml on every PR, and make i
 </tbody>
 </table></div>
 <p><strong>Links.</strong> Report folders, report files, and web addresses in the chat are links: Cmd-click (Ctrl-click on Windows and Linux) opens them in terminals that support links, such as VS Code, iTerm2, Windows Terminal, and recent GNOME Terminal. A path that no longer exists stays plain text.</p>
-<p><strong>Setup checklist.</strong> Until everything is set up, the start screen's <strong>Setup</strong> line shows how many of the five things most features rest on are set up, and names the ones that are not: <strong>Model</strong> (a live model profile), <strong>Coding agent</strong>, <strong>Work items</strong> (Azure DevOps, Jira, TestRail, Zephyr, qTest, or Xray), <strong>Domain</strong>, and <strong>Notifications</strong>. <strong>▸ how to set up</strong> puts the steps for each missing one in the chat (for <strong>Work items</strong>, type <code>/auth</code>). The checks are the same ones <code>/features</code> uses, so the two always agree.</p>
+<p><strong>Setup checklist.</strong> Until everything is set up, the start screen shows how many of the five things most features rest on are set up: <strong>Model</strong> (a live model profile), <strong>Coding agent</strong>, <strong>Work items</strong> (Azure DevOps, Jira, TestRail, Zephyr, qTest, or Xray), <strong>Domain</strong>, and <strong>Notifications</strong>. In a terminal 110 columns or wider it is the sidebar's <strong>Get set up</strong>: each finished item with what it found, and the next one as a card whose <strong>▸ Set up</strong> puts its steps in the chat (for <strong>Work items</strong>, it runs <code>/auth</code>). Narrower, it is one <strong>Setup</strong> line under the composer, and <strong>▸ how to set up</strong> gives the steps for every missing one. The checks are the same ones <code>/features</code> uses, so the two always agree.</p>
+<p><strong>Sidebar.</strong> Under setup, <strong>Work</strong> opens <strong>Runs</strong>, <strong>Reports</strong>, <strong>Jobs</strong> and <strong>Knowledge</strong> (<code>/runs</code>, <code>/reports</code>, <code>/jobs</code>, <code>/knowledge</code>) with how many of each there are, and <strong>Defects</strong> (with a tracker set up) puts a request for the open defects in the composer. <strong>System</strong> opens <strong>Features</strong>, <strong>Skills</strong>, <strong>Environments</strong>, <strong>Models</strong>, <strong>Sign in</strong> and <strong>Logs</strong>. The status line shows the branch, the model (click it to change), the tracker, and when the next scheduled job runs.</p>
 <p><strong>Command palette.</strong> Ctrl-P opens a palette of every action, command, profile, and example request; type a few letters to find one (&quot;rr&quot; finds <em>Refine my request</em>, &quot;auth&quot; finds the sign-in commands), ↑/↓ to choose, Enter to run it. Example requests are put in the prompt for you to edit, never sent straight away.</p>
 <p><strong><code>/</code> and <code>@</code> in the prompt.</strong> Typing <code>/</code> lists the commands that match; typing <code>@</code> suggests references: recent runs (<em>last run</em>, then each by its folder), files in the repository by name or path (<code>@Login</code> finds <code>pages/Login.ts</code>), and, after <code>@</code> and a number such as <code>@1761</code>, the Azure DevOps work item with its title (read-only). Tab completes, ↑/↓ choose, Esc closes the list.</p>
 <p><strong>Refine.</strong> Ctrl-R (or <em>Refine my request</em> in the palette) turns what you typed into a task specification for ForgeQE's agent, laid out as a system prompt and written in ASD-STE100 Simplified Technical English, before it is sent. It has these parts, in this order: <strong>Role</strong> (who the agent acts as), <strong>Objective</strong> (one instruction), <strong>Context</strong> (the facts, with names), <strong>Steps</strong> (only when they add something), <strong>Rules</strong> (your limits and the setup's), <strong>Output format</strong> (what comes back and how it is laid out), and <strong>Summary</strong> (what you get, in one sentence, read last):</p>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@capagents/forgeqe",
-  "version": "2.3.9",
+  "version": "2.3.10",
   "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": "SEE LICENSE IN LICENSE",
   "repository": {