@opencxh/domain 1.154.0 → 1.159.0

package/dist/entities/activity/catalog.d.ts

@@ -51,6 +51,18 @@ interface ActivityTypeInfo<T extends ActivityType = ActivityType> {
     carriesText?: boolean;
     /** Door de engine zelf geschreven; mag geen nieuwe playbook-run openen. */
     playbookAuthored?: boolean;
+    /**
+     * Betekent dit type dat er daadwerkelijk contact tot stand kwam — dat er gesproken is?
+     *
+     * Nodig omdat "is hier echt iets uitgewisseld" niet uit berichten alleen te bepalen valt: een
+     * aangenomen telefoongesprek is een volwaardige casus met nul berichten, en een gemiste oproep
+     * is het tegenovergestelde. Een eigen vlag en niet afgeleid van `shape`, want beide zijn
+     * `event` — het verschil zit in de betekenis, niet in de vorm.
+     *
+     * Bewust hier en niet als lijstje in de app die de vraag stelt: dat is precies hoe "is dit een
+     * bericht?" zes keer los kwam te staan.
+     */
+    connected?: boolean;
     /**
      * Verschijnt in de trigger-keuzelijst van playbooks en webhooks.
      *
@@ -96,9 +108,17 @@ export declare function activityIconOf(type: string): string;
 /** `mail` | `chat` | `voice` | `video`, of `undefined` voor een levenscyclus-event. */
 export declare function channelKindOf(type: string): ActivityChannelKind | undefined;
 /**
- * Draagt dit type een bericht of een interne notitie — iets wat een mens schreef en wat
- * als "het gesprek" telt? Sluit transcripten uit; die zijn wel tekst, maar geen bericht.
+ * Draagt deze vorm een bericht of een interne notitie — iets wat een mens schreef en wat als
+ * "het gesprek" telt? Sluit transcripten uit; die zijn wel tekst, maar geen bericht.
+ *
+ * Op de **shape** en niet op het type, zodat er precies één definitie van "is dit een
+ * bericht" bestaat. {@link isMessageType} beantwoordt hem voor de ingebouwde types;
+ * `ActivityTypeRegistry.isMessage` doet hetzelfde voor een type dat een app declareerde.
+ * Zonder die splitsing had elk van beide zijn eigen kopie van de regel gekregen — en dat is
+ * precies hoe er twaalf hardgecodeerde typelijstjes door de codebase zijn ontstaan.
  */
+export declare function isMessageShape(shape: ActivityShape | undefined): boolean;
+/** Zie {@link isMessageShape}. Voor de ingebouwde types. */
 export declare function isMessageType(type: string): boolean;
 /** Kan een mens hierop antwoorden? Notities niet — die gaan nergens heen. */
 export declare function isReplyableType(type: string): boolean;
@@ -111,6 +131,17 @@ export declare function carriesText(type: string): boolean;
 export declare function messageCountsAs(type: string): "inbound_message" | "outbound_message" | undefined;
 /** Door de playbook-engine zelf geschreven; mag geen nieuwe run openen. */
 export declare function isPlaybookAuthoredType(type: string): boolean;
+/** Kwam er met dit type daadwerkelijk contact tot stand? Zie {@link ActivityTypeInfo.connected}. */
+export declare function isConnectedType(type: string): boolean;
+/**
+ * Is dit een transcript-achtig artefact — meegeleverde inhoud die leesbare tekst draagt?
+ *
+ * Het onderscheid met een bestand zit al in de catalogus (`FILE_UPLOADED` draagt geen tekst), dus
+ * dit is geen nieuwe lijst maar een combinatie van twee bestaande antwoorden. Zo telt het
+ * transcript van een externe provider mee zodra die app zijn type declareert, zonder dat hier een
+ * naam bij hoeft.
+ */
+export declare function isTranscriptType(type: string): boolean;
 /** De inboxlijst-regel, of `""` wanneer het type er geen heeft. */
 export declare function activitySnippet(activity: Activity): string;
 /**

package/dist/entities/activity/resolve.d.ts

@@ -57,6 +57,30 @@ export declare class ActivityTypeRegistry {
     descriptor(type: string): ActivityTypeDescriptor | undefined;
     /** De declaratieve blokken van een type, als het er heeft. */
     blocks(type: string): ActivityBlock[] | undefined;
+    /**
+     * Dezelfde semantische vragen als de losse accessors in `catalog.ts`, maar dan óók voor
+     * types die een app declareerde.
+     *
+     * Dat verschil is de reden dat deze methodes bestaan. `isMessageType(type)` leest alleen
+     * `ACTIVITY_CATALOG`, dus een gedeclareerd type met `shape: "message"` gaf daar `false` —
+     * een helpdesk-app kon een berichtsoort meebrengen die vervolgens niet meetelde als
+     * gesprek, niet antwoordbaar was en niet in de analytics landde. Wie een registry bij de
+     * hand heeft, hoort deze te gebruiken; wie er geen heeft valt terug op de ingebouwde.
+     *
+     * De regel zelf staat maar op één plek: {@link isMessageShape} en de velden van
+     * {@link ResolvedActivityType}.
+     */
+    isMessage(type: string): boolean;
+    /** Kan een mens hierop antwoorden? Notities niet — die gaan nergens heen. */
+    isReplyable(type: string): boolean;
+    /** Leesbare inhoud voor een model: berichten, notities én transcripten. */
+    carriesText(type: string): boolean;
+    /** Telt mee als in- of uitgaand bericht in de analytics-rollup. */
+    countsAs(type: string): "inbound_message" | "outbound_message" | undefined;
+    /** `mail` | `chat` | `voice` | `video`, of `undefined` voor een levenscyclus-event. */
+    channelKind(type: string): ActivityChannelKind | undefined;
+    /** Transcript-achtig artefact: meegeleverde inhoud die leesbare tekst draagt. */
+    isTranscript(type: string): boolean;
     /** De vertaler die bij deze registry hoort, voor het oplossen van blokteksten. */
     get translator(): Translate;
 }

package/dist/entities/activity/types.d.ts

@@ -165,9 +165,16 @@ export type FileUploadedPayload = {
     /** Storage FilePointer id, when the file lives in the storage app (download via storage.file.{id}.download). */
     fileId?: string;
 };
+/**
+ * Elke status die `Interaction.status` kan aannemen, `snoozed` inbegrepen. Die ontbrak,
+ * en daardoor had de tijdlijn een gat precies waar hij het meest verrast: parkeren en
+ * wakker worden waren de enige twee statuswissels die geen spoor achterlieten, dus een
+ * gesprek sprong uit en weer in de lijst zonder dat iets vertelde waarom.
+ */
+export type InteractionStatus = "open" | "pending" | "closed" | "snoozed";
 export type InteractionStatusChangedPayload = {
-    fromStatus: "open" | "pending" | "closed";
-    toStatus: "open" | "pending" | "closed";
+    fromStatus: InteractionStatus;
+    toStatus: InteractionStatus;
 };
 export type InteractionAssignedPayload = {
     userId: string;
@@ -335,3 +342,39 @@ export type Activity = (BaseActivity & {
     type: "INTERACTION_ASSIGNED";
     payload: InteractionAssignedPayload;
 });
+/**
+ * Een activity van **welk type dan ook**, inclusief een type dat een app declareerde.
+ *
+ * `Activity` is een gesloten unie over de 41 ingebouwde types, en dat is met opzet: alleen zo
+ * weet TypeScript na `activity.type === "EMAIL_RECEIVED"` dat `payload.from` bestaat. Maar
+ * `ACTIVITY_TYPE_AUTHORING.md` nodigt apps uit hun eigen type mee te brengen, en zo'n rij
+ * pást niet in die unie — vandaar de ~40 `as Activity`-casts die door de repo staan.
+ *
+ * Een open tak ín `Activity` lost dat niet op: dan wordt `payload` overal een unie met
+ * `Record<string, unknown>` en verdwijnt precies de versmalling waar de unie voor bestaat.
+ * Daarom een eigen naam. Code die ook gedeclareerde types verwerkt — de feed, de
+ * inboxregel, de analytics-rollup — typeert op `AnyActivity` en vraagt de catalogus wat het
+ * ding is; code die in een payload leest blijft op `Activity` en versmalt.
+ */
+export type AnyActivity = Activity | (BaseActivity & {
+    type: string;
+    payload: Record<string, unknown>;
+});
+/**
+ * Type-guards voor de twee payload-vormen waar de UI rechtstreeks in leest.
+ *
+ * Dit zijn bewust wél typenamen en geen catalogus-vraag. De catalogus beantwoordt *semantiek*
+ * ("is dit een bericht", "welk kanaal") en dat hoort nooit als typelijstje in een component.
+ * Deze twee doen iets anders: ze **versmallen het type**, zodat `activity.payload.from` en
+ * `activity.payload.text` erna bestaan. Een `channelKindOf(...) === "mail"` kan dat niet — die
+ * geeft een boolean terug en TypeScript weet daarna nog steeds niet welke payload er ligt.
+ *
+ * Ze staan hier, naast de union, zodat er één plek is die de namen kent in plaats van een
+ * herhaling per component.
+ */
+export declare function isEmailActivity(activity: Activity): activity is Extract<Activity, {
+    type: "EMAIL_RECEIVED" | "EMAIL_SENT";
+}>;
+export declare function isChatMessageActivity(activity: Activity): activity is Extract<Activity, {
+    type: "CHAT_MESSAGE_SENT" | "CHAT_MESSAGE_RECEIVED";
+}>;

package/dist/entities/ai-conversation/types.d.ts

@@ -1,4 +1,25 @@
+import { AssignmentStatus } from '../assignment/types';
 export type AIConversationVisibility = "shared" | "personal";
+/**
+ * Dat deze draad die van een **agent-opdracht** is, en waar hij bij hoort te verschijnen.
+ *
+ * De draad van een opdracht leeft op `assignment:<id>` en niet op het onderwerp — dat is precies
+ * waarom een opdracht meerdere beurten kan overleven terwijl de mensvragen over hetzelfde gesprek
+ * hun eigen draad houden. Het nadeel was dat er geen enkele ingang naar toe was, behalve de
+ * agentpagina: het werk was er wel, maar niet te zien op de plek waar het over ging.
+ *
+ * Daarom levert `conversation/resolve` de draad van een opdracht ook uit bij de scope van zijn
+ * **onderwerp**, met dit stempel erop. Niet opgeslagen — het is de stand van nu, gelezen bij het
+ * ophalen, precies zoals de status van de opdracht zelf.
+ */
+export interface AIConversationAgentThread {
+    assignmentId: string;
+    /** Het `userId` van de agent die deze opdracht doet. */
+    agentId: string;
+    status: AssignmentStatus;
+    /** De scope waaronder deze draad wordt meegeleverd: het onderwerp van de opdracht. */
+    subjectScopeKey: string;
+}
 /**
  * A single assistant conversation (thread). Grouped into the tools-panel tabs by
  * `scopeKey`; messages, runs and thread-continuity key on the conversation id.
@@ -22,4 +43,9 @@ export interface AIConversation {
     origin: "auto" | "user";
     createdAt: number;
     updatedAt: number;
+    /**
+     * Gezet bij het ophalen, nooit opgeslagen: deze draad hangt aan een agent-opdracht over de
+     * gevraagde scope. Aanwezig = meelezen, niet meepraten (zie {@link AIConversationAgentThread}).
+     */
+    agent?: AIConversationAgentThread;
 }

package/dist/entities/ai-profile/types.d.ts

@@ -8,16 +8,21 @@ export interface AIProfile<T extends Record<string, any> = Record<string, any>>
     organizationId: string;
     /**
      * Who may use this profile. Company-wide (`org`) or bound to a `team`; profiles
-     * are never personal. Optional only during the migration window - the server
-     * defaults new profiles to `org` and backfills existing ones.
+     * are never personal. The server resolves one on create (`normalizeProfileScope`),
+     * so it is always present.
      */
-    ownerScope?: OwnerScope;
+    ownerScope: OwnerScope;
     name: string;
     description?: string;
     accountId: string;
     model: string;
     providerConfig?: T;
-    systemPrompt: string;
+    /**
+     * De basisinstructie van dit brein. Optioneel: een profiel dat alleen tools ontsluit heeft
+     * er geen nodig. Stond hier als verplicht terwijl het schema hem optioneel maakte, waardoor
+     * elke lezer `?? ""` moest schrijven zonder dat het type dat verklaarde.
+     */
+    systemPrompt?: string;
     contextIds?: string[];
     predefinedPrompts?: PredefinedPrompt[];
     /** Namespaced tool names this profile may use (default: none enabled). */
@@ -31,8 +36,16 @@ export interface AIProfile<T extends Record<string, any> = Record<string, any>>
      * which the transform leaves untouched.
      *
      * Under autonomy "suggest", write tools are held for approval; reads run freely.
-     * A tool absent from this list defaults to "write" (safe). Also usable by the
-     * interactive assistant's requiresConfirmation flow.
+     * A tool absent from this list defaults to "write" (safe).
+     *
+     * **Waar dit wél en níet geldt.** Afgedwongen in `playbook/ai/gate.ts`, en daarmee op elke
+     * autonome run (workflow of procedure). De interactieve assistent doet er **niets** mee: daar
+     * bestaat geen bevestigingsstap, en er is ook geen `requiresConfirmation` om aan te haken —
+     * die stond hier als belofte terwijl er nergens een implementatie was. Een `write`-markering
+     * die je met een gesprek in de chat verwacht af te dwingen, doet dus niets.
+     *
+     * Dat is een openstaand gat en geen ontwerpkeuze: een bevestigingsstap in de chat is UI plus
+     * een extra ronde, en hoort een besluit te zijn in plaats van een veld dat stil niets doet.
      */
     toolPolicy?: {
         name: string;

package/dist/entities/ai-settings/types.d.ts

@@ -0,0 +1,27 @@
+/**
+ * Wat een organisatie voor de AI-app als geheel instelt — niet per profiel, niet per gebruiker.
+ *
+ * Eén veld tot nu toe, en dat is met opzet geen `Record<string, unknown>`: een instelling die
+ * niemand kan opnoemen is een instelling die niemand kan vinden.
+ */
+export interface AiOrgSettings {
+    /**
+     * Mag de AI-app meeluisteren met gesprekken (spraak naar tekst)?
+     *
+     * Dit is de knop die er niet was: de AI-app installeren zette transcriptie aan voor élk
+     * gesprek in de organisatie, wat een technische toevalligheid was die als beleid gold.
+     */
+    listeningEnabled?: boolean;
+}
+/**
+ * Mag er meegeluisterd worden?
+ *
+ * **Afwezig = ja**, en dat is hier de juiste kant: de knop is nieuw, en een organisatie die
+ * hem nooit heeft aangeraakt hoort niet plotseling zonder transcriptie te zitten. Uit is dus
+ * een expliciete keuze en niet een lege rij.
+ *
+ * Eén plek, zodat de client (die de upload overslaat) en de server (die hem weigert) niet
+ * ieder hun eigen default kunnen hebben — dan zou de een luisteren terwijl de ander denkt van
+ * niet.
+ */
+export declare function listeningAllowed(settings: AiOrgSettings | null | undefined): boolean;

package/dist/entities/ai-settings/types.test.d.ts

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

package/dist/entities/assignment/index.d.ts

@@ -0,0 +1 @@
+export * from './types';

package/dist/entities/assignment/types.d.ts

@@ -0,0 +1,170 @@
+import { ResourceRef } from '../../platform/resource';
+import { Activity } from '../activity/types';
+import { WaitingOn } from '../playbook/types';
+/**
+ * Een **opdracht**: werk dat aan een agent is toegewezen en zo lang leeft als het werk.
+ *
+ * **Waarom dit een entity is.** Het was er geen: `plans/unify-ai.md` besliste "een opdracht *is*
+ * een run met een procedure, een agent als actor en een lange levensduur". Dat is verdedigbaar
+ * gedacht, en de code liet zien wat het kostte:
+ *
+ * - `resume-playbook.ts` kortte elke procedure-run af op `{ status: "done" }`, dus een opdracht was
+ *   structureel **één modelbeurt**;
+ * - de draad (een `AIConversation` op `playbook-run:<id>`) deelde géén geheugen met de agent:
+ *   `runProcedure` gaf bewust geen `conversationId` mee, dus wat een mens in de draad zei bereikte
+ *   de agent nooit en omgekeerd;
+ * - `retry` betekende "doe de hele opdracht opnieuw vanaf de originele trigger" — zinnig voor een
+ *   workflow van seconden, onzin voor werk dat dagen liep;
+ * - en "wat voor ding is dit" moest uit de *uitvoeringsvorm* worden afgeleid
+ *   (`decider.kind === "procedure"`), dus de vorm deed dienst als producttype.
+ *
+ * Nu is een opdracht wat hij is, en een run wat die is: **één beurt**. De opdracht leeft, de runs
+ * zijn wat hij deed.
+ */
+/**
+ * Waar een opdracht in verkeert.
+ *
+ * Bewust dezelfde woorden als de eindstanden van een run, en bewust minder: een opdracht kan niet
+ * `failed` zijn. Een gefaalde beurt is een gefaalde run — de opdracht staat dan nog open, want er
+ * is niets afgehandeld. Dat verschil is precies waarom dit een eigen vocabulaire is.
+ */
+export type AssignmentStatus = "open" | "waiting" | "done" | "escalated";
+export declare const TERMINAL_ASSIGNMENT_STATUSES: readonly ["done", "escalated"];
+export declare function isAssignmentTerminal(status: AssignmentStatus | string): boolean;
+/**
+ * De scope-soort waaronder de draad van een opdracht leeft.
+ *
+ * Was `playbook-run:<id>`, want de draad hing aan een run. Hij hangt nu aan de opdracht, en dat is
+ * het hele punt: een draad die stopt zodra één beurt klaar is, is geen draad.
+ *
+ * Staat in domain omdat het een **contract tussen client en server** is: de client bouwt de
+ * sleutel om de draad te openen, de server autoriseert hem. Twee plekken die het voorvoegsel los
+ * uitschrijven lopen bij de eerste typefout stil uiteen — en het gevolg daarvan is "geen toegang
+ * tot deze scope", niet een foutmelding die het zegt.
+ */
+export declare const ASSIGNMENT_SCOPE_KIND = "assignment";
+export declare function assignmentScopeKey(assignmentId: string): string;
+export interface Assignment {
+    id: string;
+    organizationId: string;
+    /** De agent die dit doet: het `userId` van een gebruiker met `type: "agent"`. */
+    agentId: string;
+    /** De definitie waar deze opdracht uit voortkomt (een playbook met een procedure). */
+    jobId: string;
+    /**
+     * De versie waarmee hij begon — puur voor de audit.
+     *
+     * Elke **beurt** pint zijn eigen procedure (`run.decider`), dus een verbeterde prose komt bij de
+     * volgende beurt aan zonder een lopende beurt van opdracht te laten wisselen. Eeuwig pinnen zou
+     * betekenen dat een correctie nooit aankomt; niet pinnen dat een beurt halverwege verandert.
+     */
+    jobVersion: number;
+    /** Waar deze opdracht over gaat. Afwezig = werk zonder resource (een rollup, een klus). */
+    subjectKind?: string;
+    subjectId?: string;
+    status: AssignmentStatus;
+    /**
+     * Waarop de **opdracht** wacht tussen twee beurten.
+     *
+     * Bewust hier en niet op de run, want het zijn twee verschillende soorten pauze:
+     *
+     * - een **workflow** pauzeert *midden in een flow* en hervat op stap N+1 met dezelfde vars — de
+     *   cursor (`run.resumeAtStep`) is essentieel;
+     * - een **opdracht** heeft geen cursor. "Hervatten" is *nog een beurt nemen*, met de draad als
+     *   geheugen.
+     *
+     * Dat die twee in één veld geperst zaten is waarom elke procedure-run `resumeAtStep: 0` opsloeg.
+     */
+    waitingOn?: WaitingOn | null;
+    /** De soort van `waitingOn` als platte kolom — de store kan niet in een genest object zoeken. */
+    waitingOnKind?: WaitingOn["on"] | null;
+    /**
+     * Hoeveel beurten deze opdracht al heeft gehad.
+     *
+     * Was `run.rounds`, wat het aantal keer parkeren *binnen één run* telde. Op dit niveau is het de
+     * teller die telt: een agent die met een mens heen en weer blijft pingpongen moet een plafond
+     * hebben.
+     */
+    turns: number;
+    /** De draad: agent én mens schrijven hierin. Dit is de toestand van de opdracht. */
+    conversationId: string;
+    /** Lijst-index, geen autorisatie — zie `PlaybookRun.visibleTo`. */
+    visibleTo?: string[];
+    /** Waar deze opdracht over gaat, in mensentaal. Voor de lijst. */
+    title?: string;
+    /**
+     * Waaróm de opdracht in deze stand staat, als er iets uit te leggen is.
+     *
+     * `decideAssignmentState` rekende dit al uit en niets bewaarde het, dus je zag `escalated` zonder
+     * uitleg — precies de vraag ("waarom heeft hij dit overgedragen?") die dit ontwerp zou moeten
+     * kunnen beantwoorden. De reden van de agent zelf staat hier, en zijn woorden in de draad.
+     */
+    statusReason?: string;
+    createdBy: string;
+    lastActivityAt?: number;
+}
+/**
+ * Wekt deze activity een opdracht die op een antwoord wacht?
+ *
+ * **Twee bronnen, twee regels, en dat verschil is het hele punt.**
+ *
+ * - **De klant antwoordt** (`inbound`): dat wekt altijd. Een klant kan niemand @-noemen, en zijn
+ *   antwoord is per definitie het antwoord waar de opdracht op wachtte.
+ * - **Een collega schrijft een interne notitie**: die wekt **alleen als de agent genoemd is**.
+ *
+ * Die tweede regel is er omdat "elke interne notitie wekt" te grof is: twee collega's die in het
+ * dossier overleggen zouden dan elk een modelbeurt kosten, over iets waar de agent niet bij
+ * gevraagd was — en dat vreet het beurtplafond op aan gesprek dat niet voor hem bedoeld was.
+ *
+ * Een vermelding is precies de vraag die de engine zelf niet kan beantwoorden: *is dit aan míjn
+ * agent gericht?* Dezelfde vorm als {@link assignmentMismatch} bij het toewijzen — expliciet, want
+ * geraden zou stil het verkeerde doen. En het maakt zelf-wekken onmogelijk: een agent noemt
+ * zichzelf niet.
+ */
+export declare function wakesAssignment(activity: Activity, agentId: string): boolean;
+/** Het onderwerp van een opdracht als één verwijzing, of `undefined`. */
+export declare function assignmentSubject(assignment: {
+    subjectKind?: string;
+    subjectId?: string;
+}): ResourceRef | undefined;
+/**
+ * Hoeveel beurten een opdracht mag nemen voordat een mens het overneemt.
+ *
+ * Niet oneindig, want elke beurt is een modelaanroep en een agent kan met de beste bedoelingen
+ * blijven vragen. Bij het plafond escaleert hij, en dat is te zien in de draad — een opdracht die
+ * stil ophoudt zou de vraag "waarom doet hij niets meer" onbeantwoordbaar maken.
+ */
+export declare const MAX_ASSIGNMENT_TURNS = 12;
+/**
+ * Wat een beurt als volgende zet koos. Dit is wat de control-tools vastleggen.
+ *
+ * Eén union, want de vier uitkomsten sluiten elkaar uit: je wacht op iets, je bent klaar, of je
+ * geeft het over aan een mens.
+ */
+export type AssignmentControl = {
+    kind: "wait";
+    on: WaitingOn;
+} | {
+    kind: "done";
+    note?: string;
+} | {
+    kind: "escalate";
+    reason: string;
+};
+/**
+ * Waar de opdracht na deze beurt in verkeert.
+ *
+ * Puur, zodat de regel op één plek staat en zonder Bridge te testen is — dezelfde vorm als
+ * `decideFinalState` voor een run.
+ *
+ * **Geen control-call betekent escaleren**, niet stil openblijven. Dat is de regel die
+ * `decideFinalState` al toepast op een run die wacht zonder geldige reden ("liever luid falen dan
+ * stil parkeren"): een agent die zijn beurt afmaakt zonder te zeggen wat hij wil, laat een mens
+ * met een opdracht zitten waarvan niemand weet of er nog iets gebeurt.
+ */
+export declare function decideAssignmentState(control: AssignmentControl | undefined, turnsSoFar: number, maxTurns?: number): {
+    status: AssignmentStatus;
+    waitingOn: WaitingOn | null;
+    turns: number;
+    reason?: string;
+};

package/dist/entities/assignment/types.test.d.ts

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

package/dist/entities/interaction/types.d.ts

@@ -1,5 +1,5 @@
 import { InteractionParticipant } from '../../platform/communication';
-import { ActivityType } from '../activity/types';
+import { ActivityType, InteractionStatus } from '../activity/types';
 export interface ActivityPreview {
     activityId: string;
     /** Ook een door een app gedeclareerd type; de union houdt alleen de autocomplete. */
@@ -77,7 +77,9 @@ export interface Interaction {
      */
     channelUriKey?: string;
     title: string;
-    status: "open" | "pending" | "closed" | "snoozed";
+    /** Eén definitie, gedeeld met `INTERACTION_STATUS_CHANGED`, zodat de tijdlijn elke
+     *  overgang kan vastleggen die dit veld kan maken. */
+    status: InteractionStatus;
     /**
      * UX-shape van de interactie. "thread" = email-stijl met aparte replyable
      * berichten (inline reply per activity). "conversation" = chat-stijl met

package/dist/entities/live-lens/index.d.ts

@@ -0,0 +1 @@
+export * from './types';

package/dist/entities/live-lens/types.d.ts

@@ -0,0 +1,81 @@
+import { OwnerScope } from '../contact/types';
+import { ConditionStep, ForEachStep, LookupStep, ParallelStep, Step } from '../playbook/types';
+/**
+ * Een **leesbaan**: wat er meeleest tijdens een levend gesprek, en aan wie het iets toont.
+ *
+ * **Waarom dit een eigen entity is en geen playbook met een `stream`-trigger.** Dat was het:
+ * `PlaybookTrigger` had een arm `{ kind: "stream" }` met opzet zonder velden, en zo'n rij deed
+ * daarna niets van wat een playbook doet — geen run, geen job, geen lock, geen goedkeuringspoort,
+ * geen `finalizeRun`. `live-assist` bouwde met de hand een `RunContext` en riep `executeFlow`
+ * direct aan.
+ *
+ * De prijs stond in de velden: `autonomy`, `agentId`, `procedure`, `stats`, `lastRunAt` en
+ * `debounceMs` waren voor zo'n rij allemaal betekenisloos, en `steps` mocht maar vier van de tien
+ * staptypes bevatten. Iedere lezer van `Playbook` moest dus impliciet weten of hij naar een
+ * automatisering of naar een leesbaan keek, met twee functies in domain als vangnet en een
+ * tabel-scan-plus-cache als selectie.
+ *
+ * Definities horen gescheiden te zijn naar hun **runtime**, niet naar hun editor. Een leesbaan
+ * heeft geen run, dus is het geen playbook.
+ *
+ * Wat hij deelt met een playbook is de **staptaal** en de executor — niet de tabel.
+ */
+/**
+ * Wat een leesbaan mag doen: opzoeken, kiezen, en dat desnoods parallel of per item.
+ *
+ * Dit is een **echt subtype** van {@link Step} en geen lijst met toegestane namen. Alles wat
+ * schrijft (`action`), een model kost (`classify`, `generate`, `agent`) of kan pauzeren
+ * (`wait-for-*`) valt erbuiten — en pauzeren kán hier ook niet, want er is geen rij om op te
+ * hervatten.
+ *
+ * Dat het een type is en geen controle is de winst: een leesbaan die zou schrijven is nu een
+ * typefout bij het bouwen, in plaats van een validatie die pas bij het opslaan (of erger: bij de
+ * eerste ronde, tijdens een telefoongesprek) iets zegt.
+ *
+ * Wie tijdens een gesprek iets wíl laten schrijven, doet dat met een playbook op een
+ * `activity`-trigger. Die heeft een run, een eigenaar en een goedkeuringspoort.
+ */
+export type ReadStep = LookupStep | ConditionStep | ForEachStep<ReadStep> | ParallelStep<ReadStep>;
+/** De staptypes die een leesbaan mag bevatten — de runtime-tegenhanger van {@link ReadStep}. */
+export declare const READ_STEP_TYPES: readonly string[];
+export interface LiveLens {
+    id: string;
+    organizationId: string;
+    /** Voor wie deze baan loopt. De werkmodus selecteert de team-banen; zie {@link selectLenses}. */
+    ownerScope: OwnerScope;
+    name: string;
+    description?: string;
+    enabled: boolean;
+    /** Wat er opgezocht wordt. Alleen lezen — zie {@link ReadStep}. */
+    steps: ReadStep[];
+    createdBy: string;
+}
+/**
+ * Waarom deze stappenlijst geen leesbaan mag zijn, of `null` als hij het mag.
+ *
+ * Nodig ondanks {@link ReadStep}, want een `POST` levert JSON en daar helpt een type niet: dit is
+ * de poort bij het **opslaan**. Hij draaide voorheen bij élke ronde, elke acht seconden per lopend
+ * gesprek, om een eigenschap te controleren die bij het opslaan al vaststond.
+ *
+ * Een reden en geen boolean, omdat een geweigerde baan anders stil niets doet — precies de klasse
+ * fout die "ik heb hem aangezet en er komt niets" onbeantwoordbaar maakt.
+ */
+export declare function readStepError(steps: readonly Step[]): string | null;
+/**
+ * De leesbanen die bij déze medewerker op dít moment horen.
+ *
+ * De werkmodus is wat een team-baan selecteert: zonder die keuze zouden bij iemand die in Sales
+ * én Support zit beide baansets tegelijk meelezen — het probleem waarvoor de werkmodus bestaat.
+ * Persoonlijke en org-brede banen staan er los van.
+ *
+ * Merk op dat de *acting identity* van een ronde altijd de medewerker zelf is, ook bij een team-
+ * of org-brede baan: hij ziet tijdens zijn eigen gesprek nooit meer dan hij mag zien. De eigenaar
+ * bepaalt hier alleen wélke banen er lopen.
+ *
+ * Geen `skipped`-uitkomst meer: die bestond om een baan te melden die niet mocht meelezen, en dat
+ * kan niet meer bestaan — `readStepError` weigert hem bij het opslaan.
+ */
+export declare function selectLenses<T extends Pick<LiveLens, "enabled" | "ownerScope">>(lenses: readonly T[], lens: {
+    userId: string;
+    teamId?: string;
+}): T[];

package/dist/entities/live-lens/types.test.d.ts

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

package/dist/entities/playbook/actor.d.ts

@@ -9,6 +9,26 @@ import { OwnerScope } from '../contact/types';
  * functie is die vertaling, en de enige plek waar hij hoort.
  */
 export declare function playbookActor(scope: OwnerScope): ActingIdentity;
+/**
+ * Namens wie deze run handelt.
+ *
+ * **Twee verschillende vragen, en dat is de hele reden dat deze functie naast
+ * {@link playbookActor} bestaat:**
+ *
+ * - *wie handelt* — de agent, als er één is aangewezen;
+ * - *wie mag dit beheren* — `ownerScope`, en dat blijft van mensen.
+ *
+ * Die twee op één veld laten leunen leek aantrekkelijk, want een agent is een gebruiker en
+ * `ownerScope: { kind: "personal", userId }` levert precies de juiste actor op. Maar
+ * `ownerScope` bepaalt óók wie mag bewerken, en dan kon geen enkel mens de playbook van een
+ * agent nog aanpassen — de agent zelf logt immers nooit in.
+ *
+ * Zonder `agentId` verandert er niets: dan is de actor die van de scope, precies zoals eerst.
+ */
+export declare function runActor(playbook: {
+    agentId?: string | null;
+    ownerScope: OwnerScope;
+}): ActingIdentity;
 /**
  * Stabiele sleutel om actors te groeperen. Tien playbooks van hetzelfde team horen
  * één autorisatie-call te kosten, niet tien.