@capagents/forgeqe 2.3.11 → 2.3.13

package/docs/user-guide.html

@@ -728,6 +728,12 @@ Add a GitHub Actions workflow that runs tests/cases.yaml on every PR, and make i
 <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>/memory</code></td><td>Page memory: the sites and pages ForgeQE remembers, and their flows</td></tr>
+<tr><td><code>/guardrails</code></td><td>The rules every agent follows here</td></tr>
+<tr><td><code>/doctor</code></td><td>Check what ForgeQE needs: programs, sign-ins, and the services it reaches</td></tr>
+<tr><td><code>/settings</code></td><td><code>forgeqe.yaml</code>: where it is and what it sets, opened to edit</td></tr>
+<tr><td><code>/home</code></td><td>Back to the start screen; the session stays</td></tr>
+<tr><td><code>/docs</code></td><td>The user guide</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>
@@ -826,8 +832,9 @@ 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 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>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 with <strong>▸ Set up</strong> (its steps in the chat; for <strong>Work items</strong>, it runs <code>/auth</code>) and <strong>skip</strong>. A skipped item is kept in <code>.forgeqe/setup.json</code> and not asked about again. Narrower, it is one <strong>Setup</strong> line with <strong>▸ how to set up</strong> and <strong>skip</strong>. The checks are the same ones <code>/features</code> uses, so the two always agree.</p>
+<p><strong>Sidebar and rail.</strong> The sidebar has three groups. <strong>Work</strong>: <strong>Home</strong>, <strong>This session</strong> (once you have asked something), <strong>Runs</strong>, <strong>Reports</strong>, <strong>Jobs</strong>, and <strong>Defects</strong> (with a tracker set up). <strong>Knowledge</strong>: <strong>Page memory</strong>, <strong>Test cases</strong> (with a tracker), <strong>Guardrails</strong>, <strong>Product</strong> (the knowledge files) and <strong>Skills</strong>. <strong>System</strong>: <strong>Models</strong>, <strong>Sign in</strong>, <strong>Environments</strong>, <strong>Doctor</strong>, <strong>Settings</strong>, <strong>Help</strong> and <strong>Docs</strong>. Each shows how many there are and opens its list (<code>/runs</code>, <code>/reports</code>, <code>/jobs</code>, <code>/memory</code>, <code>/guardrails</code>, <code>/knowledge</code>, <code>/skills</code>, <code>/doctor</code>, <code>/settings</code>, <code>/help</code>, <code>/docs</code>); <strong>Defects</strong> and <strong>Test cases</strong> put a request in the composer, since the agent reads them from the tracker. Narrower than 110 columns, and beside the chat at every width, the sidebar folds to a rail of its icons, so the start screen is always one click away: <strong>Home</strong> (or <code>/home</code>) shows it with the session still open, and <strong>▸ Back to the session</strong> or any request returns to it.</p>
+<p><strong>Needs you and Today.</strong> Once there are runs, the start screen shows what needs you (runs that failed this week and have not passed since, and jobs whose last run failed, each with <strong>open</strong> and <strong>rerun</strong>) and what ran today. The greeting says how many runs there were today and how many failed. The model is in the composer beside <strong>⏎ Send</strong>: click it to change it. The status line shows the branch, 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.11",
+  "version": "2.3.13",
   "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": {

package/py/forgeqe_mobile/maestro.py

@@ -15,6 +15,7 @@ from __future__ import annotations
 import json
 import os
 import re
+import shutil
 import subprocess
 import xml.etree.ElementTree as ET
 from pathlib import Path
@@ -303,7 +304,8 @@ def run_maestro(
     out_dir.mkdir(parents=True, exist_ok=True)
     junit = out_dir / "maestro-junit.xml"
     debug = out_dir / "maestro-debug"
-    args = [*command, *(["--device", device] if device else []), "test", "--format", "junit", "--output", str(junit), "--debug-output", str(debug), *flows]
+    resolved = shutil.which(command[0]) or command[0]
+    args = [resolved, *command[1:], *(["--device", device] if device else []), "test", "--format", "junit", "--output", str(junit), "--debug-output", str(debug), *flows]
     try:
         proc = run(args, env=dict(env), capture_output=True, text=True, timeout=timeout, shell=False)
     except FileNotFoundError: