@edgehero/pi-dispatch-receiver 4.3.0 → 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

@@ -4,9 +4,12 @@
  *
  * Forgejo has no `author_association`; the concept is GitHub's. What it has instead is
  * `GET /repos/{owner}/{repo}/collaborators/{collaborator}/permission`, which answers
- * `{ permission: "admin"|"write"|"read"|"none" }`. `admin` and `write` are the honest analogue of
- * `OWNER|MEMBER|COLLABORATOR`: they are exactly the levels that can push a branch, which is the property
- * the constitution actually requires.
+ * `{ permission: "owner"|"admin"|"write"|"read"|"none" }`. `owner`, `admin` and `write` are the honest
+ * analogue of `OWNER|MEMBER|COLLABORATOR`: they are exactly the levels that can push a branch, which is the
+ * property the constitution actually requires. `owner` is not hypothetical and not rare: measured on
+ * Forgejo 14.0.5, the owner of a personal repository asking about themselves gets
+ * `{"permission":"owner","role_name":"owner",...}`, and a set without it dropped every trigger they set
+ * as `author-not-allowed`.
  *
  * The shape of this module is the GitLab resolver's, for the same three reasons, and they are worth
  * restating rather than cross-referencing:
@@ -16,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.
  *
@@ -31,18 +35,31 @@ const API_PREFIX = "/api/v1";
 /**
  * The permission levels that can push to the repository. `read` and `none` cannot, so a job started on
  * their say-so would be doing work the actor could not do themselves -- the line CONST-TRIGGER-AUTHOR-GATE
- * draws.
+ * draws. These are the strings of Forgejo's access modes (none, read, write, admin, owner); `owner` is what
+ * a personal repository's owner is answered with (measured, see the header).
  */
-const WRITE_PERMISSIONS = new Set(["admin", "write"]);
+const WRITE_PERMISSIONS = new Set(["owner", "admin", "write"]);
 
 /**
- * Build the resolver. `token` is the same operator-supplied access token the worker uses; `fetchFn` is
- * injected so the whole module is testable offline.
+ * What a 403 tells the operator to fix, by which variable's token asked. Fixed strings, never the body.
+ * With the dedicated lookup token, its account is the one that must be an admin. With the fallback, the right repair
+ * is NOT to make the job's account an admin (that hands every job a token able to lift branch protection, OQ-043) but
+ * to give the lookup its own token.
+ */
+const FORBIDDEN_REASON = Object.freeze({
+	FORGEJO_PERMISSION_TOKEN: "collaborator permission lookup returned 403 (the account behind FORGEJO_PERMISSION_TOKEN must be an admin or the owner of the repository, and the token must carry read:repository)",
+	FORGEJO_TOKEN: "collaborator permission lookup returned 403 (FORGEJO_TOKEN's account is not an admin of the repository: set FORGEJO_PERMISSION_TOKEN to a read:repository token of an account that is, docs/forgejo.md)",
+});
+
+/**
+ * Build the resolver. `token` is the lookup token (FORGEJO_PERMISSION_TOKEN, or FORGEJO_TOKEN as the fallback) and
+ * `tokenVar` names which, for a 403's reason; `fetchFn` is injected so the whole module is testable offline.
  *
  * Returns `resolveAuthority(repoFullName, login)` -> `{ authorized: boolean }` | `{ indeterminate: string }`
  * -- the same shape every forge's resolver returns.
  */
-export function makeResolveForgejoAuthority({ apiUrl, token, fetchFn = fetch }) {
+export function makeResolveForgejoAuthority({ apiUrl, token, tokenVar = "FORGEJO_TOKEN", fetchFn = fetch }) {
+	const forbidden = FORBIDDEN_REASON[tokenVar] ?? FORBIDDEN_REASON.FORGEJO_TOKEN;
 	return async function resolveAuthority(repoFullName, login) {
 		// Both halves have to be present AND well-formed before they become path segments. A slash or a `..`
 		// in either would reach a different endpoint than the one this function believes it is asking, and
@@ -68,6 +85,23 @@ export function makeResolveForgejoAuthority({ apiUrl, token, fetchFn = fetch })
 			// a refusal rather than a failure.
 			return { authorized: false };
 		}
+		if (res.status === 403) {
+			// A CONFIGURATION error, named as one. Forgejo lets only a site admin, a repository admin, or the
+			// user themselves read a permission (measured on 14.0.5: a `write` collaborator's token gets 403
+			// {"message":"Only admins can query all permissions, repo admins can query all repo permissions,
+			// 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 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
+			// names the repair, and a delivery that failed this way still describes real work to redo once the
+			// account is fixed. The body is still not read: the fixed reason is enough, and a body is not ours
+			// to log. The reason names the variable whose token asked (FORBIDDEN_REASON).
+			return { indeterminate: forbidden };
+		}
 		if (!res.ok) {
 			// Note what is NOT here: the response body. A Forgejo error body can echo the request, and the
 			// request carried the token.

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.
  *