@cat-factory/app 0.147.6 → 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/board/context.ts

@@ -0,0 +1,46 @@
+import type { Ref } from 'vue'
+import type { Block } from '~/types/domain'
+
+/** A detached subtree captured before an optimistic delete, restored on failure. */
+export interface RemovalSnapshot {
+  /** The removed block + all its descendants, in their original order. */
+  removed: Block[]
+  /**
+   * Survivors whose `dependsOn`/`epicId`/`initiativeId` lost an edge to a removed block
+   * (originals to restore on rollback).
+   */
+  edges: { id: string; dependsOn: string[]; epicId: string | null; initiativeId: string | null }[]
+}
+
+/** A still-pending optimistic delete: its snapshot, the deferred-commit timer, and its workspace. */
+export interface PendingRemoval {
+  snap: RemovalSnapshot
+  timer: ReturnType<typeof setTimeout>
+  wsId: string
+}
+
+/**
+ * How long a deleted block stays undoable. The backend delete is DEFERRED for this
+ * window (a real "undo", not a client illusion) — the block is hidden immediately but
+ * only actually deleted once the window elapses, so undo just cancels the pending call.
+ */
+export const UNDO_WINDOW_MS = 6000
+
+/**
+ * Shared state + injected dependencies the board-store write factories close over. Created once in
+ * the `board` store setup and threaded into {@link createBoardMutations} / {@link createBoardRemoval}
+ * so the split operations stay behaviourally identical to the original single-closure store — the
+ * factories are cohesive extractions purely to keep each function within the size budget, not new
+ * seams. `api`/`toast`/`tr` are the store's own resolved handles (a store runs outside a component
+ * `setup`, so `tr` bridges to the Nuxt app's global i18n instance).
+ */
+export interface BoardWriteContext {
+  blocks: Ref<Block[]>
+  getBlock: (id: string) => Block | undefined
+  upsert: (block: Block) => void
+  pendingRemovals: Map<string, PendingRemoval>
+  pendingDoomed: Set<string>
+  api: ReturnType<typeof useApi>
+  toast: ReturnType<typeof useToast>
+  tr: (key: string, params?: Record<string, unknown>) => string
+}