@cat-factory/app 0.202.0 → 0.205.0

package/app/components/pipeline/BinaryOutputStepPicker.vue

@@ -0,0 +1,274 @@
+<script setup lang="ts">
+// The per-step storage + context selection for a BINARY-OUTPUT kind — a generator whose
+// deliverable is binary artifacts stored through a foundational service the org already runs
+// (docs/initiatives/binary-output-foundational-storage.md).
+//
+// Shown on a step whose kind carries the `binary-output` trait, projected onto the workspace
+// snapshot as `CustomAgentKind.binaryOutput`. Unlike the variant picker beside it this is NOT
+// an override of a default: the selection is REQUIRED — an enabled generator step without one
+// is refused at pipeline save AND at run start — so it stays in BOTH interface tiers. Hiding a
+// required input in basic mode leaves a step that cannot be saved and no way to find out why.
+//
+// The storage half offers only services from the RESOLVED catalog that declare the
+// `asset-storage` capability, because that is exactly what run admission re-validates against
+// at every start/retry/restart. Offering an id from a stale client copy would let a step save
+// clean and fail one refusal cycle later.
+//
+// The GENERATIVE half answers the other question — what MAKES the artifacts — and its candidates
+// come from a different place: the integrations are registered in the deployment's CODE, so they
+// ride the workspace snapshot (`binaryGenerators`) rather than a catalog read. Both halves are
+// offered here because a step needs both to work, and only this surface can tell a human that the
+// content types it promises to deliver are not covered by anything it selected.
+import { computed } from 'vue'
+import {
+  ASSET_STORAGE_CAPABILITY,
+  GENERATION_CONTEXT_CAPABILITY,
+  type BinaryModality,
+  type BinaryOutputConfig,
+} from '@cat-factory/contracts'
+import { binaryOutputPickIssues, type BinaryOutputPickIssue } from '~/utils/binaryOutput'
+
+const props = defineProps<{ index: number }>()
+
+const pipelines = usePipelinesStore()
+const catalog = useFoundationalServicesStore()
+const agents = useAgentsStore()
+const { t } = useI18n()
+
+/**
+ * The content-type vocabulary, as STATIC literal `t()` keys — one per member, never a key
+ * assembled at runtime, so the typed-message-key check covers them (the standing i18n rule for
+ * an enum-keyed set).
+ */
+const MODALITY_LABELS: Record<BinaryModality, () => string> = {
+  image: () => t('pipeline.builder.binaryOutputModality.image'),
+  audio: () => t('pipeline.builder.binaryOutputModality.audio'),
+  video: () => t('pipeline.builder.binaryOutputModality.video'),
+  '3d': () => t('pipeline.builder.binaryOutputModality.3d'),
+  document: () => t('pipeline.builder.binaryOutputModality.document'),
+}
+const MODALITY_ORDER: BinaryModality[] = ['image', 'audio', 'video', '3d', 'document']
+function modalityLabel(modality: BinaryModality): string {
+  return MODALITY_LABELS[modality]()
+}
+
+const config = computed(() => pipelines.draftBinaryOutput(props.index))
+
+/** Storage candidates: the capability tag is a REQUIREMENT here, enforced by admission. */
+const storageItems = computed(() =>
+  catalog.resolved
+    .filter((service) => service.capabilities.includes(ASSET_STORAGE_CAPABILITY))
+    .map((service) => ({ label: service.name, value: service.id })),
+)
+
+/**
+ * Context candidates: the WHOLE resolved catalog, with `generation-context`-tagged services
+ * ordered first. The tag is conventional and never a filter — any service with a readable
+ * contract can inform scope, and admission enforces existence only — so filtering on it here
+ * would hide a valid choice the backend would happily accept.
+ */
+const contextItems = computed(() =>
+  [...catalog.resolved]
+    .sort((a, b) => {
+      const rank = (tags: readonly string[]) =>
+        tags.includes(GENERATION_CONTEXT_CAPABILITY) ? 0 : 1
+      return rank(a.capabilities) - rank(b.capabilities) || a.name.localeCompare(b.name)
+    })
+    .map((service) => ({ label: service.name, value: service.id })),
+)
+
+/**
+ * Generative candidates: every integration the deployment registered, labelled with what it
+ * produces so the choice is legible without cross-referencing. No filter — unlike the storage
+ * half there is no capability to require, and any registered integration is one admission accepts.
+ */
+const generatorItems = computed(() =>
+  agents.binaryGenerators.map((generator) => ({
+    label: `${generator.name} — ${generator.modalities.map(modalityLabel).join(', ')}`,
+    value: generator.id,
+  })),
+)
+
+const modalityItems = computed(() =>
+  MODALITY_ORDER.map((modality) => ({ label: modalityLabel(modality), value: modality })),
+)
+
+const pick = computed(() =>
+  binaryOutputPickIssues(
+    config.value,
+    catalog.resolved,
+    catalog.available,
+    agents.binaryGenerators,
+  ),
+)
+function has(issue: BinaryOutputPickIssue): boolean {
+  return pick.value.issues.includes(issue)
+}
+
+/**
+ * Clearing the storage target drops the WHOLE selection — context and generative halves included:
+ * every other id only means anything as part of a generation that has somewhere to land, and a
+ * step carrying them alone would persist a shape the backend has no rule for. Setting a target
+ * carries the rest through, so re-pointing storage is not a silent reset of the other two.
+ */
+function setStorage(storageServiceId: string | undefined) {
+  const current = config.value
+  pipelines.setDraftBinaryOutput(
+    props.index,
+    storageServiceId ? { ...current, storageServiceId } : undefined,
+  )
+}
+
+/**
+ * Patch one half of the selection, carrying the others through. Every setter but `setStorage`
+ * goes via here so a change to one half can never silently drop another — the store rebuilds the
+ * whole `binaryOutput` bag from what it is handed, so an omitted field is a deletion.
+ */
+function patch(fields: Partial<BinaryOutputConfig>) {
+  const current = config.value
+  const storageServiceId = current?.storageServiceId
+  if (!storageServiceId) return
+  pipelines.setDraftBinaryOutput(props.index, { ...current, storageServiceId, ...fields })
+}
+
+function setContext(ids: string[]) {
+  patch({ contextServiceIds: ids })
+}
+
+function setGenerators(ids: string[]) {
+  patch({ generatorIds: ids })
+}
+
+function setModalities(modalities: BinaryModality[]) {
+  patch({ modalities })
+}
+</script>
+
+<template>
+  <div class="ms-6 flex flex-col gap-1.5" data-testid="binary-output-picker">
+    <div class="flex items-center gap-2">
+      <span class="text-[10px] text-slate-500">{{
+        t('pipeline.builder.binaryOutputStorage')
+      }}</span>
+      <USelect
+        class="w-56"
+        :model-value="config?.storageServiceId ?? ''"
+        :items="storageItems"
+        value-key="value"
+        size="xs"
+        :placeholder="t('pipeline.builder.binaryOutputPlaceholder')"
+        :disabled="!storageItems.length"
+        data-testid="binary-output-storage-select"
+        @update:model-value="setStorage($event)"
+      />
+    </div>
+
+    <div v-if="config?.storageServiceId" class="flex items-center gap-2">
+      <span class="text-[10px] text-slate-500">{{
+        t('pipeline.builder.binaryOutputContext')
+      }}</span>
+      <USelectMenu
+        class="w-56"
+        multiple
+        :model-value="config.contextServiceIds ?? []"
+        :items="contextItems"
+        value-key="value"
+        size="xs"
+        :placeholder="t('pipeline.builder.binaryOutputContextPlaceholder')"
+        data-testid="binary-output-context-select"
+        @update:model-value="setContext($event)"
+      />
+    </div>
+
+    <div v-if="config?.storageServiceId" class="flex items-center gap-2">
+      <span class="text-[10px] text-slate-500">{{
+        t('pipeline.builder.binaryOutputGenerators')
+      }}</span>
+      <USelectMenu
+        class="w-56"
+        multiple
+        :model-value="config.generatorIds ?? []"
+        :items="generatorItems"
+        value-key="value"
+        size="xs"
+        :placeholder="t('pipeline.builder.binaryOutputGeneratorsPlaceholder')"
+        :disabled="!generatorItems.length"
+        data-testid="binary-output-generator-select"
+        @update:model-value="setGenerators($event)"
+      />
+    </div>
+
+    <div v-if="config?.storageServiceId" class="flex items-center gap-2">
+      <span class="text-[10px] text-slate-500">{{
+        t('pipeline.builder.binaryOutputModalities')
+      }}</span>
+      <USelectMenu
+        class="w-56"
+        multiple
+        :model-value="config.modalities ?? []"
+        :items="modalityItems"
+        value-key="value"
+        size="xs"
+        :placeholder="t('pipeline.builder.binaryOutputModalitiesPlaceholder')"
+        data-testid="binary-output-modality-select"
+        @update:model-value="setModalities($event)"
+      />
+    </div>
+
+    <!-- Every refusal this step would hit, named where it is fixable. Each is its own line
+         with its own remedy: an unreachable catalog is not an empty one, a lost service is not
+         an untagged one, and a lost CONTEXT service is not a lost storage target. -->
+    <p
+      v-if="has('catalog_unavailable')"
+      class="text-[10px] text-amber-400"
+      data-testid="binary-output-unavailable"
+    >
+      {{ t('pipeline.builder.binaryOutputUnavailable') }}
+    </p>
+    <p
+      v-else-if="has('no_storage_service')"
+      class="text-[10px] text-amber-400"
+      data-testid="binary-output-no-storage"
+    >
+      {{ t('pipeline.builder.binaryOutputNoStorage', { capability: ASSET_STORAGE_CAPABILITY }) }}
+    </p>
+    <p v-if="has('unknown_service')" class="text-[10px] text-amber-400">
+      {{ t('pipeline.builder.binaryOutputMissing') }}
+    </p>
+    <p v-if="has('not_storage_capable')" class="text-[10px] text-amber-400">
+      {{ t('pipeline.builder.binaryOutputNotStorage', { capability: ASSET_STORAGE_CAPABILITY }) }}
+    </p>
+    <p v-if="has('unknown_context_service')" class="text-[10px] text-amber-400">
+      {{
+        t('pipeline.builder.binaryOutputContextMissing', {
+          ids: pick.unknownContextIds.join(', '),
+        })
+      }}
+    </p>
+    <!-- The generative refusals stay their own lines, and their remedies point somewhere else
+         entirely: an unregistered integration is fixed in the DEPLOYMENT'S BUILD, not in this
+         workspace, which is the whole reason the backend keeps the two reason codes apart. -->
+    <p
+      v-if="has('unknown_generator')"
+      class="text-[10px] text-amber-400"
+      data-testid="binary-output-unknown-generator"
+    >
+      {{
+        t('pipeline.builder.binaryOutputGeneratorMissing', {
+          ids: pick.unknownGeneratorIds.join(', '),
+        })
+      }}
+    </p>
+    <p
+      v-if="has('modality_uncovered')"
+      class="text-[10px] text-amber-400"
+      data-testid="binary-output-modality-uncovered"
+    >
+      {{
+        t('pipeline.builder.binaryOutputModalityUncovered', {
+          modalities: pick.uncoveredModalities.map(modalityLabel).join(', '),
+        })
+      }}
+    </p>
+  </div>
+</template>

package/app/components/pipeline/PipelineBuilder.vue

@@ -7,6 +7,7 @@ import AgentKindIcon from '~/components/pipeline/AgentKindIcon.vue'
 import AgentPromptEditor from '~/components/pipeline/AgentPromptEditor.vue'
 import EstimateThresholdFields from '~/components/pipeline/EstimateThresholdFields.vue'
 import OutputBudgetInput from '~/components/pipeline/OutputBudgetInput.vue'
+import BinaryOutputStepPicker from '~/components/pipeline/BinaryOutputStepPicker.vue'
 import { ESTIMATE_AXES, ESTIMATE_AXIS_FIELD, type EstimateAxis } from '~/utils/estimateGating'
 import { showOverrideField } from '~/utils/uiMode'
 import {
@@ -202,6 +203,36 @@ const stepsDisallowedByPurpose = computed(() =>
   }),
 )
 
+// The workspace's foundational-services catalog, for the binary-output storage/context picker.
+const foundational = useFoundationalServicesStore()
+
+/**
+ * Whether this step's kind is a BINARY-OUTPUT generator, and therefore needs the storage +
+ * context picker. Read off the kind's projected `binaryOutput` flag rather than a kind-id list,
+ * so a deployment's generator opts in by carrying the trait exactly as the engine's own checks
+ * key on it.
+ *
+ * Deliberately NOT behind `showOverrideField` / `isAdvanced` the way the variant picker is: a
+ * variant OVERRIDES what the kind ships, while this selection is REQUIRED. A basic-mode user
+ * who cannot see it has a step that cannot be saved and no way to find out why.
+ */
+function showBinaryOutputPicker(kind: AgentKind): boolean {
+  return agentKindMeta(kind).binaryOutput === true
+}
+
+// An enabled generator step with no storage selection — mirrors the backend save/start
+// rejection (`assertValidBinaryOutputSteps`), surfaced as an inline hint so the user fixes it
+// before the round trip. Same disposition as `skillStepNeedsPick`, for the same reason: both
+// are a step parametrized by a selection it cannot run without.
+const binaryOutputStepNeedsPick = computed(() =>
+  pipelines.draft.some(
+    (kind, i) =>
+      showBinaryOutputPicker(kind) &&
+      pipelines.draftEnabled[i] !== false &&
+      !pipelines.draftBinaryOutput(i)?.storageServiceId,
+  ),
+)
+
 // A step's picked skill id is no longer in the account catalog (the source dir was renamed or
 // unlinked). The step will fail cleanly at dispatch; flag it so the user re-picks.
 function skillMissing(index: number): boolean {
@@ -226,6 +257,11 @@ watch(open, (isOpen) => {
   // The workspace's per-kind output ceilings, which the per-step field shows as its inherited
   // placeholder and the prompt editor edits. Best-effort on the same terms as the prompt index.
   if (isOpen) agentSettings.load().catch(() => {})
+  // The resolved foundational-services catalog, which the binary-output picker offers from.
+  // Single-flighted per workspace, so this shares the panel's load rather than adding one. A
+  // failure is not swallowed into an empty picker: the store records `available: false`, and
+  // the picker says the catalog is unreachable rather than "no services exist".
+  if (isOpen) void foundational.ensureProbed()
 })
 
 function add(kind: AgentKind) {
@@ -531,6 +567,15 @@ async function clone(p: Pipeline) {
             {{ t('pipeline.builder.skillNeedsPick') }}
           </p>
 
+          <p
+            v-if="binaryOutputStepNeedsPick"
+            class="mb-2 flex items-center gap-1.5 rounded-md border border-amber-800/50 bg-amber-950/30 px-2 py-1 text-[11px] text-amber-300"
+            data-testid="binary-output-needs-pick"
+          >
+            <UIcon name="i-lucide-alert-triangle" class="h-3.5 w-3.5 shrink-0" />
+            {{ t('pipeline.builder.binaryOutputNeedsPick') }}
+          </p>
+
           <p
             v-if="stepsDisallowedByPurpose.length"
             class="mb-2 flex items-center gap-1.5 rounded-md border border-amber-800/50 bg-amber-950/30 px-2 py-1 text-[11px] text-amber-300"
@@ -792,6 +837,15 @@ async function clone(p: Pipeline) {
                 />
               </div>
 
+              <!-- Binary-output picker: a generator kind's step is parametrized by the
+                 foundational STORAGE service its artifacts go through (`stepOptions.binaryOutput`)
+                 plus any services consulted for the generation's scope. Required, not an
+                 override — so it shows in both interface tiers. -->
+              <BinaryOutputStepPicker
+                v-if="showBinaryOutputPicker(unit.kind)"
+                :index="unit.index"
+              />
+
               <!-- This step's own output-token ceiling. An OVERRIDE of the workspace's per-kind
                  setting (itself an override of the deployment routing default), so it is
                  advanced-only until a value is pinned; empty inherits. -->

package/app/components/settings/OpenRouterCatalogPanel.vue

@@ -32,10 +32,13 @@ const back = useIntegrationBack(open)
 const RECOMMENDED_SLUGS = [
   'anthropic/claude-fable-5',
   'anthropic/claude-opus-5',
-  'openai/gpt-5.5',
-  'google/gemini-3-pro',
-  'deepseek/deepseek-chat',
+  'openai/gpt-5.6-sol',
+  'openai/gpt-5.6-terra',
+  'google/gemini-3.1-pro-preview',
+  'google/gemini-3.6-flash',
+  'deepseek/deepseek-v4-flash',
   'moonshotai/kimi-k2.7-code',
+  'z-ai/glm-5.2',
 ]
 
 // Whether the workspace/user has an OpenRouter key connected at any reachable scope.

package/app/components/tutorial/TutorialCatalogue.logic.spec.ts

@@ -0,0 +1,103 @@
+import { describe, expect, it } from 'vitest'
+import { buildCatalogueRows, summarizeProgress } from './TutorialCatalogue.logic'
+import type { TutorialCatalogueEntry, TutorialTourState } from '~/utils/tutorial'
+
+const entry = (
+  id: string,
+  availability: TutorialCatalogueEntry['availability'],
+  stepCount = 3,
+): TutorialCatalogueEntry => ({
+  tour: {
+    id,
+    order: 10,
+    titleKey: `tutorial.tours.${id}.title`,
+    descriptionKey: `tutorial.tours.${id}.description`,
+    steps: Array.from({ length: stepCount }, (_, i) => ({
+      id: `s${i}`,
+      titleKey: 't',
+      bodyKey: 'b',
+    })),
+  },
+  availability,
+  unmet:
+    availability === 'blocked'
+      ? [{ id: 'service', labelKey: 'tutorial.requirements.service', met: () => false }]
+      : [],
+})
+
+const states = (map: Record<string, TutorialTourState>) => (id: string) => map[id] ?? 'notStarted'
+
+describe('buildCatalogueRows', () => {
+  it('carries every tour through, ready or not', () => {
+    const rows = buildCatalogueRows(
+      [entry('a', 'ready'), entry('b', 'blocked'), entry('c', 'not-applicable')],
+      states({}),
+    )
+    expect(rows.map((r) => r.tour.id)).toEqual(['a', 'b', 'c'])
+    expect(rows.map((r) => r.startable)).toEqual([true, false, false])
+  })
+
+  it('counts the steps of a runnable tour and withholds a count for the rest', () => {
+    // A blocked tour's resolved script is not what the user gets once they unblock it, and a
+    // number that quietly changes under them is worse than no number.
+    const rows = buildCatalogueRows([entry('a', 'ready', 4), entry('b', 'blocked', 4)], states({}))
+    expect(rows[0]?.stepCount).toBe(4)
+    expect(rows[1]?.stepCount).toBeNull()
+  })
+
+  it('labels each row from the user`s own progress', () => {
+    const rows = buildCatalogueRows(
+      [entry('a', 'ready'), entry('b', 'ready'), entry('c', 'ready')],
+      states({ a: 'completed', b: 'paused', c: 'inProgress' }),
+    )
+    expect(rows.map((r) => r.action)).toEqual(['restart', 'resume', 'continue'])
+  })
+
+  it('keeps a blocked tour`s unmet requirements for the reason list', () => {
+    const [row] = buildCatalogueRows([entry('a', 'blocked')], states({}))
+    expect(row?.unmet.map((r) => r.id)).toEqual(['service'])
+  })
+})
+
+describe('summarizeProgress', () => {
+  /** The launch offer is still unanswered, so only the rows can make anything resettable. */
+  const unanswered = { launchOfferAnswered: false }
+  const rows = (map: Record<string, TutorialTourState>, ids: string[]) =>
+    buildCatalogueRows(
+      ids.map((id) => entry(id, 'ready')),
+      states(map),
+    )
+
+  it('counts completions against the WHOLE catalog, not the runnable part', () => {
+    // Counting only what this board can offer today would move the denominator every time a
+    // repo was linked or a run finished — and "2 of 2" on a board with four walkthroughs
+    // still waiting reads as a finished tutorial, which is what this surface disproves.
+    const all = buildCatalogueRows(
+      [entry('a', 'ready'), entry('b', 'blocked'), entry('c', 'not-applicable')],
+      states({ a: 'completed' }),
+    )
+    expect(summarizeProgress(all, unanswered)).toMatchObject({ completed: 1, total: 3 })
+  })
+
+  it('offers a reset for a paused tour, not only for completed ones', () => {
+    expect(summarizeProgress(rows({}, ['a', 'b']), unanswered).resettable).toBe(false)
+    expect(summarizeProgress(rows({ a: 'paused' }, ['a', 'b']), unanswered).resettable).toBe(true)
+    expect(summarizeProgress(rows({ a: 'completed' }, ['a', 'b']), unanswered).resettable).toBe(
+      true,
+    )
+  })
+
+  it('offers a reset to a user who only ever answered the launch offer', () => {
+    // The case keying Reset off the rows alone got wrong, and the one that matters most: someone
+    // who clicked "No thanks" and took no tour has nothing completed and nothing paused, yet the
+    // saved answer is exactly what stops the prompt returning. Hiding the control left them no
+    // route back to the first-launch experience Reset promises.
+    expect(summarizeProgress(rows({}, ['a', 'b']), { launchOfferAnswered: true }).resettable).toBe(
+      true,
+    )
+  })
+
+  it('offers no reset on a genuinely untouched install', () => {
+    expect(summarizeProgress([], unanswered).resettable).toBe(false)
+  })
+})

package/app/components/tutorial/TutorialCatalogue.logic.ts

@@ -0,0 +1,102 @@
+import { launchActionFor } from '~/utils/tutorial'
+import type {
+  TutorialAvailability,
+  TutorialCatalogueEntry,
+  TutorialLaunchAction,
+  TutorialRequirement,
+  TutorialTour,
+  TutorialTourState,
+} from '~/utils/tutorial'
+
+/**
+ * What the catalogue renders per tour, and the progress line above the list.
+ *
+ * Extracted from `TutorialCatalogue.vue` for the same reason the overlay's decisions are
+ * (`TutorialOverlay.logic.ts`): the vitest setup has no SFC transform, so anything that
+ * DECIDES has to live outside the component to be tested. Here that is the whole of what the
+ * surface claims — which tours can be started, which are held back and by what, and how much
+ * of the catalog this user has been through.
+ */
+
+/** One rendered row: an entry, plus everything derived from it and the user's progress. */
+export interface TutorialCatalogueRow {
+  tour: TutorialTour
+  availability: TutorialAvailability
+  /** What is standing in the way, when {@link availability} is `blocked`. */
+  unmet: readonly TutorialRequirement[]
+  state: TutorialTourState
+  action: TutorialLaunchAction
+  /**
+   * How many steps a start would walk this board through — the RESOLVED count, not the
+   * declared one, since branch steps that don't apply here are already gone.
+   *
+   * Null for a tour that cannot run: its resolved script is not what the user would get once
+   * the missing requirement is met, and a number that quietly changes when they unblock it is
+   * worse than no number.
+   */
+  stepCount: number | null
+  /** Whether the row's button does anything (a blocked tour's is inert, not hidden). */
+  startable: boolean
+}
+
+/** The list, in catalog order — the entries arrive sorted by `resolveTourCatalogue`. */
+export function buildCatalogueRows(
+  entries: readonly TutorialCatalogueEntry[],
+  stateOf: (tourId: string) => TutorialTourState,
+): TutorialCatalogueRow[] {
+  return entries.map((entry) => {
+    const ready = entry.availability === 'ready'
+    const state = stateOf(entry.tour.id)
+    return {
+      tour: entry.tour,
+      availability: entry.availability,
+      unmet: entry.unmet,
+      state,
+      action: launchActionFor(state),
+      stepCount: ready ? entry.tour.steps.length : null,
+      startable: ready,
+    }
+  })
+}
+
+/** The headline count. */
+export interface TutorialProgressSummary {
+  completed: number
+  /** Every tour this deployment ships, available or not — the honest denominator. */
+  total: number
+  /**
+   * Whether there is anything for Reset to clear — which is everything `resetProgress` writes,
+   * not only what this list shows. See {@link summarizeProgress}.
+   */
+  resettable: boolean
+}
+
+/**
+ * Progress across the WHOLE catalog, not just the runnable part.
+ *
+ * Counting only what this board can offer today would move the denominator under the user
+ * every time they linked a repo or finished a run — "2 of 2 completed" on a board with four
+ * more walkthroughs waiting behind requirements reads as a finished tutorial, which is the
+ * one thing this surface exists to disprove.
+ *
+ * `launchOfferAnswered` is the store's `decision`, and it is here rather than derived from the
+ * rows because `resetProgress` clears it too — Reset restores the FIRST-LAUNCH experience, and
+ * the saved answer to "would you like a tour?" is most of that. Keying the control on the rows
+ * alone hid it from the one user who most needs it: someone who clicked "No thanks" and took no
+ * tour has nothing completed and nothing paused, so the only route back to the offer was the
+ * control that was not being drawn.
+ */
+export function summarizeProgress(
+  rows: readonly TutorialCatalogueRow[],
+  input: { launchOfferAnswered: boolean },
+): TutorialProgressSummary {
+  const completed = rows.filter((row) => row.state === 'completed').length
+  return {
+    completed,
+    total: rows.length,
+    // A paused tour is progress too: clearing it is exactly what someone handing this to a
+    // colleague wants, and offering Reset only for completions would leave it behind.
+    resettable:
+      completed > 0 || rows.some((row) => row.state === 'paused') || input.launchOfferAnswered,
+  }
+}