@cat-factory/app 0.147.7 → 0.148.1

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,
+  }
+}

package/app/plugins/modular.client.ts

@@ -16,7 +16,7 @@ import {
   environmentSetupPersistence,
 } from '~/modular/journeys/environmentSetup'
 import type { AppSlots, ResultViewContribution } from '~/modular/slots'
-import type { Block, CustomAgentKind } from '~/types/domain'
+import type { Block, CustomAgentKind, CustomTaskType } from '~/types/domain'
 
 /**
  * Wire the modular-vue registry into the Nuxt app (slice 0 of the modular-vue
@@ -98,9 +98,14 @@ export default defineNuxtPlugin({
     // selected. `<PanelsOutlet>` re-resolves reactively per subject; this only
     // validates the wiring.
     resolvePanels((slots.inspectorPanels ?? []) as PanelEntry<Block>[], null)
-    // Consumer agent kinds contributed as CODE to the static `agentKinds` slot
-    // (module slots resolve once, so the static base is the full set).
+    // Same fail-fast for the custom-task-type form-panel registry (extension slice B): a
+    // duplicate `formPanel` id across the first-party + consumer modules throws at BOOT
+    // rather than the first time the create-task form opens a custom type's section.
+    resolveComponentRegistry((slots.taskTypeFormPanels ?? []) as ResultViewContribution[])
+    // Consumer agent kinds + task types contributed as CODE to the static `agentKinds` /
+    // `taskTypes` slots (module slots resolve once, so the static base is the full set).
     useAgentsStore().registerConsumerKinds((slots.agentKinds ?? []) as CustomAgentKind[])
+    useTaskTypesStore().registerConsumerTaskTypes((slots.taskTypes ?? []) as CustomTaskType[])
     return { provide: { modular: manifest } }
   },
 })

package/app/stores/agents.spec.ts

@@ -1,5 +1,6 @@
 import { describe, expect, it } from 'vitest'
 import { useAgentsStore } from './agents'
+import { buildWorkspaceCapabilitiesManifest } from '~/modular/capabilities'
 import {
   __resetCustomAgentKindMetaForTest,
   agentKindMeta,
@@ -23,6 +24,11 @@ const backendKind = (
   },
 })
 
+/** Hydrate the store's backend-manifest half with `kinds` (via the shared capability manifest). */
+const hydrate = (agents: ReturnType<typeof useAgentsStore>, kinds: CustomAgentKind[]): void => {
+  agents.hydrateCapabilities(buildWorkspaceCapabilitiesManifest(kinds, []))
+}
+
 describe('agents store — custom-kind catalog (slice 2)', () => {
   it('exposes only the built-in archetypes before any custom kind is hydrated', () => {
     const agents = useAgentsStore()
@@ -37,9 +43,7 @@ describe('agents store — custom-kind catalog (slice 2)', () => {
     expect(isKnownAgentKind('acme-audit')).toBe(false)
     expect(agentKindMeta('acme-audit').label).toBe('Agent') // generic fallback
 
-    agents.hydrateCustomKinds([
-      backendKind('acme-audit', { category: 'review', resultView: 'acme:audit' }),
-    ])
+    hydrate(agents, [backendKind('acme-audit', { category: 'review', resultView: 'acme:audit' })])
 
     // Palette + kind lookup both see it now (sync-flush projection — no tick needed).
     expect(agents.archetypes.some((a) => a.kind === 'acme-audit')).toBe(true)
@@ -52,7 +56,7 @@ describe('agents store — custom-kind catalog (slice 2)', () => {
 
   it('never lets a custom kind shadow a built-in kind', () => {
     const agents = useAgentsStore()
-    agents.hydrateCustomKinds([backendKind('coder', { label: 'Evil Coder' })])
+    hydrate(agents, [backendKind('coder', { label: 'Evil Coder' })])
     // `coder` is a built-in; the custom entry is dropped, the built-in wins.
     expect(agents.customArchetypes.some((a) => a.kind === 'coder')).toBe(false)
     expect(agentKindMeta('coder').label).not.toBe('Evil Coder')
@@ -61,7 +65,7 @@ describe('agents store — custom-kind catalog (slice 2)', () => {
   it('merges CODE-shipped consumer kinds with BACKEND manifest kinds, de-duplicated', () => {
     const agents = useAgentsStore()
     agents.registerConsumerKinds([backendKind('acme-consumer')])
-    agents.hydrateCustomKinds([backendKind('acme-backend'), backendKind('acme-consumer')])
+    hydrate(agents, [backendKind('acme-backend'), backendKind('acme-consumer')])
     const kinds = agents.customArchetypes.map((a) => a.kind)
     expect(kinds).toContain('acme-consumer')
     expect(kinds).toContain('acme-backend')
@@ -71,20 +75,20 @@ describe('agents store — custom-kind catalog (slice 2)', () => {
 
   it('no-ops a re-hydrate of identical content (stable projection, content-versioned manifest)', () => {
     const agents = useAgentsStore()
-    agents.hydrateCustomKinds([backendKind('acme-x', { resultView: 'acme:x' })])
+    hydrate(agents, [backendKind('acme-x', { resultView: 'acme:x' })])
     const first = agents.customArchetypes
     // A new snapshot re-delivering structurally-equal kinds (fresh objects) must not
     // recompute the merged catalog — the content-derived manifest version is unchanged, so
     // `hydrateCustomKinds` skips the swap and the computed keeps its cached identity.
-    agents.hydrateCustomKinds([backendKind('acme-x', { resultView: 'acme:x' })])
+    hydrate(agents, [backendKind('acme-x', { resultView: 'acme:x' })])
     expect(agents.customArchetypes).toBe(first)
   })
 
   it('swaps the backend catalog wholesale on re-hydrate (per-workspace manifest)', () => {
     const agents = useAgentsStore()
-    agents.hydrateCustomKinds([backendKind('ws1-kind')])
+    hydrate(agents, [backendKind('ws1-kind')])
     expect(agents.customArchetypes.some((a) => a.kind === 'ws1-kind')).toBe(true)
-    agents.hydrateCustomKinds([backendKind('ws2-kind')])
+    hydrate(agents, [backendKind('ws2-kind')])
     expect(agents.customArchetypes.some((a) => a.kind === 'ws1-kind')).toBe(false)
     expect(agents.customArchetypes.some((a) => a.kind === 'ws2-kind')).toBe(true)
     expect(isKnownAgentKind('ws1-kind')).toBe(false)

package/app/stores/agents.ts

@@ -1,7 +1,7 @@
 import { defineStore } from 'pinia'
 import { computed, ref, watch } from 'vue'
 import type { RemoteModuleManifest } from '@modular-vue/core'
-import { buildAgentCapabilitiesManifest, customKindToArchetype } from '~/modular/agent-kinds'
+import { customKindToArchetype } from '~/modular/agent-kinds'
 import type { AppSlots } from '~/modular/slots'
 import {
   AGENT_ARCHETYPES,
@@ -21,9 +21,9 @@ import type { AgentArchetype, AgentKind, CustomAgentKind } from '~/types/domain'
  *  - the built-in archetypes (static);
  *  - CONSUMER-shipped kinds contributed as CODE via the modular `agentKinds`
  *    slot (`registerConsumerKinds`, fed once at boot from the resolved manifest);
- *  - the deployment's BACKEND-registered kinds, modeled as a single
+ *  - the deployment's BACKEND-registered kinds, read from the shared per-workspace
  *    {@link RemoteModuleManifest} swapped per workspace snapshot
- *    (`hydrateCustomKinds`) and read directly (single-active-manifest shape).
+ *    (`hydrateCapabilities`, reading its own `agentKinds` slot — single-active-manifest shape).
  *
  * The merged custom catalog is projected back into `catalog.ts`'s
  * {@link setCustomAgentKindMeta} read-model so the pure `agentKindMeta` /
@@ -77,7 +77,7 @@ export const useAgentsStore = defineStore('agents', () => {
 
   // Keep `catalog.ts`'s pure-util projection in sync with the merged custom
   // catalog so `agentKindMeta` / `isKnownAgentKind` resolve custom kinds. Sync
-  // flush so an imperative read right after `hydrateCustomKinds` (e.g. the run
+  // flush so an imperative read right after `hydrateCapabilities` (e.g. the run
   // dispatch resolving a custom kind's `resultView`) sees the fresh catalog with
   // no tick gap. The watch lives in the store's effect scope (disposed with it).
   watch(customByKind, (map) => setCustomAgentKindMeta(map), { immediate: true, flush: 'sync' })
@@ -119,20 +119,19 @@ export const useAgentsStore = defineStore('agents', () => {
   }
 
   /**
-   * Hydrate the deployment's BACKEND-registered custom kinds from a workspace
-   * snapshot, modeled as a single remote capability manifest (swapped wholesale
-   * per workspace). Replaces the old `registerCustomKinds` that mutated
-   * {@link AGENT_BY_KIND} directly.
+   * Hydrate the deployment's BACKEND-registered custom kinds from the shared per-workspace
+   * capability manifest (built by the workspace store from the snapshot, carrying both `agentKinds`
+   * + `taskTypes`; this store reads only its own `agentKinds` slot). Swapped wholesale per
+   * workspace. Replaces the old `registerCustomKinds` that mutated {@link AGENT_BY_KIND} directly.
    *
-   * The snapshot re-delivers the same deployment kinds on every board refresh, so
-   * skip the swap — and the downstream projection invalidation of every
-   * `agentKindMeta` consumer — when the content-derived manifest version is
-   * unchanged. A genuinely different workspace's kinds change the version and swap.
+   * The snapshot re-delivers the same deployment kinds on every board refresh, so skip the swap —
+   * and the downstream projection invalidation of every `agentKindMeta` consumer — when the
+   * content-derived manifest version is unchanged. A genuinely different workspace's capabilities
+   * change the version and swap.
    */
-  function hydrateCustomKinds(kinds: CustomAgentKind[]) {
-    const next = buildAgentCapabilitiesManifest(kinds)
-    if (capabilitiesManifest.value?.version === next.version) return
-    capabilitiesManifest.value = next
+  function hydrateCapabilities(manifest: RemoteModuleManifest<AppSlots>) {
+    if (capabilitiesManifest.value?.version === manifest.version) return
+    capabilitiesManifest.value = manifest
   }
 
   return {
@@ -141,6 +140,6 @@ export const useAgentsStore = defineStore('agents', () => {
     get,
     addAgent,
     registerConsumerKinds,
-    hydrateCustomKinds,
+    hydrateCapabilities,
   }
 })

package/app/stores/taskTypes.spec.ts

@@ -0,0 +1,100 @@
+import { describe, expect, it } from 'vitest'
+import { useTaskTypesStore } from './taskTypes'
+import { buildWorkspaceCapabilitiesManifest } from '~/modular/capabilities'
+import { __resetCustomTaskTypeMetaForTest, isKnownTaskType, taskTypeMeta } from '~/utils/catalog'
+import type { CustomTaskType } from '~/types/domain'
+
+const backendType = (
+  taskType: string,
+  over: Partial<CustomTaskType['presentation']> = {},
+): CustomTaskType => ({
+  taskType,
+  presentation: {
+    label: `L:${taskType}`,
+    icon: 'i-lucide-siren',
+    color: '#ef4444',
+    description: 'd',
+    ...over,
+  },
+})
+
+/** Hydrate the store's backend-manifest half with `taskTypes` (via the shared capability manifest). */
+const hydrate = (
+  store: ReturnType<typeof useTaskTypesStore>,
+  taskTypes: CustomTaskType[],
+): void => {
+  store.hydrateCapabilities(buildWorkspaceCapabilitiesManifest([], taskTypes))
+}
+
+describe('taskTypes store — custom task-type catalog (extension slice B)', () => {
+  it('exposes no custom types before any hydrate', () => {
+    const store = useTaskTypesStore()
+    expect(store.customTaskTypes).toEqual([])
+  })
+
+  it('folds a backend remote-manifest custom type into the catalog + the pure-util projection', () => {
+    __resetCustomTaskTypeMetaForTest()
+    const store = useTaskTypesStore()
+    // Before hydrate the pure-util lookups don't know the type; taskTypeMeta degrades to `feature`.
+    expect(isKnownTaskType('acme:incident')).toBe(false)
+    const before = taskTypeMeta('acme:incident')
+    expect(before.icon).toBe(taskTypeMeta('feature').icon) // feature fallback icon
+    expect(before.label).toBe('acme:incident') // raw id, never blank
+
+    hydrate(store, [backendType('acme:incident', { label: 'Incident' })])
+
+    // Catalog + lookup both see it now (sync-flush projection — no tick needed).
+    expect(store.customTaskTypes.some((t) => t.taskType === 'acme:incident')).toBe(true)
+    expect(isKnownTaskType('acme:incident')).toBe(true)
+    const meta = taskTypeMeta('acme:incident')
+    expect(meta.label).toBe('Incident')
+    expect(meta.labelKey).toBeUndefined() // custom types carry a literal label, not an i18n key
+  })
+
+  it('never lets a custom type shadow a built-in type', () => {
+    const store = useTaskTypesStore()
+    hydrate(store, [backendType('feature', { label: 'Evil Feature' })])
+    expect(store.customTaskTypes.some((t) => t.taskType === 'feature')).toBe(false)
+    expect(taskTypeMeta('feature').labelKey).toBe('board.addTask.types.feature')
+  })
+
+  it('merges CODE-shipped consumer types with BACKEND manifest types, de-duplicated', () => {
+    const store = useTaskTypesStore()
+    store.registerConsumerTaskTypes([backendType('acme:consumer')])
+    hydrate(store, [backendType('acme:backend'), backendType('acme:consumer')])
+    const ids = store.customTaskTypes.map((t) => t.taskType)
+    expect(ids).toContain('acme:consumer')
+    expect(ids).toContain('acme:backend')
+    expect(ids.filter((k) => k === 'acme:consumer')).toHaveLength(1)
+  })
+
+  it('no-ops a re-hydrate of identical content (content-versioned manifest)', () => {
+    const store = useTaskTypesStore()
+    hydrate(store, [backendType('acme:x')])
+    const first = store.customTaskTypes
+    hydrate(store, [backendType('acme:x')])
+    expect(store.customTaskTypes).toBe(first)
+  })
+
+  it('swaps the backend catalog wholesale on re-hydrate (per-workspace manifest)', () => {
+    const store = useTaskTypesStore()
+    hydrate(store, [backendType('acme:ws1')])
+    expect(store.customTaskTypes.some((t) => t.taskType === 'acme:ws1')).toBe(true)
+    hydrate(store, [backendType('acme:ws2')])
+    expect(store.customTaskTypes.some((t) => t.taskType === 'acme:ws1')).toBe(false)
+    expect(store.customTaskTypes.some((t) => t.taskType === 'acme:ws2')).toBe(true)
+    expect(isKnownTaskType('acme:ws1')).toBe(false)
+  })
+
+  it('get() returns the full registration (for the create-form field descriptors)', () => {
+    const store = useTaskTypesStore()
+    hydrate(store, [
+      {
+        ...backendType('acme:incident'),
+        fields: [{ key: 'sev', label: 'Severity', type: 'text' }],
+      },
+    ])
+    expect(store.get('acme:incident')?.fields?.[0]?.key).toBe('sev')
+    expect(store.get('acme:unknown')).toBeUndefined()
+  })
+})

package/app/stores/taskTypes.ts

@@ -0,0 +1,88 @@
+import { defineStore } from 'pinia'
+import { computed, ref, watch } from 'vue'
+import type { RemoteModuleManifest } from '@modular-vue/core'
+import { customTaskTypeToMeta } from '~/modular/task-types'
+import type { AppSlots } from '~/modular/slots'
+import { TASK_TYPE_META, setCustomTaskTypeMeta } from '~/utils/catalog'
+import type { CustomTaskType, TaskTypeMeta } from '~/types/domain'
+
+/**
+ * The custom task-type catalog (frontend-extension-mechanism initiative, slice B) — the exact twin
+ * of the agents store (`stores/agents.ts`), which is the template for every capability catalog.
+ *
+ * Reactive union of two sources, neither mutating the built-in {@link TASK_TYPE_META} const:
+ *  - CONSUMER-shipped task types contributed as CODE via the modular `taskTypes` slot
+ *    (`registerConsumerTaskTypes`, fed once at boot from the resolved manifest);
+ *  - the deployment's BACKEND-registered task types, folded into the single per-workspace
+ *    {@link RemoteModuleManifest} the workspace store swaps per snapshot (`hydrateCapabilities`,
+ *    reading its OWN `taskTypes` slot off the shared manifest).
+ *
+ * The merged custom catalog is projected back into `catalog.ts`'s {@link setCustomTaskTypeMeta}
+ * read-model so the pure `taskTypeMeta` lookup (used by the card badge + create-task picker)
+ * resolves a custom type reactively without importing this store.
+ */
+export const useTaskTypesStore = defineStore('taskTypes', () => {
+  // CODE-shipped consumer task types from the static `taskTypes` slot (fed once at boot by the
+  // modular install plugin — module slots are resolved once).
+  const consumerTaskTypes = ref<CustomTaskType[]>([])
+  // The active per-workspace capability manifest (shared with the agents store), or null before
+  // the first hydrate. This store reads only its own `taskTypes` slot off it.
+  const capabilitiesManifest = ref<RemoteModuleManifest<AppSlots> | null>(null)
+
+  /**
+   * The merged CUSTOM task types (consumer-slot → backend-manifest), de-duplicated and never
+   * shadowing a BUILT-IN type. A namespaced custom id can't collide with a bare built-in, but the
+   * built-in drop is kept for parity with the agents store (and to be robust to a malformed id).
+   */
+  const customTaskTypes = computed<CustomTaskType[]>(() => {
+    const seen = new Set<string>()
+    const out: CustomTaskType[] = []
+    const add = (t: CustomTaskType) => {
+      if (t.taskType in TASK_TYPE_META || seen.has(t.taskType)) return
+      seen.add(t.taskType)
+      out.push(t)
+    }
+    for (const t of consumerTaskTypes.value) add(t)
+    for (const t of capabilitiesManifest.value?.slots?.taskTypes ?? []) add(t)
+    return out
+  })
+
+  /** The custom types indexed by id, for a per-type lookup (e.g. the create-form field descriptors). */
+  const byTaskType = computed<Record<string, CustomTaskType>>(() =>
+    Object.fromEntries(customTaskTypes.value.map((t) => [t.taskType, t])),
+  )
+
+  // Keep `catalog.ts`'s pure-util projection in sync with the merged custom catalog so
+  // `taskTypeMeta` resolves custom types. Sync flush so an imperative read right after
+  // `hydrateCapabilities` sees the fresh catalog with no tick gap (mirrors the agents store).
+  const customMetaMap = computed<Record<string, TaskTypeMeta>>(() =>
+    Object.fromEntries(customTaskTypes.value.map((t) => [t.taskType, customTaskTypeToMeta(t)])),
+  )
+  watch(customMetaMap, (map) => setCustomTaskTypeMeta(map), { immediate: true, flush: 'sync' })
+
+  /** The registered custom task type for `taskType`, or undefined. */
+  function get(taskType: string): CustomTaskType | undefined {
+    return byTaskType.value[taskType]
+  }
+
+  /**
+   * Register the deployment's CODE-shipped consumer task types — the resolved modular `taskTypes`
+   * slot, fed once by the install plugin. Idempotent replace (module slots resolve once).
+   */
+  function registerConsumerTaskTypes(types: readonly CustomTaskType[]) {
+    consumerTaskTypes.value = [...types]
+  }
+
+  /**
+   * Hydrate the deployment's BACKEND-registered capabilities from the shared per-workspace manifest
+   * (built by the workspace store from the snapshot, carrying both `agentKinds` + `taskTypes`).
+   * Skips the swap — and the downstream projection invalidation — when the content-derived manifest
+   * version is unchanged, exactly like the agents store.
+   */
+  function hydrateCapabilities(manifest: RemoteModuleManifest<AppSlots>) {
+    if (capabilitiesManifest.value?.version === manifest.version) return
+    capabilitiesManifest.value = manifest
+  }
+
+  return { customTaskTypes, get, registerConsumerTaskTypes, hydrateCapabilities }
+})

package/app/stores/workspace.ts

@@ -25,6 +25,8 @@ import { useRecurringPipelinesStore } from '~/stores/recurringPipelines'
 import { useInitiativesStore } from '~/stores/initiative'
 import { useServicesStore } from '~/stores/services'
 import { useAgentsStore } from '~/stores/agents'
+import { useTaskTypesStore } from '~/stores/taskTypes'
+import { buildWorkspaceCapabilitiesManifest } from '~/modular/capabilities'
 import { useSkillsStore } from '~/stores/skills'
 import { useTrackerStore } from '~/stores/tracker'
 import { useRequirementsStore } from '~/stores/requirements'
@@ -169,10 +171,18 @@ export const useWorkspaceStore = defineStore(
       useInitiativesStore().hydratePresets(snapshot.initiativePresets)
       useTrackerStore().hydrate(snapshot.trackerSettings)
       useServicesStore().hydrate(snapshot.mounts ?? [], snapshot.serviceCatalog ?? [])
-      // Hydrate the deployment's backend-registered custom agent kinds as the workspace's
-      // remote capability manifest, so a proprietary kind renders as a first-class palette
-      // block + result view. Swapped wholesale per workspace (no global-catalog mutation).
-      useAgentsStore().hydrateCustomKinds(snapshot.customAgentKinds ?? [])
+      // Hydrate the deployment's backend-registered capabilities from ONE shared per-workspace
+      // remote capability manifest carrying BOTH custom agent kinds AND custom task types (its
+      // version covers both, so an unchanged snapshot no-ops both stores). Each store reads its
+      // own slot off it, so a proprietary agent kind renders as a first-class palette block +
+      // result view and a proprietary task type as a first-class create-task choice + card badge.
+      // Swapped wholesale per workspace (no global-catalog mutation).
+      const capabilities = buildWorkspaceCapabilitiesManifest(
+        snapshot.customAgentKinds ?? [],
+        snapshot.customTaskTypes ?? [],
+      )
+      useAgentsStore().hydrateCapabilities(capabilities)
+      useTaskTypesStore().hydrateCapabilities(capabilities)
       // The account's repo-sourced Claude Skills catalog (shared across its workspaces), so the
       // pipeline builder's per-step skill picker has its options. A straight replace.
       useSkillsStore().hydrate(snapshot.skills ?? [])

package/app/types/domain.ts

@@ -59,6 +59,10 @@ export type {
   AgentKind,
   AgentCategory,
   CustomAgentKind,
+  CustomTaskType,
+  TaskTypePresentation,
+  TaskTypeFieldDescriptor,
+  TaskTypeFieldOption,
   Pipeline,
   PipelinePurpose,
   SpendStatus,
@@ -117,6 +121,25 @@ export interface AgentArchetype {
   resultView?: string
 }
 
+/**
+ * Display metadata for a task TYPE (the card badge + create-task picker), resolved through the
+ * `taskTypeMeta` read-model. A BUILT-IN type carries an i18n {@link labelKey}; a CUSTOM
+ * (deployment-registered) type carries a literal {@link label} from the wire presentation. The
+ * renderer resolves the display string as `labelKey ? t(labelKey) : label`. Frontend-only.
+ */
+export interface TaskTypeMeta {
+  /** The task type id this meta describes. */
+  taskType: string
+  /** iconify name (lucide). */
+  icon: string
+  /** tailwind-ish accent token used across the card badge / picker. */
+  color: string
+  /** i18n key for a BUILT-IN type's label; absent for a custom type. */
+  labelKey?: string
+  /** Literal label for a CUSTOM type (from the wire presentation); absent for a built-in. */
+  label?: string
+}
+
 /** Level-of-detail buckets driven by the canvas zoom level. Shallow → deep:
  * `far`/`mid`/`close` govern a service frame (chip → card → opened with tasks);
  * `steps`/`subtasks` drill spatially into an individual task — revealing its