@cat-factory/app 0.202.0 → 0.204.0

package/README.md

@@ -185,9 +185,58 @@ picking what each of them runs on are halves of the same job.
 
 On first launch (once the board is up and no other startup advisory is open) the app asks
 whether the user wants a guided tour. The answer is SAVED per browser (`stores/tutorial.ts`,
-persisted like the interface tier): "no thanks" stops the prompt for good, closing without
-answering defers it to the next launch, and the command palette's "Take a tour" entry is the
-way back either way.
+persisted like the interface tier): "no thanks" stops the prompt for good, and closing without
+answering defers it to the next launch.
+
+**The prompt is the OFFER; the catalogue is the library.** `TutorialCatalogue.vue` — the
+sidebar's Help section, the palette, and a button in the prompt's own footer — lists every tour
+the deployment ships and lets any of them be started, resumed or repeated at any time. The two
+surfaces exist separately because they answer different questions, and the split is what keeps
+the prompt a short answerable one rather than a browsing surface. Start / Resume / Repeat /
+Back-to-the-tour is decided ONCE for both (`useTutorialLaunch` over the pure `tourState` +
+`launchActionFor`), or the same button would mean different things on two screens.
+
+**The catalogue lists the tours it CANNOT start, and says what would unlock each.** That is the
+reason a tour's preconditions are declared (`TutorialRequirement`: an id, a copy key, and the
+gate predicate) rather than being an anonymous `when(gates)`. A predicate can only answer "no",
+and a list that quietly omits four of six walkthroughs is indistinguishable from a deployment
+that ships two — to exactly the user who came looking for the rest. It also forces the two
+unavailable cases apart, because they need different reactions: `blocked` names something the
+reader can go and do ("A service on the board"), while `not-applicable` — requirements met, but
+every step is about a branch this board isn't on — names nothing at all, and telling them to fix
+it would send them hunting for a control that was never missing.
+
+**Tour gating therefore does NOT live in `navSlotFilter`**, unlike every other gated slot. A
+`SlotFilter` maps slots to slots, so it can only drop; `resolveTourCatalogue` (pure,
+gates-nullable, in `utils/tutorial.ts`) returns every tour with its availability and its unmet
+requirements, and `useTutorialTours` runs it once — exposing `tours` (what can start now, which
+is what the prompt and the overlay have always seen) and `catalogue` (everything, annotated). It
+reads the SAME registered `gates` service the nav filter does, through the shared-dependency
+`useOptional('gates')`, so the two can never disagree about what this board offers.
+
+Progress is per tour id and per browser. The catalogue's counter is over the WHOLE catalog, not
+the runnable part — counting only today's runnable tours would move the denominator every time a
+repo was linked, and "2 of 2 completed" on a board with four walkthroughs still waiting reads as
+a finished tutorial. `Reset progress` clears the completions, the resume point AND the saved
+launch answer, because everyone who asks for it (demoing, handing the app to a colleague) wants
+the first-launch experience back; it leaves a RUNNING tour alone, since a click about history
+must not end the walkthrough in progress. **It is therefore offered whenever ANY of those three
+is set, not only when a tour was taken** — someone who answered "No thanks" and stopped there has
+nothing completed and nothing paused, and that saved answer is the whole of what stands between
+them and the offer they came to restore.
+
+**The coach marks stand down while a tutorial-owned window is open** (`ownWindowOpen`). The
+overlay renders at `z-[70]`, above the app's own modals, because a step legitimately points INTO
+one — but no step points into the prompt or the catalogue, so there the same rule would float a
+highlight ring and a tooltip over the window the user just opened. The catalogue reaches that
+state by design: it is openable mid-tour, which is what the `continue` action is for. The overlay
+is SUPPRESSED rather than unmounted, because it holds the running tour's resolved script and a
+remount would re-resolve it against gates that may have flipped since the tour started.
+
+The arc this surface is being built along — what has landed, what each slice learned, and what
+is still open — is tracked in
+[`docs/initiatives/in-app-tutorials.md`](../../docs/initiatives/in-app-tutorials.md). This
+section is the authority on how the thing WORKS.
 
 A tour is **data, not components**: an ordered list of steps, each pointing at an on-screen
 control by its `data-testid` (the e2e anchor vocabulary — cover a control that has none by
@@ -202,16 +251,16 @@ in to type. A step whose anchor never appears within its wait is SKIPPED, becaus
 come and go with RBAC, tier, and deployment wiring: a tour is a set of opportunities, not a
 fixed script. Reaching the end having skipped steps is reported on the final card rather than
 congratulating the user on a walkthrough they did not see — and a tour that could only ever
-be abridged should not be offered at all, which is what each tour's `when(gates)` is for (the
-task-creation tour requires board write AND a service frame to add a task to).
+be abridged should not be offered at all, which is what each tour's `requires` is for (the
+task-creation tour needs board write AND a service frame to add a task to).
 
 **A step carries its own `when(gates)` when its BRANCH, not its control, is the thing that
 may not apply.** The two are different facts and only one of them is a defect: a skip means
 the control should be here and isn't, while a `when` means this board is not on that branch
 of the flow (a run parked on a decision has no approval gate, and the reverse). Reporting the
 second as an abridged tour would tell a user who saw exactly the right walkthrough that they
-missed half of it, every time. `resolveTours` (in `utils/tutorial.ts`, applied by
-`navSlotFilter`) drops the rejected steps and then drops a tour left with none, so a tour
+missed half of it, every time. `resolveTourCatalogue` (in `utils/tutorial.ts`) drops the
+rejected steps and marks a tour left with none `not-applicable` rather than ready, so a tour
 whose every step is branch-specific can never open on an empty cursor. With no gates service
 wired at all (a bare install withholds nothing) every branch survives instead, and only one
 of them can anchor — so the abridged notice ignores any skipped step that carries a `when`,
@@ -318,9 +367,12 @@ and it loses the slot soon enough — when this one is broken off past step 0.
 
 The catalog is the `tutorialTours` slot: first-party tours live in
 `modular/tutorial-tours.ts`, and a consumer deployment contributes its own through
-`registerAppModule` — they appear in the launch prompt beside the built-ins, gated per tour
-by its `when(gates)` predicate (the same reactive gates service the nav uses, filtered in
-`navSlotFilter`). Completion is persisted per tour id, so renaming an id resets its state.
+`registerAppModule` — they appear in the prompt and the catalogue beside the built-ins, held
+back per tour by its own `requires` (resolved against the same reactive gates service the nav
+uses). A consumer writes its own requirement objects with its own copy keys; the first-party
+ones are shared constants (`TUTORIAL_REQUIREMENTS`), because a second copy of "a service on the
+board" is a second sentence to keep in step with the gate it describes. Completion is persisted
+per tour id, so renaming an id resets its state.
 
 **A built-in tour's anchors are drift-guarded** (`tutorial-tours.spec.ts`), because they are
 the one thing about a tour that nothing else in the build checks: a renamed `data-testid`

package/app/components/binaryOutput/BinaryOutputReport.vue

@@ -0,0 +1,186 @@
+<script setup lang="ts">
+// What a BINARY-OUTPUT step delivered: the artifacts it declared it stored through the
+// foundational service the step selected, and — with equal weight — every way that record is
+// incomplete. See docs/initiatives/binary-output-foundational-storage.md.
+//
+// The engine's parse keeps six outcomes apart on purpose (not started, still running, no
+// declaration, an unreadable one, an explicit "stored nothing", and actual artifacts), because
+// each needs a different reaction and five of them are NOT "an empty list". This renders the
+// discriminant `binaryOutputView` derives, never a list that happens to be empty.
+//
+// It is a plain presenter over the STEP's own record — no fetch, no catalog read — so it drops
+// into both of the surfaces a step opens on (the result-window shell's trailing section and the
+// generic step-detail panel) and reads identically on a run whose services were withdrawn since.
+import { computed } from 'vue'
+import type { PipelineStep } from '~/types/execution'
+import { BINARY_OUTPUT_STATE_KEYS, binaryOutputView } from '~/utils/binaryOutput'
+import CopyButton from '~/components/common/CopyButton.vue'
+
+// Two callers, one renderer — the same split `StepEffortReport` makes: the generic step-detail
+// panel drops it in as a `card` (its own heading + border, among the other detail sections),
+// and `ResultWindowShell`'s collapsible footer embeds it `flat`, where the disclosure row is
+// already the heading and a second one would be chrome inside chrome.
+const props = withDefaults(defineProps<{ step: PipelineStep; variant?: 'card' | 'flat' }>(), {
+  variant: 'flat',
+})
+const { t } = useI18n()
+
+const view = computed(() => binaryOutputView(props.step))
+
+/**
+ * The outcome's own copy, from the shared exhaustive map — shared so the collapsed section row
+ * above this panel and the sentence inside it can never claim different outcomes. `stored`
+ * carries no detail (the artifacts are the statement), so it falls back to its summary.
+ */
+const state = computed(() => {
+  const keys = BINARY_OUTPUT_STATE_KEYS[view.value?.state ?? 'configured']
+  return { ...keys, text: t(keys.detail || keys.summary) }
+})
+</script>
+
+<template>
+  <section
+    v-if="view"
+    class="space-y-3"
+    :class="
+      variant === 'card' ? 'scroll-mt-4 rounded-xl border border-slate-800 bg-slate-900/50 p-4' : ''
+    "
+    data-testid="binary-output-report"
+  >
+    <div
+      v-if="variant === 'card'"
+      class="flex items-center gap-1.5 text-[11px] font-semibold uppercase tracking-wide text-slate-400"
+    >
+      <UIcon name="i-lucide-image" class="h-3.5 w-3.5" />
+      <span>{{ t('binaryOutput.heading') }}</span>
+    </div>
+
+    <!-- What happened, in one sentence, before any list. Four of the five states have no list
+         at all, and the fifth still needs its qualifications read alongside it. -->
+    <p
+      class="flex items-start gap-2 text-[12px] leading-relaxed"
+      :class="state.tone"
+      data-testid="binary-output-state"
+      :data-state="view.state"
+    >
+      <UIcon :name="state.icon" class="mt-0.5 h-3.5 w-3.5 shrink-0" />
+      <span>{{ state.text }}</span>
+    </p>
+
+    <!-- The step's own selection: the target every artifact was supposed to go through, and
+         the services it was told to scope the generation from. A step with NO selection says
+         so — it is a real state (a trait-carrying kind dispatched under an overriding kind
+         records a declaration against a step that never held one), and rendering a blank
+         would read as a missing value rather than an absent comparison. -->
+    <dl class="grid grid-cols-[auto_1fr] gap-x-3 gap-y-1 text-[11px]">
+      <dt class="text-slate-500">{{ t('binaryOutput.target') }}</dt>
+      <dd
+        v-if="view.target"
+        class="min-w-0 font-mono text-slate-300"
+        data-testid="binary-output-target"
+      >
+        {{ view.target }}
+      </dd>
+      <dd v-else class="min-w-0 text-slate-400" data-testid="binary-output-target">
+        {{ t('binaryOutput.targetNone') }}
+      </dd>
+      <template v-if="view.contextServices.length">
+        <dt class="text-slate-500">{{ t('binaryOutput.contextServices') }}</dt>
+        <dd class="min-w-0 font-mono text-slate-400">{{ view.contextServices.join(', ') }}</dd>
+      </template>
+    </dl>
+
+    <!-- The artifacts. `location` is the service's OWN addressing — an object key, a path, a
+         URL — recorded verbatim and never interpreted, so it renders as copyable text and
+         never as a link. -->
+    <ul v-if="view.rows.length" class="space-y-1.5">
+      <li
+        v-for="(row, i) in view.rows"
+        :key="`${row.service}:${row.location}:${i}`"
+        class="relative rounded-md border border-slate-800 bg-slate-950/40 px-2.5 py-2"
+        data-testid="binary-output-artifact"
+      >
+        <CopyButton :text="row.location" class="absolute end-1 top-1" />
+        <code class="block break-all pe-8 font-mono text-[11px] text-slate-200">{{
+          row.location
+        }}</code>
+        <div class="mt-1 flex flex-wrap items-center gap-x-2 gap-y-1 text-[10px] text-slate-500">
+          <span class="font-mono">{{ row.service }}</span>
+          <!-- The join the report cannot make on its own, and the question a human opens this
+               for: did it go where the step pointed it? -->
+          <UBadge
+            v-if="row.misdirected"
+            color="warning"
+            variant="subtle"
+            size="sm"
+            data-testid="binary-output-misdirected"
+          >
+            {{ t('binaryOutput.misdirectedBadge') }}
+          </UBadge>
+          <UBadge
+            v-if="row.unknown"
+            color="warning"
+            variant="subtle"
+            size="sm"
+            data-testid="binary-output-unknown-badge"
+          >
+            {{ t('binaryOutput.unknownBadge') }}
+          </UBadge>
+          <span v-if="row.entity">{{ row.entity }}</span>
+          <span v-if="row.contentType" class="font-mono">{{ row.contentType }}</span>
+        </div>
+        <p v-if="row.description" class="mt-1 text-[11px] leading-relaxed text-slate-400">
+          {{ row.description }}
+        </p>
+      </li>
+    </ul>
+
+    <!-- Every qualification the report counted, each naming its own number. Never folded into
+         one "some entries were dropped": the fix for an unknown service id is not the fix for
+         a malformed entry, and neither is the fix for a list that stops short of the tail. -->
+    <ul class="space-y-1 text-[11px] text-amber-400">
+      <!-- The step's OWN target went missing from the catalog, and an id the AGENT invented,
+           are two different failures with two different fixes (re-register it, versus correct
+           the declaration). `binaryOutputView` returns them as DISJOINT fields precisely so
+           these can be two independent lines: sharing one line meant the lost target's message
+           named every unknown id as if it were the step's own service, and silently dropped
+           the invented ones. -->
+      <li v-if="view.targetUnknown" data-testid="binary-output-target-unknown">
+        {{ t('binaryOutput.warning.targetUnknown', { id: view.target }) }}
+      </li>
+      <li v-if="view.unknownDeclaredServices.length" data-testid="binary-output-unknown-services">
+        {{
+          t(
+            'binaryOutput.warning.unknownServices',
+            {
+              ids: view.unknownDeclaredServices.join(', '),
+              count: view.unknownDeclaredServices.length,
+            },
+            view.unknownDeclaredServices.length,
+          )
+        }}
+      </li>
+      <li v-if="view.misdirected" data-testid="binary-output-misdirected-note">
+        {{
+          t(
+            'binaryOutput.warning.misdirected',
+            { count: view.misdirected, target: view.target },
+            view.misdirected,
+          )
+        }}
+      </li>
+      <li v-if="view.invalidEntries" data-testid="binary-output-invalid">
+        {{
+          t(
+            'binaryOutput.warning.invalidEntries',
+            { count: view.invalidEntries },
+            view.invalidEntries,
+          )
+        }}
+      </li>
+      <li v-if="view.omitted" data-testid="binary-output-omitted">
+        {{ t('binaryOutput.warning.omitted', { count: view.omitted }, view.omitted) }}
+      </li>
+    </ul>
+  </section>
+</template>

package/app/components/initiative/InitiativePlanReview.vue

@@ -107,7 +107,17 @@ async function copyPlan() {
 </script>
 
 <template>
-  <div class="flex min-h-0 flex-1 flex-col lg:flex-row" data-testid="initiative-plan-review">
+  <!-- The gate's id is published because a send-back is only observable through it. The rail is
+       torn down and rebuilt for the re-plan's NEW gate, but the gap between the two is not a state
+       the SPA is guaranteed to see: the send-back's own `ws.refresh()` races the re-plan, which
+       with a fast planner can park again first, so the rail goes straight from one gate to the
+       next. Asserting the absence was a race; asserting WHICH gate is on screen is the invariant
+       underneath it. Read by `initiative-plan-review.spec.ts`. -->
+  <div
+    class="flex min-h-0 flex-1 flex-col lg:flex-row"
+    data-testid="initiative-plan-review"
+    :data-approval-id="approval.id"
+  >
     <!-- Navigation column: the outline OUTSIDE the document rather than splitting its width — a
          sidebar of the window, as the step reader's is. Narrower than the reader's (`w-52` against
          its `w-72`) and held back to `lg` rather than its `md`, because this is a THREE-column

package/app/components/panels/AgentStepDetail.vue

@@ -8,6 +8,7 @@ import StepMetadataCard from '~/components/panels/StepMetadataCard.vue'
 import StepTestReport from '~/components/panels/StepTestReport.vue'
 import StepEffortReport from '~/components/panels/StepEffortReport.vue'
 import StepFragmentAdherence from '~/components/panels/StepFragmentAdherence.vue'
+import BinaryOutputReport from '~/components/binaryOutput/BinaryOutputReport.vue'
 import EnvironmentStatusPanel from '~/components/environments/EnvironmentStatusPanel.vue'
 import FrontendBindingsResolved from '~/components/panels/inspector/FrontendBindingsResolved.vue'
 import { UI_TESTER_AGENT_KIND } from '@cat-factory/contracts'
@@ -557,6 +558,15 @@ async function copyOutput() {
                    effectiveness, key obstacles). Only when the agent reported one. -->
               <StepEffortReport v-if="step.effortReport" :report="step.effortReport" />
 
+              <!-- what the step declared it stored through a foundational storage service, and
+                   every way that record is incomplete. This panel is the OTHER half of the
+                   result-window shell's trailing section: a step whose kind declares no
+                   dedicated result view opens here instead, and the shell is not involved — so
+                   without this the artifacts of exactly the kinds that need no bespoke window
+                   would have nowhere to appear. Self-hiding when the step has neither a report
+                   nor a selection, which is every step of every stock pipeline. -->
+              <BinaryOutputReport :step="step" variant="card" />
+
               <!-- edit-then-approve: a direct editor over the raw conclusions; the
                    edits become the approved proposal that flows to the next step -->
               <section v-if="editing" class="scroll-mt-4">

package/app/components/panels/ResultWindowShell.vue

@@ -25,6 +25,12 @@ import { useModalBehavior } from '@modular-vue/core'
 import StepRestartControl from '~/components/panels/StepRestartControl.vue'
 import StepEffortReport from '~/components/panels/StepEffortReport.vue'
 import StepValidationReport from '~/components/panels/StepValidationReport.vue'
+import BinaryOutputReport from '~/components/binaryOutput/BinaryOutputReport.vue'
+import {
+  BINARY_OUTPUT_STATE_KEYS,
+  binaryOutputHasWarnings,
+  binaryOutputView,
+} from '~/utils/binaryOutput'
 import { effortBand, effortHint } from '~/utils/effort'
 import {
   RESULT_WINDOW_WIDTH_CLASS,
@@ -140,6 +146,52 @@ watch(
   },
   { immediate: true },
 )
+/**
+ * The step's BINARY-OUTPUT record — the third universal trailing section, and here for the same
+ * reason as the two above: it is a by-product recorded on the STEP, not the deliverable of any
+ * one window, so no window may be able to opt out of it.
+ *
+ * The alternative — a dedicated `binary-outputs` result view a generator kind declares — cannot
+ * cover the record's own scope. The engine writes this report whenever the step's kind carries
+ * the trait OR the step carries a selection (`stepMayDeclareBinaryOutputs`, the deliberate UNION),
+ * precisely so a trait-carrying kind dispatched under an OVERRIDING kind still has its artifacts
+ * recorded. A kind-declared view is by construction blind to that case: the step's own kind
+ * declares a different window, and the artifacts exist with nowhere showing them. Resolving off
+ * the active step instead makes the surface follow the record rather than the catalog — and it
+ * leaves a generator free to declare a result view for its OWN output, which is what a generator
+ * that produces prose AND artifacts actually wants.
+ *
+ * Absent for every stock step (no report, no selection) and the section disappears, exactly as
+ * the two above do. That absence is the honest "this step had no binary-output story" — the
+ * distinct states that ARE a story (declared nothing / never declared / unreadable) all render.
+ */
+const binaryOutputs = computed(() => binaryOutputView(activeStep.value))
+const binaryOutputsOpen = ref(false)
+// A record carrying losses (unknown ids, dropped entries, a truncated list, an artifact that
+// went somewhere else) opens expanded — collapsed, it would read exactly like a clean one.
+watch(
+  binaryOutputs,
+  (view) => {
+    if (view && binaryOutputHasWarnings(view)) binaryOutputsOpen.value = true
+  },
+  { immediate: true },
+)
+
+/**
+ * The collapsed row's line: the OUTCOME, plus the artifact count only when there are artifacts.
+ * Deliberately not "N artifacts" for every state — five of the six have none, and a `0` there
+ * would render "declared nothing", "never declared" and "unreadable declaration" identically,
+ * which is the exact conflation the report's bookkeeping exists to prevent.
+ */
+const binaryOutputSummary = computed(() => {
+  const view = binaryOutputs.value
+  if (!view) return ''
+  const outcome = t(BINARY_OUTPUT_STATE_KEYS[view.state].summary)
+  return view.state === 'stored'
+    ? t('binaryOutput.storedCount', { outcome, count: view.rows.length }, view.rows.length)
+    : outcome
+})
+
 // Collapsed by default — the windows own the vertical space, and the row already carries the
 // difficulty plus the gist of what held the agent back.
 const effortOpen = ref(false)
@@ -304,6 +356,40 @@ const panelClass = computed(() => [
             <StepValidationReport :report="validationReport" />
           </div>
         </section>
+
+        <!-- Shared trailing section: what this step's agent declared it stored through a
+             foundational storage service (see `binaryOutputs` above for why it lives here and
+             not in a window). The collapsed row states the OUTCOME, never a count — five of
+             the six outcomes have no artifacts to count, and "0" is the one thing they must
+             not all read as. -->
+        <section
+          v-if="binaryOutputs"
+          class="shrink-0 border-t border-slate-800 bg-slate-900/60"
+          data-testid="result-window-binary-outputs"
+        >
+          <button
+            type="button"
+            class="flex w-full items-center gap-2 px-5 py-2 text-start hover:bg-slate-800/40"
+            :aria-expanded="binaryOutputsOpen"
+            data-testid="result-window-binary-outputs-toggle"
+            @click="binaryOutputsOpen = !binaryOutputsOpen"
+          >
+            <UIcon name="i-lucide-image" class="h-3.5 w-3.5 shrink-0 text-slate-400" />
+            <span class="text-[11px] font-semibold uppercase tracking-wide text-slate-400">
+              {{ t('binaryOutput.heading') }}
+            </span>
+            <span class="min-w-0 flex-1 truncate text-[12px] text-slate-400">
+              {{ binaryOutputSummary }}
+            </span>
+            <UIcon
+              :name="binaryOutputsOpen ? 'i-lucide-chevron-down' : 'i-lucide-chevron-up'"
+              class="ms-auto h-3.5 w-3.5 shrink-0 text-slate-500"
+            />
+          </button>
+          <div v-if="binaryOutputsOpen && activeStep" class="max-h-72 overflow-y-auto px-5 pb-3">
+            <BinaryOutputReport :step="activeStep" />
+          </div>
+        </section>
       </div>
     </div>
   </Teleport>

package/app/components/pipeline/BinaryOutputStepPicker.vue

@@ -0,0 +1,147 @@
+<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.
+import { computed } from 'vue'
+import { ASSET_STORAGE_CAPABILITY, GENERATION_CONTEXT_CAPABILITY } from '@cat-factory/contracts'
+import { binaryOutputPickIssues, type BinaryOutputPickIssue } from '~/utils/binaryOutput'
+
+const props = defineProps<{ index: number }>()
+
+const pipelines = usePipelinesStore()
+const catalog = useFoundationalServicesStore()
+const { t } = useI18n()
+
+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 })),
+)
+
+const pick = computed(() =>
+  binaryOutputPickIssues(config.value, catalog.resolved, catalog.available),
+)
+function has(issue: BinaryOutputPickIssue): boolean {
+  return pick.value.issues.includes(issue)
+}
+
+/**
+ * Clearing the storage target drops the WHOLE selection, context included: the context ids
+ * only mean anything as scope for a generation that has somewhere to land, and a step carrying
+ * context alone would persist a shape the backend has no rule for.
+ */
+function setStorage(storageServiceId: string | undefined) {
+  const contextServiceIds = config.value?.contextServiceIds
+  pipelines.setDraftBinaryOutput(
+    props.index,
+    storageServiceId
+      ? { storageServiceId, ...(contextServiceIds?.length ? { contextServiceIds } : {}) }
+      : undefined,
+  )
+}
+
+function setContext(ids: string[]) {
+  const storageServiceId = config.value?.storageServiceId
+  if (!storageServiceId) return
+  pipelines.setDraftBinaryOutput(props.index, { storageServiceId, contextServiceIds: ids })
+}
+</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>
+
+    <!-- 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>
+  </div>
+</template>