@formicoidea/labre-framework-bpmn 0.31.0 → 0.33.0

package/dist/roles.js

@@ -0,0 +1,410 @@
+/** Role ids, keyed by the `kind` used at the creation sites. */
+export const BPMN_ROLE = {
+    // The umbrella over the three families that ARE the process: events,
+    // activities and gateways. Never stamped, like the three families under it.
+    flowObject: 'bpmn:flow-object',
+    // Events: the family, the two starts and the two ends, and the leaves the
+    // descriptive profile draws under each.
+    event: 'bpmn:event',
+    startEvent: 'bpmn:start-event',
+    startEventMessage: 'bpmn:message-start-event',
+    startEventTimer: 'bpmn:timer-start-event',
+    endEvent: 'bpmn:end-event',
+    endEventMessage: 'bpmn:message-end-event',
+    endEventTerminate: 'bpmn:terminate-end-event',
+    // Activities.
+    activity: 'bpmn:activity',
+    task: 'bpmn:task',
+    taskUser: 'bpmn:user-task',
+    taskService: 'bpmn:service-task',
+    subProcess: 'bpmn:sub-process',
+    callActivity: 'bpmn:call-activity',
+    // Gateways. `gateway-exclusive` keeps the word order it shipped with — it is
+    // written in documents already — while its sibling takes the spec's own
+    // ("parallel gateway"). An id in a stored document is not a naming
+    // convention: it is a value, and renaming it would orphan every process that
+    // carries it.
+    gateway: 'bpmn:gateway',
+    gatewayExclusive: 'bpmn:gateway-exclusive',
+    gatewayParallel: 'bpmn:parallel-gateway',
+    // Data — a family of its own, never a flow object.
+    data: 'bpmn:data',
+    dataObject: 'bpmn:data-object',
+    dataStore: 'bpmn:data-store',
+    // The two artifacts: a note on the picture, and a lasso round part of it.
+    textAnnotation: 'bpmn:text-annotation',
+    group: 'bpmn:group',
+    // The frame.
+    pool: 'bpmn:pool',
+    // The connecting objects.
+    sequenceFlow: 'bpmn:sequence-flow',
+    messageFlow: 'bpmn:message-flow',
+    association: 'bpmn:association',
+};
+const _everyRoleIsMapped = true;
+void _everyRoleIsMapped;
+/** i18n key stem of a role id: `bpmn:start-event` → `com.labre.bpmn.role.start-event`. */
+const roleKey = (id) => `com.labre.bpmn.role.${id.slice('bpmn:'.length)}`;
+const FLOW_OBJECT_DEFS = [
+    /**
+     * The FLOW OBJECT — the one word BPMN itself uses for "a thing the process
+     * does", and the parent of the three families under it.
+     *
+     * Never stamped, like the three families it covers: no palette entry writes
+     * `bpmn:flow-object` and none ever will. It exists so a rule can say the thing
+     * the notation says. A sequence flow chains flow objects; a step must be
+     * reachable from the start; both sentences are about events, activities AND
+     * gateways at once, and without this role each of them would have to enumerate
+     * the three — three triplets where BPMN has one word, and a fourth family
+     * (nobody has asked for one) silently missing from every rule that forgot to
+     * grow its list.
+     *
+     * ## What it deliberately does NOT cover
+     *
+     * `bpmn:data`, `bpmn:text-annotation` and `bpmn:pool` stay outside, each for
+     * the reason its own block gives: the paperwork is not the work, commentary is
+     * never evidence, and the frame is not an artefact drawn in it. That
+     * exclusion is the whole value of the word — "a sequence flow chains flow
+     * objects" is only worth saying because a data object is not one.
+     *
+     * Pure static data, and nothing is written to a document: an element carries
+     * the role its palette entry stamped (`bpmn:task`), and the walk from it up to
+     * `bpmn:flow-object` happens in `roleIsA`, at evaluation time, out of this
+     * table. A process drawn yesterday gains the parent the moment it is opened,
+     * with no migration and nothing backfilled.
+     */
+    {
+        id: BPMN_ROLE.flowObject,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.flowObject),
+        labelFallback: 'Flow object',
+    },
+    // The three families. None of them is ever STAMPED on an element — the palette
+    // always says which event, which activity, which gateway — and that is the
+    // point: they exist so a rule can be written once about "an event" and stay
+    // written when the full pack adds the message and timer ones under them.
+    {
+        id: BPMN_ROLE.event,
+        parent: BPMN_ROLE.flowObject,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.event),
+        labelFallback: 'Event',
+    },
+    {
+        id: BPMN_ROLE.startEvent,
+        parent: BPMN_ROLE.event,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.startEvent),
+        labelFallback: 'Start event',
+    },
+    // The two TRIGGERED starts. Children of the plain start event and not
+    // siblings of it: "the process starts here" is true of all three, and a rule
+    // about where a process begins must not have to enumerate the triggers.
+    {
+        id: BPMN_ROLE.startEventMessage,
+        parent: BPMN_ROLE.startEvent,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.startEventMessage),
+        labelFallback: 'Message start event',
+    },
+    {
+        id: BPMN_ROLE.startEventTimer,
+        parent: BPMN_ROLE.startEvent,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.startEventTimer),
+        labelFallback: 'Timer start event',
+    },
+    {
+        id: BPMN_ROLE.endEvent,
+        parent: BPMN_ROLE.event,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.endEvent),
+        labelFallback: 'End event',
+    },
+    // ...and the two ends that do something on the way out.
+    {
+        id: BPMN_ROLE.endEventMessage,
+        parent: BPMN_ROLE.endEvent,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.endEventMessage),
+        labelFallback: 'Message end event',
+    },
+    {
+        id: BPMN_ROLE.endEventTerminate,
+        parent: BPMN_ROLE.endEvent,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.endEventTerminate),
+        labelFallback: 'Terminate end event',
+    },
+    {
+        id: BPMN_ROLE.activity,
+        parent: BPMN_ROLE.flowObject,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.activity),
+        labelFallback: 'Activity',
+    },
+    // The plain task — one unit of work, done by someone or something unnamed.
+    {
+        id: BPMN_ROLE.task,
+        parent: BPMN_ROLE.activity,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.task),
+        labelFallback: 'Task',
+    },
+    // The two typed tasks, under the plain one: they are tasks that also say WHO
+    // performs them. A rule about the work applies to all three; a rule about
+    // human hand-offs reads only the first.
+    {
+        id: BPMN_ROLE.taskUser,
+        parent: BPMN_ROLE.task,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.taskUser),
+        labelFallback: 'User task',
+    },
+    {
+        id: BPMN_ROLE.taskService,
+        parent: BPMN_ROLE.task,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.taskService),
+        labelFallback: 'Service task',
+    },
+    // Sub-process and call activity are activities but NOT tasks: a task is
+    // atomic and these two stand for a whole process each — one defined inline,
+    // one defined elsewhere and reused. Filing them under `bpmn:task` would make
+    // "every task is one unit of work" false.
+    {
+        id: BPMN_ROLE.subProcess,
+        parent: BPMN_ROLE.activity,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.subProcess),
+        labelFallback: 'Sub-process',
+    },
+    {
+        id: BPMN_ROLE.callActivity,
+        parent: BPMN_ROLE.activity,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.callActivity),
+        labelFallback: 'Call activity',
+    },
+    {
+        id: BPMN_ROLE.gateway,
+        parent: BPMN_ROLE.flowObject,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.gateway),
+        labelFallback: 'Gateway',
+    },
+    // The exclusive (XOR) gateway and the parallel (AND) one. Same diamond, and
+    // the marker inside is the only thing that tells them apart on the canvas —
+    // which is exactly why the marker must not be what a rule reads.
+    {
+        id: BPMN_ROLE.gatewayExclusive,
+        parent: BPMN_ROLE.gateway,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.gatewayExclusive),
+        labelFallback: 'Exclusive gateway',
+    },
+    {
+        id: BPMN_ROLE.gatewayParallel,
+        parent: BPMN_ROLE.gateway,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.gatewayParallel),
+        labelFallback: 'Parallel gateway',
+    },
+];
+/**
+ * Data — the paperwork, not the work.
+ *
+ * A family of its own, parent-less like the pool: a data object is never
+ * executed, never has a duration and is never on the happy path, so a rule
+ * written about the flow objects must not fall on it. The two leaves are the
+ * only distinction BPMN itself draws here — a data OBJECT lives and dies with
+ * the process instance, a data STORE outlives it.
+ */
+const DATA_DEFS = [
+    {
+        id: BPMN_ROLE.data,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.data),
+        labelFallback: 'Data',
+    },
+    {
+        id: BPMN_ROLE.dataObject,
+        parent: BPMN_ROLE.data,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.dataObject),
+        labelFallback: 'Data object',
+    },
+    {
+        id: BPMN_ROLE.dataStore,
+        parent: BPMN_ROLE.data,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.dataStore),
+        labelFallback: 'Data store',
+    },
+];
+/**
+ * The two artifacts — what the author drew ON the picture rather than IN it.
+ *
+ * Both parent-less and childless, and not siblings of each other either: they
+ * are not flow objects, not data and not frames, and the one thing every rule
+ * in this framework must agree on is that commentary is never evidence.
+ * Declared all the same, so a reader (and the audit) can tell an annotation
+ * from an unnamed rectangle somebody left behind.
+ *
+ * The GROUP is parent-less for a second reason, which is the spec's own: BPMN
+ * 2.0.2 §10.4 exempts it from every connection and containment constraint there
+ * is. It cannot be attached to a sequence or message flow, it is not bounded by
+ * the pool or lane it overlaps, and it may straddle several pools at once. A
+ * role under `bpmn:pool` or under any flow-object family would have made all
+ * three of those false by inheritance — the tree is where that exemption is
+ * written down.
+ *
+ * It is deliberately NOT the parent of the annotation, nor a child of it: one
+ * says something about a region, the other says something about a thing, and a
+ * rule about either must not fall on the other.
+ */
+const ARTIFACT_DEFS = [
+    {
+        id: BPMN_ROLE.textAnnotation,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.textAnnotation),
+        labelFallback: 'Text annotation',
+    },
+    {
+        id: BPMN_ROLE.group,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.group),
+        labelFallback: 'Group',
+    },
+];
+// The pool: the participant's own lane, the frame the flow objects are drawn in.
+// Parent-less, like `wardley:map` — a rule written on the flow objects must
+// never match the pool that holds them.
+const POOL_DEFS = [
+    {
+        id: BPMN_ROLE.pool,
+        kind: 'node',
+        labelKey: roleKey(BPMN_ROLE.pool),
+        labelFallback: 'Pool',
+    },
+];
+/**
+ * The two connecting objects.
+ *
+ * Neither specialises the other, and there is deliberately no `bpmn:flow`
+ * parent: a sequence flow stays inside one pool and orders the work, a message
+ * flow crosses between pools and carries nothing but the message. They are two
+ * different sentences, and a rule about one must never fall on the other.
+ */
+const FLOW_DEFS = [
+    /**
+     * The sequence flow, pre-authorised as a typed edge by `docs/adr/0010`.
+     *
+     * Tier 1 of that ADR is generic — `source` is the subject of the role's verb,
+     * `target` its object — and tier 2 is this `direction` block: the verb is "is
+     * followed by", so the source is what happens FIRST and the target is what
+     * comes next. That is the whole of what makes an arrow on this canvas a
+     * statement the author made rather than a by-product of which end their finger
+     * landed on first, and it is what the hover reveal reads back with the `bpmn`
+     * flag off.
+     */
+    {
+        id: BPMN_ROLE.sequenceFlow,
+        kind: 'edge',
+        labelKey: roleKey(BPMN_ROLE.sequenceFlow),
+        labelFallback: 'Sequence flow',
+        direction: {
+            verbKey: `${roleKey(BPMN_ROLE.sequenceFlow)}.verb`,
+            verbFallback: 'is followed by',
+            gestureHintKey: `${roleKey(BPMN_ROLE.sequenceFlow)}.gesture`,
+            gestureHintFallback: 'Drag from what happens first to what follows.',
+        },
+    },
+    /**
+     * The message flow — RESERVED.
+     *
+     * Declared in the vocabulary and stamped by nothing: the lean pack ships no
+     * creation tool for it, and the full pack adds one next session. It is written
+     * down now rather than later because the vocabulary is the one thing a stored
+     * document points at: an id declared today reads correctly whenever it is
+     * first written, whereas an id invented after the fact has to be reconciled
+     * with whatever the intervening months stamped.
+     *
+     * Its verb is its own — a message flow says nothing about ORDER, only about
+     * who told whom — which is precisely why it is not a child of the sequence
+     * flow.
+     */
+    {
+        id: BPMN_ROLE.messageFlow,
+        kind: 'edge',
+        labelKey: roleKey(BPMN_ROLE.messageFlow),
+        labelFallback: 'Message flow',
+        direction: {
+            verbKey: `${roleKey(BPMN_ROLE.messageFlow)}.verb`,
+            verbFallback: 'sends a message to',
+            gestureHintKey: `${roleKey(BPMN_ROLE.messageFlow)}.gesture`,
+            gestureHintFallback: 'Drag from the participant that sends the message to the one that receives it.',
+        },
+    },
+    /**
+     * The association — the line that ties an annotation or a data object to the
+     * work it is about.
+     *
+     * Declared WITHOUT a `direction`, and that is the whole point of it. Tier 1 of
+     * `docs/adr/0010` says an edge role names a relation with a VERB, source the
+     * subject and target the object; an association names no relation and has no
+     * verb. "This note is about that task" reads identically from either end, and
+     * the spec agrees: an association is undirected unless it carries data, which
+     * the descriptive profile does not.
+     *
+     * The consequence is deliberate and is the reason to write it down here: the
+     * hover reveal shows its LABEL and no sentence, and the "reverse direction"
+     * toolbar entry has nothing to offer — because there is no direction to be
+     * wrong about, so there is none to fix.
+     */
+    {
+        id: BPMN_ROLE.association,
+        kind: 'edge',
+        labelKey: roleKey(BPMN_ROLE.association),
+        labelFallback: 'Association',
+    },
+];
+const DEFS = [
+    ...FLOW_OBJECT_DEFS,
+    ...DATA_DEFS,
+    ...ARTIFACT_DEFS,
+    ...POOL_DEFS,
+    ...FLOW_DEFS,
+];
+// Null prototype: this is a lookup table keyed by ids that may one day come
+// from host-supplied packs, so `defs['toString']` must not resolve.
+export const BPMN_ROLES = Object.assign(Object.create(null), Object.fromEntries(DEFS.map(def => [def.id, def])));
+/**
+ * The legacy `kind` discriminant → the role it means.
+ *
+ * `kind` STAYS: it is persisted, it drives the renderer and it is what the
+ * palette writes. What it is not, from today, is the semantic authority — the
+ * ROLE is. The two are posted side by side at every creation site, the way
+ * Wardley already does it, and this table is the single place that says which
+ * kind means which role. Total over {@link BpmnNodeKind} by its type, so a new
+ * kind cannot land without being given a meaning.
+ */
+export const BPMN_ROLE_OF_KIND = {
+    startEvent: BPMN_ROLE.startEvent,
+    startEventMessage: BPMN_ROLE.startEventMessage,
+    startEventTimer: BPMN_ROLE.startEventTimer,
+    endEvent: BPMN_ROLE.endEvent,
+    endEventMessage: BPMN_ROLE.endEventMessage,
+    endEventTerminate: BPMN_ROLE.endEventTerminate,
+    task: BPMN_ROLE.task,
+    taskUser: BPMN_ROLE.taskUser,
+    taskService: BPMN_ROLE.taskService,
+    subProcess: BPMN_ROLE.subProcess,
+    callActivity: BPMN_ROLE.callActivity,
+    gatewayExclusive: BPMN_ROLE.gatewayExclusive,
+    gatewayParallel: BPMN_ROLE.gatewayParallel,
+    dataObject: BPMN_ROLE.dataObject,
+    dataStore: BPMN_ROLE.dataStore,
+    textAnnotation: BPMN_ROLE.textAnnotation,
+    group: BPMN_ROLE.group,
+};

package/dist/rules.d.ts

@@ -0,0 +1,199 @@
+import type { EndpointTriplet, ValidationRule } from '@formicoidea/labre-core/blocks/surface';
+/**
+ * BPMN validation rules — the descriptive profile, as DATA (backlog item B6).
+ *
+ * NOTE ON NUMBERING: that "B6" is the BACKLOG item this file delivers. The
+ * **B1**–**B21** headings below are RULE numbers, a different space entirely,
+ * and the two collide on one token. Every in-file cross-reference means the rule
+ * number; the backlog item is named nowhere else.
+ *
+ * DATA owned by the framework, versioned per rule: the engine
+ * (`@labre/affine-block-surface`) knows how to evaluate a FAMILY, never a
+ * concrete rule, so adding a BPMN rule is adding an entry to the array at the
+ * bottom of this file. Registered from the flag-gated `BpmnViewExtension`, so
+ * switching the `bpmn` flag off removes the rules with the rest of the tooling
+ * — processes already drawn keep rendering, they simply stop being checked
+ * (`docs/adr/0009`).
+ *
+ * ## Every rule is read off the SPEC, and cites where
+ *
+ * The page references below are to **BPMN 2.0.2 (OMG / ISO-IEC 19510)**, which
+ * the PO supplied. They are not decoration: three rules in the first draft of
+ * this pack fired on diagrams the specification explicitly sanctions, and the
+ * only thing that caught them was reading the normative text rather than the
+ * folklore.
+ *
+ * ## And every rule now DECLARES where its authority comes from
+ *
+ * The citations above used to live in these comments alone, which meant the UI
+ * could not tell a conformance defect from a house style: a Labre convention
+ * presented to an architect as a norm violation is the finding an external
+ * review will not forgive. {@link ValidationRule.provenance} promotes the
+ * distinction to data — `standard` for a normative MUST with its page,
+ * `recommendation` for a SHOULD or an industry linter, `labre-convention` for
+ * ours — and the violation bubble says which.
+ *
+ * Two rules here are `labre-convention` and neither pretends otherwise:
+ * {@link sequenceFlowSelfLoop} and {@link untypedFlow}. The first exists as a
+ * separate rule BECAUSE of this field: it was a clause of B1, whose matrix is
+ * p.95, and one rule cannot honestly declare two provenances — see B1a.
+ *
+ * ## Why BPMN is the framework that needed five families
+ *
+ * A Wardley map is judged element by element: where a thing sits, which way an
+ * arrow points. A process is judged by its JOINTS. Every question below is about
+ * a relation, a count of relations, the frames two ends sit in, or the graph the
+ * relations build — which is why four of the five families arrived with the
+ * engine work that preceded this file, and why none of them names BPMN.
+ *
+ * - `relation-endpoints` (B1–B5) — WHAT a link may run between, and how many
+ *   times. The grammar.
+ * - `edge-degree` (B6–B10, B16–B19) — HOW MANY links arrive at and leave one
+ *   symbol. The half no per-link rule can express: nothing is wrong with any
+ *   single arrow, the mistake is the count.
+ * - `edge-locality` (B11–B12) — WHICH POOL each end sits in. The swimlane
+ *   question, and the one where the two ends carry identical roles in the legal
+ *   case and the illegal one.
+ * - `role-count` (B14–B15, B20) — what one pool must CONTAIN, and only when it
+ *   already contains the other half of the pair.
+ * - `reachability` (B13) — can you get there from the start. The graph question.
+ * - `label-presence` (B21) — does the symbol carry a name at all.
+ *
+ * ## The industry linters, and where we deliberately differ
+ *
+ * The inventory was triangulated against **bpmnlint** (the bpmn-js ecosystem's
+ * linter, the one a BPMN practitioner will already have met),
+ * bpmn-visualization-js and JointJS. Where a bpmnlint rule reads the same
+ * normative sentence we do, the id and the wording are chosen so a user
+ * recognises it; where we are quieter, the rule comment says why in its own
+ * paragraph. Two of theirs are NOT adopted:
+ *
+ * - **`no-implicit-start`** (ERROR there). It contradicts p.238: a Process is not
+ *   required to contain a Start Event, and a flow object with no incoming
+ *   sequence flow is then a legitimate parallel start (p.245). We sided with the
+ *   specification — that decision is what
+ *   {@link ReachabilityDef.implicitRoots} implements, and adopting the
+ *   linter's rule would have meant shipping the two in contradiction.
+ * - **any overlap / readability rule.** The engine's pair-wise budget is pinned
+ *   by the Wardley bench, which asserts that `wardley.overlapping-artefacts` is
+ *   the ONLY registered `no-overlap` rule — a second one triggers the
+ *   spatial-index obligation. That is a piece of engine work with its own
+ *   measurements, not a line of data, so it is a backlog item and not this file.
+ *
+ * ## Severity: `warning` almost everywhere, `audit` where the spec allows the
+ * shape, and `blocking-overridable` nowhere
+ *
+ * The same promise `wardley/rules.ts:30` makes, for the same reason: NOTHING
+ * downstream implements a blocking level — no gesture is refused anywhere in
+ * this library — so shipping the value would be data claiming an effect that
+ * does not exist. Several of these are normative MUSTs and would sit there; they
+ * move in one line each, in `profiles.ts`, the day the gesture refusal lands.
+ *
+ * Five rules are declared `audit` on their own — `bpmn.activity-dead-end`,
+ * `bpmn.fake-join`, `bpmn.implicit-split`, `bpmn.single-blank-start` and
+ * `bpmn.unlabeled-step` — because in each case the specification sanctions the
+ * shape they report, or the diagram is merely unfinished. They are NUANCES for
+ * the conformance panel, never warnings on the canvas, and every one of them is
+ * quieter than the corresponding bpmnlint level on purpose.
+ *
+ * The severities declared here are the DESCRIPTIVE posture; `bpmn.sketch` — the
+ * default — demotes every one of them to `audit`, so the drawing hand is never
+ * argued with until someone asks for the stricter profile. See `profiles.ts`.
+ *
+ * ## What the whole file stays silent about
+ *
+ * A process drawn before the roles existed carries no role on anything, so it is
+ * never evaluated and never says a word (PRD principle 8). A process drawn
+ * before anybody added a pool has no frame for B11–B15 and B20 to be about, and those
+ * six are silent by construction.
+ *
+ * ## One thing the `relation-endpoints` family cannot say
+ *
+ * The ALPHABET of a `relation-endpoints` rule is derived from the roles its
+ * sanctioned triplets name. That is what makes the family proportionate — an end
+ * outside the alphabet takes the whole link out of the conversation, so a flow
+ * drawn onto a sticky note is a draft and not a finding — and it is also its one
+ * limit: **a framework cannot name a role it wants to REJECT without sanctioning
+ * a sentence for it.**
+ *
+ * Three normative prohibitions are therefore SILENCE rather than findings today:
+ *
+ * - "an Artifact MUST NOT be the source or target of a Sequence Flow" (p.65) and
+ *   "a Sequence Flow connects Events, Activities and Gateways" (p.95) — a
+ *   sequence flow dropped on a text annotation or a data object goes unjudged;
+ * - the Message Flow Connection Rules table (p.41–42), which lists what a
+ *   message may run between and then says "Thus, Lane, Gateway, Data Object,
+ *   Group, and Text Annotation are not listed in the table" — a gateway is
+ *   named by no message sentence, so it is outside B2's alphabet.
+ *
+ * Reported to the engine author rather than worked around here: a triplet
+ * written to widen an alphabet without meaning what it says would be exactly the
+ * data-that-lies this platform refuses everywhere else. The corpus pins the
+ * silence explicitly (`corpus.unit.spec.ts`), so it stays a known limit rather
+ * than an assumption.
+ *
+ * ## The engine fields this pack asked for, and now uses
+ *
+ * Six of the rules below were authored against defs that did not exist when they
+ * were written, and `claude/bpmn-engine-v2` (#145) landed all six:
+ * `RoleCountDef.ifPresent` and `.exact`, `EdgeDegreeDef.forbidPattern` and
+ * `.eitherMin`, `ReachabilityDef.implicitRoots`, and the `label-presence`
+ * family. Every one of the rules below is registered and live.
+ *
+ * Two of them are worth knowing about at the call site:
+ *
+ * - `forbidPattern` carries its OWN {@link RuleMessage} inside the pattern
+ *   rather than in a slot beside the other bounds, because a forbidden zone is
+ *   not a bound that failed and its sentence never reads like one;
+ * - `label-presence` reads the subject's OWN `text`. A framework whose artefacts
+ *   are named by a separate element beside them is asking a different question,
+ *   and this family cannot answer it. BPMN names its steps in place, so it can.
+ */
+/**
+ * `eitherMin` was also shipped, and this pack deliberately does not use it.
+ *
+ * It and `forbidPattern: { maxIn: 1, maxOut: 1 }` select exactly the same set of
+ * nodes — the engine ships a test asserting they agree across the whole degree
+ * space — so {@link gatewayMustBranch} could be written either way. It is
+ * written as a forbidden zone because that is what its SENTENCE says: "this
+ * gateway neither splits nor merges" describes a shape the diagram has, not a
+ * count it is missing, and the data reads best when it says what the message
+ * says. Nothing is wrong with the other reading; a rule simply has to pick one.
+ */
+/**
+ * The one sanctioned sentence of a sequence flow: a flow object is followed by a
+ * flow object (p.95 — "a Sequence Flow connects Events, Activities and
+ * Gateways").
+ *
+ * Written on `bpmn:flow-object` rather than on the three families under it, which
+ * is what makes it ONE triplet instead of nine: `roleIsA` resolves it for every
+ * event, activity and gateway, and for whatever the descriptive profile adds
+ * under them later.
+ *
+ * Exported so a test asserts THIS table rather than a copy of it, and so B4
+ * declares the same alphabet it judges neutral links against without restating
+ * it — see {@link untypedFlow}.
+ */
+export declare const BPMN_SEQUENCE_MATRIX: readonly EndpointTriplet[];
+/**
+ * The pack, whole: twenty-two rules, all registered, all live.
+ *
+ * Eight of them were authored ahead of the engine and sat in a held-out array
+ * for one review cycle, because two would have been actively WRONG meanwhile —
+ * an engine with no `ifPresent` reads B14/B15 as the unconditional "every pool
+ * holds a start event" the specification review removed, which fires on a
+ * conformant black-box pool. `claude/bpmn-engine-v2` (#145) landed every field
+ * they asked for, so the array is gone and the split with it.
+ *
+ * The twenty-second is B1a, and it is not a new REQUIREMENT: the no-self-loop
+ * clause left B1 so that each of the two could declare its own provenance
+ * honestly. Nothing new fires, nothing new is said, and the two i18n keys are
+ * the ones the clause already shipped.
+ *
+ * Every one of the twenty-two declares {@link ValidationRule.provenance}:
+ * twelve `standard`, each with its page; eight `recommendation`, each naming a
+ * linter or the sentence the specification merely permits; two
+ * `labre-convention`. Nothing here is `organization` — that source is reserved
+ * for the org profiles the PRD names, and no framework declares one yet.
+ */
+export declare const BPMN_RULES: readonly ValidationRule[];