@cat-factory/app 0.256.2 → 0.257.0

package/app/utils/binaryCandidates.spec.ts

@@ -0,0 +1,110 @@
+import { describe, expect, it } from 'vitest'
+import type { PipelineStep } from '~/types/execution'
+import { binaryCandidateHasWarnings, binaryCandidateView } from './binaryCandidates'
+
+function step(overrides: Record<string, unknown> = {}): PipelineStep {
+  // The candidate override MERGES into the base state rather than replacing it, so a case that
+  // only cares about one counter does not have to restate the whole candidate list.
+  const { binaryCandidates, ...rest } = overrides
+  return {
+    agentKind: 'imager',
+    state: 'waiting_decision',
+    binaryCandidates: {
+      status: 'awaiting_choice',
+      multiSelect: false,
+      invalidEntries: 0,
+      omitted: 0,
+      unusablePreviews: 0,
+      candidates: [
+        { id: 'c1', service: 's', location: 'a.png', subject: 'anvil', generator: 'flux' },
+        { id: 'c2', service: 's', location: 'b.png', subject: 'anvil', generator: 'retro' },
+        { id: 'c3', service: 's', location: 'c.png', subject: 'hammer' },
+      ],
+      ...(binaryCandidates as Record<string, unknown> | undefined),
+    },
+    ...rest,
+  } as unknown as PipelineStep
+}
+
+describe('binaryCandidateView', () => {
+  // A step that never compared renders nothing at all, exactly as the binary-output section does
+  // for a step that never generated: a row saying "no comparison here" would ride every step.
+  it('is absent for a step with no comparison story', () => {
+    expect(binaryCandidateView({ agentKind: 'coder' } as PipelineStep)).toBeNull()
+    expect(binaryCandidateView(null)).toBeNull()
+  })
+
+  // A person compares one subject at a time; forty subjects is forty comparisons, not one wall of
+  // eighty pictures.
+  it('groups candidates by subject in first-appearance order', () => {
+    const view = binaryCandidateView(step())!
+    expect(view.groups.map((g) => g.subject)).toEqual(['anvil', 'hammer'])
+    expect(view.groups[0]?.rows.map((r) => r.id)).toEqual(['c1', 'c2'])
+  })
+
+  // An unlabelled candidate is not "the same thing" as any labelled one, and filing it under the
+  // first subject would put a picture of something else into a comparison.
+  it('keeps unlabelled candidates in their own group rather than merging them', () => {
+    const view = binaryCandidateView(
+      step({
+        binaryCandidates: {
+          candidates: [
+            { id: 'c1', service: 's', location: 'a.png', subject: 'anvil' },
+            { id: 'c2', service: 's', location: 'b.png' },
+          ],
+        },
+      }),
+    )!
+    expect(view.groups.map((g) => g.subject)).toEqual(['anvil', null])
+  })
+
+  it('marks what was kept and the id it was kept under', () => {
+    const view = binaryCandidateView(
+      step({
+        binaryCandidates: {
+          status: 'chosen',
+          multiSelect: true,
+          choice: {
+            kept: [{ candidateId: 'c2', storeAs: 'anvil-pixel' }],
+            discarded: ['c1', 'c3'],
+            at: 1,
+          },
+        },
+      }),
+    )!
+    const rows = view.groups.flatMap((g) => g.rows)
+    expect(rows.find((r) => r.id === 'c2')).toMatchObject({ kept: true, storeAs: 'anvil-pixel' })
+    expect(rows.find((r) => r.id === 'c1')?.kept).toBe(false)
+    expect(view.awaiting).toBe(false)
+  })
+
+  // An automatic keep is NOT a review. A surface that renders it as a choice tells a reader a
+  // person looked at this and approved it, which is the claim the whole feature exists to make
+  // true.
+  it('reports an automatic keep as its own fact', () => {
+    const view = binaryCandidateView(
+      step({
+        binaryCandidates: {
+          status: 'chosen',
+          choice: { kept: [{ candidateId: 'c1' }], discarded: [], automatic: true, at: 1 },
+        },
+      }),
+    )!
+    expect(view.automatic).toBe(true)
+  })
+
+  it('counts candidates with no renderable preview', () => {
+    expect(binaryCandidateView(step())!.withoutPreview).toBe(3)
+  })
+})
+
+describe('binaryCandidateHasWarnings', () => {
+  // A comparison made over three of five candidates must not read as one made over all five.
+  it('is raised by any counted loss and by nothing else', () => {
+    expect(binaryCandidateHasWarnings(binaryCandidateView(step())!)).toBe(false)
+    for (const field of ['invalidEntries', 'omitted', 'unusablePreviews'] as const) {
+      const view = binaryCandidateView(step({ binaryCandidates: { [field]: 1 } }))!
+      expect(binaryCandidateHasWarnings(view)).toBe(true)
+    }
+  })
+})

package/app/utils/binaryCandidates.ts

@@ -0,0 +1,126 @@
+import type { BinaryCandidate, BinaryCandidateStepState, PipelineStep } from '~/types/execution'
+
+// ---------------------------------------------------------------------------
+// The read model behind the candidate-comparison surface
+// (docs/initiatives/binary-output-foundational-storage.md).
+//
+// A step whose selection declares a `comparison` generates a candidate from each of its selected
+// integrations, stages them, and parks. This module turns that record into what the window
+// renders: the candidates GROUPED BY SUBJECT (which is what a person actually compares), the
+// preview each one does or does not have, and every loss the parse counted.
+//
+// Pure, and reads only the step's own record, which is the rule the sibling binary-output read
+// model follows and for the same reason: the join a human wants is answerable from the step alone, so
+// the surface needs no fetch and reads identically for a finished run.
+// ---------------------------------------------------------------------------
+
+/** One candidate as the window renders it, with the two facts the raw record does not carry. */
+export interface BinaryCandidateRow extends BinaryCandidate {
+  /**
+   * The human kept this one. Meaningful only once a choice exists, which is what lets the window
+   * double as the RECORD of a settled comparison rather than only its control surface.
+   */
+  kept: boolean
+  /** The id it is to be stored under, when the person who kept it assigned one. */
+  storeAs?: string
+}
+
+/** The candidates for one subject, which is the unit a person compares. */
+export interface BinaryCandidateGroup {
+  /**
+   * What these candidates depict, or null when the agent declared no subject. Null is its own
+   * group rather than being merged into another: an unlabelled candidate is not "the same thing"
+   * as any labelled one, and quietly filing it under the first subject would put a picture of
+   * something else into a comparison.
+   */
+  subject: string | null
+  rows: BinaryCandidateRow[]
+}
+
+/** The whole surface's read model. */
+export interface BinaryCandidateView {
+  state: BinaryCandidateStepState
+  /** Candidates grouped by subject, in first-appearance order. */
+  groups: BinaryCandidateGroup[]
+  /** Whether the run is parked on this decision right now (as opposed to showing the record). */
+  awaiting: boolean
+  /** Whether more than one candidate may be kept. */
+  multiSelect: boolean
+  /**
+   * True when the engine kept the only candidate without asking. Its own flag rather than an
+   * absent decider, because a surface that renders it as a choice claims a person looked at this.
+   */
+  automatic: boolean
+  /** How many candidates carry no renderable preview, so the window can say so once. */
+  withoutPreview: number
+}
+
+/**
+ * The step's candidate read model, or null when the step has no comparison story at all.
+ *
+ * A step that never compared renders nothing, exactly as the binary-output section does for a step
+ * that never generated: a row saying "no comparison was configured here" would ride every step of
+ * every run.
+ */
+export function binaryCandidateView(
+  step: PipelineStep | null | undefined,
+): BinaryCandidateView | null {
+  const state = step?.binaryCandidates
+  if (!state) return null
+  const kept = new Map((state.choice?.kept ?? []).map((entry) => [entry.candidateId, entry]))
+  const groups: BinaryCandidateGroup[] = []
+  const bySubject = new Map<string | null, BinaryCandidateGroup>()
+  for (const candidate of state.candidates) {
+    const subject = candidate.subject ?? null
+    let group = bySubject.get(subject)
+    if (!group) {
+      group = { subject, rows: [] }
+      bySubject.set(subject, group)
+      groups.push(group)
+    }
+    const choice = kept.get(candidate.id)
+    group.rows.push({
+      ...candidate,
+      kept: choice !== undefined,
+      ...(choice?.storeAs ? { storeAs: choice.storeAs } : {}),
+    })
+  }
+  return {
+    state,
+    groups,
+    awaiting: state.status === 'awaiting_choice',
+    multiSelect: state.multiSelect === true,
+    automatic: state.choice?.automatic === true,
+    withoutPreview: state.candidates.filter((candidate) => !candidate.previewUrl).length,
+  }
+}
+
+/**
+ * Whether anything about this comparison needs saying beside the candidates: entries the parse
+ * dropped, a truncated list, or preview links it refused.
+ *
+ * Drives the window's warning strip, so a comparison made over three of five candidates cannot
+ * read as one made over all of them. A missing PREVIEW is deliberately not one of these: it is
+ * ordinary (a private asset store issues no public link) and it is stated per candidate, where
+ * the reader can see exactly which one they are judging blind.
+ */
+export function binaryCandidateHasWarnings(view: BinaryCandidateView): boolean {
+  const { invalidEntries = 0, omitted = 0, unusablePreviews = 0 } = view.state
+  return invalidEntries > 0 || omitted > 0 || unusablePreviews > 0
+}
+
+/**
+ * State → the i18n key for the line explaining why no choice was offered.
+ *
+ * An exhaustive `Record` over the reason vocabulary, so a fourth reason fails the typecheck here
+ * rather than rendering a missing key. Every member is a different fault with a different fix,
+ * which is exactly why the engine records the reason instead of leaving the step blank.
+ */
+export const BINARY_CANDIDATE_NO_CHOICE_KEYS: Record<
+  NonNullable<BinaryCandidateStepState['noChoiceReason']>,
+  string
+> = {
+  undeclared: 'binaryCandidates.noChoice.undeclared',
+  parse_failed: 'binaryCandidates.noChoice.parseFailed',
+  no_candidates: 'binaryCandidates.noChoice.noCandidates',
+}

package/app/utils/binaryOutput.ts

@@ -1,10 +1,13 @@
 import {
   ASSET_STORAGE_CAPABILITY,
+  binaryCapabilityCoverage,
   binaryFormatCoverage,
   binaryModalityOverlaps,
   normalizeMediaType,
+  requiredBinaryCapabilities,
 } from '@cat-factory/contracts'
 import type {
+  BinaryGeneratorCapability,
   BinaryModality,
   BinaryModalityOverlap,
   RegisteredBinaryGenerator,
@@ -437,6 +440,20 @@ export type BinaryOutputPickIssue =
    * think to write it; this catches the author.
    */
   | 'generator_overlap'
+  /**
+   * A per-step GENERATION OPTION whose capability no selected integration declares: a reference
+   * image handed to an endpoint that takes no image input, a seed asked of one that has none
+   * (kernel's `capability_unsupported` spelling verbatim, like the members above it). A refusal.
+   */
+  | 'capability_unsupported'
+  /**
+   * A required capability nothing selected declares, where a selected integration declares NO
+   * capabilities at all, so it might be supported and nothing may say otherwise. ADVISORY, like
+   * `media_type_unverifiable` and for the same reason: the step starts. It is the state EVERY
+   * integration registered before capabilities existed is in, so styling it as a refusal would
+   * flag most working selections in the product.
+   */
+  | 'capability_unverifiable'
 
 /** What the builder found wrong with one step's selection, and which ids to name. */
 export interface BinaryOutputPickState {
@@ -457,6 +474,10 @@ export interface BinaryOutputPickState {
    * picker and the brief cannot describe one selection two ways.
    */
   generatorOverlaps: readonly BinaryModalityOverlap[]
+  /** The capabilities the step's generation options need that nothing selected supports. */
+  unsupportedCapabilities: readonly BinaryGeneratorCapability[]
+  /** The ones that could not be judged, kept apart from the refusal above. */
+  unverifiableCapabilities: readonly BinaryGeneratorCapability[]
 }
 
 /**
@@ -482,7 +503,10 @@ export interface BinaryOutputPickState {
  */
 function generatorPickIssues(
   config: BinaryOutputConfig | undefined,
-  generators: readonly Pick<RegisteredBinaryGenerator, 'id' | 'modalities' | 'mediaTypes'>[],
+  generators: readonly Pick<
+    RegisteredBinaryGenerator,
+    'id' | 'modalities' | 'mediaTypes' | 'capabilities'
+  >[],
   unavailable: boolean,
 ): {
   issues: BinaryOutputPickIssue[]
@@ -491,6 +515,8 @@ function generatorPickIssues(
   uncoveredMediaTypes: string[]
   unverifiableMediaTypes: string[]
   overlaps: BinaryModalityOverlap[]
+  unsupportedCapabilities: BinaryGeneratorCapability[]
+  unverifiableCapabilities: BinaryGeneratorCapability[]
 } {
   const none = {
     unknownGeneratorIds: [],
@@ -498,6 +524,8 @@ function generatorPickIssues(
     uncoveredMediaTypes: [],
     unverifiableMediaTypes: [],
     overlaps: [],
+    unsupportedCapabilities: [],
+    unverifiableCapabilities: [],
   }
   if (unavailable) return { issues: ['generators_unavailable'], ...none }
   const byId = new Map(generators.map((g) => [g.id, g]))
@@ -518,12 +546,21 @@ function generatorPickIssues(
   // one step is the one where neither is the deliverable (an image generated to feed a mesh API),
   // and gating on `modalities` would go silent on exactly that step.
   const overlaps = binaryModalityOverlaps(selected)
+  // The GENERATION OPTIONS, judged against the same resolved selection and through the same
+  // imported rule the brief renders from. The requirement is DERIVED from what the step actually
+  // asks for, so a single reference image is never flagged for lacking `multi-reference`.
+  const capability = binaryCapabilityCoverage(
+    requiredBinaryCapabilities(config?.generation),
+    selected,
+  )
   const issues: BinaryOutputPickIssue[] = []
   if (unknownGeneratorIds.length) issues.push('unknown_generator')
   if (uncovered.length) issues.push('modality_uncovered')
   if (format.uncovered.length) issues.push('media_type_uncovered')
   if (format.unverifiable.length) issues.push('media_type_unverifiable')
   if (overlaps.length) issues.push('generator_overlap')
+  if (capability.uncovered.length) issues.push('capability_unsupported')
+  if (capability.unverifiable.length) issues.push('capability_unverifiable')
   return {
     issues,
     unknownGeneratorIds,
@@ -531,6 +568,8 @@ function generatorPickIssues(
     uncoveredMediaTypes: format.uncovered,
     unverifiableMediaTypes: format.unverifiable,
     overlaps,
+    unsupportedCapabilities: capability.uncovered,
+    unverifiableCapabilities: capability.unverifiable,
   }
 }
 
@@ -565,7 +604,10 @@ export function binaryOutputPickIssues(
   // that registers no integrations cannot satisfy a step that selects one. So a call site that
   // omits this FLAGS a selection rather than passing it — the loud direction — and the default
   // stays a legitimate value rather than a hole.
-  generators: readonly Pick<RegisteredBinaryGenerator, 'id' | 'modalities' | 'mediaTypes'>[] = [],
+  generators: readonly Pick<
+    RegisteredBinaryGenerator,
+    'id' | 'modalities' | 'mediaTypes' | 'capabilities'
+  >[] = [],
   // Whether the deployment's integrations could not be READ. Defaulted to `false` — the honest
   // default, since every deployment but a mothership-mode node reads them in-process and cannot
   // fail — so an omitting call site judges the list it was given rather than claiming an outage.
@@ -594,6 +636,8 @@ export function binaryOutputPickIssues(
       uncoveredMediaTypes: generative.uncoveredMediaTypes,
       unverifiableMediaTypes: generative.unverifiableMediaTypes,
       generatorOverlaps: generative.overlaps,
+      unsupportedCapabilities: generative.unsupportedCapabilities,
+      unverifiableCapabilities: generative.unverifiableCapabilities,
     }
   }
 
@@ -618,5 +662,7 @@ export function binaryOutputPickIssues(
     uncoveredMediaTypes: generative.uncoveredMediaTypes,
     unverifiableMediaTypes: generative.unverifiableMediaTypes,
     generatorOverlaps: generative.overlaps,
+    unsupportedCapabilities: generative.unsupportedCapabilities,
+    unverifiableCapabilities: generative.unverifiableCapabilities,
   }
 }

package/app/utils/catalog.ts

@@ -7,6 +7,7 @@ import type {
   BlockType,
   TaskTypeMeta,
 } from '~/types/domain'
+import type { BadgeColor } from '~/utils/badge'
 
 /** Simple unique id helper (fine for a client-only prototype). */
 export function uid(prefix = 'id'): string {
@@ -1022,7 +1023,7 @@ export function blockTypeMeta(type: BlockType): BlockTypeMeta {
 /** Color + iconography for each block status. */
 export const STATUS_META: Record<
   BlockStatus,
-  { label: string; color: string; chip: string; icon: string }
+  { label: string; color: string; chip: BadgeColor; icon: string }
 > = {
   planned: {
     label: 'Planned',

package/app/utils/initiative.ts

@@ -7,16 +7,13 @@ import type {
   InitiativeQa,
   InitiativeStatus,
 } from '~/types/domain'
+import type { BadgeColor } from '~/utils/badge'
 
 // Shared initiative presentation vocabulary, so the board card, the inspector body and
 // the tracker window render statuses/progress from ONE source. The exhaustive
 // `Record<Enum, …>` maps keep the tier-2 typecheck guard live (a new status without
 // a label/chip fails the build) without triplicating it across the components.
 
-/** Nuxt UI badge/chip colour names — mirrors `UBadge`'s `color` prop union, so a chip map
- *  types its values against it and the `:color` binding needs no cast. */
-type BadgeColor = 'error' | 'info' | 'primary' | 'secondary' | 'success' | 'warning' | 'neutral'
-
 /** Initiative lifecycle status → i18n label key. */
 export const INITIATIVE_STATUS_LABEL_KEYS: Record<InitiativeStatus, string> = {
   planning: 'initiative.status.planning',

package/app/utils/pipelineRender.spec.ts

@@ -1,6 +1,8 @@
 import { describe, it, expect } from 'vitest'
+import { binaryCandidateStatusSchema } from '@cat-factory/contracts'
 import type { ExecutionInstance, PipelineStep } from '~/types/execution'
-import { dedicatedParkView } from './pipelineRender'
+import { missingI18nKeys } from '../../test/i18nKeys'
+import { REDIRECT_PARK_PRESENTATION, dedicatedParkView } from './pipelineRender'
 
 /** A minimal coder step; the predicate only reads approval/followUps/forkDecision. */
 const step = (over: Partial<PipelineStep>): PipelineStep =>
@@ -75,6 +77,26 @@ describe('dedicatedParkView', () => {
     }
   })
 
+  // A generating step parks BETWEEN its candidate pass and its delivering pass. Approving it
+  // generically would mark done a step that has staged files and delivered nothing, so it owns
+  // the park exactly as the fork choice one subject over does.
+  it('owns the candidate park while awaiting a choice', () => {
+    expect(
+      dedicatedParkView(step({ binaryCandidates: { status: 'awaiting_choice' } as never }), run()),
+    ).toBe('binary-candidates')
+  })
+
+  // Derived from the picklist the engine itself writes, rather than a hand-listed set: every
+  // status EXCEPT the parked one must release the step, and a status added to the vocabulary is
+  // then covered here the day it lands instead of quietly falling outside a stale literal list.
+  it('releases the step on every settled status the vocabulary holds', () => {
+    const settled = binaryCandidateStatusSchema.options.filter((s) => s !== 'awaiting_choice')
+    expect(settled.length).toBeGreaterThan(0)
+    for (const status of settled) {
+      expect(dedicatedParkView(step({ binaryCandidates: { status } as never }), run())).toBeNull()
+    }
+  })
+
   it('leaves a plain approval park to the generic rail', () => {
     expect(dedicatedParkView(step({}), run())).toBeNull()
   })
@@ -108,3 +130,26 @@ describe('dedicatedParkView', () => {
     expect(dedicatedParkView(step({ approval: null, state: 'working' }), blocked)).toBeNull()
   })
 })
+
+describe('REDIRECT_PARK_PRESENTATION', () => {
+  // The `Record` over the park vocabulary already proves at COMPILE time that every park has an
+  // entry, which is the whole reason it replaced the ternaries that rendered the fork's copy for
+  // the candidate park. What no type can prove is that an entry still names a key that EXISTS:
+  // a table lookup is invisible to typed message keys and to `i18n:check` alike, so deleting the
+  // catalog entry reads as a clean removal and the button renders its own key path at runtime.
+  it('names catalog keys that resolve', () => {
+    const keys = Object.values(REDIRECT_PARK_PRESENTATION).flatMap((p) => [
+      p.noticeKey,
+      p.actionKey,
+      p.railActionKey,
+    ])
+    expect(missingI18nKeys(keys)).toEqual([])
+  })
+
+  // Two parks pointing at one string is how the bug this table replaced would come back: the
+  // copy would be uniform and wrong again, and every other check would still pass.
+  it('gives each park its own copy', () => {
+    const notices = Object.values(REDIRECT_PARK_PRESENTATION).map((p) => p.noticeKey)
+    expect(new Set(notices).size).toBe(notices.length)
+  })
+})

package/app/utils/pipelineRender.ts

@@ -133,10 +133,17 @@ export function isCompanionKind(kind: string): boolean {
   )
 }
 
+/**
+ * The parks a surface must NOT answer with the generic approve rail, named so the tables below
+ * and every consumer can be keyed exhaustively by them rather than by a string.
+ */
+export type DedicatedParkView = 'follow-ups' | 'fork-decision' | 'binary-candidates' | 'input-gate'
+
 /**
  * The dedicated window that owns a step's approval park, when the park is NOT a generic
  * prose approval: the implementation-fork window while a coder waits on (or chats about)
- * an approach choice, or the follow-up triage window while surfaced items are undecided.
+ * an approach choice, the follow-up triage window while surfaced items are undecided, or the
+ * candidate-comparison window while a generating step waits on which candidates survive.
  * The generic approve/request-changes/reject resolvers deliberately refuse these parks
  * server-side (`assertNotIterativeGate`), so every surface that offers a step's pending
  * approval must route these to their window instead of the generic "Approve & proceed"
@@ -149,7 +156,7 @@ export function isCompanionKind(kind: string): boolean {
 export function dedicatedParkView(
   step: PipelineStep,
   instance: ExecutionInstance | null | undefined,
-): 'follow-ups' | 'fork-decision' | 'input-gate' | null {
+): DedicatedParkView | null {
   // The PRE-DISPATCH INPUT GATE parks whatever step 0 happens to be, so it leaves nothing on the
   // STEP to recognise it by: its verdict is a fact about the RUN. Checked first, and off the
   // instance: approving it generically would mark the run's first working step done and skip
@@ -168,6 +175,9 @@ export function dedicatedParkView(
   // flight) still belongs to the fork window, which renders the pending reply.
   const fork = step.forkDecision?.status
   if (fork === 'awaiting_choice' || fork === 'answering') return 'fork-decision'
+  // A generating step parked between its candidate pass and its delivering pass. Approving it
+  // generically would mark a step done that has staged files and delivered nothing.
+  if (step.binaryCandidates?.status === 'awaiting_choice') return 'binary-candidates'
   // Follow-ups only own the park itself: while the coder is still WORKING (streaming
   // items, no approval raised) a step click should keep opening the ordinary detail.
   if (
@@ -180,6 +190,64 @@ export function dedicatedParkView(
   return null
 }
 
+/**
+ * The parks a dedicated WINDOW answers: every member of {@link DedicatedParkView} except the
+ * pre-dispatch input gate, which is answered by an inline notice because its remedy is to go and
+ * edit the task.
+ */
+export type RedirectParkView = Exclude<DedicatedParkView, 'input-gate'>
+
+/** How a redirect park presents itself on a surface that has to send a human to its window. */
+export interface RedirectParkPresentation {
+  icon: string
+  /** Prose explaining why the generic approve rail is not offered here. */
+  noticeKey: string
+  /** The label on the step overlay's redirect button, which has room for a full phrase. */
+  actionKey: string
+  /**
+   * The label on the inspector's compact action rail. A separate key rather than a reuse of
+   * {@link actionKey}: that rail sits in a list of one-line step rows and words the same action
+   * more tersely, and collapsing the two would silently restyle copy that is already shipped.
+   */
+  railActionKey: string
+}
+
+/**
+ * What each redirect park LOOKS like, in one exhaustive table.
+ *
+ * A `Record` over the vocabulary rather than a ternary at each of the three surfaces that render
+ * one (the step overlay's redirect notice, the pipeline chip, the inspector's action rail),
+ * because a ternary has no arm for a member it has never heard of: adding `binary-candidates` to
+ * {@link dedicatedParkView} left every one of those surfaces rendering the FORK's copy and icon
+ * for it, which is worse than rendering nothing: it names the wrong decision, and the surfaces
+ * kept compiling and kept passing. Keyed this way, a new park fails the build here until it says
+ * how it presents itself, and each surface picks the entry up with no edit of its own.
+ *
+ * Presentation only. WHICH window opens is the caller's, because the openers differ in what they
+ * need to resolve, and a park with no window (`input-gate`) is excluded from the type entirely
+ * rather than carrying null fields nobody may read.
+ */
+export const REDIRECT_PARK_PRESENTATION: Record<RedirectParkView, RedirectParkPresentation> = {
+  'follow-ups': {
+    icon: 'i-lucide-compass',
+    noticeKey: 'panels.stepDetail.followUpsParked',
+    actionKey: 'panels.stepDetail.openFollowUps',
+    railActionKey: 'inspector.execution.triageFollowUps',
+  },
+  'fork-decision': {
+    icon: 'i-lucide-git-fork',
+    noticeKey: 'panels.stepDetail.forkParked',
+    actionKey: 'panels.stepDetail.chooseApproach',
+    railActionKey: 'inspector.execution.chooseApproach',
+  },
+  'binary-candidates': {
+    icon: 'i-lucide-images',
+    noticeKey: 'panels.stepDetail.candidatesParked',
+    actionKey: 'panels.stepDetail.chooseCandidates',
+    railActionKey: 'inspector.execution.chooseCandidates',
+  },
+}
+
 /**
  * The friendly label for a container's live phase (clone → "Preparing workspace",
  * agent → "Agent running", …), falling back to the raw phase string for an unknown/new