@cat-factory/app 0.191.0 → 0.193.0

package/app/components/board/AddTaskModal.vue

@@ -387,13 +387,15 @@ const fragmentPool = computed(() => fragments.forBlockType(frame.value?.type ??
 
 // Hide UI-testing pipelines (`tester-ui` / `visual-confirmation`) when the target frame has no
 // UI to exercise — they'd be refused server-side (see utils/pipeline + the backend gate). Also
-// hide `'recurring'`-only pipelines (a one-off task start of one is refused at run start) and,
-// for a `document` / `review` task, every pipeline whose purpose doesn't match (a doc task authors
-// a doc, a review task reviews a PR — only document / review pipelines are relevant, per the
-// `purpose` classifier). Re-filters as the chosen task type changes.
+// hide `'recurring'`-only pipelines (a one-off task start of one is refused at run start) and every
+// pipeline whose purpose doesn't match the chosen task type (a doc task authors a doc, a review task
+// reviews a PR, and a `feature`/`bug` task ships code — so it is offered build + research only, not
+// the doc/review/planning presets). `blockLevel: 'task'` is passed literally because this modal only
+// ever creates a task leaf, which also drops the three planning presets the backend would refuse.
+// Re-filters as the chosen task type changes.
 const selectablePipelines = computed(() =>
   pipelines.pipelines.filter((p) =>
-    pipelineAllowedForManualStart(p, frame.value, board.blocks, taskType.value),
+    pipelineAllowedForManualStart(p, frame.value, board.blocks, taskType.value, 'task'),
   ),
 )
 // Some task types want their type-default pipeline surfaced in the modal up front, so picking the

package/app/components/board/RecurringPipelineModal.vue

@@ -74,9 +74,15 @@ const selectedPipeline = computed(() => pipelines.getPipeline(pipelineId.value))
 
 // Infer the template from the picked pipeline so the backend seeds the right block
 // description (and so we know to show the tracker config).
+//
+// Only the pipelines whose SHAPE is specific to one kind of recurring work can be inferred this
+// way. `dep-update` no longer can: its pipeline was retired in the catalog collapse (it was the
+// ordinary build tail under a recurring name), so a dependency-update schedule now runs an ordinary
+// build rung — which is also what every generic schedule runs, so inferring the template from it
+// would mislabel all of them. The template itself survives for an explicit API caller; see
+// `scheduleTemplateSchema`.
 const template = computed<ScheduleTemplate>(() => {
   if (pipelineId.value === 'pl_tech_debt') return 'tech-debt'
-  if (pipelineId.value === 'pl_dep_update') return 'dep-update'
   if (pipelineId.value === 'pl_bug_triage') return 'bug-triage'
   return 'custom'
 })
@@ -99,11 +105,10 @@ watch(open, (isOpen) => {
   if (!isOpen) return
   name.value = ''
   description.value = ''
-  // Default to the Dependency-updates pipeline if present, else the first.
-  pipelineId.value =
-    pipelines.pipelines.find((p) => p.id === 'pl_dep_update')?.id ??
-    pipelines.pipelines[0]?.id ??
-    ''
+  // Default to the first schedulable pipeline, which is the ladder's own default rung. There is no
+  // longer a canned recurring build preset to prefer — the dependency-update pipeline was the
+  // ordinary build tail under another name — so the default build is the honest starting point.
+  pipelineId.value = selectablePipelines.value[0]?.id ?? pipelines.pipelines[0]?.id ?? ''
   recurrence.value = defaultRecurrence()
   onDemand.value = false
   saving.value = false

package/app/components/focus/BlockFocusView.vue

@@ -30,12 +30,20 @@ const deps = computed(() =>
 )
 
 // Hide UI-testing pipelines when this block's frame has no UI to exercise, `'recurring'`-only
-// pipelines (a manual run of one is refused server-side), and — for a `document` task — every
-// non-document pipeline (per the `purpose` classifier) — see the backend gate.
+// pipelines (a manual run of one is refused server-side), and every pipeline whose purpose doesn't
+// match this block's task type or LEVEL (per the `purpose` classifier) — see the backend gate. The
+// level is what keeps the planning presets on initiative blocks and off everything else, in both
+// directions, so this menu never offers a run the engine answers with a 409.
 const runOptions = computed(() => {
   const frame = block.value ? board.serviceOf(block.value) : undefined
   return pipelines.pipelines.filter((p) =>
-    pipelineAllowedForManualStart(p, frame, board.blocks, block.value?.taskType),
+    pipelineAllowedForManualStart(
+      p,
+      frame,
+      board.blocks,
+      block.value?.taskType,
+      block.value?.level,
+    ),
   )
 })
 

package/app/components/panels/InspectorPanel.vue

@@ -178,13 +178,24 @@ const taskBranchUrl = computed(() => {
   return base ? `${base}/tree/${pr.branch}` : null
 })
 
-// Hide UI-testing pipelines when this block's frame has no UI to exercise, and `'recurring'`-only
-// pipelines (a manual run of one is refused server-side) — they'd be refused at run start (see
-// utils/pipeline + the backend gate).
+// Hide UI-testing pipelines when this block's frame has no UI to exercise, `'recurring'`-only
+// pipelines (a manual run of one is refused server-side), and every pipeline whose purpose doesn't
+// match this block's task type or LEVEL — they'd be refused at run start (see utils/pipeline + the
+// backend gate). The level is what keeps the planning presets on initiative blocks and off
+// everything else, so this menu never offers a run the engine answers with a 409; it applies to
+// frames and modules too, which is why it reads `block.level` rather than assuming a task.
 const runMenu = computed(() => {
   const frame = block.value ? board.serviceOf(block.value) : undefined
   return pipelines.pipelines
-    .filter((p) => pipelineAllowedForManualStart(p, frame, board.blocks))
+    .filter((p) =>
+      pipelineAllowedForManualStart(
+        p,
+        frame,
+        board.blocks,
+        block.value?.taskType,
+        block.value?.level,
+      ),
+    )
     .map((p) => ({
       label: p.name,
       icon: 'i-lucide-play',

package/app/components/panels/inspector/TaskRunSettings.vue

@@ -144,10 +144,14 @@ const selectedPipeline = computed(() =>
 // pipelines (the task's manual Run control can't start one), and — for a `document` task — every
 // non-document pipeline (it authors a doc, so a build/test pipeline makes no sense). All would be
 // refused / wrong at run start (see utils/pipeline + the backend gate + the purpose classifier).
+// `blockLevel: 'task'` is passed literally because this panel only ever edits a task leaf, which
+// drops the planning presets the engine would refuse. The task-type narrowing already excludes them
+// for `feature`/`bug`, but NOT for a `spike` / `ralph` / deployment-custom type — and a planning
+// preset settable as a task's DEFAULT pipeline is a 409 on every later Start.
 const taskFrame = computed(() => board.serviceOf(props.block))
 const selectablePipelines = computed(() =>
   pipelines.pipelines.filter((p) =>
-    pipelineAllowedForManualStart(p, taskFrame.value, board.blocks, props.block.taskType),
+    pipelineAllowedForManualStart(p, taskFrame.value, board.blocks, props.block.taskType, 'task'),
   ),
 )
 function setPipeline(id: string) {

package/app/components/prReview/PrReviewWindow.vue

@@ -7,6 +7,10 @@
 // findings to a Fixer that commits fixes onto the PR branch), `Post` (publish them as inline PR
 // review comments), or `Finish` (just record the curated selection). Fix/Post act on the
 // selection, so they require at least one selected finding.
+//
+// While the review is still RUNNING it also offers `Resume`, which re-dispatches a review that
+// appears stuck for only the slices that never reported (see `canResume` for why it is always
+// offered rather than gated on an activity heuristic).
 import { computed, ref, watch } from 'vue'
 import { useResultView } from '~/composables/useResultView'
 import { useExecutionStore } from '~/stores/execution'
@@ -208,6 +212,25 @@ async function onResolve(action: PrReviewResolution): Promise<void> {
   await prReview.resolve(id, activeSelectedIds.value, action).catch(() => {})
 }
 
+/**
+ * RESUME a review that appears stuck. Offered throughout the `reviewing` phase — including the
+ * neutral "planning" sub-state, since a wedge is just as possible before a plan is reported as
+ * after — because the whole complaint this answers is that a stuck review had no visible
+ * affordance at all. Deliberately NOT hidden behind a staleness heuristic: `lastActivityAt` freezes
+ * on a long silent turn (a single completion emits no tool call and grows no subagent transcript),
+ * so the platform cannot tell a wedged review from a quiet-but-working one, and hiding the control
+ * until it thinks it can would put it out of reach in exactly the case that motivated it.
+ */
+const canResume = computed(
+  () => status.value === 'reviewing' && !prReview.resuming && access.canExecuteRuns.value,
+)
+
+async function onResume(): Promise<void> {
+  const id = instanceId.value
+  if (!id || !canResume.value) return
+  await prReview.resume(id).catch(() => {})
+}
+
 // Per-finding CHALLENGE: the open finding's id (its inline concern box is showing) + the drafted
 // concern text. Dispatching moves the whole review to `challenging` until the verdict lands.
 const challengeForId = ref<string | null>(null)
@@ -273,7 +296,7 @@ async function onDismiss(id: string): Promise<void> {
           <div
             v-if="planning"
             data-testid="pr-review-planning"
-            class="flex h-full flex-col items-center justify-center gap-2 py-10 text-center text-slate-400"
+            class="flex flex-1 flex-col items-center justify-center gap-2 py-10 text-center text-slate-400"
           >
             <UIcon name="i-lucide-loader-circle" class="h-8 w-8 animate-spin opacity-60" />
             <p class="text-sm text-slate-200">{{ t('prReview.reviewing.planning.title') }}</p>
@@ -395,6 +418,37 @@ async function onDismiss(id: string): Promise<void> {
               </ul>
             </template>
           </div>
+
+          <!-- Nudge a review that looks stuck. Present in BOTH reviewing sub-states, and never
+               gated on a staleness guess: the heartbeat freezes on a long silent turn, so nothing
+               here can tell wedged from quiet-but-working (see `canResume`). Re-reviews only the
+               slices that never reported; the finished ones are re-aggregated from their captured
+               reports. -->
+          <div class="mt-4 border-t border-slate-800 pt-3">
+            <p
+              v-if="prReview.error"
+              data-testid="pr-review-resume-error"
+              class="mb-2 rounded-md bg-rose-500/10 px-3 py-2 text-[12px] text-rose-300"
+            >
+              {{ prReview.error }}
+            </p>
+            <div class="flex items-start justify-between gap-3">
+              <p class="min-w-0 text-[11px] text-slate-500">{{ t('prReview.resume.hint') }}</p>
+              <UButton
+                data-testid="pr-review-resume"
+                size="xs"
+                color="neutral"
+                variant="soft"
+                icon="i-lucide-rotate-ccw"
+                :loading="prReview.resuming"
+                :disabled="!canResume"
+                :title="access.canExecuteRuns.value ? undefined : t('access.noRunExecute')"
+                @click="onResume"
+              >
+                {{ t('prReview.resume.action') }}
+              </UButton>
+            </div>
+          </div>
         </div>
 
         <!-- A resolution is executing: the Fixer is committing / comments are being posted. -->

package/app/composables/api/prReview.ts

@@ -3,6 +3,7 @@ import {
   dismissPrReviewFindingContract,
   getPrReviewContract,
   resolvePrReviewContract,
+  resumePrReviewContract,
 } from '@cat-factory/contracts'
 import type { ApiContext } from './context'
 
@@ -32,6 +33,15 @@ export function prReviewApi({ send, ws }: ApiContext) {
         body,
       }),
 
+    // Re-trigger a review stuck mid-`reviewing`: only the slices that never reported are
+    // re-reviewed. No body — the engine derives what to redo from what it observed.
+    resumePrReview: (workspaceId: string, executionId: string) =>
+      send(resumePrReviewContract, {
+        pathPrefix: ws(workspaceId),
+        pathParams: { executionId },
+        body: {},
+      }),
+
     // Dismiss a parked finding entirely (drops it + prunes it from the selection).
     dismissPrReviewFinding: (workspaceId: string, executionId: string, findingId: string) =>
       send(dismissPrReviewFindingContract, {

package/app/composables/usePipelineHealth.spec.ts

@@ -140,6 +140,38 @@ describe('usePipelineHealth', () => {
     expect(invalid.value[0]!.problems.some((p) => p.type === 'shape')).toBe(true)
   })
 
+  // The regression this pins: the advisory carried its own "only a companion may be gated" rule,
+  // so when the engine generalised gating to `BUILTIN_GATABLE_KINDS` the shipped `pl_simple`
+  // ("Adaptive build" — an estimate-gated `architect`) was reported invalid in EVERY workspace.
+  // Because the advisory auto-opens a modal over the board, that made the board unusable rather
+  // than merely warning wrongly. Both sides now read the shared contracts constant.
+  it('accepts an estimate-gated NON-companion producer that the shared gatable set allows', () => {
+    const adaptive = builtin(['task-estimator', 'architect', 'architect-companion', 'coder'], {
+      gating: [null, { enabled: true, minComplexity: 0.4, onMissingEstimate: 'run' }, null, null],
+    })
+    const { hasIssues } = scan([adaptive])
+    expect(hasIssues.value).toBe(false)
+  })
+
+  it('still flags an estimate-gated kind the shared gatable set excludes (merger)', () => {
+    const gatedMerger = builtin(['task-estimator', 'coder', 'merger'], {
+      gating: [null, null, { enabled: true, minComplexity: 0.4, onMissingEstimate: 'run' }],
+    })
+    const { invalid } = scan([gatedMerger])
+    expect(invalid.value).toHaveLength(1)
+    expect(invalid.value[0]!.problems.some((p) => p.type === 'shape')).toBe(true)
+  })
+
+  it('flags a step carrying BOTH a human approval gate and an estimate gate (shape)', () => {
+    const both = builtin(['task-estimator', 'architect'], {
+      gates: [false, true],
+      gating: [null, { enabled: true, minComplexity: 0.4, onMissingEstimate: 'run' }],
+    })
+    const { invalid } = scan([both])
+    expect(invalid.value).toHaveLength(1)
+    expect(invalid.value[0]!.problems.some((p) => p.type === 'shape')).toBe(true)
+  })
+
   it('reports a built-in whose catalog version moved ahead as outdated (not invalid)', () => {
     const stale = builtin(['coder', 'reviewer'], { id: 'pl_stale', version: 1 })
     const { invalid, outdated } = scan([stale], { pl_stale: 2 })

package/app/composables/usePipelineHealth.ts

@@ -1,6 +1,7 @@
 import { computed } from 'vue'
 import type { Pipeline } from '~/types/domain'
 import type { StepGating } from '~/types/consensus'
+import { isBuiltinGatableKind } from '@cat-factory/contracts'
 import { COMPANION_FOR_PRODUCER, isKnownAgentKind, isProducerCompanion } from '~/utils/catalog'
 import { usePipelinesStore } from '~/stores/pipelines'
 
@@ -78,6 +79,11 @@ const isEnabledAt = (p: Pipeline, i: number) => p.enabled?.[i] !== false
  * gating, over the ENABLED subset), collecting the first problem instead of throwing. Returns a
  * human message, or null when the shape is valid. Kept in step with
  * `backend/packages/orchestration/src/modules/pipelines/pipelineShape.ts`.
+ *
+ * A rule here must be keyed off vocabulary SHARED with that module (`@cat-factory/contracts`)
+ * wherever one exists, never re-stated locally — see the gating note below for what a drifted copy
+ * costs. Adding a rule to `assertValidGating` without adding it here is the milder half of the same
+ * drift: a pipeline the engine refuses at save that this advisory calls healthy.
  */
 function shapeProblem(p: Pipeline): string | null {
   const kinds = p.agentKinds
@@ -102,16 +108,29 @@ function shapeProblem(p: Pipeline): string | null {
       return `Companion '${kind}' must run immediately after an enabled step it can review (${targets.join(', ')}).`
     }
   }
-  // Estimate gating: an enabled gated step must be a companion, set ≥1 threshold, and have an
-  // enabled task-estimator earlier in the chain.
+  // Estimate gating: an enabled gated step must be a GATABLE kind, must not also carry a human
+  // approval gate, must set ≥1 threshold, and must have an enabled task-estimator earlier in the
+  // chain. Gatability reads the SHARED `BUILTIN_GATABLE_KINDS` rather than a local rule, because
+  // this advisory auto-opens a modal over the board: a copy of the rule that drifts behind the
+  // engine's does not merely warn wrongly, it calls a pipeline the product SHIPS invalid and leaves
+  // the board unusable. A DEPLOYMENT-registered kind can override gatability for itself through the
+  // agent-kind registry, which the SPA cannot see, so the two are not perfectly symmetric: such a
+  // kind is reported here and accepted by the engine. That is the safe direction of the asymmetry —
+  // a dismissible advisory rather than a refused save — and the only one available without shipping
+  // the registry to the browser.
   const gating = p.gating
   if (gating) {
     for (let i = 0; i < kinds.length; i++) {
       const g = gating[i] as StepGating | null | undefined
       if (!g?.enabled || !isEnabledAt(p, i)) continue
       const kind = kinds[i]
-      if (!kind || !isProducerCompanion(kind)) {
-        return `Step '${kind}' cannot be estimate-gated — only companion steps may be skipped on the estimate.`
+      if (!kind || !isBuiltinGatableKind(kind)) {
+        return `Step '${kind}' may not be estimate-gated — its output is required by the rest of the run. Only a step whose result later steps read as context (a design, a review, an extra verification pass) may be skipped on the estimate.`
+      }
+      // A human approval gate and an estimate gate on the same step contradict: the estimate may
+      // ADD a human checkpoint but never CANCEL a pause the pipeline author asked for.
+      if (p.gates?.[i] === true) {
+        return `Step '${kind}' carries a human approval gate, so it cannot also be estimate-gated — the estimate may add a human checkpoint but never remove one.`
       }
       if (g.minComplexity === undefined && g.minRisk === undefined && g.minImpact === undefined) {
         return `Step '${kind}' is estimate-gated but sets no threshold (complexity / risk / impact).`

package/app/stores/execution.spec.ts

@@ -186,3 +186,90 @@ describe('execution store metrics preservation (live-only rollup)', () => {
     expect(step.metrics?.calls).toBe(5)
   })
 })
+
+// Regression for the optimistic-echo CLOBBER. `upsert`/`hydrate` are monotonic by `rev`, but an
+// action store's echo used to reach into the cached run and assign a step's sub-state directly,
+// comparing nothing — so a slow HTTP response overwrote state the stream had already advanced, and
+// no later event restored it. `echoAfter` closes that by capturing the run's `rev` before the
+// request and re-reading it after.
+//
+// The fork-decision chat is the case that caught it in CI: `chat` emits the one-message `answering`
+// state and then wakes the driver, which appends the reply and emits again. With a canned (no-model)
+// reply the two-message thread routinely lands first, and echoing the response dropped the reply
+// permanently — a parked run emits nothing more.
+describe('execution store echoAfter (optimistic-echo guard)', () => {
+  let store: ReturnType<typeof useExecutionStore>
+  beforeEach(() => {
+    store = useExecutionStore()
+  })
+
+  const run = (rev: number, chat: unknown[]): ExecutionInstance =>
+    ({
+      id: 'e1',
+      blockId: 'b1',
+      rev,
+      currentStep: 0,
+      steps: [{ agentKind: 'coder', forkDecision: { status: 'answering', chat } }],
+    }) as unknown as ExecutionInstance
+
+  const chatOf = () =>
+    (store.getInstance('e1')!.steps[0] as unknown as { forkDecision: { chat: unknown[] } })
+      .forkDecision.chat
+
+  it('applies the echo when nothing newer arrived while the request was in flight', () => {
+    store.hydrate([run(1, ['human'])], 'ws1')
+    return store
+      .echoAfter(
+        'e1',
+        async () => ({ status: 'answering', chat: ['human', 'echoed'] }),
+        (state, instance) => {
+          ;(instance.steps[0] as unknown as { forkDecision: unknown }).forkDecision = state
+        },
+      )
+      .then(() => expect(chatOf()).toEqual(['human', 'echoed']))
+  })
+
+  it('DROPS the echo when the stream delivered a newer revision first', async () => {
+    store.hydrate([run(1, ['human'])], 'ws1')
+    // The driver's reply lands (rev 2, two messages) while the chat POST is still in flight...
+    await store.echoAfter(
+      'e1',
+      async () => {
+        store.upsert(run(2, ['human', 'assistant reply']))
+        return { status: 'answering', chat: ['human'] }
+      },
+      (state, instance) => {
+        ;(instance.steps[0] as unknown as { forkDecision: unknown }).forkDecision = state
+      },
+    )
+    // ...so the one-message response must not put the thread back. Unguarded, this was ['human'],
+    // the reply was gone, and the "thinking…" bubble spun forever.
+    expect(chatOf()).toEqual(['human', 'assistant reply'])
+  })
+
+  it('still returns the response body when the echo is dropped', async () => {
+    store.hydrate([run(1, [])], 'ws1')
+    const returned = await store.echoAfter(
+      'e1',
+      async () => {
+        store.upsert(run(5, ['newer']))
+        return 'body'
+      },
+      () => {
+        throw new Error('apply must not run')
+      },
+    )
+    expect(returned).toBe('body')
+  })
+
+  it('skips the echo for a run the cache does not hold, rather than throwing', async () => {
+    const returned = await store.echoAfter(
+      'missing',
+      async () => 'body',
+      () => {
+        throw new Error('apply must not run')
+      },
+    )
+    expect(returned).toBe('body')
+  })
+})

package/app/stores/execution.ts

@@ -130,6 +130,44 @@ export const useExecutionStore = defineStore('execution', () => {
     } else instances.value.push(instance)
   }
 
+  /**
+   * Run an action that returns a run's authoritative sub-state and apply that state to the cached
+   * run as an OPTIMISTIC ECHO — but only when the event stream has not delivered a newer revision
+   * while the request was in flight.
+   *
+   * WHY THIS EXISTS. {@link upsert} and {@link hydrate} are monotonic by `rev`, so a stale stream
+   * event can never regress a run. An action store's echo bypassed both: it reached into the cached
+   * instance and assigned `step.forkDecision` / `step.prReview` / `step.judge` / `step.followUps`
+   * directly, with nothing comparing revisions. That is a live-push CLOBBER in its optimistic-echo
+   * form, and it loses state that no later event restores.
+   *
+   * The fork-decision chat is the case that caught it. `chat` records the human turn and wakes the
+   * durable driver, which computes the reply and re-parks — two separate emits. With no model wired
+   * the reply is canned, so the driver routinely emits the two-message thread BEFORE the browser has
+   * even processed the HTTP response carrying the one-message `answering` state. Echoing that
+   * response then dropped the reply back off the thread, permanently: the run is parked, so nothing
+   * emits again. It read as a hung "thinking…" bubble to a user and as a flaky spec in CI.
+   *
+   * The guard is the run's own `rev`, captured BEFORE the request and re-read after. Any advance
+   * means the stream has already delivered this write (or something later), so the echo has nothing
+   * left to add and is skipped. Unchanged means the echo is still the freshest thing available,
+   * which is exactly what it is for. Taking the request as a thunk keeps the capture-then-compare
+   * ordering here rather than at four call sites that each have to remember it.
+   */
+  async function echoAfter<T>(
+    executionId: string,
+    send: () => Promise<T>,
+    apply: (state: T, instance: ExecutionInstance) => void,
+  ): Promise<T> {
+    const before = byId.value.get(executionId)
+    const revBefore = before ? revOf(before) : -1
+    const state = await send()
+    const instance = byId.value.get(executionId)
+    if (!instance || revOf(instance) !== revBefore) return state
+    apply(state, instance)
+    return state
+  }
+
   const byId = computed(() => {
     const map = new Map<string, ExecutionInstance>()
     for (const e of instances.value) map.set(e.id, e)
@@ -248,6 +286,7 @@ export const useExecutionStore = defineStore('execution', () => {
     instances,
     hydrate,
     upsert,
+    echoAfter,
     byId,
     getInstance,
     getByBlock,

package/app/stores/followUps.ts

@@ -33,7 +33,7 @@ export const useFollowUpsStore = defineStore('followUps', () => {
     acting.value = next
   }
 
-  /** Run one decide action, reflecting the returned state onto the run's Coder step. */
+  /** Run one decide action, echoing the returned state onto the run's Coder step. */
   async function act(
     executionId: string,
     itemId: string,
@@ -42,13 +42,19 @@ export const useFollowUpsStore = defineStore('followUps', () => {
     error.value = null
     mark(itemId, true)
     try {
-      const state = await call(workspace.requireId())
-      // Reflect the authoritative state immediately (the stream will also echo it).
-      const instance = execution.getInstance(executionId)
-      const step = instance?.steps.find((s) => s.followUps?.enabled)
-      if (step && state && typeof state === 'object') {
-        step.followUps = state as typeof step.followUps
-      }
+      // Echo the authoritative state immediately (the stream also delivers it), but only when the
+      // stream has not already delivered something NEWER — deciding a follow-up can re-arm the run,
+      // so the driver emits while this response is still in flight. See `execution.echoAfter`.
+      await execution.echoAfter(
+        executionId,
+        () => call(workspace.requireId()),
+        (state, instance) => {
+          const step = instance.steps.find((s) => s.followUps?.enabled)
+          if (step && state && typeof state === 'object') {
+            step.followUps = state as typeof step.followUps
+          }
+        },
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Action failed'
       throw e

package/app/stores/forkDecision.ts

@@ -26,17 +26,20 @@ export const useForkDecisionStore = defineStore('forkDecision', () => {
   const error = ref<string | null>(null)
 
   /**
-   * Reflect an authoritative fork-decision state onto the run's Coder step. A pipeline may
+   * Apply an authoritative fork-decision state to the run's Coder step. A pipeline may
    * carry more than one `coder` step, so target the step this decision is about rather than
    * the first one that happens to hold fork state: prefer the step that is still live
    * (proposing / awaiting the choice / answering), then the current step, and only then fall
-   * back to the first step carrying fork state. The stream corrects any mismatch, but this
-   * keeps the immediate optimistic echo on the right step.
+   * back to the first step carrying fork state.
+   *
+   * Only ever called through {@link ExecutionStore.echoAfter}, which drops the echo when the event
+   * stream already delivered a newer revision — without that guard this assignment silently
+   * regressed the chat thread (see `echoAfter` for the failure it caused).
    */
-  function reflect(executionId: string, state: ForkDecisionStepState | null): void {
-    if (!state) return
-    const instance = execution.getInstance(executionId)
-    if (!instance) return
+  function assign(
+    instance: ReturnType<typeof execution.getInstance> & object,
+    state: ForkDecisionStepState,
+  ): void {
     const isLive = (s: (typeof instance.steps)[number]) =>
       s.agentKind === 'coder' &&
       (s.forkDecision?.status === 'awaiting_choice' ||
@@ -54,8 +57,13 @@ export const useForkDecisionStore = defineStore('forkDecision', () => {
   async function load(executionId: string): Promise<void> {
     error.value = null
     try {
-      const state = await api.getForkDecision(workspace.requireId(), executionId)
-      reflect(executionId, state as ForkDecisionStepState | null)
+      await execution.echoAfter(
+        executionId,
+        () => api.getForkDecision(workspace.requireId(), executionId),
+        (state, instance) => {
+          if (state) assign(instance, state as ForkDecisionStepState)
+        },
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to load'
     }
@@ -72,8 +80,11 @@ export const useForkDecisionStore = defineStore('forkDecision', () => {
     error.value = null
     choosing.value = true
     try {
-      const state = await api.chooseFork(workspace.requireId(), executionId, choice)
-      reflect(executionId, state as ForkDecisionStepState)
+      await execution.echoAfter(
+        executionId,
+        () => api.chooseFork(workspace.requireId(), executionId, choice),
+        (state, instance) => assign(instance, state as ForkDecisionStepState),
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to choose'
       throw e
@@ -85,15 +96,24 @@ export const useForkDecisionStore = defineStore('forkDecision', () => {
   /**
    * Send a grounded chat message about the surfaced forks. The reply is computed inline in the
    * durable driver and arrives via the execution stream; the immediate response is the
-   * `answering` state (the human message already appended), which we reflect so the thread shows
-   * the sent turn + a "thinking…" bubble without waiting for the stream.
+   * `answering` state (the human message already appended), echoed so the thread shows the sent
+   * turn + a "thinking…" bubble without waiting for the stream.
+   *
+   * The echo is the RACIEST one in the app and must stay guarded: `chat` emits the one-message
+   * `answering` state and then wakes the driver, which appends the reply and emits again, so with a
+   * canned (no-model) reply the two-message thread frequently reaches the browser first. Applying
+   * this response unconditionally dropped the reply and left the bubble spinning forever, since a
+   * parked run emits nothing more.
    */
   async function chat(executionId: string, text: string): Promise<void> {
     error.value = null
     chatting.value = true
     try {
-      const state = await api.forkChat(workspace.requireId(), executionId, text)
-      reflect(executionId, state as ForkDecisionStepState)
+      await execution.echoAfter(
+        executionId,
+        () => api.forkChat(workspace.requireId(), executionId, text),
+        (state, instance) => assign(instance, state as ForkDecisionStepState),
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to send message'
       throw e

package/app/stores/judge.ts

@@ -27,13 +27,16 @@ export const useJudgeStore = defineStore('judge', () => {
    * Reflect an authoritative judge state onto the run's judge step. A pipeline may place more
    * than one judge, so target the step this verdict is about rather than the first one holding
    * judge state: prefer the step still awaiting a decision, then the current step, and only then
-   * fall back to the first step carrying judge state. The stream corrects any mismatch; this
-   * keeps the immediate optimistic echo on the right step.
+   * fall back to the first step carrying judge state.
+   *
+   * Only ever called through {@link ExecutionStore.echoAfter}, which drops the echo when the event
+   * stream already delivered a newer revision — a `bounce` re-arms the producing step, so the
+   * driver is emitting fresh state while this response is still in flight.
    */
-  function reflect(executionId: string, state: JudgeStepState | null): void {
-    if (!state) return
-    const instance = execution.getInstance(executionId)
-    if (!instance) return
+  function assign(
+    instance: ReturnType<typeof execution.getInstance> & object,
+    state: JudgeStepState,
+  ): void {
     const current = instance.steps[instance.currentStep]
     const step =
       instance.steps.find((s) => s.judge?.status === 'awaiting_decision') ??
@@ -46,8 +49,13 @@ export const useJudgeStore = defineStore('judge', () => {
   async function load(executionId: string): Promise<void> {
     error.value = null
     try {
-      const state = await api.getJudgeState(workspace.requireId(), executionId)
-      reflect(executionId, state as JudgeStepState | null)
+      await execution.echoAfter(
+        executionId,
+        () => api.getJudgeState(workspace.requireId(), executionId),
+        (state, instance) => {
+          if (state) assign(instance, state as JudgeStepState)
+        },
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to load'
     }
@@ -66,11 +74,15 @@ export const useJudgeStore = defineStore('judge', () => {
     error.value = null
     resolving.value = true
     try {
-      const state = await api.resolveJudge(workspace.requireId(), executionId, {
-        choice,
-        ...(feedback ? { feedback } : {}),
-      })
-      reflect(executionId, state as JudgeStepState)
+      await execution.echoAfter(
+        executionId,
+        () =>
+          api.resolveJudge(workspace.requireId(), executionId, {
+            choice,
+            ...(feedback ? { feedback } : {}),
+          }),
+        (state, instance) => assign(instance, state as JudgeStepState),
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to resolve'
       throw e

package/app/stores/prReview.ts

@@ -20,20 +20,30 @@ export const usePrReviewStore = defineStore('prReview', () => {
 
   /** True while a resolve call is in flight (drives the Finish button spinner / disabled state). */
   const resolving = ref(false)
+  /**
+   * True while a RESUME call is in flight. Kept separate from `resolving` rather than folded into
+   * it: a resume acts during the `reviewing` phase and a resolve during `awaiting_selection`, so
+   * sharing one flag would let either action's spinner appear on the other's controls.
+   */
+  const resuming = ref(false)
   /** The last error message from an action, surfaced inline; cleared on the next action. */
   const error = ref<string | null>(null)
 
   /**
-   * Reflect an authoritative PR-review state onto the run's `pr-reviewer` step. A pipeline could
+   * Apply an authoritative PR-review state to the run's `pr-reviewer` step. A pipeline could
    * carry more than one such step, so target the step this review is about: prefer the step that
    * is still awaiting a selection, then the current step, and only then the first step carrying
-   * review state. The stream corrects any mismatch; this keeps the immediate optimistic echo on
-   * the right step.
+   * review state.
+   *
+   * Only ever called through {@link ExecutionStore.echoAfter}, which drops the echo when the event
+   * stream already delivered a newer revision. `resume` needs that guard most: it returns a
+   * `reviewing` state and then the re-dispatched reviewer starts publishing slice reviews, so an
+   * unguarded echo could put the freshly-captured reports back to what the resume saw.
    */
-  function reflect(executionId: string, state: PrReviewStepState | null): void {
-    if (!state) return
-    const instance = execution.getInstance(executionId)
-    if (!instance) return
+  function assign(
+    instance: ReturnType<typeof execution.getInstance> & object,
+    state: PrReviewStepState,
+  ): void {
     const isLive = (s: (typeof instance.steps)[number]) =>
       s.agentKind === 'pr-reviewer' && s.prReview?.status === 'awaiting_selection'
     const current = instance.steps[instance.currentStep]
@@ -48,8 +58,13 @@ export const usePrReviewStore = defineStore('prReview', () => {
   async function load(executionId: string): Promise<void> {
     error.value = null
     try {
-      const state = await api.getPrReview(workspace.requireId(), executionId)
-      reflect(executionId, state as PrReviewStepState | null)
+      await execution.echoAfter(
+        executionId,
+        () => api.getPrReview(workspace.requireId(), executionId),
+        (state, instance) => {
+          if (state) assign(instance, state as PrReviewStepState)
+        },
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to load'
     }
@@ -69,11 +84,11 @@ export const usePrReviewStore = defineStore('prReview', () => {
     error.value = null
     resolving.value = true
     try {
-      const state = await api.resolvePrReview(workspace.requireId(), executionId, {
-        action,
-        findingIds,
-      })
-      reflect(executionId, state as PrReviewStepState)
+      await execution.echoAfter(
+        executionId,
+        () => api.resolvePrReview(workspace.requireId(), executionId, { action, findingIds }),
+        (state, instance) => assign(instance, state as PrReviewStepState),
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to resolve review'
       throw e
@@ -82,13 +97,38 @@ export const usePrReviewStore = defineStore('prReview', () => {
     }
   }
 
+  /**
+   * Resume a review stuck mid-`reviewing`: the reviewer is re-dispatched for only the slices that
+   * never reported, and the already-captured reports are fed back in so the finished slices are
+   * re-aggregated rather than re-reviewed. Rejected (409) unless the review is still `reviewing`.
+   */
+  async function resume(executionId: string): Promise<void> {
+    error.value = null
+    resuming.value = true
+    try {
+      await execution.echoAfter(
+        executionId,
+        () => api.resumePrReview(workspace.requireId(), executionId),
+        (state, instance) => assign(instance, state as PrReviewStepState),
+      )
+    } catch (e) {
+      error.value = e instanceof Error ? e.message : 'Failed to resume review'
+      throw e
+    } finally {
+      resuming.value = false
+    }
+  }
+
   /** Dismiss a finding entirely: it's removed from the review (and the selection). Stays parked. */
   async function dismiss(executionId: string, findingId: string): Promise<void> {
     error.value = null
     resolving.value = true
     try {
-      const state = await api.dismissPrReviewFinding(workspace.requireId(), executionId, findingId)
-      reflect(executionId, state as PrReviewStepState)
+      await execution.echoAfter(
+        executionId,
+        () => api.dismissPrReviewFinding(workspace.requireId(), executionId, findingId),
+        (state, instance) => assign(instance, state as PrReviewStepState),
+      )
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to dismiss finding'
       throw e
@@ -110,15 +150,14 @@ export const usePrReviewStore = defineStore('prReview', () => {
     error.value = null
     resolving.value = true
     try {
-      const state = await api.challengePrReviewFinding(
-        workspace.requireId(),
+      await execution.echoAfter(
         executionId,
-        findingId,
-        {
-          question,
-        },
+        () =>
+          api.challengePrReviewFinding(workspace.requireId(), executionId, findingId, {
+            question,
+          }),
+        (state, instance) => assign(instance, state as PrReviewStepState),
       )
-      reflect(executionId, state as PrReviewStepState)
     } catch (e) {
       error.value = e instanceof Error ? e.message : 'Failed to challenge finding'
       throw e
@@ -127,5 +166,5 @@ export const usePrReviewStore = defineStore('prReview', () => {
     }
   }
 
-  return { resolving, error, load, resolve, dismiss, challenge }
+  return { resolving, resuming, error, load, resolve, resume, dismiss, challenge }
 })

package/app/utils/pipeline.spec.ts

@@ -1,8 +1,13 @@
 import { describe, expect, it } from 'vitest'
-import { pipelineAllowedForTaskType, purposeAllowsAgentCategory } from '@cat-factory/contracts'
+import {
+  pipelineAllowedForBlockLevel,
+  pipelineAllowedForTaskType,
+  purposeAllowsAgentCategory,
+} from '@cat-factory/contracts'
 import type { Block, Pipeline } from '~/types/domain'
 import {
   pipelineAllowedForManualStart,
+  pipelineAllowedForSchedule,
   pipelineDisplaySteps,
   pipelineGateCount,
 } from '~/utils/pipeline'
@@ -65,13 +70,67 @@ describe('pipelineAllowedForTaskType', () => {
     expect(pipelineAllowedForTaskType(pipeline({ purpose: undefined }), 'review')).toBe(false)
   })
 
-  it('every other task type is unrestricted (any purpose, and undefined type)', () => {
-    for (const type of ['feature', 'bug', 'spike', 'ralph', undefined] as const) {
+  it('a programmatic task (feature / bug) hides only what cannot ship code', () => {
+    // These ship code, so a doc-authoring or PR-review preset is meaningless for them — the mirror
+    // of the narrowing document/review tasks already had. `research` stays because reaching for a
+    // spike before committing to an approach is legitimate on an unscoped feature.
+    for (const type of ['feature', 'bug'] as const) {
       expect(pipelineAllowedForTaskType(pipeline({ purpose: 'build' }), type)).toBe(true)
-      expect(pipelineAllowedForTaskType(pipeline({ purpose: 'document' }), type)).toBe(true)
-      expect(pipelineAllowedForTaskType(pipeline({ purpose: 'review' }), type)).toBe(true)
+      expect(pipelineAllowedForTaskType(pipeline({ purpose: 'research' }), type)).toBe(true)
+      expect(pipelineAllowedForTaskType(pipeline({ purpose: 'document' }), type)).toBe(false)
+      expect(pipelineAllowedForTaskType(pipeline({ purpose: 'review' }), type)).toBe(false)
+      expect(pipelineAllowedForTaskType(pipeline({ purpose: 'planning' }), type)).toBe(false)
+    }
+  })
+
+  it('keeps an UNCLASSIFIED pipeline on a feature / bug task', () => {
+    // The one place this narrowing runs opposite to the document/review one, and it has to: a
+    // `purpose` is optional at every write boundary (the builder leaves it unset by default, a
+    // registered deployment pipeline need not declare one), so requiring it here would hide a
+    // workspace's own hand-built pipelines from the picker they were built for — silently, with
+    // nothing on screen to explain the absence. Unclassified is not known-wrong for a feature the
+    // way a document preset is.
+    for (const type of ['feature', 'bug'] as const) {
       expect(pipelineAllowedForTaskType(pipeline({ purpose: undefined }), type)).toBe(true)
     }
+    // Still hidden from the types whose narrowing DOES demand the explicit classifier.
+    expect(pipelineAllowedForTaskType(pipeline({ purpose: undefined }), 'document')).toBe(false)
+    expect(pipelineAllowedForTaskType(pipeline({ purpose: undefined }), 'review')).toBe(false)
+  })
+
+  it('an un-narrowed task type stays unrestricted (spike, ralph, custom, undefined)', () => {
+    // A custom (namespaced) deployment type has no purpose mapping we could infer, and `spike` /
+    // `ralph` pin their own default pipeline instead of narrowing the picker.
+    for (const type of ['spike', 'ralph', 'acme:incident', undefined] as const) {
+      for (const purpose of ['build', 'document', 'review', 'research', undefined] as const) {
+        expect(pipelineAllowedForTaskType(pipeline({ purpose }), type)).toBe(true)
+      }
+    }
+  })
+})
+
+describe('pipelineAllowedForBlockLevel (initiative binding)', () => {
+  it('offers an initiative block only planning pipelines', () => {
+    expect(pipelineAllowedForBlockLevel(pipeline({ purpose: 'planning' }), 'initiative')).toBe(true)
+    for (const purpose of ['build', 'document', 'review', 'research', undefined] as const) {
+      expect(pipelineAllowedForBlockLevel(pipeline({ purpose }), 'initiative')).toBe(false)
+    }
+  })
+
+  it('hides planning pipelines from every ordinary block level', () => {
+    // The surface half of the engine's BIDIRECTIONAL guard. Without it the planning presets were
+    // offered on ordinary tasks and then refused at start with a 409 — the user having already
+    // chosen before learning it could not run.
+    for (const level of ['task', 'frame', 'module', 'epic'] as const) {
+      expect(pipelineAllowedForBlockLevel(pipeline({ purpose: 'planning' }), level)).toBe(false)
+      expect(pipelineAllowedForBlockLevel(pipeline({ purpose: 'build' }), level)).toBe(true)
+    }
+  })
+
+  it('is unrestricted when the level is unknown', () => {
+    for (const purpose of ['build', 'planning', undefined] as const) {
+      expect(pipelineAllowedForBlockLevel(pipeline({ purpose }), undefined)).toBe(true)
+    }
   })
 })
 
@@ -118,3 +177,24 @@ describe('pipelineAllowedForManualStart composes the task-type gate', () => {
     expect(pipelineAllowedForManualStart(recurring, noFrame, blocks, 'document')).toBe(false)
   })
 })
+
+describe('pipelineAllowedForSchedule', () => {
+  const noFrame = undefined
+  const blocks: Block[] = []
+
+  it('keeps an ordinary build pipeline and drops a one-off-only one', () => {
+    expect(pipelineAllowedForSchedule(pipeline({ purpose: 'build' }), noFrame, blocks)).toBe(true)
+    const oneOff = pipeline({ purpose: 'build', availability: 'one-off' })
+    expect(pipelineAllowedForSchedule(oneOff, noFrame, blocks)).toBe(false)
+  })
+
+  it('drops the planning presets, which nothing else keeps out of this picker', () => {
+    // A schedule seeds a `level: 'task'` block on every fire, so the engine refuses a planning
+    // pipeline exactly as it would on a manual start — and the planning presets carry no
+    // `availability`, so the one-off filter above never touched them. Worse than the manual case
+    // because a schedule fires unattended: nobody sees the refusal, the work just stops happening.
+    expect(pipelineAllowedForSchedule(pipeline({ purpose: 'planning' }), noFrame, blocks)).toBe(
+      false,
+    )
+  })
+})

package/app/utils/pipeline.ts

@@ -1,9 +1,10 @@
 import {
   frameAllowsVisualPipeline,
+  pipelineAllowedForBlockLevel,
   pipelineAllowedForTaskType,
   pipelineHasVisualStep,
 } from '@cat-factory/contracts'
-import type { AgentKind, Block, Pipeline } from '~/types/domain'
+import type { AgentKind, Block, BlockLevel, Pipeline } from '~/types/domain'
 
 /** One agent step of a pipeline as shown in a preview: its kind + whether it's a human-gated step. */
 export interface PipelineDisplayStep {
@@ -38,9 +39,9 @@ export function pipelineGateCount(pipeline: Pipeline): number {
   return pipelineDisplaySteps(pipeline).filter((s) => s.gated).length
 }
 
-// Re-exported so a picker can import the task-type gate from the same module as the
-// launch/frame gates it composes with (the classifier itself lives in `@cat-factory/contracts`).
-export { pipelineAllowedForTaskType }
+// Re-exported so a picker can import the purpose gates from the same module as the launch/frame
+// gates they compose with (the classifiers themselves live in `@cat-factory/contracts`).
+export { pipelineAllowedForBlockLevel, pipelineAllowedForTaskType }
 
 // Surface counterpart to the backend's slice-4c run-start gate: a pipeline with a visual step
 // (`tester-ui` / `visual-confirmation`) may run only on a frame with a UI to exercise — a
@@ -69,32 +70,52 @@ export function pipelineAllowedForFrame(
 
 /**
  * Whether `pipeline` may be started as a MANUAL one-off task run (the board/inspector Run menus,
- * the add-task modal, the task run-settings default). Excludes `'recurring'`-only pipelines the
- * backend would refuse, visual pipelines on a frame with no UI, and — when a `taskType` is given —
- * pipelines whose `purpose` doesn't fit that task type (a `document` task offers only document
- * pipelines). `taskType` omitted ⇒ no task-type restriction (an un-typed context shows all).
+ * the add-task modal, the task run-settings default). Excludes, in turn:
+ *
+ *  - `'recurring'`-only pipelines the backend would refuse;
+ *  - visual pipelines on a frame with no UI;
+ *  - pipelines whose `purpose` doesn't fit the given `taskType` (a `document` task offers only
+ *    document pipelines; a `feature`/`bug` task only build + research ones);
+ *  - pipelines whose `purpose` doesn't fit the given `blockLevel` (planning pipelines run only on
+ *    an initiative block, and an initiative block runs only those).
+ *
+ * `taskType` / `blockLevel` omitted ⇒ that restriction is not applied, so an un-typed context still
+ * shows everything.
  */
 export function pipelineAllowedForManualStart(
   pipeline: Pipeline,
   frame: Block | undefined,
   blocks: readonly Block[],
   taskType?: Block['taskType'],
+  blockLevel?: BlockLevel,
 ): boolean {
   return (
     pipeline.availability !== 'recurring' &&
     pipelineAllowedForFrame(pipeline, frame, blocks) &&
-    pipelineAllowedForTaskType(pipeline, taskType)
+    pipelineAllowedForTaskType(pipeline, taskType) &&
+    pipelineAllowedForBlockLevel(pipeline, blockLevel)
   )
 }
 
 /**
  * Whether `pipeline` may be attached to a RECURRING schedule (the recurring-pipeline modal).
- * Excludes `'one-off'`-only pipelines the backend would refuse.
+ * Excludes `'one-off'`-only pipelines the backend would refuse, visual pipelines on a frame with no
+ * UI, and the planning presets.
+ *
+ * The block-level gate applies here for the same reason it applies to a manual start, and it is
+ * keyed to `'task'` because a schedule seeds a `level: 'task'` block under its frame on every fire
+ * (`RecurringPipelineService`). The planning presets carry no `availability`, so nothing else keeps
+ * them out of this picker — and a schedule the engine refuses is WORSE than a manual start it
+ * refuses: it fires unattended, so nobody sees the error and the work simply never happens.
  */
 export function pipelineAllowedForSchedule(
   pipeline: Pipeline,
   frame: Block | undefined,
   blocks: readonly Block[],
 ): boolean {
-  return pipeline.availability !== 'one-off' && pipelineAllowedForFrame(pipeline, frame, blocks)
+  return (
+    pipeline.availability !== 'one-off' &&
+    pipelineAllowedForFrame(pipeline, frame, blocks) &&
+    pipelineAllowedForBlockLevel(pipeline, 'task')
+  )
 }

package/i18n/locales/de.json

@@ -5660,6 +5660,10 @@
         "pending": "In Warteschlange"
       }
     },
+    "resume": {
+      "action": "Review fortsetzen",
+      "hint": "Hängt es? Beim Fortsetzen werden nur die Abschnitte erneut geprüft, die nie zurückgemeldet haben; die Ergebnisse der fertigen bleiben erhalten."
+    },
     "phase": {
       "planning": "Wird geprüft…",
       "reviewing": "Prüfe {completed}/{total} Abschnitte",

package/i18n/locales/en.json

@@ -5836,6 +5836,10 @@
         "pending": "Queued"
       }
     },
+    "resume": {
+      "action": "Resume review",
+      "hint": "Looks stuck? Resuming re-reviews only the chunks that never came back, and keeps the findings from the ones that did."
+    },
     "phase": {
       "planning": "Reviewing…",
       "reviewing": "Reviewing {completed}/{total} slices",

package/i18n/locales/es.json

@@ -5648,6 +5648,10 @@
         "pending": "En cola"
       }
     },
+    "resume": {
+      "action": "Reanudar la revisión",
+      "hint": "¿Parece atascada? Al reanudar solo se vuelven a revisar los fragmentos que nunca respondieron y se conservan los hallazgos de los ya terminados."
+    },
     "phase": {
       "planning": "Revisando…",
       "reviewing": "Revisando {completed}/{total} secciones",

package/i18n/locales/fr.json

@@ -5648,6 +5648,10 @@
         "pending": "En attente"
       }
     },
+    "resume": {
+      "action": "Reprendre la revue",
+      "hint": "Elle semble bloquée ? La reprise ne réexamine que les sections qui n’ont jamais répondu et conserve les constats de celles déjà terminées."
+    },
     "phase": {
       "planning": "Révision…",
       "reviewing": "Révision {completed}/{total} sections",

package/i18n/locales/he.json

@@ -5659,6 +5659,10 @@
         "pending": "בתור"
       }
     },
+    "resume": {
+      "action": "המשך סקירה",
+      "hint": "נראה שנתקע? המשך יבדוק מחדש רק את המקטעים שלא חזרו, וישמור את הממצאים של אלה שכבר הושלמו."
+    },
     "phase": {
       "planning": "בודק…",
       "reviewing": "בודק {completed}/{total} מקטעים",

package/i18n/locales/it.json

@@ -5660,6 +5660,10 @@
         "pending": "In coda"
       }
     },
+    "resume": {
+      "action": "Riprendi la revisione",
+      "hint": "Sembra bloccata? La ripresa riesamina solo i blocchi che non hanno mai risposto e conserva i rilievi di quelli già completati."
+    },
     "phase": {
       "planning": "Revisione…",
       "reviewing": "Revisione {completed}/{total} sezioni",

package/i18n/locales/ja.json

@@ -5660,6 +5660,10 @@
         "pending": "待機中"
       }
     },
+    "resume": {
+      "action": "レビューを再開",
+      "hint": "停止しているように見えますか？再開すると、応答がなかったチャンクだけを再レビューし、完了済みチャンクの指摘はそのまま引き継ぎます。"
+    },
     "phase": {
       "planning": "レビュー中…",
       "reviewing": "レビュー中 {completed}/{total} 区分",

package/i18n/locales/pl.json

@@ -5648,6 +5648,10 @@
         "pending": "W kolejce"
       }
     },
+    "resume": {
+      "action": "Wznów przegląd",
+      "hint": "Wygląda na zawieszony? Wznowienie sprawdza ponownie tylko te fragmenty, które nigdy nie odpowiedziały, i zachowuje ustalenia z już ukończonych."
+    },
     "phase": {
       "planning": "Przegląd…",
       "reviewing": "Przegląd {completed}/{total} fragmentów",

package/i18n/locales/tr.json

@@ -5660,6 +5660,10 @@
         "pending": "Sırada"
       }
     },
+    "resume": {
+      "action": "İncelemeyi sürdür",
+      "hint": "Takılmış gibi mi görünüyor? Sürdürme yalnızca hiç yanıt vermeyen parçaları yeniden inceler ve tamamlananların bulgularını korur."
+    },
     "phase": {
       "planning": "İnceleniyor…",
       "reviewing": "İnceleniyor {completed}/{total} bölüm",

package/i18n/locales/uk.json

@@ -5648,6 +5648,10 @@
         "pending": "У черзі"
       }
     },
+    "resume": {
+      "action": "Відновити рецензування",
+      "hint": "Схоже, що зависло? Відновлення повторно перевіряє лише ті фрагменти, які не відповіли, і зберігає висновки вже завершених."
+    },
     "phase": {
       "planning": "Перевірка…",
       "reviewing": "Перевірка {completed}/{total} фрагментів",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cat-factory/app",
-  "version": "0.191.0",
+  "version": "0.193.0",
   "description": "Reusable Nuxt layer for the Agent Architecture Board SPA (components, stores, composables, pages). Consume it from a thin deployment app via `extends: ['@cat-factory/app']` and point it at your backend with NUXT_PUBLIC_API_BASE. See deploy/frontend for an example.",
   "repository": {
     "type": "git",
@@ -40,7 +40,7 @@
     "valibot": "^1.4.2",
     "vue": "3.5.40",
     "wretch": "^3.0.9",
-    "@cat-factory/contracts": "0.198.0"
+    "@cat-factory/contracts": "0.200.0"
   },
   "devDependencies": {
     "@toad-contracts/testing": "0.3.2",