@cat-factory/app 0.274.0 → 0.276.0

package/README.md

@@ -15,6 +15,8 @@ The SPA source lives under `app/` (the Nuxt srcDir).
 - [What it is](#what-it-is)
 - [Tech stack](#tech-stack)
 - [Layout](#layout)
+- [Task swimlanes](#task-swimlanes)
+- [Roles (engineer / product manager / designer)](#roles-engineer--product-manager--designer)
 - [Interface modes (basic / advanced)](#interface-modes-basic--advanced)
 - [Agent tiers (basic / intermediate / advanced)](#agent-tiers-basic--intermediate--advanced)
 - [In-app tutorial tours](#in-app-tutorial-tours)
@@ -239,6 +241,153 @@ surface rather than a toast, and are tracked as G4 in
 
 A status → chip map feeding a `<UBadge :color="…">` types its values as `BadgeColor` (`utils/badge.ts`), which is derived from `UBadge`'s own prop type rather than restated as a literal union. Typed `string`, the binding does not compile and the reflex is `as any` at each call site: seven of them had accumulated. That cast also accepts a colour Nuxt UI does not define, which renders as an unstyled badge with nothing failing.
 
+## Task swimlanes
+
+A service frame lays its tasks out in **status lanes**, not at coordinates. Three lanes a reader
+works in (`not_started`, `in_progress`, `needs_you`) plus a collapsed **Done** strip beneath them.
+The vocabulary, the classification and the Done caps are `app/utils/swimlanes.ts`; the ordering and
+grouping are `app/utils/laneSort.ts`; `composables/useFrameLanes.ts` is the only store-facing half.
+
+**A lane is a CLAIM, which is a higher bar than a badge.** A mislabelled badge sits beside the
+truth; a card filed in the wrong lane states something false _and_ hides the card from the column
+its reader was scanning. Three rules follow, and they are what the tests pin:
+
+- **The classification is TOTAL.** `BASE_REASON_BY_STATUS` is a `Record<BlockStatus, …>`, so a new
+  status fails the build; and a status the TYPE says is impossible while the DATABASE still holds it
+  (a retired picklist member on an old row) resolves to `unclassified` → `needs_you`, never to
+  `undefined`, which would drop the card out of every lane with nothing left to say it existed.
+- **An imprecise reason beats a wrong lane.** The SPA models only decisions and approvals as global
+  per-block selectors; a judge / human-test / visual-confirmation / fork / follow-up / input-gate
+  park is reachable only by drilling into a step. But every one of them parks the RUN at
+  `status: 'blocked'`, and that coarse marker places the card correctly even when this layer cannot
+  name the surface. Such a park reports `parked` — named but imprecise, never demoted to "in flight".
+- **The reason is a separate answer from the lane.** The lane says "look at this"; the reason says
+  "what would I do". `failed`, `budget_paused` and `approval` all stop work dead and need three
+  unrelated actions, which is why `blocking_reason` is a grouping and why a lane header can name it.
+
+**Ordering defaults per lane** (`smart`), because the actionable order genuinely differs by column:
+what can be started now / what has gone quiet / what has waited longest. Two rules bind any new
+comparator: an **unknown timestamp sorts last in BOTH directions** (a run that reported no activity
+is not stale and not fresh, and ranking it as either invents a fact), and **every comparator ends on
+board order**, since these re-run on every live push and an unresolved tie makes the lane shuffle
+itself. `nullsLast` is the single place the first rule lives.
+
+**Sizing is decoupled from content** (`utils/laneGeometry.ts`). A lane scrolls; it does not grow. A
+service with 300 open tasks gets the same frame as one with three, which is what the old free layout
+could not do — a busy service grew until it dwarfed its neighbours.
+
+Three consumers have to agree about that size, which is why the module exports two FUNCTIONS rather
+than leaving each to do the arithmetic: `frameContentSize` is the frame's floor (read by
+`contentSize`, and by `framePlacement.EMPTY_FRAME_SIZE`, which has to reserve a spot for a frame
+that does not exist yet and so cannot measure it), and `laneBodyHeightIn` is its inverse, handing a
+lane whatever the frame's ACTUAL size leaves it. A dragged border therefore grows the lanes rather
+than leaving dead canvas below them, and a constant restating either answer is exactly what went
+stale before. A frame with no children at all is the one that skips the lanes: it renders one "add
+the first task" panel and is sized for that.
+
+**Two preferences, deliberately different scopes.** The sort/group choice is per user, per browser
+(`stores/laneView.ts`, persisted like the interface tier): it is personal and changes several times
+an hour, and making it shared would let one person's triage sweep re-arrange everyone's board. The
+Done lane's two **caps** are per-workspace settings (`doneLaneMaxItems`, `doneLaneRetentionDays`),
+because what the board may show of a service's history is a shared decision. Both caps hide cards
+only, and the lane reports the two drop counts separately: an age drop means "there is older
+history", a cap drop means "there is more from this period".
+
+**A task with no `completedAt` is exempt from the age cap**, not treated as ancient. Every block
+merged before that column existed reads that way, and hiding history on the strength of a timestamp
+nobody recorded would be the platform inferring a fact it does not have. The count cap still bounds
+them, so the exemption cannot make the lane unbounded, and `undatedShown` says how many there are.
+
+**A FRAME still has coordinates, and they live on its `WorkspaceMount`, not on the block** (one
+shared service sits at a different spot on every board that mounts it), so every frame-returning read
+projects through kernel's `applyMountLayout`. The resize path is where people hit a missed projection,
+because a `size`-only edit is the one frame patch with no other visible effect: the SPA upserts the
+authoritative block the mutation returned and the frame jumps to coordinates no board shows it at.
+
+**Dragging a card now only reparents** (`positioned: false` in `useBlockDrag`): between services,
+and into or out of a module via a module group header's drop zone. Which LANE a card is in is not
+something a drop can decide — the lane is derived from state, so dropping a not-started card on
+"In progress" could only lie or silently do nothing. Because that drop target exists only while the
+reader has grouping set to `module`, the inspector carries a **module picker** that does not depend
+on the current grouping; module sub-frames no longer render as boxes, so without it the only route
+into a module would be to change a view preference first.
+
+**A move re-stamps the module the task DECLARES**, which is the one thing about that drag that is
+not obvious. A task names its module twice: the block it is parented to, and `moduleName`, which
+exists because the engine only materialises the module block on merge, so a task can name its module
+before anything is its parent. Grouping reads the parent and falls back to the declared name — so a
+card dragged OUT of a module and left still declaring it lands right back in the group it came from.
+`BoardService.reparent` therefore rewrites the name from the destination container, exactly as it
+already rewrote the `type` a task inherits from its frame, and the SPA's optimistic write predicts
+the same answer through the shared `moduleNameInContainer` (`@cat-factory/contracts`) so the card
+does not visibly jump when the response lands. "No module" is the EMPTY STRING on the wire, the way
+every other clearable field spells a clear; `undefined` is dropped by `JSON.stringify` and reaches
+the server as an empty patch.
+
+## Roles (engineer / product manager / designer)
+
+The outermost of the three narrowing axes, and the only one the app **asks about**: on a first-ever
+launch it puts up one question, "what do you work on?", offering `engineer`, `product-manager` and
+`designer` with a line each on what picking it gives you. Vocabulary, resolution and the
+presentation table are in `app/utils/uiRole.ts`; the choice and its once-per-session prompt live in
+the `uiRole` store.
+
+Two roles, three names. `engineer` and `product-manager` both map to the **`full`** surface, and
+that is the product decision rather than an oversight: the two do the same job in this app (plan
+work on a board, run it, review and merge it), and what makes the question answerable is the copy a
+person recognises themselves in. `designer` maps to **`intake`**: the services already on the board,
+the work in flight on them, and the routes that bring new work IN (a new task, a task from a tracker
+ticket, a task from a design). None of the platform configuration behind that. They are separate
+`UiRole` members precisely so one of them can gain a surface the other does not without a migration.
+
+- **The default is the FULL surface, and an unanswered question changes nothing.** Closing the prompt
+  writes no choice, so the next launch asks again and the person keeps the whole product in the
+  meantime. There is deliberately no "don't ask me again": an unanswered question costs nothing,
+  where a wrongly-recorded one costs somebody destinations they need. It is also why the prompt
+  yields to every startup advisory (and why the tour offer, in turn, yields to it: the role decides
+  which surfaces exist, so a tour picked ahead of it could be about half a product).
+- **It is not authorization.** Workspace RBAC (ADR 0025) decides what a request may do and is
+  enforced server-side; this decides what the SPA OFFERS, and every role's surface is still gated by
+  the caller's permissions on top. Nothing here can widen what a person may do, and everything it
+  hides is something they may well be allowed to open, which is why the **way back is reachable from
+  inside the narrowed role**: the switcher at the top of the sidebar (rendered in every role) plus a
+  command-palette entry, both `intake`.
+- **There is NO deployment env pin**, unlike the interface tier. Which tier a fleet of kiosk-ish
+  deployments shows is a decision an operator can reasonably make; which JOB the person at the
+  keyboard does is not something a build can know.
+- **A narrowed role CAPS the interface tier at basic** (`resolveUiMode` takes the surface and answers
+  `basic` for `intake`, ahead of the env pin). Resolved rather than merely hidden, so every
+  `isAdvanced` reader inside a surface agrees with the narrowed nav without restating the role, and
+  the tier switcher is dropped for that role: a control that flipped a tier the resolver fixes would
+  be the same lie it refuses to be under an env pin.
+
+The seams, and what a new feature should use rather than reading the store ad hoc:
+
+- **A nav destination** declares `intake: true` in `app/modular/nav-contributions.ts` to survive a
+  narrowed role. It is **opt-in**, so a destination added later defaults to the full-surface roles:
+  getting that wrong costs one flag, where the other default is a persona that stopped being simple
+  without anyone deciding to un-simplify it. Today's set is three (`tutorial`,
+  `keyboard-shortcuts`, `ui-role`), and `nav-contributions.spec.ts` pins it against a table naming
+  each one's reason, so adding a fourth forces the claim to be written down. The `fullSurface` gate
+  rides the same reactive `NavGates` service as `advancedMode`, so a role switch re-gates all three
+  shells with no reload; all three axes (role, tier, `gate`) must pass.
+- **A deployment's own external tool** declares the same flag, and defaults the same way. The three
+  axes live on one `NavGatedContribution` that both `NavContribution` and `ExternalToolContribution`
+  extend, and `navSlotFilter` runs the one `navItemVisible` over both slots, because a tool is
+  projected onto a nav contribution downstream. A tool filtered by any other expression is a
+  registered application that outlives the narrowing every destination beside it obeys, which is how
+  the role axis first shipped; `nav-contributions.spec.ts` pins the two slots' verdicts in lockstep
+  across the axes rather than trusting the two spellings to stay equal.
+- **A surface that narrows inline** reads `useUiRoleStore().fullSurface` (the frame header's bug-hunt
+  button, the palette's per-connection integration commands). Same rule as the tier: what remains
+  must be exactly what the full surface would have shown, only less of it.
+- **A tutorial tour whose step clicks a non-`intake` nav entry declares
+  `TUTORIAL_REQUIREMENTS.fullSurface`.** Which tours those are is not a judgement call:
+  `tutorial-tours.spec.ts` derives the pairing from `navItemVisible`, so a tour that gains such a
+  step fails until the requirement is declared. A single STEP that the role removes (the orientation
+  tour's interface-tier step) declares `when` instead, so it is dropped rather than reported as an
+  abridged tour.
+
 ## Interface modes (basic / advanced)
 
 The SPA renders at one of two **interface tiers**. `basic` (the default) is the everyday
@@ -247,6 +396,8 @@ options that only exist to override a workspace-level default are left at that d
 the nav is trimmed to what that loop needs. `advanced` shows everything. The tier resolves in
 a fixed order, first match wins:
 
+0. **The [role](#roles-engineer--product-manager--designer)'s surface**, as a ceiling: an `intake`
+   role renders `basic` whatever the two below say.
 1. **`NUXT_PUBLIC_UI_MODE`** (`basic` | `advanced`): the deployment pin. Like
    `NUXT_PUBLIC_API_BASE` it is baked in at **build** time (`ssr: false`), and while it is
    set the in-app switcher is a read-only indicator, since a preference the resolver ignores
@@ -274,8 +425,8 @@ hoc where it can be avoided:
 
 - **A nav destination** declares `advanced: true` in `app/modular/nav-contributions.ts`. The
   shared `navSlotFilter` drops it in basic mode across all three shells (sidebar, command
-  palette, toolbar), independently of its RBAC `gate`: both must pass. A consumer module's
-  own contributions take the same flag. The bar is **whether the everyday delivery loop needs
+  palette, toolbar), independently of its RBAC `gate` and of the role's `intake` flag: all
+  three must pass. A consumer module's own contributions take the same flag. The bar is **whether the everyday delivery loop needs
   it**, and marking an item does one of two distinguishable things:
   - **Reached another way**; a shortcut whose surface a basic destination also opens, so
     nothing is lost (the Merge / Service-best-practices palette entries into Workspace
@@ -937,8 +1088,11 @@ example ships in [`deploy/frontend`](https://github.com/kibertoad/cat-factory/tr
 ## Key UI surfaces
 
 - **Board canvas** (`components/board`): `BoardCanvas` + `nodes/` (`BlockNode`,
-  `ModuleFrame`, `TaskCard`), dependency edges, the per-block `AgentFailureCard` /
-  `AgentStopButton`, and a deep-zoom `focus/BlockFocusView`. A running task card expands
+  `FrameSwimlanes` / `TaskLane` / `LaneGroup` / `LaneTask`, `TaskCard`), dependency edges,
+  the per-block `AgentFailureCard` /
+  `AgentStopButton`, and a deep-zoom `focus/BlockFocusView`. Tasks are laid out in status
+  lanes rather than at coordinates (see [Task swimlanes](#task-swimlanes)); the board-level
+  order/grouping override is `LaneViewControl` in the toolbar. 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`.

package/app/components/board/LaneViewControl.vue

@@ -0,0 +1,87 @@
+<script setup lang="ts">
+import {
+  LANE_GROUP_KEYS,
+  LANE_SORT_KEYS,
+  type LaneGroupKey,
+  type LaneSortKey,
+} from '~/utils/laneSort'
+import { showOverrideField } from '~/utils/uiMode'
+
+/**
+ * The board-level override for how every frame's swimlanes are ordered and grouped.
+ *
+ * It is an OVERRIDE, which is what makes it an advanced-tier affordance: hidden, what remains is
+ * exactly the `smart` per-lane order and no grouping — the default it would otherwise have shown.
+ * The gate is `showOverrideField` rather than `isAdvanced` alone, because the preference persists
+ * per browser: someone who picks "by severity" in advanced mode and then switches to basic must
+ * still be able to see and clear it, or the board would be ordered by a rule they cannot find.
+ */
+const { t } = useI18n()
+const uiMode = useUiModeStore()
+const laneView = useLaneViewStore()
+
+// The DEFAULT values are passed as `undefined` rather than as themselves: `showOverrideField`
+// reveals the control as soon as any value it edits is set, and `smart`/`none` being set is
+// exactly the state where there is nothing to reveal.
+const visible = computed(() =>
+  showOverrideField(
+    uiMode.isAdvanced,
+    laneView.sortKey === 'smart' ? undefined : laneView.sortKey,
+    laneView.groupKey === 'none' ? undefined : laneView.groupKey,
+  ),
+)
+
+const sortItems = computed(() =>
+  LANE_SORT_KEYS.map((key) => ({
+    label: t(`board.lanes.sort.${key}`),
+    icon: laneView.sortKey === key ? 'i-lucide-check' : undefined,
+    onSelect: () => laneView.setSortKey(key as LaneSortKey),
+  })),
+)
+
+const groupItems = computed(() =>
+  LANE_GROUP_KEYS.map((key) => ({
+    label: t(`board.lanes.group.${key}`),
+    icon: laneView.groupKey === key ? 'i-lucide-check' : undefined,
+    onSelect: () => laneView.setGroupKey(key as LaneGroupKey),
+  })),
+)
+
+/**
+ * One menu, two labelled sections, plus a reset. Grouped rather than two adjacent buttons because
+ * the two choices are read together — "the newest bugs, by module" is one intent — and because the
+ * toolbar has no room for two more controls at small widths.
+ */
+const items = computed(() => [
+  [{ label: t('board.lanes.sort.heading'), type: 'label' as const }],
+  sortItems.value,
+  [{ label: t('board.lanes.group.heading'), type: 'label' as const }],
+  groupItems.value,
+  ...(laneView.hasOverride
+    ? [
+        [
+          {
+            label: t('board.lanes.resetView'),
+            icon: 'i-lucide-rotate-ccw',
+            onSelect: () => laneView.reset(),
+          },
+        ],
+      ]
+    : []),
+])
+</script>
+
+<template>
+  <UDropdownMenu v-if="visible" :items="items">
+    <UButton
+      color="neutral"
+      :variant="laneView.hasOverride ? 'soft' : 'ghost'"
+      size="sm"
+      icon="i-lucide-arrow-down-up"
+      :title="t('board.lanes.viewTitle')"
+      data-testid="lane-view-control"
+    >
+      <span class="hidden sm:inline">{{ t('board.lanes.viewTitle') }}</span>
+    </UButton>
+  </UDropdownMenu>
+</template>

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

@@ -2,15 +2,15 @@
 import type { Block, BlockStatus } from '~/types/domain'
 import { blockTypeMeta, STATUS_META } from '~/utils/catalog'
 import DecisionBadge from './DecisionBadge.vue'
-import DraggableTask from './DraggableTask.vue'
+import FrameSwimlanes from './FrameSwimlanes.vue'
 import InitiativeCard from './InitiativeCard.vue'
-import ModuleFrame from './ModuleFrame.vue'
 import ResizeGrips from './ResizeGrips.vue'
 import AgentFailureCard from '~/components/board/AgentFailureCard.vue'
 import AgentStopButton from '~/components/board/AgentStopButton.vue'
 import { useBlockDrag } from '~/composables/useBlockDrag'
 import { useFrameStacking } from '~/composables/useFrameStacking'
 import { useViewport } from '~/composables/useViewport'
+import { laneBodyHeightIn } from '~/utils/laneGeometry'
 
 // Vue Flow passes the node's `id` and `data` as props to custom node components.
 // Only frames are rendered as board nodes; their tasks live inside the card.
@@ -26,6 +26,7 @@ const services = useServicesStore()
 const reviews = useReviewStage()
 const access = useWorkspaceAccess()
 const uiMode = useUiModeStore()
+const uiRole = useUiRoleStore()
 const { t } = useI18n()
 const { lod } = useSemanticZoom()
 // Coarse-pointer (touch) bumps the frame-header actions from `xs` to `sm` so
@@ -42,7 +43,9 @@ const isShared = computed(() => services.isSharedFrame(props.id))
 const typeMeta = computed(() => (block.value ? blockTypeMeta(block.value.type) : null))
 
 // ---- this service's children (tasks + modules) -----------------------------
-const directTasks = computed(() => board.tasksOf(props.id))
+// No `directTasks` here: the swimlanes take EVERY task under the frame, its modules' included,
+// because a module is a grouping inside a lane now rather than a box of its own. `modules` is
+// still read for the composition line's module count.
 const modules = computed(() => board.modulesOf(props.id))
 const initiativeBlocks = computed(() => board.initiativesOf(props.id))
 const allTasks = computed(() => board.allTasksUnder(props.id))
@@ -53,6 +56,9 @@ const hasTasks = computed(
 )
 const prTasks = computed(() => allTasks.value.filter((t) => t.status === 'pr_ready').length)
 const canvas = computed(() => board.containerSize(props.id))
+// A lane's scroll viewport fills whatever the frame's actual size leaves it, so dragging the
+// frame's border gives the reader more of the lane rather than dead canvas beneath it.
+const laneBodyHeight = computed(() => laneBodyHeightIn(canvas.value, initiativeBlocks.value.length))
 
 // Frame status is derived from its tasks — services never reach "done".
 const frameStatus = computed<BlockStatus>(() => board.frameStatus(props.id))
@@ -272,7 +278,7 @@ const ITEM_ICON: Record<string, string> = {
       />
     </div>
 
-    <!-- ===================== The service card: 2D canvas of tasks + modules =====================
+    <!-- ============= The service card: the initiative band + task swimlanes =============
          There is no chip or compact variant: a service is always expanded to its task canvas, at
          every zoom level, so panning is a fixed layout and zooming has no expand/collapse
          transition to snap on. The two gated-off branches that used to sit here (a far-zoom chip
@@ -460,8 +466,13 @@ const ITEM_ICON: Record<string, string> = {
                   :title="t('board.frame.createInitiativeTitle')"
                   @click.stop="createInitiative"
                 />
+                <!-- Hunting a tracker board for a bug worth adopting is TRIAGE, not intake: it
+                     rates open bugs against each other and picks one to take on, which is the
+                     engineer/PM judgement call. So it is dropped for a narrowed role, whose three
+                     routes in (a new task, a task from a named ticket, a task from a design) all
+                     start from work somebody has already decided to do. -->
                 <UButton
-                  v-if="tasks.anyOffered"
+                  v-if="tasks.anyOffered && uiRole.fullSurface"
                   class="nodrag"
                   data-testid="frame-hunt-bugs"
                   :size="isTouch ? 'sm' : 'xs'"
@@ -495,15 +506,24 @@ const ITEM_ICON: Record<string, string> = {
           </div>
         </div>
 
-        <!-- the 2D drop zone: modules and loose tasks live here, draggable -->
+        <!-- The frame's canvas. Tasks are laid out in status swimlanes rather than at
+             coordinates, so this is a fixed-size viewport (each lane scrolls) instead of the 2D
+             free-drag surface it used to be. `data-drop-zone` stays on the outer box so a drop
+             in the padding between lanes still resolves to this service rather than falling
+             through to nothing; each lane body carries the same zone for drops inside it. -->
         <div
           :data-drop-zone="block.id"
-          class="nodrag relative rounded-xl bg-slate-950/40"
-          :style="{ width: canvas.w + 'px', height: canvas.h + 'px' }"
+          class="nodrag relative rounded-xl bg-slate-950/40 p-2"
+          :style="{ width: canvas.w + 'px', minHeight: canvas.h + 'px' }"
         >
-          <ModuleFrame v-for="m in modules" :key="m.id" :module-id="m.id" />
-          <InitiativeCard v-for="i in initiativeBlocks" :key="i.id" :block-id="i.id" />
-          <DraggableTask v-for="t in directTasks" :key="t.id" :task-id="t.id" />
+          <!-- Initiatives sit in a wrapping band above the lanes: they are containers of work,
+               not units of it, so they belong in no status lane. -->
+          <div v-if="initiativeBlocks.length" class="mb-2 flex flex-wrap gap-2">
+            <InitiativeCard v-for="i in initiativeBlocks" :key="i.id" :block-id="i.id" />
+          </div>
+
+          <FrameSwimlanes v-if="hasTasks" :frame-id="block.id" :lane-body-height="laneBodyHeight" />
+
           <button
             v-if="!hasTasks && access.canWriteBoard.value"
             type="button"

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

@@ -0,0 +1,139 @@
+<script setup lang="ts">
+import LaneGroup from './LaneGroup.vue'
+import TaskLane from './TaskLane.vue'
+import { useFrameLanes } from '~/composables/useFrameLanes'
+import { LANE_GEOMETRY } from '~/utils/laneGeometry'
+import { LANE_META } from '~/utils/swimlanes'
+
+/**
+ * A service frame's tasks, laid out in status lanes.
+ *
+ * Three live lanes side by side, then the Done lane as a full-width strip beneath them rather
+ * than a fourth column. A collapsed column cannot state its own count without turning its label
+ * sideways, and giving the archive a quarter of the width permanently would take it from the
+ * three lanes a reader actually works in. As a strip it is one row when shut and a wide grid when
+ * opened, which is also the better shape for scanning history.
+ */
+const props = defineProps<{
+  frameId: string
+  /** A live lane's scroll viewport, resolved by the frame from its own size. */
+  laneBodyHeight: number
+}>()
+
+const { t } = useI18n()
+const laneView = useLaneViewStore()
+const { lanes, doneSelection } = useFrameLanes(computed(() => props.frameId))
+
+const liveLanes = computed(() => lanes.value.filter((l) => l.lane !== 'done'))
+const doneLane = computed(() => lanes.value.find((l) => l.lane === 'done'))
+
+/**
+ * What the Done lane is holding back, as one line.
+ *
+ * The two counts are reported separately because they tell a reader different things: an age
+ * drop means "there is older history, look further back", a cap drop means "there is more from
+ * this same period". Reporting nothing at all would be the worse failure — a truncated archive
+ * would read exactly like a complete one.
+ */
+const withheldNote = computed(() => {
+  const { hiddenByAge, hiddenByCap, undatedShown } = doneSelection.value
+  const parts: string[] = []
+  if (hiddenByCap > 0) parts.push(t('board.lanes.done.hiddenByCap', { count: hiddenByCap }))
+  if (hiddenByAge > 0) parts.push(t('board.lanes.done.hiddenByAge', { count: hiddenByAge }))
+  // Blocks merged before completion dates were recorded have no honest age, so the age cap
+  // cannot apply to them. Saying so stops the window looking tighter than it is.
+  if (undatedShown > 0 && hiddenByAge > 0) {
+    parts.push(t('board.lanes.done.undated', { count: undatedShown }))
+  }
+  return parts.join(' · ')
+})
+</script>
+
+<template>
+  <div class="space-y-2">
+    <!-- The three lanes a reader works in -->
+    <div class="flex items-start" :style="{ gap: LANE_GEOMETRY.laneGap + 'px' }">
+      <TaskLane
+        v-for="rendered in liveLanes"
+        :key="rendered.lane"
+        :rendered="rendered"
+        :group-key="laneView.groupKey"
+        :frame-id="frameId"
+        :body-height="laneBodyHeight"
+      />
+    </div>
+
+    <!-- The Done strip. Rendered only once the service HAS finished something: an empty archive
+         is the one lane whose emptiness says nothing a reader needs (a new service has merged
+         nothing, which its three live lanes already show). -->
+    <div v-if="doneLane && doneLane.total > 0" class="rounded-lg bg-slate-900/40">
+      <button
+        type="button"
+        class="nodrag flex w-full items-center gap-1.5 rounded-lg px-2 py-1.5 text-left hover:bg-slate-800/40"
+        data-testid="done-lane-toggle"
+        :aria-expanded="!laneView.doneLaneCollapsed"
+        @click.stop="laneView.toggleDoneLane()"
+      >
+        <UIcon
+          :name="laneView.doneLaneCollapsed ? 'i-lucide-chevron-right' : 'i-lucide-chevron-down'"
+          class="h-3.5 w-3.5 shrink-0 text-slate-500"
+        />
+        <UIcon
+          :name="LANE_META.done.icon"
+          class="h-3.5 w-3.5 shrink-0"
+          :style="{ color: LANE_META.done.color }"
+        />
+        <span class="text-[11px] font-semibold text-slate-200">{{
+          t(LANE_META.done.labelKey)
+        }}</span>
+        <!-- The TOTAL, not what the caps admitted: "this service has finished 312 tasks" is the
+             fact the lane carries, and counting only the visible cards would understate it by
+             two orders of magnitude. -->
+        <span
+          class="shrink-0 rounded px-1 text-[10px] font-semibold tabular-nums"
+          :style="{
+            backgroundColor: LANE_META.done.color + '22',
+            color: LANE_META.done.color,
+          }"
+          data-testid="lane-count-done"
+          >{{ doneLane.total }}</span
+        >
+        <span v-if="withheldNote" class="ms-auto truncate text-[10px] text-slate-500">{{
+          withheldNote
+        }}</span>
+      </button>
+
+      <!-- The archive opens as a WIDE GRID: each group takes the strip's full width and wraps its
+           own cards across it, and the groups stack. Wrapping the GROUPS instead read correctly
+           only when there were several of them — under the default `none` grouping a lane is
+           exactly one group, so the whole archive rendered as a single card-wide column down the
+           left of an otherwise empty strip. -->
+      <div
+        v-if="!laneView.doneLaneCollapsed"
+        :data-drop-zone="frameId"
+        data-testid="lane-done"
+        data-lane="done"
+        class="nodrag space-y-2 overflow-y-auto p-2 pt-0"
+        :style="{ maxHeight: laneBodyHeight + 'px' }"
+      >
+        <!-- A zero cap is a real setting ("count them, show none"), so the strip explains why it
+             has nothing in it rather than looking broken. -->
+        <p
+          v-if="doneSelection.shown.length === 0"
+          class="px-1 text-[10px] leading-snug text-slate-600"
+        >
+          {{ t('board.lanes.done.allWithheld') }}
+        </p>
+        <LaneGroup
+          v-for="(group, i) in doneLane.groups"
+          v-else
+          :key="group.label ?? `catch-all-${i}`"
+          :group="group"
+          :group-key="laneView.groupKey"
+          :frame-id="frameId"
+          layout="grid"
+        />
+      </div>
+    </div>
+  </div>
+</template>

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

@@ -9,10 +9,14 @@
 // 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.
+// The tracker button opens the dedicated window directly.
+//
+// Laid out in a wrapping band above the frame's task swimlanes, not at coordinates. It used to be
+// free-positioned inside the frame's canvas beside the task cards, and lost that along with them
+// when tasks moved into lanes: with the canvas gone there is nothing left for an initiative's
+// coordinates to be relative to, and its drag handle only ever moved it within a canvas nothing
+// renders now. An initiative is still a first-class board block with its own inspector.
 import type { InitiativeStatus } from '~/types/domain'
-import { useBlockDrag } from '~/composables/useBlockDrag'
 import { useInitiativePlanning } from '~/composables/useInitiativePlanning'
 import {
   INITIATIVE_ATTENTION_ICONS,
@@ -27,7 +31,6 @@ const board = useBoardStore()
 const initiatives = useInitiativesStore()
 const ui = useUiStore()
 const { t } = useI18n()
-const { draggingId, startDrag } = useBlockDrag()
 
 const block = computed(() => board.getBlock(props.blockId))
 const initiative = computed(() => initiatives.forBlock(props.blockId))
@@ -56,36 +59,14 @@ const {
 function select() {
   ui.select(props.blockId)
 }
-function onHandle(e: PointerEvent) {
-  if (block.value) startDrag(block.value, e)
-}
 </script>
 
 <template>
-  <div
-    v-if="block"
-    class="absolute w-[230px]"
-    :style="{
-      left: block.position.x + 'px',
-      top: block.position.y + 'px',
-      zIndex: draggingId === blockId ? 60 : 10,
-      pointerEvents: draggingId === blockId ? 'none' : undefined,
-    }"
-  >
-    <div
-      class="nodrag nopan flex cursor-grab touch-none items-center justify-center rounded-t-lg border border-b-0 border-indigo-800/60 bg-indigo-950/60 py-px active:cursor-grabbing pointer-coarse:py-2"
-      :title="t('board.frame.dragTask')"
-      @pointerdown="onHandle"
-    >
-      <UIcon
-        name="i-lucide-grip-horizontal"
-        class="h-3 w-3 text-indigo-400/60 pointer-coarse:h-5 pointer-coarse:w-5"
-      />
-    </div>
+  <div v-if="block" class="w-[230px]">
     <div
       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="cursor-pointer rounded-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 || attention ? 'board-pulse' : '',