@cat-factory/app 0.147.6 → 0.148.1

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

package/app/utils/catalog.ts

@@ -5,6 +5,7 @@ import type {
   AgentKind,
   BlockStatus,
   BlockType,
+  TaskTypeMeta,
 } from '~/types/domain'
 
 /** Simple unique id helper (fine for a client-only prototype). */
@@ -698,6 +699,112 @@ export function isKnownAgentKind(kind: string): boolean {
   return kind in AGENT_BY_KIND || kind in SYSTEM_AGENT_META || kind in customAgentKindMeta.value
 }
 
+// ---------------------------------------------------------------------------
+// Task-type presentation (frontend-extension-mechanism initiative, slice B) — the exact twin of
+// the agent-kind read-model above: a frozen BUILT-IN map + a reactive CUSTOM projection fed by the
+// task-types store, resolved through {@link taskTypeMeta} so the card badge + create-task picker
+// render a built-in OR a deployment-registered custom type — and an UNREGISTERED namespaced type
+// (stale data after an extension was removed) degrades to the `feature` presentation, never a crash.
+// ---------------------------------------------------------------------------
+
+/**
+ * The BUILT-IN task-type presentations, keyed by type. Icons mirror the create-task picker's old
+ * hardcoded list; `labelKey` is the i18n key the renderer resolves (built-in labels are localized,
+ * unlike a custom type's literal wire label). `recurring` is not human-creatable but is stamped on
+ * the reused schedule block, so it needs a badge too.
+ */
+export const TASK_TYPE_META: Record<string, TaskTypeMeta> = {
+  feature: {
+    taskType: 'feature',
+    icon: 'i-lucide-sparkles',
+    color: '#38bdf8',
+    labelKey: 'board.addTask.types.feature',
+  },
+  bug: {
+    taskType: 'bug',
+    icon: 'i-lucide-bug',
+    color: '#f87171',
+    labelKey: 'board.addTask.types.bug',
+  },
+  document: {
+    taskType: 'document',
+    icon: 'i-lucide-file-text',
+    color: '#c084fc',
+    labelKey: 'board.addTask.types.document',
+  },
+  spike: {
+    taskType: 'spike',
+    icon: 'i-lucide-flask-conical',
+    color: '#fbbf24',
+    labelKey: 'board.addTask.types.spike',
+  },
+  review: {
+    taskType: 'review',
+    icon: 'i-lucide-clipboard-check',
+    color: '#34d399',
+    labelKey: 'board.addTask.types.review',
+  },
+  ralph: {
+    taskType: 'ralph',
+    icon: 'i-lucide-infinity',
+    color: '#a78bfa',
+    labelKey: 'board.addTask.types.ralph',
+  },
+  recurring: {
+    taskType: 'recurring',
+    icon: 'i-lucide-repeat',
+    color: '#94a3b8',
+    labelKey: 'board.addTask.types.recurring',
+  },
+}
+
+/**
+ * Reactive read-model of the deployment's CUSTOM task types (consumer-slot + backend
+ * remote-manifest), kept in sync by the task-types store — the exact twin of
+ * {@link customAgentKindMeta}. The store is the source of truth; this `shallowRef` is its
+ * synchronous projection so {@link taskTypeMeta} / {@link isKnownTaskType} resolve a custom type
+ * WITHOUT importing the store (circular) or mutating {@link TASK_TYPE_META}.
+ */
+const customTaskTypeMeta = shallowRef<Record<string, TaskTypeMeta>>({})
+
+/** Replace the custom task-type projection (called only by the task-types store). */
+export function setCustomTaskTypeMeta(map: Record<string, TaskTypeMeta>): void {
+  customTaskTypeMeta.value = map
+}
+
+/** Test-only: clear the custom task-type projection so a spec starts from built-ins only. */
+export function __resetCustomTaskTypeMetaForTest(): void {
+  customTaskTypeMeta.value = {}
+}
+
+/**
+ * Resolve display metadata for ANY task type — a BUILT-IN ({@link TASK_TYPE_META}), a deployment
+ * CUSTOM type (projected into {@link customTaskTypeMeta} by the task-types store), or an
+ * UNREGISTERED namespaced one (stale data after its extension was removed) — ALWAYS returning a
+ * usable icon/color/label. An unregistered/unknown type falls back to the `feature` presentation
+ * (its icon/color) but keeps the raw id as its literal label, so a leftover string renders a badge
+ * instead of breaking the card. Reading `customTaskTypeMeta` reactively means a component computed
+ * re-runs when the custom catalog changes.
+ */
+export function taskTypeMeta(taskType: string | undefined): TaskTypeMeta {
+  if (!taskType) return TASK_TYPE_META.feature!
+  return (
+    TASK_TYPE_META[taskType] ??
+    customTaskTypeMeta.value[taskType] ?? {
+      taskType,
+      icon: TASK_TYPE_META.feature!.icon,
+      color: TASK_TYPE_META.feature!.color,
+      // Unregistered namespaced type: no i18n key, so show its raw id rather than a blank badge.
+      label: taskType,
+    }
+  )
+}
+
+/** Whether a task type is known to this build — a built-in or a projected custom type. */
+export function isKnownTaskType(taskType: string): boolean {
+  return taskType in TASK_TYPE_META || taskType in customTaskTypeMeta.value
+}
+
 type BlockTypeMeta = { label: string; icon: string; accent: string }
 
 /** Visual metadata for each architecture block type. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cat-factory/app",
-  "version": "0.147.6",
+  "version": "0.148.1",
   "description": "Reusable Nuxt layer for the Agent Architecture Board SPA (components, stores, composables, pages). Consume it from a thin deployment app via `extends: ['@cat-factory/app']` and point it at your backend with NUXT_PUBLIC_API_BASE. See deploy/frontend for an example.",
   "repository": {
     "type": "git",
@@ -40,7 +40,7 @@
     "valibot": "^1.4.2",
     "vue": "3.5.40",
     "wretch": "^3.0.9",
-    "@cat-factory/contracts": "0.154.2"
+    "@cat-factory/contracts": "0.156.0"
   },
   "devDependencies": {
     "@toad-contracts/testing": "0.3.2",