@capagents/forgeqe 2.3.9 → 2.3.11

package/docs/ARCHITECTURE.md

@@ -182,7 +182,7 @@ Tools take structured arguments. `run_test_cases` and `find_test_cases` get a li
 
 **Permissions.** The agent's bash is allowed except `git push*`, `git * push*` (so `git -C . push` is caught too), and `gh repo delete*`, each also with a leading `*` so a push wrapped in another command (`env git push`, `sh -c 'git push'`) is caught; the agent runtime matches each command of a chain on its own and applies the last matching rule. These rules are guard rails, not a sandbox. `forgeqe_*` tools are allowed. `external_directory` allows only the run and memory folders. Tool calls to `forgeqe_*` are hidden from the `⚙` lines because their `ToolEvent`s already render richer output (browser steps, suite cards).
 
-**Callers.** The TUI opens the brain on the first message and keeps it for the session, so follow-up answers and "write a test for that run" have context; `/profile` (or Tab) closes it and keeps the turns so far: the next agent session's first prompt is `carryOver(turns, text)`, the last 20 turns with remembered secrets redacted, so switching models does not lose the conversation. It renders `card` events as result panels and `agent` events as `⚙` and test lines with their own token counter, and its `waitForUser` pushes the prompt into the transcript and opens a **Your turn** dialog (Done, continue / Cancel); opening another dialog or Esc settles it as cancelled. `forgeqe run` opens the brain for one request, prints tool events (cards as `cardText`) and the reply as plain lines, waits for Enter in `waitForUser` when stdin is a terminal, and exits 0 done, 1 failed, 2 stopped, 3 needs input. `forgeqe run --direct` and a missing agent runtime run `browser_run` directly. `forgeqe mcp` serves the same `TOOLS` on stdio and logs `ToolEvent`s to stderr; it has no `waitForUser`. `forgeqe start` and `forgeqe mcp` stop background monitors when they return, because `src/index.ts` calls `process.exit`.
+**Callers.** The TUI opens the brain on the first message and keeps it for the session, so follow-up answers and "write a test for that run" have context; `/profile` (or Tab) closes it and keeps the turns so far: the next agent session's first prompt is `carryOver(turns, text)`, the last 20 turns with remembered secrets redacted, so switching models does not lose the conversation. It renders `card` events as result panels and `agent` events as `⚙` and test lines with their own token counter, and its `waitForUser` pushes the prompt into the transcript and opens a **Your turn** dialog (Done, continue / Cancel); opening another dialog or Esc settles it as cancelled. `forgeqe run` opens the brain for one request, prints tool events (cards as `cardText`) and the reply as plain lines, waits for Enter in `waitForUser` when stdin is a terminal, and exits 0 done, 1 failed, 2 stopped, 3 needs input. `forgeqe run --direct` and a missing agent runtime run `browser_run` directly. `forgeqe mcp` serves the same `TOOLS` on stdio and logs `ToolEvent`s to stderr; it has no `waitForUser`. `forgeqe chat --jsonl` (`src/chat/jsonl.ts`) is the TUI's agent for a program: like the TUI, it opens the brain on the first message, keeps it for every message, runs with `session: "shell"`, runs Tier 0 requests as recorded before asking the agent, and continues an earlier conversation with `carryOver` (`--carry-over FILE`, with its own reason sentence); like `forgeqe run`, it takes its flags (`repoFlag`, `memoryFlags`, …) and writes one session log; like `forgeqe mcp`, it is a machine interface, with stdout claimed for the protocol and every other print sent to stderr. It writes each `CodeEvent` and `ToolEvent` unchanged as a JSON line (`agent`, `tool`), turns `ask` and `waitForUser` into `ask` and `wait` lines answered on stdin, ends every turn with one `turn_done`, and passes every outgoing string through `redactSecrets` and the values of `privateEnvNames` and profile keys. The protocol is in HOW_TO_USE.md. `forgeqe start`, `forgeqe mcp`, and `forgeqe chat` stop background monitors when they return, because `src/index.ts` calls `process.exit`.
 
 ## Tool scope (`src/mcp/scope.ts`, `src/capabilities`)
 

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.11",
   "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": {