@opencxh/domain 1.160.0 → 1.162.0

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

@@ -106,22 +106,27 @@ export interface Assignment {
 /**
  * Wekt deze activity een opdracht die op een antwoord wacht?
  *
- * **Twee bronnen, twee regels, en dat verschil is het hele punt.**
+ * **Vier regels, van hard naar zacht.**
  *
- * - **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**.
+ * 1. **De klant antwoordt** (`inbound`): wekt altijd. Een klant kan niemand @-noemen, en zijn
+ *    antwoord is per definitie het antwoord waar de opdracht op wachtte.
+ * 2. **De agent zelf schreef dit**: nooit. Zonder deze poort is de vraag die de agent stelt het
+ *    signaal waarop hij wakker wordt — een lus die pas bij het beurtplafond stopt.
+ * 3. **De agent is genoemd**: wekt, ongeacht waarop hij wacht. Een vermelding is de expliciete
+ *    vraag die de engine zelf niet kan beantwoorden: *is dit aan míjn agent gericht?*
+ * 4. **Een interne notitie terwijl hij op een antwoord wacht** (`waitingOn === "reply"`): wekt.
  *
- * 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.
+ * Regel 4 is nieuw en vervangt "alleen als hij genoemd is" voor dit ene geval. **Als een agent
+ * expliciet om een antwoord heeft gevraagd, ís het volgende wat een collega schrijft dat antwoord** —
+ * dan iemand dwingen zijn eigen agent te @-noemen op de vraag die die agent net zelf stelde is een
+ * ritueel, niet een signaal. De oude vrees ("twee collega's die overleggen kosten elk een beurt")
+ * blijft gedekt door de rand eromheen: `waitingOn` moet `"reply"` zijn, en zodra hij op een taak
+ * wacht of nog bezig is, is de vermelding weer de enige weg naar binnen.
  *
- * 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.
+ * @param waitingOn Waarop de opdracht wacht. Weggelaten = alleen de regels 1-3 (het gedrag van
+ *                  vóór regel 4), zodat een beller die het niet weet nooit te ruim wekt.
  */
-export declare function wakesAssignment(activity: Activity, agentId: string): boolean;
+export declare function wakesAssignment(activity: Activity, agentId: string, waitingOn?: WaitingOn["on"]): boolean;
 /** Het onderwerp van een opdracht als één verwijzing, of `undefined`. */
 export declare function assignmentSubject(assignment: {
     subjectKind?: string;

package/dist/entities/custom-field-def/types.d.ts

@@ -1,4 +1,17 @@
-export type CustomFieldType = "text" | "select";
+/**
+ * De soorten aangepaste velden.
+ *
+ * Begon als `text | select`, want dat was alles wat een gesprek nodig had. Werkitems vragen
+ * er meer: een dealwaarde moet als bedrag getoond worden, een doorlooptijd als duur, en een
+ * klant als verwijzing naar het bedrijvenregister in plaats van als vrije tekst.
+ *
+ * Bewust **geen** `multi_select`: {@link CustomFieldDef.multiValued} bestaat al, wordt al
+ * opgeslagen en betekent precies dat. Twee manieren om één ding te zeggen levert een
+ * renderer op met een tak die niemand onderhoudt.
+ */
+export type CustomFieldType = "text" | "textarea" | "number" | "currency" | "date" | "duration" | "select" | "user" | "checkbox"
+/** Verwijst naar een resource elders in het platform; zie {@link CustomFieldDef.refKinds}. */
+ | "resource_ref";
 /** A selectable option for a `select` field. `label` falls back to `value` when absent. */
 export interface CustomFieldOption {
     value: string;
@@ -21,10 +34,24 @@ export interface CustomFieldDef {
     options?: CustomFieldOption[];
     /** `select` only: multi-select — the stored value becomes a string[]. */
     multiValued?: boolean;
-    /** Resource kinds this field applies to, e.g. ["interaction"]. */
+    /** Resource kinds this field applies to, e.g. ["interaction"], ["work_item"]. */
     appliesTo: string[];
     /** Empty/absent = all teams; otherwise only shown when the resource belongs to one of these teams. */
     teamIds?: string[];
+    /**
+     * Voor `resource_ref`: welke scope-soorten gekozen mogen worden (`"company"`,
+     * `"contact"`, `"work_item"`). Leeg = alles wat de kiezer aanbiedt.
+     */
+    refKinds?: string[];
+    /**
+     * Welke work-projecten dit veld aanzetten. Leeg/afwezig = elk project, net als bij
+     * {@link CustomFieldDef.teamIds}.
+     *
+     * Bestaat omdat een velddefinitie platformbreed is maar een veldenset dat niet is: twee
+     * projecten mogen allebei een "Bedrag" kennen met een eigen betekenis. Additief, dus
+     * bestaande definities houden een lege lijst en blijven overal gelden.
+     */
+    projectIds?: string[];
     /**
      * When true, this field becomes an analytics dimension `comms.cf.<key>`: every conversation-level
      * metric can be grouped/filtered by its value. Opt-in to avoid turning free-text fields into

package/dist/entities/time-entry/duration.d.ts

@@ -0,0 +1,22 @@
+import { TimeEntry, TimeRounding } from './types';
+/**
+ * De verstreken tijd van een regel, in seconden.
+ *
+ * In `domain` en niet in de app-server, omdat client én server hetzelfde antwoord moeten geven:
+ * de server stempelt de duur bij het stoppen, het paneel laat 'm ondertussen elke seconde
+ * oplopen. Zou het paneel zelf tellen vanaf een eigen nulpunt, dan loopt de zichtbare klok weg
+ * van wat er uiteindelijk geboekt wordt zodra een tabblad even slaapt.
+ */
+export declare function elapsedSeconds(entry: Pick<TimeEntry, "accumulatedSeconds" | "runningSince">, now: number): number;
+/**
+ * De geboekte duur die bij een gemeten duur hoort.
+ *
+ * Naar boven en met een minimum van één eenheid: wie "per 15 minuten" kiest, wil dat een klus
+ * van drie minuten een kwartier wordt en niet nul. Bij `exact` is de bodem één minuut, om
+ * dezelfde reden — een regel van nul seconden is geen regel.
+ */
+export declare function applyRounding(rawSeconds: number, rounding: TimeRounding | undefined): number;
+/** `0:45` / `2:05` — uren en minuten, zoals de dagtotalen in het paneel. */
+export declare function formatHm(totalSeconds: number): string;
+/** `12:34` onder het uur, `1:02:03` erboven — de lopende klok. */
+export declare function formatClock(totalSeconds: number): string;

package/dist/entities/time-entry/duration.test.d.ts

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

package/dist/entities/time-entry/index.d.ts

@@ -0,0 +1,3 @@
+export * from './duration';
+export * from './types';
+export * from './work-type';

package/dist/entities/time-entry/types.d.ts

@@ -0,0 +1,176 @@
+import { OwnerScope } from '../contact/types';
+/**
+ * Waar een urenregel in zijn leven staat.
+ *
+ * `review` is met opzet een **server**-staat en niet iets wat alleen in het paneel leeft: het
+ * ontwerp laat je na het stoppen nog afronden, een werksoort kiezen en een notitie bijwerken
+ * voordat de regel telt. Zat die tussenstap alleen in de client, dan was een dichtgeslagen
+ * tabblad precies het moment waarop het gewerkte uur verdampt. Nu vindt het paneel de regel bij
+ * het volgende bezoek gewoon terug en staat de review-kaart er weer.
+ *
+ * `logged` is de enige staat die meetelt in totalen en in de rapportage.
+ */
+export type TimeEntryStatus = "running" | "paused" | "review" | "logged";
+/** Hoe de gemeten tijd naar een boekbare duur wordt vertaald. */
+export type TimeRounding = "exact" | "15" | "30";
+/** Handmatig ingevoerd of daadwerkelijk geklokt — zichtbaar in de rapportage. */
+export type TimeEntrySource = "timer" | "manual";
+export interface TimeEntry {
+    id: string;
+    organizationId: string;
+    /** Wie de tijd schreef. Een regel hoort altijd bij precies één mens. */
+    userId: string;
+    /**
+     * Waarop geboekt wordt: `"interaction:abc"`, `"task:42"`, `"company:xyz"`. Afwezig =
+     * algemeen werk zonder object.
+     *
+     * Bewust een opake sleutel en geen `interactionId`: de app die de soort bezit beantwoordt
+     * de toegangsvraag (`assertScopeAccess`), dus urenregistratie hoeft geen enkele andere app
+     * te kennen om er tijd op te kunnen schrijven.
+     */
+    scopeKey?: string;
+    /** Menselijk etiket op schrijfmoment ("Gesprek · RE: EYLO"), zodat een lijst leesbaar blijft
+     *  zonder per regel de bron-app te bevragen. */
+    scopeLabel?: string;
+    /** Dossiersleutels van de resource, platgeslagen bij schrijven — zie de `keys`-conventie. */
+    keys?: string[];
+    /** Eigenaarschap zoals de bron-app het ziet; bepaalt wie de regel in een teamweergave ziet. */
+    ownerScope?: OwnerScope;
+    status: TimeEntryStatus;
+    /** Epoch ms, gezet door de server. De client rekent alleen af hoe laat het nu is. */
+    startedAt: number;
+    /** Epoch ms; gezet zodra de timer stopt. Afwezig zolang hij loopt of gepauzeerd staat. */
+    endedAt?: number;
+    /**
+     * Seconden die vóór het huidige segment al gebankt zijn.
+     *
+     * Pauzeren mag geen tweede rij opleveren — het ontwerp belooft één regel per klus, met een
+     * pauzeknop erin. Daarom telt de server bij elke pauze het gelopen segment hierbij op en
+     * laat `runningSince` los; hervatten zet alleen `runningSince` opnieuw. De verstreken tijd
+     * is dus altijd `accumulatedSeconds + (runningSince ? now - runningSince : 0)`, en dat
+     * antwoord is hetzelfde op elk apparaat.
+     */
+    accumulatedSeconds: number;
+    /** Epoch ms waarop het lopende segment begon. Afwezig = gepauzeerd of gestopt. */
+    runningSince?: number;
+    /** Wat de klok werkelijk mat. Blijft staan als afronding de geboekte duur optrekt. */
+    rawSeconds?: number;
+    /**
+     * De geboekte duur in seconden — dít telt in totalen en facturatie.
+     *
+     * Los van `rawSeconds` omdat afronding een keuze van de gebruiker is en geen meting: wie
+     * later vraagt "waar komt dat kwartier vandaan" moet de gemeten twee minuten nog kunnen zien.
+     */
+    durationSeconds?: number;
+    rounding?: TimeRounding;
+    billable: boolean;
+    /** Verwijst naar `WorkType.key`. */
+    workType?: string;
+    note?: string;
+    source: TimeEntrySource;
+    createdAt?: number;
+    updatedAt?: number;
+}
+/**
+ * Een beheerbare werksoort in plaats van een rijtje in code: welke soorten een organisatie
+ * kent verschilt per bedrijf, en de soort bepaalt of iets standaard declarabel is.
+ */
+export interface WorkType {
+    id: string;
+    organizationId: string;
+    /**
+     * Stabiele sleutel die op de urenregel belandt.
+     *
+     * Uniek binnen de organisatie en niet binnen de scope, hoewel de soort een team kan
+     * toebehoren: `TimeEntry.workType` bewaart alléén deze sleutel en de rapportage groepeert
+     * erop. Twee teams met elk een eigen `installatie` zouden daar als één regel uitkomen, met
+     * twee betekenissen erin.
+     */
+    key: string;
+    label: string;
+    /** Standaardwaarde voor `TimeEntry.billable`; per regel te overrulen. */
+    defaultBillable: boolean;
+    /** Meegenomen als dimensie in de rapportage. */
+    reportable?: boolean;
+    order?: number;
+    archived?: boolean;
+    /**
+     * Van wie deze soort is: de hele organisatie of één team. Bepaalt wie hem in zijn
+     * urenpaneel ziet en wie hem mag beheren.
+     *
+     * Geen `personal`, om dezelfde reden als bij `Topic`: een soort die maar één mens kent,
+     * maakt het geboekte uur onleesbaar voor de collega die de week overneemt. Afwezig telt als
+     * org-breed — dat is wat elke soort vóór dit veld feitelijk was.
+     */
+    ownerScope?: Extract<OwnerScope, {
+        kind: "org";
+    } | {
+        kind: "team";
+    }>;
+    createdAt?: number;
+    updatedAt?: number;
+}
+/**
+ * Wat het beheerscherm naar de server stuurt.
+ *
+ * Zonder `id` is het een nieuwe soort. `key` staat er met opzet niet in: die leidt de server af
+ * uit de naam en ligt daarna vast, omdat geboekte uren ernaar verwijzen.
+ */
+export interface SaveWorkTypeRequest {
+    id?: string;
+    label: string;
+    defaultBillable?: boolean;
+    reportable?: boolean;
+    order?: number;
+    archived?: boolean;
+    ownerScope?: WorkType["ownerScope"];
+}
+/** Een kandidaat waarop de gebruiker kan klokken, aangeboden in de leegstaat van het paneel. */
+export interface TimeTarget {
+    scopeKey?: string;
+    /** Soortlabel boven de titel ("GESPREK OP JE SCHERM", "TAAK"). */
+    kindLabel: string;
+    title: string;
+    /** Lucide-icoonnaam. */
+    icon: string;
+    keys?: string[];
+}
+export interface StartTimerRequest {
+    scopeKey?: string;
+    scopeLabel?: string;
+    keys?: string[];
+    workType?: string;
+    note?: string;
+}
+/** Wat er bij het opslaan van een regel nog aan te passen valt. */
+export interface SaveTimeEntryRequest {
+    id: string;
+    rounding?: TimeRounding;
+    workType?: string;
+    billable?: boolean;
+    note?: string;
+    /** Naar een ander object boeken dan waar de timer op startte. */
+    scopeKey?: string;
+    scopeLabel?: string;
+    keys?: string[];
+}
+export interface ManualTimeEntryRequest {
+    scopeKey?: string;
+    scopeLabel?: string;
+    keys?: string[];
+    /** Epoch ms; de dag waarop de regel valt. */
+    startedAt: number;
+    durationSeconds: number;
+    workType?: string;
+    billable?: boolean;
+    note?: string;
+}
+/** Wat het paneel in één keer ophaalt: de lopende timer plus de dag eromheen. */
+export interface TimeDaySummary {
+    /** De regel die nu loopt, gepauzeerd staat of op afronding wacht — er is er hooguit één. */
+    active?: TimeEntry;
+    /** Afgeronde regels van de opgevraagde dag, oplopend op starttijd. */
+    entries: TimeEntry[];
+    totalSeconds: number;
+    billableSeconds: number;
+}

package/dist/entities/time-entry/work-type.d.ts

@@ -0,0 +1,44 @@
+import { WorkType } from './types';
+/**
+ * De sleutel die bij een naam hoort: kleine letters, streepjes, geen accenten.
+ *
+ * In `domain` en niet in de app-server omdat het beheerscherm hem al tijdens het typen laat
+ * zien — wat de gebruiker daar ziet moet exact zijn wat de server straks wegschrijft, anders
+ * belooft het formulier `installatie-op-locatie` en staat er `installatieoplocatie` in de
+ * rapportage.
+ *
+ * `normalize("NFD")` plus het weghalen van de combineertekens, zodat "Béta" `beta` wordt en niet
+ * `b-ta`: een leesbare sleutel is het halve doel.
+ */
+export declare function workTypeKey(label: string): string;
+/**
+ * Dezelfde sleutel, maar gegarandeerd nog vrij binnen de organisatie.
+ *
+ * Botsingen zijn echt: de sleutel is org-uniek terwijl soorten per team beheerd worden, dus twee
+ * teams die allebei "Installatie" aanmaken komen hier uit. De tweede krijgt `installatie-2` in
+ * plaats van een foutmelding — een beheerder die een naam kiest, hoort niet te struikelen over
+ * een sleutel die hij nooit heeft gezien.
+ *
+ * `taken` bevat óók gearchiveerde sleutels: die staan nog op geboekte uren, dus hergebruiken zou
+ * oud werk stilzwijgend onder een nieuwe soort schuiven.
+ */
+export declare function uniqueWorkTypeKey(label: string, taken: Iterable<string>): string;
+/**
+ * Ziet deze gebruiker deze soort?
+ *
+ * Een soort zonder scope is org-breed: rijen zijn ouder dan het veld, en ze wegfilteren zou een
+ * bestaande organisatie zijn hele lijst kosten.
+ */
+export declare function isWorkTypeVisible(workType: Pick<WorkType, "ownerScope">, teamIds: string[]): boolean;
+/**
+ * Wat het paneel toont: niet-gearchiveerd, in de juiste volgorde.
+ *
+ * Zonder team-argument, en dat is met opzet: de server heeft de teamzichtbaarheid al afgekapt
+ * voordat de lijst de client bereikt (dat is een rechtenvraag). Zou de client hier nóg eens op
+ * `teamIds` filteren, dan moest hij het lidmaatschap van de gebruiker kennen — en met een lege
+ * lijst, zoals hij hem nu heeft, zou hij precies de teamsoorten wegfilteren die de server net
+ * heeft goedgekeurd.
+ */
+export declare function activeWorkTypes(workTypes: WorkType[]): WorkType[];
+/** De volgorde van de chips: `order` eerst, gelijke waarden alfabetisch zodat hij stabiel is. */
+export declare function compareWorkTypes(a: WorkType, b: WorkType): number;

package/dist/entities/time-entry/work-type.test.d.ts

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

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

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

package/dist/entities/work/keys.d.ts

@@ -0,0 +1,57 @@
+import { WorkItem, WorkProject } from './types';
+/**
+ * Sleutels: de scopeKeys waarmee andere apps werk aanwijzen, en de menselijke itemsleutel.
+ *
+ * Beide staan in `domain` en niet in de app, omdat het contracten zijn: de client bouwt een
+ * scopeKey om een timer te starten, de server autoriseert hem, en twee plekken die het
+ * voorvoegsel los uitschrijven lopen bij de eerste typefout stil uiteen — met "geen toegang
+ * tot deze scope" als gevolg in plaats van een foutmelding die zegt wat er mis is.
+ */
+/** De scope-soorten die `apps/work` claimt via `/provider/scope/describe`. */
+export declare const WORK_ITEM_SCOPE_KIND = "work_item";
+export declare const WORK_PROJECT_SCOPE_KIND = "work_project";
+export declare function workItemScopeKey(itemId: string): string;
+export declare function workProjectScopeKey(projectId: string): string;
+/**
+ * De menselijke sleutel: `SAL-142`, of `SAL-142-1` voor een subitem.
+ *
+ * Alleen voor items mét project — een los item heeft er geen, en dat is geen omissie maar het
+ * verschil tussen "werk dat een plek in een proces heeft" en "iets wat ik nog moet doen".
+ */
+export declare function formatItemKey(projectKey: string, sequenceNumber: number, subSequence?: number): string;
+/** Wat er in een `SAL-142-1` zit, of `null` als het geen itemsleutel is. */
+export interface ParsedItemKey {
+    projectKey: string;
+    sequenceNumber: number;
+    subSequence?: number;
+}
+/**
+ * Leest een sleutel die iemand heeft ingetypt of geplakt.
+ *
+ * Hoofdletterongevoelig aan de invoerkant en genormaliseerd aan de uitvoerkant, want mensen
+ * typen `sal-142` in een zoekveld en verwachten hun item. Het projectvoorvoegsel is
+ * `[A-Z0-9]{2,8}`, wat een streepje uitsluit — anders zou `SAL-142-1` net zo goed te lezen
+ * zijn als project `SAL-142`, item `1`.
+ */
+export declare function parseItemKey(input: string): ParsedItemKey | null;
+/** De projectsleutel die bij een naam hoort: `"Sales pipeline"` → `"SAL"`. */
+export declare function suggestProjectKey(name: string): string;
+/**
+ * De dossiersleutels van een item: waarmee uren, geheugen en attributen het terugvinden.
+ *
+ * **Klein houden.** Dit is de set van de rij zelf en niet zijn hele omgeving — deze sleutels
+ * rijden mee op elke autorisatie, inclusief elke geheugen-schrijfactie, dus de kinderen van
+ * dit item horen er niet in. Dezelfde afweging die `companyDossierKeys` maakt tegenover
+ * `keySetForCompany` in crm.
+ *
+ * De harde bovengrens is er voor het pathologische geval: een item met tweehonderd partijen
+ * mag geen array van tweehonderd sleutels op elke autorisatie leggen.
+ */
+export declare function itemDossierKeys(item: Pick<WorkItem, "id" | "projectId" | "ancestorKeys" | "partyKeys">, limit?: number): string[];
+/**
+ * De dossiersleutels van een project: alleen zichzelf.
+ *
+ * Een project heeft onbegrensd veel items, dus zijn kinderen meegeven zou een onbegrensd
+ * array op elke autorisatie leggen. Wie de items wil, vraagt ernaar.
+ */
+export declare function projectDossierKeys(project: Pick<WorkProject, "id">): string[];

package/dist/entities/work/keys.test.d.ts

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

package/dist/entities/work/ladder.d.ts

@@ -0,0 +1,97 @@
+import { WorkProject, WorkStatus, WorkStatusCategory } from './types';
+/**
+ * De statusladder — de enige plek die weet of een item een project heeft.
+ *
+ * `WorkItem.projectId` is optioneel, en zonder discipline betekent dat een `if (projectId)`
+ * in elke lijst, elke teller en elke statuskiezer. Alles wat "welke statussen kan dit item
+ * hebben" of "is dit open" vraagt gaat daarom door {@link ladderFor} en {@link categoryOf},
+ * en nergens anders.
+ */
+/**
+ * De vaste ladder voor werk zónder project.
+ *
+ * Deze drie sleutels zijn **gereserveerd**: een project mag ze niet claimen, want dan zou
+ * dezelfde sleutel in twee ladders een andere categorie kunnen hebben en werd de
+ * org-brede "wat staat er open"-query stil onjuist. `validateStatuses` bewaakt dat.
+ *
+ * De labels zijn **i18n-sleutels, geen tekst** — een letterlijke string hier zou de taal op
+ * moduleniveau vastzetten voor elke consument, en dat is precies wat de i18n-regel in
+ * `DESIGN_SYSTEM.md` §11 verbiedt. Ze staan zonder app-voorvoegsel omdat de app-sdk dat er
+ * bij het opzoeken zelf voor zet; een `work:`-voorvoegsel hier zou in de eigen app
+ * verdubbelen tot `work:work:status_open`.
+ *
+ * Een projectstatus heeft géén sleutel maar een naam die een beheerder heeft ingetypt. Alleen
+ * deze drie zijn vertaalbaar, want alleen deze zijn van ons.
+ */
+export declare const LOOSE_STATUSES: readonly WorkStatus[];
+/** De sleutels die {@link LOOSE_STATUSES} bezet houdt. */
+export declare const RESERVED_STATUS_KEYS: readonly string[];
+/**
+ * De ladder die voor dit item geldt.
+ *
+ * Een project zónder statussen valt terug op de vaste ladder in plaats van een lege lijst op
+ * te leveren: een statuskiezer met nul opties is een doodlopende weg, en een half aangemaakt
+ * project hoort niet onbruikbaar te zijn.
+ */
+export declare function ladderFor(project?: WorkProject | null): readonly WorkStatus[];
+/**
+ * De categorie van een statussleutel binnen een ladder.
+ *
+ * Valt terug op `"todo"` bij een onbekende sleutel, en dat is de veilige kant: een item dat
+ * door een verwijderde status wees zou anders als afgerond uit elke telling verdwijnen. Beter
+ * zichtbaar op de verkeerde plek dan onzichtbaar.
+ */
+export declare function categoryOf(statusKey: string, ladder: readonly WorkStatus[]): WorkStatusCategory;
+/** De status zelf, als de ladder hem kent. */
+export declare function statusIn(statusKey: string, ladder: readonly WorkStatus[]): WorkStatus | undefined;
+/** Waar een nieuw item begint: de expliciete keuze van het project, anders de eerste stap. */
+export declare function defaultStatusKey(project?: WorkProject | null): string;
+/** `order` eerst, gelijke waarden op label zodat de volgorde stabiel is. */
+export declare function sortStatuses(ladder: readonly WorkStatus[]): WorkStatus[];
+/**
+ * Is dit item afgerond? De enige juiste manier om die vraag te stellen.
+ *
+ * `isWorkClosed` en niet `isClosed`, want `entities/interaction` exporteert die naam al voor
+ * een gesprek. Twee `isClosed`en in één barrel is precies de verwarring waar dit veld niet
+ * op zit te wachten.
+ */
+export declare function isWorkClosed(statusKey: string, ladder: readonly WorkStatus[]): boolean;
+/**
+ * De statussleutel die bij een naam hoort: kleine letters, streepjes, geen accenten.
+ *
+ * Dezelfde vorm en dezelfde reden als `workTypeKey` bij de werksoorten: het beheerscherm
+ * toont hem al tijdens het typen, dus wat de gebruiker daar ziet moet precies zijn wat de
+ * server wegschrijft. `normalize("NFD")` plus het weghalen van de combineertekens, zodat
+ * "Béta" `beta` wordt en niet `b-ta`.
+ */
+export declare function workStatusKey(label: string): string;
+/**
+ * Dezelfde sleutel, gegarandeerd nog vrij binnen de organisatie.
+ *
+ * Botsingen zijn hier de regel en niet de uitzondering: sleutels zijn org-uniek terwijl
+ * statussen per project beheerd worden, dus twee projecten die allebei een "Review" aanmaken
+ * komen hier uit. De tweede krijgt `review-2` in plaats van een foutmelding — een beheerder
+ * die een naam kiest hoort niet te struikelen over een sleutel die hij nooit heeft gezien.
+ *
+ * `taken` moet óók de sleutels van verwijderde statussen bevatten zolang er items naar
+ * wijzen, en altijd {@link RESERVED_STATUS_KEYS}.
+ */
+export declare function uniqueWorkStatusKey(label: string, taken: Iterable<string>): string;
+/** Wat er mis is met een voorgestelde ladder, als leesbare redenen. */
+export interface StatusLadderProblem {
+    /** Index in de aangeleverde lijst, of `-1` als het de lijst als geheel betreft. */
+    index: number;
+    reason: "empty" | "duplicate_key" | "reserved_key" | "missing_key" | "no_open" | "no_done";
+    key?: string;
+}
+/**
+ * Valideert een ladder vóór hij wordt opgeslagen.
+ *
+ * Bestaat omdat de store hier niets bewaakt: `statuses` is één ingebed array, dus uniciteit
+ * en volledigheid zijn de verantwoordelijkheid van de schrijver. Puur en zonder I/O, zodat
+ * het beheerscherm dezelfde regels kan tonen als de server afdwingt.
+ *
+ * De twee laatste regels zijn geen smaak: een ladder zonder open-categorie maakt elk nieuw
+ * item meteen afgerond, en een ladder zonder `done` maakt afronden onmogelijk.
+ */
+export declare function validateStatuses(statuses: readonly WorkStatus[]): StatusLadderProblem[];

package/dist/entities/work/ladder.test.d.ts

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