@cat-factory/app 0.180.0 → 0.182.0

package/app/components/tasks/TaskContextIssues.vue

@@ -1,6 +1,10 @@
 <script setup lang="ts">
-// Inspector section for a task block: the tracker issues (Jira, GitHub Issues, …)
-// attached to it as agent context. Attaching uses the SAME inline picker as task
+// Inspector section for a task OR initiative block: the tracker issues (Jira,
+// GitHub Issues, …) attached to it as agent context. An initiative takes the same
+// attachments (the create-initiative modal stages them exactly as the add-task one
+// does) and its whole planning pipeline reads them, so it gets the same section —
+// only the prose differs, which is why the hint/empty copy is level-keyed below.
+// Attaching uses the SAME inline picker as task
 // creation (source selector + in-repo search + paste-by-reference —
 // ContextIssuePicker), NOT the old dropdown that opened a second, page-level
 // "Import an issue…" modal on top of the inspector (stacked page-level modals
@@ -28,6 +32,20 @@ onMounted(() => {
 })
 
 const linked = computed(() => tasks.tasksForBlock(props.block.id))
+
+// Two STATIC literal keys per string, picked by level — the copy names what reads the issue
+// (the agents implementing a task vs the pipeline that plans an initiative), which is the
+// whole point of the hint. Assembling one key from `block.level` would defeat the typed
+// message-key check for a two-member choice that gains nothing from being dynamic.
+const isInitiative = computed(() => props.block.level === 'initiative')
+const hint = computed(() =>
+  isInitiative.value ? t('tasks.contextIssues.hintInitiative') : t('tasks.contextIssues.hint'),
+)
+const emptyHint = computed(() =>
+  isInitiative.value
+    ? t('tasks.contextIssues.emptyHintInitiative')
+    : t('tasks.contextIssues.emptyHint'),
+)
 // Already-linked issues, so the inline picker filters them out / never re-offers them.
 const chosenKeys = computed(() =>
   linked.value.map((issue) =>
@@ -71,7 +89,7 @@ async function attach(item: PendingContext) {
   <InspectorSection
     v-if="tasks.available"
     :title="t('tasks.contextIssues.title')"
-    :hint="t('tasks.contextIssues.hint')"
+    :hint="hint"
     :count="linked.length"
   >
     <template #actions>
@@ -133,7 +151,7 @@ async function attach(item: PendingContext) {
       </a>
     </div>
     <p v-else class="text-[11px] text-slate-500">
-      {{ t('tasks.contextIssues.emptyHint') }}
+      {{ emptyHint }}
     </p>
   </InspectorSection>
 </template>

package/app/composables/useInitiativePlanning.ts

@@ -4,7 +4,11 @@ import { useExecutionStore } from '~/stores/execution'
 import { useInitiativesStore } from '~/stores/initiative'
 import { usePipelinesStore } from '~/stores/pipelines'
 import { useUiStore } from '~/stores/ui'
-import { interviewGatePhase } from '~/utils/interviewGate'
+import {
+  INITIATIVE_INTERVIEWER_KIND,
+  interviewGatePhase,
+  interviewStepReached,
+} from '~/utils/interviewGate'
 
 /**
  * Shared planning affordances for an `initiative`-level block, used by BOTH the board card
@@ -41,12 +45,14 @@ export function useInitiativePlanning(blockId: MaybeRefOrGetter<string>) {
    * The live interview phase, derived from the entity AND the planning run (see
    * {@link interviewGatePhase} for why the run status is load-bearing).
    */
-  const interviewPhase = computed(() =>
-    interviewGatePhase(
+  const interviewPhase = computed(() => {
+    const run = execution.getByBlock(toValue(blockId))
+    return interviewGatePhase(
       initiative.value?.interview?.status,
-      execution.getByBlock(toValue(blockId))?.status,
-    ),
-  )
+      run?.status,
+      interviewStepReached(run, INITIATIVE_INTERVIEWER_KIND),
+    )
+  })
 
   /**
    * The interviewer has PARKED the planning run for the human. NOT keyed on whether individual
@@ -62,8 +68,20 @@ export function useInitiativePlanning(blockId: MaybeRefOrGetter<string>) {
    */
   const awaitingAnswers = computed(() => interviewPhase.value === 'awaiting')
 
-  /** An interviewer pass is running — the human is waiting on the planner, not the reverse. */
-  const interviewing = computed(() => interviewPhase.value === 'working')
+  /**
+   * The planning run is mid-flight with nothing for the human to answer — either an interviewer
+   * pass is running (`working`) or the run has not reached the interview yet (`preparing`, the
+   * codebase analysis that now leads). BOTH phases, deliberately: this drives the card's and
+   * inspector's "Planning in progress" button, which is the only route into the planning window
+   * while a run owns the block. Narrowing it to `working` would drop that route for the whole of
+   * the analysis and fall through to a "Run planning" button for a run already running.
+   *
+   * The two phases are distinguished INSIDE the window, where there is room to say which is which;
+   * the affordance is the same either way.
+   */
+  const interviewing = computed(
+    () => interviewPhase.value === 'working' || interviewPhase.value === 'preparing',
+  )
 
   /**
    * Optimistic start flag: flip true the instant "Run planning" is clicked, before the stream

package/app/composables/useResultViewRunMeta.spec.ts

@@ -0,0 +1,74 @@
+import { describe, expect, it } from 'vitest'
+import type { PipelineStep } from '~/types/execution'
+import { resultViewStepIndex } from '~/composables/useResultViewRunMeta'
+
+// The off-path fallback: which step a result window reports run metadata for when it was opened
+// from a board card / the inspector rather than from the run's timeline. The precedence exists
+// because a window's kind set can mix model-running steps with bookkeeping ones — the initiative
+// tracker is registered for the analyst, the planner AND `initiative-committer`, which runs no
+// model — so "the most recent one" alone would anchor on the step with no telemetry.
+
+function step(agentKind: string, overrides: Partial<PipelineStep> = {}): PipelineStep {
+  return { agentKind, state: 'pending', ...overrides } as PipelineStep
+}
+
+/** A step that recorded model calls (the shape `attachStepMetrics` folds onto the run). */
+function metered(agentKind: string, calls: number, startedAt = 1_000): PipelineStep {
+  return step(agentKind, { startedAt, metrics: { calls } as PipelineStep['metrics'] })
+}
+
+describe('resultViewStepIndex', () => {
+  it('is null when no step declares the view', () => {
+    const steps = [step('coder'), step('tester')]
+    expect(resultViewStepIndex(steps, 'initiative-tracker')).toBeNull()
+  })
+
+  it('falls back to the first declaring step before the run reaches any of them', () => {
+    const steps = [
+      step('initiative-interviewer'),
+      step('initiative-analyst'),
+      step('initiative-planner'),
+    ]
+    // Index 1 — the analyst; the interviewer declares the PLANNING window, not the tracker.
+    expect(resultViewStepIndex(steps, 'initiative-tracker')).toBe(1)
+  })
+
+  it('prefers the last started step while the run is mid-flight with no telemetry yet', () => {
+    const steps = [
+      step('initiative-interviewer', { startedAt: 10 }),
+      step('initiative-analyst', { startedAt: 20 }),
+      step('initiative-planner'),
+    ]
+    expect(resultViewStepIndex(steps, 'initiative-tracker')).toBe(1)
+  })
+
+  it('prefers the last step that actually ran a model over a later bookkeeping step', () => {
+    const steps = [
+      metered('initiative-interviewer', 4),
+      metered('initiative-analyst', 12),
+      metered('initiative-planner', 31),
+      // Runs no model, so it records no calls — and must not shadow the planner's telemetry.
+      step('initiative-committer', { startedAt: 2_000 }),
+    ]
+    expect(resultViewStepIndex(steps, 'initiative-tracker')).toBe(2)
+  })
+
+  it('ignores a metered step belonging to another window', () => {
+    const steps = [metered('initiative-interviewer', 9), step('initiative-analyst')]
+    expect(resultViewStepIndex(steps, 'initiative-tracker')).toBe(1)
+    expect(resultViewStepIndex(steps, 'initiative-planning')).toBe(0)
+  })
+
+  it('treats a zero-call rollup as unmetered', () => {
+    const steps = [
+      metered('initiative-analyst', 5),
+      step('initiative-planner', {
+        startedAt: 3_000,
+        metrics: { calls: 0 } as PipelineStep['metrics'],
+      }),
+    ]
+    // The analyst keeps the tier-1 match: a rollup that recorded nothing is not telemetry, so
+    // the later step doesn't shadow it just for having a `metrics` object.
+    expect(resultViewStepIndex(steps, 'initiative-tracker')).toBe(0)
+  })
+})

package/app/composables/useResultViewRunMeta.ts

@@ -0,0 +1,98 @@
+import { computed } from 'vue'
+import type { ExecutionInstance, PipelineStep } from '~/types/execution'
+import { agentKindMeta } from '~/utils/catalog'
+
+/**
+ * Resolves the `StepRunMeta` prop bundle for a dedicated result window, for BOTH of the ways
+ * such a window opens (see `stores/ui/resultViews.ts`):
+ *
+ * - the PIPELINE path (`dispatchStepView`), which carries `instanceId` + `stepIndex` — the step
+ *   is exactly the one that was clicked, as every step-backed window already assumes; and
+ * - an OFF-PATH open (`ui.openInitiativeTracker`, `ui.openInitiativePlanning`, …), which carries
+ *   only a block id, because the human entered from the board card or the inspector rather than
+ *   from the run's timeline.
+ *
+ * Windows that are reachable BOTH ways used to fall back to no metadata at all on the second
+ * route, which is how the initiative windows ended up with no run details, no model and no token
+ * telemetry — on the entry point people actually use. The fallback resolves the block's live run
+ * and picks the step this window represents, so the two routes report the same facts.
+ */
+export function useResultViewRunMeta(
+  viewId: string,
+  source: {
+    blockId: () => string | null
+    instanceId: () => string | null
+    stepIndex: () => number | null
+  },
+) {
+  const execution = useExecutionStore()
+
+  /**
+   * The run the metadata describes: the dispatched one on the pipeline path, else the block's
+   * live run. Read reactively rather than resolved once at open time, so a window left open
+   * across a run start/advance follows it instead of freezing on whatever existed at mount.
+   */
+  const instance = computed<ExecutionInstance | null>(() => {
+    const id = source.instanceId()
+    if (id !== null) return execution.getInstance(id) ?? null
+    const blockId = source.blockId()
+    return blockId ? (execution.getByBlock(blockId) ?? null) : null
+  })
+
+  const stepNumber = computed<number | null>(() => {
+    const index = source.stepIndex()
+    if (index !== null) return index
+    return instance.value ? resultViewStepIndex(instance.value.steps, viewId) : null
+  })
+
+  const step = computed<PipelineStep | null>(() => {
+    const index = stepNumber.value
+    if (index === null) return null
+    return instance.value?.steps[index] ?? null
+  })
+
+  return {
+    instance,
+    step,
+    /** The run id, for the copyable field + the "View all calls" observability link. */
+    instanceId: computed(() => instance.value?.id),
+    /** 1-based position, as `StepRunMeta` renders it ("N of M"). */
+    position: computed(() => (stepNumber.value === null ? undefined : stepNumber.value + 1)),
+    totalSteps: computed(() => instance.value?.steps.length),
+    runFailed: computed(() => instance.value?.status === 'failed'),
+    failureAt: computed(() => instance.value?.failure?.occurredAt),
+  }
+}
+
+/**
+ * The step an off-path open should report, among the run's steps whose agent kind declares
+ * `viewId` as its dedicated result view (the same `resultView` seam `dispatchStepView` routes
+ * on, so the mapping can never drift from the window registry).
+ *
+ * Precedence, most to least specific:
+ *
+ * 1. the last step that has actually RUN A MODEL. A window's kind set can span both model-running
+ *    steps and bookkeeping ones — the initiative tracker is registered for the analyst and the
+ *    planner but also for `initiative-committer`, which runs no model — and anchoring on the last
+ *    STARTED step alone would hand a human who opened the window for its telemetry the one step
+ *    guaranteed to have none.
+ * 2. the last started step, so a run mid-flight (or one whose telemetry sink isn't wired) still
+ *    reports timing, model and run id rather than nothing.
+ * 3. the first declaring step, so a run that hasn't reached any of them yet still names which
+ *    step is coming and how far into the pipeline it sits.
+ *
+ * Null when the run declares none — the caller hides the sidebar rather than rendering an empty one.
+ */
+export function resultViewStepIndex(steps: readonly PipelineStep[], viewId: string): number | null {
+  let first: number | null = null
+  let lastStarted: number | null = null
+  let lastMetered: number | null = null
+  for (let i = 0; i < steps.length; i++) {
+    const step = steps[i]
+    if (!step || agentKindMeta(step.agentKind).resultView !== viewId) continue
+    if (first === null) first = i
+    if (step.startedAt != null) lastStarted = i
+    if ((step.metrics?.calls ?? 0) > 0) lastMetered = i
+  }
+  return lastMetered ?? lastStarted ?? first
+}

package/app/composables/useTaskExpansion.ts

@@ -15,22 +15,24 @@ function sameSet(a: Set<string>, b: Set<string>) {
 }
 
 /**
- * Board-level driver deciding which task cards may expand their full pipeline list
- * once zoomed in (the deep `steps`/`subtasks` bands). Two gates, recomputed every
- * frame against live DOM rects so they follow pan / zoom / drag / resize:
+ * Board-level driver deciding which task cards expand their full pipeline list.
+ * Recomputed every frame against live DOM rects so it follows pan / zoom / drag / resize,
+ * and writes two independent grants into the `taskExpansion` store (which combines them —
+ * see the store for how they resolve):
  *
- *  - visibility: a task expands only while its card overlaps the board viewport.
- *  - overlap: walking the visible candidates nearest-header-to-screen-centre first, a
- *    task expands only if its footprint doesn't collide with one already granted, so the
- *    card you're looking at wins an overlap and the rest stay compact.
- *  - hover: the task directly under the pointer is granted first, so hovering any card
- *    expands its pipeline regardless of its position on screen. "Under the pointer" is
- *    the TOPMOST card at the cursor (document.elementFromPoint), so hovering a region
+ *  - hover: the task directly under the pointer, at ANY zoom level. "Under the pointer"
+ *    is the TOPMOST card at the cursor (document.elementFromPoint), so hovering a region
  *    already covered by another open pipeline keeps that pipeline, not the card beneath.
+ *  - zoom: at the deep `steps`/`subtasks` bands, every on-screen card, minus overlaps —
+ *    two sub-gates:
+ *      - visibility: a task expands only while its card overlaps the board viewport.
+ *      - overlap: walking the visible candidates nearest-header-to-screen-centre first, a
+ *        task expands only if its footprint doesn't collide with one already granted, so
+ *        the card you're looking at wins an overlap and the rest stay compact. The hovered
+ *        card is granted first, so it wins every overlap it's part of.
  *
- * Writes the permitted id set into the `taskExpansion` store; `TaskPipelineMini` reads it.
- * Only tasks with a running pipeline (steps to show) are candidates — a task that
- * wouldn't expand never blocks a neighbour.
+ * Only tasks with a running pipeline (steps to show) are candidates for either grant — a
+ * task that wouldn't expand never blocks a neighbour and never lifts an empty card.
  */
 export function useTaskExpansion(container: Ref<HTMLElement | null>) {
   const board = useBoardStore()
@@ -65,14 +67,27 @@ export function useTaskExpansion(container: Ref<HTMLElement | null>) {
   // The task whose card is topmost at the pointer, or null. Using elementFromPoint (not a
   // rect test) means an open pipeline stacked above a neighbour wins the hit, so hovering
   // a region obscured by another pipeline doesn't switch to the card hidden beneath it.
+  //
+  // Blocks with no pipeline to show are filtered out here rather than left to the card:
+  // a frame, a module, or a task with no run expands to nothing, and granting it would
+  // still lift an empty card over its neighbours (see DraggableTask's z-index).
   function hoveredTaskId(): string | null {
     if (!pointer) return null
     const hit = document.elementFromPoint(pointer.x, pointer.y)
-    return hit?.closest('[data-block-id]')?.getAttribute('data-block-id') ?? null
+    const id = hit?.closest('[data-block-id]')?.getAttribute('data-block-id') ?? null
+    if (!id || !execution.getByBlock(id)?.steps.length) return null
+    return id
   }
 
   function recompute() {
-    // Task cards only expand at the deep zoom bands; clear everything otherwise.
+    // Hover expands a card at ANY zoom band, so the pointer hit is resolved BEFORE the
+    // zoom gate below — resolving it after would collapse the hovered card the moment the
+    // user zoomed back out past the `steps` band.
+    const hovered = hoveredTaskId()
+    if (store.hoveredId !== hovered) store.setHovered(hovered)
+
+    // The zoom-driven expansion (every on-screen card, overlap-resolved) is deep-band
+    // only; clear its grants otherwise. The hover grant above stands on its own.
     if (!lodAtLeast(ui.lod, 'steps')) {
       if (store.allowed.size) store.setAllowed(new Set())
       return
@@ -117,7 +132,6 @@ export function useTaskExpansion(container: Ref<HTMLElement | null>) {
     // clears every footprint already granted, so the centre-most card wins any overlap.
     // The hovered card is granted FIRST, so hovering a card expands it regardless of its
     // distance from the centre (and a centre-most neighbour it overlaps yields to it).
-    const hovered = hoveredTaskId()
     const claimed: Rect[] = []
     const next = new Set<string>()
     const hoveredCard = hovered ? candidates.find((c) => c.id === hovered) : undefined

package/app/docs/consumer-extensions.md

@@ -170,16 +170,17 @@ re-deriving the "which run is this / how did the model do" facts. **Composables*
 **components** must be named through the `#components` virtual module (see the boxed note
 below). Compose these:
 
-| Building block         | Reference it as                           | What it gives you                                                                                                                                                                                                                                                                                             |
-| ---------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ResultWindowShell`    | `#components` → `PanelsResultWindowShell` | The shared modal chrome for a result window — backdrop, header (icon/title/subtitle), a `#header-extras` slot, close button, and the modal _behaviour_ (focus-trap + return, body-scroll lock, shared-stack Escape via `useModalBehavior`). Pass `stepRef` to surface the shared "restart from here" control. |
-| `StepRunMeta`          | `#components` → `PanelsStepRunMeta`       | **The shared run-details metadata block** every agent window reuses: step position, live duration, model, run id, and the LLM model-activity rollup. Drop it into your window's sidebar — never reinvent run metadata.                                                                                        |
-| `MarkdownProse`        | `#components` → `CommonMarkdownProse`     | Render an agent's prose output as markdown.                                                                                                                                                                                                                                                                   |
-| `CopyButton`           | `#components` → `CommonCopyButton`        | The shared copy-to-clipboard affordance.                                                                                                                                                                                                                                                                      |
-| `InspectorSection`     | `#components` → `PanelsInspectorSection`  | The collapsible inspector-section shell (chevron header, count, hint) so a consumer panel reads like a built-in one.                                                                                                                                                                                          |
-| `useResultView(id)`    | auto-imported                             | The window seam contract: `{ open, blockId, instanceId, stepIndex, close }` (+ an `onOpen` loader for windows that fetch, and an `onClose` flush). Escape is owned by the shell, not here.                                                                                                                    |
-| `usePanelSubject<T>()` | `@modular-vue/core`                       | Read the block injected into an inspector panel by `<PanelsOutlet>`.                                                                                                                                                                                                                                          |
-| `useAppOverlays()`     | auto-imported                             | Open / close your own top-level overlays: `{ open(id, subject?), close(), active }`. The store-free seam a nav `run` closure uses to open an `appOverlays`-slot component (see "Top-level overlays").                                                                                                         |
+| Building block                | Reference it as                           | What it gives you                                                                                                                                                                                                                                                                                                                                                                                                |
+| ----------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ResultWindowShell`           | `#components` → `PanelsResultWindowShell` | The shared modal chrome for a result window — backdrop, header (icon/title/subtitle), a `#header-extras` slot, close button, and the modal _behaviour_ (focus-trap + return, body-scroll lock, shared-stack Escape via `useModalBehavior`). Pass `stepRef` to surface the shared "restart from here" control.                                                                                                    |
+| `StepRunMeta`                 | `#components` → `PanelsStepRunMeta`       | **The shared run-details metadata block** every agent window reuses: step position, live duration, model, run id, and the LLM model-activity rollup. Drop it into your window's sidebar — never reinvent run metadata.                                                                                                                                                                                           |
+| `MarkdownProse`               | `#components` → `CommonMarkdownProse`     | Render an agent's prose output as markdown.                                                                                                                                                                                                                                                                                                                                                                      |
+| `CopyButton`                  | `#components` → `CommonCopyButton`        | The shared copy-to-clipboard affordance.                                                                                                                                                                                                                                                                                                                                                                         |
+| `InspectorSection`            | `#components` → `PanelsInspectorSection`  | The collapsible inspector-section shell (chevron header, count, hint) so a consumer panel reads like a built-in one.                                                                                                                                                                                                                                                                                             |
+| `useResultView(id)`           | auto-imported                             | The window seam contract: `{ open, blockId, instanceId, stepIndex, close }` (+ an `onOpen` loader for windows that fetch, and an `onClose` flush). Escape is owned by the shell, not here.                                                                                                                                                                                                                       |
+| `useResultViewRunMeta(id, …)` | auto-imported                             | The `StepRunMeta` prop bundle (`{ step, instanceId, position, totalSteps, runFailed, failureAt }`), resolved for BOTH ways a window opens. A window reachable off-path — from a board card or the inspector — carries no `stepIndex`, so wiring `StepRunMeta` straight off `useResultView` leaves it blank on exactly that route; this resolves the block's live run and the step your view id declares instead. |
+| `usePanelSubject<T>()`        | `@modular-vue/core`                       | Read the block injected into an inspector panel by `<PanelsOutlet>`.                                                                                                                                                                                                                                                                                                                                             |
+| `useAppOverlays()`            | auto-imported                             | Open / close your own top-level overlays: `{ open(id, subject?), close(), active }`. The store-free seam a nav `run` closure uses to open an `appOverlays`-slot component (see "Top-level overlays").                                                                                                                                                                                                            |
 
 > **Reference layer components through `#components`, not bare tags.** Nuxt auto-registers a
 > layer's components under a **path-derived** name (`components/panels/ResultWindowShell.vue`

package/app/modular/panels/inspector.logic.spec.ts

@@ -98,11 +98,18 @@ describe('inspector panel group', () => {
     expect(visibleIds(block('epic'))).toEqual(['epic-children'])
   })
 
-  // An initiative's planning pipeline is an ordinary run, so it shares the task body's execution
-  // panel — its own inspector leading, the run detail under it. Pinned because the panel is the
-  // only surface carrying the Stop / Discard-run controls that unwedge a stalled planning run.
-  it('an initiative shows its inspector, then the shared execution panel', () => {
-    expect(visibleIds(block('initiative'))).toEqual(['initiative-inspector', 'task-execution'])
+  // An initiative shares two of the task body's panels: the CONTEXT sections (the
+  // create-initiative modal attaches the same documents/issues, and the planning pipeline reads
+  // them, so the inspector must surface them) and the execution panel (planning is an ordinary
+  // run — and that panel carries the only Stop / Discard-run controls that unwedge a stalled
+  // one). Order is pinned too: identity + controls, the context it was given, then the run.
+  it('an initiative shows its inspector, then the shared context + execution panels', () => {
+    expect(visibleIds(block('initiative'))).toEqual([
+      'initiative-inspector',
+      'task-context-docs',
+      'task-context-issues',
+      'task-execution',
+    ])
   })
 
   it('no subject selected resolves to no panels', () => {

package/app/modular/panels/inspector.logic.ts

@@ -76,12 +76,20 @@ const isTask = (b: Block) => b.level === 'task'
 const isFrame = (b: Block) => b.level === 'frame'
 /**
  * A block whose inspector carries a pipeline RUN. An initiative's planning pipeline is an
- * ordinary run of ordinary agent steps (interviewer → analyst → planner → committer), so it
+ * ordinary run of ordinary agent steps (analyst → interviewer → planner → committer), so it
  * gets the same execution panel a task does — step list, live phases, step-detail drill-down,
  * and the Stop / Discard-run controls that are the only way to unwedge a stalled planning run.
  * Before this it had no run surface at all, which is why a stuck plan was a dead end.
  */
 const hasRuns = (b: Block) => isTask(b) || b.level === 'initiative'
+/**
+ * A block that carries attached CONTEXT (imported documents + tracker issues). The
+ * create-initiative modal stages the same attachments the add-task modal does and links them
+ * to the initiative block, and the whole planning pipeline reads them — so an initiative
+ * whose inspector never showed them left the user with no evidence the attachment landed and
+ * no way to reach the source. Same panels, same store reads (both are keyed by block id only).
+ */
+const takesContext = (b: Block) => isTask(b) || b.level === 'initiative'
 /** frame OR module — the "container" panels. */
 const isContainer = (b: Block) => b.level === 'frame' || b.level === 'module'
 /**
@@ -111,8 +119,9 @@ const isDeployableFrame = (b: Block) => isFrame(b) && b.type !== 'document'
  * extensibility value.
  */
 export const INSPECTOR_PANEL_SPECS: readonly InspectorPanelSpec[] = [
-  { id: 'task-context-docs', order: 10, when: isTask },
-  { id: 'task-context-issues', order: 20, when: isTask },
+  // Shared with the initiative body — an initiative takes the same attachments a task does.
+  { id: 'task-context-docs', order: 10, when: takesContext },
+  { id: 'task-context-issues', order: 20, when: takesContext },
   { id: 'recurring-schedule', order: 30, when: isTask },
   // Shared with the initiative body — the panel renders a RUN, and an initiative has one.
   { id: 'task-execution', order: 40, when: hasRuns },
@@ -133,8 +142,8 @@ export const INSPECTOR_PANEL_SPECS: readonly InspectorPanelSpec[] = [
   // test-infra and release-health panels above it.
   { id: 'service-validation-checks', order: 180, when: isDeployableFrame },
   { id: 'epic-children', order: 200, when: (b) => b.level === 'epic' },
-  // Ordered BEFORE the shared execution panel (40) so an initiative reads the way a task does:
-  // its own identity + controls first, the run detail under them. Levels never overlap, so this
+  // Ordered FIRST so an initiative reads the way a task does: its own identity + controls, then
+  // the context it was given (10/20), then the run detail (40). Levels never overlap, so this
   // number only ever competes with the task ids the initiative body doesn't render.
-  { id: 'initiative-inspector', order: 35, when: (b) => b.level === 'initiative' },
+  { id: 'initiative-inspector', order: 5, when: (b) => b.level === 'initiative' },
 ]

package/app/stores/taskExpansion.spec.ts

@@ -0,0 +1,88 @@
+import { describe, it, expect } from 'vitest'
+import { useTaskExpansionStore } from '~/stores/taskExpansion'
+import { useUiStore } from '~/stores/ui'
+
+/**
+ * The expansion gate combines two independent grants (hover at any zoom, the deep zoom
+ * bands otherwise). Both `TaskPipelineMini` (what renders) and `DraggableTask` (what
+ * stacks on top) read `isExpanded`, so these cases pin the rule they share.
+ *
+ * Zoom is set through the ui store's raw `zoom`, the same value the board canvas writes;
+ * `lod` derives from it (< 1.8 is shallower than the `steps` band).
+ */
+function setup(zoom: number) {
+  const ui = useUiStore()
+  ui.zoom = zoom
+  const store = useTaskExpansionStore()
+  store.setDriverActive(true)
+  return store
+}
+
+describe('taskExpansion — hover expands at any zoom level', () => {
+  it('expands the hovered card while zoomed out past the steps band', () => {
+    const store = setup(0.5) // `far`
+    store.setHovered('task-a')
+    expect(store.isExpanded('task-a')).toBe(true)
+    // Hover is a grant of ONE card: its neighbours stay compact at this zoom.
+    expect(store.isExpanded('task-b')).toBe(false)
+  })
+
+  it('expands the hovered card at every band, not just the shallow ones', () => {
+    const store = setup(1) // `mid`
+    store.setHovered('task-a')
+    expect(store.isExpanded('task-a')).toBe(true)
+    useUiStore().zoom = 1.5 // `close`
+    expect(store.isExpanded('task-a')).toBe(true)
+    useUiStore().zoom = 3 // `subtasks`
+    expect(store.isExpanded('task-a')).toBe(true)
+  })
+
+  it('collapses again once the pointer leaves the card', () => {
+    const store = setup(0.5)
+    store.setHovered('task-a')
+    store.setHovered(null)
+    expect(store.isExpanded('task-a')).toBe(false)
+  })
+
+  it('expands a hovered card the zoom gate denied for overlapping a neighbour', () => {
+    const store = setup(2) // `steps`
+    store.setAllowed(new Set(['task-b']))
+    store.setHovered('task-a')
+    expect(store.isExpanded('task-a')).toBe(true)
+    expect(store.isExpanded('task-b')).toBe(true)
+  })
+})
+
+describe('taskExpansion — the zoom grant is unchanged', () => {
+  it('honours the driver grant only from the steps band up', () => {
+    const store = setup(1.5) // `close` — one band shallower than `steps`
+    store.setAllowed(new Set(['task-a']))
+    expect(store.isExpanded('task-a')).toBe(false)
+    useUiStore().zoom = 2 // `steps`
+    expect(store.isExpanded('task-a')).toBe(true)
+  })
+
+  it('denies a card the driver left out of the permitted set', () => {
+    const store = setup(2)
+    store.setAllowed(new Set(['task-b']))
+    expect(store.isExpanded('task-a')).toBe(false)
+  })
+
+  it('falls back to allowed with no driver mounted, still only at the deep bands', () => {
+    const ui = useUiStore()
+    ui.zoom = 2
+    const store = useTaskExpansionStore() // driverActive stays false
+    expect(store.isExpanded('task-a')).toBe(true)
+    ui.zoom = 1
+    expect(store.isExpanded('task-a')).toBe(false)
+  })
+
+  it('drops both grants when the driver unmounts', () => {
+    const store = setup(2)
+    store.setAllowed(new Set(['task-a']))
+    store.setHovered('task-b')
+    store.setDriverActive(false)
+    expect(store.allowed.size).toBe(0)
+    expect(store.hoveredId).toBeNull()
+  })
+})

package/app/stores/taskExpansion.ts

@@ -1,37 +1,57 @@
 import { defineStore } from 'pinia'
 import { ref } from 'vue'
+import { lodAtLeast } from '~/composables/useSemanticZoom'
+import { useUiStore } from '~/stores/ui'
 
 /**
- * Which task cards may expand their full build-pipeline list once zoomed in.
+ * Which task cards render their full build-pipeline list.
  *
- * Deep-zoom (`steps`/`subtasks`) grows a task card downward, and cards are
- * absolutely positioned in their frame, so several expanded cards stacked
- * vertically pile on top of each other. The board driver (`useTaskExpansion`)
- * recomputes a permitted set every frame — only on-screen cards, the one closest to
- * the screen centre when two would overlap, plus whichever card the pointer is hovering
- * (hover expands a card regardless of position) — and writes it here.
- * `TaskPipelineMini` reads `canExpand` to decide whether to expand or stay compact.
+ * Two independent grants, both written every frame by the board driver
+ * (`useTaskExpansion`) and combined HERE so the render (`TaskPipelineMini`) and the
+ * stacking (`DraggableTask`) can never disagree about which cards are expanded:
  *
- * `driverActive` lets the gate degrade gracefully: with no board driver mounted
- * (e.g. a card rendered in isolation) `canExpand` falls back to "allowed", so the
- * plain zoom behaviour is unchanged.
+ *  - HOVER — the card under the pointer expands at ANY zoom level. Pointing at a task
+ *    is asking what it is doing right now, and that answer used to be reachable only
+ *    by first zooming past the `steps` band.
+ *  - ZOOM — past the `steps` band, every on-screen card expands. Deep-zoom grows a card
+ *    downward and cards are absolutely positioned in their frame, so several expanded
+ *    cards stacked vertically pile on top of each other; the driver denies whichever
+ *    would collide with a card nearer the screen centre and writes the survivors here.
+ *
+ * `driverActive` lets the zoom grant degrade gracefully: with no board driver mounted
+ * (e.g. a card rendered in isolation) it falls back to "allowed", so the plain zoom
+ * behaviour is unchanged. The hover grant needs no fallback — without the driver
+ * nothing is hovered.
  */
 export const useTaskExpansionStore = defineStore('taskExpansion', () => {
+  const ui = useUiStore()
   const allowed = ref<Set<string>>(new Set())
+  const hoveredId = ref<string | null>(null)
   const driverActive = ref(false)
 
   function setAllowed(ids: Set<string>) {
     allowed.value = ids
   }
 
+  function setHovered(id: string | null) {
+    hoveredId.value = id
+  }
+
   function setDriverActive(active: boolean) {
     driverActive.value = active
-    if (!active) allowed.value = new Set()
+    if (!active) {
+      allowed.value = new Set()
+      hoveredId.value = null
+    }
   }
 
-  function canExpand(id: string) {
+  /** Whether this task card should render its pipeline: hovered at any zoom, else
+   *  granted by the deep-zoom bands. */
+  function isExpanded(id: string) {
+    if (hoveredId.value === id) return true
+    if (!lodAtLeast(ui.lod, 'steps')) return false
     return driverActive.value ? allowed.value.has(id) : true
   }
 
-  return { allowed, driverActive, setAllowed, setDriverActive, canExpand }
+  return { allowed, hoveredId, driverActive, setAllowed, setHovered, setDriverActive, isExpanded }
 })