@bpmnkit/docspack 0.0.2 → 0.0.4

package/.llms/chunks/packages.core.installation-bpmn.makeempty-processid-processname.md

@@ -8,4 +8,4 @@ const xml = Bpmn.makeEmpty("my-process", "My Process");
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-bpmn.parse-xml.md

@@ -7,4 +7,4 @@ const definitions = Bpmn.parse(xmlString);
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-bpmn.sample_xml.md

@@ -4,4 +4,4 @@ A constant containing a simple 3-node sample diagram (start → task → end).
 Useful for demos and tests.
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-compactify-definitions.md

@@ -1,7 +1,15 @@
 # @bpmnkit/core — Installation — `compactify(definitions)`
 
-Converts a `BpmnDefinitions` object to a `CompactDiagram` — a small JSON object
-suitable for LLM prompts.
+Projects a `BpmnDefinitions` object onto a `CompactDiagram` — a small JSON object suitable
+for LLM prompts. **Lossy:** it keeps topology, names, `<bpmn:documentation>` and the common
+Zeebe bindings, and drops collaborations, participants, message flows, lanes, data stores,
+artifacts, root-level messages and errors, multi-instance loop characteristics, full
+`zeebe:ioMapping` entries and diagram interchange.
+
+`documentation` is carried on every element and on the process itself, because in Camunda 8 it
+is not decoration: on an ad-hoc sub-process child it is the tool description handed to the LLM,
+and on a start event it is where the process input contract is written. It had been dropped, so
+a single `rename` operation cost a file the documentation of every element in it.
 
 ```typescript
 import { compactify } from "@bpmnkit/core";
@@ -10,4 +18,4 @@ const compact = compactify(Bpmn.parse(xml));
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-createflowelement-id-type-options.md

@@ -0,0 +1,7 @@
+# @bpmnkit/core — Installation — `createFlowElement(id, type, options?)`
+
+Builds an empty flow element of any `BpmnElementType`, with the right shape for that type.
+This is the single place that mapping lives; the fluent builder uses it too.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-diagrambuilder-collaborations.md

@@ -0,0 +1,35 @@
+# @bpmnkit/core — Installation — DiagramBuilder — collaborations
+
+`.participant()`, `.message()` and `.messageFlow()` build a pooled diagram. Ids are used
+verbatim, so a generated diagram can be referred to by the ids you chose.
+
+```typescript
+const defs = Bpmn.createDiagram("Order")
+  .process("order", (p) => p.startEvent("o_start").serviceTask("o_send", { taskType: "send" }).endEvent("o_end"))
+  .process("supply", (p) => p.startEvent("s_start").serviceTask("s_recv", { taskType: "recv" }).endEvent("s_end"))
+  .participant("P_Buyer", { name: "Buyer", processId: "order" })
+  .participant("P_Seller", { name: "Seller", processId: "supply" })
+  .participant("P_Bank", { name: "Bank" })            // black box — no process
+  .message("Msg_Order", { name: "order placed", correlationKey: "= orderId" })
+  .messageFlow("MF_1", { source: "o_send", target: "s_recv", messageRef: "Msg_Order" })
+  .build();
+```
+
+A message flow's `source` and `target` name either participants or flow nodes inside them —
+both are valid BPMN, and `applyAutoLayout` reads either.
+
+A diagram with no participants gets **no** collaboration element. An empty
+`<bpmn:collaboration/>` is not a neutral addition: a modeler reads it as "this document is
+pooled" and renders every process pool-less.
+
+`.collaborationId(id)` renames the collaboration, which defaults to `"Collaboration_1"`.
+
+`build()` refuses a collaboration a modeler would not open, reporting every problem at once:
+a participant naming a process the diagram does not contain, two participants claiming the
+same process, a duplicate id, a message flow whose endpoint does not exist or which names an
+undeclared message, and — the one that is easy to write by accident — a message flow that
+starts and ends in the same pool. A message flow is what crosses a pool boundary; one that
+stays inside a pool should be a sequence flow.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-diffdiagram-before-after.md

@@ -0,0 +1,33 @@
+# @bpmnkit/core — Installation — `diffDiagram(before, after)`
+
+What a *reviewer* would see change — `diffSemantics()` plus the layout half it deliberately
+ignores, restricted to elements a canvas can actually draw.
+
+```typescript
+import { diffDiagram } from "@bpmnkit/core";
+
+const result = diffDiagram(before, after);
+result.added;    // ids only in `after`
+result.removed;  // ids only in `before`
+result.changed;  // same element, different semantics
+result.moved;    // same semantics, different place on the canvas
+result.total;
+result.planes;   // per-plane breakdown — a change inside a collapsed sub-process
+                 // is invisible in a viewer until the reader drills into it
+```
+
+`moved` is why this exists. The semantic hash drops all diagram interchange — that is what
+makes it stable across a re-layout — so a task somebody dragged reads as no change at all in
+`diffSemantics()`. Here the geometry is compared separately from DI (bounds, waypoints, label
+placement, and flags such as collapsed/expanded). An element that changed *and* moved is
+reported as changed, since a semantic change is what a reviewer needs first.
+
+An element with nothing to draw on either side is left out, so a changed `targetNamespace`
+cannot inflate a count against nothing on screen.
+
+The same comparison is [`casen diff bpmn`](/docs/cli/diff) on the command line,
+`createBpmnDiff()` in `@bpmnkit/plugins` on a pair of canvases, and *Compare Diagram with
+HEAD* in the [VS Code extension](/docs/guides/vscode).
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-diffsemantics-before-after.md

@@ -0,0 +1,15 @@
+# @bpmnkit/core — Installation — `diffSemantics(before, after)`
+
+What changed between two models, as `{ added, removed, changed }` keyed by element id. Changes
+are attributed to the element that actually changed rather than to all of its ancestors, and
+running auto-layout produces an empty diff.
+
+```typescript
+import { diffSemantics } from "@bpmnkit/core";
+
+const { added, removed, changed } = diffSemantics(before, after);
+// changed: [{ id: "Task_1", before: {...}, after: {...} }]
+```
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-element-catalog.md

@@ -0,0 +1,10 @@
+# @bpmnkit/core — Installation — Element catalog
+
+`ELEMENT_TYPE_GROUPS` maps every `BpmnElementType` to one of `event`, `task`, `gateway`,
+`container` or `data`, with `allElementTypes()` and `elementTypesInGroup(group)` over it. Tool
+schemas and prompts render their type lists from this rather than hard-coding one — a
+hand-written list is how the MCP schema came to advertise 18 types while the compact path
+accepted 23.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-ensurezeebeextension-owner-extension.md

@@ -0,0 +1,32 @@
+# @bpmnkit/core — Installation — `ensureZeebeExtension(owner, extension)`
+
+Finds a Zeebe extension element on a flow element, creating it if absent, and refuses a
+placement the Zeebe schema does not allow. Use it instead of pushing onto `extensionElements`
+directly: the push cannot fail, so `zeebe:calledDecision` on a service task becomes a deploy
+error in Camunda rather than a throw where it was written.
+
+```typescript
+import { ensureZeebeExtension, ZeebePlacementError } from "@bpmnkit/core";
+
+ensureZeebeExtension(serviceTask, "zeebe:taskDefinition").attributes.type = "worker";
+ensureZeebeExtension(serviceTask, "zeebe:calledDecision"); // throws ZeebePlacementError
+```
+
+`ZeebePlacementError` carries `ownerElement`, `extension` and `allowedOn`, so the message
+names the elements that *would* have been valid.
+
+`isZeebePlacementAllowed(ownerElement, extension)` answers the same question without throwing,
+and `ZEEBE_PLACEMENT` is the table itself — extension name to the element names that may own it.
+
+The table is generated from `zeebe.json`'s `meta.allowedIn` (`zeebe-bpmn-moddle`, MIT),
+resolved against the BPMN type graph, so it states the schema's rules rather than ours. **An
+extension the schema says nothing about is allowed**: the descriptor declares no owner for
+`zeebe:subscription` or `zeebe:properties`, and inventing a rule there would reject valid
+documents. Non-`zeebe:` extensions are not checked at all.
+
+`applyBpmnOperations` runs the same check, and reports a misplaced extension as an ordinary
+operation problem — checked before anything is written, so the element is left untouched and
+the rest of the batch still applies.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-expand-compact.md

@@ -1,6 +1,8 @@
 # @bpmnkit/core — Installation — `expand(compact)`
 
-Converts a `CompactDiagram` back to a `BpmnDefinitions` object.
+Builds a `BpmnDefinitions` object from a `CompactDiagram`. It restores only what the compact
+form carries, so `expand(compactify(definitions))` is not `definitions` — use this to build a
+model from a compact definition, not as a round trip for a file you need to keep.
 
 ```typescript
 import { expand } from "@bpmnkit/core";
@@ -9,5 +11,9 @@ const definitions = expand(compactDiagram);
 const xml = Bpmn.export(definitions);
 ```
 
+Every element type the model knows expands to itself, data elements included. The switch is
+exhaustive, so a new `BpmnElementType` fails the build here rather than silently arriving as a
+`task` — which is how `dataObject`, `dataObjectReference` and `dataStoreReference` were lost.
+
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-joins-inferred-by-default-or-declared.md

@@ -0,0 +1,28 @@
+# @bpmnkit/core — Installation — Joins: inferred by default, or declared
+
+Where several branches of one gateway reach the same element, `build()` inserts a matching
+join gateway for you. That is a help when you are reading the chain you just wrote, and a trap
+for generated code, which cannot see the element it did not emit.
+
+```typescript
+const defs = builder.build({ explicitJoins: true });
+// Error: Inferred join gateways: gw_join. Declare them with .connectTo(joinId),
+// or drop { explicitJoins: true } to keep the inference.
+```
+
+The error names the gateway it would have added, which is the id you pass to `.connectTo()`.
+
+A join you declare only counts if it **matches the split**: an exclusive split converging on a
+parallel gateway is not the gateway inference would have added, so it is still inferred — and
+with `explicitJoins` that refusal is the only thing that tells you.
+
+`Bpmn.continueProcess()` never infers joins at all, whatever this option says. Inference reads
+the whole topology, and on a document you were handed that means rewriting edges you never
+touched.
+
+`{ strict: true }` is the former name for this option and still works. It was renamed because
+"strict" says nothing about what it is strict *about*, and because `applyBpmnOperations` takes
+a `strict` that means something else entirely.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-layoutprocess-process.md

@@ -12,4 +12,4 @@ const result = layoutProcess(process);
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-processbuilder-methods.md

@@ -9,11 +9,20 @@ All builder methods return `this` for chaining.
 | `.serviceTask(id, options?)` | Add a service task |
 | `.userTask(id, options?)` | Add a user task |
 | `.scriptTask(id, options?)` | Add a script task |
+| `.sendTask(id, options?)` | Add a send task |
+| `.receiveTask(id, options?)` | Add a receive task |
+| `.businessRuleTask(id, options?)` | Add a business rule task |
+| `.manualTask(id, options?)` | Add a manual task — work done outside the engine, no job worker |
+| `.task(id, options?)` | Add an abstract task with no Zeebe extensions |
 | `.exclusiveGateway(id, options?)` | Add an XOR gateway |
 | `.parallelGateway(id, options?)` | Add a parallel gateway |
 | `.inclusiveGateway(id, options?)` | Add an inclusive gateway |
 | `.eventBasedGateway(id, options?)` | Add an event-based gateway |
+| `.complexGateway(id, options?)` | Add a complex gateway (aspirational — Zeebe does not execute these) |
 | `.subProcess(id, builder, options?)` | Add an embedded sub-process |
+| `.adHocSubProcess(id, builder, options?)` | Add an ad-hoc sub-process — its children are **not** auto-chained, see below |
+| `.eventSubProcess(id, builder, options?)` | Add an event sub-process (emits `subProcess triggeredByEvent="true"`) |
+| `.transaction(id, builder, options?)` | Add a transaction sub-process (atomic scope) |
 | `.callActivity(id, options?)` | Add a call activity |
 | `.intermediateCatchEvent(id, options?)` | Add a catch event |
 | `.intermediateThrowEvent(id, options?)` | Add a throw event |
@@ -23,7 +32,13 @@ All builder methods return `this` for chaining.
 | `.defaults(options)` | Set process-wide defaults (e.g. `{ serviceTask: { retries: "5" } }`) applied to all subsequent tasks |
 | `.disconnectedStartEvent(id?, options?)` | Add a start event with no auto-connection to the current cursor — alias for `addStartEvent` |
 | `.withAutoLayout()` | Apply Sugiyama layout before building |
-| `.build(options?)` | Return the completed `BpmnDefinitions`. Pass `{ strict: true }` to throw if auto-join gateways are inserted (encourages explicit topology) |
+| `.build(options?)` | Return the completed `BpmnDefinitions`. Pass `{ explicitJoins: true }` to refuse inferred join gateways — see below |
+
+Every BPMN element type the model knows is reachable from a builder chain, except the three
+data types (`dataObject`, `dataObjectReference`, `dataStoreReference`) — those are wired by
+data associations rather than sequence flows, so the chain has nowhere to put them. A
+compile-time table, `BUILDER_COVERAGE`, holds the SDK to that: adding an element type without
+a builder method fails the build. Run `pnpm --filter @bpmnkit/core check:builder` to print it.
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-projectsemantics-definitions.md

@@ -0,0 +1,7 @@
+# @bpmnkit/core — Installation — `projectSemantics(definitions)`
+
+The canonical, presentation-free projection `semanticHash` covers. Returns `{ value, elements }`
+— the whole model as canonical JSON, plus a shallow projection per element id.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-reconcilecompact-definitions-compact-options.md

@@ -0,0 +1,12 @@
+# @bpmnkit/core — Installation — `reconcileCompact(definitions, compact, options?)`
+
+Applies a `CompactDiagram` to an existing model as a set of changes. Elements that already
+exist are patched in place and keep their extensions, new ones are inserted, and ones the input
+no longer mentions are removed — where `expand(compact)` would rebuild the whole document and
+discard everything the compact form cannot describe.
+
+Processes are only added, never removed: sending one process of a multi-process document means
+"this is how that process should look", not "delete the others".
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-retypeelement-element-type.md

@@ -0,0 +1,20 @@
+# @bpmnkit/core — Installation — `retypeElement(element, type)`
+
+Returns a copy of a flow element with a different `type`, keeping its id, name, documentation
+and — crucially — its incoming and outgoing sequence flows. Use this to change a task's type
+instead of removing and re-adding the element, which drops the wiring.
+
+```typescript
+import { retypeElement } from "@bpmnkit/core";
+
+const index = process.flowElements.findIndex((el) => el.id === "charge");
+process.flowElements[index] = retypeElement(process.flowElements[index], "manualTask");
+```
+
+Nested content is carried between container types, and a multi-instance marker between types
+that both allow one. Zeebe extensions the new type cannot legally hold are dropped, using the
+same placement table `ensureZeebeExtension` enforces — so a `serviceTask` retyped to
+`manualTask` does not keep a job worker the engine would refuse.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation-semantichash-definitions.md

@@ -0,0 +1,23 @@
+# @bpmnkit/core — Installation — `semanticHash(definitions)`
+
+SHA-256 of the model's meaning, with the diagram excluded. Two documents that say the same
+thing hash the same however they are laid out, ordered or formatted — so a changed hash means
+the model changed, not that the picture moved.
+
+```typescript
+import { Bpmn, applyAutoLayout, semanticHash } from "@bpmnkit/core";
+
+const definitions = Bpmn.parse(xml);
+semanticHash(applyAutoLayout(definitions)) === semanticHash(definitions); // true
+```
+
+Excluded from the hash: diagram interchange and its `bioc`/`color` extensions,
+`zeebe:modelerTemplateIcon`, and `exporter`/`exporterVersion`. Element order, attribute order
+and whitespace do not affect it. `modeler:executionPlatform` **is** included — it names the
+engine the model targets, so changing it is a real change.
+
+Synchronous and dependency-free, so it works in the browser and does not force callers to
+become async.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.installation.md

@@ -8,4 +8,4 @@ pnpm add @bpmnkit/core
 ## API Reference
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.overview.md

@@ -4,7 +4,7 @@
 BPMN 2.0 programmatically:
 
 - **Fluent builder** — chain method calls to construct any process shape
-- **Parser/serializer** — round-trip any BPMN 2.0 XML with full fidelity
+- **Parser/serializer** — round-trip BPMN 2.0 XML, keeping unmodelled content verbatim
 - **Auto-layout** — Sugiyama algorithm assigns coordinates automatically
 - **Compact format** — token-efficient AI-friendly intermediate representation
 - **DMN support** — parse, build, and export DMN 1.3 decision tables
@@ -12,4 +12,4 @@ BPMN 2.0 programmatically:
 Zero runtime dependencies. ESM-only. Runs in browsers, Node.js, Deno, Bun, and edge runtimes.
 
 ---
-Source: https://docs.bpmnkit.com/packages/core/
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.writing-files-bpmnkit-core-node-exportpreserving-original-definitions.md

@@ -0,0 +1,51 @@
+# @bpmnkit/core — Writing files — `@bpmnkit/core/node` — `exportPreserving(original, definitions)`
+
+Writes a model back over the file it came from, changing as little as possible.
+
+`Bpmn.export()` writes a model the way this toolkit writes models. That is the right output
+for a new document and the wrong one for an existing file: the first visual edit reformats
+every line, and the commit says "the whole diagram" when it means "a box moved".
+
+Exported from `@bpmnkit/core` itself, not the `/node` subpath — it is string work, and the
+caller owns the file:
+
+```typescript
+import { readFile, writeFile } from "node:fs/promises";
+import { Bpmn, exportPreserving } from "@bpmnkit/core";
+
+const onDisk = await readFile("order.bpmn", "utf8");
+const edited = Bpmn.parse(onDisk);
+edited.processes[0].flowElements[0].name = "Validate Order";
+
+await writeFile("order.bpmn", exportPreserving(onDisk, edited));
+// Renaming one task changes one line, not the whole file.
+```
+
+Indentation, attribute order, comments, the order children were written in, and attributes
+left at their schema default all survive. Opening a file and writing it back unchanged leaves
+it byte for byte.
+
+Nothing about that is assumed, though. The model cannot represent the order a file writes its
+children in — a process holds `flowElements` and `sequenceFlows` as separate lists — so each
+strategy is tried, **the result is parsed back and compared against a plain write**, and the
+first that reads the same is the one used. The plain write is the floor, so calling this is
+never worse than not.
+
+| Function | Takes | Returns |
+| --- | --- | --- |
+| `exportPreserving(original, definitions)` | the file's current text + a model | the new text |
+| `exportPreservingResult(original, definitions)` | same | the text plus what it managed to keep |
+| `preserveBpmnFormatting(original, updated)` | two documents as text | for a caller that already serialised, such as an editor's `exportXml()` |
+| `exportDmnPreserving` / `preserveDmnFormatting` | DMN | the same treatment |
+| `exportFormPreserving` / `preserveFormFormatting` | Camunda form JSON | indentation, key order and trailing newline |
+
+This is what the [VS Code extension](/docs/guides/vscode) saves through, and what makes a
+visual edit reviewable in a pull request.
+
+Builder output is stable for the same reason: sequence-flow and root-definition ids are
+derived from the model (`Flow_<source>_<target>`, `Message_<name>`, `Error_<code>`) rather
+than randomly generated, so rebuilding an unchanged model produces the same file and the one
+edge that changed is not buried in a diff of edges that did not.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.writing-files-bpmnkit-core-node-writebpmn-definitions-options.md

@@ -0,0 +1,38 @@
+# @bpmnkit/core — Writing files — `@bpmnkit/core/node` — `writeBpmn(definitions, options)`
+
+The only supported way to write a BPMN file, and the only one that checks what it wrote.
+Before anything reaches disk it serialises the model, **parses the result back**, and compares
+the semantic hashes. If they differ the write is refused and nothing is written.
+
+```typescript
+import { writeBpmn } from "@bpmnkit/core/node";
+import { WriteError, WriteVerificationError } from "@bpmnkit/core";
+
+const result = await writeBpmn(definitions, {
+  output: "flow.bpmn",
+  force: false,        // default — refuses rather than replace an existing file
+  layout: "preserve",  // default — "auto" regenerates the diagram first
+});
+
+result.destination;    // absolute path written
+result.semanticHash;   // the model's hash, verified after reading it back
+result.outputSha256;   // digest of the exact bytes on disk
+result.changes;        // what this write changed about the file it replaced
+```
+
+The file appears complete or not at all: contents go to a temporary file in the destination's
+own directory and are then linked or renamed into place, so an interrupted write cannot leave
+a half-written model behind. Two concurrent writes to the same new path cannot both succeed.
+
+`WriteVerificationError` carries a `changes` field naming the elements that diverged.
+`WriteError` means the destination exists and `force` was not given, or the filesystem refused.
+
+**What the check does not cover.** It compares the model in memory against the model read back
+from the output, so it catches the serialiser losing something. It cannot catch the *parser*
+having dropped something on the way in — content the parser never saw is absent from both
+sides. That is what the round-trip corpus gate covers, and there is deliberately no option to
+skip verification: turning it off would only ever be used to get past the bug it exists to
+report. If you want unchecked serialisation, `Bpmn.export()` still returns a string.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.core.writing-files-bpmnkit-core-node.md

@@ -0,0 +1,7 @@
+# @bpmnkit/core — Writing files — `@bpmnkit/core/node`
+
+Anything that touches the filesystem lives behind the `@bpmnkit/core/node` subpath, so
+importing `@bpmnkit/core` itself never pulls `node:` builtins into a browser bundle.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/packages.docspack.installation.md

@@ -32,7 +32,7 @@ When you're ready for production, deploy to a real Camunda 8 cluster:
 ...
 
 ---
-Source: https://docs.bpmnkit.com/getting-started/quick-start/
+Source: /docs/getting-started/quick-start
 
 ---
 cost: 1,204 tokens, capped at 3,000
@@ -42,4 +42,4 @@ Every answer names the package, the version and the chunk it came from, and clos
 what it cost. An agent can quote the chunk id back when a passage turns out to be wrong.
 
 ---
-Source: https://docs.bpmnkit.com/packages/docspack/
+Source: https://bpmnkit.com/docs/packages/docspack

package/.llms/chunks/packages.docspack.overview.md

@@ -20,4 +20,4 @@ does the same job with no extra tooling.
 - Zero runtime dependencies
 
 ---
-Source: https://docs.bpmnkit.com/packages/docspack/
+Source: https://bpmnkit.com/docs/packages/docspack

package/.llms/chunks/packages.docspack.reading-it-yourself.md

@@ -31,4 +31,4 @@ with the versions installed.
 Options: `--limit <n>`, `--max-tokens <n>`, `--pack <name>`, `--cwd <dir>`.
 
 ---
-Source: https://docs.bpmnkit.com/packages/docspack/
+Source: https://bpmnkit.com/docs/packages/docspack

package/.llms/chunks/packages.docspack.trust.md

@@ -10,4 +10,4 @@ security boundary rather than as configuration:
 - packages under the `@docspack-community` scope are labelled unreviewed in every answer
 
 ---
-Source: https://docs.bpmnkit.com/packages/docspack/
+Source: https://bpmnkit.com/docs/packages/docspack

package/.llms/chunks/packages.docspack.using-the-index-directly.md

@@ -21,7 +21,7 @@ console.log(`${tokens} tokens`);
 
 ## How the pack is built
 
-`bpmnkit-docs build` reads the Markdown under `apps/docs/src/content/docs`, splits each
+`bpmnkit-docs build` reads the Markdown under `apps/landing/src/content/docs`, splits each
 document at its `##` headings, and writes one file per chunk:
 
 ```
@@ -49,4 +49,4 @@ You can steer either from the document itself:
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/docspack/
+Source: https://bpmnkit.com/docs/packages/docspack

package/.llms/chunks/packages.editor.basic-setup.md

@@ -38,4 +38,4 @@ const hud = initEditorHud(editor, {
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/editor/
+Source: https://bpmnkit.com/docs/packages/editor

package/.llms/chunks/packages.editor.full-editor-with-all-plugins.md

@@ -27,4 +27,4 @@ const hud = initEditorHud(editor, { aiButton: dock.aiPane.button });
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/editor/
+Source: https://bpmnkit.com/docs/packages/editor

package/.llms/chunks/packages.editor.hud-options.md

@@ -38,4 +38,4 @@ type SideDock = {
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/editor/
+Source: https://bpmnkit.com/docs/packages/editor

package/.llms/chunks/packages.editor.overview.md

@@ -18,4 +18,4 @@ pnpm add @bpmnkit/editor
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/editor/
+Source: https://bpmnkit.com/docs/packages/editor

package/.llms/chunks/packages.engine.installation.md

@@ -74,4 +74,4 @@ const processes = engine.getDeployedProcesses();
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/engine/
+Source: https://bpmnkit.com/docs/packages/engine

package/.llms/chunks/packages.engine.overview.md

@@ -16,4 +16,4 @@ JavaScript runtime — no external services required.
 Zero runtime dependencies. ESM-only.
 
 ---
-Source: https://docs.bpmnkit.com/packages/engine/
+Source: https://bpmnkit.com/docs/packages/engine

package/.llms/chunks/packages.engine.processinstance.md

@@ -14,4 +14,4 @@
 | `instance.deliverMessage(name, vars?)` | Correlate a message to a waiting event |
 
 ---
-Source: https://docs.bpmnkit.com/packages/engine/
+Source: https://bpmnkit.com/docs/packages/engine

package/.llms/chunks/packages.engine.variable-scoping.md

@@ -24,4 +24,4 @@ Call `parseDurationMs(str)` from `@bpmnkit/engine` to convert duration strings
 to milliseconds in your own code.
 
 ---
-Source: https://docs.bpmnkit.com/packages/engine/
+Source: https://bpmnkit.com/docs/packages/engine

package/.llms/chunks/packages.worker-client.client.poll-jobtype-options.md

@@ -37,4 +37,4 @@ interface ActivatedJob {
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/worker-client/
+Source: https://bpmnkit.com/docs/packages/worker-client

package/.llms/chunks/packages.worker-client.createworkerclient-options.md

@@ -29,4 +29,4 @@ const client = createWorkerClient({
 A `WorkerClient` object with a single `poll()` method.
 
 ---
-Source: https://docs.bpmnkit.com/packages/worker-client/
+Source: https://bpmnkit.com/docs/packages/worker-client

package/.llms/chunks/packages.worker-client.job.complete-variables.md

@@ -26,4 +26,4 @@ await job.throwError("PAYMENT_DECLINED", "Card declined by issuer", { code: "05"
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/worker-client/
+Source: https://bpmnkit.com/docs/packages/worker-client

package/.llms/chunks/packages.worker-client.md

@@ -30,4 +30,4 @@ for await (const job of client.poll("com.example:send-email:1")) {
 ```
 
 ---
-Source: https://docs.bpmnkit.com/packages/worker-client/
+Source: https://bpmnkit.com/docs/packages/worker-client

package/.llms/chunks/packages.worker-client.oauth2-camunda-saas.md

@@ -23,4 +23,4 @@ node dist/index.js
 | `ZEEBE_TOKEN_AUDIENCE` | OAuth2 audience |
 
 ---
-Source: https://docs.bpmnkit.com/packages/worker-client/
+Source: https://bpmnkit.com/docs/packages/worker-client