fix(workflow): early-end tip-unchanged/open-PR; arm deadline without ephemeral

changelog.d/1570-early-end-tip-openpr.fixed.md

@@ -0,0 +1 @@
+**Workflow early-end stops tip-unchanged and open-PR loops (#1570):** Claim/Verify (and any step) that signals `tip-unchanged` or an already-open PR now ends the run immediately — including on the fail/onFail path — so loop and recovery edges cannot burn their max attempts on the same tip SHA. Preferred markers are OUTPUT values or a whole-line `EARLY-END <reason>`; common phrases (`tip unchanged`, `has open PR`, …) are honored when a Bot forgets the structured marker. `needs-human` and `already-claimed` stay. Factory guidance is in `EARLY_END_GUIDANCE`.

changelog.d/1571-step-deadline-no-ephemeral.fixed.md

@@ -0,0 +1 @@
+**Workflow step deadlines arm without an ephemeral Bot map (#1571):** a live running step now gets the ten-minute `STEP_DEADLINE_MS` even when the host cannot spawn run Bots, so a silent step cannot hold a lane forever. A test covers expiry with no reply and no ephemeral map.

docs/subsystems/workflow.md

@@ -31,7 +31,7 @@ Everything in `plugins/workflow/`: the graph rules, the run store, the matcher,
 | `plugins/workflow/src/service.js` | The store, lanes (active runs, FIFO queue, terminal history), `maxConcurrent`, `rename`, `delete`, `saveGraph`, `define`, `runNamed`, `ingest`, `stepResult`. `rename` updates a workflow's name and optional description; `delete` removes the workflow, releases ephemeral Bots, and cleans logs/runs/routes. Factory template ids (e.g. `delivery`) are normal saved rows and may be deleted. A spawn hook makes one run Bot per node. Disposing the plugin ends every live run still marked `running` (nodes in flight are failed, the run is archived) and then releases every run Bot and drops those ids from the saved record only once the release has finished, handing the release back as a promise the host awaits, so a shutdown cannot persist a run as `running` with no ephemeral map and cannot leave hidden Bots that no state names (#1387, #1414). A released run Bot also gives its runner name back to the allocator instead of keeping it for the lifetime of the process. A dispatch that does not land is not marked handed: it is retried twice with a short backoff, and a step still unanswered after `STEP_DEADLINE_MS` (10 minutes) fails the run and releases its Bots (#1530). |
 | `plugins/workflow/src/ephemeral.js` | Builds each node's run Bot from its prompt, role, model and tools, and releases the ids the host returns. `node.tools` names the connectors that node may call: `spawn` passes the cleaned list to `fb.bot.create`, the host records it as `stepTools`, and `connector-access.js` allows only the connectors it names (`github` covers `mcp__github__*`, `composio` covers `mcp__composio__*`) — a node that names none reaches none. File and shell rights do not come from that list: every node Bot gets the `danger-full-access` preset a normal sidebar Bot has, and `EPHEMERAL_DENIED_TOOLS` still refuses the team tools at the guard and approval layers. The list is also stored in `fields.tools` for the UI. |
 | `plugins/workflow/src/match.js` | Which open card matches a Workflow or a local Bot. |
-| `plugins/workflow/src/template.js` | 发布交付流水线 (a parallel branch) and the weekly report, each node with the inputs and outputs that edge carries. |
+| `plugins/workflow/src/template.js` | Factory delivery/weekly graphs plus `EARLY_END_GUIDANCE` for Claim/Verify/Triage early-end markers; 发布交付流水线 (a parallel branch) and the weekly report, each node with the inputs and outputs that edge carries. |
 | `plugins/workflow/src/narrate.js` | Progress lines for a step. A live run quotes the Bot reply when present; otherwise delivery-template nodes may use canned copy. A join line is only for a rank of more than one node. |
 | `plugins/workflow/client.js` | Sidebar section (with mini-flowcharts), workflow stage (view/control: one card per live run with its own title, node line, segment progress, status chip, and Pause / Resume / Stop; click a card or its Flow button to focus that run in the drawer flowchart; optional aggregate chip when several run or the queue is non-empty — no message composer), assign dialog (scrollable with sticky footer), flowchart drawer (collapsed by default, per-node inspector, fitted to the 400px panel so the graph needs no inner horizontal scroll), and Settings → Workflow graphs (canvas-first with inspector panel). The product UI starts only live runs (assign, ingest). The stage shows the queue and refreshes state while runs are active; a running node uses a breathing border animation. Visual flowcharts replace text chains across all surfaces. Sidebar rows (including factory ids such as `delivery`) support Delete with confirm. The stage and dialogs portal onto `document.body`; a missing container stays in the section tree. A stage control that fails — a graph save, Reset, Pause, Resume or Stop that throws, rejects, answers `{ok:false}` or does not answer within 10 s — ends on the section's `.wf-err` alert instead of being swallowed, and a success clears the alert. |
 
@@ -46,7 +46,7 @@ Everything in `plugins/workflow/`: the graph rules, the run store, the matcher,
 
 1. Friends' Bots are not nodes. A `remote` Bot is refused by create, define and the matcher.
 2. The canvas and the run share one graph: nodes, edges and positions. A drag commits `workflow/graph`, but only while **Edit** is on — a factory preset is copied first (#1378). Status highlighting reads that same graph. Replacing edges does not recompute who is already running. The Settings canvas paints that graph on the same 960px design plane, scaled to the width the settings page gives it, so the canvas is not a second scroll container inside the page's own scroll; its pointer deltas are divided by the scale, and its wires keep a stronger stroke than a plain divider so an edge can be followed at that size (#1483).
-3. **A live run advances only when its ephemeral Bot replies, following the graph's edges in order.** That reply advances the run and may appear on the workflow stage log; it is not delivered into a persistent sidebar Bot conversation (for example Chief). The `workflow-step` send middleware denies those replies after `stepResult` runs. Nodes start only when their forward predecessors finish and edges reach them. **Early termination (#1537, #1538):** When a node completes with `needs-human` or `already-claimed` detected in its outputs or reply text (see `checkEarlyEnd` in Key files), the run ends immediately with status `done`, sets `run.earlyEnd` to the condition name, and does not advance to or spawn successor nodes. This allows Triage, Claim, or any step to terminate the pipeline cleanly when human intervention is required or the issue is already owned by another agent. There is no scripted or seeded run path: `workflow/state` exposes only `live === true` runs. A run does not create a schedule. `scheduleLabel` is display text. When the host can create Bots, starting a live run (`assign`, `run_workflow`, `ingest`) spawns one ephemeral Bot per node from that node's prompt, role, model and tools, sends it the step from the Main Bot, and removes every instance when the run finishes, fails for good, or is reset. A `failOnce` retry keeps them. They are hidden and left out of the sidebar. Loading the plugin does not spawn Bots for the default workflows. Plugin unload (`dispose`) and the load-time `reap` both end a live run still marked `running`: in-flight nodes are failed, the run is archived as `failed`, and any ephemeral Bot ids are released. A run already written as `running` with no ephemeral map (an older unload) is healed the same way on the next load (#1414). Loading is also the one moment a run the host left behind is noticed when its ephemeral map is still present: `reap` releases those instances and records the run as `failed`. Nothing resumes it. A run that already ended keeps its own status (#1388). `workflow/reset` stopping one live run ends it the same way before its Bots are released: nodes still `running` become `failed`, so the strip cannot keep painting a run that is over (#1424). Every wait is bounded (#1530). A dispatch that does not land is not marked handed: the chat names the code and the attempt, and it is retried after a short backoff at most twice, never twice inside one hand-off, so a 429 is not hammered. When it still does not land, the step and the run fail with the reason written into the chat. Each running step also holds a deadline — `STEP_DEADLINE_MS`, ten minutes, one constant in `service.js`; when it expires the node and the run fail as `failed`, the run's ephemeral Bots are released, the chat says the step timed out, and `warn` names it once. The deadline is cleared as soon as the step moves, and by Pause, Stop, Reset, delete, `reap` and `dispose`; a paused run holds none, and Resume arms it again from that moment. A timer never outlives the run that started it. A reply that matches no running step — its run ended, or the node already moved — is reported through `warn` once per Bot and run instead of being dropped silently. A reply that says `could not answer your message` or `model call failed` fails that node and does not start its successor. A 429 or rate-limit mention in any other reply does not.
+3. **A live run advances only when its ephemeral Bot replies, following the graph's edges in order.** That reply advances the run and may appear on the workflow stage log; it is not delivered into a persistent sidebar Bot conversation (for example Chief). The `workflow-step` send middleware denies those replies after `stepResult` runs. Nodes start only when their forward predecessors finish and edges reach them. **Early termination (#1537, #1538):** When a node completes **or fails** with `needs-human`, `already-claimed`, `tip-unchanged`, or `open-pr` detected in its outputs or reply text (see `checkEarlyEnd` in Key files), the run ends immediately with status `done`, sets `run.earlyEnd` to the condition name, and does not advance to successors, take a success-path `loop`, or burn `onFail` recovery attempts. Preferred signals are a declared OUTPUT equal to the marker, or a whole reply line `EARLY-END <reason>`; the engine also honors common phrases (`tip unchanged` / `unchanged tip`, `has open PR` / `already has open PR` / `found open PR`, plus the existing already-claimed heuristics) so a Bot that forgets the structured marker cannot soft-lock Claim↔Verify on the same tip. Factory prompt guidance lives in `EARLY_END_GUIDANCE` (`plugins/workflow/src/template.js`) for Settings graphs that wire Triage / Claim / Verify: Verify must escalate once on an unchanged tip, not re-run the full suite. There is no scripted or seeded run path: `workflow/state` exposes only `live === true` runs. A run does not create a schedule. `scheduleLabel` is display text. When the host can create Bots, starting a live run (`assign`, `run_workflow`, `ingest`) spawns one ephemeral Bot per node from that node's prompt, role, model and tools, sends it the step from the Main Bot, and removes every instance when the run finishes, fails for good, or is reset. A `failOnce` retry keeps them. They are hidden and left out of the sidebar. Loading the plugin does not spawn Bots for the default workflows. Plugin unload (`dispose`) and the load-time `reap` both end a live run still marked `running`: in-flight nodes are failed, the run is archived as `failed`, and any ephemeral Bot ids are released. A run already written as `running` with no ephemeral map (an older unload) is healed the same way on the next load (#1414). Loading is also the one moment a run the host left behind is noticed when its ephemeral map is still present: `reap` releases those instances and records the run as `failed`. Nothing resumes it. A run that already ended keeps its own status (#1388). `workflow/reset` stopping one live run ends it the same way before its Bots are released: nodes still `running` become `failed`, so the strip cannot keep painting a run that is over (#1424). Every wait is bounded (#1530). A dispatch that does not land is not marked handed: the chat names the code and the attempt, and it is retried after a short backoff at most twice, never twice inside one hand-off, so a 429 is not hammered. When it still does not land, the step and the run fail with the reason written into the chat. Each running live step also holds a deadline — `STEP_DEADLINE_MS`, ten minutes, one constant in `service.js` (armed even when the host cannot spawn ephemeral Bots); when it expires the node and the run fail as `failed`, the run's ephemeral Bots are released, the chat says the step timed out, and `warn` names it once. The deadline is cleared as soon as the step moves, and by Pause, Stop, Reset, delete, `reap` and `dispose`; a paused run holds none, and Resume arms it again from that moment. A timer never outlives the run that started it. A reply that matches no running step — its run ended, or the node already moved — is reported through `warn` once per Bot and run instead of being dropped silently. A reply that says `could not answer your message` or `model call failed` fails that node and does not start its successor. A 429 or rate-limit mention in any other reply does not.
 4. Each workflow keeps a FIFO queue and up to `maxConcurrent` live runs (default 2, an integer from 1 to 8 on the record, via `workflow/concurrency`, or in Settings → Workflow graphs). A task that does not fit is enqueued. When a run finishes, every workflow with a free slot is drained, oldest enqueue first. A new assign on a workflow that already has a queue waits behind it. A task does not replace a running run or release that run's Bots. Migrating an old store keeps only runs that were still `running` with ephemeral Bot ids; other legacy scripted rows are dropped from active state (finished tasks may remain in lane history). History records a finished or failed live run. Lowering the cap does not stop a run that has already started. Assigning `{ botId }` claims the card for that local Bot and does not enqueue. A remote Bot is refused. `activeCount` is `runningOf(lane)` — live runs with `live === true` and `status === 'running'`. The stage aggregate chip and the Runs tab (运行记录) must agree: every such run appears as its own running row and progress card, and the chip count does not exceed that list.
 5. A node declares up to eight inputs and eight outputs. A required input is an output of the same name on an ancestor, or `task`, `title`, or `brief` on a root. A start with no provider is refused, and Bots spawned for that attempt are released. On a Bot-backed run a successor stays queued until its required inputs are present. If every forward predecessor is done, failed or skipped and an input is still missing, that node fails and the run stops. The dispatch text carries `Input <name>: <value>`. The Bot reports `OUTPUT <name>: <value>`; a single declared output may be the reply body. Nodes start in edge order.
 6. Each node is a real ephemeral Bot for that run, then it is removed. A permanent sidebar Bot (`botId`) is optional and is not required for the step to run. **File and shell rights are the same as a normal sidebar Bot's:** every node Bot gets the `danger-full-access` preset, and `EPHEMERAL_DENIED_TOOLS` still refuses the team-admin tools at the guard and approval layers (#1466, 29 names). **`node.tools` selects connectors only:** `spawn` passes the node's cleaned list to `fb.bot.create`, the host records it as `stepTools`, and `connector-access.js` allows `mcp__github__*` for `github` and `mcp__composio__*` for `composio` — a connector the node did not name is refused, and a node that names none reaches none. The list is also stored in `fields.tools` for the UI. A hidden run Bot cannot show an approval card, so the approval seam answers the same way the guard does. The host stores this on the run Bot as `stepTools` and `permission`.

plugins/workflow/src/graph.js

@@ -426,21 +426,44 @@
 
 // Check if a step result indicates the workflow should end early.
 // Returns { shouldEnd: true, reason: string } if the run should stop, or { shouldEnd: false } to continue.
+// Reasons: needs-human (#1538), already-claimed (#1537), tip-unchanged, open-pr.
+// Prefer structured OUTPUT values or a whole-line "EARLY-END <reason>" directive; also honor
+// common completion phrases so a Bot that forgets the marker still cannot burn loop/onFail max.
 function checkEarlyEnd(outputs, text) {
   const lowerText = String(text ?? '').toLowerCase()
-  const outputValues = Object.values(outputs ?? {}).map(v => String(v ?? '').toLowerCase())
-
-  // Check for needs-human marker (issue #1538)
-  if (lowerText.includes('needs-human') || outputValues.some(v => v.includes('needs-human'))) {
+  const outputValues = Object.values(outputs ?? {}).map(v => String(v ?? '').toLowerCase().trim())
+  const reasons = ['needs-human', 'already-claimed', 'tip-unchanged', 'open-pr']
+
+  for (const line of lowerText.split(/\r?\n/)) {
+    const match = line.trim().match(/^early-end\s+([a-z0-9_-]+)$/i)
+    if (match && reasons.includes(match[1].toLowerCase())) {
+      return { shouldEnd: true, reason: match[1].toLowerCase() }
+    }
+  }
+
+  for (const reason of reasons) {
+    if (outputValues.some(v => v === reason || v.includes(reason))) {
+      return { shouldEnd: true, reason }
+    }
+  }
+
+  if (lowerText.includes('needs-human')) {
     return { shouldEnd: true, reason: 'needs-human' }
   }
-
-  // Check for already-claimed marker (issue #1537)
+
   if (outputValues.some(v => v.includes('already-claimed')) ||
       (lowerText.includes('already claimed') && (lowerText.includes('agent-working') || lowerText.includes('claimed-by')))) {
     return { shouldEnd: true, reason: 'already-claimed' }
   }
-
+
+  if (/tip[\s_-]*unchanged|unchanged[\s_-]*tip/.test(lowerText)) {
+    return { shouldEnd: true, reason: 'tip-unchanged' }
+  }
+
+  if (/open\s+pr\s+already|already\s+has\s+(an\s+)?open\s+pr|has\s+(an\s+)?open\s+pr|found\s+(an\s+)?open\s+pr/.test(lowerText)) {
+    return { shouldEnd: true, reason: 'open-pr' }
+  }
+
   return { shouldEnd: false }
 }
 
@@ -530,7 +553,9 @@
   return fired
 }
 
-function loopDecision(graph, nodeId, outputs, loops) {
+function loopDecision(graph, nodeId, outputs, loops, text) {
+  // Do not take a success-path loop when the completion already signals stop.
+  if (checkEarlyEnd(outputs, text).shouldEnd) return null
   const edges = graph.edges.filter(edge => edge.loop === true && edge.from === nodeId)
   for (const edge of edges) {
     const ran = (Number(loops?.[edgeKey(edge)]) || 0) + 1
@@ -622,8 +647,8 @@
   const index = layerIndex(graph, nodeId)
   const layer = graph.layers[index]
   const outputs = ctx.outputs && typeof ctx.outputs === 'object' ? ctx.outputs : {}
   const loops = { ...(ctx.loops ?? {}) }
   const fired = { ...(ctx.fired ?? {}) }
 
   // Check if this completion should end the run early (#1537, #1538)
   const earlyEnd = checkEarlyEnd(outputs, ctx.text)
@@ -643,7 +668,7 @@
     }
   }
 
-  const looping = loopDecision(graph, nodeId, outputs, ctx.loops)
+  const looping = loopDecision(graph, nodeId, outputs, ctx.loops, ctx.text)
   if (looping) {
     loops[edgeKey(looping.edge)] = looping.ran
     const body = loopBody(graph, nodeId, looping.edge.to)
@@ -690,8 +715,26 @@
 export function failNode(graph, status, nodeId, ctx = {}) {
   if (!nodeById(graph, nodeId)) throw new Error(`Unknown Bot ${nodeId}`)
   if (status[nodeId] !== 'running') throw new Error(`${nodeId} is not running`)
-
+
+  // Tip-unchanged / open-PR / needs-human / already-claimed must not burn onFail max
+  // looping Claim↔Verify on the same tip. Early-end wins over recovery.
+  const earlyEnd = checkEarlyEnd(ctx.outputs ?? {}, ctx.text)
+  if (earlyEnd.shouldEnd) {
+    const next = copyStatus(status)
+    next[nodeId] = 'done'
+    return {
+      status: next,
+      started: [],
+      joined: false,
+      finished: true,
+      failAttempts: { ...(ctx.failAttempts ?? {}) },
+      recovered: false,
+      reset: [],
+      earlyEnd: earlyEnd.reason,
+    }
+  }
+
   const failAttempts = { ...(ctx.failAttempts ?? {}) }
   const recovery = failRecoveryDecision(graph, nodeId, failAttempts)
 
   if (recovery) {