@opencxh/domain 1.171.0 → 1.172.2

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

@@ -1,45 +1,45 @@
-import { OwnerScope } from '../contact/types';
+import { OrgTeamScope } from '../scope/types';
 /**
- * Een onderwerp is een **etiket** op een gesprek: waar gaat dit over. Verder niets.
+ * A topic is a **label** on a conversation: what is this about. Nothing more.
  *
- * Er zat ooit ook een kennis-kant in (`knowledgeSources`: urls en kb-artikelen die "bij dit
- * onderwerp horen"). Die is eruit gehaald omdat hij door niemand gelezen werd — het formulier
- * vulde hem, de entity bewaarde hem, en geen enkele prompt of zoekactie deed er iets mee. Wat hij
- * beloofde doet de kennisbank inmiddels beter (hybride RAG over álle artikelen) en het geheugen
- * daarnaast (`memory_find_similar`, uit echt verkeer). Zie `docs/TOPICS.md`.
+ * It once also had a knowledge side (`knowledgeSources`: urls and kb articles "belonging to this
+ * topic"). That was removed because nobody read it — the form filled it, the entity stored it, and
+ * no prompt or search did anything with it. What it promised the knowledge base now does better
+ * (hybrid RAG over *all* articles) and the memory layer alongside it (`memory_find_similar`, from
+ * real traffic). See `docs/TOPICS.md`.
  */
 export interface Topic {
     id: string;
     organizationId: string;
     /**
-     * Van wie dit onderwerp is. `org` of `team`; **`personal` wordt geweigerd bij het schrijven** —
-     * een onderwerp dat maar één persoon kent, kan een collega niet lezen op een gesprek dat hij
-     * overneemt. Het type laat het toe omdat `OwnerScope` gedeeld is; de validatie niet.
+     * Whose topic this is: `org` or `team`. A topic only one person knows cannot be read by a
+     * colleague taking over the conversation. `OrgTeamScope` says so in the type, so it is not only
+     * the write validation enforcing it.
      */
-    ownerScope: OwnerScope;
+    ownerScope: OrgTeamScope;
     name: string;
     description: string;
     /**
-     * Voorbeeldzinnen die de classificatie-prompt meekrijgt. Dit is het enige veld dat de
-     * classifier scherper maakt, en dus het enige dat het waard is om bij te houden.
+     * Example sentences the classification prompt receives. The only field that sharpens the
+     * classifier, and therefore the only one worth maintaining.
      */
     examples: string[];
     /**
-     * Voorgestelde voorbeelden, nog niet overgenomen. Groeit vanzelf: elke keer dat een **mens**
-     * dit onderwerp op een gesprek zet of corrigeert, komt de openingszin hier terecht.
+     * Suggested examples, not accepted yet. Grows by itself: every time a **person** puts this topic
+     * on a conversation or corrects it, the opening sentence lands here.
      *
-     * Bewust náást `examples` en niet erin: de classificatie-prompt is de plek waar één slecht
-     * voorbeeld het gedrag van élk volgend gesprek verschuift, en er is geen undo op een prompt die
-     * drie weken scheef stond. `examples` blijft van de beheerder; dit is een voorstel.
+     * Deliberately next to `examples` and not in it: the classification prompt is where one bad
+     * example shifts the behaviour of *every* following conversation, and there is no undo on a
+     * prompt that sat crooked for three weeks. `examples` stays the admin's; this is a suggestion.
      */
     exampleCandidates?: TopicExampleCandidate[];
 }
 /**
- * Eén voorgesteld voorbeeld.
+ * One suggested example.
  *
- * `corrected` onderscheidt "iemand zette een onderwerp op een gesprek dat er nog geen had" van
- * "iemand zette het onderwerp om" — dat tweede is een gecorrigeerde fout en daarmee het meest
- * informatieve geval dat er is. De UI zet ze daarom bovenaan.
+ * `corrected` distinguishes "someone put a topic on a conversation that had none" from "someone
+ * changed the topic" — the second is a corrected mistake and thereby the most informative case
+ * there is. The UI puts those on top.
  */
 export interface TopicExampleCandidate {
     text: string;
@@ -48,14 +48,14 @@ export interface TopicExampleCandidate {
     corrected: boolean;
 }
 /**
- * Hoeveel voorbeelden er per onderwerp mee mogen.
+ * How many examples a topic may carry.
  *
- * De hele lijst gaat als JSON de systemprompt in bij élke classificatie
- * (`apps/ai/server/src/playbook/ai/classify.ts`), dus ongelimiteerd groeien maakt het classificeren
- * per gesprek duurder tot het niet meer past.
+ * The whole list goes into the system prompt as JSON on *every* classification
+ * (`apps/ai/server/src/playbook/ai/classify.ts`), so unlimited growth makes classifying more
+ * expensive per conversation until it no longer fits.
  */
 export declare const MAX_TOPIC_EXAMPLES = 20;
-/** Idem voor de kandidatenlijst: een voorstellenbak die volloopt, leest niemand meer na. */
+/** Same for the candidate list: a suggestion bucket that fills up is one nobody reviews. */
 export declare const MAX_TOPIC_CANDIDATES = 20;
-/** Een voorbeeld is een openingszin, geen transcript. */
+/** An example is an opening sentence, not a transcript. */
 export declare const MAX_TOPIC_EXAMPLE_CHARS = 300;

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

@@ -1,26 +1,25 @@
 /**
- * Mens of agent.
+ * Human or agent.
  *
- * Een agent is **geen apart begrip naast de gebruiker** maar een gebruiker met een ander type.
- * Dat is een keuze met een concreet doel: hij krijgt een echt `userId`, dus hij loopt door
- * `authorizeIdentity` op het fail-closed pad, hij tekent zijn activities met zijn eigen naam in
- * plaats van als "system", hij kan lid van een team zijn (`getReadableTeamIds` werkt), en hij
- * verbruikt van zijn eigen per-user-budget. Elk van die dingen zou anders een uitzondering zijn
- * geweest, en elke uitzondering is een plek waar een audit hem kwijtraakt.
+ * An agent is **not a separate concept beside the user** but a user with a different type. A
+ * choice with a concrete purpose: it gets a real `userId`, so it runs through `authorizeIdentity`
+ * on the fail-closed path, it signs its activities with its own name instead of as "system", it
+ * can be a team member (`getReadableTeamIds` works), and it spends from its own per-user budget.
+ * Each of those would otherwise have been an exception, and every exception is a place where an
+ * audit loses it.
  *
- * Afwezig betekent `"user"`: bestaande rijen zijn mensen, en de mirror wordt niet gebackfilld.
+ * Absent means `"user"`: existing rows are humans, and the mirror is not backfilled.
  */
 export type UserType = "user" | "agent";
 /**
- * Wat een ander oppervlak van een gebruiker mag weten om hem te **tónen**.
+ * What another surface may know about a user in order to **show** them.
  *
- * Los van {@link User}, en dat is het punt: een naam opzoeken is iets anders dan een gebruiker
- * beheren. De beheerroute geeft het hele record plus zijn rollen (een extra RPC naar
- * `system.rbac`) — dat is precies wat je niet wil als je alleen een auteursnaam in een tijdlijn
- * zet: het kost een call die niemand nodig heeft en het deelt e-mail en rollen met een app die
- * daar niets mee te maken heeft.
+ * Separate from {@link User}, and that is the point: looking a name up is not the same as managing
+ * a user. The admin route returns the whole record plus its roles (an extra RPC to `system.rbac`) —
+ * exactly what you do not want when only putting an author name in a timeline: it costs a call
+ * nobody needs and shares email and roles with an app that has nothing to do with them.
  *
- * `type` zit er wél in: een tijdlijn of een deelnemerslijst wil een agent kunnen markeren.
+ * `type` *is* in here: a timeline or a participant list wants to be able to mark an agent.
  */
 export interface UserProfile {
     id: string;
@@ -29,16 +28,16 @@ export interface UserProfile {
     avatarUrl?: string;
     type?: UserType;
     /**
-     * Het brein van een agent, als dit een agent is — zie {@link User.profileId}.
+     * An agent's brain, when this is an agent — see {@link User.profileId}.
      *
-     * Hoort bij dit compacte record en niet alleen bij het volledige: "is dit een agent" staat er
-     * al (`type`), en "met welk brein" is de directe vervolgvraag van elke beller die er werk aan
-     * geeft. Zonder dit veld moest de ai-app de beheerroute gebruiken — het hele record plus een
-     * RPC naar `system.rbac` — om één id te weten.
+     * Belongs on this compact record and not only on the full one: "is this an agent" is already
+     * here (`type`), and "with which brain" is the immediate follow-up of every caller handing it
+     * work. Without this field the ai app had to use the admin route — the whole record plus an RPC
+     * to `system.rbac` — to learn one id.
      */
     profileId?: string;
 }
-/** Is deze gebruiker een agent? Afwezig type = mens. */
+/** Is this user an agent? An absent type = human. */
 export declare function isAgentUser(user: {
     type?: UserType | string;
 }): boolean;
@@ -48,16 +47,13 @@ export interface User {
     email: string;
     availableOrganizations: string[];
     /**
-     * Mens of agent. Zie {@link UserType}.
+     * Human or agent. See {@link UserType}.
      *
-     * Staat op de **lokale mirror** en niet in `system.users`: dat is het platform-record en dat
-     * kennen we niet. Alles wat "is dit een mens" moet weten leest dit veld.
+     * Sits on the **local mirror** and not in `system.users`: that is the platform record and we do
+     * not own it. Everything that needs to know "is this a human" reads this field.
      */
     type?: UserType;
-    /**
-     * Het brein van een agent: het `AIProfile` waarmee hij werkt. Alleen gezet als
-     * `type === "agent"`.
-     */
+    /** An agent's brain: the `AIProfile` it works with. Only set when `type === "agent"`. */
     profileId?: string;
     /** Mirrored from system.users. */
     firstName?: string;

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

@@ -19,16 +19,16 @@ export interface Webhook {
     enabled: boolean;
     createdBy: string;
     /**
-     * Hoe de laatste aflevering ging.
+     * How the last delivery went.
      *
-     * Vier velden en geen afleverhistorie: de vraag die een beheerder stelt is "komt dit aan?", en
-     * die is met de laatste poging plus een teller beantwoord. Een volledige historie is een eigen
-     * scherm en een eigen entiteit.
+     * Four fields and no delivery history: the question an admin asks is "does this arrive?", and
+     * that is answered by the last attempt plus a counter. A full history is a screen of its own and
+     * an entity of its own.
      */
     lastDeliveryAt?: number;
-    /** HTTP-status van de laatste poging. Afwezig = de call kwam niet tot een antwoord. */
+    /** HTTP status of the last attempt. Absent = the call never reached an answer. */
     lastStatus?: number;
     lastError?: string;
-    /** Opeenvolgende mislukkingen, nul zodra er één aankomt — niet een totaalteller. */
+    /** Consecutive failures, zero as soon as one arrives — not a running total. */
     failureCount?: number;
 }

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

@@ -1,57 +1,56 @@
 import { WorkItem, WorkProject } from './types';
 /**
- * Sleutels: de scopeKeys waarmee andere apps werk aanwijzen, en de menselijke itemsleutel.
+ * Keys: the scopeKeys other apps point at work with, and the human item key.
  *
- * 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.
+ * Both live in `domain` and not in the app, because they are contracts: the client builds a
+ * scopeKey to start a timer, the server authorizes it, and two places spelling the prefix out
+ * separately drift apart silently on the first typo — resulting in "no access to this scope"
+ * instead of an error saying what is wrong.
  */
-/** De scope-soorten die `apps/work` claimt via `/provider/scope/describe`. */
+/** The scope kinds `apps/work` claims through `/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.
+ * The human key: `SAL-142`, or `SAL-142-1` for a 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".
+ * Only for items *with* a project — a loose item has none, and that is not an omission but the
+ * difference between "work with a place in a process" and "something I still have to do".
  */
 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. */
+/** What sits inside a `SAL-142-1`, or `null` when it is not an item key. */
 export interface ParsedItemKey {
     projectKey: string;
     sequenceNumber: number;
     subSequence?: number;
 }
 /**
- * Leest een sleutel die iemand heeft ingetypt of geplakt.
+ * Reads a key someone typed or pasted.
  *
- * 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`.
+ * Case-insensitive on the input side and normalized on the output side, because people type
+ * `sal-142` in a search field and expect their item. The project prefix is `[A-Z0-9]{2,8}`, which
+ * excludes a hyphen — otherwise `SAL-142-1` could just as well read as project `SAL-142`, item `1`.
  */
 export declare function parseItemKey(input: string): ParsedItemKey | null;
-/** De projectsleutel die bij een naam hoort: `"Sales pipeline"` → `"SAL"`. */
+/** The project key belonging to a name: `"Sales pipeline"` → `"SAL"`. */
 export declare function suggestProjectKey(name: string): string;
 /**
- * De dossiersleutels van een item: waarmee uren, geheugen en attributen het terugvinden.
+ * An item's file keys: what hours, memory and attributes find it back with.
  *
- * **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.
+ * **Keep it small.** This is the set of the row itself and not of its whole surroundings — these
+ * keys ride along on every authorization, including every memory write, so this item's children do
+ * not belong in it. The same trade-off `companyDossierKeys` makes against `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.
+ * The hard upper bound is there for the pathological case: an item with two hundred parties must
+ * not put an array of two hundred keys on every authorization.
  */
 export declare function itemDossierKeys(item: Pick<WorkItem, "id" | "projectId" | "ancestorKeys" | "partyKeys">, limit?: number): string[];
 /**
- * De dossiersleutels van een project: alleen zichzelf.
+ * A project's file keys: itself only.
  *
- * Een project heeft onbegrensd veel items, dus zijn kinderen meegeven zou een onbegrensd
- * array op elke autorisatie leggen. Wie de items wil, vraagt ernaar.
+ * A project has unbounded items, so passing its children would put an unbounded array on every
+ * authorization. Whoever wants the items asks for them.
  */
 export declare function projectDossierKeys(project: Pick<WorkProject, "id">): string[];

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

@@ -1,97 +1,93 @@
 import { WorkProject, WorkStatus, WorkStatusCategory } from './types';
 /**
- * De statusladder — de enige plek die weet of een item een project heeft.
+ * The status ladder — the only place that knows whether an item has a project.
  *
- * `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.
+ * `WorkItem.projectId` is optional, and without discipline that means an `if (projectId)` in every
+ * list, every counter and every status picker. So anything asking "which statuses can this item
+ * have" or "is this open" goes through {@link ladderFor} and {@link categoryOf}, and nowhere else.
  */
 /**
- * De vaste ladder voor werk zónder project.
+ * The fixed ladder for work *without* a 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.
+ * These three keys are **reserved**: a project may not claim them, because then the same key could
+ * have a different category in two ladders and the org-wide "what is open" query would silently go
+ * wrong. `validateStatuses` guards that.
  *
- * 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`.
+ * The labels are **i18n keys, not text** — a literal string here would fix the language at module
+ * level for every consumer, exactly what the i18n rule in `DESIGN_SYSTEM.md` §11 forbids. They
+ * carry no app prefix because the app-sdk adds that on lookup; a `work:` prefix here would double
+ * up to `work:work:status_open` inside the app itself.
  *
- * 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.
+ * A project status has no key but a name an admin typed. Only these three are translatable,
+ * because only these are ours.
  */
 export declare const LOOSE_STATUSES: readonly WorkStatus[];
-/** De sleutels die {@link LOOSE_STATUSES} bezet houdt. */
+/** The keys {@link LOOSE_STATUSES} occupies. */
 export declare const RESERVED_STATUS_KEYS: readonly string[];
 /**
- * De ladder die voor dit item geldt.
+ * The ladder that applies to this item.
  *
- * 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.
+ * A project *without* statuses falls back to the fixed ladder instead of yielding an empty list: a
+ * status picker with zero options is a dead end, and a half-created project should not be
+ * unusable.
  */
 export declare function ladderFor(project?: WorkProject | null): readonly WorkStatus[];
 /**
- * De categorie van een statussleutel binnen een ladder.
+ * The category of a status key within a 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.
+ * Falls back to `"todo"` on an unknown key, which is the safe side: an item pointing at a deleted
+ * status would otherwise vanish from every count as if finished. Better visible in the wrong place
+ * than invisible.
  */
 export declare function categoryOf(statusKey: string, ladder: readonly WorkStatus[]): WorkStatusCategory;
-/** De status zelf, als de ladder hem kent. */
+/** The status itself, when the ladder knows it. */
 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. */
+/** Where a new item starts: the project's explicit choice, otherwise the first step. */
 export declare function defaultStatusKey(project?: WorkProject | null): string;
-/** `order` eerst, gelijke waarden op label zodat de volgorde stabiel is. */
+/** `order` first, ties broken on label so the ordering is stable. */
 export declare function sortStatuses(ladder: readonly WorkStatus[]): WorkStatus[];
 /**
- * Is dit item afgerond? De enige juiste manier om die vraag te stellen.
+ * Is this item finished? The only correct way to ask that question.
  *
- * `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.
+ * `isWorkClosed` and not `isClosed`, because `entities/interaction` already exports that name for a
+ * conversation. Two `isClosed`es in one barrel is exactly the confusion this field does not need.
  */
 export declare function isWorkClosed(statusKey: string, ladder: readonly WorkStatus[]): boolean;
 /**
- * De statussleutel die bij een naam hoort: kleine letters, streepjes, geen accenten.
+ * The status key belonging to a name: lowercase, hyphens, no accents.
  *
- * 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`.
+ * Same shape and same reason as `workTypeKey` for the work types: the admin screen shows it while
+ * you type, so what the user sees there has to be exactly what the server writes.
+ * `normalize("NFD")` plus stripping the combining marks, so "Béta" becomes `beta` and not `b-ta`.
  */
 export declare function workStatusKey(label: string): string;
 /**
- * Dezelfde sleutel, gegarandeerd nog vrij binnen de organisatie.
+ * The same key, guaranteed still free within the organisation.
  *
- * 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.
+ * Collisions are the rule here and not the exception: keys are org-unique while statuses are
+ * managed per project, so two projects both creating a "Review" end up here. The second gets
+ * `review-2` instead of an error — an admin picking a name should not trip over a key they never
+ * saw.
  *
- * `taken` moet óók de sleutels van verwijderde statussen bevatten zolang er items naar
- * wijzen, en altijd {@link RESERVED_STATUS_KEYS}.
+ * `taken` must also contain the keys of deleted statuses as long as items point at them, and
+ * always {@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. */
+/** What is wrong with a proposed ladder, as readable reasons. */
 export interface StatusLadderProblem {
-    /** Index in de aangeleverde lijst, of `-1` als het de lijst als geheel betreft. */
+    /** Index in the supplied list, or `-1` when it concerns the list as a whole. */
     index: number;
     reason: "empty" | "duplicate_key" | "reserved_key" | "missing_key" | "no_open" | "no_done";
     key?: string;
 }
 /**
- * Valideert een ladder vóór hij wordt opgeslagen.
+ * Validates a ladder before it is stored.
  *
- * 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.
+ * Exists because the store guards nothing here: `statuses` is one embedded array, so uniqueness
+ * and completeness are the writer's responsibility. Pure and without I/O, so the admin screen can
+ * show the same rules the server enforces.
  *
- * 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.
+ * The last two rules are not taste: a ladder without an open category marks every new item
+ * finished immediately, and a ladder without `done` makes finishing impossible.
  */
 export declare function validateStatuses(statuses: readonly WorkStatus[]): StatusLadderProblem[];