@edgehero/pi-dispatch-receiver 4.3.1 → 5.0.0

package/src/filter.mjs

@@ -46,7 +46,7 @@
  * user); `deliveryId` is the `X-GitHub-Delivery` GUID, carried into the job for downstream dedup.
  */
 import { findCloseRule } from "./close.mjs";
-import { escapeRegExp, firstMatchingRule, labelSet, matchedLabel, matchesRule } from "./predicate.mjs";
+import { escapeRegExp, firstMatchingRule, heldCandidateOr, labelSet, matchedLabel, matchesRule, steerModeOf } from "./predicate.mjs";
 import { hasParkedLabel } from "@edgehero/pi-dispatch/parked";
 
 const AUTHOR_ALLOWLIST = new Set(["OWNER", "MEMBER", "COLLABORATOR"]);
@@ -119,103 +119,128 @@ export function filter(eventName, subset, cfg, selfId, deliveryId, closerAuthori
 		return { enqueue: false, reason: "unhandled-event" };
 	}
 
-	if (!resolved.enqueue) return resolved; // carries the drop reason
+	// A drop is returned as it is, except a phrase-free reply that failed ONLY for the missing parked marker (issue #638,
+	// DES-AWAIT-INPUT-ENDS-THE-JOB): that one also carries `heldCandidate`, the job the parked-reply route would have
+	// built, through the SAME `build` below, so the receiver can hold it for a run that is parking right now and the job
+	// that run starts is byte for byte the one the marker would have produced. Still a drop: nothing here enqueues it.
+	if (!resolved.enqueue) return heldCandidateOr(resolved, build);
+	return build(resolved);
 
-	// (3) Build the job from the INT-WEBHOOK-PAYLOAD-SUBSET fields only. No sender.login (not in the
-	// subset), provider/model/maxTurns only when the matched rule named them (absent, the worker fills the
-	// deployment default, #502), no field outside the subset --
-	// with two trigger-context additions (issue #49): `matched` is harness-computed, the filter's own
-	// decision record naming the triggers.json entry that fired (not payload data at all); `comment`,
-	// present only on the comment route, carries the invoking comment's body/author_association, both
-	// fields INT-WEBHOOK-PAYLOAD-SUBSET already names.
-	//
-	// `packages` and `image` are harness-computed EXECUTION knobs read off the matched triggers.json entry
-	// (like `matched`), never payload data -- REQ-GLOBAL-PI-OVERLAY's per-trigger control over loading the
-	// operator-staged pi packages, and INT-TRIGGERS-FILE-CONTRACT's per-trigger container image. Both sit at
-	// JOB level, NOT inside `trigger`: `trigger` is the descriptive context object carried verbatim into
-	// /job/event.json (INT-CONTAINER-JOB-INPUTS) and must stay descriptive, so an execution switch has no
-	// business there. Both are omitted entirely when the matched rule did not set them, so an unflagged
-	// trigger's job literal is byte-identical to today's.
-	const job = {
-		repo: subset.repository?.full_name,
-		target: resolved.target,
-		// EXACTLY ONE of flow/command, decided by the matched rule (issue #189; the shared parser enforces
-		// the exclusivity at load). A command rule dispatches a registered pi extension command instead of
-		// resolving a flow, and its job must carry NO flow key at all -- a present-and-undefined flow would
-		// change the enqueued bytes for every consumer that serializes the job. The spread keeps a flow
-		// rule's literal byte-identical to what it always was.
-		...(resolved.command !== undefined ? { command: resolved.command } : { flow: resolved.flow }),
-		...(resolved.packages !== undefined ? { packages: resolved.packages } : {}),
-		...(resolved.image !== undefined ? { image: resolved.image } : {}),
-		// #227. A SEPARATE spread, and this is the whole of the bug it replaces: folded into the `image`
-		// conditional above, a trigger that named a venue but no image had its venue silently dropped here --
-		// it loaded, validated, reached this function on the rule, and then ran on the default. That is
-		// exactly the destructive absence `validateBackend`'s near-miss sweep refuses a misspelling for,
-		// arriving through the plumbing instead of the spelling, one file downstream of the guard.
-		...(resolved.backend !== undefined ? { backend: resolved.backend } : {}),
-		// #291. A separate spread, the backend line's rule one field over: folded into a neighbour's
-		// conditional, a trigger that named only exclusions would have them silently dropped here -- and a
-		// dropped exclusion runs the job WITH the tool, the destructive absence the loader's own sweep
-		// refuses a misspelling for, arriving through the plumbing instead of the spelling.
-		...(resolved.excludeTools !== undefined ? { excludeTools: resolved.excludeTools } : {}),
-		// REQ-MCP-OPERATOR-SERVERS. Its own spread, the excludeTools rule above: a dropped list runs
-		// the job without its servers.
-		...(resolved.mcp !== undefined ? { mcp: resolved.mcp } : {}),
-		// #502. One spread PER FIELD, the excludeTools rule above: folded into one conditional, a trigger
-		// that named only a model would have its provider's absence decide whether the model survives,
-		// and a dropped model runs the job on the deployment default while the file reads as chosen.
-		...(resolved.provider !== undefined ? { provider: resolved.provider } : {}),
-		...(resolved.model !== undefined ? { model: resolved.model } : {}),
-		...(resolved.maxTurns !== undefined ? { maxTurns: resolved.maxTurns } : {}),
-		...(resolved.models !== undefined ? { models: resolved.models } : {}),
-		// #501. Its own spread, the rule above: a dropped cap runs the job under the deployment's cap, or none,
-		// while the file reads as narrowed.
-		...(resolved.maxCostUsd !== undefined ? { maxCostUsd: resolved.maxCostUsd } : {}),
-		// The trigger's injected skills dir (REQ-PER-TRIGGER-SKILLS), at JOB level beside image/packages and
-		// NEVER inside `trigger`. That placement is sharpest here of all: `trigger` is carried into
-		// /job/event.json, and a worker-host path in an agent-readable file is the leak prepare-local's
-		// basename(folder) restraint already exists to prevent.
-		...(resolved.skillsDir !== undefined ? { skillsDir: resolved.skillsDir } : {}),
-		// REQ-TRIGGER-SECRETS. Conditional exactly like skillsDir above, so a trigger that binds no
-		// secret enqueues the job data it always has. The map holds REFERENCES, never values: the
-		// receiver has no resolver and reaches no vault -- the worker resolves them pre-spend.
-		...(resolved.secrets !== undefined ? { secrets: resolved.secrets } : {}),
-		...(resolved.secretsProfile !== undefined ? { secretsProfile: resolved.secretsProfile } : {}),
-		...(resolved.waitFor !== undefined ? { waitFor: resolved.waitFor } : {}),
-		...(resolved.instructions !== undefined ? { instructions: resolved.instructions } : {}),
-		// Conditional like packages/image, and for the same reason: an unflagged job's data must stay
-		// byte-identical to today's, so the key is absent rather than present-and-undefined.
-		...(resolved.resume !== undefined ? { resume: resolved.resume } : {}),
-		// REQ-AWAIT-INPUT (issue #625): whether the job may end awaiting a person's answer. Present only when armed,
-		// resume's rule, so an unflagged job's data stays byte-identical.
-		...(resolved.awaitInput === true ? { awaitInput: true } : {}),
-		// A phrase-free reply to a parked issue (issue #625): the worker gates it on the `parked` sidecar before any spend.
-		...(resolved.parkedReply === true ? { parkedReply: true } : {}),
-		// How many independent sandboxes race this flow (REQ-REPLICA-RUNS). At JOB level like the rest, never
-		// inside `trigger`, and for the sharpest version of that reason: this is the caller's fanout count --
-		// receiver.mjs reads it to decide how many times to enqueue -- and a descriptive context object copied
-		// into /job/event.json is no place for the number of jobs to create.
-		...(resolved.replicas !== undefined ? { replicas: resolved.replicas } : {}),
-		trigger: {
-			event: eventName,
-			action,
-			deliveryId,
-			sender: { id: subset.sender.id },
-			matched: resolved.matched,
-			...(resolved.comment ? { comment: resolved.comment } : {}),
-			// The invoking review, present only on the review route (issue #66), sibling of `comment` and
-			// carried for the same reason: without it a "Request changes: rename the helper" review starts a
-			// job that cannot know what was asked. All four fields are named by INT-WEBHOOK-PAYLOAD-SUBSET and
-			// the body stays DATA all the way down (CONST-ISSUE-TEXT-IS-DATA).
-			//
-			// NOTE the pair above: `event` is `pull_request_review` and `action` is the raw `submitted`,
-			// byte-for-byte what GitHub sent. `matched.action` is the canonical `review_submitted`, because
-			// `matched` names the triggers.json entry that fired rather than the payload. This is the first
-			// GitHub case where the two differ, and INT-CONTAINER-JOB-INPUTS says so.
-			...(resolved.review ? { review: resolved.review } : {}),
-		},
-	};
-	return { enqueue: true, job };
+	// The job from a resolved route. One function for every route and for the held candidate (issue #638), declared
+	// here so it closes over this delivery's subset and ids.
+	function build(resolved) {
+		// (3) Build the job from the INT-WEBHOOK-PAYLOAD-SUBSET fields only. No sender.login (not in the
+		// subset), provider/model/maxTurns only when the matched rule named them (absent, the worker fills the
+		// deployment default, #502), no field outside the subset --
+		// with two trigger-context additions (issue #49): `matched` is harness-computed, the filter's own
+		// decision record naming the triggers.json entry that fired (not payload data at all); `comment`,
+		// present only on the comment route, carries the invoking comment's body/author_association, both
+		// fields INT-WEBHOOK-PAYLOAD-SUBSET already names.
+		//
+		// `packages` and `image` are harness-computed EXECUTION knobs read off the matched triggers.json entry
+		// (like `matched`), never payload data -- REQ-GLOBAL-PI-OVERLAY's per-trigger control over loading the
+		// operator-staged pi packages, and INT-TRIGGERS-FILE-CONTRACT's per-trigger container image. Both sit at
+		// JOB level, NOT inside `trigger`: `trigger` is the descriptive context object carried verbatim into
+		// /job/event.json (INT-CONTAINER-JOB-INPUTS) and must stay descriptive, so an execution switch has no
+		// business there. Both are omitted entirely when the matched rule did not set them, so an unflagged
+		// trigger's job literal is byte-identical to today's.
+		const job = {
+			repo: subset.repository?.full_name,
+			target: resolved.target,
+			// EXACTLY ONE of flow/command, decided by the matched rule (issue #189; the shared parser enforces
+			// the exclusivity at load). A command rule dispatches a registered pi extension command instead of
+			// resolving a flow, and its job must carry NO flow key at all -- a present-and-undefined flow would
+			// change the enqueued bytes for every consumer that serializes the job. The spread keeps a flow
+			// rule's literal byte-identical to what it always was.
+			...(resolved.command !== undefined ? { command: resolved.command } : { flow: resolved.flow }),
+			...(resolved.packages !== undefined ? { packages: resolved.packages } : {}),
+			...(resolved.image !== undefined ? { image: resolved.image } : {}),
+			// #227. A SEPARATE spread, and this is the whole of the bug it replaces: folded into the `image`
+			// conditional above, a trigger that named a venue but no image had its venue silently dropped here --
+			// it loaded, validated, reached this function on the rule, and then ran on the default. That is
+			// exactly the destructive absence `validateBackend`'s near-miss sweep refuses a misspelling for,
+			// arriving through the plumbing instead of the spelling, one file downstream of the guard.
+			...(resolved.backend !== undefined ? { backend: resolved.backend } : {}),
+			// #291. A separate spread, the backend line's rule one field over: folded into a neighbour's
+			// conditional, a trigger that named only exclusions would have them silently dropped here -- and a
+			// dropped exclusion runs the job WITH the tool, the destructive absence the loader's own sweep
+			// refuses a misspelling for, arriving through the plumbing instead of the spelling.
+			...(resolved.excludeTools !== undefined ? { excludeTools: resolved.excludeTools } : {}),
+			// Issue #800, each its own spread by the same rule: a dropped list runs the job with what the file takes away.
+			...(resolved.excludeExtensions !== undefined ? { excludeExtensions: resolved.excludeExtensions } : {}),
+			...(resolved.excludeExtensionTools !== undefined ? { excludeExtensionTools: resolved.excludeExtensionTools } : {}),
+			// REQ-MCP-OPERATOR-SERVERS. Its own spread, the excludeTools rule above: a dropped list runs
+			// the job without its servers.
+			...(resolved.mcp !== undefined ? { mcp: resolved.mcp } : {}),
+			// #502. One spread PER FIELD, the excludeTools rule above: folded into one conditional, a trigger
+			// that named only a model would have its provider's absence decide whether the model survives,
+			// and a dropped model runs the job on the deployment default while the file reads as chosen.
+			...(resolved.provider !== undefined ? { provider: resolved.provider } : {}),
+			...(resolved.model !== undefined ? { model: resolved.model } : {}),
+			...(resolved.maxTurns !== undefined ? { maxTurns: resolved.maxTurns } : {}),
+			...(resolved.models !== undefined ? { models: resolved.models } : {}), ...(resolved.fallbackModels !== undefined ? { fallbackModels: resolved.fallbackModels } : {}),
+			// #501. Its own spread, the rule above: a dropped cap runs the job under the deployment's cap, or none,
+			// while the file reads as narrowed.
+			...(resolved.maxCostUsd !== undefined ? { maxCostUsd: resolved.maxCostUsd } : {}),
+			// The trigger's injected skills dir (REQ-PER-TRIGGER-SKILLS), at JOB level beside image/packages and
+			// NEVER inside `trigger`. That placement is sharpest here of all: `trigger` is carried into
+			// /job/event.json, and a worker-host path in an agent-readable file is the leak prepare-local's
+			// basename(folder) restraint already exists to prevent.
+			...(resolved.skillsDir !== undefined ? { skillsDir: resolved.skillsDir } : {}),
+			// REQ-TRIGGER-SECRETS. Conditional exactly like skillsDir above, so a trigger that binds no
+			// secret enqueues the job data it always has. The map holds REFERENCES, never values: the
+			// receiver has no resolver and reaches no vault -- the worker resolves them pre-spend.
+			...(resolved.secrets !== undefined ? { secrets: resolved.secrets } : {}),
+			...(resolved.secretsProfile !== undefined ? { secretsProfile: resolved.secretsProfile } : {}),
+			...(resolved.waitFor !== undefined ? { waitFor: resolved.waitFor } : {}),
+			...(resolved.instructions !== undefined ? { instructions: resolved.instructions } : {}),
+			// Conditional like packages/image, and for the same reason: an unflagged job's data must stay
+			// byte-identical to today's, so the key is absent rather than present-and-undefined.
+			...(resolved.resume !== undefined ? { resume: resolved.resume } : {}),
+			// REQ-AWAIT-INPUT (issue #625): whether the job may end awaiting a person's answer. Present only when armed,
+			// resume's rule, so an unflagged job's data stays byte-identical.
+			...(resolved.awaitInput === true ? { awaitInput: true } : {}),
+			...(resolved.gates !== undefined ? { gates: resolved.gates, ...(resolved.gateTimeout !== undefined ? { gateTimeout: resolved.gateTimeout } : {}), ...(resolved.gateBudgetRaiseUsd !== undefined ? { gateBudgetRaiseUsd: resolved.gateBudgetRaiseUsd } : {}) } : {}),
+			// Issue #644: the progress tool and the forge status comment, each present only when armed, awaitInput's rule.
+			...(resolved.progress === true ? { progress: true } : {}),
+			...(resolved.statusComment === true ? { statusComment: true } : {}),
+			// Issue #645: durable runs, present only when armed, the same rule.
+			...(resolved.recover === true ? { recover: true } : {}),
+			// Issue #646: steering a running job, present only when armed, the same rule.
+			...(resolved.steer === true ? { steer: true } : {}),
+			// Issue #646: how this phrase comment steers a job of its trigger that is already running, set only on the comment
+			// route of a steer-armed trigger (never a parked reply, never a command). The receiver reads it to try the run's
+			// inbox before it enqueues, and `enqueueForgeJob` names its fields, so it never reaches a queue. At JOB level, never
+			// inside `trigger`, which is copied verbatim into /job/event.json.
+			...(resolved.steerMode !== undefined ? { steerMode: resolved.steerMode } : {}),
+			// A phrase-free reply to a parked issue (issue #625): the worker gates it on the `parked` sidecar before any spend.
+			...(resolved.parkedReply === true ? { parkedReply: true } : {}),
+			// How many independent sandboxes race this flow (REQ-REPLICA-RUNS). At JOB level like the rest, never
+			// inside `trigger`, and for the sharpest version of that reason: this is the caller's fanout count --
+			// receiver.mjs reads it to decide how many times to enqueue -- and a descriptive context object copied
+			// into /job/event.json is no place for the number of jobs to create.
+			...(resolved.replicas !== undefined ? { replicas: resolved.replicas } : {}),
+			trigger: {
+				event: eventName,
+				action,
+				deliveryId,
+				sender: { id: subset.sender.id },
+				matched: resolved.matched,
+				...(resolved.comment ? { comment: resolved.comment } : {}),
+				// The invoking review, present only on the review route (issue #66), sibling of `comment` and
+				// carried for the same reason: without it a "Request changes: rename the helper" review starts a
+				// job that cannot know what was asked. All four fields are named by INT-WEBHOOK-PAYLOAD-SUBSET and
+				// the body stays DATA all the way down (CONST-ISSUE-TEXT-IS-DATA).
+				//
+				// NOTE the pair above: `event` is `pull_request_review` and `action` is the raw `submitted`,
+				// byte-for-byte what GitHub sent. `matched.action` is the canonical `review_submitted`, because
+				// `matched` names the triggers.json entry that fired rather than the payload. This is the first
+				// GitHub case where the two differ, and INT-CONTAINER-JOB-INPUTS says so.
+				...(resolved.review ? { review: resolved.review } : {}),
+			},
+		};
+		return { enqueue: true, job };
+	}
 }
 
 /** Issue label path: the label allowlist IS the human approval gate -- only collaborators can label. */
@@ -230,15 +255,19 @@ function routeIssueLabel(subset, triggers) {
 		// A command rule (issue #189) skips flow resolution entirely: the label match IS the dispatch.
 		...(rule.command !== undefined ? { command: rule.command } : { flow: rule.flow }),
 		packages: rule.packages, // the MATCHED rule's fields -- rules in one file may differ on them
-		image: rule.image, backend: rule.backend, excludeTools: rule.excludeTools, mcp: rule.mcp,
-		provider: rule.provider, model: rule.model, maxTurns: rule.maxTurns, models: rule.models, maxCostUsd: rule.maxCostUsd,
+		image: rule.image, backend: rule.backend, excludeTools: rule.excludeTools, excludeExtensions: rule.excludeExtensions, excludeExtensionTools: rule.excludeExtensionTools, mcp: rule.mcp,
+		provider: rule.provider, model: rule.model, maxTurns: rule.maxTurns, models: rule.models, fallbackModels: rule.fallbackModels, maxCostUsd: rule.maxCostUsd,
 		skillsDir: rule.skillsDir,
 		secrets: rule.secrets,
 		secretsProfile: rule.secretsProfile,
 		waitFor: rule.waitFor,
 		instructions: rule.instructions,
 		resume: rule.resume,
-		awaitInput: rule.awaitInput,
+		awaitInput: rule.awaitInput, gates: rule.gates, gateTimeout: rule.gateTimeout, gateBudgetRaiseUsd: rule.gateBudgetRaiseUsd,
+		progress: rule.progress,
+		statusComment: rule.statusComment,
+		recover: rule.recover,
+		steer: rule.steer,
 		replicas: rule.replicas,
 		matched: { index: rule.index, type: "label", label: matchedLabel(L, rule.predicate) },
 		target: { type: "issue", number: subset.issue?.number, title: subset.issue?.title, body: subset.issue?.body },
@@ -251,7 +280,7 @@ function routeIssueLabel(subset, triggers) {
  * `knownFlows` is passed separately because it is NOT a per-forge rule -- it is the whole file's flow
  * vocabulary, and it bounds which names a comment may summon rather than which rules may match.
  */
-function routeComment(subset, triggers, knownFlows) {
+function routeComment(subset, triggers, knownFlows, assumeParked = false) {
 	if (!AUTHOR_ALLOWLIST.has(subset.comment?.author_association)) {
 		return { enqueue: false, reason: "author-not-allowed" };
 	}
@@ -263,8 +292,17 @@ function routeComment(subset, triggers, knownFlows) {
 	// trigger arms run.resume and is not a command, and only when the forge says the issue carries the marker. The
 	// author gate above already ran: this widens WHICH comments start a job, never WHO may. The marker is a hint; the
 	// worker refuses the job before any spend unless the key's `parked` sidecar exists.
-	const parkedReply = !phraseHit && typeof phrase === "string" && typeof body === "string" && triggers.comment?.resume === true && triggers.comment?.command === undefined && subset.issue?.pull_request !== true && hasParkedLabel(subset.issue?.labels);
+	const parkedCandidate = !phraseHit && typeof phrase === "string" && typeof body === "string" && triggers.comment?.resume === true && triggers.comment?.command === undefined && subset.issue?.pull_request !== true;
+	const parkedReply = parkedCandidate && (assumeParked || hasParkedLabel(subset.issue?.labels));
 	if (!phraseHit && !parkedReply) {
+		// Issue #638: a reply that fails ONLY for the missing marker (the run asked its question and is still parking, so
+		// the label is not on yet) is still a drop, but it carries the route the marker would have taken, built by this
+		// same function with the marker assumed (so every other rule above still decided it). The receiver holds it for a
+		// run that is parking on this target, or drops it exactly as today.
+		if (parkedCandidate) {
+			const held = routeComment(subset, triggers, knownFlows, true);
+			if (held.enqueue) return { enqueue: false, reason: "no-trigger-phrase", heldResolved: held };
+		}
 		return { enqueue: false, reason: "no-trigger-phrase" };
 	}
 	// On a COMMAND rule (issue #189) the whole flow-resolution block below -- default flow, the `<phrase>
@@ -299,18 +337,27 @@ function routeComment(subset, triggers, knownFlows) {
 		// The single comment trigger IS the matched rule here, so its opt-in is the job's. A `<phrase>
 		// <flow>` override changes WHICH flow runs, never which triggers.json entry authorized it.
 		packages: triggers.comment.packages,
-		image: triggers.comment.image, backend: triggers.comment.backend, excludeTools: triggers.comment.excludeTools, mcp: triggers.comment.mcp,
-		provider: triggers.comment.provider, model: triggers.comment.model, maxTurns: triggers.comment.maxTurns, models: triggers.comment.models, maxCostUsd: triggers.comment.maxCostUsd,
+		image: triggers.comment.image, backend: triggers.comment.backend, excludeTools: triggers.comment.excludeTools, excludeExtensions: triggers.comment.excludeExtensions, excludeExtensionTools: triggers.comment.excludeExtensionTools, mcp: triggers.comment.mcp,
+		provider: triggers.comment.provider, model: triggers.comment.model, maxTurns: triggers.comment.maxTurns, models: triggers.comment.models, fallbackModels: triggers.comment.fallbackModels, maxCostUsd: triggers.comment.maxCostUsd,
 		skillsDir: triggers.comment.skillsDir,
 		secrets: triggers.comment.secrets,
 		secretsProfile: triggers.comment.secretsProfile,
 		waitFor: triggers.comment.waitFor,
 		instructions: triggers.comment.instructions,
 		resume: triggers.comment.resume,
-		awaitInput: triggers.comment.awaitInput,
+		awaitInput: triggers.comment.awaitInput, gates: triggers.comment.gates, gateTimeout: triggers.comment.gateTimeout, gateBudgetRaiseUsd: triggers.comment.gateBudgetRaiseUsd,
+		progress: triggers.comment.progress,
+		statusComment: triggers.comment.statusComment,
+		recover: triggers.comment.recover,
+		steer: triggers.comment.steer,
 		replicas: triggers.comment.replicas,
 		matched: { index: triggers.comment.index, type: "comment", phrase },
 		...(parkedReply && { parkedReply: true }),
+		// Issue #646: a phrase comment on a steer-armed trigger may steer a run of it that is already going. Only with the
+		// phrase (a parked reply is an answer to a parked run, never a steer) and never on a command rule (the loader refuses
+		// `steer` beside `command`; checked again here so a drifted file cannot reach a run). The author gate above already
+		// ran: this changes where an admitted comment goes, never who may send one. The `later` grammar is `steerModeOf`'s.
+		...(phraseHit && command === undefined && triggers.comment.steer === true && { steerMode: steerModeOf(body, phrase) }),
 		// The invoking comment rides on the trigger: body and author_association are both named by
 		// INT-WEBHOOK-PAYLOAD-SUBSET, and the body stays DATA all the way down (CONST-ISSUE-TEXT-IS-DATA).
 		comment: { body: subset.comment.body, author_association: subset.comment.author_association },
@@ -400,15 +447,19 @@ function routePullRequest(subset, triggers, action) {
 			// A command rule (issue #189) skips flow resolution entirely: the rule match IS the dispatch.
 			...(rule.command !== undefined ? { command: rule.command } : { flow: rule.flow }),
 			packages: rule.packages, // the MATCHED rule's fields -- rules in one file may differ on them
-			image: rule.image, backend: rule.backend, excludeTools: rule.excludeTools, mcp: rule.mcp,
-			provider: rule.provider, model: rule.model, maxTurns: rule.maxTurns, models: rule.models, maxCostUsd: rule.maxCostUsd,
+			image: rule.image, backend: rule.backend, excludeTools: rule.excludeTools, excludeExtensions: rule.excludeExtensions, excludeExtensionTools: rule.excludeExtensionTools, mcp: rule.mcp,
+			provider: rule.provider, model: rule.model, maxTurns: rule.maxTurns, models: rule.models, fallbackModels: rule.fallbackModels, maxCostUsd: rule.maxCostUsd,
 			skillsDir: rule.skillsDir,
 			secrets: rule.secrets,
 			secretsProfile: rule.secretsProfile,
 			waitFor: rule.waitFor,
 			instructions: rule.instructions,
 			resume: rule.resume,
-			awaitInput: rule.awaitInput,
+			awaitInput: rule.awaitInput, gates: rule.gates, gateTimeout: rule.gateTimeout, gateBudgetRaiseUsd: rule.gateBudgetRaiseUsd,
+			progress: rule.progress,
+			statusComment: rule.statusComment,
+			recover: rule.recover,
+			steer: rule.steer,
 			replicas: rule.replicas,
 			matched: { index: rule.index, type: "pull_request", action },
 			...(isReview ? { review: { id: review.id, body: review.body, state: review.state, author_association: review.author_association } } : {}),
@@ -518,15 +569,19 @@ function routeClose(rules, number, closerAuthorized, matchedFor, targetFor) {
 		// A command rule (issue #189) skips flow resolution entirely: the rule match IS the dispatch.
 		...(rule.command !== undefined ? { command: rule.command } : { flow: rule.flow }),
 		packages: rule.packages, // the MATCHED rule's fields -- rules in one file may differ on them
-		image: rule.image, backend: rule.backend, excludeTools: rule.excludeTools, mcp: rule.mcp,
-		provider: rule.provider, model: rule.model, maxTurns: rule.maxTurns, models: rule.models, maxCostUsd: rule.maxCostUsd,
+		image: rule.image, backend: rule.backend, excludeTools: rule.excludeTools, excludeExtensions: rule.excludeExtensions, excludeExtensionTools: rule.excludeExtensionTools, mcp: rule.mcp,
+		provider: rule.provider, model: rule.model, maxTurns: rule.maxTurns, models: rule.models, fallbackModels: rule.fallbackModels, maxCostUsd: rule.maxCostUsd,
 		skillsDir: rule.skillsDir,
 		secrets: rule.secrets,
 		secretsProfile: rule.secretsProfile,
 		waitFor: rule.waitFor,
 		instructions: rule.instructions,
 		resume: rule.resume,
-		awaitInput: rule.awaitInput,
+		awaitInput: rule.awaitInput, gates: rule.gates, gateTimeout: rule.gateTimeout, gateBudgetRaiseUsd: rule.gateBudgetRaiseUsd,
+		progress: rule.progress,
+		statusComment: rule.statusComment,
+		recover: rule.recover,
+		steer: rule.steer,
 		replicas: rule.replicas,
 		matched: matchedFor(rule),
 		target: targetFor(),
@@ -553,8 +608,8 @@ export function wantsCloserAuthority(eventName, subset, group, selfId) {
 	// Filter's own step-0/1 guards, replicated FIRST and in the same order (fail-closed identity, then
 	// the unconditional bot-loop guard): the harness closing its own issue -- the natural last act of
 	// the very flow a close trigger arms -- must not cost a lookup, and an INDETERMINATE lookup on a
-	// self-delivery would 503 (so: redeliver, retry, loop) traffic the filter would only ever drop as
-	// `self`.
+	// self-delivery would answer 503 (a failed delivery in the hook's history and a `lookup-failed` count on the
+	// Connections page) for traffic the filter would only ever drop as `self`.
 	if (typeof subset?.sender?.id !== "number") return false;
 	if (subset.sender.id === selfId) return false;
 	if (eventName === "issues" && subset.action === CLOSE_ACTION) {

package/src/forgejo-members.mjs

@@ -19,7 +19,8 @@
  *   - it runs AFTER verification, so an unauthenticated flood cannot make this project call Forgejo;
  *   - it returns a two-armed verdict, because "not a collaborator" and "could not tell" are different
  *     answers. A 404 is determinate and refuses; anything else is INDETERMINATE and the receiver answers
- *     503, so Forgejo redelivers and the stable `X-GitHub-Delivery` GUID dedups the retry. Collapsing
+ *     503. Forgejo never resends that on its own, and its replay is a new delivery id (receiver.mjs, WHAT A
+ *     503 MEANS), so a person replays what still needs to run. Collapsing
  *     indeterminate to "deny" would drop real work during an outage behind a 204 that looks exactly like a
  *     stranger being correctly refused.
  *
@@ -91,8 +92,8 @@ export function makeResolveForgejoAuthority({ apiUrl, token, tokenVar = "FORGEJO
 			// collaborators can query only their own"}; the same account raised to repo admin gets 200). The
 			// other 403s this route can give are the token's scope (`token does not have at least one of
 			// required scope(s)`, `token scope is limited to public repos`), so the dedicated token's reason names its scope too.
-			// Still indeterminate, and that is a decision, not an oversight. A retry cannot heal it, but the
-			// retry costs nothing (no token is minted and nothing spends before this answer), while the
+			// Still indeterminate, and that is a decision, not an oversight. A replay cannot heal it, but the
+			// replay costs nothing (no token is minted and nothing spends before this answer), while the
 			// alternative is worse in the way this file's header names: a determinate refusal answers 204, which
 			// Forgejo records as a successful delivery, so the one place the operator looks would show every
 			// trigger "delivered" while nothing ran. A 503 marks each delivery failed there, the log line below

package/src/github-members.mjs

@@ -20,7 +20,8 @@
  *     payload-only and lookup-free, and an unauthenticated flood cannot make this project call GitHub;
  *   - it returns a two-armed verdict, because "not a collaborator" and "could not tell" are different
  *     answers. A 404 is determinate and refuses; anything unrecognised is INDETERMINATE and the receiver
- *     answers 503, so GitHub redelivers and the stable `X-GitHub-Delivery` GUID dedups the retry.
+ *     answers 503. GitHub never resends that on its own (receiver.mjs, WHAT A 503 MEANS): a redelivery by
+ *     hand within 3 days keeps the `X-GitHub-Delivery` GUID, so it queues at most once.
  *     Collapsing indeterminate to "deny" would drop real work during an outage behind a 204 that looks
  *     exactly like a stranger being correctly refused.
  *

package/src/gitlab-members.mjs

@@ -13,7 +13,8 @@
  *     API calls on an attacker's behalf.
  *   - It distinguishes "not a member" from "could not tell", and those are different answers. A 404 is
  *     determinate and yields `authorized: false`, which the gate refuses. Anything else -- a 5xx, a dead
- *     socket, a revoked token -- is INDETERMINATE, and the receiver answers 503 so GitLab redelivers.
+ *     socket, a revoked token -- is INDETERMINATE, and the receiver answers 503. GitLab never resends that on
+ *     its own (receiver.mjs, WHAT A 503 MEANS); a "Resend Request" keeps the id, so it queues at most once.
  *     Collapsing indeterminate to "deny" would silently drop legitimate work during an outage, with a 204
  *     that reads exactly like a correctly-refused stranger.
  *

package/src/held.mjs

@@ -0,0 +1,120 @@
+/**
+ * Held replies, the receiver's side (issue #638, DES-AWAIT-INPUT-ENDS-THE-JOB; keys and scripts in the worker's
+ * held-replies.mjs): an answer to a run that is parking right now is held for that run's settle instead of being lost.
+ *
+ * TWO WAYS A REPLY USED TO BE LOST, two entry points here, both shared by the four webhook arms and the poller so no
+ * forge can weaken one alone (the four-copies doctrine of receiver.mjs):
+ *   (a) `holdAfterDedup`: a resume comment for an awaitInput trigger that the semantic window deduplicated against a
+ *       run still going (the parked run finishing, or a resumed run). Held under the SURVIVING job's id, which is the
+ *       run id the worker registered: the window is keyed per target and flow, so the survivor is that run.
+ *   (b) `holdBeforeLabel`: a phrase-free reply on an issue that the filter dropped ONLY because the parked marker was
+ *       not set yet (the filter's `heldCandidate`). Held under every awaitInput run live on the target.
+ * A run is live only while its worker's keeper refreshes it (held-settle.mjs), and the hold script refuses once the run
+ * has settled, so `ok` or `dup` means the run's settle will see the reply; anything else (no live run, `gone`,
+ * `closed`, `full`, a refusal, a Valkey fault) returns null and the caller answers EXACTLY as it did before this
+ * feature: a hold is a rescue for a reply that was going to be lost, never a way to lose one that was not.
+ *
+ * WHAT THE HELD REPLY BECOMES is the worker's call at the run's final outcome: the first one started as a resumed job if
+ * the run parked, dropped (today's coalescing) if it did not. The fallback stored is `fallbackJobOf`, the object the
+ * late steer stores, so "the job this comment would have been" has one spelling.
+ *
+ * Not the steer inbox, deliberately, and never consulted by `trySteer`: see held-replies.mjs for why the keys are apart.
+ * Logs carry the delivery, the kind, the target in the arm's grammar and run ids, never the comment. Never throws.
+ */
+
+import { awaitTargetKeyOf, holdReply, liveAwaitRunsForTarget, recentlyParked } from "@edgehero/pi-dispatch/held-replies";
+import { forgeMessageId } from "@edgehero/pi-dispatch/steer-inbox";
+import { fallbackJobOf } from "./steer.mjs";
+
+/** At most this many live awaitInput runs of one target take a pre-label reply: the steer fanout's bound. */
+export const HELD_FANOUT_LIMIT = 4;
+
+const nowOf = (now) => (typeof now === "function" ? now() : now);
+
+/**
+ * Whether a fanout outcome may hold anything: a COMMENT-matched job armed with both `run.resume` (it continues the
+ * parked session) and `run.awaitInput` (the trigger whose runs park), at least one replica of which the window
+ * swallowed. Free, so the caller asks it before it asks for a Valkey client.
+ */
+export function wantsHoldAfterDedup(job, outcome) {
+	return job?.trigger?.matched?.type === "comment" && job.resume === true && job.awaitInput === true && Array.isArray(outcome?.deduplicated) && outcome.deduplicated.length > 0;
+}
+
+async function holdUnder({ redis, runIds, job, kind, route, now, log, delivery, target }) {
+	const id = forgeMessageId(job?.trigger?.deliveryId);
+	if (id === null) {
+		log({ event: "held_fell_through", delivery, kind, route, reason: "no-delivery-id" });
+		return null;
+	}
+	const entry = { id, at: nowOf(now), route, fallback: fallbackJobOf(job, kind) };
+	const held = [];
+	const outcomes = {};
+	for (const runId of runIds) {
+		const r = await holdReply({ redis, runId, entry, now });
+		const outcome = typeof r === "string" ? r : (r?.error ?? "error");
+		outcomes[outcome] = (outcomes[outcome] ?? 0) + 1;
+		if (r === "ok" || r === "dup") {
+			held.push(runId);
+			log({ event: "held", delivery, repo: job.repo, target, route, runId });
+		}
+	}
+	if (held.length > 0) return { held: held.length, runIds: held };
+	log({ event: "held_fell_through", delivery, kind, route, reason: Object.keys(outcomes).length === 1 ? Object.keys(outcomes)[0] : "mixed", outcomes });
+	return null;
+}
+
+/**
+ * (a) `{ held, runIds }` when at least one surviving run took the reply, else null. `outcome` is `fanout`'s, `job` the
+ * job that was enqueued (no `steerMode`), `target` the arm's own grammar for the log.
+ */
+export async function holdAfterDedup({ redis, job, kind, outcome, now = Date.now, log = () => {}, delivery, target } = {}) {
+	try {
+		if (!wantsHoldAfterDedup(job, outcome)) return null;
+		if (!redis) {
+			log({ event: "held_fell_through", delivery, kind, route: "dedup", reason: "no-client" });
+			return null;
+		}
+		const runIds = [...new Set(outcome.deduplicated.map((d) => d?.survivingJobId).filter((r) => typeof r === "string" && r !== ""))];
+		if (runIds.length === 0) return null;
+		return await holdUnder({ redis, runIds, job, kind, route: "dedup", now, log, delivery, target });
+	} catch {
+		return null;
+	}
+}
+
+/**
+ * (b) `{ held, runIds }` when at least one live awaitInput run on the candidate's target took the reply; `{ enqueue:
+ * true }` when none did but a run PARKED on the target within the last minute (its take raised the parked marker,
+ * held-replies.mjs): the reply was posted before the label and delivered after the take, and is enqueued as the ordinary
+ * parked reply it would have been a moment later (it coalesces against the taken job, or resumes the parked session),
+ * never dropped for the label it raced (review round 2); else null. `candidate` is the filter's `heldCandidate` (the
+ * parked-reply job, `parkedReply: true`).
+ */
+export async function holdBeforeLabel({ redis, candidate, kind, now = Date.now, log = () => {}, delivery, target } = {}) {
+	try {
+		if (!candidate || typeof candidate !== "object" || candidate.parkedReply !== true) return null;
+		const targetKey = awaitTargetKeyOf({ ...candidate, kind });
+		if (targetKey === null) return null;
+		if (!redis) {
+			log({ event: "held_fell_through", delivery, kind, route: "pre-label", reason: "no-client" });
+			return null;
+		}
+		const runs = await liveAwaitRunsForTarget({ redis, targetKey, now, limit: HELD_FANOUT_LIMIT });
+		if (!Array.isArray(runs)) {
+			log({ event: "held_fell_through", delivery, kind, route: "pre-label", reason: runs?.error ?? "error" });
+			return null;
+		}
+		const held = runs.length > 0 ? await holdUnder({ redis, runIds: runs, job: candidate, kind, route: "pre-label", now, log, delivery, target }) : null;
+		if (held !== null) return held;
+		const parked = await recentlyParked({ redis, targetKey });
+		if (parked === true) {
+			log({ event: "held_after_park", delivery, kind, repo: candidate.repo, target });
+			return { enqueue: true };
+		}
+		// No live run and no park is the ordinary case (a phrase-free comment on an issue nothing is parking on), so it
+		// logs nothing: the caller's `dropped` line is exactly today's.
+		return null;
+	} catch {
+		return null;
+	}
+}