@bpmnkit/docspack 0.0.5 → 1.0.0

package/.llms/chunks/guides.using-bpmnkit-with-ai.where-to-go-next.md

@@ -0,0 +1,13 @@
+# Using BPMN Kit with AI — Where to go next
+
+- [AI Integration](/docs/guides/ai) — the compact format, prompting, the Claude
+  and OpenAI calls, and the MCP server
+- [Building Processes with AI](/docs/guides/ai-implement) — the `ProcessPlan`
+  pipeline, which compiles rather than generating XML
+- [AI Agents](/docs/guides/ai-agents) — putting an LLM *inside* a process as a
+  Camunda AI Agent Sub-process
+- [Claude Code Plugin](/docs/guides/claude-code-plugin) — the slash commands that
+  drive all of it
+
+---
+Source: https://bpmnkit.com/docs/guides/using-bpmnkit-with-ai

package/.llms/chunks/packages.ascii.from-the-command-line.md

@@ -0,0 +1,23 @@
+# @bpmnkit/ascii — From the command line
+
+`casen view` wraps all three, picking the renderer from the file extension:
+
+```sh
+casen view order.bpmn
+casen view risk-score.dmn
+```
+
+See [`casen view`](/docs/cli/view) for the flags it adds on top.
+
+
+## Stability
+
+`@bpmnkit/ascii` carries the [1.0 stability promise](/docs/getting-started/stability): its
+exports will not change shape without a major version.
+
+The promise covers the three function signatures and `RenderOptions`. It does **not** cover
+the exact characters that come out — box-drawing details, column widths and truncation are
+presentation, and improving them is a minor. Do not assert on the rendering byte for byte.
+
+---
+Source: https://bpmnkit.com/docs/packages/ascii

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

@@ -0,0 +1,34 @@
+# @bpmnkit/ascii — Installation
+
+```sh
+npm install @bpmnkit/ascii
+```
+
+
+## Rendering a process
+
+```typescript
+import { renderBpmnAscii } from "@bpmnkit/ascii";
+import { readFileSync } from "node:fs";
+
+console.log(renderBpmnAscii(readFileSync("order.bpmn", "utf-8")));
+```
+
+```text
+╭─────────╮           ┌──────────────────────┐          ╭─────────╮
+│ ○ Start │──────────►│ [svc] Process Order  │─────────►│ ● End   │
+╰─────────╯           └──────────────────────┘          ╰─────────╯
+```
+
+Shapes follow BPMN. Events are rounded boxes carrying a marker — `○` start, `●` end, `◎`
+intermediate catch, `◉` throw, `◈` boundary. Activities are square boxes with a three-letter
+type tag — `[svc]`, `[usr]`, `[scr]`, `[snd]`, `[rcv]`, `[dmn]`, `[man]`, `[cal]`, `[sub]`,
+`[txn]`. Gateways are diamonds — `×` exclusive, `+` parallel, `◇` inclusive, `?` event-based,
+`✱` complex. Labels are truncated to the box, which keeps columns aligned on a wide process.
+
+The layout comes from the diagram's own coordinates, so what you get is the shape someone drew
+rather than a re-layout. A model with no diagram interchange has nothing to place — run
+`applyAutoLayout` from `@bpmnkit/core` first if you built it in code.
+
+---
+Source: https://bpmnkit.com/docs/packages/ascii

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

@@ -0,0 +1,15 @@
+# @bpmnkit/ascii — Overview
+
+`@bpmnkit/ascii` turns a diagram into text. It takes the XML and returns a string — no canvas,
+no DOM, no headless browser — so a process can be shown somewhere a picture cannot go: a
+terminal, a CI log, a pull-request comment, or a prompt.
+
+That last one is the reason it exists. A model reading a diagram as a grid of labelled boxes
+gets the topology in a few hundred tokens, which is a great deal cheaper than the XML and a
+great deal more legible than a screenshot. `casen view` is this package with a file path in
+front of it.
+
+Three renderers, one per artifact kind, and no dependencies beyond `@bpmnkit/core`.
+
+---
+Source: https://bpmnkit.com/docs/packages/ascii

package/.llms/chunks/packages.ascii.rendering-a-decision-table.md

@@ -0,0 +1,29 @@
+# @bpmnkit/ascii — Rendering a decision table
+
+```typescript
+import { renderDmnAscii } from "@bpmnkit/ascii";
+
+console.log(renderDmnAscii(readFileSync("risk-score.dmn", "utf-8")));
+```
+
+```text
+DRD
+───
+
+Risk score [FIRST]
+──────────────────
+
+╔═══╦═════════╦════════════╦════════╗
+║ F ║ Amount  ║ Country    ║ Risk   ║
+╠═══╬═════════╬════════════╬════════╣
+║ 1 ║ < 1000  ║ "DE", "AT" ║ "low"  ║
+║ 2 ║ >= 1000 ║            ║ "high" ║
+╚═══╩═════════╩════════════╩════════╝
+```
+
+The hit policy is shown beside the table name and in the corner cell, because a table read
+without it means something different — an empty cell under `FIRST` is "anything, and stop
+here", which is not what it looks like.
+
+---
+Source: https://bpmnkit.com/docs/packages/ascii

package/.llms/chunks/packages.ascii.rendering-a-form.md

@@ -0,0 +1,39 @@
+# @bpmnkit/ascii — Rendering a form
+
+```typescript
+import { renderFormAscii } from "@bpmnkit/ascii";
+
+console.log(renderFormAscii(readFileSync("approval.form", "utf-8")));
+```
+
+Fields are listed in layout order with their keys, types and validation, so a form can be
+reviewed in the same place as the process that raises it.
+
+
+## API Reference
+
+| Export | Signature |
+|---|---|
+| `renderBpmnAscii` | `(xml: string, options?: RenderOptions) => string` |
+| `renderDmnAscii` | `(xml: string, options?: RenderOptions) => string` |
+| `renderFormAscii` | `(json: string, options?: RenderOptions) => string` |
+
+Each takes the file's text and returns the rendering. Parsing is strict — a document that is
+not valid BPMN throws, naming what it found — so wrap the call if you are rendering a
+directory. A document that parses but holds no flow elements
+renders as `(empty)`.
+
+### `RenderOptions`
+
+```typescript
+interface RenderOptions {
+  /**
+   * Heading shown above the diagram.
+   * Defaults to the process name from the XML; pass `false` for no heading.
+   */
+  title?: string | false;
+}
+```
+
+---
+Source: https://bpmnkit.com/docs/packages/ascii

package/.llms/chunks/packages.camunda-docspack.a-note-on-the-pack-s-name.md

@@ -0,0 +1,15 @@
+# @bpmnkit/camunda-docspack — A note on the pack's name
+
+A vendor that redistributes somebody else's documentation needs a second pack, so
+this one is `@bpmnkit/camunda-docspack` rather than a second `@bpmnkit/docspack`.
+The name is still a pure check inside a scope BPMN Kit owns, so the pack carries
+the same trust as `@bpmnkit/docspack`.
+
+The docspack spec originally named one pack per npm scope, and `bpmnkit-docs`
+read the `-docspack` suffix ahead of it. Upstream adopted the shape in
+**`docspack@1.2.0`**, so both readers now find this pack — but a `docspack` CLI
+older than 1.2.0 will not, and will answer Camunda questions out of
+`@bpmnkit/docspack` instead. `bpmnkit-docs` has no such floor.
+
+---
+Source: https://bpmnkit.com/docs/packages/camunda-docspack

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

@@ -0,0 +1,41 @@
+# @bpmnkit/camunda-docspack — Installation
+
+```sh
+pnpm add -D @bpmnkit/camunda-docspack
+```
+
+There is no second CLI to learn: `bpmnkit-docs`, from
+[`@bpmnkit/docspack`](/docs/packages/docspack), reads every pack installed.
+
+
+## Asking it
+
+```sh
+npx bpmnkit-docs ask "how should I name an exclusive gateway" \
+  --pack @bpmnkit/camunda-docspack
+npx bpmnkit-docs ask "POST /jobs/activation" --pack @bpmnkit/camunda-docspack
+npx bpmnkit-docs ask "what permissions does creating a process instance need" \
+  --pack @bpmnkit/camunda-docspack
+```
+
+`--pack` both disambiguates and pays for itself: the index is built by reading
+every chunk off disk, so narrowing to one pack is roughly 150ms against 650ms
+across both. Leave it off when you do not know which pack answers.
+
+Confirm it is installed before relying on it:
+
+```sh
+npx bpmnkit-docs list
+```
+
+```
+@bpmnkit/camunda-docspack@0.1.1  1054 chunks
+@bpmnkit/docspack@0.0.5  206 chunks
+```
+
+A pack missing from that list is a pack no answer can come from. See
+[Using BPMN Kit with AI](/docs/guides/using-bpmnkit-with-ai) for the paragraph to
+put in `AGENTS.md` or `CLAUDE.md` so an agent knows to ask both.
+
+---
+Source: https://bpmnkit.com/docs/packages/camunda-docspack

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

@@ -0,0 +1,28 @@
+# @bpmnkit/camunda-docspack — Overview
+
+`@bpmnkit/camunda-docspack` packages the **Camunda 8 documentation** as a
+[docspack](https://docspack.dev/spec) pack you can search offline: BPMN and FEEL
+references, engine concepts, the best-practice pages, and one digest per
+Orchestration Cluster API operation.
+
+It is the companion to [`@bpmnkit/docspack`](/docs/packages/docspack), and the
+split is the point. Ask ours how to *drive the library*; ask this one what the
+*engine* does — gateway semantics, FEEL syntax, job activation, permissions.
+Those are different questions and the right answer to one is the wrong answer to
+the other.
+
+> **This is Camunda's documentation, not BPMN Kit's.** The content is the work of
+> Camunda Services GmbH and copyright in it remains with them. This package adds
+> only the tooling that stages, chunks and indexes it. It is redistributed under
+> **CC BY-SA 3.0**, the licence Camunda publishes it under — which is why this
+> package is CC BY-SA 3.0 rather than MIT like the rest of BPMN Kit. BPMN Kit is
+> not affiliated with, endorsed by or sponsored by Camunda. For canonical and
+> current documentation prefer [docs.camunda.io](https://docs.camunda.io).
+
+It is built from the `docs/` tree of
+[camunda/camunda-docs](https://github.com/camunda/camunda-docs) — the unreleased
+**8.10** documentation — plus the Orchestration Cluster API specification, and
+rebuilt weekly.
+
+---
+Source: https://bpmnkit.com/docs/packages/camunda-docspack

package/.llms/chunks/packages.camunda-docspack.rebuilding-it.md

@@ -0,0 +1,27 @@
+# @bpmnkit/camunda-docspack — Rebuilding it
+
+A weekly workflow (`.github/workflows/camunda-docspack.yml`) rebuilds the pack
+from upstream. By hand you need a camunda-docs checkout:
+
+```sh
+node packages/camunda-docspack/dist/cli.js --camunda-docs ../camunda-docs
+```
+
+
+## API Reference
+
+The published artefact is the `.llms/` payload; these exports are the build that
+produces it.
+
+| Export | Purpose |
+| --- | --- |
+| `build(options)` | Stage a camunda-docs checkout and write the `.llms/` payload |
+| `stage(options)` | Run the staging transforms only, to a directory |
+| `bpmnToText(xml)` | Render a BPMN diagram as a compact flow description |
+| `readOperations(entry)` | Read one digest per operation from an OpenAPI document |
+| `stripMdx(source, options)` | Reduce Camunda's MDX to indexable Markdown |
+| `absoluteLinks(markdown, slug)` | Rewrite relative links to `docs.camunda.io` URLs |
+| `notice(commit)` | The CC BY-SA 3.0 attribution written on every build |
+
+---
+Source: https://bpmnkit.com/docs/packages/camunda-docspack

package/.llms/chunks/packages.camunda-docspack.what-makes-this-corpus-different.md

@@ -0,0 +1,16 @@
+# @bpmnkit/camunda-docspack — What makes this corpus different
+
+- **Diagrams as text.** The best-practice pages argue through embedded BPMN
+  diagrams, and Camunda's own Markdown export drops them. Each one is rendered as
+  a flow description instead, so a page about naming gateways still contains the
+  gateway, its question and its conditions.
+- **227 API operations.** One digest per endpoint, read from the specification
+  rather than from the generated reference pages, with required permissions
+  decoded, the version it appeared in, and its consistency guarantee.
+- **Every chunk cites its page.** Links are rewritten to absolute
+  `docs.camunda.io` URLs and each chunk ends with the page it came from.
+- **Nothing dropped silently.** An MDX component the build does not recognise
+  fails the build by file and line rather than quietly thinning the corpus.
+
+---
+Source: https://bpmnkit.com/docs/packages/camunda-docspack

package/.llms/chunks/packages.connectors.api-reference.md

@@ -0,0 +1,22 @@
+# @bpmnkit/connectors — API Reference
+
+| Export | Description |
+|---|---|
+| `listConnectors()` | Every connector in the catalog, as summaries |
+| `searchConnectors(query)` | Summaries matching name, description or keywords |
+| `getTemplate(id)` | The full `ElementTemplate` for an id |
+| `summarizeTemplate(template)` | `ConnectorSummary` from a template you hold |
+| `propertyKey(property)` | The variable name a template property binds to |
+| `applyConnectorTemplate(id, values)` | Catalog template → builder options + problems |
+| `applyElementTemplate(template, values)` | Template object → builder options + problems |
+| `validateElementTemplate(template)` | `{ valid, problems, warnings }` |
+| `readTemplateDocument(text)` | Parse a file holding one template or many |
+| `registerElementTemplates(templates)` | Merge templates into the catalog |
+| `clearRegisteredTemplates()` | Drop everything registered |
+| `CAMUNDA_CONNECTOR_TEMPLATES` | The 116 bundled templates, raw |
+
+From `@bpmnkit/connectors/node`: `discoverElementTemplates`, `collectElementTemplates`,
+`DEFAULT_CONFIG_FOLDER`, `TEMPLATES_SUBFOLDER`.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

package/.llms/chunks/packages.connectors.applying-a-template.md

@@ -0,0 +1,64 @@
+# @bpmnkit/connectors — Applying a template
+
+Applying does not mutate an element. It turns a template plus your values into the **builder
+options** for whichever element kind the template applies to, which you hand to
+`@bpmnkit/core`:
+
+```typescript
+import { applyConnectorTemplate } from "@bpmnkit/connectors";
+import { Bpmn } from "@bpmnkit/core";
+
+const { serviceTask, problems } = applyConnectorTemplate("io.camunda.connectors.Slack.v1", {
+  token: "=secrets.SLACK_TOKEN",
+  "data.channel": "#alerts",
+  "data.text": "=message",
+});
+
+// serviceTask = {
+//   name: "Slack connector",
+//   taskType: "io.camunda:slack:1",
+//   ioMapping: { inputs: [...], outputs: [] },
+//   modelerTemplate: "io.camunda.connectors.Slack.v1",
+//   modelerTemplateVersion: "1",
+//   modelerTemplateIcon: "data:image/svg+xml;utf8,...",
+// }
+
+Bpmn.createProcess("alerting").startEvent("in").serviceTask("notify", serviceTask).build();
+```
+
+`applyElementTemplate(template, values)` is the same operation against a template object
+rather than a catalog id — the path a workspace template takes.
+
+The result carries exactly one populated element key, so the template decides what it applies
+to rather than the caller guessing:
+
+```typescript
+interface ApplyResult {
+  serviceTask?: ServiceTaskOptions;
+  adHocSubProcess?: Partial<AdHocSubProcessOptions>;
+  startEvent?: Partial<StartEventOptions>;
+  boundaryEvent?: Partial<BoundaryEventOptions>;
+  intermediateEvent?: Partial<IntermediateCatchEventOptions>;
+  problems: ApplyProblem[];
+}
+```
+
+Nothing throws — "this value does not belong to this template" and "this required value is
+missing" are answers a UI has to show, so they come back as `problems` alongside whatever
+could be built:
+
+```typescript
+applyConnectorTemplate("io.camunda.connectors.Slack.v1", {}).problems;
+// [{ key: "token", kind: "missing-required",
+//    message: 'Missing required value for "OAuth token" (token)' }, …]
+
+applyConnectorTemplate("nope.does.not.exist", {}).problems;
+// [{ message: 'Unknown connector template "nope.does.not.exist"' }]
+```
+
+Application is deterministic: property order and the emitted bindings depend only on the
+template and the values, never on iteration order or the clock. That is what lets a diagram be
+rebuilt in CI and diffed.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

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

@@ -0,0 +1,45 @@
+# @bpmnkit/connectors — Installation
+
+```sh
+npm install @bpmnkit/connectors
+```
+
+
+## Browsing the catalog
+
+```typescript
+import { listConnectors, searchConnectors, getTemplate } from "@bpmnkit/connectors";
+
+listConnectors().length;        // 116
+searchConnectors("slack");      // 6 matches, inbound and outbound
+
+const template = getTemplate("io.camunda.connectors.Slack.v1");
+```
+
+`listConnectors` and `searchConnectors` return `ConnectorSummary` — the shape a picker needs,
+without the full template:
+
+```typescript
+interface ConnectorSummary {
+  id: string;
+  name: string;
+  description?: string;
+  taskType: string;              // e.g. "io.camunda:http-json:1"
+  appliesTo: string[];           // e.g. ["bpmn:Task"]
+  direction: ConnectorDirection; // "outbound" | "inbound"
+  keywords: string[];
+  requiredInputs: ConnectorInputSpec[];
+  optionalInputs: ConnectorInputSpec[];
+}
+```
+
+Each `ConnectorInputSpec` carries what a form needs to render the field — `label`,
+`description`, `default`, `choices`, whether it is `isSecret` or `isFeel`, and the `condition`
+that decides whether it applies at all. `summarizeTemplate` produces the same shape from a
+template you hold yourself.
+
+`CAMUNDA_CONNECTOR_TEMPLATES` is the raw bundled array if you would rather work with the
+templates directly.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

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

@@ -0,0 +1,16 @@
+# @bpmnkit/connectors — Overview
+
+`@bpmnkit/connectors` answers two questions about Camunda 8 connectors: **which ones exist**,
+and **what happens to a task when you apply one**.
+
+It bundles the 116 out-of-the-box Camunda connector templates as data, so a catalog, a search
+box or an AI tool call can work offline. And it resolves a template plus a set of values into
+the `zeebe:taskDefinition`, `zeebe:ioMapping` and `zeebe:modelerTemplate` bookkeeping the
+Modeler would write — deterministically, so the same template and values always produce the
+same XML.
+
+The package root is browser-safe. Everything that touches the filesystem lives behind
+`@bpmnkit/connectors/node`.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

package/.llms/chunks/packages.connectors.stability.md

@@ -0,0 +1,16 @@
+# @bpmnkit/connectors — Stability
+
+`@bpmnkit/connectors` carries the [1.0 stability promise](/docs/getting-started/stability):
+its exports will not change shape without a major version.
+
+Two things the promise does **not** freeze, because both track Camunda rather than this
+package:
+
+- **The catalog's contents.** Connectors are added, and upstream templates gain versions and
+  properties. A changed `CAMUNDA_CONNECTOR_TEMPLATES` is a minor; the types describing it are
+  covered as usual.
+- **Template validation being strict about new upstream shapes.** A template that validates
+  today will not start failing in a minor — that direction *is* covered.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

package/.llms/chunks/packages.connectors.validating-a-template.md

@@ -0,0 +1,27 @@
+# @bpmnkit/connectors — Validating a template
+
+```typescript
+import { validateElementTemplate } from "@bpmnkit/connectors";
+
+validateElementTemplate(template);
+// {
+//   valid: false,
+//   problems: [
+//     { path: 'properties[0].type',
+//       message: 'unknown property type "nope" — expected one of String, Text, Hidden, Dropdown, Boolean, Number' },
+//     { path: 'properties[0].binding', message: 'binding is required' },
+//   ],
+//   warnings: [],
+// }
+```
+
+Problems are reported by **path** rather than as a JSON-schema `oneOf` dump, and every problem
+is collected rather than stopping at the first. Warnings are kept separate from problems, so a
+CI gate can fail on one and not the other. `readTemplateDocument` parses a file that may hold
+one template or an array of them.
+
+The CLI wraps this as [`casen connector validate`](/docs/cli/connector), which exits non-zero
+for CI and takes `--format json`.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

package/.llms/chunks/packages.connectors.workspace-templates.md

@@ -0,0 +1,20 @@
+# @bpmnkit/connectors — Workspace templates
+
+A project can ship its own `.camunda/element-templates/`. The filesystem half lives behind its
+own entry point so importing the catalog in a browser never pulls in `node:fs`:
+
+```typescript
+import { discoverElementTemplates, collectElementTemplates } from "@bpmnkit/connectors/node";
+```
+
+- `discoverElementTemplates` walks **upward** from a diagram to the project root, nearest
+  winning — the resolution a modeler needs.
+- `collectElementTemplates` walks **downward** from a root — the sweep a CI check needs, so a
+  broken template in a sub-folder is reported rather than skipped because the root looked fine.
+
+`registerElementTemplates` merges what you found into the catalog, later registration winning
+on an id collision, so `listConnectors`, `searchConnectors` and `getTemplate` then see a
+project's own templates alongside the bundled ones. `clearRegisteredTemplates` undoes it.
+
+---
+Source: https://bpmnkit.com/docs/packages/connectors

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

@@ -6,6 +6,14 @@ Zeebe bindings, and drops collaborations, participants, message flows, lanes, da
 artifacts, root-level messages and errors, multi-instance loop characteristics, full
 `zeebe:ioMapping` entries and diagram interchange.
 
+A sequence flow leaving an exclusive, inclusive or complex gateway carries `isDefault: true`
+when the gateway names it in `bpmn:default`. It sits on the flow rather than on the gateway
+because that is where its alternative, `condition`, sits — a model writing the branches of a
+decision marks one of them instead of pointing back at a flow id. `expand` turns it into the
+attribute; a flow marked `isDefault` that leaves anything else, or a gateway with two of them,
+throws rather than being dropped, because a lost default is a gateway that deadlocks the first
+time every condition is false.
+
 `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

package/.llms/chunks/packages.core.installation-createcompactstream-options.md

@@ -0,0 +1,41 @@
+# @bpmnkit/core — Installation — `createCompactStream(options?)`
+
+Reads a diagram out of a model's token stream, so it can be rendered while it is still being
+written. A model emits a diagram one character at a time, and the outermost `}` — the one
+`JSON.parse` waits for — is the last character it sends, so the seconds before it arrives are
+unusable to everything downstream.
+
+This does not parse the document. It takes complete `{…}` literals as they close and keeps the
+ones shaped like a `CompactElement` or a `CompactFlow` — the innermost objects, and therefore
+the first to finish.
+
+```typescript
+import { createCompactStream } from "@bpmnkit/core";
+
+// `base` is the diagram being edited, so a frame shows the whole process rather
+// than the fragment the model is adding to it. Omit it to build from nothing.
+const stream = createCompactStream({ base: currentDiagram });
+
+for await (const chunk of tokens) {
+  const frame = stream.push(chunk); // null until the frame changes
+  if (frame) canvas.loadDefinitions(frame, { keepViewport: true });
+}
+```
+
+Not parsing is also what makes it indifferent to what it is reading: a tool-call argument, a
+fenced JSON block in an assistant's prose, and the body of a code-mode snippet all carry the
+same literals, and none of them has to be valid as a whole.
+
+**Frames are advisory.** Every one is a guess at an unfinished document, and the caller is
+expected to have an authoritative result coming. `push` never throws on input, drops what it
+cannot place, and strips `isDefault` from a flow rather than failing when the gateway it claims
+has not been written yet — a preview without the marker beats no preview. Use the model's
+finished output, not a frame, as the thing you save or deploy.
+
+A single pass over a brace stack reads each character once and considers each literal once,
+innermost first, so a sub-process is seen after the children it reclaims from the top level.
+On a recorded Claude run writing a seven-element order process, the first renderable frame
+arrived 16% of the way into the tool argument, with 15 frames following.
+
+---
+Source: https://bpmnkit.com/docs/packages/core

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

@@ -20,9 +20,9 @@ with `explicitJoins` that refusal is the only thing that tells you.
 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.
+`{ strict: true }` was the former name for this option. It was removed in 1.0.0 — "strict"
+says nothing about what it is strict *about*, and `applyBpmnOperations` takes a `strict` that
+means something else entirely. Rename it to `explicitJoins`; the behaviour is identical.
 
 ---
 Source: https://bpmnkit.com/docs/packages/core

package/.llms/chunks/{packages.docspack.installation.md → packages.docspack.giving-an-agent-access.md}

@@ -1,18 +1,13 @@
-# @bpmnkit/docspack — Installation
-
-```sh
-pnpm add -D @bpmnkit/docspack
-```
-
-
-## Giving an agent access
+# @bpmnkit/docspack — Giving an agent access
 
 Any agent with a shell can run the command, so one paragraph in `AGENTS.md`, `CLAUDE.md`
 or `.cursor/rules` is the whole setup:
 
 ```md
-Run `npx bpmnkit-docs ask "<question>"` for BPMN Kit documentation. It answers
-from the version this project installed. Prefer what it returns over recalled
+Run `npx bpmnkit-docs ask "<question>"` for BPMN Kit documentation, and
+`npx bpmnkit-docs ask "<question>" --pack @bpmnkit/camunda-docspack` for Camunda 8
+documentation — BPMN semantics, FEEL, engine behaviour, the REST API. Both answer
+from the versions this project installed. Prefer what they return over recalled
 knowledge — when the two disagree, the retrieved chunk is right.
 ```
 

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

@@ -30,5 +30,11 @@ with the versions installed.
 
 Options: `--limit <n>`, `--max-tokens <n>`, `--pack <name>`, `--cwd <dir>`.
 
+`--pack` narrows before the index is built, not after, so asking one pack a
+question does not pay for reading the others — roughly 150ms against 650ms
+across both packs. A name that is not installed is an error listing what is,
+rather than an empty answer that would read as "the documentation does not cover
+this".
+
 ---
 Source: https://bpmnkit.com/docs/packages/docspack

package/.llms/chunks/packages.docspack.the-other-pack.md

@@ -0,0 +1,24 @@
+# @bpmnkit/docspack — The other pack
+
+BPMN Kit publishes a second pack:
+**[`@bpmnkit/camunda-docspack`](/docs/packages/camunda-docspack)**, the Camunda 8
+documentation — BPMN and FEEL references, engine concepts, best practices and the
+Orchestration Cluster API. `bpmnkit-docs` reads both, so ask this package how to
+drive the library and that one what the engine does:
+
+```sh
+npx bpmnkit-docs ask "how should I name an exclusive gateway" --pack @bpmnkit/camunda-docspack
+```
+
+Install them together, and tell your agent about both — see
+[Using BPMN Kit with AI](/docs/guides/using-bpmnkit-with-ai).
+
+
+## Installation
+
+```sh
+pnpm add -D @bpmnkit/docspack @bpmnkit/camunda-docspack
+```
+
+---
+Source: https://bpmnkit.com/docs/packages/docspack