@cat-factory/app 0.204.0 → 0.206.0

package/app/components/binaryOutput/BinaryOutputReport.vue

@@ -126,6 +126,21 @@ const state = computed(() => {
           >
             {{ t('binaryOutput.unknownBadge') }}
           </UBadge>
+          <!-- WHAT MADE IT, beside where it went. Absent is a real state, not a gap: a step may
+               generate through its own model with no registered integration, so an unattributed
+               row is rendered without a generator rather than with an "unknown" one. -->
+          <span v-if="row.generator" class="font-mono" data-testid="binary-output-generator">{{
+            row.generator
+          }}</span>
+          <UBadge
+            v-if="row.generatorUnknown"
+            color="warning"
+            variant="subtle"
+            size="sm"
+            data-testid="binary-output-unknown-generator-badge"
+          >
+            {{ t('binaryOutput.unknownGeneratorBadge') }}
+          </UBadge>
           <span v-if="row.entity">{{ row.entity }}</span>
           <span v-if="row.contentType" class="font-mono">{{ row.contentType }}</span>
         </div>
@@ -160,6 +175,32 @@ const state = computed(() => {
           )
         }}
       </li>
+      <!-- The generative twin of the line above, and its own line for the same reason: an
+           unregistered integration is fixed in the DEPLOYMENT'S BUILD, where an unknown service is
+           fixed in the workspace catalog. The entries themselves are RETAINED, so leaving this out
+           would attribute an artifact to something nobody can look up with nothing saying so. -->
+      <li
+        v-if="view.unknownDeclaredGenerators.length"
+        data-testid="binary-output-unknown-generators"
+      >
+        {{
+          t(
+            'binaryOutput.warning.unknownGenerators',
+            {
+              ids: view.unknownDeclaredGenerators.join(', '),
+              count: view.unknownDeclaredGenerators.length,
+            },
+            view.unknownDeclaredGenerators.length,
+          )
+        }}
+      </li>
+      <!-- The third state of the same question, and the reason it is not the line above with an
+           empty list: an empty `unknownDeclaredGenerators` otherwise means every claimed id
+           checked out. Someone reading this panel to decide whether these artifacts are real
+           must not be handed a clean bill of health nobody issued. -->
+      <li v-if="view.generatorsUnverified" data-testid="binary-output-generators-unverified">
+        {{ t('binaryOutput.warning.generatorsUnverified') }}
+      </li>
       <li v-if="view.misdirected" data-testid="binary-output-misdirected-note">
         {{
           t(

package/app/components/pipeline/BinaryOutputStepPicker.vue

@@ -13,16 +13,45 @@
 // `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 } from '@cat-factory/contracts'
+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. */
@@ -48,32 +77,71 @@ const contextItems = computed(() =>
     .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),
+  binaryOutputPickIssues(
+    config.value,
+    catalog.resolved,
+    catalog.available,
+    agents.binaryGenerators,
+    agents.binaryGeneratorsUnavailable,
+  ),
 )
 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.
+ * 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 contextServiceIds = config.value?.contextServiceIds
+  const current = config.value
   pipelines.setDraftBinaryOutput(
     props.index,
-    storageServiceId
-      ? { storageServiceId, ...(contextServiceIds?.length ? { contextServiceIds } : {}) }
-      : undefined,
+    storageServiceId ? { ...current, storageServiceId } : undefined,
   )
 }
 
-function setContext(ids: string[]) {
-  const storageServiceId = config.value?.storageServiceId
+/**
+ * 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, { storageServiceId, contextServiceIds: ids })
+  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>
 
@@ -113,6 +181,41 @@ function setContext(ids: string[]) {
       />
     </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. -->
@@ -143,5 +246,39 @@ function setContext(ids: string[]) {
         })
       }}
     </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.
+         Unless the set could not be READ, in which case none of them is a claim anyone can make:
+         it says so and stops, exactly as run admission does. -->
+    <p
+      v-if="has('generators_unavailable')"
+      class="text-[10px] text-amber-400"
+      data-testid="binary-output-generators-unavailable"
+    >
+      {{ t('pipeline.builder.binaryOutputGeneratorsUnavailable') }}
+    </p>
+    <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/composables/usePipelineErrorToast.ts

@@ -25,8 +25,8 @@
  */
 
 import { createBespokeConflictToasts } from '~/composables/pipelineErrorToast/bespokeConflicts'
-import type { ApiErrorCode, ConflictReason } from '@cat-factory/contracts'
-import { apiErrorEnvelope, apiErrorStatus } from './api/errors'
+import type { ApiErrorCode, ConflictReason, UnavailableReason } from '@cat-factory/contracts'
+import { apiErrorEnvelope, apiErrorReason, apiErrorStatus } from './api/errors'
 
 /** The parsed shape of a backend conflict (`{ error: { code: 'conflict', details } }`). */
 interface ConflictDetails {
@@ -228,6 +228,10 @@ const CONFLICT_INFO: Record<Exclude<ConflictReason, BespokeConflictReason>, Conf
     titleKey: 'errors.conflict.title.binary_output_service_invalid',
     descriptionKey: 'errors.conflict.description.binary_output_service_invalid',
   },
+  binary_output_generator_invalid: {
+    titleKey: 'errors.conflict.title.binary_output_generator_invalid',
+    descriptionKey: 'errors.conflict.description.binary_output_generator_invalid',
+  },
   foundational_service_not_inherited: {
     titleKey: 'errors.conflict.title.foundational_service_not_inherited',
     descriptionKey: 'errors.conflict.description.foundational_service_not_inherited',
@@ -281,6 +285,28 @@ const GENERIC_DESCRIPTION_KEYS: Record<Exclude<ApiErrorCode, 'conflict'>, string
   internal: 'errors.generic.description.internal',
 }
 
+/**
+ * Translated description per REASON, for the non-conflict failures whose status class alone would
+ * describe them wrongly. Checked before {@link GENERIC_DESCRIPTION_KEYS} and falling through to
+ * it for every reason not listed, so this stays a short list of exceptions rather than a second
+ * vocabulary to keep in sync.
+ *
+ * It exists because the generic 503 copy has to commit to something, and what it commits to is
+ * "this deployment has not configured the capability this action needs". That is right for the
+ * common 503 (a module nobody wired) and exactly wrong for an outage: it tells an operator their
+ * build is missing a registration when the truth is that a set could not be read right now. On a
+ * mothership-mode node that is the misattribution this whole seam exists to remove, reappearing
+ * one layer up — with the honest wording demoted to untranslated detail behind a disclosure. So
+ * the reasons in {@link UNAVAILABLE_REASONS} carry their own copy, and the exhaustive `Record`
+ * over that union is the drift guard: a new user-reachable 503 reason fails this typecheck until
+ * it has wording.
+ */
+const UNAVAILABLE_DESCRIPTION_KEYS: Record<UnavailableReason, string> = {
+  binary_generators_unreachable: 'errors.unavailable.description.binary_generators_unreachable',
+  foundational_builtins_unreachable:
+    'errors.unavailable.description.foundational_builtins_unreachable',
+}
+
 /**
  * The request never reached a server that answered in our envelope shape — offline, DNS, a dropped
  * connection, CORS. Distinct from {@link UNEXPECTED_DESCRIPTION_KEY} on purpose: this one's remedy
@@ -322,7 +348,13 @@ export function describeGenericFailure(error: unknown): GenericFailure {
   // don't know must resolve to `undefined`, which is exactly what the alias's index signature
   // says and what a cast would have hidden. The narrow Record above stays the drift guard.
   const byCode: Readonly<Record<string, string | undefined>> = GENERIC_DESCRIPTION_KEYS
-  const mapped = envelope?.code ? byCode[envelope.code] : undefined
+  // A REASON that has its own copy wins over the status class's, through the same widened-alias
+  // read and for the same reason: a `reason` this build doesn't know must resolve to `undefined`
+  // and fall through, never narrow the wire string to the union by casting.
+  const byReason: Readonly<Record<string, string | undefined>> = UNAVAILABLE_DESCRIPTION_KEYS
+  const reason = apiErrorReason(error)
+  const mapped =
+    (reason ? byReason[reason] : undefined) ?? (envelope?.code ? byCode[envelope.code] : undefined)
   // No envelope at all AND no status ⇒ nothing answered; with a status, something did.
   const unrecognised =
     !envelope && apiErrorStatus(error) === undefined

package/app/stores/agents.ts

@@ -10,6 +10,7 @@ import {
   SYSTEM_AGENT_META,
   uid,
 } from '~/utils/catalog'
+import type { RegisteredBinaryGenerator } from '@cat-factory/contracts'
 import type { AgentArchetype, AgentKind, AgentKindVariant, CustomAgentKind } from '~/types/domain'
 
 /**
@@ -45,6 +46,22 @@ export const useAgentsStore = defineStore('agents', () => {
   // there — so folding it into the kind catalog would make it placeable, which is exactly what
   // the backend model says it is not. A straight replace, like the skills catalog it mirrors.
   const variants = ref<AgentKindVariant[]>([])
+  /**
+   * The deployment's GENERATIVE BINARY INTEGRATIONS, from the workspace snapshot. Static
+   * deployment-registered composition data like {@link variants}, and it rides the same store for
+   * the same reason: it is a fact ABOUT the agent catalog that the pipeline builder branches on,
+   * with no workspace state behind it. Empty on the stock product — the platform ships none.
+   */
+  const binaryGenerators = ref<RegisteredBinaryGenerator[]>([])
+
+  /**
+   * Whether that set could not be READ, straight off the snapshot's own flag. Its own piece of
+   * state rather than something inferred from an empty list, because the two are opposite facts:
+   * an empty list means this deployment registers none (fix it in the build), and an unreadable
+   * one means nobody knows (fix the connection). A picker that renders them alike sends someone
+   * to the wrong repository. False on every deployment that reads its integrations in-process.
+   */
+  const binaryGeneratorsUnavailable = ref(false)
 
   /**
    * The merged CUSTOM catalog (consumer-slot → backend-manifest → runtime), each
@@ -140,6 +157,20 @@ export const useAgentsStore = defineStore('agents', () => {
     capabilitiesManifest.value = manifest
   }
 
+  /**
+   * Hydrate the deployment's registered generative binary integrations from the snapshot (a
+   * straight replace, like {@link hydrateVariants}). The builder's binary-output picker offers
+   * exactly these ids, so they are the same set run admission resolves a step's `generatorIds`
+   * against — an id offered from anywhere else would save clean and be refused at run START.
+   */
+  function hydrateBinaryGenerators(
+    list: readonly RegisteredBinaryGenerator[],
+    unavailable = false,
+  ) {
+    binaryGenerators.value = [...list]
+    binaryGeneratorsUnavailable.value = unavailable
+  }
+
   /** Hydrate the deployment's registered agent-kind variants from the snapshot (straight replace). */
   function hydrateVariants(list: readonly AgentKindVariant[]) {
     variants.value = [...list]
@@ -172,6 +203,9 @@ export const useAgentsStore = defineStore('agents', () => {
     variants,
     hydrateVariants,
     variantsForKind,
+    binaryGenerators,
+    binaryGeneratorsUnavailable,
+    hydrateBinaryGenerators,
     variantLabel,
   }
 })

package/app/stores/pipelines/draftStepConfig.ts

@@ -180,15 +180,21 @@ export function createPipelineStepConfigActions(ctx: PipelinesContext) {
    * An EMPTY `contextServiceIds` is dropped rather than stored, for the reason the consensus
    * tier set drops its own empty array: the field's absence means "no scope service was
    * selected", while `[]` reads as "context was considered and rejected" — a different claim,
-   * and one the brief renderer would repeat to the agent.
+   * and one the brief renderer would repeat to the agent. `generatorIds` and `modalities` take
+   * the same treatment for the same reason: an absent `generatorIds` means the step generates
+   * through whatever its agent already has, and an absent `modalities` imposes no delivery
+   * requirement — both of which the brief STATES, so persisting `[]` would have it state the
+   * wrong thing.
    */
   function setDraftBinaryOutput(index: number, config: BinaryOutputConfig | undefined) {
     const next: StepOptions = { ...draftStepOptions.value[index] }
     if (config?.storageServiceId) {
-      const { storageServiceId, contextServiceIds } = config
+      const { storageServiceId, contextServiceIds, generatorIds, modalities } = config
       next.binaryOutput = {
         storageServiceId,
         ...(contextServiceIds?.length ? { contextServiceIds } : {}),
+        ...(generatorIds?.length ? { generatorIds } : {}),
+        ...(modalities?.length ? { modalities } : {}),
       }
     } else delete next.binaryOutput
     draftStepOptions.value[index] = Object.keys(next).length ? next : null

package/app/stores/workspace/hydrate.ts

@@ -100,6 +100,14 @@ export function applySnapshotToStores(snapshot: WorkspaceSnapshot, boardSince?:
   // The deployment's registered agent-kind variants (alternate prompts for existing kinds), so
   // the builder can offer them per step and the run views can name the one a step ran under.
   useAgentsStore().hydrateVariants(snapshot.agentKindVariants ?? [])
+  // The deployment's registered generative binary integrations, so the builder's binary-output
+  // picker can offer a step's `generatorIds` from the same set run admission validates against.
+  // …and whether that set could not be read at all, which the picker must say rather than
+  // render as an empty deployment (see `binaryGeneratorsUnavailable` on the snapshot).
+  useAgentsStore().hydrateBinaryGenerators(
+    snapshot.binaryGenerators ?? [],
+    snapshot.binaryGeneratorsUnavailable === true,
+  )
   useTaskTypesStore().hydrateCapabilities(capabilities)
   // The account's repo-sourced Claude Skills catalog (shared across its workspaces), so the
   // pipeline builder's per-step skill picker has its options. A straight replace.

package/app/utils/binaryOutput.spec.ts

@@ -12,7 +12,14 @@ function step(patch: Partial<PipelineStep>): PipelineStep {
 }
 
 function report(patch: Partial<BinaryOutputReport> = {}): BinaryOutputReport {
-  return { stored: [], unknownServices: [], invalidEntries: 0, omitted: 0, ...patch }
+  return {
+    stored: [],
+    unknownServices: [],
+    unknownGenerators: [],
+    invalidEntries: 0,
+    omitted: 0,
+    ...patch,
+  }
 }
 
 const artifact = (service: string, location: string) => ({ service, location })
@@ -220,6 +227,177 @@ describe('binaryOutputView', () => {
   })
 })
 
+describe('the generative half of the read model', () => {
+  // The schema gained `unknownGenerators` and a per-artifact `generator`; both are RETAINED
+  // claims, so a surface that drops them attributes an artifact to something nobody can look up
+  // with nothing saying so — the exact silent loss `unknownDeclaredServices` exists to close.
+  it('names integrations the deployment does not register, and badges their rows', () => {
+    const view = binaryOutputView(
+      step({
+        stepOptions: { binaryOutput: { storageServiceId: 'files', generatorIds: ['retro'] } },
+        binaryOutputs: report({
+          stored: [
+            { ...artifact('files', 'a.png'), generator: 'retro' },
+            { ...artifact('files', 'b.png'), generator: 'ghost' },
+            artifact('files', 'c.png'),
+          ],
+          unknownGenerators: ['ghost'],
+        }),
+      }),
+    )
+    expect(view?.unknownDeclaredGenerators).toEqual(['ghost'])
+    expect(view?.rows.map((r) => r.generatorUnknown)).toEqual([false, true, false])
+    // An UNATTRIBUTED row is not an unknown one: generating without a registered integration is
+    // legal (a model with native image output), so it must not be flagged as a bad id.
+    expect(view?.rows[2]?.generator).toBeUndefined()
+    expect(binaryOutputHasWarnings(view!)).toBe(true)
+  })
+
+  it('surfaces an UNCHECKED generative verdict, and does not let it read as a clean one', () => {
+    // The settlement-side twin of the picker's `generators_unavailable`. An empty
+    // `unknownDeclaredGenerators` normally means every claimed id checked out, so a reader
+    // deciding whether these artifacts are real would take silence here as confirmation. The
+    // flag has to reach both the line AND the collapsed summary's tone, or the one place it is
+    // stated is behind a section that looks like it has nothing to say.
+    const view = binaryOutputView(
+      step({
+        stepOptions: { binaryOutput: { storageServiceId: 'files', generatorIds: ['retro'] } },
+        binaryOutputs: report({
+          stored: [{ ...artifact('files', 'a.png'), generator: 'retro' }],
+          generatorsUnverified: true,
+        }),
+      }),
+    )
+    expect(view?.generatorsUnverified).toBe(true)
+    expect(view?.unknownDeclaredGenerators).toEqual([])
+    // The artifacts themselves survived the outage — that is the whole point of recording them.
+    expect(view?.rows).toHaveLength(1)
+    expect(binaryOutputHasWarnings(view!)).toBe(true)
+  })
+
+  it('reads a checked-and-clean report as clean, which is what makes the flag mean anything', () => {
+    const view = binaryOutputView(
+      step({
+        stepOptions: { binaryOutput: { storageServiceId: 'files', generatorIds: ['retro'] } },
+        binaryOutputs: report({
+          stored: [{ ...artifact('files', 'a.png'), generator: 'retro' }],
+        }),
+      }),
+    )
+    expect(view?.generatorsUnverified).toBe(false)
+    expect(binaryOutputHasWarnings(view!)).toBe(false)
+  })
+
+  it('carries the step selection through, and treats empty as a real state', () => {
+    const configured = binaryOutputView(
+      step({
+        state: 'pending',
+        stepOptions: {
+          binaryOutput: {
+            storageServiceId: 'files',
+            generatorIds: ['retro'],
+            modalities: ['image'],
+          },
+        },
+      }),
+    )
+    expect(configured?.generators).toEqual(['retro'])
+    expect(configured?.modalities).toEqual(['image'])
+    const bare = binaryOutputView(
+      step({ state: 'pending', stepOptions: { binaryOutput: { storageServiceId: 'files' } } }),
+    )
+    expect(bare?.generators).toEqual([])
+    expect(bare?.modalities).toEqual([])
+  })
+})
+
+describe('binaryOutputPickIssues, generative half', () => {
+  const catalog = [{ id: 'files', capabilities: ['asset-storage'] }]
+  const generators = [
+    { id: 'retro', modalities: ['image' as const] },
+    { id: 'studio', modalities: ['audio' as const] },
+  ]
+
+  it('mirrors the admission refusal for an id this deployment does not register', () => {
+    const pick = binaryOutputPickIssues(
+      { storageServiceId: 'files', generatorIds: ['retro', 'ghost'] },
+      catalog,
+      true,
+      generators,
+    )
+    expect(pick.issues).toContain('unknown_generator')
+    expect(pick.unknownGeneratorIds).toEqual(['ghost'])
+  })
+
+  it('names a declared content type nothing selected can produce', () => {
+    const pick = binaryOutputPickIssues(
+      { storageServiceId: 'files', generatorIds: ['retro'], modalities: ['image', 'audio'] },
+      catalog,
+      true,
+      generators,
+    )
+    expect(pick.issues).toContain('modality_uncovered')
+    expect(pick.uncoveredModalities).toEqual(['audio'])
+  })
+
+  it('reports BOTH faults when an unknown id was the one covering a requirement', () => {
+    // One edit should clear the step. Naming only the missing id would leave the user to
+    // discover the uncovered requirement on the next round trip.
+    const pick = binaryOutputPickIssues(
+      { storageServiceId: 'files', generatorIds: ['ghost'], modalities: ['audio'] },
+      catalog,
+      true,
+      generators,
+    )
+    expect(pick.issues).toEqual(expect.arrayContaining(['unknown_generator', 'modality_uncovered']))
+  })
+
+  it('judges the generative half even when no storage target is picked yet', () => {
+    // The early return for `not_selected` must not hide a second, independent fault.
+    const pick = binaryOutputPickIssues(
+      { storageServiceId: '', generatorIds: ['ghost'] },
+      catalog,
+      true,
+      generators,
+    )
+    expect(pick.issues).toEqual(expect.arrayContaining(['not_selected', 'unknown_generator']))
+  })
+
+  it('is silent about a step that selects no integration at all', () => {
+    const pick = binaryOutputPickIssues({ storageServiceId: 'files' }, catalog, true, generators)
+    expect(pick.issues).toEqual([])
+  })
+
+  it('reports an UNREADABLE set as an outage and makes no claim about the selection', () => {
+    // The picker's half of the mothership-mode disposition. A failed read arrives as the same
+    // empty list an unregistering deployment produces, so judging the selection against it would
+    // tell someone their step names an integration nobody registered — about an id that is very
+    // likely fine, and with the remedy pointing at the wrong repository.
+    const pick = binaryOutputPickIssues(
+      { storageServiceId: 'files', generatorIds: ['retro'], modalities: ['audio'] },
+      catalog,
+      true,
+      [],
+      true,
+    )
+    expect(pick.issues).toEqual(['generators_unavailable'])
+    expect(pick.unknownGeneratorIds).toEqual([])
+    expect(pick.uncoveredModalities).toEqual([])
+  })
+
+  it('still judges an EMPTY set, which is a real answer about the deployment', () => {
+    // The distinction the flag exists for: same empty list, opposite fact, opposite message.
+    const pick = binaryOutputPickIssues(
+      { storageServiceId: 'files', generatorIds: ['retro'] },
+      catalog,
+      true,
+      [],
+      false,
+    )
+    expect(pick.issues).toContain('unknown_generator')
+  })
+})
+
 describe('binaryOutputPickIssues', () => {
   const service = (id: string, capabilities: string[]) => ({ id, capabilities })
   const catalog = [