@cat-factory/app 0.182.0 → 0.182.1

package/README.md

@@ -177,9 +177,13 @@ Two placements are load-bearing enough to state, because putting a new one in th
 wrong place is invisible until a user cannot find it:
 
 - **The sidebar section is a claim about what the destination IS.** `models` is the
-  engines, `integrations` the optional systems, `infrastructure` where agent
-  containers and test environments run, `configuration` workspace/account settings.
-  `nav-contributions.spec.ts` pins the section order and each section's membership.
+  model layer — the engines, the per-agent model choice, and the surfaces that
+  evaluate a prompt+agent+model combination (Sandbox, Kaizen); `integrations` the
+  optional EXTERNAL systems; `infrastructure` where agent containers and test
+  environments run; `configuration` workspace/account settings. A surface that
+  connects to nothing does not belong in `integrations` however configuration-shaped
+  it feels. `nav-contributions.spec.ts` pins the section order and each section's
+  membership.
 - **A flow that edits ONE entity's config is a section of the window that owns that
   config, not a sibling nav entry.** The guided Docker Compose environment setup
   (`ComposeEnvironmentSetupSection.vue` → `EnvironmentSetupWizard.vue`) lives inside

package/app/components/board/nodes/BlockNode.vue

@@ -83,12 +83,22 @@ const selected = computed(() => ui.selectedBlockId === props.id)
 // kept (gated off) so the prior behaviour is one edit away if we want chips back.
 const showExpanded = computed(() => true)
 
-// Surface a pending decision from this frame OR any of its tasks (O(tasks) map
+// Every child whose parked run the frame badge speaks for: its tasks AND its initiative
+// blocks. An initiative is a frame child like a module and runs an ordinary pipeline (its
+// planner parks on a real approval gate), so leaving it out made a whole class of parked run
+// invisible at frame level — the badge read "nothing needs you" while a plan sat waiting.
+const attentionIds = computed(() => {
+  const ids = new Set(taskIds.value)
+  for (const i of initiativeBlocks.value) ids.add(i.id)
+  return ids
+})
+
+// Surface a pending decision from this frame OR any of its children (O(children) map
 // lookups, not a scan of every open decision per frame).
 const blockDecisions = computed(() => {
   const byBlock = execution.decisionsByBlock
   const out = [...(byBlock.get(props.id) ?? [])]
-  for (const id of taskIds.value) {
+  for (const id of attentionIds.value) {
     const list = byBlock.get(id)
     if (list) out.push(...list)
   }
@@ -100,14 +110,14 @@ function openFirstDecision() {
   if (d) ui.openDecision(d.instanceId, d.decision.id)
 }
 
-// Surface a pending approval gate from this frame OR any of its tasks — but NOT an
+// Surface a pending approval gate from this frame OR any of its children — but NOT an
 // iterative reviewer gate (requirements-review / clarity-review) that's mid-cycle
 // (incorporating / re-reviewing in the driver), which is background work needing no human,
 // so it stays off the frame's "Approval" badge.
 const blockApprovals = computed(() => {
   const byBlock = execution.approvalsByBlock
   const candidates = [...(byBlock.get(props.id) ?? [])]
-  for (const id of taskIds.value) {
+  for (const id of attentionIds.value) {
     const list = byBlock.get(id)
     if (list) candidates.push(...list)
   }

package/app/components/board/nodes/InitiativeCard.vue

@@ -5,12 +5,18 @@
 // initiative's equivalent "Run planning" (and, while parked mid-interview, "Answer
 // planning questions") lives right here on the board — the same actions the
 // inspector offers — so starting an initiative isn't hidden behind selecting it.
+// It likewise mirrors a task card's `attention` affordance: a planning run parked
+// on the plan-approval gate (or on an agent-raised decision) offers the button that
+// opens the window resolving it, instead of leaving the card on a spinning "Run
+// planning" whose only route in was the inspector's execution panel.
 // The tracker button opens the dedicated window directly. Draggable within its
 // frame like a task card.
 import type { InitiativeStatus } from '~/types/domain'
 import { useBlockDrag } from '~/composables/useBlockDrag'
 import { useInitiativePlanning } from '~/composables/useInitiativePlanning'
 import {
+  INITIATIVE_ATTENTION_ICONS,
+  INITIATIVE_ATTENTION_LABEL_KEYS,
   INITIATIVE_STATUS_CHIPS,
   INITIATIVE_STATUS_LABEL_KEYS,
   initiativeProgress,
@@ -40,6 +46,7 @@ const {
   running,
   awaitingAnswers,
   interviewing,
+  attention,
   starting,
   runPlanning,
   openPlanning,
@@ -79,7 +86,10 @@ function onHandle(e: PointerEvent) {
       data-testid="initiative-card"
       :data-status="status"
       class="cursor-pointer rounded-b-lg border border-indigo-800/60 bg-indigo-950/40 p-3 transition hover:border-indigo-600"
-      :class="[selected ? 'ring-2 ring-indigo-400/60' : '', awaitingAnswers ? 'board-pulse' : '']"
+      :class="[
+        selected ? 'ring-2 ring-indigo-400/60' : '',
+        awaitingAnswers || attention ? 'board-pulse' : '',
+      ]"
       @click.stop="select"
     >
       <div class="flex items-start justify-between gap-2">
@@ -106,8 +116,23 @@ function onHandle(e: PointerEvent) {
         </div>
       </div>
       <div class="nodrag mt-2 flex flex-wrap items-center gap-1">
+        <!-- Parked for a human: the drafted plan awaits approval, or an agent raised a
+             decision. Opens the window that can resolve the park (never the generic panel,
+             which the server refuses for a park a dedicated window owns). -->
         <UButton
-          v-if="awaitingAnswers"
+          v-if="attention"
+          data-testid="initiative-card-review"
+          :data-attention="attention.kind"
+          size="xs"
+          variant="solid"
+          color="warning"
+          :icon="INITIATIVE_ATTENTION_ICONS[attention.kind]"
+          @click.stop="attention.open()"
+        >
+          {{ t(INITIATIVE_ATTENTION_LABEL_KEYS[attention.kind]) }}
+        </UButton>
+        <UButton
+          v-else-if="awaitingAnswers"
           data-testid="initiative-card-answer-planning"
           size="xs"
           variant="solid"

package/app/components/initiative/InitiativeTrackerWindow.vue

@@ -1,14 +1,20 @@
 <script setup lang="ts">
-// The initiative tracker window — the dedicated read-only view of an initiative's
-// plan/tracker entity: goal + constraints, the phases with their per-item status +
-// PR links, the execution policy, and the decisions / deviations / follow-ups /
-// caveats logs. Renders the DB entity (the source of truth) — never the in-repo
-// mirror, which may not exist (GitHub-unwired workspaces). Opened via the universal
-// result-view host: from the board card / inspector (`ui.openInitiativeTracker`) or
-// as the planner step's result view. Live `initiative` stream events patch the
-// store, so an open window follows the plan as it is ingested and later executed.
-import { computed, reactive, ref } from 'vue'
+// The initiative tracker window — the dedicated view of an initiative's plan/tracker
+// entity: goal + constraints, the phases with their per-item status + PR links, the
+// execution policy, and the decisions / deviations / follow-ups / caveats logs.
+// Renders the DB entity (the source of truth) — never the in-repo mirror, which may
+// not exist (GitHub-unwired workspaces). Opened via the universal result-view host:
+// from the board card / inspector (`ui.openInitiativeTracker`) or as the planner
+// step's result view. Live `initiative` stream events patch the store, so an open
+// window follows the plan as it is ingested and later executed.
+//
+// It also OWNS the planner's plan-approval gate: this window is where the planner
+// step's park routes (its archetype declares this result view), so the approve /
+// request-changes rail has to live here or the gate has no resolving surface at all —
+// which is exactly how an approved-only-over-REST plan gate shipped.
+import { computed, reactive, ref, watch } from 'vue'
 import type { InitiativeFollowUp, InitiativeItem } from '~/types/domain'
+import { useInitiativePlanning } from '~/composables/useInitiativePlanning'
 import {
   INITIATIVE_FOLLOWUP_STATUS_CHIPS,
   INITIATIVE_FOLLOWUP_STATUS_LABEL_KEYS,
@@ -23,6 +29,8 @@ import StepRunMeta from '~/components/panels/StepRunMeta.vue'
 
 const board = useBoardStore()
 const initiatives = useInitiativesStore()
+const execution = useExecutionStore()
+const access = useWorkspaceAccess()
 const { t } = useI18n()
 const toast = useToast()
 
@@ -92,6 +100,58 @@ async function checkpointControl(action: 'resume' | 'cancel') {
   }
 }
 
+// ---- Plan review: the planner step's human gate, resolved right here -----------------------
+// Derived from the BLOCK (via the shared planning composable), not from this window's own
+// `stepIndex`: the card / inspector open the tracker with no step, and that is the entry point a
+// human parked on the gate actually uses. So the rail appears on every route into the window.
+const { planApproval } = useInitiativePlanning(() => blockId.value ?? '')
+
+/** Draft feedback for "request changes" (the planner re-runs with it), and the rail's in-flight
+ *  state. Reset when a different initiative opens so a draft can't follow the window. */
+const planFeedback = ref('')
+const requestingChanges = ref(false)
+const resolvingPlan = ref(false)
+watch(blockId, () => {
+  planFeedback.value = ''
+  requestingChanges.value = false
+})
+
+const canRequestChanges = computed(() => planFeedback.value.trim().length > 0)
+
+/**
+ * Accept the drafted plan: the run advances to the committer, which persists the initiative and
+ * arms the execution loop. The window deliberately stays OPEN — the rail disappears with the
+ * approval (live), and the tracker is where the plan then starts executing.
+ */
+async function approvePlan() {
+  const parked = planApproval.value
+  if (!parked || resolvingPlan.value) return
+  resolvingPlan.value = true
+  try {
+    await execution.approveStep(parked.instanceId, parked.approval.id)
+  } finally {
+    resolvingPlan.value = false
+  }
+}
+
+/** Send the plan back to the planner with what to change; it re-plans and parks again. */
+async function submitPlanChanges() {
+  const parked = planApproval.value
+  if (!parked || resolvingPlan.value || !canRequestChanges.value) return
+  resolvingPlan.value = true
+  try {
+    const ok = await execution.requestStepChanges(parked.instanceId, parked.approval.id, {
+      feedback: planFeedback.value.trim(),
+    })
+    if (ok) {
+      planFeedback.value = ''
+      requestingChanges.value = false
+    }
+  } finally {
+    resolvingPlan.value = false
+  }
+}
+
 const policyRules = computed(() => initiative.value?.policy?.rules ?? [])
 function ruleAxes(rule: { minComplexity?: number; minRisk?: number; minImpact?: number }): string {
   const axes = [
@@ -234,6 +294,86 @@ async function savePolicy() {
         </div>
 
         <template v-else>
+          <!-- The planner's human gate: the plan below is drafted but NOT yet committed. This
+               is the only surface that can resolve it (the generic approval panel is never
+               reached — the planner's archetype routes its park to this window), so approve /
+               request changes live here, beside the plan they judge. -->
+          <section
+            v-if="planApproval"
+            class="mb-4 rounded-lg border border-amber-500/40 bg-amber-500/10 p-3.5"
+            data-testid="initiative-plan-review"
+          >
+            <div class="flex items-start gap-2.5">
+              <UIcon
+                name="i-lucide-clipboard-check"
+                class="mt-0.5 h-4 w-4 shrink-0 text-amber-300"
+              />
+              <div class="min-w-0 flex-1">
+                <h3 class="text-[13px] font-semibold text-amber-200">
+                  {{ t('initiative.planReview.title') }}
+                </h3>
+                <p class="mt-0.5 text-[12px] leading-relaxed text-amber-100/80">
+                  {{ t('initiative.planReview.body') }}
+                </p>
+                <div v-if="!requestingChanges" class="mt-2.5 flex flex-wrap gap-2">
+                  <button
+                    class="rounded bg-indigo-600 px-2.5 py-1 text-[11px] font-medium text-white hover:bg-indigo-500 disabled:opacity-50"
+                    :disabled="resolvingPlan || !access.canExecuteRuns.value"
+                    :title="access.canExecuteRuns.value ? undefined : t('access.noRunExecute')"
+                    data-testid="initiative-plan-approve"
+                    @click="approvePlan"
+                  >
+                    {{ t('initiative.planReview.approve') }}
+                  </button>
+                  <button
+                    class="rounded border border-amber-400/50 px-2.5 py-1 text-[11px] font-medium text-amber-200 hover:bg-amber-500/10 disabled:opacity-50"
+                    :disabled="resolvingPlan || !access.canExecuteRuns.value"
+                    :title="access.canExecuteRuns.value ? undefined : t('access.noRunExecute')"
+                    data-testid="initiative-plan-request-changes"
+                    @click="requestingChanges = true"
+                  >
+                    {{ t('initiative.planReview.requestChanges') }}
+                  </button>
+                </div>
+                <!-- Request-changes composer: the feedback is what the planner re-plans FROM,
+                     so it is required — an empty send would re-run the planner with nothing
+                     to act on and park again on the same plan. -->
+                <div v-else class="mt-2.5">
+                  <UTextarea
+                    v-model="planFeedback"
+                    :rows="3"
+                    autoresize
+                    size="sm"
+                    class="w-full"
+                    data-testid="initiative-plan-feedback"
+                    :placeholder="t('initiative.planReview.feedbackPlaceholder')"
+                  />
+                  <div class="mt-2 flex flex-wrap gap-2">
+                    <button
+                      class="rounded bg-amber-500 px-2.5 py-1 text-[11px] font-medium text-slate-950 hover:bg-amber-400 disabled:opacity-50"
+                      :disabled="
+                        resolvingPlan || !canRequestChanges || !access.canExecuteRuns.value
+                      "
+                      :title="access.canExecuteRuns.value ? undefined : t('access.noRunExecute')"
+                      data-testid="initiative-plan-send-back"
+                      @click="submitPlanChanges"
+                    >
+                      {{ t('initiative.planReview.sendBack') }}
+                    </button>
+                    <button
+                      class="rounded border border-slate-600 px-2.5 py-1 text-[11px] font-medium text-slate-300 hover:bg-slate-800 disabled:opacity-50"
+                      :disabled="resolvingPlan"
+                      data-testid="initiative-plan-cancel-changes"
+                      @click="requestingChanges = false"
+                    >
+                      {{ t('common.cancel') }}
+                    </button>
+                  </div>
+                </div>
+              </div>
+            </div>
+          </section>
+
           <!-- Paused at a phase checkpoint (D2): a completed checkpoint phase is awaiting
                    review before the next phase spawns. Read the phase's artifacts/PRs below,
                    then resume (continue) or cancel (stop) the initiative right here. -->

package/app/components/panels/inspector/InitiativeInspector.vue

@@ -6,7 +6,12 @@
 // with slice 4.
 import type { Block, InitiativeStatus } from '~/types/domain'
 import { useInitiativePlanning } from '~/composables/useInitiativePlanning'
-import { INITIATIVE_STATUS_LABEL_KEYS, initiativeProgress } from '~/utils/initiative'
+import {
+  INITIATIVE_ATTENTION_ICONS,
+  INITIATIVE_ATTENTION_LABEL_KEYS,
+  INITIATIVE_STATUS_LABEL_KEYS,
+  initiativeProgress,
+} from '~/utils/initiative'
 
 const props = defineProps<{ block: Block }>()
 
@@ -24,6 +29,7 @@ const {
   running,
   awaitingAnswers,
   interviewing,
+  attention,
   starting,
   runPlanning,
   openPlanning,
@@ -56,8 +62,23 @@ function control(action: 'pause' | 'resume' | 'cancel') {
     </p>
 
     <div class="flex flex-wrap items-center gap-2">
+      <!-- Parked for a human (the drafted plan awaits approval, or an agent raised a decision).
+           The same affordance the board card carries, resolved from the same composable — the
+           run's park must not be reachable only through the execution panel's step list. -->
       <UButton
-        v-if="awaitingAnswers"
+        v-if="attention"
+        data-testid="initiative-review"
+        :data-attention="attention.kind"
+        color="warning"
+        variant="solid"
+        size="sm"
+        :icon="INITIATIVE_ATTENTION_ICONS[attention.kind]"
+        @click="attention.open()"
+      >
+        {{ t(INITIATIVE_ATTENTION_LABEL_KEYS[attention.kind]) }}
+      </UButton>
+      <UButton
+        v-else-if="awaitingAnswers"
         data-testid="initiative-answer-planning"
         color="primary"
         variant="solid"

package/app/composables/useInitiativePlanning.ts

@@ -4,12 +4,25 @@ import { useExecutionStore } from '~/stores/execution'
 import { useInitiativesStore } from '~/stores/initiative'
 import { usePipelinesStore } from '~/stores/pipelines'
 import { useUiStore } from '~/stores/ui'
+import { agentKindMeta } from '~/utils/catalog'
+import { selectPlanApproval, type InitiativeAttentionKind } from '~/utils/initiative'
 import {
   INITIATIVE_INTERVIEWER_KIND,
   interviewGatePhase,
   interviewStepReached,
 } from '~/utils/interviewGate'
 
+/**
+ * What an initiative's planning run needs from a human right now: which kind of park it is (the
+ * card + inspector resolve its icon/label from the shared `INITIATIVE_ATTENTION_*` maps, so the
+ * two surfaces word one park identically), and the action that opens the surface which can
+ * RESOLVE it — the step's own dedicated window, via `dispatchStepView`.
+ */
+export interface InitiativeAttention {
+  kind: InitiativeAttentionKind
+  open: () => void
+}
+
 /**
  * Shared planning affordances for an `initiative`-level block, used by BOTH the board card
  * (`InitiativeCard`) and the inspector (`InitiativeInspector`) so the two surfaces can never drift
@@ -83,6 +96,60 @@ export function useInitiativePlanning(blockId: MaybeRefOrGetter<string>) {
     () => interviewPhase.value === 'working' || interviewPhase.value === 'preparing',
   )
 
+  /**
+   * The planner's parked plan-approval gate, or undefined. `pl_initiative` gates the planner step
+   * (`{ kind: 'initiative-planner', gate: true }`), so a finished planning pass PARKS the run on a
+   * pending `step.approval` until a human accepts the plan — the state this composable's other
+   * flags deliberately do NOT cover (the interview has converged, and the run is `blocked`, so
+   * `awaitingAnswers` and `interviewing` are both false and the card would otherwise sit on a
+   * disabled, spinning "Run planning").
+   *
+   * The interviewer's own park is excluded by the window its step routes to (see
+   * {@link selectPlanApproval}), not by the interview phase, so the two affordances can never both
+   * claim one park.
+   */
+  const planApproval = computed(() =>
+    selectPlanApproval(
+      execution.approvalsByBlock.get(toValue(blockId)) ?? [],
+      (kind) => agentKindMeta(kind).resultView,
+    ),
+  )
+
+  /** An agent-raised decision on the planning run (the analyst is an ordinary agent step). */
+  const pendingDecision = computed(() => execution.decisionsByBlock.get(toValue(blockId))?.[0])
+
+  /**
+   * The single thing a human has to act on, or null — the initiative dual of a task card's
+   * `attention`. A decision outranks an approval (a step never holds both; this is just a stable
+   * order). Opening always goes through the step-view dispatch, so the park lands in the window
+   * that can RESOLVE it (the plan gate → the tracker window's plan-review rail) rather than a
+   * generic panel that would refuse it.
+   */
+  const attention = computed<InitiativeAttention | null>(() => {
+    const id = toValue(blockId)
+    const decision = pendingDecision.value
+    if (decision) {
+      return {
+        kind: 'decision',
+        open: () => {
+          ui.select(id)
+          ui.openDecision(decision.instanceId, decision.decision.id)
+        },
+      }
+    }
+    const approval = planApproval.value
+    if (approval) {
+      return {
+        kind: 'approval',
+        open: () => {
+          ui.select(id)
+          ui.openApprovalDetail(approval.instanceId, approval.approval.id)
+        },
+      }
+    }
+    return null
+  })
+
   /**
    * Optimistic start flag: flip true the instant "Run planning" is clicked, before the stream
    * pushes the block's `executionId` back. Cleared the moment `running` takes over (success) or the
@@ -123,6 +190,9 @@ export function useInitiativePlanning(blockId: MaybeRefOrGetter<string>) {
     interviewPhase,
     awaitingAnswers,
     interviewing,
+    planApproval,
+    pendingDecision,
+    attention,
     starting,
     runPlanning,
     openPlanning,

package/app/modular/nav-contributions.spec.ts

@@ -285,10 +285,20 @@ describe('nav grouping helpers', () => {
       'workspaceContext',
       'configuration',
     ])
-    // The engines are their own section, ahead of the optional integrations; `model-config`
-    // sits beside the providers it picks models from rather than under `configuration`.
+    // The model layer is its own section, ahead of the optional integrations: the engines,
+    // the per-agent model choice (beside the providers it picks from, rather than under
+    // `configuration`), and the two surfaces that evaluate a prompt+agent+model. Sandbox and
+    // Kaizen used to sit under `integrations`, which read as a claim they connect to an
+    // external system; they don't — they exercise and grade what this section configures.
     const models = groups.find((g) => g.group === 'models')
-    expect(models?.items.map((i) => i.id)).toEqual(['model-providers', 'model-config'])
+    expect(models?.items.map((i) => i.id)).toEqual([
+      'model-providers',
+      'model-config',
+      'sandbox',
+      'kaizen',
+    ])
+    const integrations = groups.find((g) => g.group === 'integrations')
+    expect(integrations?.items.map((i) => i.id)).toEqual(['integrations-hub'])
     const configuration = groups.find((g) => g.group === 'configuration')
     expect(configuration?.items.map((i) => i.id)).toEqual([
       'workspace-settings',

package/app/modular/nav-contributions.ts

@@ -30,11 +30,15 @@ export type NavSurface = 'sidebar' | 'command' | 'toolbar'
  *
  * `models` and `integrations` are deliberately SEPARATE sections even though a model
  * provider is technically also an external system we connect to. They answer different
- * questions: `models` is the ENGINE the harnesses run on (no provider ⇒ nothing runs at
- * all), `integrations` is the optional systems that feed a run context or receive its
- * output (source control, trackers, documents, chat, observability) — each of which a
- * deployment can live without. Folding the providers in among them buried the one
- * connection every deployment must make in a list of ones most never touch.
+ * questions: `models` is the MODEL LAYER — which engine the harnesses run on (no provider
+ * ⇒ nothing runs at all), which model each agent kind uses, and how well a given
+ * prompt+agent+model actually performs (`sandbox`, `kaizen`); `integrations` is the
+ * optional EXTERNAL SYSTEMS that feed a run context or receive its output (source control,
+ * trackers, documents, chat, observability) — each of which a deployment can live without.
+ * Folding the providers in among them buried the one connection every deployment must make
+ * in a list of ones most never touch; parking the two model-quality surfaces there was the
+ * same mistake from the other end — neither Sandbox nor Kaizen connects to anything, they
+ * evaluate what the `models` section configures.
  */
 export type NavSidebarGroup =
   | 'create'
@@ -268,33 +272,6 @@ export const NAV_CONTRIBUTIONS: readonly NavContribution[] = [
     testId: 'nav-integrations',
     sidebar: { group: 'integrations', order: 10 },
   },
-  {
-    id: 'sandbox',
-    labelKey: 'nav.sandbox',
-    icon: 'i-lucide-flask-conical',
-    surfaces: S('sidebar', 'command'),
-    advanced: true,
-    gate: (g) => g.canManageIntegrations,
-    action: 'sandbox',
-    testId: 'nav-sandbox',
-    sidebar: { group: 'integrations', order: 20 },
-    command: {
-      group: 'workspace',
-      order: 70,
-      labelKey: 'layout.commandBar.cmd.sandbox',
-      keywordsKey: 'layout.commandBar.keywords.sandbox',
-    },
-  },
-  {
-    id: 'kaizen',
-    labelKey: 'nav.kaizen',
-    icon: 'i-lucide-sparkles',
-    surfaces: S('sidebar'),
-    advanced: true,
-    action: 'kaizen',
-    testId: 'nav-kaizen',
-    sidebar: { group: 'integrations', order: 30 },
-  },
   {
     id: 'infrastructure',
     labelKey: 'nav.infrastructure',
@@ -370,6 +347,39 @@ export const NAV_CONTRIBUTIONS: readonly NavContribution[] = [
       keywordsKey: 'layout.commandBar.keywords.modelConfiguration',
     },
   },
+  {
+    // Trying prompt versions and models against graded fixtures — a model-layer surface,
+    // not an integration: it connects to no external system, it exercises the providers
+    // and per-agent models the two entries above configure.
+    id: 'sandbox',
+    labelKey: 'nav.sandbox',
+    icon: 'i-lucide-flask-conical',
+    surfaces: S('sidebar', 'command'),
+    advanced: true,
+    gate: (g) => g.canManageIntegrations,
+    action: 'sandbox',
+    testId: 'nav-sandbox',
+    sidebar: { group: 'models', order: 30 },
+    command: {
+      group: 'workspace',
+      order: 70,
+      labelKey: 'layout.commandBar.cmd.sandbox',
+      keywordsKey: 'layout.commandBar.keywords.sandbox',
+    },
+  },
+  {
+    // The same axis after the fact: grading history and verified prompt+agent+model combos.
+    // Sandbox asks "which combination should we use", Kaizen answers "how is the one we
+    // shipped doing" — both read the model layer, so they sit with it.
+    id: 'kaizen',
+    labelKey: 'nav.kaizen',
+    icon: 'i-lucide-sparkles',
+    surfaces: S('sidebar'),
+    advanced: true,
+    action: 'kaizen',
+    testId: 'nav-kaizen',
+    sidebar: { group: 'models', order: 40 },
+  },
   {
     id: 'service-fragment-defaults',
     labelKey: 'layout.commandBar.cmd.serviceFragmentDefaults',

package/app/utils/initiative.spec.ts

@@ -1,7 +1,12 @@
 import { INITIATIVE_ITEM_TERMINAL_STATUSES } from '@cat-factory/contracts'
 import { describe, it, expect } from 'vitest'
 import type { InitiativeItem, InitiativePhase, InitiativeQa } from '~/types/domain'
-import { isPendingQuestion, orderInterviewQuestions, pendingCheckpointPhase } from './initiative'
+import {
+  isPendingQuestion,
+  orderInterviewQuestions,
+  pendingCheckpointPhase,
+  selectPlanApproval,
+} from './initiative'
 
 // `pendingCheckpointPhase` mirrors the backend `pendingCheckpoint` (orchestration
 // `initiative.logic.ts`); these pin the same ordering/edge cases the loop pauses on, so the
@@ -150,3 +155,48 @@ describe('orderInterviewQuestions', () => {
     expect(orderInterviewQuestions([])).toEqual([])
   })
 })
+
+// The plan-review park: which of a block's pending approvals the board card / inspector offer as
+// "Review plan", and which one they must leave alone. Both gates on the planning pipeline park on
+// a `step.approval`, so the interviewer's park (owned by the planning window's "Answer planning
+// questions") is the case this selector exists to keep out — offering it here would give one park
+// two differently-worded buttons, and the tracker window it opened could not resolve it.
+
+/** A pending approval as `execution.approvalsByBlock` carries it (only the fields read here). */
+const parked = (agentKind: string, id: string) => ({ agentKind, approval: { id } })
+
+/** The catalog's result-view resolver, as the composable passes it in. */
+const resultViewOf = (kind: string): string | undefined =>
+  kind === 'initiative-interviewer'
+    ? 'initiative-planning'
+    : kind.startsWith('initiative-')
+      ? 'initiative-tracker'
+      : undefined
+
+describe('selectPlanApproval', () => {
+  it('is undefined when nothing is parked', () => {
+    expect(selectPlanApproval([], resultViewOf)).toBeUndefined()
+  })
+
+  it('picks the planner gate — the plan awaiting approval', () => {
+    const approvals = [parked('initiative-planner', 'ap_1')]
+    expect(selectPlanApproval(approvals, resultViewOf)?.approval.id).toBe('ap_1')
+  })
+
+  it('leaves the interviewer park to the planning window', () => {
+    const approvals = [parked('initiative-interviewer', 'ap_interview')]
+    expect(selectPlanApproval(approvals, resultViewOf)).toBeUndefined()
+  })
+
+  it('finds the plan gate past an interview park (a re-run interviewing again)', () => {
+    const approvals = [parked('initiative-interviewer', 'ap_interview'), parked('x', 'ap_plan')]
+    expect(selectPlanApproval(approvals, resultViewOf)?.approval.id).toBe('ap_plan')
+  })
+
+  it('offers a gated step of a custom planning pipeline, whatever window it routes to', () => {
+    // A kind with no dedicated window at all still parks a human; the affordance opens whatever
+    // `dispatchStepView` routes it to (the generic panel), which is exactly what resolves it.
+    const approvals = [parked('some-custom-kind', 'ap_custom')]
+    expect(selectPlanApproval(approvals, resultViewOf)?.approval.id).toBe('ap_custom')
+  })
+})

package/app/utils/initiative.ts

@@ -59,6 +59,50 @@ export const INITIATIVE_ITEM_STATUS_CHIPS: Record<InitiativeItemStatus, BadgeCol
   skipped: 'neutral',
 }
 
+/**
+ * The two ways an initiative's planning run parks for a human: an agent-raised `decision`, or a
+ * pending step `approval` (the plan-approval gate the `initiative-planner` step carries). Resolved
+ * per block by `useInitiativePlanning().attention`.
+ */
+export type InitiativeAttentionKind = 'decision' | 'approval'
+
+/** Park kind → i18n label key for the card/inspector button that opens the resolving window. */
+export const INITIATIVE_ATTENTION_LABEL_KEYS: Record<InitiativeAttentionKind, string> = {
+  decision: 'initiative.inspector.resolveDecision',
+  approval: 'initiative.inspector.reviewPlan',
+}
+
+/** Park kind → button icon, so the board card and the inspector can't diverge on one park. */
+export const INITIATIVE_ATTENTION_ICONS: Record<InitiativeAttentionKind, string> = {
+  decision: 'i-lucide-circle-help',
+  approval: 'i-lucide-clipboard-check',
+}
+
+/**
+ * The result view the INTERVIEW gate owns. Its park rides the same `step.approval` mechanism as
+ * every other gate, so anything offering "there is a plan to review here" has to exclude it: the
+ * interview park is already owned by the planning window, behind the differently-worded "Answer
+ * planning questions".
+ */
+export const INTERVIEW_GATE_RESULT_VIEW = 'initiative-planning'
+
+/**
+ * The block's parked approval that is a PLAN REVIEW — the planner's human gate (`pl_initiative`
+ * declares `{ kind: 'initiative-planner', gate: true }`), or any other gated step of a custom
+ * planning pipeline — as opposed to the interviewer's park.
+ *
+ * Discriminated by the step's own result view, the seam `dispatchStepView` routes on, rather than
+ * by an agent-kind list or by the interview phase: the affordance's ACTION is that dispatch, so
+ * keying the offer on the same fact guarantees the button opens a window that can resolve what it
+ * offered — and that the interview and plan affordances can never both claim one park.
+ */
+export function selectPlanApproval<A extends { agentKind: string }>(
+  approvals: readonly A[],
+  resultViewOf: (agentKind: string) => string | undefined,
+): A | undefined {
+  return approvals.find((a) => resultViewOf(a.agentKind) !== INTERVIEW_GATE_RESULT_VIEW)
+}
+
 /** Follow-up triage status → i18n label key. Exhaustive so a new status fails the build. */
 export const INITIATIVE_FOLLOWUP_STATUS_LABEL_KEYS: Record<InitiativeFollowUp['status'], string> = {
   open: 'initiative.followUpStatus.open',

package/i18n/locales/de.json

@@ -4282,12 +4282,22 @@
     "inspector": {
       "runPlanning": "Planung ausführen",
       "answerPlanning": "Planungsfragen beantworten",
+      "reviewPlan": "Plan prüfen",
+      "resolveDecision": "Auflösen",
       "planningInProgress": "Planung läuft",
       "pause": "Pausieren",
       "resume": "Fortsetzen",
       "cancel": "Initiative abbrechen",
       "hint": "Die Planning-Pipeline erkundet die Codebasis, entwirft den mehrphasigen Plan zur Freigabe und committet dann das Tracker-Dokument ins Repository."
     },
+    "planReview": {
+      "title": "Dieser Plan wartet auf dich",
+      "body": "Der Planner hat die Phasen und Aufgaben unten entworfen. Gib sie frei, um den Plan zu committen und die Arbeit zu starten, oder schicke den Plan mit deinen Änderungswünschen zurück.",
+      "approve": "Plan freigeben",
+      "requestChanges": "Änderungen anfordern",
+      "feedbackPlaceholder": "Was soll der Planner ändern? Umfang, Reihenfolge der Phasen, fehlende Arbeit, eine Aufgabe, die woanders hingehört …",
+      "sendBack": "An den Planner zurückschicken"
+    },
     "planning": {
       "title": "Die Initiative planen",
       "subtitle": "Beantworten Sie die Fragen des Planers, damit er die Initiative eingrenzen kann",

package/i18n/locales/en.json

@@ -5459,12 +5459,22 @@
     "inspector": {
       "runPlanning": "Run planning",
       "answerPlanning": "Answer planning questions",
+      "reviewPlan": "Review plan",
+      "resolveDecision": "Resolve",
       "planningInProgress": "Planning in progress",
       "pause": "Pause",
       "resume": "Resume",
       "cancel": "Cancel initiative",
       "hint": "The planning pipeline explores the codebase, drafts the multi-phase plan for approval, then commits the tracker document to the repository."
     },
+    "planReview": {
+      "title": "This plan is waiting for you",
+      "body": "The planner drafted the phases and items below. Approve them to commit the plan and start the work, or send the plan back with what to change.",
+      "approve": "Approve plan",
+      "requestChanges": "Request changes",
+      "feedbackPlaceholder": "What should the planner change? Scope, phase order, missing work, an item that belongs elsewhere…",
+      "sendBack": "Send back to the planner"
+    },
     "planning": {
       "title": "Plan the initiative",
       "subtitle": "Answer the planner's questions so it can scope the initiative",

package/i18n/locales/es.json

@@ -5294,12 +5294,22 @@
     "inspector": {
       "runPlanning": "Ejecutar planificacion",
       "answerPlanning": "Responder preguntas de planificacion",
+      "reviewPlan": "Revisar plan",
+      "resolveDecision": "Resolver",
       "planningInProgress": "Planificacion en curso",
       "pause": "Pausar",
       "resume": "Reanudar",
       "cancel": "Cancelar iniciativa",
       "hint": "El pipeline de planificacion explora el codigo, redacta el plan multifase para su aprobacion y luego confirma el documento de seguimiento en el repositorio."
     },
+    "planReview": {
+      "title": "Este plan te está esperando",
+      "body": "El planificador redactó las fases y los elementos de abajo. Apruébalos para confirmar el plan y empezar el trabajo, o devuelve el plan indicando qué cambiar.",
+      "approve": "Aprobar plan",
+      "requestChanges": "Solicitar cambios",
+      "feedbackPlaceholder": "¿Qué debería cambiar el planificador? Alcance, orden de las fases, trabajo que falta, un elemento que va en otro sitio…",
+      "sendBack": "Devolver al planificador"
+    },
     "planning": {
       "title": "Planificar la iniciativa",
       "subtitle": "Responde las preguntas del planificador para acotar la iniciativa",

package/i18n/locales/fr.json

@@ -5294,12 +5294,22 @@
     "inspector": {
       "runPlanning": "Lancer la planification",
       "answerPlanning": "Repondre aux questions de planification",
+      "reviewPlan": "Examiner le plan",
+      "resolveDecision": "Résoudre",
       "planningInProgress": "Planification en cours",
       "pause": "Mettre en pause",
       "resume": "Reprendre",
       "cancel": "Annuler l'initiative",
       "hint": "Le pipeline de planification explore le code, redige le plan multiphase pour approbation, puis valide le document de suivi dans le depot."
     },
+    "planReview": {
+      "title": "Ce plan vous attend",
+      "body": "Le planificateur a rédigé les phases et les éléments ci-dessous. Approuvez-les pour valider le plan et lancer le travail, ou renvoyez le plan en indiquant ce qu'il faut changer.",
+      "approve": "Approuver le plan",
+      "requestChanges": "Demander des modifications",
+      "feedbackPlaceholder": "Que doit changer le planificateur ? Périmètre, ordre des phases, travail manquant, un élément qui a sa place ailleurs…",
+      "sendBack": "Renvoyer au planificateur"
+    },
     "planning": {
       "title": "Planifier l'initiative",
       "subtitle": "Repondez aux questions du planificateur pour cadrer l'initiative",

package/i18n/locales/he.json

@@ -5305,12 +5305,22 @@
     "inspector": {
       "runPlanning": "הרצת תכנון",
       "answerPlanning": "מענה על שאלות התכנון",
+      "reviewPlan": "בדיקת התוכנית",
+      "resolveDecision": "פתור",
       "planningInProgress": "התכנון מתבצע",
       "pause": "השהה",
       "resume": "המשך",
       "cancel": "ביטול היוזמה",
       "hint": "צינור התכנון חוקר את הקוד, מנסח את התוכנית הרב-שלבית לאישור, ואז שומר את מסמך המעקב במאגר."
     },
+    "planReview": {
+      "title": "התוכנית הזו ממתינה לך",
+      "body": "המתכנן ניסח את השלבים והפריטים שלמטה. אשרו אותם כדי לשמור את התוכנית ולהתחיל בעבודה, או החזירו את התוכנית עם מה שצריך לשנות.",
+      "approve": "אישור התוכנית",
+      "requestChanges": "בקשת שינויים",
+      "feedbackPlaceholder": "מה המתכנן צריך לשנות? היקף, סדר השלבים, עבודה חסרה, פריט ששייך למקום אחר…",
+      "sendBack": "החזרה למתכנן"
+    },
     "planning": {
       "title": "תכנון היוזמה",
       "subtitle": "ענה על שאלות המתכנן כדי למקד את היוזמה",

package/i18n/locales/it.json

@@ -4282,12 +4282,22 @@
     "inspector": {
       "runPlanning": "Esegui pianificazione",
       "answerPlanning": "Rispondi alle domande di pianificazione",
+      "reviewPlan": "Rivedi il piano",
+      "resolveDecision": "Risolvi",
       "planningInProgress": "Pianificazione in corso",
       "pause": "Pausa",
       "resume": "Riprendi",
       "cancel": "Annulla iniziativa",
       "hint": "La pipeline di pianificazione esplora il codebase, redige il piano multi-fase per l'approvazione, poi effettua il commit del documento del tracker nel repository."
     },
+    "planReview": {
+      "title": "Questo piano ti sta aspettando",
+      "body": "Il planner ha redatto le fasi e gli elementi qui sotto. Approvali per confermare il piano e avviare il lavoro, oppure rimanda indietro il piano indicando cosa cambiare.",
+      "approve": "Approva il piano",
+      "requestChanges": "Richiedi modifiche",
+      "feedbackPlaceholder": "Cosa deve cambiare il planner? Ambito, ordine delle fasi, lavoro mancante, un elemento che sta altrove…",
+      "sendBack": "Rimanda al planner"
+    },
     "planning": {
       "title": "Pianifica l'iniziativa",
       "subtitle": "Rispondi alle domande del pianificatore affinche possa definire l'ambito dell'iniziativa",

package/i18n/locales/ja.json

@@ -5306,12 +5306,22 @@
     "inspector": {
       "runPlanning": "計画を実行",
       "answerPlanning": "計画の質問に回答",
+      "reviewPlan": "計画をレビュー",
+      "resolveDecision": "解決",
       "planningInProgress": "計画を実行中",
       "pause": "一時停止",
       "resume": "再開",
       "cancel": "イニシアチブをキャンセル",
       "hint": "計画パイプラインはコードベースを調査し、承認用の複数フェーズ計画を起草し、その後トラッカー文書をリポジトリにコミットします。"
     },
+    "planReview": {
+      "title": "この計画が承認を待っています",
+      "body": "プランナーが以下のフェーズと項目を起草しました。承認すると計画がコミットされ、作業が始まります。変更したい点がある場合は、その内容を添えて計画を差し戻してください。",
+      "approve": "計画を承認",
+      "requestChanges": "変更を依頼",
+      "feedbackPlaceholder": "プランナーに変更してほしい点は何ですか。範囲、フェーズの順序、不足している作業、別の場所に属する項目など…",
+      "sendBack": "プランナーに差し戻す"
+    },
     "planning": {
       "title": "イニシアチブを計画",
       "subtitle": "プランナーの質問に答えてイニシアチブの範囲を定めます",

package/i18n/locales/pl.json

@@ -5294,12 +5294,22 @@
     "inspector": {
       "runPlanning": "Uruchom planowanie",
       "answerPlanning": "Odpowiedz na pytania planowania",
+      "reviewPlan": "Przejrzyj plan",
+      "resolveDecision": "Rozwiąż",
       "planningInProgress": "Planowanie w toku",
       "pause": "Wstrzymaj",
       "resume": "Wznow",
       "cancel": "Anuluj inicjatywe",
       "hint": "Pipeline planowania bada kod, przygotowuje wielofazowy plan do zatwierdzenia, a nastepnie zapisuje dokument trackera w repozytorium."
     },
+    "planReview": {
+      "title": "Ten plan czeka na Ciebie",
+      "body": "Planer przygotował poniższe fazy i elementy. Zatwierdź je, aby zapisać plan i rozpocząć pracę, albo odeślij plan z informacją, co zmienić.",
+      "approve": "Zatwierdź plan",
+      "requestChanges": "Poproś o zmiany",
+      "feedbackPlaceholder": "Co planer ma zmienić? Zakres, kolejność faz, brakująca praca, element, który pasuje gdzie indziej…",
+      "sendBack": "Odeślij do planera"
+    },
     "planning": {
       "title": "Zaplanuj inicjatywe",
       "subtitle": "Odpowiedz na pytania planisty, aby okreslic zakres inicjatywy",

package/i18n/locales/tr.json

@@ -5306,12 +5306,22 @@
     "inspector": {
       "runPlanning": "Planlamayi calistir",
       "answerPlanning": "Planlama sorularini yanitla",
+      "reviewPlan": "Planı incele",
+      "resolveDecision": "Çöz",
       "planningInProgress": "Planlama suruyor",
       "pause": "Duraklat",
       "resume": "Devam et",
       "cancel": "Girisimi iptal et",
       "hint": "Planlama hatti kod tabanini inceler, onay icin cok asamali plani hazirlar ve ardindan izleyici belgesini depoya kaydeder."
     },
+    "planReview": {
+      "title": "Bu plan sizi bekliyor",
+      "body": "Planlayıcı aşağıdaki aşamaları ve maddeleri hazırladı. Planı kaydedip işe başlamak için onaylayın ya da neyin değişmesi gerektiğini yazarak planı geri gönderin.",
+      "approve": "Planı onayla",
+      "requestChanges": "Değişiklik iste",
+      "feedbackPlaceholder": "Planlayıcı neyi değiştirmeli? Kapsam, aşama sırası, eksik iş, başka yere ait bir madde…",
+      "sendBack": "Planlayıcıya geri gönder"
+    },
     "planning": {
       "title": "Girisimi planla",
       "subtitle": "Girisimi kapsamlandirmak icin planlayicinin sorularini yanitlayin",

package/i18n/locales/uk.json

@@ -5294,12 +5294,22 @@
     "inspector": {
       "runPlanning": "Запустити планування",
       "answerPlanning": "Відповісти на питання планування",
+      "reviewPlan": "Переглянути план",
+      "resolveDecision": "Вирішити",
       "planningInProgress": "Планування триває",
       "pause": "Призупинити",
       "resume": "Відновити",
       "cancel": "Скасувати ініціативу",
       "hint": "Пайплайн планування досліджує кодову базу, готує багатофазний план на затвердження, а потім комітить документ трекера до репозиторію."
     },
+    "planReview": {
+      "title": "Цей план чекає на вас",
+      "body": "Планувальник підготував фази та елементи нижче. Затвердіть їх, щоб зафіксувати план і розпочати роботу, або поверніть план із зазначенням, що змінити.",
+      "approve": "Затвердити план",
+      "requestChanges": "Запросити зміни",
+      "feedbackPlaceholder": "Що має змінити планувальник? Обсяг, порядок фаз, пропущена робота, елемент, якому місце деінде…",
+      "sendBack": "Повернути планувальнику"
+    },
     "planning": {
       "title": "Спланувати ініціативу",
       "subtitle": "Дайте відповіді на питання планувальника, щоб окреслити ініціативу",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cat-factory/app",
-  "version": "0.182.0",
+  "version": "0.182.1",
   "description": "Reusable Nuxt layer for the Agent Architecture Board SPA (components, stores, composables, pages). Consume it from a thin deployment app via `extends: ['@cat-factory/app']` and point it at your backend with NUXT_PUBLIC_API_BASE. See deploy/frontend for an example.",
   "repository": {
     "type": "git",