@cat-factory/app 0.147.7 → 0.149.0

package/app/components/panels/StepFragmentAdherence.vue

@@ -0,0 +1,85 @@
+<script setup lang="ts">
+// A code/PR review step's best-practice adherence report, surfaced in run details: for each
+// best-practice standard (prompt fragment) folded into the reviewer's prompt, how well the reviewed
+// change adheres (1..10) and the issues that standard surfaced. Recorded on the step
+// (`step.fragmentAdherence`) by the engine from the review agent's output. Rendered only when the
+// reviewer reported at least one standard; when none were reachable the reviewer says so in its
+// summary instead (so there is nothing to show here).
+import type { FragmentAdherence } from '~/types/execution'
+
+const props = defineProps<{ items: FragmentAdherence }>()
+const { t } = useI18n()
+
+/** Rating band → bar colour: poor adherence (rose) → partial (amber) → strong (emerald). */
+function ratingClass(rating: number): string {
+  return rating >= 8 ? 'bg-emerald-400' : rating >= 5 ? 'bg-amber-400' : 'bg-rose-400'
+}
+function ratingPct(rating: number): number {
+  return Math.min(100, Math.max(0, (rating / 10) * 100))
+}
+/** The label the reviewer was asked to cite the standard by: its title, else its id. */
+function label(item: FragmentAdherence[number]): string {
+  return item.title?.trim() || item.fragmentId || t('panels.stepDetail.adherence.unnamed')
+}
+</script>
+
+<template>
+  <section
+    v-if="items.length"
+    data-testid="step-fragment-adherence"
+    class="scroll-mt-4 rounded-xl border border-slate-800 bg-slate-900/50 p-4"
+  >
+    <div
+      class="mb-2 flex items-center gap-1.5 text-[11px] font-semibold uppercase tracking-wide text-slate-400"
+    >
+      <UIcon name="i-lucide-clipboard-check" class="h-3.5 w-3.5" />
+      <span>{{ t('panels.stepDetail.adherence.heading') }}</span>
+    </div>
+
+    <div class="space-y-2.5">
+      <article
+        v-for="(item, i) in items"
+        :key="item.fragmentId ?? i"
+        data-testid="step-fragment-adherence-item"
+        class="rounded-lg border border-slate-800 bg-slate-900/60 px-3 py-2"
+      >
+        <div class="flex items-center gap-2">
+          <span class="min-w-0 flex-1 truncate text-[13px] font-medium text-slate-100">{{
+            label(item)
+          }}</span>
+          <div class="h-1.5 w-16 shrink-0 overflow-hidden rounded-full bg-slate-700/60">
+            <div
+              class="h-full rounded-full"
+              :class="ratingClass(item.rating)"
+              :style="{ width: `${ratingPct(item.rating)}%` }"
+            />
+          </div>
+          <span class="shrink-0 text-[12px] font-medium text-slate-200">
+            {{ t('panels.stepDetail.adherence.outOfTen', { value: item.rating }) }}
+          </span>
+        </div>
+        <p
+          v-if="item.assessment"
+          class="mt-1 whitespace-pre-wrap text-[12px] leading-relaxed text-slate-300"
+        >
+          {{ item.assessment }}
+        </p>
+        <div v-if="item.relatedFindings.length" class="mt-1.5">
+          <p class="text-[10px] font-semibold uppercase tracking-wide text-slate-500">
+            {{ t('panels.stepDetail.adherence.relatedFindings') }}
+          </p>
+          <ul class="mt-0.5 space-y-0.5">
+            <li
+              v-for="(finding, fi) in item.relatedFindings"
+              :key="fi"
+              class="flex items-start gap-1.5 text-[11px] text-slate-400"
+            >
+              <UIcon name="i-lucide-dot" class="mt-0.5 h-3.5 w-3.5 shrink-0" />
+              <span>{{ finding }}</span>
+            </li>
+          </ul>
+        </div>
+      </article>
+    </div>
+  </section>
+</template>

package/app/components/prReview/PrReviewWindow.vue

@@ -466,6 +466,14 @@ async function onDismiss(id: string): Promise<void> {
             {{ state.summary }}
           </p>
 
+          <!-- Best-practice adherence: per standard folded into the reviewer's prompt, a 1..10
+               rating of how well the PR adheres + the issues that standard surfaced. -->
+          <StepFragmentAdherence
+            v-if="step?.fragmentAdherence?.length"
+            :items="step.fragmentAdherence"
+            class="mb-3"
+          />
+
           <!-- A clean PR / resolved review with no findings. -->
           <div
             v-if="findings.length === 0"

package/app/components/settings/WorkspaceSettingsPanel.vue

@@ -8,7 +8,7 @@
 // The latter three are body-only section components rendered in tabs here (no longer
 // standalone modals).
 import { reactive, ref, watch } from 'vue'
-import type { CreateTaskType, TaskLimitMode } from '~/types/domain'
+import type { TaskLimitMode } from '~/types/domain'
 import RiskPolicyPanel from '~/components/settings/RiskPolicyPanel.vue'
 import IssueTrackerPanel from '~/components/settings/IssueTrackerPanel.vue'
 import ServiceFragmentDefaultsPanel from '~/components/settings/ServiceFragmentDefaultsPanel.vue'
@@ -103,12 +103,18 @@ const tabsUi = {
   indicator: 'hidden',
 }
 
-const TASK_TYPES: CreateTaskType[] = ['feature', 'bug', 'document', 'spike']
+// The finite BUILT-IN create-task types this per-type running-task-limit UI configures.
+// `CreateTaskType` widened to an open `string` (to admit consumer-registered CUSTOM task types),
+// so the config surface pins the built-in set it renders inputs for — a custom type buckets on its
+// own id server-side (`RunAdmission`) and is not configured here. Keying the records below off this
+// finite union (not the open `CreateTaskType`) keeps them exhaustive + undefined-free.
+type LimitTaskType = 'feature' | 'bug' | 'document' | 'spike' | 'review' | 'ralph'
+const TASK_TYPES: LimitTaskType[] = ['feature', 'bug', 'document', 'spike']
 
 // Per-task-type label for the "Max {type} tasks" inputs. An exhaustive Record keyed off
-// the CreateTaskType union (a missing member fails the typecheck); each value is a LITERAL
-// catalog key so the typed-message-keys check sees it. Leaf keys mirror the enum verbatim.
-const TASK_TYPE_KEYS: Record<CreateTaskType, string> = {
+// the finite {@link LimitTaskType} union (a missing member fails the typecheck); each value is a
+// LITERAL catalog key so the typed-message-keys check sees it. Leaf keys mirror the enum verbatim.
+const TASK_TYPE_KEYS: Record<LimitTaskType, string> = {
   feature: 'settings.workspaceSettings.taskTypes.feature',
   bug: 'settings.workspaceSettings.taskTypes.bug',
   document: 'settings.workspaceSettings.taskTypes.document',
@@ -124,7 +130,7 @@ const MODES = computed<{ value: TaskLimitMode; label: string }[]>(() => [
 ])
 
 /** The localized "Max {type} tasks" label for a per-type running-task limit input. */
-function maxTaskTypeLabel(type: CreateTaskType): string {
+function maxTaskTypeLabel(type: LimitTaskType): string {
   const key = TASK_TYPE_KEYS[type]
   const typeLabel = te(key) ? t(key) : type
   return t('settings.workspaceSettings.taskLimit.maxPerType', { type: typeLabel })
@@ -135,7 +141,7 @@ const draft = reactive({
   waitingEscalationMinutes: 120,
   taskLimitMode: 'off' as TaskLimitMode,
   taskLimitShared: 5 as number,
-  perType: {} as Record<CreateTaskType, number>,
+  perType: {} as Record<LimitTaskType, number>,
   storeAgentContext: true,
   artifactRetentionDays: 14,
   kaizenEnabled: true,
@@ -173,7 +179,7 @@ async function save() {
                 acc[t] = draft.perType[t]
                 return acc
               },
-              {} as Record<CreateTaskType, number>,
+              {} as Record<LimitTaskType, number>,
             )
           : null,
       storeAgentContext: draft.storeAgentContext,

package/app/composables/api/fragments.ts

@@ -3,6 +3,7 @@ import {
   createPromptFragmentContract,
   deletePromptFragmentContract,
   fragmentSourceStatusContract,
+  generatePromptFragmentTitleContract,
   linkFragmentSourceContract,
   listFragmentCatalogContract,
   listFragmentSourcesContract,
@@ -17,6 +18,7 @@ import type {
   CreateDocumentFragmentInput,
   CreatePromptFragmentInput,
   FragmentOwnerKind,
+  GenerateFragmentTitleInput,
   LinkFragmentSourceInput,
   UpdatePromptFragmentInput,
 } from '~/types/domain'
@@ -58,6 +60,21 @@ export function fragmentsApi({ send, ws, scope }: ApiContext) {
         pathParams: { fragmentId },
       }),
 
+    // Auto-generate a title for a hand-authored fragment from its content (an inline LLM call).
+    // At the account scope the backend resolves the model against `viaWorkspaceId`'s scope;
+    // ignored at the workspace scope (which uses the addressed workspace).
+    generateFragmentTitle: (
+      kind: FragmentOwnerKind,
+      id: string,
+      body: GenerateFragmentTitleInput,
+      viaWorkspaceId?: string,
+    ) =>
+      send(generatePromptFragmentTitleContract, {
+        pathPrefix: scope(kind, id),
+        queryParams: { viaWorkspaceId },
+        body,
+      }),
+
     // Link an external document (Confluence/Notion/GitHub) as a living fragment.
     createDocumentFragment: (
       kind: FragmentOwnerKind,

package/app/docs/consumer-extensions.md

@@ -62,14 +62,15 @@ export default defineNuxtPlugin(() => {
 
 ## The landed seams
 
-| Seam                                | Slot key          | Entry shape                                                                                      | Host                                        |
-| ----------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------- |
-| Run-detail windows                  | `resultViews`     | `{ id: '<ns>:<name>', component }`                                                               | `StepResultViewHost` via `dispatchStepView` |
-| Agent kinds (palette data)          | `agentKinds`      | `{ kind, container, presentation: { label, icon, color, description, category?, resultView? } }` | agents store merge → `agentKindMeta`        |
-| Sidebar / command-palette / toolbar | `nav`             | `{ id, labelKey, icon, surfaces, gate?, run, sidebar?, command?, toolbar? }`                     | the three shells via `useNavContributions`  |
-| Inspector body panels               | `inspectorPanels` | `{ id, component, when(block), order }` (`PanelEntry<Block>`)                                    | `<PanelsOutlet>` in `InspectorPanel`        |
-| Multi-step wizards                  | (journeys)        | `registerJourney` + step modules                                                                 | `<JourneyHost>` / `<JourneyOutlet>`         |
-| Locale strings                      | (i18n)            | `i18n/locales/*.json` in the deployment                                                          | `@nuxtjs/i18n` layer deep-merge             |
+| Seam                                | Slot key          | Entry shape                                                                                      | Host                                                                 |
+| ----------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------- |
+| Run-detail windows                  | `resultViews`     | `{ id: '<ns>:<name>', component }`                                                               | `StepResultViewHost` via `dispatchStepView`                          |
+| Agent kinds (palette data)          | `agentKinds`      | `{ kind, container, presentation: { label, icon, color, description, category?, resultView? } }` | agents store merge → `agentKindMeta`                                 |
+| Custom task types                   | `taskTypes`       | `{ taskType: '<ns>:<name>', presentation, fields?, defaultPipelineId?, formPanel? }`             | `AddTaskModal` picker/fields + `TaskCard` badge (via `taskTypeMeta`) |
+| Sidebar / command-palette / toolbar | `nav`             | `{ id, labelKey, icon, surfaces, gate?, run, sidebar?, command?, toolbar? }`                     | the three shells via `useNavContributions`                           |
+| Inspector body panels               | `inspectorPanels` | `{ id, component, when(block), order }` (`PanelEntry<Block>`)                                    | `<PanelsOutlet>` in `InspectorPanel`                                 |
+| Multi-step wizards                  | (journeys)        | `registerJourney` + step modules                                                                 | `<JourneyHost>` / `<JourneyOutlet>`                                  |
+| Locale strings                      | (i18n)            | `i18n/locales/*.json` in the deployment                                                          | `@nuxtjs/i18n` layer deep-merge                                      |
 
 ### Run-detail windows (`resultViews` + `agentKinds`)
 
@@ -102,6 +103,38 @@ show the panel, and `order` places it among the built-ins. Your panel component
 selected block via `usePanelSubject<Block>()` (`@modular-vue/core`). `when` must tolerate a
 nullish subject (the boot-time validation resolve passes `null`).
 
+### Custom task types (`taskTypes`)
+
+Model a proprietary work item — an "incident", "pentest", "compliance-audit" — as a first-class
+task type, the create-task twin of an agent kind. Contribute `{ taskType: '<ns>:<name>',
+presentation: { label, icon, color, description }, fields?, defaultPipelineId?, formPanel? }` to
+the `taskTypes` slot (see `acme:incident` in the example module). The SPA merges it into the
+create-task picker and the card-badge catalog:
+
+- **`presentation`** drives the create-task picker entry and the `TaskCard` type badge (resolved
+  through the pure `taskTypeMeta` read-model — the `agentKindMeta` twin). An UNREGISTERED
+  namespaced type (a stale row after your extension is removed) degrades to the `feature`
+  presentation, so a leftover string never breaks a card.
+- **`fields`** are descriptor-driven create-form inputs (`text` / `textarea` / `number` /
+  `select`); their values land in the task's sparse `taskTypeFields.custom` bag (no migration).
+- **`formPanel`** optionally names a bespoke create-form section component you contribute to the
+  `taskTypeFormPanels` slot (paired by that id, like `resultViews`); shown INSTEAD of `fields`. An
+  unpaired id degrades to the descriptor fields.
+- **`defaultPipelineId`** pre-selects the type's pipeline in the picker.
+
+The **same type can be delivered from the backend** instead of code-shipped: register it on the
+deployment's app-owned `TaskTypeRegistry` and it arrives in the workspace snapshot's
+`customTaskTypes`, folded into the SAME merged catalog (data over the wire, never components). The
+widened `taskType` contract (`<built-in> | <ns>:<name>`) accepts the namespaced id everywhere, so a
+task created with it round-trips with zero host edits.
+
+> **Validation.** A BACKEND-registered task type is checked at boot by `validateRegistrations`
+> (namespaced id, well-formed `formPanel`, a `defaultPipelineId` that resolves to a real pipeline).
+> A CODE-shipped `taskTypes` entry is trusted and **not** validated (like a code-shipped agent kind):
+> a malformed `taskType`/`formPanel` id or a `defaultPipelineId` naming no real pipeline fails
+> silently — the type just won't pre-select a pipeline and an unpaired `formPanel` degrades to the
+> descriptor `fields`. Prefer backend registration when you want the fail-fast guardrail.
+
 ## Reuse the shared building blocks — don't reinvent them
 
 The layer ships window/inspector primitives you compose instead of hand-rolling chrome or

package/app/modular/agent-kinds.spec.ts

@@ -1,10 +1,5 @@
 import { describe, expect, it } from 'vitest'
-import {
-  buildAgentCapabilitiesManifest,
-  capabilitiesManifestVersion,
-  customKindToArchetype,
-  WORKSPACE_CAPABILITIES_MANIFEST_ID,
-} from './agent-kinds'
+import { customKindToArchetype } from './agent-kinds'
 import type { AgentKind, CustomAgentKind } from '~/types/domain'
 
 const kind = (
@@ -22,39 +17,6 @@ const kind = (
   },
 })
 
-describe('buildAgentCapabilitiesManifest', () => {
-  it('models the snapshot kinds as one remote capability manifest carrying the agentKinds slot', () => {
-    const kinds = [kind(), kind()]
-    const manifest = buildAgentCapabilitiesManifest(kinds)
-    expect(manifest.id).toBe(WORKSPACE_CAPABILITIES_MANIFEST_ID)
-    expect(manifest.slots?.agentKinds).toEqual(kinds)
-  })
-
-  it('copies the input (no aliasing of the caller array)', () => {
-    const kinds = [kind()]
-    const manifest = buildAgentCapabilitiesManifest(kinds)
-    kinds.push(kind())
-    expect(manifest.slots?.agentKinds).toHaveLength(1)
-  })
-
-  it('derives an identical version for identical content (so an unchanged re-hydrate no-ops)', () => {
-    // A fresh, structurally-equal kinds array (a new snapshot re-delivering the same kinds)
-    // must produce the same version — that's what lets `hydrateCustomKinds` skip the swap.
-    expect(buildAgentCapabilitiesManifest([kind()]).version).toBe(
-      buildAgentCapabilitiesManifest([kind()]).version,
-    )
-  })
-
-  it('changes the version when a display/pairing field or the kind set differs', () => {
-    const base = capabilitiesManifestVersion([kind()])
-    expect(capabilitiesManifestVersion([kind({ label: 'Renamed' })])).not.toBe(base)
-    expect(capabilitiesManifestVersion([kind({ resultView: 'acme:audit' })])).not.toBe(base)
-    expect(capabilitiesManifestVersion([kind({}, 'acme-other')])).not.toBe(base)
-    expect(capabilitiesManifestVersion([kind(), kind({}, 'acme-two')])).not.toBe(base)
-    expect(capabilitiesManifestVersion([])).not.toBe(base)
-  })
-})
-
 describe('customKindToArchetype', () => {
   it('projects presentation onto the display archetype', () => {
     expect(customKindToArchetype(kind())).toEqual({

package/app/modular/agent-kinds.ts

@@ -1,67 +1,16 @@
-import type { RemoteModuleManifest } from '@modular-vue/core'
 import type { AgentArchetype, CustomAgentKind } from '~/types/domain'
-import type { AppSlots } from './slots'
 
 /**
- * Custom agent kinds as remote capability manifests (slice 2 of the modular-vue
- * adoption — docs/initiatives/modular-vue-adoption.md).
+ * Custom agent-kind projection (slice 2 of the modular-vue adoption —
+ * docs/initiatives/modular-vue-adoption.md).
  *
- * A deployment's BACKEND-registered agent kinds arrive in the workspace snapshot
- * as `customAgentKinds` (wire data). Rather than mutating a module-global
- * catalog, they're modeled as a single {@link RemoteModuleManifest} whose
- * `agentKinds` slot carries the data. cat-factory holds ONE active manifest per
- * workspace (swapped on snapshot), so the agents store reads its `.slots`
- * directly — the sanctioned single-active-manifest shape (the merge-many
- * `mergeRemoteManifests` helper is for holding several manifests at once, which
- * we don't). CODE-shipped consumer kinds instead enter via the static
- * `agentKinds` slot (a `registerAppModule` module); the store merges both.
+ * A deployment's BACKEND-registered agent kinds arrive in the workspace snapshot as
+ * `customAgentKinds` (wire data), folded into the shared per-workspace capability manifest
+ * (see `./capabilities.ts`, generalized to carry custom TASK types too). CODE-shipped consumer
+ * kinds instead enter via the static `agentKinds` slot (a `registerAppModule` module); the agents
+ * store merges both. This module holds only the wire→display projection they share.
  */
 
-/** The stable id for the per-workspace capability manifest built from the snapshot. */
-export const WORKSPACE_CAPABILITIES_MANIFEST_ID = 'cat-factory:workspace-capabilities'
-
-/**
- * A deterministic, key-order-independent content signature of the custom kinds, used as the
- * manifest `version`. The workspace snapshot re-delivers the SAME deployment-registered kinds on
- * every board-event refresh (a full `workspace.refresh()` runs `hydrateCustomKinds` each time), so
- * a content-derived version lets the store skip re-projecting an UNCHANGED catalog — otherwise
- * every refresh would replace the `customAgentKindMeta` read-model and needlessly invalidate the
- * ~17 `agentKindMeta` / `isKnownAgentKind` consumers. It still changes (and swaps wholesale) when a
- * different workspace's kinds actually differ. Serialized as fixed-order tuples of only the fields
- * that affect display/pairing, so a re-serialization with reordered object keys can't spuriously
- * differ.
- */
-export function capabilitiesManifestVersion(kinds: readonly CustomAgentKind[]): string {
-  return JSON.stringify(
-    kinds.map((k) => [
-      k.kind,
-      k.container,
-      k.presentation.label,
-      k.presentation.icon,
-      k.presentation.color,
-      k.presentation.description,
-      k.presentation.category ?? null,
-      k.presentation.resultView ?? null,
-    ]),
-  )
-}
-
-/**
- * Model the snapshot's `customAgentKinds` as a single remote capability manifest. The `version` is
- * a {@link capabilitiesManifestVersion content signature} so identical snapshots produce an
- * identical manifest — which `useAgentsStore().hydrateCustomKinds` uses to no-op an unchanged
- * re-hydrate. Swapped wholesale (not diffed) when the content genuinely changes.
- */
-export function buildAgentCapabilitiesManifest(
-  kinds: readonly CustomAgentKind[],
-): RemoteModuleManifest<AppSlots> {
-  return {
-    id: WORKSPACE_CAPABILITIES_MANIFEST_ID,
-    version: capabilitiesManifestVersion(kinds),
-    slots: { agentKinds: [...kinds] },
-  }
-}
-
 /**
  * Project a wire `CustomAgentKind` onto the frontend's display `AgentArchetype`
  * (icon/label/color/description + optional category/resultView). The inverse of

package/app/modular/capabilities.spec.ts

@@ -0,0 +1,88 @@
+import { describe, expect, it } from 'vitest'
+import {
+  buildWorkspaceCapabilitiesManifest,
+  WORKSPACE_CAPABILITIES_MANIFEST_ID,
+  workspaceCapabilitiesVersion,
+} from './capabilities'
+import type { AgentKind, CustomAgentKind, CustomTaskType } from '~/types/domain'
+
+const kind = (
+  over: Partial<CustomAgentKind['presentation']> = {},
+  kindId = 'acme-audit',
+): CustomAgentKind => ({
+  kind: kindId as AgentKind,
+  container: true,
+  presentation: {
+    label: 'Audit',
+    icon: 'i-lucide-shield',
+    color: '#fff',
+    description: 'd',
+    ...over,
+  },
+})
+
+const taskType = (
+  over: Partial<CustomTaskType['presentation']> = {},
+  id = 'acme:incident',
+): CustomTaskType => ({
+  taskType: id,
+  presentation: {
+    label: 'Incident',
+    icon: 'i-lucide-siren',
+    color: '#ef4444',
+    description: 'd',
+    ...over,
+  },
+})
+
+describe('buildWorkspaceCapabilitiesManifest', () => {
+  it('models the snapshot capabilities as one manifest carrying BOTH slots', () => {
+    const kinds = [kind()]
+    const taskTypes = [taskType()]
+    const manifest = buildWorkspaceCapabilitiesManifest(kinds, taskTypes)
+    expect(manifest.id).toBe(WORKSPACE_CAPABILITIES_MANIFEST_ID)
+    expect(manifest.slots?.agentKinds).toEqual(kinds)
+    expect(manifest.slots?.taskTypes).toEqual(taskTypes)
+  })
+
+  it('copies the inputs (no aliasing of the caller arrays)', () => {
+    const kinds = [kind()]
+    const taskTypes = [taskType()]
+    const manifest = buildWorkspaceCapabilitiesManifest(kinds, taskTypes)
+    kinds.push(kind())
+    taskTypes.push(taskType())
+    expect(manifest.slots?.agentKinds).toHaveLength(1)
+    expect(manifest.slots?.taskTypes).toHaveLength(1)
+  })
+
+  it('derives an identical version for identical content (so an unchanged re-hydrate no-ops)', () => {
+    expect(buildWorkspaceCapabilitiesManifest([kind()], [taskType()]).version).toBe(
+      buildWorkspaceCapabilitiesManifest([kind()], [taskType()]).version,
+    )
+  })
+
+  it('changes the version when an agent-kind display/pairing field or the kind set differs', () => {
+    const base = workspaceCapabilitiesVersion([kind()], [])
+    expect(workspaceCapabilitiesVersion([kind({ label: 'Renamed' })], [])).not.toBe(base)
+    expect(workspaceCapabilitiesVersion([kind({ resultView: 'acme:audit' })], [])).not.toBe(base)
+    expect(workspaceCapabilitiesVersion([kind({}, 'acme-other')], [])).not.toBe(base)
+    expect(workspaceCapabilitiesVersion([kind(), kind({}, 'acme-two')], [])).not.toBe(base)
+    expect(workspaceCapabilitiesVersion([], [])).not.toBe(base)
+  })
+
+  it('changes the version when a task-type field, its fields, or the set differs', () => {
+    const base = workspaceCapabilitiesVersion([], [taskType()])
+    expect(workspaceCapabilitiesVersion([], [taskType({ label: 'Renamed' })])).not.toBe(base)
+    expect(workspaceCapabilitiesVersion([], [taskType({}, 'acme:other')])).not.toBe(base)
+    expect(
+      workspaceCapabilitiesVersion([], [{ ...taskType(), defaultPipelineId: 'pl_review' }]),
+    ).not.toBe(base)
+    expect(
+      workspaceCapabilitiesVersion(
+        [],
+        [{ ...taskType(), fields: [{ key: 'sev', label: 'Severity', type: 'text' }] }],
+      ),
+    ).not.toBe(base)
+    expect(workspaceCapabilitiesVersion([], [])).not.toBe(base)
+  })
+})

package/app/modular/capabilities.ts

@@ -0,0 +1,77 @@
+import type { RemoteModuleManifest } from '@modular-vue/core'
+import type { CustomAgentKind, CustomTaskType } from '~/types/domain'
+import type { AppSlots } from './slots'
+
+/**
+ * The per-workspace capability manifest (modular-vue adoption slice 2 + the
+ * frontend-extension-mechanism initiative, slice B).
+ *
+ * A deployment's BACKEND-registered capabilities arrive in the workspace snapshot as wire data
+ * — `customAgentKinds` (slice 2) AND `customTaskTypes` (slice B). Rather than mutating
+ * module-global catalogs, BOTH are folded into ONE {@link RemoteModuleManifest} whose slots carry
+ * the data. cat-factory holds ONE active manifest per workspace (swapped on snapshot), so each
+ * store reads its OWN slot off the shared manifest — the sanctioned single-active-manifest shape
+ * (`mergeRemoteManifests` is for holding several at once, which we don't). CODE-shipped consumer
+ * capabilities instead enter via the static `agentKinds` / `taskTypes` slots (a `registerAppModule`
+ * module); each store merges its slot + its manifest half.
+ */
+
+/** The stable id for the per-workspace capability manifest built from the snapshot. */
+export const WORKSPACE_CAPABILITIES_MANIFEST_ID = 'cat-factory:workspace-capabilities'
+
+/**
+ * A deterministic, key-order-independent content signature covering BOTH capability lists, used as
+ * the manifest `version`. The workspace snapshot re-delivers the SAME deployment capabilities on
+ * every board-event refresh (a full `workspace.refresh()` re-hydrates each time), so a
+ * content-derived version lets each store skip re-projecting an UNCHANGED catalog — otherwise every
+ * refresh would replace its read-model and needlessly invalidate every `agentKindMeta` /
+ * `taskTypeMeta` consumer. It still changes (and swaps wholesale) when a different workspace's
+ * capabilities genuinely differ. Serialized as fixed-order tuples of only the fields that affect
+ * display/pairing, so a re-serialization with reordered object keys can't spuriously differ.
+ */
+export function workspaceCapabilitiesVersion(
+  kinds: readonly CustomAgentKind[],
+  taskTypes: readonly CustomTaskType[],
+): string {
+  return JSON.stringify([
+    kinds.map((k) => [
+      k.kind,
+      k.container,
+      k.presentation.label,
+      k.presentation.icon,
+      k.presentation.color,
+      k.presentation.description,
+      k.presentation.category ?? null,
+      k.presentation.resultView ?? null,
+    ]),
+    taskTypes.map((t) => [
+      t.taskType,
+      t.presentation.label,
+      t.presentation.icon,
+      t.presentation.color,
+      t.presentation.description,
+      t.defaultPipelineId ?? null,
+      t.formPanel ?? null,
+      // The descriptor list affects the create-form, so fold its shape into the signature too.
+      (t.fields ?? []).map((f) => [f.key, f.type, f.label, f.required ?? false]),
+    ]),
+  ])
+}
+
+/**
+ * Model the snapshot's `customAgentKinds` + `customTaskTypes` as a single remote capability
+ * manifest. The `version` is a {@link workspaceCapabilitiesVersion content signature over both
+ * lists} so identical snapshots produce an identical manifest — which each store's
+ * `hydrateCapabilities` uses to no-op an unchanged re-hydrate. Swapped wholesale (not diffed) when
+ * the content genuinely changes.
+ */
+export function buildWorkspaceCapabilitiesManifest(
+  kinds: readonly CustomAgentKind[],
+  taskTypes: readonly CustomTaskType[],
+): RemoteModuleManifest<AppSlots> {
+  return {
+    id: WORKSPACE_CAPABILITIES_MANIFEST_ID,
+    version: workspaceCapabilitiesVersion(kinds, taskTypes),
+    slots: { agentKinds: [...kinds], taskTypes: [...taskTypes] },
+  }
+}

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

@@ -50,6 +50,8 @@ const slots = (): AppSlots => ({
   resultViews: [],
   agentKinds: [],
   inspectorPanels: [],
+  taskTypes: [],
+  taskTypeFormPanels: [],
 })
 const ids = (s: unknown) => (s as AppSlots).nav.map((i) => i.id)
 

package/app/modular/registry.ts

@@ -101,7 +101,14 @@ export function createAppRegistry(
   // are registered from the client plugin via `extraModules` + `registerJourney`.
   const registry = createRegistry<AppDeps, AppSlots>({
     services: { gates: deps.gates },
-    slots: { nav: [], resultViews: [], agentKinds: [], inspectorPanels: [] },
+    slots: {
+      nav: [],
+      resultViews: [],
+      agentKinds: [],
+      inspectorPanels: [],
+      taskTypes: [],
+      taskTypeFormPanels: [],
+    },
   }).use(journeysPlugin())
   for (const mod of [...FIRST_PARTY_MODULES, ...extraModules, ...consumerModules]) {
     registry.register(mod)

package/app/modular/slots.ts

@@ -1,6 +1,6 @@
 import type { Component } from 'vue'
 import type { ComponentEntry, PanelEntry } from '@modular-vue/core'
-import type { Block, CustomAgentKind } from '~/types/domain'
+import type { Block, CustomAgentKind, CustomTaskType } from '~/types/domain'
 import type { NavContribution } from './nav-contributions'
 
 /**
@@ -23,6 +23,14 @@ import type { NavContribution } from './nav-contributions'
  *    predicate. Replaces `InspectorPanel.vue`'s level/type `v-if` fan; a consumer
  *    contributes its own panels to the SAME slot via `registerAppModule`. This is
  *    the slot key `definePanelGroup<Block>('inspectorPanels')` names.
+ *  - `taskTypes` (extension slice B) — CODE-shipped custom task types a consumer
+ *    module contributes (the create-task-picker + card-badge data half). BACKEND-
+ *    registered types arrive separately in the shared capability manifest read by
+ *    the task-types store — see `stores/taskTypes.ts`. Symmetric with `agentKinds`.
+ *  - `taskTypeFormPanels` (extension slice B) — a bespoke create-task-form section
+ *    per custom task type, addressed by the type's `formPanel` id and paired via
+ *    `resolveComponentRegistry` (same shape as `resultViews`); shown INSTEAD of the
+ *    descriptor-driven `fields`. An unpaired id degrades to the descriptor fields.
  *
  * The index signature is mutable (`unknown[]`) to satisfy the runtime's
  * `SlotMap` constraint while `unknown[]` still meets `useReactiveSlots`'
@@ -33,6 +41,8 @@ export interface AppSlots {
   resultViews: ResultViewContribution[]
   agentKinds: CustomAgentKind[]
   inspectorPanels: PanelEntry<Block>[]
+  taskTypes: CustomTaskType[]
+  taskTypeFormPanels: ResultViewContribution[]
   [key: string]: unknown[]
 }
 
@@ -43,5 +53,7 @@ export interface AppSlots {
  * helpers index and pair it with the wire-delivered `presentation.resultView`
  * id — the sanctioned "backend data selects a code-shipped, locally-registered
  * component" pairing (see the modular-vue Remote Capability Manifests guide).
+ * Reused for `taskTypeFormPanels` (a bespoke create-form section paired by a
+ * custom task type's `formPanel` id).
  */
 export type ResultViewContribution = ComponentEntry<Component>

package/app/modular/task-types.ts

@@ -0,0 +1,27 @@
+import type { CustomTaskType, TaskTypeMeta } from '~/types/domain'
+
+/**
+ * Custom task-type projection (frontend-extension-mechanism initiative, slice B — the frontend
+ * analogue of `customKindToArchetype` for agent kinds).
+ *
+ * A deployment's BACKEND-registered task types arrive in the workspace snapshot as
+ * `customTaskTypes` (wire data), folded into the shared per-workspace capability manifest (see
+ * `./capabilities.ts`). CODE-shipped consumer task types instead enter via the static `taskTypes`
+ * slot (a `registerAppModule` module); the task-types store merges both. This module holds only
+ * the wire→display projection they share.
+ */
+
+/**
+ * Project a wire {@link CustomTaskType} onto the frontend's display {@link TaskTypeMeta}. A custom
+ * type carries a LITERAL label (from the wire presentation), unlike a built-in type whose label is
+ * an i18n key — so the projected meta sets `label` (not `labelKey`); the renderer resolves the
+ * display string accordingly (`labelKey ? t(labelKey) : label`).
+ */
+export function customTaskTypeToMeta(t: CustomTaskType): TaskTypeMeta {
+  return {
+    taskType: t.taskType,
+    icon: t.presentation.icon,
+    color: t.presentation.color,
+    label: t.presentation.label,
+  }
+}