@cat-factory/app 0.294.0 → 0.296.0

package/app/components/board/AgentFailureCard.vue

@@ -7,6 +7,7 @@
 import type { ConflictReason, EnvironmentFailureReason } from '@cat-factory/contracts'
 import type { AgentRunSummary } from '~/stores/agentRuns'
 import FailureDetail from '~/components/board/FailureDetail.vue'
+import BootstrapRunSteps from '~/components/bootstrap/BootstrapRunSteps.vue'
 
 const props = withDefaults(
   defineProps<{ run: AgentRunSummary; variant?: 'compact' | 'expanded' }>(),
@@ -92,9 +93,29 @@ const title = computed(() => {
     ? t('board.failure.bootstrapFailed')
     : t('board.failure.runFailed')
 })
-const retryLabel = computed(() =>
-  props.run.kind === 'bootstrap' ? t('board.failure.retryBootstrap') : t('board.failure.retryRun'),
+// A MULTI-STEP bootstrap (the monorepo flow) is not retried from the top: the service resumes
+// from the step the run reached, keeping the survey's paid-for reads and, past the review, the
+// decisions a human already gave. So the button says which step it re-enters at, from the SAME
+// rule the service branches on, rather than "retry", which invites the reviewer to expect to be
+// asked for their decisions again. A single-step run has nothing to resume and keeps "retry".
+const { resumeStep } = useBootstrapRunSteps(() =>
+  props.run.kind === 'bootstrap' ? props.run.runId : null,
 )
+const retryLabel = computed(() => {
+  if (props.run.kind !== 'bootstrap') return t('board.failure.retryRun')
+  const step = resumeStep.value
+  return step
+    ? t('board.failure.resumeBootstrap', { step: t(`bootstrap.steps.name.${step}`) })
+    : t('board.failure.retryBootstrap')
+})
+
+// The run's own observability panel. Offered here because a failed BOOTSTRAP has no step surface
+// to reach it from (a task run's steps each carry their own "Model activity" control), and what
+// a bootstrap failed on is exactly the question its model calls, provided context and tool-call
+// trajectory answer.
+function inspectRun() {
+  ui.openObservability(props.run.runId)
+}
 
 const retrying = ref(false)
 async function retry() {
@@ -159,6 +180,14 @@ async function retry() {
       }}
     </p>
 
+    <!-- Which of the run's steps it got to. Renders for a multi-step (monorepo) bootstrap only;
+         see BootstrapRunSteps. -->
+    <BootstrapRunSteps
+      v-if="!compact && run.kind === 'bootstrap'"
+      :run-id="run.runId"
+      class="mt-2"
+    />
+
     <FailureDetail
       v-if="!compact && failure"
       :detail="failure.detail"
@@ -184,6 +213,18 @@ async function retry() {
         {{ retrying ? t('board.failure.retrying') : compact ? t('common.retry') : retryLabel }}
       </button>
 
+      <button
+        v-if="run.kind === 'bootstrap'"
+        type="button"
+        class="nodrag flex items-center gap-1 rounded-md bg-rose-900/20 text-rose-300 hover:bg-rose-900/50"
+        :class="compact ? 'px-2 py-0.5 text-[10px]' : 'px-2 py-1 text-[11px]'"
+        data-testid="agent-failure-inspect"
+        @click.stop="inspectRun"
+      >
+        <UIcon name="i-lucide-activity" :class="compact ? 'h-3 w-3' : 'h-3.5 w-3.5'" />
+        {{ t('observability.modelActivity') }}
+      </button>
+
       <!-- Environment provisioning failures are almost always a deploy-backend / provider-config
            issue, so link straight to where it's set up rather than leaving the user to hunt. The
            destination + label follow the cause: a `deploy_runner_unwired` failure needs the runner

package/app/components/board/nodes/BlockNode.vue

@@ -8,6 +8,7 @@ import ResizeGrips from './ResizeGrips.vue'
 import AgentFailureCard from '~/components/board/AgentFailureCard.vue'
 import AgentStopButton from '~/components/board/AgentStopButton.vue'
 import AdoptionReviewModal from '~/components/bootstrap/AdoptionReviewModal.vue'
+import BootstrapRunSteps from '~/components/bootstrap/BootstrapRunSteps.vue'
 import { useBlockDrag } from '~/composables/useBlockDrag'
 import { useFrameStacking } from '~/composables/useFrameStacking'
 import { useViewport } from '~/composables/useViewport'
@@ -346,7 +347,21 @@ const ITEM_ICON: Record<string, string> = {
             <span>{{ item.label }}</span>
           </li>
         </ul>
-        <div v-if="run" class="mt-2 flex justify-end">
+        <!-- Which of the run's own steps it is on. A monorepo bootstrap is three moves around a
+             human decision, and the bar above reports only the current container's todo list, so
+             without this the card cannot say whether the survey, the review or the write is what
+             is happening. Renders nothing for a one-step new-repo run. -->
+        <BootstrapRunSteps v-if="run" :run-id="run.runId" class="mt-2" />
+        <div v-if="run" class="mt-2 flex items-center justify-end gap-1.5">
+          <UButton
+            size="xs"
+            color="neutral"
+            variant="ghost"
+            icon="i-lucide-activity"
+            @click.stop="ui.openObservability(run.runId)"
+          >
+            {{ t('observability.modelActivity') }}
+          </UButton>
           <AgentStopButton :run-id="run.runId" :kind="run.kind" size="xs" variant="ghost" />
         </div>
       </div>
@@ -359,6 +374,7 @@ const ITEM_ICON: Record<string, string> = {
           <UIcon name="i-lucide-user-check" class="mt-0.5 h-4 w-4 shrink-0 text-amber-400" />
           <p class="text-xs text-amber-200/90">{{ t('bootstrap.adoption.cardPrompt') }}</p>
         </div>
+        <BootstrapRunSteps :run-id="awaitingReview.id" />
         <div class="flex justify-end">
           <UButton size="xs" color="warning" variant="subtle" @click.stop="reviewOpen = true">
             {{ t('bootstrap.adoption.cardAction') }}

package/app/components/bootstrap/BootstrapModal.logic.spec.ts

@@ -1,5 +1,6 @@
 import { describe, expect, it } from 'vitest'
 import {
+  defaultBootstrapDelivery,
   serviceDirectoryLeaf,
   serviceDirectoryParent,
 } from '~/components/bootstrap/BootstrapModal.logic'
@@ -41,3 +42,13 @@ describe('serviceDirectoryParent', () => {
     expect(serviceDirectoryParent('')).toBe('')
   })
 })
+
+describe('defaultBootstrapDelivery', () => {
+  it('reviews a monorepo and pushes a repository being created', () => {
+    // The form has to SHOW the default it is about to send, and the two targets want opposite
+    // ones, so a constant would render the wrong answer for one of them and ask the person to
+    // correct a choice they never made. Same rule the backend applies to a request naming none.
+    expect(defaultBootstrapDelivery(true)).toBe('pull_request')
+    expect(defaultBootstrapDelivery(false)).toBe('direct_push')
+  })
+})

package/app/components/bootstrap/BootstrapModal.logic.ts

@@ -1,3 +1,4 @@
+import type { BootstrapDelivery } from '~/types/domain'
 import { repoPathSegments } from '~/utils/repoPath'
 
 // The pure half of the bootstrap launch form's monorepo service-directory field. That field
@@ -26,3 +27,18 @@ export function serviceDirectoryLeaf(directory: string, serviceName: string): st
 export function serviceDirectoryParent(directory: string): string {
   return repoPathSegments(directory).slice(0, -1).join('/')
 }
+
+/**
+ * The delivery a target takes when nobody has answered the question.
+ *
+ * The backend applies the same rule for a request that names none, and it is stated on both
+ * sides deliberately: the form has to SHOW the default it is about to send, and a control
+ * rendering the wrong one asks the person to correct something they never chose. The two targets
+ * want opposite answers, which is why it is a function of the target rather than a constant.
+ *
+ * Also what the form RESETS to after a launch: an explicit choice binds the run it was made for,
+ * never every later one, so the reset restores the default for whatever target is still selected.
+ */
+export function defaultBootstrapDelivery(intoMonorepo: boolean): BootstrapDelivery {
+  return intoMonorepo ? 'pull_request' : 'direct_push'
+}

package/app/components/bootstrap/BootstrapModal.vue

@@ -4,8 +4,14 @@
 // adapt it (in a sandbox container) — either by cloning a chosen reference
 // architecture, or from scratch following a freeform prompt. The modal pairs the
 // launch form with the managed base list.
-import type { BootstrapStatus, FrameRepoType, ReferenceArchitecture } from '~/types/domain'
+import type {
+  BootstrapDelivery,
+  BootstrapStatus,
+  FrameRepoType,
+  ReferenceArchitecture,
+} from '~/types/domain'
 import {
+  defaultBootstrapDelivery,
   serviceDirectoryLeaf,
   serviceDirectoryParent,
 } from '~/components/bootstrap/BootstrapModal.logic'
@@ -105,6 +111,42 @@ const targetItems = computed(() => [
 ])
 const intoMonorepo = computed(() => target.value === 'monorepo')
 
+// ---- how the work LANDS ----------------------------------------------------
+// A third axis, orthogonal to both of the above: the same service, written the same way, either
+// arrives as a pull request somebody reviews or straight on the default branch. The two targets
+// want opposite defaults (a repository being created has nobody to review its first commit; a
+// monorepo's default branch is the branch every other service builds from), which is exactly why
+// this is a control and not a constant.
+const delivery = ref<BootstrapDelivery>(defaultBootstrapDelivery(false))
+// Whether the person has answered this question themselves. Until they have, switching target
+// re-defaults; once they have, their answer stands, because re-defaulting over an explicit
+// choice is how a run they asked to review lands unreviewed. Cleared after a launch, so the
+// answer binds the run it was given for rather than every later one (see `launch`).
+const deliveryTouched = ref(false)
+watch(intoMonorepo, (into) => {
+  if (!deliveryTouched.value) delivery.value = defaultBootstrapDelivery(into)
+})
+function chooseDelivery(value: BootstrapDelivery) {
+  deliveryTouched.value = true
+  delivery.value = value
+}
+const deliveryItems = computed(() => [
+  {
+    label: t('bootstrap.delivery.pullRequest.label'),
+    value: 'pull_request' as const,
+    description: intoMonorepo.value
+      ? t('bootstrap.delivery.pullRequest.descMonorepo')
+      : t('bootstrap.delivery.pullRequest.descNewRepo'),
+  },
+  {
+    label: t('bootstrap.delivery.directPush.label'),
+    value: 'direct_push' as const,
+    description: intoMonorepo.value
+      ? t('bootstrap.delivery.directPush.descMonorepo')
+      : t('bootstrap.delivery.directPush.descNewRepo'),
+  },
+])
+
 /** The projected repo the new service lands in, by numeric id. */
 const monorepoRepoId = ref<number | undefined>(undefined)
 const monorepoDirectory = ref('')
@@ -323,6 +365,7 @@ async function launch() {
       private: isPrivate.value,
       instructions: instructions.value.trim(),
       type: selectedType.value,
+      delivery: delivery.value,
       ...(intoMonorepo.value && monorepoRepoId.value
         ? {
             monorepo: {
@@ -363,6 +406,12 @@ async function launch() {
       browsingDirectory.value = false
       // Reset the repo role too, so a later bootstrap doesn't silently inherit this one's type.
       selectedType.value = 'service'
+      // And the delivery, which has to reset the ANSWERED flag with it: leaving that set disarms
+      // the per-target default for good, so a "push directly" picked deliberately for one
+      // monorepo would go on governing the next bootstrap, into a different repository, without
+      // the person having been asked about that one. Back to the current target's own default.
+      deliveryTouched.value = false
+      delivery.value = defaultBootstrapDelivery(intoMonorepo.value)
       // The provisional frame arrived (bootstrap() refreshed the board). Re-home it to
       // free space so it never overlaps an existing service — the backend places it on a
       // fixed diagonal stagger that can land on top of a large neighbour — then centre the
@@ -553,6 +602,17 @@ const statusLabel = computed<Record<BootstrapStatus, string>>(() => ({
             <URadioGroup v-model="target" :items="targetItems" />
           </UFormField>
 
+          <!-- Where the service goes and how it gets there are two questions, and the second
+               has no answer that is right for both targets. Its descriptions therefore change
+               with the target rather than the control being duplicated per target. -->
+          <UFormField :label="t('bootstrap.delivery.label')" required>
+            <URadioGroup
+              :model-value="delivery"
+              :items="deliveryItems"
+              @update:model-value="chooseDelivery($event as BootstrapDelivery)"
+            />
+          </UFormField>
+
           <!-- Landing in an existing monorepo: pick the repository and the subdirectory. The
                run surveys the monorepo's conventions against the template's and PARKS for a
                human adoption review before it writes anything. -->
@@ -800,6 +860,18 @@ const statusLabel = computed<Record<BootstrapStatus, string>>(() => ({
               >
                 {{ t('bootstrap.recent.open') }}
               </ULink>
+              <!-- The deliverable of a `pull_request` run, and the only thing it produced that
+                   the user still has to act on. A monorepo run has no `repoUrl` at all, so
+                   without this the run's whole output is unreachable from the list that
+                   offered the choice. -->
+              <ULink
+                v-if="job.prUrl"
+                :to="job.prUrl"
+                target="_blank"
+                class="text-[11px] text-indigo-400 hover:underline"
+              >
+                {{ t('bootstrap.recent.openPr') }}
+              </ULink>
               <UBadge :color="statusColor[job.status]" variant="subtle" size="sm">
                 {{ statusLabel[job.status] }}
               </UBadge>

package/app/components/bootstrap/BootstrapRunSteps.vue

@@ -0,0 +1,50 @@
+<script setup lang="ts">
+// The steps a bootstrap run is made of, with the one it reached marked.
+//
+// A monorepo bootstrap is three moves around a human decision (survey → your adoption
+// decisions → write the service and open the PR), and it was rendered as a single
+// "bootstrapping…" bar. That bar cannot say which move a stopped run got to, so "retry" read
+// as "start the whole thing again" when what the platform actually does is resume from the
+// step reached, the survey's paid-for reads and the reviewer's settled decisions included.
+//
+// The steps and their states come from `@cat-factory/contracts`, which is also what
+// `BootstrapService.retry` branches on: the label on the button and the behaviour behind it
+// are one rule, not two. How a state RENDERS is `BOOTSTRAP_STEP_STYLE`, beside the vocabulary
+// it is keyed by.
+import type { BootstrapStepId, BootstrapStepState } from '@cat-factory/contracts'
+
+const props = defineProps<{ runId: string }>()
+
+const { t } = useI18n()
+// A ONE-step run renders nothing: a new-repo bootstrap is a single move, which the banner around
+// this already names, and a one-row checklist restating it is noise rather than information.
+const { steps: allSteps, multiStep } = useBootstrapRunSteps(() => props.runId)
+const steps = computed(() => (multiStep.value ? allSteps.value : []))
+
+function stepLabel(id: BootstrapStepId): string {
+  return t(`bootstrap.steps.name.${id}`)
+}
+function stateLabel(state: BootstrapStepState): string {
+  return t(`bootstrap.steps.state.${state}`)
+}
+</script>
+
+<template>
+  <ol v-if="steps.length" class="space-y-1" data-testid="bootstrap-run-steps">
+    <li
+      v-for="step in steps"
+      :key="step.id"
+      class="flex items-start gap-1.5 text-[11px]"
+      :data-step="step.id"
+      :data-state="step.state"
+    >
+      <UIcon
+        :name="BOOTSTRAP_STEP_STYLE[step.state].icon"
+        class="mt-px h-3 w-3 shrink-0"
+        :class="BOOTSTRAP_STEP_STYLE[step.state].iconClass"
+      />
+      <span :class="BOOTSTRAP_STEP_STYLE[step.state].labelClass">{{ stepLabel(step.id) }}</span>
+      <span class="ms-auto shrink-0 text-slate-500">{{ stateLabel(step.state) }}</span>
+    </li>
+  </ol>
+</template>

package/app/components/panels/InspectorPanel.vue

@@ -7,6 +7,7 @@ import { inspectorPanels } from '~/modular/panels/inspector.logic'
 import IconButton from '~/components/common/IconButton.vue'
 import AgentFailureCard from '~/components/board/AgentFailureCard.vue'
 import AgentStopButton from '~/components/board/AgentStopButton.vue'
+import BootstrapRunSteps from '~/components/bootstrap/BootstrapRunSteps.vue'
 import { BLUEPRINT_AGENT_KIND } from '@cat-factory/contracts'
 import { VCS_PROVIDER_ICONS } from '~/utils/vcs'
 
@@ -489,16 +490,33 @@ const showOriginalDescription = ref(false)
       <!-- failed run (bootstrap or execution): shared failure banner + retry -->
       <AgentFailureCard v-if="failedRun" :run="failedRun" />
 
-      <!-- running bootstrap: let the user stop it (kills the container) -->
+      <!-- running bootstrap: show the steps, let the user inspect it, let them stop it -->
       <div
         v-else-if="runningRun"
-        class="flex items-center justify-between gap-2 rounded-lg border border-amber-900/60 bg-amber-950/30 px-3 py-2"
+        class="space-y-2 rounded-lg border border-amber-900/60 bg-amber-950/30 px-3 py-2"
       >
-        <span class="flex items-center gap-1.5 text-xs text-amber-300">
-          <UIcon name="i-lucide-loader-circle" class="h-3.5 w-3.5 animate-spin" />
-          {{ t('panels.inspector.bootstrapping') }}
-        </span>
-        <AgentStopButton :run-id="runningRun.runId" :kind="runningRun.kind" size="xs" />
+        <div class="flex items-center justify-between gap-2">
+          <span class="flex items-center gap-1.5 text-xs text-amber-300">
+            <UIcon name="i-lucide-loader-circle" class="h-3.5 w-3.5 animate-spin" />
+            {{ t('panels.inspector.bootstrapping') }}
+          </span>
+          <div class="flex items-center gap-1.5">
+            <!-- A bootstrap has no step surface of its own, so this is where its run details are
+                 reached from: the same panel every task run opens, over the same four sinks. -->
+            <UButton
+              v-if="runningRun.kind === 'bootstrap'"
+              size="xs"
+              color="neutral"
+              variant="ghost"
+              icon="i-lucide-activity"
+              @click="ui.openObservability(runningRun.runId)"
+            >
+              {{ t('observability.modelActivity') }}
+            </UButton>
+            <AgentStopButton :run-id="runningRun.runId" :kind="runningRun.kind" size="xs" />
+          </div>
+        </div>
+        <BootstrapRunSteps v-if="runningRun.kind === 'bootstrap'" :run-id="runningRun.runId" />
       </div>
 
       <!-- external links -->

package/app/components/panels/ObservabilityPanel.vue

@@ -50,13 +50,30 @@ const EMPTY_TRAJECTORY: RunToolCallTrajectory = Object.freeze({
 const ui = useUiStore()
 const execution = useExecutionStore()
 const board = useBoardStore()
+const agentRuns = useAgentRunsStore()
 const observability = useObservabilityStore()
 const { t, d } = useI18n()
 
 const executionId = computed(() => ui.observabilityInstanceId)
 const open = computed(() => !!executionId.value)
 const instance = computed(() => execution.getInstance(executionId.value ?? undefined))
-const block = computed(() => (instance.value ? board.getBlock(instance.value.blockId) : undefined))
+// The panel is opened over an AGENT RUN, and a repo bootstrap is one: it has no execution row,
+// so everything below that reads `instance` answers nothing for it. Its own run supplies the two
+// things the panel states about a run rather than about its calls: whose work this was, and what
+// it failed on. The four telemetry reads need none of it: they are keyed by the run id alone.
+const bootstrap = computed(() => agentRuns.bootstrapById(executionId.value))
+const blockId = computed(() => instance.value?.blockId ?? bootstrap.value?.blockId ?? null)
+const block = computed(() => (blockId.value ? board.getBlock(blockId.value) : undefined))
+/**
+ * The line under the title. An execution names its pipeline; a bootstrap names itself, because
+ * "which pipeline" has no answer for it and an empty subtitle on a panel opened from a service
+ * card reads as a panel that failed to load rather than as a run of a different kind.
+ */
+const runSubtitle = computed(() =>
+  instance.value ? instance.value.pipelineName : bootstrap.value ? t('bootstrap.runKind') : '',
+)
+/** The structured failure the pinned summary speaks from, whichever kind of run this is. */
+const runFailure = computed(() => instance.value?.failure ?? bootstrap.value?.failure ?? null)
 
 const calls = computed<LlmCallMetric[]>(() =>
   executionId.value ? observability.callsFor(executionId.value) : [],
@@ -201,7 +218,7 @@ const visibleCalls = computed(() => filterCallsByOutcome(calls.value, callFilter
  */
 const failureEvidence = computed(() =>
   deriveRunFailureEvidence({
-    failure: instance.value?.failure ?? null,
+    failure: runFailure.value,
     calls: calls.value,
     callsAnswer: sinkAnswer({
       loading: loading.value,
@@ -357,7 +374,19 @@ function sum(items: LlmCallMetric[], pick: (m: LlmCallMetric) => number): number
 
 // Where the run's tokens went, by PHASE. Unlike the totals above (derived from the capped call
 // list), this reads the engine's SQL rollup off the steps, so it stays honest on a long run.
-const phaseRows = computed(() => foldRunPhaseMetrics(instance.value?.steps ?? []))
+//
+// A run with NO execution row (a repo bootstrap) has no steps to fold one from, which is a
+// different fact from a run whose phases each spent nothing, and the difference matters here
+// more than anywhere: this rollup is also what prices the run, so left as an empty list it hides
+// both the table and the cost tile, and a bootstrap that made N model calls reads as one that
+// cost nothing. Stated as its own answer, and rendered as a note.
+const phaseRollup = computed<{ available: boolean; rows: ReturnType<typeof foldRunPhaseMetrics> }>(
+  () =>
+    instance.value
+      ? { available: true, rows: foldRunPhaseMetrics(instance.value.steps ?? []) }
+      : { available: false, rows: [] },
+)
+const phaseRows = computed(() => phaseRollup.value.rows)
 const phaseCarryTotal = computed(() =>
   phaseRows.value.reduce((acc, p) => acc + p.carryCostTokens, 0),
 )
@@ -391,6 +420,18 @@ const showCost = computed(
 const runCost = computed(() =>
   formatCost(sumCosts(phaseRows.value.map((p) => p.costEstimate)), costCurrency.value),
 )
+/**
+ * What the cost tile SAYS when it shows no figure. An unpriced phase and a run kind with no
+ * rollup to price from are different facts, and the tile is rendered for the second one rather
+ * than dropped: a missing tile is indistinguishable from a run that cost nothing.
+ */
+const costNoteKey = computed(() =>
+  !phaseRollup.value.available
+    ? 'observability.summary.costNoRollup'
+    : runCost.value
+      ? 'observability.summary.costHint'
+      : 'observability.summary.costIncomplete',
+)
 /** Share of the run's carry cost a phase accounts for (0..100), or null when nothing carried. */
 function carryShare(carryCostTokens: number): number | null {
   return phaseCarryTotal.value > 0 ? pct(carryCostTokens / phaseCarryTotal.value) : null
@@ -473,7 +514,7 @@ function exportJson() {
               {{ t('observability.modelActivity') }}
             </h1>
             <p v-if="block" class="truncate text-xs text-slate-500">
-              {{ block.title }} · {{ instance?.pipelineName }}
+              {{ block.title }} · {{ runSubtitle }}
             </p>
           </div>
           <div class="ms-auto flex items-center gap-1.5">
@@ -569,18 +610,14 @@ function exportJson() {
                   </dt>
                   <dd class="mt-0.5 tabular-nums text-slate-200">{{ totals.calls }}</dd>
                 </div>
-                <div v-if="showCost">
+                <div v-if="showCost || !phaseRollup.available">
                   <dt class="text-[11px] uppercase tracking-wide text-slate-500">
                     {{ t('observability.summary.cost') }}
                   </dt>
                   <dd class="mt-0.5 tabular-nums text-slate-200">
                     {{ runCost ?? '—' }}
                     <span class="mt-0.5 block text-[11px] text-slate-500">
-                      {{
-                        runCost
-                          ? t('observability.summary.costHint')
-                          : t('observability.summary.costIncomplete')
-                      }}
+                      {{ t(costNoteKey) }}
                     </span>
                   </dd>
                 </div>
@@ -683,18 +720,23 @@ function exportJson() {
             <!-- where the run's tokens went, by phase (the engine's SQL rollup, not the
                  capped call list) -->
             <section
-              v-if="phaseRows.length"
+              v-if="phaseRows.length || !phaseRollup.available"
               class="rounded-xl border border-slate-800 bg-slate-900/50 p-4"
             >
               <div class="flex items-baseline gap-2">
                 <h2 class="text-[11px] uppercase tracking-wide text-slate-500">
                   {{ t('observability.phase.title') }}
                 </h2>
-                <span class="text-[11px] text-slate-600">
+                <span v-if="phaseRollup.available" class="text-[11px] text-slate-600">
                   {{ t('observability.phase.subtitle') }}
                 </span>
               </div>
-              <div class="mt-3 overflow-x-auto">
+              <!-- No rollup to fold: said in words, because an absent table and a run that spent
+                   nothing look identical, and the calls listed above prove it spent something. -->
+              <p v-if="!phaseRollup.available" class="mt-2 text-[12px] text-slate-400">
+                {{ t('observability.phase.noRollup') }}
+              </p>
+              <div v-else class="mt-3 overflow-x-auto">
                 <table class="w-full min-w-[32rem] text-[12px]">
                   <thead>
                     <tr class="text-[11px] uppercase tracking-wide text-slate-500">
@@ -998,6 +1040,17 @@ function exportJson() {
               @show-failing-tools="revealFailingToolCalls"
               @retry="retryFailureEvidence"
             />
+            <!-- A monorepo bootstrap's SURVEY explores through the platform's own bounded reader,
+                 whose every read lands on the run's adoption transcript rather than here (that is
+                 the record a reviewer checks a recommendation against, and it outlives this
+                 window). Said out loud because the apply container's calls below are not empty,
+                 so the survey's absence would otherwise read as a phase that used no tools. -->
+            <p
+              v-if="bootstrap?.monorepo"
+              class="rounded-lg border border-dashed border-slate-800 px-3 py-2 text-[12px] text-slate-400"
+            >
+              {{ t('observability.toolCalls.surveyReadsElsewhere') }}
+            </p>
             <ToolCallList
               v-model:filter="toolFilter"
               :trajectory="trajectory"

package/app/composables/useBootstrapRunSteps.spec.ts

@@ -0,0 +1,131 @@
+import { describe, it, expect, beforeEach } from 'vitest'
+import type { BootstrapJob } from '~/types/domain'
+import { useAgentRunsStore } from '~/stores/agentRuns'
+import { useBootstrapRunSteps } from '~/composables/useBootstrapRunSteps'
+
+// What this composable owns beyond the shared derivation (tested in `@cat-factory/contracts`):
+// the SPA-only question of whether a run has more than one step, which is what decides whether
+// the board renders a step list at all and whether the retry control offers to RESUME.
+
+const MONOREPO: BootstrapJob['monorepo'] = {
+  repoGithubId: 7,
+  directory: 'services/payments',
+  repoOwner: 'acme',
+  repoName: 'platform',
+  branch: null,
+}
+
+function job(id: string, over: Partial<BootstrapJob> = {}): BootstrapJob {
+  return {
+    id,
+    workspaceId: 'ws_test',
+    referenceArchitectureId: null,
+    referenceArchitectureName: null,
+    repoName: id,
+    repoOwner: null,
+    repoUrl: null,
+    instructions: '',
+    status: 'running',
+    blockId: `blk_${id}`,
+    subtasks: null,
+    error: null,
+    failure: null,
+    monorepo: null,
+    phase: null,
+    // The base fixture is a new-repo run, so it takes that target's default delivery. The step
+    // rule never reads the field, which is why no case below overrides it: how a run's work
+    // lands says nothing about how many moves it takes to get there.
+    delivery: 'direct_push',
+    adoptionPlan: null,
+    adoptionReview: null,
+    prUrl: null,
+    createdAt: 1,
+    updatedAt: 1,
+    ...over,
+  }
+}
+
+/** A recorded plan; only its own status is read by the rule. */
+function plan(status: 'ready' | 'unavailable'): BootstrapJob['adoptionPlan'] {
+  return { status } as unknown as BootstrapJob['adoptionPlan']
+}
+
+describe('useBootstrapRunSteps', () => {
+  let store: ReturnType<typeof useAgentRunsStore>
+  beforeEach(() => {
+    store = useAgentRunsStore()
+  })
+
+  it('offers nothing for a new-repo run, which has one move and so nothing to resume', () => {
+    store.upsertBootstrap(job('b1', { status: 'failed' }))
+    const { multiStep, resumeStep } = useBootstrapRunSteps('b1')
+    expect(multiStep.value).toBe(false)
+    // Null rather than 'scaffold': there is progress to keep on a monorepo run and none here,
+    // so the card must keep saying "retry" instead of promising a resume it cannot make.
+    expect(resumeStep.value).toBeNull()
+  })
+
+  it('marks the survey done and the review as the step a broken monorepo run is holding', () => {
+    store.upsertBootstrap(
+      job('b2', {
+        monorepo: MONOREPO,
+        phase: 'survey',
+        status: 'failed',
+        failure: { kind: 'agent' } as unknown as BootstrapJob['failure'],
+        adoptionPlan: plan('ready'),
+      }),
+    )
+    const { steps, multiStep, resumeStep } = useBootstrapRunSteps('b2')
+    expect(multiStep.value).toBe(true)
+    expect(steps.value).toEqual([
+      { id: 'survey', state: 'done' },
+      { id: 'review', state: 'failed' },
+      { id: 'apply', state: 'pending' },
+    ])
+    expect(resumeStep.value).toBe('review')
+  })
+
+  it('renders a run the reviewer STOPPED as stopped, not as a broken review step', () => {
+    // A stop is stored as a `failed` status with a `cancelled` kind, and this is the shape the
+    // card actually renders: stopping a parked run must not report the reviewer's own decision
+    // step back to them as a fault. The resume it offers is unchanged.
+    store.upsertBootstrap(
+      job('b2s', {
+        monorepo: MONOREPO,
+        phase: 'survey',
+        status: 'failed',
+        failure: { kind: 'cancelled' } as unknown as BootstrapJob['failure'],
+        adoptionPlan: plan('ready'),
+      }),
+    )
+    const { steps, resumeStep } = useBootstrapRunSteps('b2s')
+    expect(steps.value.map((step) => step.state)).toEqual(['done', 'stopped', 'pending'])
+    expect(resumeStep.value).toBe('review')
+  })
+
+  it('follows the run as live events advance it, rather than pinning the first read', () => {
+    // The card is open while the run moves: the review is settled and the apply dispatches, and
+    // the step list has to follow the store rather than the value it was mounted with.
+    store.upsertBootstrap(job('b3', { monorepo: MONOREPO, phase: 'survey', updatedAt: 1 }))
+    const { steps, resumeStep } = useBootstrapRunSteps('b3')
+    expect(steps.value.map((s) => s.state)).toEqual(['running', 'pending', 'pending'])
+    store.upsertBootstrap(
+      job('b3', {
+        monorepo: MONOREPO,
+        phase: 'apply',
+        adoptionPlan: plan('ready'),
+        adoptionReview: { choices: [] } as unknown as BootstrapJob['adoptionReview'],
+        updatedAt: 2,
+      }),
+    )
+    expect(steps.value.map((s) => s.state)).toEqual(['done', 'done', 'running'])
+    expect(resumeStep.value).toBe('apply')
+  })
+
+  it('answers empty for a run the store does not hold', () => {
+    const { steps, multiStep, resumeStep } = useBootstrapRunSteps('nope')
+    expect(steps.value).toEqual([])
+    expect(multiStep.value).toBe(false)
+    expect(resumeStep.value).toBeNull()
+  })
+})