@capagents/forgeqe 1.1.0 → 1.1.1

package/HOW_TO_USE.md

@@ -467,23 +467,24 @@ The chat gets a short summary and a card with both paths as links, and **Open th
 
 **`/` and `@` in the prompt.** Typing `/` lists the commands that match; typing `@` suggests references: recent runs (*last run*, then each by its folder), files in the repository by name or path (`@Login` finds `pages/Login.ts`), and, after `@` and a number such as `@1761`, the Azure DevOps work item with its title (read-only). Tab completes, ↑/↓ choose, Esc closes the list.
 
-**Refine.** Ctrl-R (or *Refine my request* in the palette) turns what you typed into a task specification for ForgeQE's agent, in ASD-STE100 Simplified Technical English, before it is sent:
+**Refine.** Ctrl-R (or *Refine my request* 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: **Role** (who the agent acts as), **Objective** (one instruction), **Context** (the facts, with names), **Steps** (only when they add something), **Rules** (your limits and the setup's), **Output format** (what comes back and how it is laid out), and **Summary** (what you get, in one sentence, read last):
 
 ```
-Goal: Check the Azure DevOps QI-Payments pipelines and make a shareable report for the manager.
+Role: A release analyst who reads Azure DevOps deployments.
+
+Objective: Get what is deployed now in each environment of each Azure DevOps project.
 
 Context:
-- Project: Azure DevOps project QI-Payments.
-- Pipeline: build definition 32, QI-Payments-CD.
-- Latest checked CD build: build 1021, failed, finished 2026-09-21.
+- System: Azure DevOps organization devcgazuredevops.
+- Projects: Autothon, CQube.AI, BlackBox_AI, QI-Payments, QI-MobileBanking, Atlas.Ai, QI-Claims.
 
-Steps:
-1. Review the recent runs of QI-Payments-CI and QI-Payments-CD.
-2. Make a shareable report with a short manager summary.
+Output format: One section for each project, with a line for each environment: the deployed build, its date, and its status.
 
-Result: A shareable report file with a short summary for the manager.
+Summary: Show the deployed build in each environment, and why each deployment failed.
 ```
 
+Refine is one model session of its own, separate from the conversation: a few model steps (usually two) and read-only tool calls, typically 15K–25K tokens and 20–30 seconds. The panel title shows what it cost and how much of the request keeps the ASD-STE100 rules (*✦ Refined request · STE 100% · 20.8K tokens · 21s*), and its tokens count in the session total in the footer.
+
 A read-only agent writes it. It starts knowing every capability and whether it works in this setup, and the domain; it checks names and ids in the systems that are set up (work items, test plans, pipelines, sprints, recent runs). The panel shows the request with what it **checked** ✓, what it **assumed** ~, and what is **missing** ? (for example "Which story? Give the work item id"); a capability that is not set up shows as missing too. Enter sends it, `e` puts it in the prompt to edit, Esc keeps yours. Refine never runs anything, writes files, or changes a work item; it never invents an id, URL, project, or file.
 
 **Next steps.** When a request finishes, up to three suggestions appear above the prompt: from what it produced (*Open the report*, *Write a test for this run*, *Why did it fail?*, *Rerun the cases that failed*) and from the agent's answer, which suggests the follow-ups you are likely to want (*Write a release report*, *Show the failed CD logs*). Click one or press Alt-1 to Alt-3; suggestions that start work are put in the prompt first, to adjust and send.

package/docs/user-guide.html

@@ -622,20 +622,20 @@ Add a GitHub Actions workflow that runs tests/cases.yaml on every PR, and make i
 <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>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, in ASD-STE100 Simplified Technical English, before it is sent:</p>
-<pre><code>Goal: Check the Azure DevOps QI-Payments pipelines and make a shareable report for the manager.
+<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>
+<pre><code>Role: A release analyst who reads Azure DevOps deployments.
+
+Objective: Get what is deployed now in each environment of each Azure DevOps project.
 
 Context:
-- Project: Azure DevOps project QI-Payments.
-- Pipeline: build definition 32, QI-Payments-CD.
-- Latest checked CD build: build 1021, failed, finished 2026-09-21.
+- System: Azure DevOps organization devcgazuredevops.
+- Projects: Autothon, CQube.AI, BlackBox_AI, QI-Payments, QI-MobileBanking, Atlas.Ai, QI-Claims.
 
-Steps:
-1. Review the recent runs of QI-Payments-CI and QI-Payments-CD.
-2. Make a shareable report with a short manager summary.
+Output format: One section for each project, with a line for each environment: the deployed build, its date, and its status.
 
-Result: A shareable report file with a short summary for the manager.
+Summary: Show the deployed build in each environment, and why each deployment failed.
 </code></pre>
+<p>Refine is one model session of its own, separate from the conversation: a few model steps (usually two) and read-only tool calls, typically 15K–25K tokens and 20–30 seconds. The panel title shows what it cost and how much of the request keeps the ASD-STE100 rules (<em>✦ Refined request · STE 100% · 20.8K tokens · 21s</em>), and its tokens count in the session total in the footer.</p>
 <p>A read-only agent writes it. It starts knowing every capability and whether it works in this setup, and the domain; it checks names and ids in the systems that are set up (work items, test plans, pipelines, sprints, recent runs). The panel shows the request with what it <strong>checked</strong> ✓, what it <strong>assumed</strong> ~, and what is <strong>missing</strong> ? (for example &quot;Which story? Give the work item id&quot;); a capability that is not set up shows as missing too. Enter sends it, <code>e</code> puts it in the prompt to edit, Esc keeps yours. Refine never runs anything, writes files, or changes a work item; it never invents an id, URL, project, or file.</p>
 <p><strong>Next steps.</strong> When a request finishes, up to three suggestions appear above the prompt: from what it produced (<em>Open the report</em>, <em>Write a test for this run</em>, <em>Why did it fail?</em>, <em>Rerun the cases that failed</em>) and from the agent's answer, which suggests the follow-ups you are likely to want (<em>Write a release report</em>, <em>Show the failed CD logs</em>). Click one or press Alt-1 to Alt-3; suggestions that start work are put in the prompt first, to adjust and send.</p>
 <div class="tbl"><table>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@capagents/forgeqe",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "ForgeQE: a browser agent CLI that runs goals and test cases in Chrome and turns passing runs into tests in your repo",
   "license": "MIT",
   "type": "module",

package/prompts/brain.md

@@ -12,7 +12,7 @@ Find what the user wants from their message. Then do it with your tools. ForgeQE
 - A request to write or repair tests, or a CI pipeline task.
 - A question.
 
-A message can also be a task specification with the parts Goal, Context, Steps, Rules, and Result. Refine in the shell writes this type of message. Do the goal. Use the context as facts. Do the steps in sequence. Obey the rules. Give the result that it asks for.
+A message can also be a task specification with the parts Role, Objective, Context, Steps, Rules, Output format, and Summary. Refine in the shell writes this type of message. Take the role. Do the objective. Use the context as facts. Do the steps in sequence. Obey the rules. Give the answer in the output format.
 
 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 that must occur 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.
@@ -80,6 +80,13 @@ Azure DevOps, Jira, Xray, and other systems:
 - Do not call the APIs of these systems from the shell, with curl, Python, PowerShell, or a script. The shell does not have the credentials, and ForgeQE blocks these commands. Use query_api.
 - Azure DevOps classic releases are not in the MCP tools. Read them with query_api and the release host, for example https://vsrm.dev.azure.com/<organization>/<project>/_apis/release/releases?$top=10 or _apis/release/deployments.
 - When the user asks about releases in Azure DevOps, read both: the classic releases, and the runs of the deployment pipelines (the pipelines MCP tools). Say which of them each project uses.
+- For release details, find what is deployed now, not only the last run. Do these steps for each project:
+  1. Read the environments with query_api: <project>/_apis/distributedtask/environments.
+  2. Read the deployments of each environment: <project>/_apis/distributedtask/environments/<id>/environmentdeploymentrecords?top=5&api-version=7.1-preview.1.
+  3. Read the stages of each deployment run: <project>/_apis/build/builds/<id>/timeline. Give each stage with its result.
+  4. When a stage failed, give the cause from the timeline: the failed task, check, or approval, and its message.
+  5. Compare the newest CI build with the build that the environments have. Say when a newer build is not deployed.
+- Keep these cases apart: a project without a deployment pipeline, a pipeline without runs, and a run that failed.
 - Create or change items only when the user asks. Examples are to file a bug, add a comment, move an issue, or edit a work item. Say what you changed, with its id or key.
 - The only exception is to save test cases that you wrote from a story (see below).
 - Azure DevOps dashboards: use create_ado_dashboard, not the browser.
@@ -326,6 +333,7 @@ Rules:
   - Use bold only for the one word or number that is important in a line, such as a status or a count. Do not make full sentences bold.
   - Use a table only for two or three short columns.
 - Keep replies short and specific. Give in full the test cases, tests, and reviews that the user asked for. Keep only your own comments short.
+- A status alone is not an answer. When a result is "failed", empty, or "none found", find the cause with your tools before you reply. Give the cause and the next action that fixes it.
 - When the user asks for a report, a write-up, or a summary to share, collect the facts with your tools. Examples are "create a release report" and "write up the open defects".
 - Then save the report with write_report. Reply with three to five lines of summary. The shell shows the paths of the report as links, so do not repeat them.
 - Do not only paste a long report into the reply.

package/prompts/refine.md

@@ -5,37 +5,41 @@ used_by: "the shell's Refine (ctrl+r)"
 ---
 You refine a request that the user typed for ForgeQE, a test automation assistant. ForgeQE then sends the refined request to its agent. You do not do the request. You do not change data.
 
-Write the refined request as a short task specification for the agent. Write it in ASD-STE100 Simplified Technical English:
+Write the refined request in ASD-STE100 Simplified Technical English:
 - Use short sentences: 20 words or fewer in an instruction, 25 words or fewer in a description.
 - Give one instruction in each sentence. Start an instruction with a verb.
 - Use the active voice.
 - Use simple words with one meaning. For example, use "make sure", not "ensure", and "use", not "utilize".
 - Use the same name for the same thing each time.
 
-Fill in these parts:
-- goal: one instruction that says what the agent must do. Start with a verb. Name the exact thing to get or do, not a general word. Example: "Run the test cases of Azure DevOps test plan 412, suite 77." Example: "Get the latest classic release and the latest deployment pipeline run of each project."
+Write the request as a system prompt for the agent. Fill in these parts, in this sequence:
+- role: the role that the agent takes for this task, as one short description. Examples: "A release analyst who reads Azure DevOps deployments." and "A test engineer who runs manual test cases in the browser."
+- objective: one instruction that says what the agent must do. Start with a verb. Name the exact thing to get or do, not a general word. Example: "Run the test cases of Azure DevOps test plan 412, suite 77." Example: "Get what is deployed now in each environment of each project, with the stages and the cause of each failed deployment."
 - context: the facts that the agent needs. Give the system, the project, the work items, the files, and the runs with their exact names. Give one fact for each line.
 - Give names, not internal ids such as GUIDs. Give an id only when it is the name that people use, for example a work item number, a test plan or suite number, or a build number.
 - Put a list of items of the same type on one line, for example "Projects: Autothon, CQube.AI, QI-Payments".
 - Give only the facts that this task needs. Do not give the working directory or the settings of forgeqe.yaml. The agent already has them.
-- steps: the actions, in sequence, when the request has more than one action. Give one action for each step. Each step must add information that the goal does not give. Leave this empty for a request with one action.
+- steps: the actions, in sequence, when the request has more than one action. Give one action for each step. Each step must add information that the objective does not give, for example which data to read or how to compare it. When the steps only say the objective again, leave steps empty.
 - rules: the limits that the user gave or that the setup sets. Examples are "Do not send results back to Azure DevOps", "Use 2 browsers at the same time", and "Show the browser". Give only rules that come from the user or from "This session".
-- result: what the agent must give back. Examples are a report saved as a file with a short summary, a test file and its run, or a list of test cases with links.
+- output: the output format. Say what the agent gives back and how it is laid out. Examples: "One section for each project, with a line for each environment: the deployed build, its date, and its status." and "A report file, with a summary of three lines in the chat."
+- summary: what the user gets, in one sentence of 15 words or fewer. The agent reads it last. Do not copy the objective. Example: "Show the deployed build in each environment, and why each deployment failed."
 
 Rules for your work:
 - Keep the intent and the scope of the user exactly. Do not add work that the user did not ask for. Do not remove work that the user asked for.
+- Keep each word that changes the result, such as "current", "all", "details", or "failed". For example, "current release" means what is deployed now, not the last run.
 - Use the names that ForgeQE uses, for example "Azure DevOps project QI-Payments", "test plan 412, suite 77", "story 1761", or "SHOP-12".
 - Use "This session" and "What ForgeQE can do here" to know the capabilities and the setup.
 - Describe each action in plain words, for example "run the test cases" or "write a Playwright test". Do not name the tools of ForgeQE or the capability ids.
 - Change references such as "the last run", "that story", or "the payments plan" into the item that they point to. Do this only when exactly one item fits.
 - Check facts with your read-only tools. For example, check that a work item, a test plan, a suite, or a run exists, what its name is, and how many cases it has.
 - Put each fact of context in grounded, with the same words, and say if you checked it. Do not add facts to grounded that are not in context.
-- A request can mean more than one thing. Then select the meaning that the capabilities of ForgeQE support best, and write the goal for it. Say the meaning that you selected in assumed.
-- Put a question in missing only when a wrong selection gives a different result. In the question, give the possible meanings, for example "Classic releases, deployment pipeline runs, or release readiness (GO / NO-GO)?".
+- A request can mean more than one thing. Then select the meaning that the capabilities of ForgeQE support best, and write the objective for it. Say the meaning that you selected in assumed.
+- Do not ask about a meaning that you selected in assumed. The user sees assumed and can change it.
+- Put a question in missing only when you cannot select a meaning and a wrong selection gives a different result. In the question, give the possible meanings, for example "Classic releases, deployment pipeline runs, or release readiness (GO / NO-GO)?".
 - Do not invent an id, a URL, a project, or a file.
 - If you cannot find or check an item, put a short question for the user in missing.
 - If a capability that the request needs is not set up, put this in missing. Say what the user must set up.
 - Keep the settings that the user gave, for example the number of browsers, a visible browser, or whether results go back. Do not add other settings.
 - Write in the language of the user.
 
-Finish with the structured result: goal, context, steps, rules, result, grounded, assumed, and missing.
+Finish with the structured result: role, objective, context, steps, rules, output, summary, grounded, assumed, and missing.

package/src/mcp/server.ts

@@ -54,8 +54,18 @@ export function createMcpServer(opts: McpServerOptions) {
             base.emit?.(e)
           }
         : undefined
-      const out = await tool.run(params.arguments || {}, { ...base, emit, signal: controller.signal })
+      const said = (ok: boolean) => {
+        if (tool.line && emit) emit({ type: "call", text: tool.line(params.arguments || {}), ok })
+      }
+      let out: unknown
+      try {
+        out = await tool.run(params.arguments || {}, { ...base, emit, signal: controller.signal })
+      } catch (err) {
+        if (!controller.signal.aborted) said(false)
+        throw err
+      }
       if (controller.signal.aborted) return finish({ content: [{ type: "text", text: "Stopped by the user." }], isError: true })
+      said(true)
       return finish({ content: [{ type: "text", text: typeof out === "string" ? out : JSON.stringify(out, null, 2) }] })
     } catch (err) {
       return finish({ content: [{ type: "text", text: controller.signal.aborted ? "Stopped by the user." : (err as Error).message || String(err) }], isError: true })

package/src/mcp/tools.ts

@@ -98,6 +98,25 @@ export type ToolEvent =
   | { type: "card"; card: Card }
   /** write_report saved a report: its page and its Markdown. */
   | { type: "report"; title: string; html: string; markdown: string }
+  /** A finished call of a tool that has no card of its own, as one line: "Azure DevOps API · QI-Claims/_apis/build/builds (top 5)". */
+  | { type: "call"; text: string; ok: boolean }
+
+const API_LABEL: Record<string, string> = { azure_devops: "Azure DevOps", jira: "Jira", xray: "Xray", confluence: "Confluence" }
+
+/**
+ * A query_api call as a line: "Azure DevOps API · QI-Claims/_apis/release/releases (top 1, queryOrder descending)". The
+ * host and organization are left out, as are api-version and the start of a WIQL query.
+ */
+export function queryLine(args: Record<string, any>): string {
+  const name = `${API_LABEL[String(args.system)] || String(args.system || "API")} API`
+  if (args.wiql) return `${name} · WIQL (${clip(String(args.wiql).replace(/\s+/g, " ").replace(/^SELECT .*? FROM WorkItems WHERE /i, ""), 90)})`
+  if (args.query) return `${name} · GraphQL (${clip(String(args.query).replace(/\s+/g, " "), 90)})`
+  const raw = String(args.path || "")
+  const url = /^https?:\/\//.test(raw) ? raw.replace(/^https?:\/\/[^/]+\/(?:[^/]+\/(?=[^/]+\/_apis\/))?/, "") : raw.replace(/^\//, "")
+  const [where, search = ""] = url.split("?")
+  const params = [...new URLSearchParams(search)].filter(([k]) => k !== "api-version").map(([k, v]) => `${k.replace(/^\$/, "")} ${v}`)
+  return `${name} · ${decodeURIComponent(where || "")}${params.length ? ` (${clip(params.join(", "), 90)})` : ""}`
+}
 
 export type ToolContext = {
   config: AppConfig
@@ -135,6 +154,8 @@ export type McpTool = {
   description: string
   inputSchema: Record<string, unknown>
   run(args: Record<string, any>, ctx: ToolContext): Promise<unknown>
+  /** The call as one line in the conversation, for a tool that shows nothing else: the ForgeQE tools are hidden there. */
+  line?(args: Record<string, any>): string
 }
 
 const clip = (s: string | undefined, n: number) => {
@@ -563,6 +584,7 @@ export const TOOLS: McpTool[] = [
         limit: { type: "integer", minimum: 1, maximum: 25, description: "Most pages to return (default 10)" },
       },
     },
+    line: (args) => `Confluence · ${args.cql ? `search (${clip(String(args.cql), 90)})` : `pages (${clip((Array.isArray(args.pages) ? args.pages : []).map(String).join(", "), 90)})`}`,
     async run(args, ctx) {
       const pages = Array.isArray(args.pages) ? args.pages.map(String) : undefined
       return readConfluence(ctx.config.sources, { pages, cql: args.cql ? String(args.cql) : undefined, limit: Number(args.limit) || undefined })
@@ -592,6 +614,7 @@ export const TOOLS: McpTool[] = [
       },
       required: ["system"],
     },
+    line: queryLine,
     async run(args, ctx) {
       return queryApi(ctx.config.sources, { system: args.system, path: args.path, query: args.query, variables: args.variables, wiql: args.wiql, project: args.project })
     },

package/src/refine.ts

@@ -10,6 +10,7 @@ import { CAPABILITIES } from "./capabilities/registry.ts"
 import { allStatuses } from "./capabilities/status.ts"
 import { domainNotes } from "./domain.ts"
 import type { CodeEvent } from "./types.ts"
+import { steScore } from "./ste.ts"
 
 /**
  * The shell's Refine (ctrl+r): what the user typed becomes a precise request for ForgeQE's agent, checked against what
@@ -20,13 +21,18 @@ import type { CodeEvent } from "./types.ts"
 /** The only tools the refiner may call: each reads, none changes anything or starts a run. */
 export const REFINE_TOOLS = ["capabilities", "query_api", "find_test_cases", "list_sprints", "run_details"]
 
-/** The refined request as a task specification: what ForgeQE's agent is asked to do, in the parts its own prompt uses. */
-export type RefinedSpec = { goal: string; context: string[]; steps: string[]; rules: string[]; result: string }
+/**
+ * The refined request as a task specification, laid out as a system prompt: the role the agent takes, the objective,
+ * the context, the steps, the rules, the output format, and the objective again in one sentence at the end.
+ */
+export type RefinedSpec = { role: string; objective: string; context: string[]; steps: string[]; rules: string[]; output: string; summary: string }
 
 export type Refined = {
-  /** The request that is sent: the spec written out (Goal, Context, Steps, Rules, Result). */
+  /** The request that is sent: the spec written out (Role, Objective, Context, Steps, Rules, Output format, Summary). */
   refined: string
   spec?: RefinedSpec
+  /** The share of the request's sentences that keep the ASD-STE100 rules, 0 to 1. */
+  ste?: number
   grounded: { fact: string; checked: boolean }[]
   assumed: string[]
   missing: string[]
@@ -37,11 +43,13 @@ const lines = { type: "array", items: { type: "string" } } as const
 export const REFINE_SCHEMA = {
   type: "object",
   properties: {
-    goal: { type: "string", description: "One instruction that starts with a verb: what the agent must do" },
+    role: { type: "string", description: "The role the agent takes for this task, as one description, e.g. A release analyst who reads Azure DevOps deployments" },
+    objective: { type: "string", description: "One instruction that starts with a verb: what the agent must do" },
     context: { ...lines, description: "Facts the agent needs, one per line: system, project, work items, files, runs, with exact names and ids" },
     steps: { ...lines, description: "The actions in sequence, one per step; empty for a request with one action" },
     rules: { ...lines, description: "Limits the user gave or the setup sets, one per line" },
-    result: { type: "string", description: "What the agent must give back" },
+    output: { type: "string", description: "The output format: what the agent gives back and how it is laid out (sections, a table, a file)" },
+    summary: { type: "string", description: "The objective again, in one short sentence, as the last line" },
     grounded: {
       type: "array",
       items: { type: "object", properties: { fact: { type: "string" }, checked: { type: "boolean" } }, required: ["fact", "checked"] },
@@ -49,7 +57,7 @@ export const REFINE_SCHEMA = {
     assumed: { type: "array", items: { type: "string" } },
     missing: { type: "array", items: { type: "string" } },
   },
-  required: ["goal", "context", "steps", "rules", "result", "grounded", "assumed", "missing"],
+  required: ["role", "objective", "context", "steps", "rules", "output", "summary", "grounded", "assumed", "missing"],
 } as const
 
 const REFINE_AGENT = {
@@ -64,11 +72,14 @@ const REFINE_AGENT = {
 
 /** The spec as the request ForgeQE's agent gets: labelled parts, empty ones left out. */
 export function composeRefined(spec: RefinedSpec): string {
-  const parts = [`Goal: ${spec.goal}`]
+  const parts: string[] = []
+  if (spec.role) parts.push(`Role: ${spec.role}`)
+  parts.push(`Objective: ${spec.objective}`)
   if (spec.context.length) parts.push(["Context:", ...spec.context.map((c) => `- ${c}`)].join("\n"))
   if (spec.steps.length) parts.push(["Steps:", ...spec.steps.map((st, i) => `${i + 1}. ${st}`)].join("\n"))
   if (spec.rules.length) parts.push(["Rules:", ...spec.rules.map((r) => `- ${r}`)].join("\n"))
-  if (spec.result) parts.push(`Result: ${spec.result}`)
+  if (spec.output) parts.push(`Output format: ${spec.output}`)
+  if (spec.summary) parts.push(`Summary: ${spec.summary}`)
   return parts.join("\n\n")
 }
 
@@ -97,13 +108,18 @@ export function refineRequest(text: string, recent: { user: string; reply: strin
 }
 
 /** Keeps only what the schema allows, so the shell never shows a malformed answer. */
-export function cleanRefined(r: (Partial<Refined> & Partial<RefinedSpec>) | null | undefined, original: string): Refined {
+export function cleanRefined(r: (Partial<Refined> & Partial<RefinedSpec> & { goal?: string; result?: string }) | null | undefined, original: string): Refined {
   const strings = (v: unknown) => (Array.isArray(v) ? v.map(String).map((s) => s.trim()).filter(Boolean) : [])
-  const goal = String(r?.goal || "").trim()
-  const spec: RefinedSpec | undefined = goal ? { goal, context: strings(r?.context), steps: strings(r?.steps), rules: strings(r?.rules), result: String(r?.result || "").trim() } : undefined
+  const text = (v: unknown) => String(v || "").trim()
+  // goal and result: the names an older refine prompt (a project's own copy) gives the objective and the output.
+  const objective = text(r?.objective) || text(r?.goal)
+  const spec: RefinedSpec | undefined = objective
+    ? { role: text(r?.role), objective, context: strings(r?.context), steps: strings(r?.steps), rules: strings(r?.rules), output: text(r?.output) || text(r?.result), summary: text(r?.summary) }
+    : undefined
+  const refined = spec ? composeRefined(spec) : text(r?.refined) || original
   return {
-    refined: spec ? composeRefined(spec) : String(r?.refined || "").trim() || original,
-    ...(spec ? { spec } : {}),
+    refined,
+    ...(spec ? { spec, ste: steScore(refined).score } : {}),
     grounded: Array.isArray(r?.grounded) ? r!.grounded.filter((g) => g && String(g.fact || "").trim()).map((g) => ({ fact: String(g.fact).trim(), checked: g.checked === true })) : [],
     assumed: strings(r?.assumed),
     missing: strings(r?.missing),
@@ -150,7 +166,7 @@ export async function refine(opts: {
     })
     try {
       let out = await session.prompt(refineRequest(opts.text, opts.recent))
-      if (!out.report && !out.error && !opts.signal?.aborted) out = await session.prompt("Give the structured result: goal, context, steps, rules, result, grounded, assumed, and missing.")
+      if (!out.report && !out.error && !opts.signal?.aborted) out = await session.prompt("Give the structured result: role, objective, context, steps, rules, output, summary, grounded, assumed, and missing.")
       if (!out.report) throw new Error(out.error ? `Refine failed: ${out.error}` : "Refine gave no result.")
       return cleanRefined(out.report, opts.text)
     } finally {

package/src/tui/App.tsx

@@ -519,6 +519,7 @@ export function App({ options }: { options: TuiOptions }) {
   }
 
   /** Refines what is in the prompt; the user then decides what is sent. */
+  const refineCount = useRef(0)
   const startRefine = () => {
     const text = promptTextRef.current.trim()
     const cfg = configRef.current
@@ -534,10 +535,19 @@ export function App({ options }: { options: TuiOptions }) {
     const controller = new AbortController()
     refineAbort.current = controller
     setRefine({ phase: "working", original: text })
-    void (options.refine || refine)({ config: cfg, cwd: sessionSetup(cfg, options.repo).cwd, text, recent: convoRef.current, signal: controller.signal })
+    // Refine is a model session of its own: its tokens count in the session total, under a key per refine.
+    const key = `refine-${++refineCount.current}`
+    const started = Date.now()
+    let used = 0
+    const onEvent = (e: CodeEvent) => {
+      if (e.kind !== "usage") return
+      used = e.usage.input + e.usage.output
+      useTokens(key, used)
+    }
+    void (options.refine || refine)({ config: cfg, cwd: sessionSetup(cfg, options.repo).cwd, text, recent: convoRef.current, signal: controller.signal, onEvent })
       .then((result) => {
         if (controller.signal.aborted || refiningRef.current?.phase !== "working") return
-        setRefine({ phase: "done", original: text, result, choice: initialChoice(result.missing) })
+        setRefine({ phase: "done", original: text, result, choice: initialChoice(result.missing), ...(used ? { tokens: used } : {}), ms: Date.now() - started })
       })
       .catch((err) => {
         if (controller.signal.aborted) return
@@ -914,6 +924,10 @@ export function App({ options }: { options: TuiOptions }) {
       case "info":
         push(e.ok === undefined ? "code" : e.ok ? "ok" : "err", e.text)
         return
+      case "call":
+        pushTool(e.text, e.ok)
+        if (!aborted()) setActivity(`Agent: ${clip(e.text, 60)}`)
+        return
       case "agent": {
         const ev = e.event
         inspect(ev)

package/src/tui/refine-panel.tsx

@@ -1,11 +1,12 @@
 import type { Refined } from "../refine.ts"
 import { Spinner } from "./components.tsx"
-import { theme } from "./theme.ts"
+import { formatDuration, formatTokens, theme } from "./theme.ts"
 
 /** Refine's panel, in the prompt's place: working, the result with what was checked, or why it could not refine. */
 export type RefineState =
   | { phase: "working"; original: string }
-  | { phase: "done"; original: string; result: Refined; choice: number }
+  /** `tokens` and `ms`: what Refine's own model session cost, shown in the title. */
+  | { phase: "done"; original: string; result: Refined; choice: number; tokens?: number; ms?: number }
   | { phase: "error"; original: string; message: string }
 
 export const REFINE_CHOICES = [
@@ -28,7 +29,10 @@ export function initialChoice(missing: string[]): number {
 
 export function RefinePanel(props: { state: RefineState; width: number; onChoose: (id: RefineChoice) => void; onHover: (i: number) => void }) {
   const { state, width } = props
-  const title = state.phase === "working" ? " ✦ Refining " : state.phase === "error" ? " ✦ Could not refine " : " ✦ Refined request "
+  const cost = state.phase === "done" && state.tokens ? ` · ${formatTokens(state.tokens)} tokens${state.ms ? ` · ${formatDuration(state.ms)}` : ""}` : ""
+  // How much of the request keeps the ASD-STE100 rules, as Refine's prompt asks.
+  const ste = state.phase === "done" && state.result.ste !== undefined ? ` · STE ${Math.round(state.result.ste * 100)}%` : ""
+  const title = state.phase === "working" ? " ✦ Refining " : state.phase === "error" ? " ✦ Could not refine " : ` ✦ Refined request${ste}${cost} `
   // Facts Refine checked that are also context lines are marked there, not repeated under Checked.
   const contextLines = state.phase === "done" ? state.result.refined.split("\n").filter((l) => l.startsWith("- ")).map((l) => norm(l.slice(2))) : []
   const inContext = new Set(contextLines)
@@ -61,9 +65,9 @@ export function RefinePanel(props: { state: RefineState; width: number; onChoose
           <text fg={theme.err}>{state.message}</text>
         ) : (
           <>
-            {/* The request as it is sent: its labelled parts (Goal, Context, Steps, Rules, Result) stand out. */}
+            {/* The request as it is sent: its labelled parts (Role, Objective, Context, Steps, Rules, Output format, Summary) stand out. */}
             {state.result.refined.split("\n").map((line, i) => {
-              const label = /^(Goal|Context|Steps|Rules|Result):/.exec(line)
+              const label = /^(Role|Objective|Context|Steps|Rules|Output format|Summary|Goal|Result):/.exec(line)
               // A context line Refine checked against the systems: ✓ in place of its dash, so it is not listed twice.
               if (line.startsWith("- ") && checked.has(norm(line.slice(2)))) {
                 return (