@cat-factory/app 0.213.1 → 0.215.0

package/README.md

@@ -208,6 +208,54 @@ omission. It thins an offer, never the library: an un-offered tour is listed, st
 in the progress line and one footer button away, and `requires` remains the only thing that can
 hold a tour back, which is always reported.
 
+**The finish card HANDS OFF to the next walkthrough** (`nextTourAfter`, offered beside Done). The
+delivery loop is a chain — each tour produces the state the next one requires — and finishing one is
+the last moment the product can bring the tutorial up at all: `startTour` writes
+`decision: 'accepted'`, which is exactly what stops the launch prompt auto-opening, so without this
+the walkthrough a user's own action just unlocked is reachable only by going and finding the
+catalogue. It offers ONE tour, launch-offer tours first whatever their `order` (a deployment's
+reference tour must not cut into the arc), never one already completed or the one just finished, and
+nothing at all when nothing is ready — where the plain Done is the honest ending. It reads the gates
+LIVE, which is the one deliberate exception to the held-script rule below: completing `first-task` is
+precisely what makes `run-task` ready, so a candidate resolved at tour start would be empty exactly
+when it matters. Taking the offer completes this tour first (or its badge stays "not started") and
+goes through the same `useTutorialLaunch().launch`, so a suggested tour the user had broken off
+earlier RESUMES. **Per-run overlay state resets with the script**, not by the component unmounting:
+the handoff completes one tour and starts the next in ONE tick, so `touring` never goes false for a
+render and the finished tour's skips would otherwise be counted against the new one.
+
+**A CONTEXTUAL offer catches a tour becoming takeable** (`resolveNudge` over `newlyAvailableTour` +
+`useTutorialNudge` + `TutorialNudge.vue`): a corner card, not a modal, since the whole point is the
+moment. The trigger is deliberately not a per-surface hook — every tour already declares, as its
+`requires`, the predicate that means "you can take this now", so ONE rule over the resolved
+catalogue covers the catalog and inherits `navRequirementDrift` unchanged. Four rules bind it. It
+fires on a TRANSITION into `ready`, never on the standing state, which would greet every board load
+with an offer about a walkthrough available for weeks. Only the launch-offer arc, for the same reason
+`offeredAtLaunch` exists. Never twice per tour (`nudgedTourIds`, persisted) and never after an
+explicit decline — "no thanks" answered the question about guided tours, not about when it was
+asked. And the offer is HELD rather than dropped while a tour or a tutorial window is up, because
+the two most valuable moments (a run parked, a run failed) routinely arrive then; it is marked spent
+when RAISED, so holding it cannot become nagging.
+
+**What that transition is measured against is the subtle half, and it takes TWO guards** (both in
+the pure `resolveNudge`, so they are unit-tested rather than inferred from a watcher; the composable
+holds only the ref, because a pure function cannot). Every gate reads a store something fills
+asynchronously, so a baseline taken when the composable mounts records "nothing is takeable" and the
+app's own startup then reads as a transition, which is the every-board-load greeting the rule exists
+to prevent arriving through the mechanism meant to be its cure.
+
+- **`workspace.ready`** gates taking a baseline at all on the snapshot having been fanned out, and
+  is re-set per board, which is what makes switching boards RE-SEED rather than offer everything the
+  incoming board happens to satisfy.
+- **A board-state FINGERPRINT** (`boardStateFingerprint`, over the `boardHas*` gates) is what an
+  offer requires to have MOVED. Readiness widening is not the world changing: a permission
+  resolving or a capability probe answering makes tours takeable that were "blocked" only because
+  the app had not found out yet, and the app finding out about itself is not a moment to interrupt
+  anyone about. Those resolutions advance the baseline silently. This is the guard that generalises
+  — it needs no list of which stores load late, because none of them describe the world — and it is
+  the reason readiness alone was not enough: `workspace.ready` flips before the RBAC access and the
+  integration probes have landed.
+
 **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",
@@ -226,7 +274,42 @@ is what the prompt and the overlay have always seen) and `catalogue` (everything
 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
+**Progress follows the USER, not the browser** (`useTutorialSync` / `useTutorialServer` over
+`GET|PUT|DELETE /tutorial/progress`). The browser-persisted store stays what the SPA reads and stays
+fully functional with no accounts, no store wired on the facade, or offline; the server row is a
+MIRROR, adopted in the snapshot fan-out (`stores/workspace/hydrate.ts`) so the launch prompt decides
+whether to appear against the merged state rather than this browser's copy alone. Both id lists are
+grow-only sets and are UNIONED on BOTH sides, because two browsers signed in as one person each hold
+a full copy and each write it back: a last-writer-wins replace on either side silently drops what the
+other learned, and the symptom is a finished walkthrough going back to "not started" days later.
+Only `decision` is replaced (a preference, not an accumulating fact), and then only where this browser
+is not holding an answer the mirror has not carried yet: without that exception a failed push lets the
+next snapshot re-adopt the older server answer, so "No thanks" silently comes back as accepted and
+every contextual offer re-arms. "Reset progress" is a DELETE, which is also why the catalogue calls
+`useTutorialServer` and not just the store — a local clear alone would be undone by the next snapshot
+re-merging the row.
+
+Three rules make fire-and-forget honest rather than merely convenient. Every push carries the WHOLE
+local state, so a retry, a racing tab and a stale copy are all the same well-formed write. The
+RESPONSE (the merged row) is reconciled back through the store, which is what closes the hole the
+server's un-rev-guarded merge leaves: two concurrent merges can lose a writer's ids, because a union
+is idempotent under retry but not commutative under concurrency, and the loser's answer comes back
+missing something local and re-pushes automatically. And the mirror watches the store's LOCAL
+revision counter rather than its state, because adopting the server's own ids is a state change too:
+watching the state posts the server's row straight back at it on every fresh-browser board load, and
+a reset (whose server side is the DELETE) would race a push of the freshly-emptied state.
+
+**The funnel is counted** (`POST /tutorial/events` → the kernel `OperationalMetrics` counters
+`tutorial.tour_started` / `_completed` / `_abandoned`, dimensioned by tour). The events are DERIVED
+from the cursor in one watcher rather than emitted from each store action, because those are five
+sites and a missing `started` fails nothing — it just biases the number the next decision is made
+against. Vue's batching is what makes that work across the handoff: it completes one tour and starts
+the next in a single tick, so the cursor goes `A → null → B` and the watcher sees `A → B` with the
+completion list one longer, reporting "A completed, B started". A resume counts as a start, which is
+deliberate: an attempt is an attempt, and not counting re-entries would make completions exceed
+starts. Nothing per-user or per-workspace is recorded, and nothing is stored.
+
+Progress is per tour id. 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
@@ -245,10 +328,9 @@ state by design: it is openable mid-tour, which is what the `continue` action is
 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.
+The decisions behind this surface, and why each alternative was rejected, are recorded in
+[ADR 0033](../../backend/docs/adr/0033-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
@@ -302,14 +384,18 @@ each drift on their own: the same split components make for inline placeholders.
 The built-ins come in two halves. The DELIVERY LOOP, end to end, each tour gated on the state the
 previous one leaves behind, so the launch prompt only ever offers what this board can demonstrate:
 board basics, add a repository (`add-service`), create a task (`first-task`), run it (`run-task`),
-answer it when it parks (`answer-park`), review and merge the result (`review-merge`). Then the
-PLATFORM behind it, catalogue-only: connect an engine (`wire-models`), assemble a flow
-(`design-pipeline`), curate the standards agents read (`agent-standards`), link the systems a run
-talks to (`connect-systems`). Each of those covers ONE surface and ends there, because the surface
-opens as a modal over the sidebar it was reached from, so a later step could not click another
-sidebar entry anyway, and each declares exactly the permission that renders the entry it clicks,
-since a weaker requirement offers a tour to someone with no such control and it then reports itself
-abridged.
+answer it when it parks (`answer-park`), read a failure when one comes (`diagnose-failure`), review
+and merge the result (`review-merge`). The loop covers work going WRONG on purpose: a first run fails
+often, `boardHasFinishedRun` deliberately excludes failures (a result view and a merge control are
+not what a failed run renders), and that left the state a new user is most likely to be in as the
+only one on the arc with no walkthrough. Then the PLATFORM behind it, catalogue-only: connect an
+engine (`wire-models`), assemble a flow (`design-pipeline`), curate the standards agents read
+(`agent-standards`), link the systems a run talks to (`connect-systems`), where runs execute
+(`prepare-infrastructure`), review by panel (`panel-reviews`), the shared services designs build on
+(`share-services`). Each of those covers ONE surface and ends there, because the surface opens as a
+modal over the sidebar it was reached from, so a later step could not click another sidebar entry
+anyway, and each declares exactly the permission that renders the entry it clicks, since a weaker
+requirement offers a tour to someone with no such control and it then reports itself abridged.
 
 **That pairing is DERIVED from the nav catalog, not restated.** A step whose anchor IS a nav
 entry's `testId` is checked by `navRequirementDrift` (`tutorial-tours.spec.ts`, beside the anchor
@@ -322,6 +408,14 @@ from BASIC mode; basic is the shipped default, so that tour would be offered to
 and find nothing. "Renders" therefore means the gate AND the tier, and a tour that wants an
 advanced entry has to declare the tier as a requirement of its own.
 
+**A SECTION can hide itself the same way, one level below anything that guard can see.**
+`panel-reviews` clicks `nav-model-config`, a BASIC-mode entry, but the consensus section inside that
+panel renders on `uiMode.isAdvanced || groups.hasGroups` — so on the shipped default tier a workspace
+that has never made a group renders nothing for the anchored step to find. `navRequirementDrift` pairs
+a tour only against a NAV entry's visibility, so this one is declared by hand (`advancedTier`) and
+pinned by its own named case in `tutorial-tours.spec.ts`. Any tour anchoring INSIDE a surface owes the
+same check of what that surface's own `v-if`s read.
+
 Two deliberate asymmetries about click-to-advance: `run-task` points at Start without it,
 because starting a run spends real model budget and nobody should discover they agreed to that by
 following a tutorial; `design-pipeline` points at Save without it, because Save is DISABLED until

package/app/components/observability/StepMetricsBar.vue

@@ -2,6 +2,7 @@
 import { computed } from 'vue'
 import type { StepMetrics } from '~/types/execution'
 import {
+  formatCost,
   formatMs,
   formatTokens,
   headroomColor,
@@ -33,6 +34,10 @@ const totalInput = computed(() => totalInputTokens(m.value))
 const cacheRead = computed(() => m.value.cacheReadTokens ?? 0)
 const cacheWrite = computed(() => m.value.cacheWriteTokens ?? 0)
 const hasCache = computed(() => cacheRead.value > 0 || cacheWrite.value > 0)
+// Money beside the volume, not instead of it. Null when the deployment prices nothing or has
+// no rate for the model that ran — the figure is then OMITTED rather than shown as 0.00, which
+// would claim the step was free.
+const cost = computed(() => formatCost(m.value.costEstimate, m.value.costCurrency))
 const headroom = computed(() => headroomRatio(m.value))
 const transport = computed(() => transportRatio(m.value))
 const headroomTone = computed(() => headroomColor(headroom.value, m.value.truncatedCalls > 0))
@@ -61,6 +66,12 @@ const headroomTone = computed(() => headroomColor(headroom.value, m.value.trunca
       >
         {{ formatTokens(totalInput) }}↑ {{ formatTokens(m.completionTokens) }}↓
       </span>
+      <template v-if="cost">
+        <span class="text-slate-500">·</span>
+        <span class="tabular-nums text-slate-300" :title="t('observability.metricsBar.costHint')">
+          {{ cost }}
+        </span>
+      </template>
       <div class="ms-auto flex items-center gap-1">
         <UBadge v-if="m.errors > 0" color="error" variant="subtle" size="sm">
           {{ t('observability.metricsBar.errors', { count: m.errors }, m.errors) }}

package/app/components/panels/AgentStepDetail.vue

@@ -7,6 +7,7 @@ import StepRestartControl from '~/components/panels/StepRestartControl.vue'
 import StepMetadataCard from '~/components/panels/StepMetadataCard.vue'
 import StepTestReport from '~/components/panels/StepTestReport.vue'
 import StepEffortReport from '~/components/panels/StepEffortReport.vue'
+import StepReproductionReport from '~/components/panels/StepReproductionReport.vue'
 import StepFragmentAdherence from '~/components/panels/StepFragmentAdherence.vue'
 import BinaryOutputReport from '~/components/binaryOutput/BinaryOutputReport.vue'
 import EnvironmentStatusPanel from '~/components/environments/EnvironmentStatusPanel.vue'
@@ -558,6 +559,19 @@ async function copyOutput() {
                    effectiveness, key obstacles). Only when the agent reported one. -->
               <StepEffortReport v-if="step.effortReport" :report="step.effortReport" />
 
+              <!-- the bugfix REPRODUCTION PROOF: the declared reproducing check run against the
+                   pre-fix tree and the final one, with both captured outputs, or the agent's
+                   structural declaration that the bug cannot be reproduced. This panel is the
+                   half that matters most: the engine records the proof on whichever step OPENED
+                   the pull request, and in every built-in pipeline that is the `coder` — a kind
+                   with no dedicated result view, so it opens HERE and the result-window shell is
+                   never involved. Self-hiding for a run that declared no reproducing check. -->
+              <StepReproductionReport
+                v-if="step.reproduction"
+                :report="step.reproduction"
+                variant="card"
+              />
+
               <!-- 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

package/app/components/panels/MergerResultView.vue

@@ -7,7 +7,7 @@
 // banner — instead of the agent's raw JSON. Opened via the universal result-view host,
 // the same seam the requirements / tester windows use.
 import { computed } from 'vue'
-import type { ChangeClass, MergeAxis, MergeDecision } from '@cat-factory/contracts'
+import type { ChangeClass, MergeAxis, MergeDecision, WorkspaceRole } from '@cat-factory/contracts'
 import StepRunMeta from '~/components/panels/StepRunMeta.vue'
 import ResultWindowShell from '~/components/panels/ResultWindowShell.vue'
 import MarkdownProse from '~/components/common/MarkdownProse.vue'
@@ -70,6 +70,8 @@ const REASON_KEYS: Record<MergeDecision['reason'], string> = {
   merge_partial: 'panels.mergerResult.reason.merge_partial',
   class_auto_merge: 'panels.mergerResult.reason.class_auto_merge',
   class_requires_review: 'panels.mergerResult.reason.class_requires_review',
+  role_requires_review: 'panels.mergerResult.reason.role_requires_review',
+  dry_run: 'panels.mergerResult.reason.dry_run',
 }
 const OUTCOME_KEYS: Record<MergeDecision['outcome'], string> = {
   auto_merged: 'panels.mergerResult.outcome.auto_merged',
@@ -131,7 +133,18 @@ const axes = computed(() => {
   ]
 })
 
-/** The plain-language "why" line, interpolating the preset + any exceeded axes. */
+/**
+ * The role the run was admitted under, when one was pinned. A `role_requires_review` line names
+ * it, because the remedy that reason points at is a PERSON (a teammate on a higher tier can merge
+ * this as it stands) rather than a setting.
+ */
+const ROLE_KEYS: Record<WorkspaceRole, string> = {
+  admin: 'merge.role.admin',
+  member: 'merge.role.member',
+  viewer: 'merge.role.viewer',
+}
+
+/** The plain-language "why" line, interpolating the preset, any exceeded axes, and the role. */
 const reasonText = computed(() => {
   const d = decision.value
   if (!d) return ''
@@ -139,6 +152,11 @@ const reasonText = computed(() => {
   return t(REASON_KEYS[d.reason], {
     preset: d.thresholds.presetName,
     axes: axisLabels,
+    // Never blank: a role-scoped reason is only ever produced for a run that pinned one, and the
+    // fallback keeps the sentence readable rather than leaving a hole if that ever changes.
+    role: d.thresholds.initiatorRole
+      ? t(ROLE_KEYS[d.thresholds.initiatorRole])
+      : t('merge.role.unattributed'),
   })
 })
 </script>

package/app/components/panels/ObservabilityPanel.vue

@@ -10,9 +10,11 @@ import type {
 import { agentKindMeta } from '~/utils/catalog'
 import {
   foldRunPhaseMetrics,
+  formatCost,
   formatMs,
   formatTokens,
   pct,
+  sumCosts,
   totalInputTokens,
 } from '~/utils/observability'
 
@@ -164,6 +166,36 @@ const phaseRows = computed(() => foldRunPhaseMetrics(instance.value?.steps ?? []
 const phaseCarryTotal = computed(() =>
   phaseRows.value.reduce((acc, p) => acc + p.carryCostTokens, 0),
 )
+/**
+ * The currency the engine priced this run in. Read off the step rollups rather than assumed,
+ * because the amounts come from a deployment-configured table whose currency an operator sets;
+ * absent ⇒ nothing priced the run, and every amount below is null too.
+ */
+const costCurrency = computed(
+  () => instance.value?.steps?.find((s) => s.metrics?.costCurrency)?.metrics?.costCurrency,
+)
+/**
+ * Whether to show money at all: this deployment prices, and at least one phase of this run
+ * actually got a figure.
+ *
+ * Deliberately NOT gated on the run TOTAL being known. A mixed-model run is the normal shape
+ * (a harness CLI serves some turns with a model of its own choosing), so one phase on an
+ * unpriced model is common — and gating the column on the total meant that one phase hid the
+ * cost of every other, with no indication anything had been withheld.
+ */
+const showCost = computed(
+  () => !!costCurrency.value && phaseRows.value.some((p) => p.costEstimate != null),
+)
+/**
+ * The run's estimated cost, folded from the same SQL rollup the phase table shows — NOT from
+ * the capped call list the token totals beside it use, which would silently under-report a run
+ * longer than the page. Null when any phase could not be priced (see `sumCosts`), in which case
+ * the tile SAYS the total is incomplete rather than quietly dropping it: a missing figure and a
+ * partial one are both wrong to render as a number, but only one of them is worth explaining.
+ */
+const runCost = computed(() =>
+  formatCost(sumCosts(phaseRows.value.map((p) => p.costEstimate)), costCurrency.value),
+)
 /** Share of the run's carry cost a phase accounts for (0..100), or null when nothing carried. */
 function carryShare(carryCostTokens: number): number | null {
   return phaseCarryTotal.value > 0 ? pct(carryCostTokens / phaseCarryTotal.value) : null
@@ -314,6 +346,21 @@ function exportJson() {
                   </dt>
                   <dd class="mt-0.5 tabular-nums text-slate-200">{{ totals.calls }}</dd>
                 </div>
+                <div v-if="showCost">
+                  <dt class="text-[11px] uppercase tracking-wide text-slate-500">
+                    {{ t('observability.summary.cost') }}
+                  </dt>
+                  <dd class="mt-0.5 tabular-nums text-slate-200">
+                    {{ runCost ?? '—' }}
+                    <span class="mt-0.5 block text-[11px] text-slate-500">
+                      {{
+                        runCost
+                          ? t('observability.summary.costHint')
+                          : t('observability.summary.costIncomplete')
+                      }}
+                    </span>
+                  </dd>
+                </div>
                 <div>
                   <dt class="text-[11px] uppercase tracking-wide text-slate-500">
                     {{ t('observability.summary.tokensInOut') }}
@@ -437,6 +484,11 @@ function exportJson() {
                       <th class="py-1 px-3 text-end font-normal">
                         {{ t('observability.phase.columns.tokensInOut') }}
                       </th>
+                      <th v-if="showCost" class="py-1 px-3 text-end font-normal">
+                        <span :title="t('observability.phase.costHint')">
+                          {{ t('observability.phase.columns.cost') }}
+                        </span>
+                      </th>
                       <!-- The sort key, MARKED as one. Rows lead with carry cost rather than
                            with tokens, and the two orders genuinely differ: a phase that runs
                            late carries almost nothing however much it spent (nothing after it
@@ -476,6 +528,11 @@ function exportJson() {
                         {{ formatTokens(totalInputTokens(p)) }}↑
                         {{ formatTokens(p.completionTokens) }}↓
                       </td>
+                      <td v-if="showCost" class="py-1.5 px-3 text-end tabular-nums text-slate-300">
+                        <!-- An em dash, not 0: this phase's model had no rate, and a zero here
+                             would read as a phase that cost nothing. -->
+                        {{ formatCost(p.costEstimate, costCurrency) ?? '—' }}
+                      </td>
                       <td class="py-1.5 ps-3 text-end tabular-nums text-slate-300">
                         {{ formatTokens(p.carryCostTokens) }}
                         <span v-if="carryShare(p.carryCostTokens) !== null" class="text-slate-600">

package/app/components/panels/ResultWindowShell.vue

@@ -25,7 +25,9 @@ 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 StepReproductionReport from '~/components/panels/StepReproductionReport.vue'
 import BinaryOutputReport from '~/components/binaryOutput/BinaryOutputReport.vue'
+import { REPRODUCTION_STATUS_KEYS } from '~/utils/reproduction'
 import {
   BINARY_OUTPUT_STATE_KEYS,
   binaryOutputHasWarnings,
@@ -146,6 +148,34 @@ watch(
   },
   { immediate: true },
 )
+/**
+ * The step's BUGFIX REPRODUCTION PROOF — resolved off the active step for the same reason as the
+ * three sections around it: the engine writes it onto whichever step OPENED the pull request, which
+ * is a property of the dispatch rather than of the step's own kind, so no window may be able to opt
+ * out of showing it. Absent for every run that declared no reproducing check, and the section
+ * disappears.
+ */
+const reproductionReport = computed(() => activeStep.value?.reproduction ?? null)
+const reproductionOpen = ref(false)
+// Anything short of proof opens expanded: an `inconclusive` verdict and a structural infeasibility
+// declaration are both things a reviewer has to read and weigh, where `reproduced` is the one
+// answer a collapsed one-line row states completely.
+watch(
+  reproductionReport,
+  (report) => {
+    if (report && report.status !== 'reproduced') reproductionOpen.value = true
+  },
+  { immediate: true },
+)
+/**
+ * The verdict's copy, icon and tone, from the EXHAUSTIVE lookup keyed off the contracts union
+ * rather than a t() call over a key assembled at runtime: the typed-key check cannot see such a
+ * key, so a fourth verdict would ship as a blank chip on the surface whose whole job is saying what
+ * was and was not proven.
+ */
+const reproductionKeys = computed(() =>
+  reproductionReport.value ? REPRODUCTION_STATUS_KEYS[reproductionReport.value.status] : null,
+)
 /**
  * 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
@@ -357,6 +387,53 @@ const panelClass = computed(() => [
           </div>
         </section>
 
+        <!-- Shared trailing section: the bugfix reproduction proof (the declared check run against
+             the pre-fix tree and the final one). Collapsed when it proved the fix, expanded when it
+             did not — an inconclusive verdict or an infeasibility declaration is the one a reviewer
+             opened the window to read. -->
+        <section
+          v-if="reproductionReport"
+          class="shrink-0 border-t border-slate-800 bg-slate-900/60"
+          data-testid="result-window-reproduction"
+        >
+          <button
+            type="button"
+            class="flex w-full items-center gap-2 px-5 py-2 text-start hover:bg-slate-800/40"
+            :aria-expanded="reproductionOpen"
+            data-testid="result-window-reproduction-toggle"
+            @click="reproductionOpen = !reproductionOpen"
+          >
+            <UIcon
+              :name="reproductionKeys!.icon"
+              class="h-3.5 w-3.5 shrink-0"
+              :class="reproductionKeys!.proven ? 'text-emerald-400' : 'text-amber-400'"
+            />
+            <span class="text-[11px] font-semibold uppercase tracking-wide text-slate-400">
+              {{ t('panels.stepDetail.reproduction.heading') }}
+            </span>
+            <span
+              class="shrink-0 rounded px-1.5 py-0.5 text-[11px] font-medium"
+              :class="
+                reproductionKeys!.proven
+                  ? 'bg-emerald-500/15 text-emerald-300'
+                  : 'bg-amber-500/15 text-amber-300'
+              "
+            >
+              {{ t(reproductionKeys!.chip) }}
+            </span>
+            <span class="min-w-0 flex-1 truncate text-[12px] text-slate-400">
+              {{ t(reproductionKeys!.verdict) }}
+            </span>
+            <UIcon
+              :name="reproductionOpen ? '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="reproductionOpen" class="max-h-72 overflow-y-auto px-5 pb-3">
+            <StepReproductionReport :report="reproductionReport" />
+          </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

package/app/components/panels/StepReproductionReport.vue

@@ -0,0 +1,167 @@
+<script setup lang="ts">
+import { computed } from 'vue'
+import type { ReproductionPhaseOutcome, ReproductionReport } from '~/types/reproduction'
+import { REPRODUCTION_STATUS_KEYS, REPRODUCTION_TREE_KEYS } from '~/utils/reproduction'
+
+// The BUGFIX REPRODUCTION PROOF for a step: the declared reproducing check as the
+// executor-harness ran it against the pre-fix tree and against the final tree, with both captured
+// outputs. The verdict is computed from the two exit codes by the harness — never self-reported by
+// the model, which is the entire point (the `repro-test` kind's own `outcome` has always been the
+// agent's CLAIM, and this is what checks it). See
+// backend/docs/adr/0033-bugfix-reproduction-proof.md.
+//
+// Two callers, one renderer, exactly as `StepEffortReport` has: 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. BOTH are needed, and that is the point: the engine records the proof on whichever
+// step OPENED the pull request — in every built-in pipeline the `coder`, whose kind declares no
+// result view and therefore opens the step-detail panel the shell is not involved in.
+const props = withDefaults(
+  defineProps<{ report: ReproductionReport; variant?: 'card' | 'flat' }>(),
+  { variant: 'flat' },
+)
+const { t } = useI18n()
+
+/**
+ * The two trees, as rows. An ABSENT final run is normal rather than missing data: a green pre-fix
+ * tree already settles the verdict, so running the second one could only confirm what is already
+ * not proof — and each run costs a full setup plus test. The row says which, instead of leaving a
+ * blank a reader would read as a failure to record.
+ */
+const phases = computed(() => [
+  { key: 'base' as const, label: REPRODUCTION_TREE_KEYS.base, outcome: props.report.base },
+  { key: 'final' as const, label: REPRODUCTION_TREE_KEYS.final, outcome: props.report.final },
+])
+
+/** The verdict's copy + icon, from the exhaustive lookup rather than an assembled key. */
+const presentation = computed(() => REPRODUCTION_STATUS_KEYS[props.report.status])
+
+/** A phase's result chip: setup failure and timeout are their own answers, not plain failures. */
+function phaseLabel(outcome: ReproductionPhaseOutcome): string {
+  if (outcome.setupFailed) return t('panels.stepDetail.reproduction.setupFailed')
+  if (outcome.timedOut) return t('panels.stepDetail.reproduction.timedOut')
+  return outcome.passed
+    ? t('panels.stepDetail.reproduction.passed')
+    : t('panels.stepDetail.reproduction.exitCode', { code: outcome.exitCode })
+}
+</script>
+
+<template>
+  <section
+    class="space-y-2"
+    data-testid="step-reproduction-report"
+    :class="
+      variant === 'card' ? 'scroll-mt-4 rounded-xl border border-slate-800 bg-slate-900/50 p-4' : ''
+    "
+  >
+    <div
+      v-if="variant === 'card'"
+      class="flex items-center gap-1.5 text-[11px] font-semibold uppercase tracking-wide text-slate-400"
+    >
+      <UIcon :name="presentation.icon" class="h-3.5 w-3.5" />
+      <span>{{ t('panels.stepDetail.reproduction.heading') }}</span>
+    </div>
+
+    <p class="text-[11px] text-slate-400" data-testid="reproduction-verdict">
+      {{ t(presentation.verdict) }}
+    </p>
+
+    <!-- The producer's own one-line diagnosis, rendered VERBATIM. Only the side that ran the two
+         trees can tell a test that misses the defect from a resumed run whose pre-fix tree already
+         carried this step's own interrupted work, so re-deriving a cause from the exit codes here
+         is exactly the inference that gets it wrong. -->
+    <p v-if="report.note" class="text-[11px] text-amber-300" data-testid="reproduction-observation">
+      {{ report.note }}
+    </p>
+
+    <!-- A structural infeasibility declaration: the reason, and what the agent verified instead.
+         This is what keeps "could not be reproduced" from looking like "nobody tried". -->
+    <template v-if="report.status === 'declared_infeasible'">
+      <div v-if="report.reason" class="rounded-md border border-slate-800 bg-slate-950/40 p-2">
+        <p class="text-[11px] font-semibold uppercase tracking-wide text-slate-400">
+          {{ t('panels.stepDetail.reproduction.reason') }}
+        </p>
+        <p class="mt-1 whitespace-pre-wrap text-[12px] text-slate-300">{{ report.reason }}</p>
+      </div>
+      <div
+        v-if="report.alternativeVerification"
+        class="rounded-md border border-slate-800 bg-slate-950/40 p-2"
+      >
+        <p class="text-[11px] font-semibold uppercase tracking-wide text-slate-400">
+          {{ t('panels.stepDetail.reproduction.alternative') }}
+        </p>
+        <p class="mt-1 whitespace-pre-wrap text-[12px] text-slate-300">
+          {{ report.alternativeVerification }}
+        </p>
+      </div>
+    </template>
+
+    <template v-else>
+      <div v-if="report.command" class="flex items-baseline gap-2">
+        <span class="shrink-0 text-[11px] text-slate-500">{{
+          t('panels.stepDetail.reproduction.command')
+        }}</span>
+        <span class="truncate font-mono text-[11px] text-slate-300">{{ report.command }}</span>
+      </div>
+
+      <!-- A dropped path can leave the pre-fix tree without the reproduction, which greens it and
+           reads as "the test does not capture the defect". Stated, never implied. -->
+      <p
+        v-if="report.omittedTestPaths"
+        class="text-[11px] text-amber-300"
+        data-testid="reproduction-omitted-paths"
+      >
+        {{
+          t(
+            'panels.stepDetail.reproduction.omittedTestPaths',
+            { count: report.omittedTestPaths },
+            report.omittedTestPaths,
+          )
+        }}
+      </p>
+
+      <div
+        v-for="phase in phases"
+        :key="phase.key"
+        class="rounded-md border border-slate-800 bg-slate-950/40 p-2"
+        data-testid="reproduction-phase"
+      >
+        <div class="flex items-center gap-2">
+          <UIcon
+            :name="phase.outcome?.passed ? 'i-lucide-check' : 'i-lucide-x'"
+            class="h-3.5 w-3.5 shrink-0"
+            :class="
+              phase.outcome
+                ? phase.outcome.passed
+                  ? 'text-emerald-400'
+                  : 'text-rose-400'
+                : 'text-slate-600'
+            "
+          />
+          <span class="text-[12px] font-medium text-slate-200">
+            {{ t(phase.label) }}
+          </span>
+          <span class="ms-auto shrink-0 text-[11px] tabular-nums text-slate-400">
+            {{
+              phase.outcome ? phaseLabel(phase.outcome) : t('panels.stepDetail.reproduction.notRun')
+            }}
+          </span>
+        </div>
+        <pre
+          v-if="phase.outcome?.outputTail"
+          class="mt-1.5 max-h-48 overflow-auto whitespace-pre-wrap break-words rounded bg-slate-950 p-2 font-mono text-[11px] text-slate-400"
+          data-testid="reproduction-output"
+          >{{ phase.outcome.outputTail }}</pre>
+      </div>
+
+      <p class="text-[11px] text-slate-500">
+        {{
+          t('panels.stepDetail.reproduction.attempts', {
+            attempts: report.attempts,
+            maxAttempts: report.maxAttempts,
+          })
+        }}
+      </p>
+    </template>
+  </section>
+</template>