@osolmaz/pi-workflows 0.11.0 → 0.11.1

package/docs/plans/2026-08-20-autoimplement-blocker-challenge-plan.md

@@ -0,0 +1,138 @@
+---
+title: Confirm blockers before autoimplement stops
+author: Onur Solmaz <2453968+osolmaz@users.noreply.github.com>
+date: 2026-08-20
+---
+
+# Confirm blockers before autoimplement stops
+
+Autoimplement must not stop only because one model says that work is blocked. A separate agent must challenge the claim and confirm that the blocker is real before the workflow uses its terminal blocked result.
+
+The canonical workflow behavior is in [Workflow authoring reference](../workflows.md#built-in-planning-and-implementation).
+
+## Outcome
+
+Add one independent `challengeBlocker` agent node to the built-in autoimplement workflow. Use only existing public Pi Workflows primitives. Keep the graph explicit and reuse the existing redesign include and terminal blocked result.
+
+The challenge asks these questions in plain terms:
+
+- Are you really blocked?
+- Is this really a blocker right now?
+- Can you find a safe way to move forward and finish this?
+- Are you getting stuck on something trivial, procedural, reversible, or already authorized?
+
+The challenge inspects the task, approved plan, current result, evidence, scope, authority, previous attempts, and viable alternatives. It distinguishes a true external blocker from normal rollout work, local implementation work, a design adjustment, a missing verification step, or a reversible operational task.
+
+## Output and validation
+
+The challenge returns this bounded structured output:
+
+```json
+{
+  "route": "continue | blocked",
+  "blockingNow": true,
+  "outsideAuthority": true,
+  "canProceed": false,
+  "reason": "concise reason",
+  "nextAction": "",
+  "alternativesChecked": ["checked alternative"],
+  "evidence": ["concrete evidence"]
+}
+```
+
+A terminal blocked result is valid only when all these conditions hold:
+
+- `route` is `blocked`.
+- `blockingNow` is `true`.
+- `outsideAuthority` is `true`.
+- `canProceed` is `false`.
+- `nextAction` is empty.
+- `alternativesChecked` contains checked practical alternatives.
+- `evidence` contains concrete evidence.
+
+A `continue` result must name the next practical action. Contradictory output, such as `route: blocked` with `canProceed: true`, cannot route to the terminal blocked result.
+
+Keep the output concise and bounded.
+
+## Routing
+
+Route `classifyImplementation.blocked` to `challengeBlocker`. A `continue` challenge result routes to the existing redesign include. Redesign can revise and document the plan, then return through implementation, verification, review, comment handling, CI, and delivery. A valid `blocked` result routes to the existing terminal blocked result.
+
+Inspect each later model-produced blocked exit in verification, review, comment handling, CI, delivery, and equivalent current nodes. Route operational or model-judged blockers through the same challenge when it is safe. Use one reusable challenge node and existing edges or includes. Do not copy the prompt into several nodes and do not add an engine-level blocker feature.
+
+Preserve direct terminal stops for these hard boundaries:
+
+- an explicit human stop;
+- cancellation;
+- an exhausted workflow safety or replan limit;
+- a protected authorization gap;
+- an independent blocked result from redesign when another challenge could make an unsafe or unbounded loop.
+
+Limit blocker challenges to three attempts in one run. Include all earlier challenge outputs in each later challenge prompt. If a fourth challenge would be needed, stop with the normal safety-limit reason. Do not repeat an unsupported blocker assertion.
+
+Include the latest challenge output in the workflow's latest-issue or context helper. A later redesign must receive the rejected blocker, its evidence, and its required next action.
+
+## Required behavior
+
+A supported cutover does not become blocked only because an artifact has an ownership or packaging mismatch. In the Bob artifact incident, authorized deployment and rollback make the safe rollout work part of the task. The challenge must return `continue`, name the next rollout action, and route to redesign.
+
+A missing external authorization for a prohibited remote mutation can remain blocked when no non-mutating path completes the task.
+
+A local test failure, stale package, packaging mismatch, rollback preparation, or deployment procedure is not, by itself, outside the granted authority.
+
+## Tests
+
+Add focused tests in `test/builtin-autoimplement.test.ts` or the best current autoimplement test file. Prove all these cases:
+
+1. A false blocker routes to redesign and continued work.
+2. A confirmed blocker reaches the terminal blocked result.
+3. Contradictory blocked output is rejected or cannot route to the terminal blocked result.
+4. The Bob artifact-ownership mismatch returns `continue` when rollout is authorized.
+5. An explicit human stop bypasses the challenge.
+6. A protected authorization gap remains a hard stop.
+7. An independent `redesign.blocked` path does not create a loop.
+8. Earlier challenge context is present and the three-attempt bound works.
+9. All relevant late-stage model-generated blocker routes use the challenge.
+10. Normal success paths remain unchanged.
+
+Keep compute nodes pure. Put the independent reasoning in the challenge agent node.
+
+## Documentation
+
+Update `docs/workflows.md` with the blocker-confirmation rule, hard-stop exceptions, and bounded routing. Keep the public behavior concise. Do not add internal details that users do not need.
+
+## Verification
+
+Run focused tests during development. Before completion, run these exact checks:
+
+```bash
+npm run check
+npm run test:e2e
+npx slophammer-ts@latest dry .
+npx slophammer-ts@latest check . --only ts.dependency-boundaries-required
+git diff --check
+```
+
+Verify discovery and behavior through the installed package path or the repository's supported real-Pi end-to-end path. A fresh Pi process is required because built-in discovery is process-local.
+
+Review the final diff for missing blocker routes, accidental unbounded loops, and false terminal blockers. Fix each valid finding.
+
+## Boundaries
+
+- Preserve current run-bundle schemas unless a schema change is required. Do not add a persistence layer.
+- Use existing public Pi Workflows primitives only. Do not change Pi core.
+- Keep explicit human and protected authorization boundaries intact.
+- Use a hard cutover. Do not retain a legacy blocker route.
+- Preserve unrelated work and do not modify other repositories.
+- Make only the smallest source-based adjustment needed to preserve the approved behavior.
+- Do not stop for a trivial, reversible, or already authorized issue.
+- Commit coherent changes with a Conventional Commit message and push after all checks pass.
+- Do not publish a package, create a release, or merge anything.
+
+## Contract impact
+
+- **Session state:** normal workflow messages and tool results only.
+- **Other persistent data:** none beyond the existing run bundle records for normal node outputs.
+- **Pi internals:** none.
+- **Public Pi API:** existing documented extension APIs only.
+- **Public Pi Workflows API:** existing agent, compute, edge, and included-workflow primitives only.

package/docs/plans/2026-08-20-herdr-plugin-sync-plan.md

@@ -0,0 +1,104 @@
+---
+title: Keep the Herdr plugin linked after package updates
+author: Onur Solmaz <2453968+osolmaz@users.noreply.github.com>
+date: 2026-08-20
+---
+
+# Keep the Herdr plugin linked after package updates
+
+Pi Workflows ships its Herdr plugin inside the npm package. Herdr records the package's absolute path. npm can move an installed package between nested and hoisted `node_modules` directories during an update, which leaves Herdr linked to a path that no longer exists.
+
+Pi Workflows will own one explicit command that finds its own package and repairs this link. OnurPi will call that command after it installs an exact reviewed Pi Workflows release. OnurPi will not contain Herdr paths, manifests, or link-repair rules.
+
+## Outcome
+
+The canonical command is:
+
+```bash
+pi-workflows herdr sync --json
+```
+
+`pi-workflows herdr setup` remains an alias for compatibility.
+
+The command validates the bundled package before it changes Herdr. It then creates a missing link, enables a disabled link, leaves a correct link unchanged, or replaces a link to another package path or version. A successful result requires a new Herdr query that shows the expected plugin ID, package version, package root, manifest path, enabled state, and no warning.
+
+## Scope
+
+### Pi Workflows
+
+- Resolve the installed package root from the running CLI.
+- Validate `package.json`, `herdr-plugin.toml`, and the bundled viewer before changing Herdr.
+- Reconcile the current registration through Herdr's public CLI.
+- Return a versioned JSON result with one of `linked`, `relinked`, `enabled`, `unchanged`, or `unavailable`.
+- Return `unavailable` only when the Herdr executable is absent.
+- Treat malformed package data, malformed Herdr output, command failures, identity conflicts, and failed verification as errors.
+- Keep output bounded and use argument arrays instead of shell commands.
+- Test source and packed-package layouts, including paths that contain spaces.
+
+### OnurPi
+
+- Keep the Pi Workflows dependency pinned to an exact reviewed release.
+- Invoke the local `pi-workflows herdr sync --json` command from an explicit TypeScript sync script after dependency installation.
+- Accept the versioned result and keep Herdr-specific behavior in Pi Workflows.
+- Keep package installation free of `postinstall` side effects.
+
+## Non-goals
+
+- Do not create another Herdr plugin package or release.
+- Do not duplicate the manifest or viewer in OnurPi.
+- Do not add hard-coded `node_modules` paths.
+- Do not edit Herdr state files directly.
+- Do not change Herdr core or Pi core.
+- Do not hot-reload running Pi processes. A running process still needs `/reload` or restart after a package update.
+- Do not add a service, watcher, or implicit package-install mutation.
+
+## Command contract
+
+The JSON result uses schema `pi-workflows.herdr-sync.v1` and contains:
+
+- the result status;
+- whether Herdr state changed;
+- the plugin ID;
+- the expected and effective versions when available;
+- the effective enabled state when available;
+- a plain summary; and
+- an advisory that running Pi processes must reload after a package update.
+
+A missing Herdr executable returns `unavailable` with exit code zero because Herdr is an optional integration. Every other failure returns a nonzero exit code and does not claim success.
+
+The command preflights the new package before unlinking an old registration. Herdr currently exposes separate unlink and link commands, so replacement cannot be atomic. If replacement fails, Pi Workflows makes one restore attempt only when the previous package root still passes the same validation. It then reports the state found by a fresh Herdr query.
+
+Concurrent sync commands converge on the same target. After a failed or ambiguous mutation, the command queries Herdr and adopts the result only when another process already reached the exact expected state. It does not repeat the same mutation blindly.
+
+## Compatibility
+
+Existing `herdr setup` callers use the same implementation. Other Pi Workflows CLI commands do not change. The npm package remains the only source of the plugin manifest and viewer.
+
+OnurPi adds only invocation timing and result handling. It does not parse the Herdr manifest or issue link commands.
+
+## Verification
+
+### Pi Workflows
+
+- Test first link, unchanged link, disabled link, moved package path, stale path, and version update.
+- Test missing Herdr, malformed manifests, malformed plugin records, command failures, post-action mismatches, and bounded restore behavior.
+- Test concurrent adoption and paths with spaces.
+- Run the CLI from `npm pack` contents in nested and hoisted layouts.
+- Run `npm run check`, `npm run test:e2e`, Slophammer, SimpleDoc, and diff checks.
+
+### OnurPi
+
+- Test every structured result and invalid command output with a fake executable.
+- Verify the wrapper contains no plugin ID, manifest copy, Herdr mutation command, or package path.
+- Verify root and wrapper dependency pins remain equal.
+- Run `npm run check`, `npm run slophammer`, SimpleDoc, and diff checks.
+
+### Adoption
+
+After a separately approved Pi Workflows release, update OnurPi to that exact version and run:
+
+```bash
+npm run workflows:sync
+```
+
+Then verify the Herdr plugin list, open `piw`, and start or reload Pi to confirm resource discovery. Repeating the sync must return `unchanged`.

package/docs/workflows.md

@@ -419,6 +419,10 @@ The built-in `plan-approval` workflow offers verified human `continue`, `stop`,
 
 Autoimplement writes and runs the exact Pi Reviewer command. It records P0 through P2 by review round. P0 or P1 work requires another review. P2-only work can be addressed and verified without another reviewer run. CI tracking commands are also explicit. One CI watch lasts at most five minutes, after which the model runs more useful local tests before checking CI again.
 
+A model-generated blocker from implementation or a safe later stage does not end autoimplement by itself. A separate blocker-challenge agent checks the task, approved plan, current result, evidence, scope, authority, earlier attempts, and practical alternatives. It confirms a blocker only when the blocker exists now, is outside the granted authority, has no safe path forward, has an empty next action, and includes concrete evidence and checked alternatives. A rejected blocker must name the next practical action and routes through the existing redesign workflow before implementation and verification continue.
+
+Autoimplement can run the blocker challenge at most three times in one run. Each later challenge receives the earlier challenge results. Reaching the limit stops with the normal workflow safety-limit reason. Explicit human stops, cancellation, exhausted workflow or replan limits, protected authorization gaps, and an independent blocked result from redesign remain direct stops. These hard boundaries do not enter the blocker challenge.
+
 ### Built-in monitor
 
 The built-in `monitor` workflow turns a plain request for repeated checks into

package/herdr-plugin.toml

@@ -1,6 +1,6 @@
 id = "osolmaz.pi-workflows"
 name = "Pi Workflows"
-version = "0.11.0"
+version = "0.11.1"
 min_herdr_version = "0.7.0"
 description = "Open the active Pi Workflows run in piw from a managed Herdr pane."
 platforms = ["linux", "macos"]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@osolmaz/pi-workflows",
-  "version": "0.11.0",
+  "version": "0.11.1",
   "description": "Workflow and controller runtime with a live terminal viewer for the pi coding agent",
   "keywords": [
     "pi-package"

package/src/builtins/autoimplement.workflow.ts

@@ -87,8 +87,22 @@ export type AutoimplementBlocked = {
   evidence: unknown;
 };
 
+type BlockerChallenge = {
+  route: "continue" | "blocked";
+  blockingNow: boolean;
+  outsideAuthority: boolean;
+  canProceed: boolean;
+  reason: string;
+  nextAction: string;
+  alternativesChecked: string[];
+  evidence: string[];
+};
+
 const FIVE_MINUTES_MS = 5 * 60_000;
 const TEN_MINUTES_MS = 10 * 60_000;
+const MAX_BLOCKER_CHALLENGES = 3;
+const MAX_CHALLENGE_ITEMS = 5;
+const MAX_CHALLENGE_TEXT = 500;
 
 function requireRecord(value: unknown, label: string): Record<string, unknown> {
   if (value === null || typeof value !== "object" || Array.isArray(value)) {
@@ -104,6 +118,80 @@ function requireString(value: unknown, label: string): string {
   return value.trim();
 }
 
+function boundedChallengeItems(value: unknown, label: string): string[] {
+  if (!Array.isArray(value) || value.length > MAX_CHALLENGE_ITEMS) {
+    throw new Error(`${label} must be an array with at most ${MAX_CHALLENGE_ITEMS} items`);
+  }
+  return value.map((item, index) => {
+    const text = requireString(item, `${label}[${index}]`);
+    if (text.length > MAX_CHALLENGE_TEXT) {
+      throw new Error(`${label}[${index}] must be at most ${MAX_CHALLENGE_TEXT} characters`);
+    }
+    return text;
+  });
+}
+
+function parseBlockerChallenge(value: unknown): BlockerChallenge {
+  const result = requireRecord(value, "blocker challenge");
+  if (result.route !== "continue" && result.route !== "blocked") {
+    throw new Error("blocker challenge route must be continue or blocked");
+  }
+  for (const key of ["blockingNow", "outsideAuthority", "canProceed"] as const) {
+    if (typeof result[key] !== "boolean") {
+      throw new Error(`blocker challenge ${key} must be a boolean`);
+    }
+  }
+  const blockingNow = result.blockingNow as boolean;
+  const outsideAuthority = result.outsideAuthority as boolean;
+  const canProceed = result.canProceed as boolean;
+  const reason = requireString(result.reason, "blocker challenge reason");
+  if (reason.length > MAX_CHALLENGE_TEXT) {
+    throw new Error(`blocker challenge reason must be at most ${MAX_CHALLENGE_TEXT} characters`);
+  }
+  if (typeof result.nextAction !== "string") {
+    throw new Error("blocker challenge nextAction must be a string");
+  }
+  const nextAction = result.nextAction.trim();
+  if (nextAction.length > MAX_CHALLENGE_TEXT) {
+    throw new Error(
+      `blocker challenge nextAction must be at most ${MAX_CHALLENGE_TEXT} characters`,
+    );
+  }
+  const alternativesChecked = boundedChallengeItems(
+    result.alternativesChecked,
+    "blocker challenge alternativesChecked",
+  );
+  const evidence = boundedChallengeItems(result.evidence, "blocker challenge evidence");
+
+  if (result.route === "blocked") {
+    if (
+      blockingNow !== true ||
+      outsideAuthority !== true ||
+      canProceed !== false ||
+      nextAction.length > 0 ||
+      alternativesChecked.length === 0 ||
+      evidence.length === 0
+    ) {
+      throw new Error(
+        "blocked challenge requires blockingNow=true, outsideAuthority=true, canProceed=false, an empty nextAction, and concrete alternatives and evidence",
+      );
+    }
+  } else if (canProceed !== true || nextAction.length === 0) {
+    throw new Error("continue challenge requires canProceed=true and a practical nextAction");
+  }
+
+  return {
+    route: result.route,
+    blockingNow,
+    outsideAuthority,
+    canProceed,
+    reason,
+    nextAction,
+    alternativesChecked,
+    evidence,
+  };
+}
+
 function parseInput(value: unknown): AutoimplementInput {
   const input = requireRecord(value, "autoimplement input");
   const constraints = input.constraints;
@@ -339,6 +427,41 @@ function currentPlanDigest(context: WorkflowNodeContext): string {
   return digest(plan);
 }
 
+function blockerChallenges(context: WorkflowNodeContext): BlockerChallenge[] {
+  return context.state.steps
+    .filter((step) => step.nodeId === "challengeBlocker" && step.outcome === "ok")
+    .map((step) => step.output as BlockerChallenge);
+}
+
+function latestBlockerClaim(context: WorkflowNodeContext): unknown {
+  const ids = [
+    "classifyImplementation",
+    "classifyVerification",
+    "repairReviewCommand",
+    "inspectComments",
+    "inspectCi",
+    "repairCiCommand",
+    "assessTrackedCi",
+    "classifyCi",
+    "finalizeDelivery",
+  ];
+  for (let index = context.state.steps.length - 1; index >= 0; index -= 1) {
+    const step = context.state.steps[index];
+    if (step && ids.includes(step.nodeId)) {
+      return { source: step.nodeId, result: step.output };
+    }
+  }
+  throw new Error("No model-generated blocker claim is available to challenge");
+}
+
+function recentWorkflowAttempts(context: WorkflowNodeContext): unknown[] {
+  return context.state.steps.slice(-12).map((step) => ({
+    nodeId: step.nodeId,
+    outcome: step.outcome,
+    output: step.output,
+  }));
+}
+
 function latestIssue(context: WorkflowNodeContext): unknown {
   const approval = context.outputs.approval as
     | { exit?: string; output?: { instructions?: unknown } }
@@ -351,6 +474,7 @@ function latestIssue(context: WorkflowNodeContext): unknown {
     };
   }
   const ids = [
+    "challengeBlocker",
     "classifyImplementation",
     "classifyVerification",
     "triageReview",
@@ -415,6 +539,8 @@ function reviewRounds(context: WorkflowNodeContext): ReviewAssessment[] {
 
 function latestBlockedReason(context: WorkflowNodeContext): { reason: string; evidence: unknown } {
   const candidates = [
+    "challengeBlockerGuard",
+    "challengeBlocker",
     "finalizeDelivery",
     "inspectCi",
     "assessTrackedCi",
@@ -634,6 +760,51 @@ export const autoimplementWorkflow = defineWorkflow({
           "implementation assessment",
         ),
     }),
+    challengeBlockerGuard: compute({
+      run: (context) => {
+        const challenges = blockerChallenges(context);
+        return challenges.length >= MAX_BLOCKER_CHALLENGES
+          ? {
+              route: "blocked",
+              reason: `Blocker challenge reached the ${MAX_BLOCKER_CHALLENGES}-attempt workflow safety limit.`,
+              evidence: { attempts: challenges.length, challenges },
+            }
+          : {
+              route: "challenge",
+              attempt: challenges.length + 1,
+              limit: MAX_BLOCKER_CHALLENGES,
+            };
+      },
+    }),
+    challengeBlocker: agent({
+      statusDetail: "challenging blocker claim",
+      prompt: (context) => {
+        const request = context.input as AutoimplementInput;
+        return [
+          "Independently challenge the latest claim that autoimplement is blocked.",
+          "Are you really blocked?",
+          "Is this really a blocker right now?",
+          "Can you find a safe way to move forward and finish this?",
+          "Are you getting stuck on something trivial, procedural, reversible, or already authorized?",
+          "Inspect the task, approved plan, current result, evidence, scope, authority, previous attempts, and viable alternatives.",
+          "Distinguish a true external blocker from ordinary rollout work, local implementation work, a design adjustment, a missing verification step, or a reversible operational task.",
+          "A local test failure, stale package, packaging or artifact mismatch, rollback preparation, or deployment procedure is not by itself outside authority.",
+          "If a safe deployment and rollback path is already authorized, a supported cutover is work to do, not a blocker.",
+          "Confirm blocked only when the issue blocks progress now, is outside authority, and has no safe practical path forward.",
+          "Return continue with the next practical action when work can proceed. Keep text concise, with at most five alternatives and five evidence items.",
+          `Task: ${request.task}`,
+          `Approved plan: ${JSON.stringify(currentPlan(context))}`,
+          `Current result and claimed blocker: ${JSON.stringify(latestBlockerClaim(context))}`,
+          `Authorized scope: ${request.scope ?? request.repository ?? "the current repository and task"}`,
+          `Constraints and authority: ${JSON.stringify(request.constraints ?? [])}`,
+          `Merge authorized: ${request.merge === true}`,
+          `Previous blocker challenges: ${JSON.stringify(blockerChallenges(context))}`,
+          `Recent workflow attempts: ${JSON.stringify(recentWorkflowAttempts(context))}`,
+        ].join("\n");
+      },
+      expectedOutput: `{ "route": "continue" | "blocked", "blockingNow": true | false, "outsideAuthority": true | false, "canProceed": true | false, "reason": "concise reason", "nextAction": "practical action or empty when blocked", "alternativesChecked": ["checked alternative"], "evidence": ["concrete evidence"] }`,
+      validate: parseBlockerChallenge,
+    }),
     verify: agent({
       timeoutMs: 45 * 60_000,
       statusDetail: "verifying",
@@ -1008,15 +1179,33 @@ export const autoimplementWorkflow = defineWorkflow({
       from: "classifyImplementation",
       switch: {
         on: "$.route",
-        cases: { verify: "verify", redesign: "redesign", fix: "fix", blocked: "blocked" },
+        cases: {
+          verify: "verify",
+          redesign: "redesign",
+          fix: "fix",
+          blocked: "challengeBlockerGuard",
+        },
       },
     },
+    {
+      from: "challengeBlockerGuard",
+      switch: { on: "$.route", cases: { challenge: "challengeBlocker", blocked: "blocked" } },
+    },
+    {
+      from: "challengeBlocker",
+      switch: { on: "$.route", cases: { continue: "redesign", blocked: "blocked" } },
+    },
     { from: "verify", to: "classifyVerification" },
     {
       from: "classifyVerification",
       switch: {
         on: "$.route",
-        cases: { publish: "publish", redesign: "redesign", fix: "fix", blocked: "blocked" },
+        cases: {
+          publish: "publish",
+          redesign: "redesign",
+          fix: "fix",
+          blocked: "challengeBlockerGuard",
+        },
       },
     },
     { from: "fix", to: "verify" },
@@ -1035,7 +1224,10 @@ export const autoimplementWorkflow = defineWorkflow({
     },
     {
       from: "repairReviewCommand",
-      switch: { on: "$.route", cases: { retry: "runReview", blocked: "blocked" } },
+      switch: {
+        on: "$.route",
+        cases: { retry: "runReview", blocked: "challengeBlockerGuard" },
+      },
     },
     {
       from: "assessReview",
@@ -1062,7 +1254,12 @@ export const autoimplementWorkflow = defineWorkflow({
       from: "inspectComments",
       switch: {
         on: "$.route",
-        cases: { redesign: "redesign", fix: "fix", ci: "inspectCi", blocked: "blocked" },
+        cases: {
+          redesign: "redesign",
+          fix: "fix",
+          ci: "inspectCi",
+          blocked: "challengeBlockerGuard",
+        },
       },
     },
     {
@@ -1073,7 +1270,7 @@ export const autoimplementWorkflow = defineWorkflow({
           green: "finalizeDelivery",
           failed: "classifyCi",
           pending: "trackCi",
-          unavailable: "blocked",
+          unavailable: "challengeBlockerGuard",
         },
       },
     },
@@ -1086,7 +1283,10 @@ export const autoimplementWorkflow = defineWorkflow({
     },
     {
       from: "repairCiCommand",
-      switch: { on: "$.route", cases: { retry: "trackCi", blocked: "blocked" } },
+      switch: {
+        on: "$.route",
+        cases: { retry: "trackCi", blocked: "challengeBlockerGuard" },
+      },
     },
     {
       from: "assessTrackedCi",
@@ -1096,7 +1296,7 @@ export const autoimplementWorkflow = defineWorkflow({
           green: "finalizeDelivery",
           failed: "classifyCi",
           pending: "opportunisticTest",
-          unavailable: "blocked",
+          unavailable: "challengeBlockerGuard",
         },
       },
     },
@@ -1109,13 +1309,16 @@ export const autoimplementWorkflow = defineWorkflow({
           redesign: "redesign",
           fix: "fix",
           unrelated: "finalizeDelivery",
-          blocked: "blocked",
+          blocked: "challengeBlockerGuard",
         },
       },
     },
     {
       from: "finalizeDelivery",
-      switch: { on: "$.status", cases: { completed: "finalize", blocked: "blocked" } },
+      switch: {
+        on: "$.status",
+        cases: { completed: "finalize", blocked: "challengeBlockerGuard" },
+      },
     },
   ],
 });