@cat-factory/app 0.181.0 → 0.182.1

package/README.md

@@ -131,7 +131,10 @@ example ships in [`deploy/frontend`](../../deploy/frontend) (the `acme:security`
 
 - **Board canvas** (`components/board`) — `BoardCanvas` + `nodes/` (`BlockNode`,
   `ModuleFrame`, `TaskCard`), dependency edges, the per-block `AgentFailureCard` /
-  `AgentStopButton`, and a deep-zoom `focus/BlockFocusView`.
+  `AgentStopButton`, and a deep-zoom `focus/BlockFocusView`. A running task card expands
+  its build pipeline (`TaskPipelineMini`) on hover at any zoom level, and across every
+  on-screen card past the `steps` zoom band — the two grants are combined in the
+  `taskExpansion` store and driven by `useTaskExpansion`.
 - **Sidebar & chrome** (`components/layout`) — board/account switchers, palettes
   entry points, the language + [interface-mode](#interface-modes-basic--advanced)
   switchers, the `SpendWarningBanner`, and the toolbar (zoom, LOD, decision queue).
@@ -174,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/DraggableTask.vue

@@ -10,8 +10,9 @@ const task = computed(() => board.getBlock(props.taskId))
 const { draggingId, startDrag } = useBlockDrag()
 
 // An expanded pipeline grows downward over its neighbours, so it must stack above the
-// other (compact) task cards — never let a neighbour render on top of the pipeline.
-const expanded = computed(() => expansion.allowed.has(props.taskId))
+// other (compact) task cards — never let a neighbour render on top of the pipeline. Reads
+// the same predicate the pipeline itself renders on, so the two can't disagree.
+const expanded = computed(() => expansion.isExpanded(props.taskId))
 
 // Once a task is merged it stops being a unit of work and becomes part of the
 // architecture: it no longer renders as a draggable card (arrows fall back to its

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/board/nodes/TaskPipelineMini.vue

@@ -12,11 +12,11 @@ import { lodAtLeast } from '~/composables/useSemanticZoom'
 import { prReviewPhase } from '~/utils/prReviewProgress'
 import PrReviewPhaseBadge from '~/components/prReview/PrReviewPhaseBadge.vue'
 
-// Spatial drill-down inside a task card: at the `steps` zoom band the task's
-// build-pipeline steps appear, and one band deeper (`subtasks`) each step's live
-// todo breakdown expands — done / in-progress / pending — exactly the way a
-// zoomed-in bootstrap card reads. Renders nothing until the task has a run and
-// the user has zoomed in far enough, so it's safe to mount on every task card.
+// Drill-down inside a task card: the task's build-pipeline steps appear on hover (at any
+// zoom level) or once the `steps` zoom band is reached, and one band deeper (`subtasks`)
+// each step's live todo breakdown expands — done / in-progress / pending — exactly the way
+// a zoomed-in bootstrap card reads. Renders nothing until the task has a run and the card
+// is expanded, so it's safe to mount on every task card.
 const props = defineProps<{ taskId: string }>()
 
 const execution = useExecutionStore()
@@ -40,13 +40,10 @@ const runFailed = computed(() => instance.value?.status === 'failed')
 // (spinning "Running") rather than a frozen subtask list.
 const companionByStep = computed(() => steps.value.map((s) => gateCompanionFor(s, runFailed.value)))
 
-// Expand the pipeline list only when zoomed in far enough AND the board driver
-// permits this card — on-screen, and the centre-most of any cards that would
-// otherwise overlap (see useTaskExpansion) — so deep-zoom expansions don't pile up.
-const showSteps = computed(
-  () =>
-    lodAtLeast(lod.value, 'steps') && steps.value.length > 0 && expansion.canExpand(props.taskId),
-)
+// Expand the pipeline list when the board driver says so: this card is hovered (at any
+// zoom level), or the deep zoom bands granted it — on-screen, and the centre-most of any
+// cards that would otherwise overlap. See stores/taskExpansion.ts.
+const showSteps = computed(() => steps.value.length > 0 && expansion.isExpanded(props.taskId))
 const showItems = computed(() => lodAtLeast(lod.value, 'subtasks'))
 
 // Clicking a step opens the full agent step-detail overlay — execution metadata

package/app/components/docs/DocInterviewWindow.vue

@@ -19,7 +19,11 @@
 import { computed, reactive, watch } from 'vue'
 import InterviewGateNotice from '~/components/common/InterviewGateNotice.vue'
 import ResultWindowShell from '~/components/panels/ResultWindowShell.vue'
-import { interviewGatePhase } from '~/utils/interviewGate'
+import {
+  DOC_INTERVIEWER_KIND,
+  interviewGatePhase,
+  interviewStepReached,
+} from '~/utils/interviewGate'
 
 const board = useBoardStore()
 const docInterview = useDocInterviewStore()
@@ -63,7 +67,13 @@ const resuming = computed(() => docInterview.resuming)
  * actually says, so the questions come back rather than the window sticking on a spinner.
  */
 const phase = computed(() =>
-  resuming.value ? 'working' : interviewGatePhase(session.value?.status, run.value?.status),
+  resuming.value
+    ? 'working'
+    : interviewGatePhase(
+        session.value?.status,
+        run.value?.status,
+        interviewStepReached(run.value, DOC_INTERVIEWER_KIND),
+      ),
 )
 /** The interview converged: the synthesized authoring brief is what the window shows. */
 const converged = computed(() => phase.value === 'converged')
@@ -133,10 +143,21 @@ const onProceed = () => flushThen((id) => docInterview.proceedInterview(id))
           {{ t('docInterview.intro') }}
         </p>
 
+        <!-- The run is still ahead of the interview (the researcher + outliner steps). Same
+             chrome, different claim: nothing has been asked yet, so the "working on your answers"
+             copy below would describe answers that do not exist. -->
+        <InterviewGateNotice
+          v-if="phase === 'preparing'"
+          variant="working"
+          :title="t('docInterview.preparing')"
+          :hint="t('docInterview.preparingHint')"
+          testid="doc-interview-preparing"
+        />
+
         <!-- A pass is running: the human is waiting on the interviewer. Without this the window is
              byte-identical to the parked state and the submit reads as a no-op. -->
         <InterviewGateNotice
-          v-if="phase === 'working'"
+          v-else-if="phase === 'working'"
           variant="working"
           :title="t('docInterview.working')"
           :hint="t('docInterview.workingHint')"

package/app/components/initiative/InitiativePlanningWindow.vue

@@ -4,8 +4,9 @@
 // (pending `qa` entries with an empty answer) are shown here; the human answers them, then either
 // SUBMITS them (the `continue` action: the interviewer re-runs and may ask follow-ups) or plans
 // now (the `proceed` action: skip the remaining questions — the interviewer converges and the run
-// advances to the analyst/planner). The labels say submit/plan-now rather than continue/proceed
-// because the latter pair both read as "go forward" and were indistinguishable in use.
+// advances to the planner; the analyst already ran, ahead of this gate). The labels say
+// submit/plan-now rather than continue/proceed because the latter pair both read as "go forward"
+// and were indistinguishable in use.
 // Opened via the universal result-view host: from the inspector / card
 // (`ui.openInitiativePlanning`) or as the interviewer step's result view. Live `initiative`
 // stream events patch the store, so an open window follows the interview as it progresses.
@@ -29,7 +30,11 @@ import {
   isPendingQuestion,
   orderInterviewQuestions,
 } from '~/utils/initiative'
-import { interviewGatePhase } from '~/utils/interviewGate'
+import {
+  INITIATIVE_INTERVIEWER_KIND,
+  interviewGatePhase,
+  interviewStepReached,
+} from '~/utils/interviewGate'
 import ResultWindowShell from '~/components/panels/ResultWindowShell.vue'
 import StepRunMeta from '~/components/panels/StepRunMeta.vue'
 
@@ -117,7 +122,11 @@ const resuming = computed(() => initiatives.resuming)
 const phase = computed(() =>
   resuming.value
     ? 'working'
-    : interviewGatePhase(initiative.value?.interview?.status, run.value?.status),
+    : interviewGatePhase(
+        initiative.value?.interview?.status,
+        run.value?.status,
+        interviewStepReached(run.value, INITIATIVE_INTERVIEWER_KIND),
+      ),
 )
 
 /**
@@ -229,10 +238,21 @@ async function onDiscard() {
             {{ t('initiative.planning.intro') }}
           </p>
 
+          <!-- The run is still ahead of the interview — the codebase analysis that grounds it. It
+               wears the working chrome but says something different on purpose: nothing has been
+               asked yet, so "working on your answers" would describe answers that do not exist. -->
+          <InterviewGateNotice
+            v-if="phase === 'preparing'"
+            variant="working"
+            :title="t('initiative.planning.preparing')"
+            :hint="t('initiative.planning.preparingHint')"
+            testid="initiative-planning-preparing"
+          />
+
           <!-- A pass is running: the human is waiting on the planner. Without this the window is
                byte-identical to the parked state and the submit reads as a no-op. -->
           <InterviewGateNotice
-            v-if="phase === 'working'"
+            v-else-if="phase === 'working'"
             variant="working"
             :title="t('initiative.planning.working')"
             :hint="t('initiative.planning.workingHint')"
@@ -316,8 +336,8 @@ async function onDiscard() {
     <!-- Action rail. The submit/plan-now pair shows only while the run is actually parked on the
          human: mid-pass they would re-submit a question set already in flight, and the resume is a
          no-op once it isn't. Discard is the opposite — it is offered for as long as a run owns the
-         block, because the phases where those two are hidden (working, failed) are exactly the ones
-         a wedged run sits in. -->
+         block, because the phases where those two are hidden (preparing, working, failed) are
+         exactly the ones a wedged run sits in. -->
     <footer
       v-if="initiative && (canDiscard || (phase === 'awaiting' && questions.length > 0))"
       class="flex items-center justify-between gap-3 border-t border-slate-800 px-5 py-3"

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"