@gavin-hu/my-pi-agent 0.11.4 → 0.13.0

package/extensions/file-open/README.md

@@ -28,12 +28,14 @@ pi install ./                               # install the package for a user
 ## What it does
 
 - Opens a file or directory with the OS-native application: `open` on macOS,
-  `cmd /c start` on Windows, `xdg-open` on Linux.
+  `explorer` on Windows, `xdg-open` on Linux.
 - Reveals it in the file manager instead with `-r` (or `reveal: true`): `open -R`
   on macOS, `explorer /select,` on Windows, and the containing directory on
   Linux, which has no "select" verb.
 - Unwraps the editor's `@` file-mention prefix and surrounding quotes, so
   `/open @src/app.ts` and `/open @"my file.txt"` both work.
+- Reports a launcher that cannot be started, and (on macOS and Linux) a launcher
+  that exits non-zero because no handler accepted the target.
 - Resolves relative paths against the effective working directory, so under the
   `worktree` extension `/open .` opens the isolated worktree.
 - Launches the handler detached, so it outlives the Pi session.
@@ -47,14 +49,17 @@ pi install ./                               # install the package for a user
 
 The `-r` flag must come first. A missing path is reported through a notification
 and nothing is launched. An empty argument means the working directory. The
-command needs an interactive terminal UI.
+command first reports `Opening <path>` (or `Revealing <path>`); a launcher that
+starts but then fails adds a `Could not open` error notification. The command
+needs an interactive terminal UI.
 
 ## Tool
 
 `open_path` — `exposure: "codemode"`, inactive by default, not read-only,
-open-world (`openWorldHint: true` because it starts an OS process). It is
-listed by the `codemode` tool and reachable through `ctx.executeTool`; it is not
-declared to the model unless activated.
+open-world (`openWorldHint: true` because it starts an OS process). It is listed
+by the `codemode` tool for a script to call as `tools.open_path(...)`, and an
+extension can reach it through `ctx.executeTool`; it is not declared to the
+model unless activated.
 
 | Parameter | Type | Meaning |
 |---|---|---|
@@ -68,10 +73,11 @@ Result (`details` / `structuredContent`):
 | `target` | The absolute path that was handled. |
 | `reveal` | Whether it was revealed rather than opened. |
 
-The model-facing `content` is `Opened <target>` or `Revealed <target>`. A path
-that does not exist is thrown as an error naming the resolved path; a launch
-failure is reported through `ctx.ui.notify` because the handler runs detached,
-and the tool result still names the target.
+The model-facing `content` is `Opened <target>` or `Revealed <target>` — the
+handler was started, not proof that it succeeded. A path that does not exist is
+thrown as an error naming the resolved path; a launcher that cannot be started,
+or (on macOS and Linux) exits non-zero, is reported through `ctx.ui.notify`
+because the handler runs detached, and the tool result still names the target.
 
 ## Behaviour by mode
 
@@ -94,12 +100,18 @@ JSON, and print modes; a codemode script can call it in any of them. Only the
 - **Not confined.** Unlike `read_doc`, the tool opens any path on the machine:
   confinement would defeat its purpose of showing the user a file wherever it
   lives. Relative paths resolve against the effective worktree root.
-- **Best-effort launch.** A missing handler or a refused launch is reported, not
-  retried.
+- **Best-effort launch.** A launcher that cannot be started is reported, and so
+  is a non-zero exit on macOS and Linux, where `open` and `xdg-open` return a
+  failure status when no handler accepts the target. Windows `explorer` can exit
+  non-zero after a successful open, so only a failure to start is reported
+  there. Nothing is retried.
 
 ## Limitations
 
 - Reveal has no native meaning on Linux, so it opens the containing directory.
+- On Windows a refused target is not reported: `explorer` does not relay the
+  failure and its exit status is unreliable, so `/open` and `open_path` can only
+  report that the launcher started.
 - A launch that the OS accepts but the user never sees (a backgrounded app, a
   hidden window) is not detected: `spawn` reports only that the process started.
 - `-r` is parsed only as the first token of `/open`, so a path that genuinely
@@ -115,7 +127,7 @@ JSON, and print modes; a codemode script can call it in any of them. Only the
 | Command | `/open [path]` and `/open -r [path]`; reports through `ctx.ui.notify`. |
 | State | None persisted, and none needed: every call is independent. |
 | Lifecycle | No `session_start` / `session_shutdown` hooks; the factory holds no long-lived resources. |
-| Host seams | `resolveEffectiveCwd` and `isExtensionEnabled` (`lib/env.ts`), `stripControlChars` (`lib/format.ts`), `spawn` / `open` / `xdg-open` / `cmd` / `explorer` (via the injected launcher in `open.ts`). |
+| Host seams | `resolveEffectiveCwd` and `isExtensionEnabled` (`lib/env.ts`), `stripControlChars` (`lib/format.ts`), `spawn` / `open` / `xdg-open` / `explorer` (via the injected launcher in `open.ts`). |
 | Config | None. |
 
 ## Design notes
@@ -123,8 +135,11 @@ JSON, and print modes; a codemode script can call it in any of them. Only the
 `buildCommand` and `normalizeTarget` are pure and `openTarget` takes an injected
 launcher, so the command for each platform is asserted without a process and a
 test launches nothing. The launch is best-effort: `spawn` reports a missing
-handler asynchronously, so the failure goes to `onError` (and a notification)
-rather than being thrown from a synchronous call the tool could catch.
+launcher asynchronously and the child reports its exit, so both failures go to
+`onError` (and a notification) rather than being thrown from a synchronous call
+the tool could catch. `exitMeansFailure` opts Windows out because `explorer` can
+exit non-zero after a successful open. Windows opens through `explorer` rather
+than `cmd /c start` so cmd cannot re-parse a path containing `%`.
 
 The tool is `codemode`-exposed, matching how it was configured before the move:
 opening a native app is a side effect the user should trigger, so it stays out
@@ -135,7 +150,7 @@ of the model's active tool set unless a script explicitly reaches for it.
 | Module | Responsibility |
 |---|---|
 | `index.ts` | The extension factory: registers `open_path` and the `/open` command, resolves the target, and routes a launch failure to `ctx.ui.notify`. |
-| `open.ts` | `normalizeTarget` and `buildCommand` (pure), `resolveTarget` (existence check), and `openTarget` with the injectable launcher. |
+| `open.ts` | `normalizeTarget` and `buildCommand` (pure), `resolveTarget` (existence check), and `openTarget` with the injectable launcher, which reports a start failure and a meaningful non-zero exit. |
 | `schema.ts` | `TOOL_NAME`, the TypeBox `parameters` / `outputSchema`, and the `OpenPathArgs` / `OpenPathResult` types. |
 | `open.test.ts` | Pure-module tests for normalization, resolution, per-platform commands, and the launcher seam. |
 | `extension.test.ts` | Extension-surface tests: registration, disabling, the tool call, and the command. |

package/extensions/file-open/index.ts

@@ -25,8 +25,9 @@ export default function fileOpen(pi: ExtensionAPI, deps: FileOpenDeps = {}): voi
 
 	/**
 	 * Resolve `raw` against the effective root and hand it to the native
-	 * handler. A launch failure is reported through `ctx.ui.notify` because the
-	 * handler runs detached; the target is returned for the caller's message.
+	 * handler. A start failure, or a non-zero exit where the platform reports
+	 * one, goes through `ctx.ui.notify` because the handler runs detached; the
+	 * target is returned for the caller's message.
 	 */
 	const launch = (mode: OpenMode, raw: string, ctx: ExtensionContext): string => {
 		const root = resolveEffectiveCwd(ctx.cwd);
@@ -84,7 +85,7 @@ export default function fileOpen(pi: ExtensionAPI, deps: FileOpenDeps = {}): voi
 			const rest = trimmed.replace(/^-r\b\s*/, "").trim();
 			try {
 				const target = launch(reveal ? "reveal" : "open", rest, ctx);
-				ctx.ui.notify(`${reveal ? "Revealed" : "Opened"} ${target}`, "info");
+				ctx.ui.notify(`${reveal ? "Revealing" : "Opening"} ${target}`, "info");
 			} catch (error) {
 				ctx.ui.notify(error instanceof Error ? error.message : String(error), "error");
 			}

package/extensions/file-open/open.ts

@@ -5,7 +5,7 @@
  * runs is asserted without a process. `openTarget` takes an injectable spawn so
  * a test launches nothing. Opening is best-effort: the caller decides what to do
  * with a failure, which is reported through `onError` rather than thrown, since
- * `spawn` reports a missing handler asynchronously.
+ * the launcher reports a start failure and a non-zero exit asynchronously.
  */
 
 import { spawn } from "node:child_process";
@@ -19,6 +19,11 @@ export type OpenMode = "open" | "reveal";
 export interface NativeCommand {
 	command: string;
 	args: string[];
+	/**
+	 * Whether a non-zero exit means the target was not opened. Windows
+	 * `explorer` can exit non-zero after a successful open, so it opts out.
+	 */
+	exitMeansFailure: boolean;
 }
 
 /**
@@ -51,49 +56,75 @@ export function buildCommand(
 	platform: NodeJS.Platform = process.platform,
 ): NativeCommand {
 	if (platform === "darwin") {
-		return mode === "reveal" ? { command: "open", args: ["-R", target] } : { command: "open", args: [target] };
+		return mode === "reveal"
+			? { command: "open", args: ["-R", target], exitMeansFailure: true }
+			: { command: "open", args: [target], exitMeansFailure: true };
 	}
 	if (platform === "win32") {
+		// `explorer` opens with the default handler without routing the path
+		// through cmd, which would expand `%NAME%` inside it.
 		return mode === "reveal"
-			? { command: "explorer", args: [`/select,${target}`] }
-			: { command: "cmd", args: ["/c", "start", "", target] };
+			? { command: "explorer", args: [`/select,${target}`], exitMeansFailure: false }
+			: { command: "explorer", args: [target], exitMeansFailure: false };
 	}
 	// Linux et al. xdg-open has no "select" verb, so reveal opens the parent.
-	return { command: "xdg-open", args: [mode === "reveal" ? dirname(target) : target] };
+	return {
+		command: "xdg-open",
+		args: [mode === "reveal" ? dirname(target) : target],
+		exitMeansFailure: true,
+	};
+}
+
+/** The child surface `openTarget` listens on; an injected launcher may return none. */
+export interface LauncherChild {
+	on(event: "error", listener: (error: Error) => void): unknown;
+	on(event: "exit", listener: (code: number | null, signal: NodeJS.Signals | null) => void): unknown;
 }
 
 /** A launcher seam; the default spawns the command detached. */
-export type SpawnFn = (command: string, args: string[]) => unknown;
+export type SpawnFn = (command: string, args: string[]) => LauncherChild | undefined;
 
 export interface OpenTargetOptions {
 	/** Platform to build the command for; defaults to the running one. */
 	platform?: NodeJS.Platform;
 	/** Override the launcher (tests). */
 	spawn?: SpawnFn;
-	/** Called when the handler cannot be started or reports an error. */
+	/** Called once when the handler cannot start, or exits non-zero where that is meaningful. */
 	onError?: (error: Error) => void;
 }
 
+/** Spawn the handler detached so the application outlives the session. */
+const spawnDetached: SpawnFn = (command, args) => {
+	const child = spawn(command, args, { detached: true, stdio: "ignore" });
+	child.unref();
+	return child;
+};
+
 /** Start the native handler for `target`, detached so it outlives the session. */
 export function openTarget(mode: OpenMode, target: string, options: OpenTargetOptions = {}): void {
-	const { command, args } = buildCommand(mode, target, options.platform);
-	const onError = options.onError;
+	const { command, args, exitMeansFailure } = buildCommand(mode, target, options.platform);
+	const launch = options.spawn ?? spawnDetached;
 
-	if (options.spawn) {
-		try {
-			options.spawn(command, args);
-		} catch (error) {
-			onError?.(toError(error));
-		}
-		return;
-	}
+	// A start failure and an exit both arrive asynchronously; report at most
+	// one, since both can fire for the same launch.
+	let reported = false;
+	const report = (error: Error): void => {
+		if (reported) return;
+		reported = true;
+		options.onError?.(error);
+	};
 
 	try {
-		const child = spawn(command, args, { detached: true, stdio: "ignore" });
-		child.on("error", (error) => onError?.(error));
-		child.unref();
+		const child = launch(command, args);
+		child?.on("error", report);
+		if (child && exitMeansFailure) {
+			child.on("exit", (code, signal) => {
+				if (signal) report(new Error(`the OS handler was stopped by ${signal}`));
+				else if (code !== 0) report(new Error(`the OS handler exited with status ${code}`));
+			});
+		}
 	} catch (error) {
-		onError?.(toError(error));
+		report(toError(error));
 	}
 }
 

package/extensions/goal/README.md

@@ -21,7 +21,11 @@ How the `goal` call and its result look in the transcript — the call line as a
   objective. Send the complete objective every call; an empty objective clears
   it.
 - Tracks `status`: `active` while the goal is being pursued, `achieved` when it
-  is done.
+  is done. Achieving it while the branch's todo list still has open items names
+  the count in the result (`1 todo item is still open…`), so the model closes the
+  *how* instead of declaring the *what* done over an unfinished list. The count
+  is read from the branch through `lib/todo-state.ts`; the structured result is
+  unchanged.
 - Shows a persistent one-line rail above the editor whenever a goal exists,
   label-first to match the [`todo`](../todo/) widget, pinned at the top of the
   `Goal / Todos` stack when both are loaded:
@@ -44,8 +48,9 @@ How the `goal` call and its result look in the transcript — the call line as a
 - Understands the goal before recording it: `/goal <prompt>` asks the session
   model to restate the goal as it understands it and, when it cannot yet, to ask
   up to three questions — which the command asks directly through host dialogs
-  (`select` / `input`). The model then folds the answers into the final
-  restatement, and the user confirms or corrects it in the editor. `/goal set
+  (`select` / `input`). The answers are carried into the editor under the
+  restatement as `Also: <question> → <answer>` notes, and the user confirms,
+  folds them in, or corrects the goal there. `/goal set
   <prompt>` reuses the loop but records without starting a turn, `/goal edit`
   changes the current goal in place, and `/goal raw <prompt>` records the typed
   words verbatim. The loop is best-effort and needs a dialog UI plus a model; the
@@ -79,8 +84,19 @@ line: control characters (including `ESC`) become spaces and any whitespace run
 (newlines, tabs, repeated spaces) collapses to one space. This keeps the widget
 to one logical line and stops model text from injecting terminal sequences.
 
+A successful `status: "achieved"` call also appends one line to the model-facing
+text when the branch's todo list still has open items — `3 todo items are still
+open; close or clear the list if that work is done.` The list is replayed from
+the branch, so the note appears whether the todos were written by the model, by
+`/todos`, or by an approved plan. It is text only: `details`,
+`structuredContent`, and the transcript header are unaffected.
+
 `goal` is allowlisted in `plan-mode` (alongside `todo`), so the model can record
 or update the objective during read-only exploration without leaving plan mode.
+Plan mode also reads the goal: it restates an active one in its injected context,
+and when a plan is approved with no goal at all it offers to record the plan's
+title as the goal (`lib/goal-state.ts` is the reader). An existing goal — active
+or achieved — is never replaced by that offer.
 
 ### `/goal` command
 
@@ -90,9 +106,9 @@ entry; `reconstructGoal` replays both entry kinds in branch order.
 | Command | What it does |
 |---|---|
 | `/goal` | Show the current goal, or the command usage when none is set. |
-| `/goal <prompt>` | Run the understanding loop — restate, ask any questions the model needs, re-comprehend, then confirm/edit — and start the run. Replacing a live goal is confirmed first. |
+| `/goal <prompt>` | Run the understanding loop — restate, ask any questions the model needs, then confirm/edit in the editor, which carries the answers as notes — and start the run. Replacing a live goal is confirmed first. |
 | `/goal raw <prompt>` | Skip the loop: record the typed words verbatim and start the run. |
-| `/goal set <prompt>` (or `/goal edit <prompt>`) | The same loop, but record the goal without starting a run. |
+| `/goal set <prompt>` (or `/goal edit <prompt>`) | The same loop, but record the goal without starting a run. An explicit `set`/`edit <text>` replaces an active goal without asking, since the command already says so. |
 | `/goal set` (or `/goal edit`) | Open the editor prefilled with the current goal and save it as the active goal, without starting a run. |
 | `/goal done` (or `/goal achieved`) | Mark the current goal achieved (idempotent). |
 | `/goal clear` | Clear the goal. |
@@ -113,7 +129,7 @@ without one they show the usage instead. `/goal raw` never needs one.
 
 The tool works in every mode. The persistent widget requires interactive
 (`tui`) mode; the reminder and the `/goal` command work everywhere. The
-`/goal <prompt>` runs the loop: each model call uses a cancellable `tui` spinner
+`/goal <prompt>` runs the loop: its model call uses a cancellable `tui` spinner
 in interactive mode and runs directly in RPC; the questions and the confirm step
 are host dialogs, forwarded by RPC. In print and JSON mode the loop is skipped
 and the typed text is sent. The widget is always a single line; the transcript
@@ -166,8 +182,8 @@ depends on config.
 | State storage | tool-result `details` plus a `pi.appendEntry("goal", { goal })` custom entry for command-set goals |
 | Lifecycle hooks | `session_start` (load config, reconstruct), `session_tree` (reconstruct), `session_shutdown` (clear widget); `before_agent_start` (inject `goal-context`), `context` (filter stale/duplicate reminders) |
 | UI | `ctx.ui.setWidget` one-line rail in `tui` mode; coordinated through `pi.events` so it stays the top rail |
-| Model calls | Up to two `ctx.modelRegistry.complete` calls on the session model (comprehend, then re-comprehend), each with a 30 s timeout and `cacheRetention: "none"`; skipped without a dialog UI or a model; their usage is not counted in session totals |
-| Questions | When the goal is not yet understood, the command asks the model's questions through `ctx.ui.select` / `ctx.ui.input` and passes the answers to the re-comprehension call. No cross-extension tool is used. |
+| Model calls | One `ctx.modelRegistry.complete` call on the session model with a 30 s timeout and `cacheRetention: "none"`; skipped without a dialog UI or a model; its usage is not counted in session totals |
+| Questions | When the goal is not yet understood, the command asks the model's questions through `ctx.ui.select` / `ctx.ui.input` and carries the answers into the editor prefill. No cross-extension tool is used. |
 
 ## Design notes
 
@@ -181,8 +197,10 @@ depends on config.
   user-driven path: one comprehension call (`clarify-prompt.ts` + `clarify.ts`)
   returns `{ understood, goal, questions }`. An understood goal opens a prefilled
   `ctx.ui.editor`, then `pi.sendUserMessage` sets and runs it. A not-understood
-  goal has its questions asked through host dialogs and its answers folded into
-  the goal by a second model call, then confirmed in the editor. `/goal set`
+  goal has its questions asked through host dialogs, and its answers ride into
+  the editor as `Also:` notes under the restatement: no second model call
+  rewrites the goal, so the user is the one who folds them into the sentence.
+  `/goal set`
   reuses the loop but skips the send; a bare `/goal set` or `/goal edit` opens
   the editor prefilled with the current goal; and `/goal raw` skips the loop
   entirely. The loop is best-effort (a failure keeps the typed text) and a
@@ -214,6 +232,20 @@ depends on config.
   the status header alone (`Goal · active`), because the call line above it
   already carries the objective; it does not restate it. `achieved: "show"`
   restores the dimmed widget line; config only affects presentation.
+- **Completing the *what* checks the *how*.** Marking a goal achieved while the
+  todo list still holds open items appends one line to the model-facing result
+  naming the count. The list is replayed from the branch by
+  `lib/todo-state.ts` (shared with plan's approval-time merge, which reads the
+  same channel), never by importing the `todo` extension. The same reasoning
+  applies to the goal itself: `lib/goal-state.ts` owns the entry type and the
+  objective limit, and plan reads the published goal through it. Only the text is
+  affected: `details` and `structuredContent` stay the goal alone, and the
+  transcript result is still the status header.
+- **One verb table.** `GOAL_VERBS` is the only list of reserved words: the
+  parser looks a first word up in it, the completions are generated from it, and
+  a test asserts every word is offered as a completion and named in `GOAL_HELP`.
+  Adding a verb without documenting or completing it fails that test instead of
+  drifting silently.
 - **Sanitize at the boundary.** `normalizeGoal` and `parseClarification` both route
   model text through `lib/format.ts`'s `sanitizeLine`, so an embedded newline
   cannot corrupt the widget and raw escapes cannot restyle the terminal.
@@ -225,16 +257,16 @@ depends on config.
 | `index.ts` | Factory: wire the runtime, tool, command, reminder, and session events. |
 | `types.ts` | `Goal`, `GoalStatus`, `GoalDetails`. |
 | `schema.ts` | TypeBox parameters and pure validation/normalization. |
-| `clarify-prompt.ts` | Comprehension and re-comprehension prompts plus their message builders (pure). |
+| `clarify-prompt.ts` | The comprehension prompt and its message builder (pure). |
 | `clarify-parse.ts` | Parse the `{ understood, goal, questions }` reply (and the plain-text fallback), normalize questions, and expose the limits (pure). |
-| `clarify.ts` | The two model calls, their cancellable loaders, the in-command questionnaire, and the confirm/edit dialog (host). |
+| `clarify.ts` | The model call, its cancellable loader, the in-command questionnaire, and the confirm/edit dialog (host). |
 | `state.ts` | Branch reconstruction (pure). |
 | `format.ts` | Model-facing and terminal text plus the header and rail vocabulary (pure). |
 | `config.ts` | Widget config load/validation (the `goal` section of `bytefly.json`). |
 | `tui.ts` | The persistent goal widget and the transcript status header. |
 | `runtime.ts` | Session-scoped state and widget synchronization. |
 | `tools.ts` | `goal` tool registration and rendering. |
-| `commands.ts` | `/goal`. |
+| `commands.ts` | `/goal`: the `GOAL_VERBS` table, the argument parser, the completions, and the command handler. |
 
 ## Testing
 

package/extensions/goal/clarify-prompt.ts

@@ -1,15 +1,14 @@
 /**
  * Prompt text for the goal comprehension step (pure).
  *
- * Both system prompts are sent only on the nested clarifier calls, so they are
- * not part of Pi's always-on prompt budget. The model's job is to understand and
- * restate the user's goal — not to improve it — and, when it cannot yet, to ask
- * only what it needs from the user. The second call folds the answers into the
- * final restatement.
+ * Sent only on the nested clarifier call, so it is not part of Pi's always-on
+ * prompt budget. The model's job is to understand and restate the user's goal —
+ * not to improve it — and, when it cannot yet, to ask only what it needs from
+ * the user.
  */
 
 import type { UserMessage } from "@earendil-works/pi-ai";
-import { MAX_QUESTIONS, type ClarifyAnswer } from "./clarify-parse.ts";
+import { MAX_QUESTIONS } from "./clarify-parse.ts";
 
 /** The comprehension system prompt: understand the goal, ask only what is missing. */
 export const CLARIFY_SYSTEM_PROMPT = `You are establishing a shared understanding of the user's goal for this session.
@@ -33,12 +32,6 @@ Rules:
 - Ask only what only the user can answer: purpose, scope, preference, or priority. Never ask for a fact the work itself would reveal, and never ask the user to restate the goal.
 - Give a question 2-4 concrete options when the answers are a small known set, or no options at all when free-form.`;
 
-/** The re-comprehension system prompt: fold the answers into one goal statement. */
-export const REFINE_SYSTEM_PROMPT = `The user has answered questions about their goal. Restate the goal as you now understand it.
-
-Reply with ONLY the goal as one sentence, no prose and no code fence.
-Use their answers and the original request; add nothing they did not state.`;
-
 /** The user message sent to the clarifier alongside {@link CLARIFY_SYSTEM_PROMPT}. */
 export function buildClarifyUserText(text: string): string {
 	return `Understand this session goal:\n\n${text}`;
@@ -54,27 +47,3 @@ export function buildClarifyMessages(
 		messages: [{ role: "user", content: [{ type: "text", text: buildClarifyUserText(text) }], timestamp: now }],
 	};
 }
-
-/** The user message that carries the original request, the first restatement, and the answers. */
-export function buildRefineUserText(original: string, goal: string, answers: readonly ClarifyAnswer[]): string {
-	const lines = [`Original request:\n${original}`];
-	if (goal) lines.push(`First restatement: ${goal}`);
-	lines.push("The user was asked, and answered:");
-	for (const item of answers) lines.push(`- ${item.question}\n  ${item.answer}`);
-	return lines.join("\n");
-}
-
-/** The request sent to the clarifier after the user answers. */
-export function buildRefineMessages(
-	original: string,
-	goal: string,
-	answers: readonly ClarifyAnswer[],
-	now = Date.now(),
-): { systemPrompt: string; messages: UserMessage[] } {
-	return {
-		systemPrompt: REFINE_SYSTEM_PROMPT,
-		messages: [
-			{ role: "user", content: [{ type: "text", text: buildRefineUserText(original, goal, answers) }], timestamp: now },
-		],
-	};
-}