@cat-factory/app 0.131.0 → 0.133.0

package/app/modular/registry.ts

@@ -0,0 +1,93 @@
+import type { AnyModuleDescriptor } from '@modular-vue/core'
+import { createRegistry } from '@modular-vue/runtime'
+import type { ModuleRegistry } from '@modular-vue/runtime'
+import { navigationModule } from '~/modular/nav-contributions'
+import type { AppSlots, NavGates } from '~/modular/nav-contributions'
+
+/**
+ * modular-vue registry for the `@cat-factory/app` layer (slice 0 of the
+ * modular-vue adoption — docs/initiatives/modular-vue-adoption.md).
+ *
+ * This is the frontend analogue of the backend's public registries
+ * (`registerAgentKind`, `registerGate`): a single registry into which the layer
+ * registers its own first-party feature modules AND a consumer deployment
+ * contributes its own, all through the same seam. The registry is resolved and
+ * installed by `app/plugins/modular.client.ts`.
+ *
+ * Slice 1 registers the first real feature module: `cat-factory:navigation`
+ * contributes the whole nav/command catalog to the `nav` slot, gated reactively
+ * by a `gates` service + `navSlotFilter` and rendered by `SideBar`, `CommandBar`,
+ * and `BoardToolbar` via `useReactiveSlots`. Later slices add result views,
+ * wizards, and inspector panels as further modules registered here.
+ */
+
+/**
+ * The layer's shared-dependency shape (grows as later slices wire more deps).
+ * A `type` (not `interface`) so it satisfies the registry's
+ * `Record<string, any>` dependency constraint — an interface lacks the implicit
+ * index signature a type-literal has.
+ */
+export type AppDeps = {
+  /** Reactive RBAC/availability gates the nav `slotFilter` reads. */
+  gates: NavGates
+}
+
+/**
+ * First-party modules the layer always registers. Real feature modules land
+ * here as each area is converted; slice 1 adds the navigation catalog.
+ */
+const FIRST_PARTY_MODULES: readonly AnyModuleDescriptor[] = [navigationModule]
+
+/**
+ * Consumer-contributed modules, collected before the layer resolves its
+ * registry. A deployment extending `@cat-factory/app` calls
+ * {@link registerAppModule} from its own Nuxt plugin (which runs before the
+ * layer's install plugin — see the ordering note in
+ * `app/plugins/modular.client.ts`). Module descriptors carry Vue components, so
+ * they can't travel through serializable Nuxt config; this in-process seam is
+ * how the layer stays unforked while a consumer contributes real components.
+ */
+const consumerModules: AnyModuleDescriptor[] = []
+
+/**
+ * Contribute a module to the app registry from a consumer deployment (or a
+ * first-party plugin). Call this at plugin-setup time, before the layer's
+ * install plugin resolves the registry. Registering the same id twice makes
+ * `resolve()` throw at build time (duplicate-id validation), which is the
+ * intended guard.
+ */
+export function registerAppModule(module: AnyModuleDescriptor): void {
+  consumerModules.push(module)
+}
+
+/**
+ * Test-only: drop every consumer-registered module so a spec can exercise
+ * {@link registerAppModule} without leaking state into the next test. Not part
+ * of the runtime seam.
+ */
+export function __resetConsumerModulesForTest(): void {
+  consumerModules.length = 0
+}
+
+/**
+ * Build a fresh registry with the first-party modules plus everything a consumer
+ * contributed via {@link registerAppModule}. A new registry per call because
+ * `resolve()` / `resolveManifest()` are single-commit; the install plugin calls
+ * this exactly once at client startup (`ssr: false`, so a singleton app).
+ *
+ * `deps.gates` is the reactive gate service the nav `slotFilter` reads; it's
+ * built in the install plugin (Vue context) and registered as a `service` so
+ * `useReactiveSlots` tracks it. The `nav` slot default is seeded empty so the
+ * key always exists even before any module (or with only consumer modules)
+ * contributes.
+ */
+export function createAppRegistry(deps: AppDeps): ModuleRegistry<AppDeps, AppSlots> {
+  const registry = createRegistry<AppDeps, AppSlots>({
+    services: { gates: deps.gates },
+    slots: { nav: [] },
+  })
+  for (const mod of [...FIRST_PARTY_MODULES, ...consumerModules]) {
+    registry.register(mod)
+  }
+  return registry
+}

package/app/plugins/modular.client.ts

@@ -0,0 +1,40 @@
+import { installModularApp } from '@modular-vue/nuxt/runtime'
+import { createAppRegistry } from '~/modular/registry'
+import { navSlotFilter } from '~/modular/nav-contributions'
+import { createNavGates } from '~/modular/nav-gates'
+
+/**
+ * Wire the modular-vue registry into the Nuxt app (slice 0 of the modular-vue
+ * adoption — docs/initiatives/modular-vue-adoption.md).
+ *
+ * `enforce: 'post'` is load-bearing for the consumer-contribution seam. Nuxt
+ * loads layer plugins before the consuming app's plugins within the same enforce
+ * bucket, so a consumer that calls `registerAppModule(...)` from a normal plugin
+ * would otherwise run AFTER this one and miss the resolve. Putting this plugin in
+ * the `post` bucket flips the order: the consumer's default-bucket registration
+ * runs first, then this resolves the registry with everything registered. A
+ * consumer therefore contributes from a default (or `pre`) plugin — documented
+ * in the framework-mode-nuxt guide upstream.
+ *
+ * `ssr: false`, so this runs once on the client and a singleton registry is
+ * fine. `installModularApp` is the router-owning path: it grafts each module's
+ * routes onto Nuxt's router (none yet — the nav modules are non-routed) and
+ * installs the modular contexts (shared deps, navigation, slots) app-wide.
+ *
+ * Slice 1 wires the reactive nav gating here: `createNavGates()` builds the
+ * reactive `gates` service (Pinia + composables are available in a `post`
+ * plugin), which the registry registers as a `service` and `navSlotFilter` reads
+ * per item. The shells consume the gated `nav` slot through `useReactiveSlots`,
+ * so a permission/connection flip re-gates them with no `recalculateSlots()`.
+ */
+export default defineNuxtPlugin({
+  name: 'cat-factory:modular',
+  enforce: 'post',
+  setup(nuxtApp) {
+    const registry = createAppRegistry({ gates: createNavGates() })
+    const manifest = installModularApp({ vueApp: nuxtApp.vueApp, $router: useRouter() }, registry, {
+      slotFilter: navSlotFilter,
+    })
+    return { provide: { modular: manifest } }
+  },
+})

package/app/utils/modular.ts

@@ -0,0 +1,11 @@
+/**
+ * Auto-imported seam for the modular-vue registry. Re-exported from `app/utils/`
+ * (which Nuxt auto-imports across the whole `extends` chain) so a consumer
+ * deployment can contribute modules with a bare `registerAppModule(...)` call
+ * from its own plugin — no deep import into the layer's internals, the same
+ * ergonomics as the layer's auto-imported stores and composables.
+ *
+ * See `app/modular/registry.ts` for the seam itself and
+ * docs/initiatives/modular-vue-adoption.md for the adoption plan.
+ */
+export { registerAppModule } from '~/modular/registry'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cat-factory/app",
-  "version": "0.131.0",
+  "version": "0.133.0",
   "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",
@@ -18,6 +18,11 @@
     "access": "public"
   },
   "dependencies": {
+    "@modular-frontend/core": "^0.1.0",
+    "@modular-vue/core": "^1.0.1",
+    "@modular-vue/nuxt": "^0.1.1",
+    "@modular-vue/runtime": "^1.1.0",
+    "@modular-vue/vue": "^1.1.0",
     "@nuxt/ui": "^4.9.0",
     "@nuxtjs/i18n": "^10.4.1",
     "@pinia/nuxt": "^0.11.3",
@@ -32,7 +37,7 @@
     "pinia": "^3.0.4",
     "pinia-plugin-persistedstate": "^4.7.1",
     "valibot": "^1.4.2",
-    "vue": "3.5.39",
+    "vue": "3.5.40",
     "wretch": "^3.0.9",
     "@cat-factory/contracts": "0.147.1"
   },