host: every completed turn should carry its own outcome, not leave workflow steps parsing prose #2742

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: a0f18ef90d46450580e793b8977b4332
Branch: dev/1-turns-failure-marker
Base: 757ed34
At: 2026-11-09T06:52:23Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

The defect

A workflow step decides whether its turn succeeded by pattern-matching the prose of the reply. plugins/workflow/index.js:22-27 holds three legacy notice shapes, and index.js:30-41 (failureMarker()) prefers an explicit marker when one exists (msg.failure, msg.deliverArgs.failure, msg.ok) but falls back to text sniffing when none does. On the host side, only a real failure carries failure: true (core/src/host/turns.js:713/719, added by #2677); a stop notice (turns.js:728) and every ordinary reply carry no marker at all, so both go through the prose path.

Two consequences follow from one table:

1. A turn the host stopped before it answered is read as a successful step unless its prose happens to match a shape. #2741 patches this in the plugin by adding the stop-notice shape; that is a stopgap, because the next new sentence the host writes will be missed again.
2. A normal answer that merely contains one of the shapes is read as a failure unless it carries failure: false — which ordinary replies never carry.

The step's outcome should be carried by the protocol, not by the wording of the message.

Expected behaviour

• Every turn the host completes carries an explicit outcome: success replies failure: false, failed replies failure: true with their reason, and a turn stopped before it answered failure: true with the stop notice as the reason.
• With that in place, plugins/workflow classifies by the marker alone; the legacy prose shapes are then only a compatibility path for messages saved before this change, and a stop notice can never be read as an answer.

Scope

• core/src/host/turns.js: set failure: true plus the reason on the stop reply (:728), and failure: false on an ordinary completed reply. Keep the existing :713/719 behaviour.
• plugins/workflow/index.js: make failureMarker() authoritative when a marker is present (it already prefers it — verify no branch falls through), and keep the legacy shapes only for marker-less messages; do not widen them.
• Tests: a stop reply reads failed with its reason; an ordinary reply reads done even when it quotes a notice shape; a marker-less legacy message still classifies the way it does today (compatibility control).
• The narrow plugin fix lands separately in #2741; if #2741 merges first, this issue removes the need for its added shape rather than reverting it.

Duplicate check (run before writing this)

Closed-issue search for "step failure notice" / "stopped before it could answer" / "failure marker": #2677 and #2678 (both closed) fixed only the quoted-notice direction and left the marker-less stop notice alone; #2741 (open, ours) is the in-plugin stopgap. No issue covers giving every completed turn an explicit outcome.

Acceptance

• The three cases above on the PR's tip, with the marker-less control still green.
• core + plugins/workflow suites green, npm run verify exit 0, ds-bot-patches check and canonical green after regenerating carriers.
• Risk tier: T2/T3 by path — core/src/host/turns.js is a T2 path and plugins/** T2; the risk-gate comment on the PR is the authority, and the checkpoint must carry the tier it reports.