@cat-factory/app 0.173.0 → 0.176.0

package/README.md

@@ -56,10 +56,10 @@ over the WebSocket. How that sync works is written up in
 ## Interface modes (basic / advanced)
 
 The SPA renders at one of two **interface tiers**. `basic` (the default) is the everyday
-surface: the run/pipeline options that only exist to override a workspace-level default are
-left at that default, and the nav is trimmed to the destinations that are the **only route**
-to their capability. `advanced` shows everything. The tier resolves in a fixed order, first
-match wins:
+**delivery** surface — plan work on a board, run it, review and merge it: the run/pipeline
+options that only exist to override a workspace-level default are left at that default, and
+the nav is trimmed to what that loop needs. `advanced` shows everything. The tier resolves in
+a fixed order, first match wins:
 
 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
@@ -82,20 +82,32 @@ 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 for setting it is **route count, not how
-  advanced the surface feels**: hiding the only way to reach a capability removes the
-  capability from the tier, while hiding a shortcut into a surface a basic destination also
-  opens removes nothing. So the flag belongs on a surface that sits beside the delivery path
-  (Sandbox, Kaizen), on a palette shortcut into a Workspace-settings tab, or on a knob the
-  Integrations hub already offers — and never on a sole route (the pipeline builder, the
-  fragment library, the infrastructure/PREnv windows, the operator + reports views).
-  `nav-contributions.spec.ts` pins the advanced set against a table of each item's
-  alternative route, so promoting one forces that claim to be written down.
+  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
+    settings, the local-models knob the Integrations hub already offers).
+  - **Out of the tier** — the sole route, hidden on purpose, so the capability is _absent_
+    from basic mode and the tier switch is the way to it (Sandbox, Kaizen, repo bootstrap,
+    and the deployment-wide operator + reports rollups).
+
+  Sole-route items stay in basic when the delivery loop runs on them: the pipeline builder,
+  add-from-repo, the fragment library, the infrastructure/PREnv windows, and the workspace /
+  model configuration a run actually reads. `nav-contributions.spec.ts` pins the advanced set
+  against a table naming each item's kind and reason, so promoting one forces that claim to be
+  written down rather than assumed.
+
 - **A less-used option inside a surface** reads `useUiModeStore().isAdvanced`. Hide, never
   disable, and only ever hide an OVERRIDE: what remains must be exactly the default the hidden
   field would have shown, so a basic-mode user never gets different behaviour from an advanced
   one — only fewer choices. An input nothing else supplies (the pipeline, the apriori branches)
   stays in both tiers however advanced it feels.
+- **A whole AUTHORING affordance** may be tier-scoped the same way — the frame header's
+  recurring-schedule and initiative buttons are advanced-only — but only while the tier hides
+  the ability to CREATE, never the ability to SEE. Existing state has to stay legible in basic
+  mode through its normal surfaces (a live schedule still badges its task card and opens its
+  inspector panel; an initiative is still a block on the board with its own inspector), or the
+  tier turns into a way for a user to be acted on by configuration they cannot find.
 - **An override control on an EXISTING entity gates on `showOverrideField(isAdvanced, …values)`**
   (`app/utils/uiMode.ts`) rather than on `isAdvanced` alone. Hiding an override is only safe
   while it is unset — always true for a creation form, never guaranteed for a block that a

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

@@ -24,6 +24,7 @@ const agentRuns = useAgentRunsStore()
 const services = useServicesStore()
 const reviews = useReviewStage()
 const access = useWorkspaceAccess()
+const uiMode = useUiModeStore()
 const { t } = useI18n()
 const { lod } = useSemanticZoom()
 // Coarse-pointer (touch) bumps the frame-header actions from `xs` to `sm` so
@@ -161,6 +162,13 @@ function addRecurring() {
   ui.openAddRecurring(props.id)
 }
 
+// Hunt this service's tracker board for a bug worth picking up. Scoped to THIS frame, so
+// an adopted candidate lands here rather than wherever the board's first frame happens to be.
+function huntBugs() {
+  ui.expandFrame(props.id)
+  ui.openBugHunt(null, props.id)
+}
+
 function createInitiative() {
   ui.expandFrame(props.id)
   ui.openCreateInitiative(props.id)
@@ -491,8 +499,18 @@ const ITEM_ICON: Record<string, string> = {
                   :title="t('board.frame.createTaskFromIssueTitle')"
                   @click.stop="createTaskFromIssue"
                 />
+                <!-- Recurring pipelines + initiatives are ADVANCED-tier authoring: both plan
+                     work rather than do it (a schedule that fires runs on a cadence, an
+                     initiative that groups tasks under a goal), and the basic frame header is
+                     the most-used control strip on the board. Hiding the CREATE affordance
+                     removes neither's existing state from basic mode — a live schedule still
+                     badges its task card and opens its inspector panel, and an initiative is
+                     still a block on the board with its own inspector — so what a basic-mode
+                     user loses is the ability to author a new one, not sight of one. -->
                 <UButton
+                  v-if="uiMode.isAdvanced"
                   class="nodrag"
+                  data-testid="frame-add-recurring"
                   :size="isTouch ? 'sm' : 'xs'"
                   variant="ghost"
                   color="neutral"
@@ -501,6 +519,7 @@ const ITEM_ICON: Record<string, string> = {
                   @click.stop="addRecurring"
                 />
                 <UButton
+                  v-if="uiMode.isAdvanced"
                   class="nodrag"
                   data-testid="frame-add-initiative"
                   :size="isTouch ? 'sm' : 'xs'"
@@ -510,6 +529,17 @@ const ITEM_ICON: Record<string, string> = {
                   :title="t('board.frame.createInitiativeTitle')"
                   @click.stop="createInitiative"
                 />
+                <UButton
+                  v-if="tasks.anyOffered"
+                  class="nodrag"
+                  data-testid="frame-hunt-bugs"
+                  :size="isTouch ? 'sm' : 'xs'"
+                  variant="ghost"
+                  color="neutral"
+                  icon="i-lucide-radar"
+                  :title="t('board.frame.huntBugsTitle')"
+                  @click.stop="huntBugs"
+                />
               </template>
               <UButton
                 class="nodrag"

package/app/components/focus/BlockFocusView.vue

@@ -5,6 +5,7 @@ import { blockTypeMeta, STATUS_META } from '~/utils/catalog'
 import { pipelineAllowedForManualStart } from '~/utils/pipeline'
 import PipelineProgress from '~/components/pipeline/PipelineProgress.vue'
 import IconButton from '~/components/common/IconButton.vue'
+import { useInitiativePlanning } from '~/composables/useInitiativePlanning'
 
 const board = useBoardStore()
 const pipelines = usePipelinesStore()
@@ -44,6 +45,20 @@ function runPipeline(id: string) {
   if (pipeline && block.value) void execution.start(block.value.id, pipeline)
 }
 
+/**
+ * An initiative block accepts exactly ONE pipeline — its preset's planning pipeline — and the
+ * engine refuses every other, so it gets the same single "Run planning" control the board card and
+ * the inspector offer rather than a picker whose every other row would be rejected on click. Same
+ * composable as those two surfaces, so which pipeline it starts can't drift across the three.
+ */
+const isInitiative = computed(() => block.value?.level === 'initiative')
+const {
+  planningPipeline,
+  running: planningRunning,
+  starting: planningStarting,
+  runPlanning,
+} = useInitiativePlanning(() => block.value?.id ?? '')
+
 function close() {
   ui.focus(null)
 }
@@ -99,9 +114,28 @@ function openApprovalFor(approvalId: string) {
         {{ statusMeta.label }}
       </UBadge>
       <div class="ms-auto flex items-center gap-2">
+        <!-- An initiative has one legal pipeline, so it gets the button, not the picker. -->
+        <UButton
+          v-if="isInitiative"
+          color="primary"
+          variant="soft"
+          size="sm"
+          icon="i-lucide-play"
+          :loading="planningStarting || planningRunning"
+          :disabled="!planningPipeline || planningRunning || planningStarting"
+          data-testid="focus-run-planning"
+          @click="runPlanning"
+        >
+          {{ t('initiative.inspector.runPlanning') }}
+        </UButton>
         <!-- The rich picker rather than a list of names: the run starts the moment a row is
              clicked, so the preview is the only chance to see which agents it will run. -->
-        <PipelinePicker model-value="" :options="runOptions" @update:model-value="runPipeline">
+        <PipelinePicker
+          v-else
+          model-value=""
+          :options="runOptions"
+          @update:model-value="runPipeline"
+        >
           <template #trigger>
             <UButton
               color="primary"

package/app/components/initiative/InitiativePlanningWindow.vue

@@ -127,6 +127,25 @@ async function flushThen(action: (id: string) => Promise<unknown>) {
 
 const onContinue = () => flushThen((id) => initiatives.continuePlanning(id))
 const onProceed = () => flushThen((id) => initiatives.proceedPlanning(id))
+
+/**
+ * The escape hatch for a planning run that stalled. It belongs HERE, not only in the inspector's
+ * execution panel behind this window: submit and plan-now are the two things that wedge, so the
+ * human who needs a way out is looking at exactly this footer. Offered whenever a run still owns
+ * the block — including mid-pass and after a failed pass, which is where a wedge actually shows up
+ * and where neither of the other two buttons is even rendered.
+ *
+ * Discarding returns the block to `planned`, which re-enables "Run planning"; the interviewer gate
+ * drops the previous run's round bookkeeping on that fresh start, so the re-run genuinely
+ * re-interviews instead of force-converging on its first pass. Close on success — leaving the
+ * window open on the now-empty idle state would read as another dead end.
+ */
+const { resetting, resetRun } = useRunReset()
+const canDiscard = computed(() => !!block.value?.executionId)
+async function onDiscard() {
+  if (!blockId.value) return
+  if (await resetRun(blockId.value)) close()
+}
 </script>
 
 <template>
@@ -221,28 +240,51 @@ const onProceed = () => flushThen((id) => initiatives.proceedPlanning(id))
       </template>
     </div>
 
-    <!-- Action rail. Only while the run is actually parked on the human: mid-pass these would
-         re-submit a question set already in flight, and the resume is a no-op once it isn't. -->
+    <!-- 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. -->
     <footer
-      v-if="initiative && phase === 'awaiting' && questions.length > 0"
+      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"
     >
-      <p class="text-[11px] text-slate-500">
-        <span
-          v-if="unanswered > 0"
-          class="text-amber-400/90"
-          data-testid="initiative-planning-unanswered"
-        >
-          {{ t('initiative.planning.unanswered', { count: unanswered }) }}
-        </span>
-        <span v-else>{{ t('initiative.planning.hint') }}</span>
-      </p>
-      <div class="flex items-center gap-2">
+      <UButton
+        v-if="canDiscard"
+        color="error"
+        variant="ghost"
+        size="sm"
+        icon="i-lucide-trash-2"
+        :loading="resetting"
+        :disabled="resuming"
+        :title="t('initiative.planning.discardTitle')"
+        data-testid="initiative-planning-discard"
+        @click="onDiscard"
+      >
+        {{ t('initiative.planning.discard') }}
+      </UButton>
+      <!-- `ms-auto` rather than relying on `justify-between`: discard is conditional, and without
+           it this group left-aligns on the (transient) render where it is the only child. -->
+      <div
+        v-if="phase === 'awaiting' && questions.length > 0"
+        class="ms-auto flex items-center gap-2"
+      >
+        <p class="text-[11px] text-slate-500">
+          <span
+            v-if="unanswered > 0"
+            class="text-amber-400/90"
+            data-testid="initiative-planning-unanswered"
+          >
+            {{ t('initiative.planning.unanswered', { count: unanswered }) }}
+          </span>
+          <span v-else>{{ t('initiative.planning.hint') }}</span>
+        </p>
         <UButton
           color="neutral"
           variant="ghost"
           size="sm"
           :loading="resuming"
+          :disabled="resetting"
           :title="t('initiative.planning.proceedTitle')"
           data-testid="initiative-planning-proceed"
           @click="onProceed"
@@ -253,7 +295,7 @@ const onProceed = () => flushThen((id) => initiatives.proceedPlanning(id))
           color="primary"
           size="sm"
           :loading="resuming"
-          :disabled="unanswered > 0"
+          :disabled="unanswered > 0 || resetting"
           :title="
             unanswered > 0
               ? t('initiative.planning.unanswered', { count: unanswered })

package/app/components/layout/IntegrationsHub.vue

@@ -1,4 +1,6 @@
 <script setup lang="ts">
+import { showOverrideField } from '~/utils/uiMode'
+
 // The Integrations hub: a single modal that lists every external system the WORKSPACE can
 // enable or link in. Each row reuses the existing per-integration panel handlers on the `ui`
 // store (so the integrations themselves are unchanged); opening one closes the hub and
@@ -25,6 +27,7 @@ const publicApiKeys = usePublicApiKeysStore()
 const userSecrets = useUserSecretsStore()
 const apiKeys = useApiKeysStore()
 const workspace = useWorkspaceStore()
+const uiMode = useUiModeStore()
 
 // True when the per-user "My setup" hub is reachable (UserMenu renders only when signed in).
 // When false (auth disabled / local mode) we fold the personal rows back into this hub so
@@ -268,7 +271,17 @@ const groups = computed<IntegrationGroup[]>(() => {
   // Gated like every other backend-toggleable system: hidden until a probe confirms
   // the observability module is enabled (`available === true`), so a disabled backend
   // doesn't show a dead "Connect" row that only 503s.
-  if (releaseHealth.available) {
+  //
+  // Also an ADVANCED-tier row. Post-release health is the one integration here that acts
+  // AFTER delivery rather than during it — it watches monitors once a release ships and can
+  // spawn an on-call agent — so it sits outside the everyday loop the basic tier serves.
+  // Gated with `showOverrideField` rather than a bare `isAdvanced`: an already-connected
+  // Datadog is live behaviour on this workspace, and a tier must never conceal a connection a
+  // basic-mode user would then have no way to inspect or disconnect.
+  if (
+    releaseHealth.available &&
+    showOverrideField(uiMode.isAdvanced, releaseHealth.connection.connected || null)
+  ) {
     out.push({
       title: t('layout.integrationsHub.groups.observability'),
       items: [

package/app/components/panels/InspectorPanel.vue

@@ -13,7 +13,6 @@ const pipelines = usePipelinesStore()
 const execution = useExecutionStore()
 const ui = useUiStore()
 const documents = useDocumentsStore()
-const tasks = useTasksStore()
 const fragments = useFragmentsStore()
 const agentRuns = useAgentRunsStore()
 const github = useGitHubStore()
@@ -60,6 +59,14 @@ watch(
 )
 const isContainer = computed(() => level.value === 'frame' || level.value === 'module')
 const isTask = computed(() => level.value === 'task')
+const isInitiative = computed(() => level.value === 'initiative')
+/**
+ * Blocks whose inspector carries a pipeline RUN — a task, and an initiative (whose planning
+ * pipeline is an ordinary run of ordinary agent steps). Both get the execution panel and the
+ * Focus view; what differs is only how the run is STARTED (a task picks any pipeline, an
+ * initiative may only run its planning one, so it keeps its own "Run planning" control).
+ */
+const hasRuns = computed(() => isTask.value || isInitiative.value)
 
 const instance = computed(() => execution.getInstance(block.value?.executionId))
 const typeMeta = computed(() => (block.value ? blockTypeMeta(block.value.type) : null))
@@ -104,7 +111,10 @@ const runBlockedReason = computed(() => {
 const canRun = computed(() => runnable.value && access.canExecuteRuns.value)
 
 // The delete control names what it removes, so selecting a task and deleting it
-// reads as "Delete task" rather than ambiguously removing the whole service.
+// reads as "Delete task" rather than ambiguously removing the whole service. An
+// initiative is its own level (it hangs off a frame like a module does), so it must
+// name ITSELF — offering to "delete service" there describes the wrong blast radius
+// entirely: the frame and every other thing under it survive.
 const deleteLabel = computed(() =>
   schedule.value
     ? t('panels.inspector.deleteRecurringPipeline')
@@ -112,7 +122,9 @@ const deleteLabel = computed(() =>
       ? t('panels.inspector.deleteTask')
       : level.value === 'module'
         ? t('panels.inspector.deleteModule')
-        : t('panels.inspector.deleteService'),
+        : isInitiative.value
+          ? t('panels.inspector.deleteInitiative')
+          : t('panels.inspector.deleteService'),
 )
 
 // A task is "started" once a pipeline has been launched on it (it has an
@@ -437,33 +449,9 @@ const showOriginalDescription = ref(false)
         >
           {{ block!.pullRequest!.branch }}
         </UButton>
-        <UButton
-          v-if="tasks.available"
-          color="neutral"
-          variant="soft"
-          size="xs"
-          icon="i-lucide-ticket"
-          @click="ui.openTaskImport()"
-        >
-          {{
-            tasks.anyOffered
-              ? t('panels.inspector.importIssue')
-              : t('panels.inspector.connectTracker')
-          }}
-        </UButton>
-        <!-- Hunt this service's tracker board for a bug worth picking up. Scoped to the
-             selected container, so an adopted candidate lands here rather than wherever the
-             board's first frame happens to be. -->
-        <UButton
-          v-if="isContainer && tasks.anyOffered"
-          color="neutral"
-          variant="soft"
-          size="xs"
-          icon="i-lucide-radar"
-          @click="ui.openBugHunt(null, block!.id)"
-        >
-          {{ t('panels.inspector.huntBugs') }}
-        </UButton>
+        <!-- Tracker entry points (import an issue, hunt bugs) live on the service frame's
+             header, where they are already scoped to a frame — the inspector doesn't
+             duplicate them. -->
         <UButton
           v-if="isContainer && documents.available && documents.anyConnected"
           color="neutral"
@@ -543,11 +531,12 @@ const showOriginalDescription = ref(false)
           </UButton>
         </UDropdownMenu>
         <UButton
-          v-if="isTask"
+          v-if="hasRuns"
           color="neutral"
           variant="soft"
           size="sm"
           icon="i-lucide-maximize-2"
+          data-testid="inspector-focus"
           @click="ui.focus(block.id)"
         >
           {{ t('panels.inspector.focus') }}

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

@@ -22,72 +22,64 @@ function addTask() {
 </script>
 
 <template>
+  <!-- Modules and tasks are two peer collapsible lists, not one "Contents" group: the
+       grouping added a level of nesting without adding information, and a service's task
+       list is long enough to want collapsing independently of its modules. -->
   <InspectorSection
-    :title="t('inspector.container.title')"
-    :hint="t('inspector.container.hint')"
-    :count="tasks.length"
+    v-if="modules.length"
+    :title="t('inspector.container.modulesTitle')"
+    :hint="t('inspector.container.modulesHint')"
+    :count="modules.length"
     default-open
   >
-    <!-- modules (services only) -->
-    <div v-if="modules.length">
-      <div class="mb-1 text-[11px] font-semibold uppercase tracking-wide text-slate-400">
-        {{ t('inspector.container.modules', { count: modules.length }) }}
-      </div>
-      <ul class="space-y-1">
-        <li
-          v-for="m in modules"
-          :key="m.id"
-          class="flex cursor-pointer items-center gap-2 rounded-md px-2 py-1 hover:bg-slate-800/60"
-          @click="ui.select(m.id)"
-        >
-          <UIcon name="i-lucide-package" class="h-3.5 w-3.5 text-violet-400" />
-          <span class="truncate text-xs text-slate-200">{{ m.title }}</span>
-          <span class="ms-auto text-[10px] text-slate-500">{{
-            t(
-              'inspector.container.taskCount',
-              { count: board.tasksOf(m.id).length },
-              board.tasksOf(m.id).length,
-            )
-          }}</span>
-        </li>
-      </ul>
-    </div>
+    <ul class="space-y-1">
+      <li
+        v-for="m in modules"
+        :key="m.id"
+        class="flex cursor-pointer items-center gap-2 rounded-md px-2 py-1 hover:bg-slate-800/60"
+        @click="ui.select(m.id)"
+      >
+        <UIcon name="i-lucide-package" class="h-3.5 w-3.5 text-violet-400" />
+        <span class="truncate text-xs text-slate-200">{{ m.title }}</span>
+        <span class="ms-auto text-[10px] text-slate-500">{{
+          t(
+            'inspector.container.taskCount',
+            { count: board.tasksOf(m.id).length },
+            board.tasksOf(m.id).length,
+          )
+        }}</span>
+      </li>
+    </ul>
+  </InspectorSection>
 
-    <div>
-      <div class="mb-1 flex items-center justify-between">
-        <span class="text-[11px] font-semibold uppercase tracking-wide text-slate-400">
-          {{
-            isFrame
-              ? t('inspector.container.allTasks', { count: tasks.length })
-              : t('inspector.container.tasks', { count: tasks.length })
-          }}
-        </span>
-        <div class="flex items-center gap-1.5">
-          <ReviewDebtBadge />
-          <UButton size="xs" variant="soft" color="primary" icon="i-lucide-plus" @click="addTask">
-            {{ t('inspector.container.addTask') }}
-          </UButton>
-        </div>
-      </div>
-      <ul v-if="tasks.length" class="space-y-1">
-        <li
-          v-for="task in tasks"
-          :key="task.id"
-          class="flex cursor-pointer items-center gap-2 rounded-md px-2 py-1 hover:bg-slate-800/60"
-          @click="ui.select(task.id)"
-        >
-          <span
-            class="h-2 w-2 shrink-0 rounded-full"
-            :style="{ backgroundColor: STATUS_META[task.status].color }"
-          />
-          <span class="truncate text-xs text-slate-200">{{ task.title }}</span>
-          <span class="ms-auto text-[10px] text-slate-500">{{
-            STATUS_META[task.status].label
-          }}</span>
-        </li>
-      </ul>
-      <div v-else class="text-[11px] text-slate-500">{{ t('inspector.container.noTasks') }}</div>
-    </div>
+  <InspectorSection
+    :title="isFrame ? t('inspector.container.allTasksTitle') : t('inspector.container.tasksTitle')"
+    :hint="t('inspector.container.tasksHint')"
+    :count="tasks.length"
+    default-open
+  >
+    <template #actions>
+      <ReviewDebtBadge />
+      <UButton size="xs" variant="soft" color="primary" icon="i-lucide-plus" @click="addTask">
+        {{ t('inspector.container.addTask') }}
+      </UButton>
+    </template>
+    <ul v-if="tasks.length" class="space-y-1">
+      <li
+        v-for="task in tasks"
+        :key="task.id"
+        class="flex cursor-pointer items-center gap-2 rounded-md px-2 py-1 hover:bg-slate-800/60"
+        @click="ui.select(task.id)"
+      >
+        <span
+          class="h-2 w-2 shrink-0 rounded-full"
+          :style="{ backgroundColor: STATUS_META[task.status].color }"
+        />
+        <span class="truncate text-xs text-slate-200">{{ task.title }}</span>
+        <span class="ms-auto text-[10px] text-slate-500">{{ STATUS_META[task.status].label }}</span>
+      </li>
+    </ul>
+    <div v-else class="text-[11px] text-slate-500">{{ t('inspector.container.noTasks') }}</div>
     <p v-if="isFrame" class="text-[11px] text-slate-500">
       {{ t('inspector.container.servicesHint') }}
     </p>

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

@@ -2,6 +2,7 @@
 import { computed, reactive, ref, watch } from 'vue'
 import type { Block } from '~/types/domain'
 import InspectorSection from '~/components/panels/inspector/InspectorSection.vue'
+import { showOverrideField } from '~/utils/uiMode'
 
 // Per-service (frame) post-release-health mapping: which observability monitors/SLOs the
 // `post-release-health` gate watches after this service's PRs ship. Keyed by THIS block's
@@ -11,6 +12,7 @@ const props = defineProps<{ block: Block }>()
 
 const store = useReleaseHealthStore()
 const ui = useUiStore()
+const uiMode = useUiModeStore()
 const toast = useToast()
 const { t } = useI18n()
 const { confirmAction, toastDone } = useConfirmAction()
@@ -21,6 +23,14 @@ const draft = reactive({ monitorIds: '', sloIds: '', envTag: '' })
 const connected = computed(() => store.connection.connected)
 const saved = computed(() => store.configForBlock(props.block.id))
 
+// Post-release health is an ADVANCED-tier concern: with no mapping the gate is a pass-through,
+// so basic mode hides the whole section rather than showing a service-level knob whose absence
+// changes nothing. `showOverrideField` (not a bare `isAdvanced`) because the mapping is per
+// SERVICE and durable — once a teammate on the advanced tier maps monitors onto this frame,
+// hiding the panel would leave a basic-mode user with releases being watched (and an on-call
+// agent that can spawn) by a configuration they can neither see nor clear.
+const show = computed(() => showOverrideField(uiMode.isAdvanced, saved.value))
+
 function parseIds(csv: string): string[] {
   return csv
     .split(',')
@@ -91,6 +101,7 @@ async function clear() {
 
 <template>
   <InspectorSection
+    v-if="show"
     :title="t('inspector.releaseHealth.title')"
     :hint="t('inspector.releaseHealth.sectionHint')"
   >

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

@@ -192,26 +192,11 @@ async function stopRun() {
     stopping.value = false
   }
 }
-const resetting = ref(false)
-async function resetRun() {
-  if (resetting.value) return
-  // Destructive: discards the run and returns the task to planned — gate it behind a confirm,
-  // matching the confirm-then-mutate contract the board delete path uses.
-  const ok = await confirm({
-    title: t('inspector.execution.resetConfirm.title'),
-    description: t('inspector.execution.resetConfirm.body'),
-    variant: 'destructive',
-    confirmLabel: t('inspector.execution.resetConfirm.confirm'),
-    icon: 'i-lucide-trash-2',
-  })
-  if (!ok) return
-  resetting.value = true
-  try {
-    await execution.cancel(props.block.id)
-  } finally {
-    resetting.value = false
-  }
-}
+// Destructive: discards the run and returns the block to planned, behind a confirm. Shared with
+// the initiative planning window (which offers the same escape hatch in place) so the two can't
+// drift on the prompt or on what "discard" means.
+const { resetting, resetRun: discardRun } = useRunReset()
+const resetRun = () => discardRun(props.block.id)
 
 /**
  * The reviewer-effort tag for this merge, preselected from evidence rather than starting blank: if

package/app/composables/useBlockDeletion.ts

@@ -76,7 +76,14 @@ export function useBlockDeletion() {
         ? 'task'
         : block.level === 'module'
           ? 'module'
-          : 'service'
+          : // An initiative names itself rather than falling through to the service copy, which
+            // would describe a blast radius orders of magnitude larger than the real one. Its
+            // cascade is also genuinely different from a container's: the plan goes with it, but
+            // the tasks its loop already spawned are NOT descendants — the backend only detaches
+            // their membership link — so the count branch below deliberately doesn't apply.
+            block.level === 'initiative'
+            ? 'initiative'
+            : 'service'
     const title = t(`panels.inspector.confirmDelete.${kind}.title`)
     // For a container (service/module) state the exact cascade size so the blast radius is
     // explicit — "and everything inside it" hides how many tasks/modules go with it.