@opencxh/domain 1.264.0 → 1.264.4

package/dist/entities/ai-account/capabilities.d.ts

@@ -0,0 +1,60 @@
+/**
+ * What an AI account can be the default for — one list, and everything else is derived from it.
+ *
+ * There were three, and they had to agree without anything enforcing it: `AiCapability`
+ * (llm/stt/tts/embedding) for the account flags, `AiVendorCapability`
+ * (chat/transcription/embedding) for what a vendor claims, and `UsageCapability` (the same three
+ * again) for the usage row. `llm` and `chat` were the same thing under two names, and `tts`
+ * existed in exactly one of the three. Adding a capability meant editing a fan-out of five
+ * places plus a form and a table, which is the drift this catalog exists to stop.
+ *
+ * `id` is the name used everywhere: the adapter key in `providers/registry`, the value of the
+ * `ai.capability` analytics dimension, and what a vendor declares. It is therefore part of the
+ * stored format — the usage rollup holds these strings — and must not be renamed casually.
+ *
+ * `defaultFlag` is the metadata key on the managed-account record. It keeps the older `Llm`/`Stt`
+ * spelling on purpose: those are stored keys, and renaming them buys nothing a reader needs.
+ */
+export interface AiCapabilityDefinition {
+    id: string;
+    /** Metadata key on the account record that marks it as the default for this capability. */
+    defaultFlag: string;
+    /** Column and checkbox label in the accounts screen. */
+    label: string;
+}
+export declare const AI_CAPABILITIES: readonly [{
+    readonly id: "chat";
+    readonly defaultFlag: "isDefaultLlm";
+    readonly label: "LLM";
+}, {
+    readonly id: "transcription";
+    readonly defaultFlag: "isDefaultStt";
+    readonly label: "STT";
+}, {
+    readonly id: "tts";
+    readonly defaultFlag: "isDefaultTts";
+    readonly label: "TTS";
+}, {
+    readonly id: "embedding";
+    readonly defaultFlag: "isDefaultEmbedding";
+    readonly label: "Embeddings";
+}];
+/** What an account can be the default for, and what a vendor can claim. One vocabulary. */
+export type AiCapability = (typeof AI_CAPABILITIES)[number]["id"];
+/** The metadata keys, as a union — so a flags object can be typed rather than indexed. */
+export type AiDefaultFlag = (typeof AI_CAPABILITIES)[number]["defaultFlag"];
+/** `{ isDefaultLlm: boolean, … }`, derived. Adding a capability adds its field here too. */
+export type AiDefaultFlags = {
+    [K in AiDefaultFlag]: boolean;
+};
+export declare function capabilityDefaultFlag(capability: AiCapability): AiDefaultFlag;
+/** Read the flags off a stored metadata bag, in one place instead of four literal lines. */
+export declare function readDefaultFlags(meta: Record<string, unknown> | undefined): AiDefaultFlags;
+/**
+ * `patch ?? current` per flag, for a partial update.
+ *
+ * A plain spread cannot do this: an absent key in the patch arrives as `undefined` and would
+ * overwrite the stored value with "not the default" — the difference between "leave it alone"
+ * and "turn it off".
+ */
+export declare function mergeDefaultFlags(patch: Partial<AiDefaultFlags> | undefined, current: Partial<AiDefaultFlags> | undefined): AiDefaultFlags;

package/dist/entities/ai-account/capabilities.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/entities/ai-account/index.d.ts

@@ -1,2 +1,3 @@
+export * from './capabilities';
 export * from './types';
 export * from './vendors';

package/dist/entities/ai-account/vendors.d.ts

@@ -1,18 +1,9 @@
+import { AiCapability } from './capabilities';
 /**
- * The AI vendors the ai app has an adapter for.
- *
- * One source for both the UI (account form, table labels) and the server (default model, API
- * host). Those lists used to be separate and drifted apart — the UI named vendors no adapter
- * existed for.
- *
- * This catalog describes *what* a vendor is. *How* you talk to it (which adapter class, which
- * model filter) lives server-side in `providers/registry`, which answers to this list: a vendor
- * claiming `"chat"` here without a chat adapter there is a test failure.
- *
- * `id` is what ends up in `AiAccount.vendor`, so that string is part of the storage format and
- * must not be renamed casually.
+ * What a vendor can do. Was its own union of three; it is the same vocabulary the account
+ * defaults and the usage rows use, so it now names {@link AiCapability} instead of repeating it.
  */
-export type AiVendorCapability = "chat" | "transcription" | "embedding";
+export type AiVendorCapability = AiCapability;
 export interface AiVendor {
     id: string;
     label: string;
@@ -28,9 +19,9 @@ export interface AiVendor {
     /**
      * Which attachment kinds this vendor accepts directly.
      *
-     * Deliberately not a value in `capabilities`: `findAdapterGaps()` maps every capability it does
-     * not know to `"embedding"`, so a vendor claiming `"attachments"` there would be reported as a
-     * missing embedding adapter.
+     * Deliberately not a value in `capabilities`: that list is the capability catalog, and an
+     * adapter either exists for an entry or `findAdapterGaps()` says so. "Accepts images" is a
+     * property of a vendor, not something you build an adapter for.
      *
      * Absent or empty = text only. The right default for the Chat Completions vendors: they share one
      * adapter but not one set of capabilities, and a guess yields a 400 mid-conversation.

package/dist/entities/memory/ingest.d.ts

@@ -1,4 +1,4 @@
-import { MemoryKindId, MemoryLink, MemorySubjectKey } from './item';
+import { MemoryKindId, MemorySubjectKey } from './item';
 /**
  * Writing is a **CAS upsert**, not a snapshot replace like analytics.
  *
@@ -28,7 +28,6 @@ export interface MemoryUpsertRequest {
     /** Omit it: the hub extracts keywords from title + body itself (one tokenizer, write and read). */
     keywords?: string[];
     tags?: string[];
-    links?: MemoryLink[];
 }
 export type MemoryUpsertRejection = "stale-version" | "stale-watermark" | "unknown-kind" | "kind-disabled" | "subject-kind-mismatch" | "not-owner";
 export interface MemoryUpsertResult {

package/dist/entities/memory/item.d.ts

@@ -9,17 +9,6 @@
 export type MemorySubjectKey = string;
 /** `comms.resolution` (app-declared) or `sales_besluitvormer` (org-owned). */
 export type MemoryKindId = string;
-/**
- * A reference to something else — internal (`interaction:i_2`) or external (`hubspot:5591`,
- * `clickup:86ab2`).
- *
- * A **list**, never an object keyed by the relation: **the same `rel` may occur twice** — two
- * linked companies, three involved interactions — and a map would throw one away.
- */
-export interface MemoryLink {
-    rel: string;
-    target: string;
-}
 /** Hard limit on the body. Memory is a summary; it is not a shadow copy of a mailbox. */
 export declare const MAX_MEMORY_CHARS = 2000;
 export interface MemoryItem {
@@ -91,7 +80,6 @@ export interface MemoryItem {
     keywords?: string[];
     /** Fast alternative keys, e.g. `tel:+31612345678` for the moment the phone rings. */
     tags?: string[];
-    links?: MemoryLink[];
     /** Model the vector was made with; retrieval only compares within the same model. */
     embeddingModel?: string;
     /** From a live pull (phase 3); never persisted. */