@cat-factory/app 0.247.0 → 0.248.0

package/app/components/environments/EnvironmentSetupWizard.vue

@@ -1,7 +1,7 @@
 <script setup lang="ts">
 // The environment setup wizard shell (shared-stacks slice 7; converted to a
 // modular-vue journey in slice 3 of the modular-vue adoption —
-// docs/initiatives/modular-vue-adoption.md).
+// backend/docs/adr/0049-modular-vue-adoption.md).
 //
 // This component is now purely the MODAL + STEPPER CHROME. The step sequence,
 // forward/back navigation, and resume are owned by the `environment-setup`

package/app/components/environments/steps/JourneyStepNav.vue

@@ -1,6 +1,6 @@
 <script setup lang="ts">
 // Shared footer chrome for a modular-vue journey step (slice 3 of the modular-vue
-// adoption — docs/initiatives/modular-vue-adoption.md). Renders the Back control
+// adoption — backend/docs/adr/0049-modular-vue-adoption.md). Renders the Back control
 // (wired to the host-provided `goBack`, present only when the current entry
 // declared `allowBack` and there's a prior step) plus a `primary` slot for the
 // step's own advance affordance, so gating stays local to each step.

package/app/components/layout/BoardToolbar.vue

@@ -5,7 +5,7 @@ import IconButton from '~/components/common/IconButton.vue'
 
 const ui = useUiStore()
 const board = useBoardStore()
-// Toolbar contributions from the shared nav manifest (docs/initiatives/modular-vue-adoption.md,
+// Toolbar contributions from the shared nav manifest (backend/docs/adr/0049-modular-vue-adoption.md,
 // slice 1). First-party contributes none — this is the reactive extension point a consumer
 // deployment uses to add a board-toolbar action via `registerAppModule`, gated + rendered like
 // the sidebar/command entries with zero edits here.

package/app/components/layout/CommandBar.vue

@@ -26,7 +26,7 @@ const library = useFragmentLibraryStore()
 const access = useWorkspaceAccess()
 
 // The static destination catalog + its RBAC/availability gating now comes from
-// the shared nav manifest (docs/initiatives/modular-vue-adoption.md, slice 1),
+// the shared nav manifest (backend/docs/adr/0049-modular-vue-adoption.md, slice 1),
 // rendered here as command entries. The DYNAMIC per-connection commands below
 // (github/slack/doc/task connect + import) stay local to the palette — they vary
 // per live connection, so they are not part of the static manifest this slice.

package/app/components/layout/SideBar.vue

@@ -31,7 +31,7 @@ const providerConnections = useProviderConnectionsStore()
 const ui = useUiStore()
 
 // The nav catalog + its reactive RBAC/availability gating now lives in the shared
-// modular-vue manifest (docs/initiatives/modular-vue-adoption.md, slice 1): every
+// modular-vue manifest (backend/docs/adr/0049-modular-vue-adoption.md, slice 1): every
 // destination is declared once in `nav-contributions.ts`, gated by `navSlotFilter`
 // over a reactive `gates` service, and rendered here (and in CommandBar / BoardToolbar)
 // from `useReactiveSlots`. Sections + items appear/disappear reactively as a permission
@@ -230,7 +230,7 @@ watch(
       </button>
 
       <!-- Sections + items come from the shared nav manifest, already gated by the
-         reactive slotFilter (docs/initiatives/modular-vue-adoption.md, slice 1) — which
+         reactive slotFilter (backend/docs/adr/0049-modular-vue-adoption.md, slice 1) — which
          also drops the `advanced` items in basic interface mode. An empty section is
          dropped upstream, so there is no per-section `v-if` here.
          In the rail the section HEADERS go (they'd wrap to nothing at 3.5rem) but the

package/app/components/merge/MergeEffortChips.vue

@@ -6,7 +6,7 @@
 // Tagging is never mandatory: the parent can always act without a selection, and an untagged
 // merge records a null tag. This component only chooses; the parent performs the action.
 //
-// See docs/initiatives/merge-track-record.md.
+// See backend/docs/adr/0046-merge-track-record.md.
 import { computed } from 'vue'
 import { REVIEW_EFFORTS } from '@cat-factory/contracts'
 import type { ChangeClass, MergeClassRollup, ReviewEffort } from '~/types/merge'

package/app/components/panels/InspectorPanel.vue

@@ -524,7 +524,7 @@ const showOriginalDescription = ref(false)
            `Block | null` is rejected at compile time. `unknown` is the real
            runtime contract; `as any` is the minimal unblock until the binding
            types the prop explicitly (filed upstream — see the slice-4 residuals
-           in docs/initiatives/modular-vue-slice4-upstream-zones.md). -->
+           in backend/docs/adr/0049-modular-vue-adoption.md). -->
       <PanelsOutlet
         :group="inspectorPanels"
         :subject="(block ?? null) as any"

package/app/components/panels/ResultWindowShell.vue

@@ -1,7 +1,7 @@
 <script setup lang="ts">
 // Shared modal shell for the agent-run result windows (slice 5 of the modular-vue
-// adoption — docs/initiatives/modular-vue-adoption.md; progress in
-// docs/initiatives/modular-vue-slice5-progress.md).
+// adoption — backend/docs/adr/0049-modular-vue-adoption.md; progress in
+// backend/docs/adr/0049-modular-vue-adoption.md).
 //
 // Every result window (the merger verdict, the tester report, the requirements-review
 // loop, the gates, …) used to hand-roll the SAME modal chrome — `<Teleport>`, a

package/app/components/panels/StepResultViewHost.vue

@@ -1,6 +1,6 @@
 <script setup lang="ts">
 // Universal dedicated-result-view host (slice 2 of the modular-vue adoption —
-// docs/initiatives/modular-vue-adoption.md). An agent archetype can declare a
+// backend/docs/adr/0049-modular-vue-adoption.md). An agent archetype can declare a
 // `resultView` id (see `~/utils/catalog`); when a step of that kind is opened,
 // `ui.resultView` is set and this host mounts the matching registered window
 // instead of the generic `AgentStepDetail` prose panel.

package/app/components/panels/inspector/TaskRunSettings.vue

@@ -195,7 +195,7 @@ function setResolveOnMerge(value: WritebackOverride | null) {
   board.updateBlock(props.block.id, { trackerResolveOnMerge: value })
 }
 // Only consulted for runs started through the public API — a task started here keeps its in-app
-// clarification window regardless (docs/initiatives/headless-clarification-loop.md).
+// clarification window regardless (backend/docs/adr/0047-headless-clarification-loop.md).
 function setQuestionsOnPark(value: WritebackOverride | null) {
   board.updateBlock(props.block.id, { trackerQuestionsOnPark: value })
 }

package/app/components/settings/MergeClassRulesEditor.vue

@@ -6,7 +6,7 @@
 //
 // `unknown` is deliberately not listed: no rule may ever match it (an unclassifiable diff must
 // fall back to the score ceilings), so offering one would be a lie. See
-// docs/initiatives/merge-track-record.md.
+// backend/docs/adr/0046-merge-track-record.md.
 import { computed } from 'vue'
 import { autoMergeShare, frictionlessShare, RULEABLE_CHANGE_CLASSES } from '@cat-factory/contracts'
 import type { MergeClassRule, MergeClassRules } from '~/types/merge'

package/app/modular/agent-kinds.ts

@@ -2,7 +2,7 @@ import type { AgentArchetype, CustomAgentKind } from '~/types/domain'
 
 /**
  * Custom agent-kind projection (slice 2 of the modular-vue adoption —
- * docs/initiatives/modular-vue-adoption.md).
+ * backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * A deployment's BACKEND-registered agent kinds arrive in the workspace snapshot as
  * `customAgentKinds` (wire data), folded into the shared per-workspace capability manifest

package/app/modular/journeys/environmentSetup.logic.ts

@@ -1,6 +1,6 @@
 /**
  * Pure navigation logic for the environment-setup journey (slice 3 of the
- * modular-vue adoption — docs/initiatives/modular-vue-adoption.md).
+ * modular-vue adoption — backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * The journey owns only the WIZARD NAVIGATION — the ordered steps
  * (pick → review → preflight → save), the forward transitions, and the

package/app/modular/journeys/environmentSetup.ts

@@ -18,7 +18,7 @@ import {
 
 /**
  * The environment-setup journey — the slice-3 pilot of the modular-vue adoption
- * (docs/initiatives/modular-vue-adoption.md). It replaces the wizard's hand-rolled
+ * (backend/docs/adr/0049-modular-vue-adoption.md). It replaces the wizard's hand-rolled
  * `STEP_ORDER` + `step` ref + `goToStep` navigation (in `stores/environmentWizard.ts`)
  * with a typed, back/rewind-capable, resumable journey; the per-step data + async
  * actions stay in that Pinia store, driven by the step components below.

package/app/modular/journeys/persistence.ts

@@ -5,7 +5,7 @@ import { createPiniaJourneyPersistence } from '@modular-vue/journeys'
 
 /**
  * Pinia-backed journey persistence (slice 3 of the modular-vue adoption —
- * docs/initiatives/modular-vue-adoption.md).
+ * backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * A journey's `persistence` adapter is what makes `runtime.start()` mean
  * RESUME: it probes `keyFor(input)` for an in-flight serialized instance and

package/app/modular/nav-contributions.ts

@@ -10,7 +10,7 @@ export type { AppSlots } from './slots'
 
 /**
  * The single nav/command catalog for the layer (slice 1 of the modular-vue
- * adoption — docs/initiatives/modular-vue-adoption.md).
+ * adoption — backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * Every destination is declared ONCE here as data and rendered three ways —
  * `SideBar`, `CommandBar`, `BoardToolbar` — instead of each shell hand-rolling

package/app/modular/panels/inspector.logic.ts

@@ -3,7 +3,7 @@ import type { Block } from '~/types/domain'
 
 /**
  * Pure definition of the block-inspector panel group (slice 4 of the modular-vue
- * adoption — docs/initiatives/modular-vue-adoption.md).
+ * adoption — backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * The inspector used to be a 631-line `v-if` fan in `InspectorPanel.vue` that
  * switched its body on the selected block's `level` (frame/module/task/epic/

package/app/modular/registry.ts

@@ -8,7 +8,7 @@ import type { AppSlots } from '~/modular/slots'
 
 /**
  * modular-vue registry for the `@cat-factory/app` layer (slice 0 of the
- * modular-vue adoption — docs/initiatives/modular-vue-adoption.md).
+ * modular-vue adoption — backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * This is the frontend analogue of the backend's public registries
  * (`registerAgentKind`, `registerGate`): a single registry into which the layer

package/app/modular/result-views.ts

@@ -25,7 +25,7 @@ import type { ResultViewContribution } from './slots'
 
 /**
  * The first-party result-view registry (slice 2 of the modular-vue adoption —
- * docs/initiatives/modular-vue-adoption.md).
+ * backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * Every built-in dedicated result window is contributed as a `ComponentEntry`
  * to the `resultViews` slot instead of living in a hardcoded `Record` in

package/app/modular/slots.ts

@@ -10,7 +10,7 @@ import type { WorkspaceMetadataFieldDefinition } from './workspace-metadata'
  * The layer's aggregated slot map — the single home for every slot key the
  * first-party modules (and consumer deployments) contribute to. Grows one key
  * per converted seam as the modular-vue adoption proceeds
- * (docs/initiatives/modular-vue-adoption.md):
+ * (backend/docs/adr/0049-modular-vue-adoption.md):
  *
  *  - `nav` (slice 1) — the nav/command catalog, rendered by the three shells.
  *  - `resultViews` (slice 2) — the id → dedicated result-window registry

package/app/plugins/modular.client.ts

@@ -20,7 +20,7 @@ import type { Block, CustomAgentKind, CustomTaskType } from '~/types/domain'
 
 /**
  * Wire the modular-vue registry into the Nuxt app (slice 0 of the modular-vue
- * adoption — docs/initiatives/modular-vue-adoption.md).
+ * adoption — backend/docs/adr/0049-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

package/app/stores/agents.ts

@@ -16,7 +16,7 @@ import type { AgentArchetype, AgentKind, AgentKindVariant, CustomAgentKind } fro
 
 /**
  * The agent palette catalog (slice 2 of the modular-vue adoption —
- * docs/initiatives/modular-vue-adoption.md).
+ * backend/docs/adr/0049-modular-vue-adoption.md).
  *
  * Reactive union of three sources, none of which mutates the frozen built-in
  * {@link AGENT_BY_KIND} const any more:

package/app/stores/environmentWizard.ts

@@ -33,7 +33,7 @@ import { createSaveActions } from '~/stores/environmentWizard/save'
 // compose provider keys purely on the saved recipe (the build-flag rule). Mirrors the other infra
 // stores' idiom; the flow state is a singleton so the wizard's step children share it.
 //
-// Since slice 3 of the modular-vue adoption (docs/initiatives/modular-vue-adoption.md) the wizard's
+// Since slice 3 of the modular-vue adoption (backend/docs/adr/0049-modular-vue-adoption.md) the wizard's
 // step NAVIGATION lives in a modular-vue journey (`app/modular/journeys/environmentSetup.ts`), NOT
 // here — this store no longer holds a `step` / `STEP_ORDER` / `goToStep`. It is purely the per-frame
 // data+action layer the journey's step components drive; `beginForFrame` seeds it when a step first

package/app/stores/publicApiKeys.spec.ts

@@ -13,6 +13,7 @@ function key(over: Partial<PublicApiKey> = {}): PublicApiKey {
     scope: 'write',
     createdByUserId: null,
     createdByKeyId: null,
+    externalIdentity: null,
     createdAt: 1,
     lastUsedAt: null,
     revokedAt: null,

package/app/utils/modular.ts

@@ -6,6 +6,6 @@
  * 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.
+ * backend/docs/adr/0049-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.247.0",
+  "version": "0.248.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",
@@ -40,7 +40,7 @@
     "valibot": "^1.4.2",
     "vue": "3.5.40",
     "wretch": "^3.0.9",
-    "@cat-factory/contracts": "0.269.0"
+    "@cat-factory/contracts": "0.270.0"
   },
   "devDependencies": {
     "@toad-contracts/testing": "0.3.2",