relay-flow 0.2.5-alpha → 0.2.7-alpha

package/README.md

@@ -1,36 +1,160 @@
 # relay-flow
 
-Durable, graph-based agent workflow runner. A ticket is the unit of work; a workflow YAML declares nodes and routes; a durable engine (go-workflows + SQLite) drives progression, waits, retries, and recovery. The task system (Jira and Beads built-ins) supplies parent tickets and mailbox subtasks; the runner (Orca built-in) owns worktrees and terminals; the harness (OpenCode and Pi built-ins) owns agent sessions and report semantics. All three are pluggable.
+Durable, graph-based agent workflow runner. A ticket is the unit of work; a workflow YAML declares nodes and routes; a durable executor drives progression, waits, retries, and recovery. Task systems (Jira and Beads), runners (Orca and Herdr), harnesses (OpenCode and Pi), and durable executors (go-workflows and Temporal) are selectable independently.
 
 This is a ground-up rewrite. The previous per-workflow, in-memory daemon is gone. There is no migration path and no compatibility layer.
 
 ---
 
-## Setup
+## Quick start
 
-### Prerequisites
+### 1. Install relay-flow
 
-| Tool | Why |
-|---|---|
-| [opencode](https://opencode.ai) | Agents run in opencode sessions (harness) |
-| [Orca](https://github.com/Necmttn/orca) CLI + app | Worktrees + terminals (runner) |
-| `bd` CLI | Beads task-system access (required when `taskPlugin: beads`) |
-| Dolt | External/server-backed Beads only |
-| Jira API token | Jira REST API v3 access (required when `taskPlugin: jira`) |
-| Go 1.24+ | Build the CLI |
+Install the latest released CLI with Homebrew:
 
-### Install
+```sh
+brew install rajpopat27/tap/relay-flow
+```
+
+### 2. Install the harness extension
+
+Choose the harness that will run your agent sessions. Both commands install the
+same `relay-flow-plugin` package with host-specific entrypoints.
+
+**OpenCode**
+
+```sh
+opencode plugin relay-flow-plugin@0.2.7-alpha
+```
+
+**Pi**
+
+```sh
+pi install npm:relay-flow-plugin@0.2.7-alpha
+```
+
+Pi loads the package's `pi.ts` extension from its manifest. Do not add
+`-e`/`--extension` to relay-flow's Pi launch command.
+
+### 3. Initialize relay-flow
+
+Choose one task system, runner, harness, and durable executor. This example
+uses Jira, Orca, OpenCode, and the default embedded executor:
 
 ```sh
-go install github.com/rajpopat27/relay-flow/cmd/relay-flow@latest
+relay-flow init \
+  --task-plugin jira \
+  --runner-plugin orca \
+  --harness-plugin opencode
 ```
 
+The default executor is `goworkflows` with SQLite. To use Temporal instead,
+add `--executor-plugin temporal`, `--temporal-address <host:port>`, and
+`--temporal-namespace <name>` to the command.
+
+### 4. Authenticate the task system
+
+For Jira, authenticate the selected task plugin:
+
+```sh
+relay-flow task auth
+```
+
+For Beads, skip this command and initialize/authenticate the Beads workspace
+with `bd` and, when needed, Dolt. See [Beads task system](#beads-task-system)
+below.
+
+### 5. Start the server
+
+```sh
+relay-flow serve --background
+```
+
+### 6. Register a repository
+
+The repository must already exist in the selected runner. For Orca:
+
+```sh
+orca repo add --path /work/payments
+relay-flow repo register
+```
+
+For Herdr, register the repository path directly; relay-flow creates ticket
+worktrees lazily. The interactive registration asks for the task-system values
+required by the selected task plugin.
+
+### 7. Submit a workflow
+
+```sh
+relay-flow workflow submit --file examples/minimal-jira-task-workflow.yaml
+relay-flow workflow list
+```
+
+Replace the example workflow with
+`examples/minimal-beads-task-workflow.yaml` when using Beads. The workflow's
+`repos` value must match the name used during repository registration.
+
+## Supported plugins
+
+Each category is a replaceable boundary. Select one plugin from each category
+at initialization; the workflow YAML and core orchestration do not change when
+you switch an implementation.
+
+| Category | Supported plugins | Owns |
+|---|---|---|
+| Task system | `jira`, `beads` | Parent tickets, mailbox subtasks, task state, labels, comments, and task configuration |
+| Runner | `orca`, `herdr` | Ticket worktrees, environments, terminals, process liveness, and cleanup |
+| Harness | `opencode`, `pi` | Agent launch commands, sessions, prompts, report parsing, nudges, and resume behavior |
+| Durable executor | `goworkflows`, `temporal` | Graph progression, waits, retries, recovery, and durable execution state |
+
+The default durable executor is `goworkflows`, which stores execution state in
+SQLite. `temporal` uses an external Temporal server and is selected with the
+Temporal address and namespace during `init`.
+
+The plugin composition is explicit:
+
+```text
+Task system (Jira or Beads)
+        │
+        ▼
+Durable executor (go-workflows or Temporal)
+        │
+        ▼
+Runner (Orca or Herdr)
+        │
+        ▼
+Harness (OpenCode or Pi)
+        │
+        ▼
+relay-flow report transport
+```
+
+The equivalent non-interactive selection is:
+
+```sh
+relay-flow init \
+  --task-plugin <jira|beads> \
+  --runner-plugin <orca|herdr> \
+  --harness-plugin <opencode|pi> \
+  --executor-plugin <goworkflows|temporal>
+```
+
+`--executor-plugin` defaults to `goworkflows`. Jira requires Jira credentials;
+Beads requires the `bd` CLI and a configured workspace. Orca requires its CLI
+and app; Herdr requires its CLI/server. OpenCode and Pi each require their
+corresponding agent runtime. These integrations remain behind their small
+contracts, so task-system fields do not leak into runners or harnesses.
+
+## Detailed setup
+
+### Harness configuration
+
 OpenCode plugin configuration uses both entrypoints. The server entrypoint is listed in `opencode.json`:
 
 ```json
 {
   "$schema": "https://opencode.ai/config.json",
-  "plugin": ["relay-flow-plugin"]
+  "plugin": ["relay-flow-plugin@0.2.7-alpha"]
 }
 ```
 
@@ -39,7 +163,7 @@ The native HITL approval entrypoint is listed in `.opencode/tui.json`:
 ```json
 {
   "$schema": "https://opencode.ai/tui.json",
-  "plugin": ["relay-flow-plugin"]
+  "plugin": ["relay-flow-plugin@0.2.7-alpha"]
 }
 ```
 
@@ -55,7 +179,7 @@ Pi plugin: install the same published package manually in Pi's global package
 settings before starting a Pi harness session:
 
 ```sh
-pi install npm:relay-flow-plugin@<version>
+pi install npm:relay-flow-plugin@0.2.7-alpha
 ```
 
 Relay-flow does not install or configure the package automatically. Pi resolves
@@ -71,14 +195,14 @@ structured report, applies the agent/HITL nudge policy, and delivers
 `reportId` comes from the harness session/message identity; `nodeVisitID` is
 internal and is never part of either plugin payload.
 
-### One-time machine setup
+### Machine setup details
 
 ```sh
 relay-flow init
 relay-flow task auth
 ```
 
-`init` only selects the task system, runner, and harness (singleton options are automatic), writes machine config, and initializes SQLite. `task auth` delegates authentication to that selected task plug-in. Jira prompts for its site, email, and masked API token, validates `/myself`, and owns the system-wide `credentials.yaml`; for scripts, pass `task auth --site`, `--email`, and `--token`. A normal init rerun refuses existing state. `relay-flow init --force` updates safe stopped instances while preserving durable and repo state.
+`init` selects the task system, runner, harness, and durable executor (singleton options are automatic), writes machine config, and initializes the selected execution backend. `task auth` delegates authentication to that selected task plug-in. Jira prompts for its site, email, and masked API token, validates `/myself`, and owns the system-wide `credentials.yaml`; for scripts, pass `task auth --site`, `--email`, and `--token`. A normal init rerun refuses existing state. `relay-flow init --force` updates safe stopped instances while preserving durable and repo state.
 
 For Beads, select the plugin explicitly when scripting setup:
 
@@ -135,7 +259,7 @@ Shows a multi-select titled `Select repositories`; use Space to select Orca repo
 
 Each Jira poll uses REST v3 enhanced search and requests linked-issue status with the candidate fields. Tickets with any unfinished inward `Blocks` issue are filtered before routing; no per-ticket blocker lookup is made.
 
-For scripts, use `relay-flow repo register --name <name> --path <path> --set project=<project>`. Component is always derived from `--name` and cannot be overridden. Registration is rejected while another repo already holds the same canonical task scope.
+For scripted Jira registration, use `relay-flow repo register --name <name> --path <path> --set project=<project>`. Component is always derived from `--name` and cannot be overridden. Registration is rejected while another repo already holds the same canonical task scope.
 
 ### Beads task system
 
@@ -177,7 +301,13 @@ bd init \
 # Example external workspace: /var/lib/beads/payments/.beads
 ```
 
-Register the code repository and its Beads workspace separately. `beadsDir` is required for every Beads repo, must name an existing directory, and is the task scope used to reject duplicate workspace registration:
+For the relay-flow installation used by this repository, the configured Beads workspace is:
+
+```text
+/home/raj/.beads/relay-flow/.beads
+```
+
+Register the code repository and its Beads workspace separately. `beadsDir` is required for every Beads repo and must name an existing directory. It selects the Beads workspace/database; it is not the code repository path or a workflow filter:
 
 ```sh
 # Local/embedded workspace
@@ -193,7 +323,7 @@ relay-flow repo register \
   --set beadsDir=/var/lib/beads/payments/.beads
 ```
 
-The registered `--path` remains the code/runner repository. Every `bd` command runs with that path as its working directory and the configured `beadsDir` as `BEADS_DIR`, even when unrelated Beads selector variables exist in the relay-flow environment. Two repos may register different canonical `beadsDir` values; a second repo pointing at the same workspace is rejected. A Beads prefix such as `payments-...` is optional and only makes issue IDs recognizable—it is not a component, workspace selector, poller selector, or database isolation mechanism.
+The registered `--path` remains the code/runner repository. Every `bd` command runs with that path as its working directory and the configured `beadsDir` as `BEADS_DIR`, even when unrelated Beads selector variables exist in the relay-flow environment. Multiple code repositories may share one Beads/Dolt workspace when their derived repository labels differ. Relay-flow derives one reserved label, `repo:<lowercase-registered-name>`, for each repository; names must use letters, numbers, `.`, `_`, or `-`, and be at most 250 characters so the derived label stays within Beads' 255-character limit. The label is not entered in workflow configuration. A parent must carry exactly one such repository label to be eligible for that repo's poller: missing or ambiguous `repo:` labels are ignored before workflow filters and routing. Workflow ownership labels remain independent `wf:<workflow>` labels. A collision between derived labels in the same workspace is rejected before the second repository is registered. A Beads prefix such as `payments-...` is optional and only makes issue IDs recognizable—it is not a component, workspace selector, poller selector, or database isolation mechanism.
 
 Beads workflow filters are structured and evaluated in relay-flow. For example, `examples/beads-workflow.yaml` uses the Beads status and issue-type fields:
 
@@ -211,7 +341,7 @@ Filter values are exact and are not translated between providers.
 
 The supported Beads status names are `open`, `in_progress`, `blocked`, `deferred`, `hooked`, and `closed`. The claimed-parent poll uses the canonical active set `open,in_progress,blocked,deferred`; it intentionally does not substitute `hooked` for `deferred`. Omitted lifecycle settings move the parent to `in_progress` at `start`, a work-node mailbox to `in_progress`, and the parent to `closed` at `end` — the same shape as Jira, with Beads-native values. Relay-flow creates one Repo Poller per registered repo, not one poller per workflow. Each poll reads ready top-level parents and relay-owned active parents, deduplicates them, and never routes mailbox children. Claims are permanent `wf:<workflow>` labels.
 
-Beads does not need relay-flow credentials or a Beads-specific poller. In server mode, leave Dolt and Beads server setup running outside relay-flow and point each repo at its own `beadsDir`.
+Beads does not need relay-flow credentials or a Beads-specific poller. In server mode, leave Dolt and Beads server setup running outside relay-flow; each registered code repository still supplies its `beadsDir`, and repositories that share that workspace are isolated by their derived `repo:` labels.
 
 ### Submit a workflow
 
@@ -223,10 +353,7 @@ Workflows live at `~/.relay-flow/workflows/<name>.yaml` after submit. Replacemen
 
 Use [`examples/config-reference.yaml`](examples/config-reference.yaml) for the complete machine configuration, [`examples/workflow-reference.yaml`](examples/workflow-reference.yaml) for the complete workflow schema, or the provider-specific minimal workflows [`examples/minimal-jira-task-workflow.yaml`](examples/minimal-jira-task-workflow.yaml) and [`examples/minimal-beads-task-workflow.yaml`](examples/minimal-beads-task-workflow.yaml). Runtime node agents should follow [`docs/agent-instructions.md`](docs/agent-instructions.md). The existing [`examples/default-story-workflow.yaml`](examples/default-story-workflow.yaml) remains a more detailed Jira Story example, while [`examples/beads-workflow.yaml`](examples/beads-workflow.yaml) shows the Beads lifecycle shape. Replace the repo name and uncomment only the optional fields you need.
 
-Task, runner, and harness plugins are selected machine-wide. A single relay-flow
-configuration cannot run Jira and Beads simultaneously; use separate
-`RELAY_FLOW_HOME` directories or machine configurations when both providers are
-needed.
+Task, runner, harness, and durable executor plugins are selected machine-wide. A single relay-flow configuration cannot run Jira and Beads simultaneously; use separate `RELAY_FLOW_HOME` directories or machine configurations when both providers are needed.
 
 ### Run
 
@@ -256,6 +383,8 @@ cleanupRunnerOnEnd: false        # optional; when true the runner tears down at
 taskConfig:                      # optional; adapter-owned; merged root → repo → workflow → node
   filters:
     parentStatuses: [To Do]
+    labels: ["workflow:true"]
+    assignees: ["currentUser()"] # Jira resolves this to the authenticated email.
 
 nodes:
   start:
@@ -265,20 +394,43 @@ nodes:
     onSuccess: [{ target: coding }]
 
   coding:
-    type: agent                  # or hitl
-    agent: build                 # opencode agent
+    type: agent
+    agent: build
     description: |               # becomes the mailbox description and launch prompt
-      Implement the ticket.
+      Implement the ticket in the current worktree.
+    nudgePrompt: |
+      Continue working on {{ticket}}. Read the parent {{taskSystem}} ticket
+      {{ticket}} and your assigned ticket {{mailbox}} to understand the requirements. Read
+      the latest feedback, address the requested changes, and work on the next
+      bounded task slice. Return the complete report. Valid choices are:
+      {{nextSteps}}.
     onSuccess: [{ target: reviewing, when: "work complete" }]
     onFailure: [{ target: coding,   when: "retry" }]
-    nudgePrompt: "Check edge cases for {{ticket}} before reporting." # optional custom instructions
 
   reviewing:
+    type: agent
+    agent: plan
+    description: Review the completed implementation and report required changes.
+    nudgePrompt: |
+      Review {{ticket}}. Read the parent {{taskSystem}} ticket {{ticket}} and
+      your assigned ticket {{mailbox}} to understand the requirements. Re-check the
+      implementation and latest coding feedback, then return the complete
+      report. Valid choices are:
+      {{nextSteps}}.
+    onSuccess: [{ target: humanReview, when: "ready for human review" }]
+    onFailure: [{ target: coding,      when: "changes required" }]
+
+  humanReview:
     type: hitl
-    agent: build
-    description: Human review.
-    onSuccess: [{ target: end }]
-    onFailure: [{ target: coding }]
+    agent: plan
+    description: Approve the reviewed implementation or request changes.
+    nudgePrompt: |
+      Review the completed work for {{ticket}} with the human. Read the parent
+      {{taskSystem}} ticket {{ticket}} and your assigned ticket {{mailbox}} to
+      understand the requirements. Return the complete report. Valid choices are:
+      {{nextSteps}}.
+    onSuccess: [{ target: end,    when: "approved" }]
+    onFailure: [{ target: coding, when: "changes requested" }]
 
   end: {}
 ```
@@ -462,7 +614,7 @@ tickets are not reopened automatically.
 ## Architecture
 
 - **Task system** owns parent tickets, mailbox subtasks, task state, labels, comments, and adapter config. The parent ticket is the unit of work.
-- **Durable workflow engine** (go-workflows + SQLite) owns graph progression, waits, reports, retries, and recovery. No custom state machine.
+- **Durable workflow engine** (`goworkflows` + SQLite or `temporal`) owns graph progression, waits, reports, retries, and recovery. No custom state machine.
 - **Mailbox subtask** is one agent/HITL node's scratch space; its description defines the node's work and its comments hold the node's summary plus selected incoming feedback.
 - **Harness** owns agent launch, session/report behavior, parsing, nudging, and resume semantics.
 - **Runner** owns ticket worktrees/environments, terminals, liveness, and execution of harness commands.

package/cmd/relay-flow/beads_composition_test.go

@@ -361,9 +361,9 @@ issue_json() {
   case "$issue" in
     demo-parent)
       if [ -f "$BD_STATE/claimed" ]; then
-        labels='["wf:beadsComposition"]'
+        labels='["repo:payments","wf:beadsComposition"]'
       else
-        labels='[]'
+        labels='["repo:payments"]'
       fi
       printf '[{"id":"demo-parent","title":"Composition parent","status":"%s","issue_type":"epic","priority":1,"labels":%s}]\n' "$status" "$labels"
       ;;
@@ -385,7 +385,7 @@ if [ "$#" -eq 6 ] && [ "$1" = list ] && [ "$2" = --ready ] && [ "$3" = --no-pare
   if [ -f "$BD_STATE/claimed" ]; then
     printf '[]\n'
   else
-    printf '[{"id":"demo-parent","title":"Composition parent","status":"open","issue_type":"epic","priority":1,"labels":[]}]\n'
+    printf '[{"id":"demo-parent","title":"Composition parent","status":"open","issue_type":"epic","priority":1,"labels":["repo:payments"]}]\n'
   fi
   exit 0
 fi

package/examples/beads-workflow.yaml

@@ -4,6 +4,9 @@
 #   relay-flow repo register --name payments --path /work/payments \
 #     --set beadsDir=/work/payments/.beads
 #
+# Relay-flow derives the reserved repo:payments label from the registered
+# repository name. Parents without exactly one matching repo: label are
+# ignored before workflow filters; wf:<workflow> remains a separate claim.
 # The Beads prefix is optional and is not a workspace/component selector.
 name: beadsStoryFlow
 repos:

package/examples/config-reference.yaml

@@ -118,7 +118,11 @@ repos:
 #
 # Beads uses the shared taskConfig fields (filters, assignee, transitionTo,
 # templates) but does not accept Jira-only project/component fields. beadsDir
-# is required at repo scope and must not be supplied only at root scope.
+# is required at repo scope and must not be supplied only at root scope. The
+# registered code path is the bd working directory; beadsDir selects the
+# workspace/database. Shared workspaces isolate parents with the derived
+# reserved repo:<lowercase-repo-name> label (the registered name may be at
+# most 250 ASCII characters), not with workflow labels.
 #
 # Pi variant:
 # harnessPlugin: pi

package/examples/default-story-workflow.yaml

@@ -11,10 +11,11 @@ taskConfig:
       - To Do
     issueTypes:
       - Story
-    # labels:
-    #   - coding
-    # assignees:
-    #   - owner@example.com
+    labels:
+      - "workflow:true"
+    assignees:
+      - currentUser()
+      # Jira resolves currentUser() to the authenticated Jira email.
   # assignee: default-node-owner@example.com
   # project: PAY
   # component: api
@@ -28,48 +29,62 @@ nodes:
       transitionTo:
         parentStatus: In Progress
     onSuccess:
-      - target: implement
+      - target: coding
         when: The parent story is ready for implementation
 
-  implement:
+  coding:
     type: agent
     agent: build
-    description: Implement the parent story and verify the changes.
-    # nudgePrompt: "Finish {{node}} for {{ticket}} and choose one of: {{nextSteps}}"
+    description: Implement the parent story in the current ticket worktree.
+    nudgePrompt: |
+      Continue working on {{ticket}}. Read the parent {{taskSystem}} ticket
+      {{ticket}} and your assigned ticket {{mailbox}} to understand the requirements. Read
+      the latest feedback, address the requested changes, and work on the next
+      bounded task slice. Return the complete report. Valid choices are:
+      {{nextSteps}}.
     taskConfig:
       # assignee: developer@example.com
       transitionTo:
         taskStatus: In Progress
         # parentStatus: In Progress
     onSuccess:
-      - target: review
+      - target: reviewing
         when: Implementation and verification are complete
     onFailure:
-      - target: implement
+      - target: coding
         when: Implementation needs another pass
 
-  review:
+  reviewing:
     type: agent
     agent: plan
-    description: Review the implementation for correctness, regressions, and missing tests.
-    # nudgePrompt: "Complete the review for {{ticket}}. Valid routes: {{nextSteps}}"
+    description: Review the completed implementation and report required changes.
+    nudgePrompt: |
+      Review {{ticket}}. Read the parent {{taskSystem}} ticket {{ticket}} and
+      your assigned ticket {{mailbox}} to understand the requirements. Re-check the
+      implementation and latest coding feedback, then return the complete
+      report. Valid choices are:
+      {{nextSteps}}.
     taskConfig:
       # assignee: reviewer@example.com
       transitionTo:
         taskStatus: In Progress
         # parentStatus: In Review
     onSuccess:
-      - target: prReview
+      - target: humanReview
         when: The changes are ready for human approval
     onFailure:
-      - target: implement
+      - target: coding
         when: Code changes are required
 
-  prReview:
+  humanReview:
     type: hitl
     agent: plan
-    description: Discuss the pull request with the human and obtain approval.
-    # nudgePrompt: "Review {{ticket}} with the human. Valid routes: {{nextSteps}}"
+    description: Approve the reviewed implementation or request changes.
+    nudgePrompt: |
+      Review the completed work for {{ticket}} with the human. Read the parent
+      {{taskSystem}} ticket {{ticket}} and your assigned ticket {{mailbox}} to
+      understand the requirements. Return the complete report. Valid choices are:
+      {{nextSteps}}.
     taskConfig:
       # assignee: human-reviewer@example.com
       transitionTo:
@@ -79,7 +94,7 @@ nodes:
       - target: end
         when: The human approves the review
     onFailure:
-      - target: implement
+      - target: coding
         when: The human requests code changes
 
   end:

package/internal/execution/goworkflows/activities.go

@@ -44,6 +44,21 @@ func (a *Activities) runSpec(w run.Work) runner.RunSpec {
 	}
 }
 
+// agentEnv returns the repo task system's agent workspace environment, or nil
+// when the adapter exposes none. It is resolved at launch time so no workspace
+// value is carried in durable workflow history.
+func (a *Activities) agentEnv(repoName string) (map[string]string, error) {
+	sys, err := a.taskSystem(repoName)
+	if err != nil {
+		return nil, err
+	}
+	provider, ok := sys.(task.AgentEnvironment)
+	if !ok {
+		return nil, nil
+	}
+	return provider.AgentEnv(), nil
+}
+
 // EnsureMailboxes ensures one mailbox per work node and returns the
 // node-to-mailbox map.
 func (a *Activities) EnsureMailboxes(ctx context.Context, w run.Work, specs []task.MailboxSpec) (map[string]task.Mailbox, error) {
@@ -220,6 +235,10 @@ func (a *Activities) EnsureNodeRuntime(ctx context.Context, nw run.NodeWork, rep
 	if err != nil {
 		return err
 	}
+	spec.TaskEnv, err = a.agentEnv(nw.Repo)
+	if err != nil {
+		return err
+	}
 	cmd, err := a.Harness.BuildCommand(spec)
 	if err != nil {
 		return err

package/internal/execution/goworkflows/engine_test.go

@@ -71,7 +71,7 @@ func TestMailboxDescriptionAndLaunchPromptAreTaskSystemNeutral(t *testing.T) {
 		if err != nil {
 			t.Fatal(err)
 		}
-		want := "Task system: " + taskSystem + "\nUse the " + taskSystem + " tools to read the parent ticket PAY-101.\n\nYour mailbox is PAY-234. Read its description and comments for node instructions and feedback.\n\nReturn the complete report directly. Relay-flow will show a native TUI approval dialog after the report is valid. Do not use OpenCode's Question tool for relay-flow approval."
+		want := "Task system: " + taskSystem + "\nUse the " + taskSystem + " tools to read the parent ticket PAY-101.\n\nYour mailbox is PAY-234. Read its description and comments for node instructions and feedback.\n\nKeep the summary brief, and make the feedback as detailed and actionable as possible for the next agent.\n\nReturn the complete report directly. Relay-flow will show a native TUI approval dialog after the report is valid. Do not use OpenCode's Question tool for relay-flow approval."
 		if prompt != want {
 			t.Fatalf("RenderPrompt(%s) = %q, want %q", taskSystem, prompt, want)
 		}