@bpmn-ld/bpmn-ld 0.0.0-stage → 0.1.0

package/skills/bpmn-ld/examples/positive/task-message-references.jsonld

@@ -0,0 +1,151 @@
+{
+  "@context": [
+    "../../../../contexts/core.jsonld",
+    {
+      "@base": "https://example.org/models/task-message-references/"
+    }
+  ],
+  "@graph": [
+    {
+      "id": "Message_Confirmation",
+      "type": "Message",
+      "name": "Order confirmation"
+    },
+    {
+      "id": "Message_Order",
+      "type": "Message",
+      "name": "Order"
+    },
+    {
+      "id": "Collaboration_1",
+      "type": "Collaboration",
+      "participants": [
+        {
+          "id": "Participant_Customer",
+          "type": "Participant",
+          "name": "Customer",
+          "processRef": "Process_Customer"
+        },
+        {
+          "id": "Participant_Shop",
+          "type": "Participant",
+          "name": "Shop",
+          "processRef": "Process_Shop"
+        }
+      ],
+      "messageFlows": [
+        {
+          "id": "MessageFlow_Order",
+          "type": "MessageFlow",
+          "name": "Order",
+          "sourceRef": "SendOrder",
+          "targetRef": "ReceiveOrder",
+          "messageRef": "Message_Order"
+        },
+        {
+          "id": "MessageFlow_Confirmation",
+          "type": "MessageFlow",
+          "name": "Confirmation",
+          "sourceRef": "SendConfirmation",
+          "targetRef": "ReceiveConfirmation"
+        }
+      ]
+    },
+    {
+      "id": "Process_Customer",
+      "type": "Process",
+      "name": "Customer process",
+      "flowElements": [
+        {
+          "id": "CustomerStart",
+          "type": "StartEvent",
+          "name": "Wants to order"
+        },
+        {
+          "id": "SendOrder",
+          "type": "SendTask",
+          "name": "Send order",
+          "implementation": "##WebService",
+          "messageRef": "Message_Order"
+        },
+        {
+          "id": "ReceiveConfirmation",
+          "type": "ReceiveTask",
+          "name": "Receive confirmation",
+          "messageRef": "Message_Confirmation"
+        },
+        {
+          "id": "CustomerEnd",
+          "type": "EndEvent",
+          "name": "Order confirmed"
+        },
+        {
+          "id": "CustomerFlow_1",
+          "type": "SequenceFlow",
+          "sourceRef": "CustomerStart",
+          "targetRef": "SendOrder"
+        },
+        {
+          "id": "CustomerFlow_2",
+          "type": "SequenceFlow",
+          "sourceRef": "SendOrder",
+          "targetRef": "ReceiveConfirmation"
+        },
+        {
+          "id": "CustomerFlow_3",
+          "type": "SequenceFlow",
+          "sourceRef": "ReceiveConfirmation",
+          "targetRef": "CustomerEnd"
+        }
+      ]
+    },
+    {
+      "id": "Process_Shop",
+      "type": "Process",
+      "name": "Shop process",
+      "flowElements": [
+        {
+          "id": "ReceiveOrder",
+          "type": "ReceiveTask",
+          "name": "Receive order",
+          "instantiate": true,
+          "messageRef": "Message_Order"
+        },
+        {
+          "id": "CheckStock",
+          "type": "ServiceTask",
+          "name": "Check stock"
+        },
+        {
+          "id": "SendConfirmation",
+          "type": "SendTask",
+          "name": "Send confirmation",
+          "messageRef": "Message_Confirmation"
+        },
+        {
+          "id": "ShopEnd",
+          "type": "EndEvent",
+          "name": "Order handled"
+        },
+        {
+          "id": "ShopFlow_1",
+          "type": "SequenceFlow",
+          "sourceRef": "ReceiveOrder",
+          "targetRef": "CheckStock"
+        },
+        {
+          "id": "ShopFlow_2",
+          "type": "SequenceFlow",
+          "sourceRef": "CheckStock",
+          "targetRef": "SendConfirmation"
+        },
+        {
+          "id": "ShopFlow_3",
+          "type": "SequenceFlow",
+          "sourceRef": "SendConfirmation",
+          "targetRef": "ShopEnd"
+        }
+      ]
+    }
+  ]
+}

package/skills/bpmn-ld/examples/positive/transaction.jsonld

@@ -0,0 +1,48 @@
+{
+  "@context": [
+    "../../../../contexts/core.jsonld",
+    { "@base": "https://example.org/models/transaction/" }
+  ],
+  "@graph": [
+    {
+      "id": "Process_Order",
+      "type": "Process",
+      "name": "Order fulfilment",
+      "flowElements": [
+        { "id": "OrderReceived", "type": "StartEvent", "name": "Order received" },
+        {
+          "id": "ChargeAndShip",
+          "type": "Transaction",
+          "name": "Charge and ship",
+          "method": "Compensate",
+          "flowElements": [
+            { "id": "TxStart", "type": "StartEvent", "name": "Begin" },
+            { "id": "ChargeCard", "type": "ServiceTask", "name": "Charge card" },
+            { "id": "ShipGoods", "type": "ServiceTask", "name": "Ship goods" },
+            { "id": "TxEnd", "type": "EndEvent", "name": "Done" },
+            { "id": "TxFlow_1", "type": "SequenceFlow", "sourceRef": "TxStart", "targetRef": "ChargeCard" },
+            { "id": "TxFlow_2", "type": "SequenceFlow", "sourceRef": "ChargeCard", "targetRef": "ShipGoods" },
+            { "id": "TxFlow_3", "type": "SequenceFlow", "sourceRef": "ShipGoods", "targetRef": "TxEnd" }
+          ]
+        },
+        {
+          "id": "ReserveStock",
+          "type": "Transaction",
+          "name": "Reserve stock",
+          "method": "Store",
+          "flowElements": [
+            { "id": "StockStart", "type": "StartEvent", "name": "Begin" },
+            { "id": "ReserveItems", "type": "ServiceTask", "name": "Reserve items" },
+            { "id": "StockEnd", "type": "EndEvent", "name": "Reserved" },
+            { "id": "StockFlow_1", "type": "SequenceFlow", "sourceRef": "StockStart", "targetRef": "ReserveItems" },
+            { "id": "StockFlow_2", "type": "SequenceFlow", "sourceRef": "ReserveItems", "targetRef": "StockEnd" }
+          ]
+        },
+        { "id": "OrderCompleted", "type": "EndEvent", "name": "Order completed" },
+        { "id": "Flow_1", "type": "SequenceFlow", "sourceRef": "OrderReceived", "targetRef": "ChargeAndShip" },
+        { "id": "Flow_2", "type": "SequenceFlow", "sourceRef": "ChargeAndShip", "targetRef": "ReserveStock" },
+        { "id": "Flow_3", "type": "SequenceFlow", "sourceRef": "ReserveStock", "targetRef": "OrderCompleted" }
+      ]
+    }
+  ]
+}

package/skills/bpmn-ld/references/clarification-and-refinement.md

@@ -0,0 +1,60 @@
+# Clarification, assumptions and refinement
+
+How to decide between asking and assuming, how to apply feedback to an existing model, and how to report. The fix-round cap is three rounds, as in `SKILL.md`.
+
+## When to ask and when to assume
+
+Ask before writing when the answer would change the shape of the process and cannot be inferred. Otherwise state an assumption, keep going and report it.
+
+Ask when:
+
+- the request does not say what the process is for, where it starts or where it ends, and no reasonable default exists;
+- a decision has several plausible outcomes that lead to different flows, for example "who approves, the manager or finance?";
+- the answer decides whether branches run in parallel or as an exclusive choice and the text gives no hint;
+- several participants are involved and it is unclear who owns which step.
+
+Assume when:
+
+- the gap is a detail that is cheap to change later, such as the exact name of a task or the wording of a condition;
+- a default is standard practice, for example one start event and an end event per outcome;
+- the request is silent on an unhappy path that the user did not ask for.
+
+Examples:
+
+- "Model our order process": ask what starts it and what the possible outcomes are. Nothing can be inferred.
+- "Orders over 1000 need approval": assume that smaller orders skip approval and continue, and report it.
+- "Notify the customer and update stock": assume the two steps run in parallel only if the text says they are independent; otherwise ask or state the sequence assumed.
+
+Ask at most a few focused questions in one message, then wait. Never ask something the request already answers.
+
+## Reporting assumptions
+
+List every assumption in the final report under an `Assumptions` list, one per line, in plain language:
+
+- name the element by its `id` where one exists;
+- say what was assumed and what the alternative would have been;
+- mark which assumptions are most likely to need confirmation.
+
+Do not hide assumptions inside the model or leave them out because the checks passed. A valid model can still be the wrong process.
+
+## Applying feedback to an existing model
+
+Edit the existing document in place. Do not regenerate it from scratch.
+
+- Change only the elements the feedback touches: add, remove or rewire the nodes and sequence flows concerned.
+- Preserve existing `id` values of every element that stays, so references, diagrams and the user's mental model stay stable.
+- When inserting a step, give the new elements fresh unique ids and update `sourceRef` and `targetRef` of the neighbouring flows.
+- When removing a step, remove the flows attached to it and reconnect its neighbours.
+- Re-run both checks from `SKILL.md` after every change set, then report as usual.
+- Treat feedback that changes the intent of the process as a new clarification question, not as an edit.
+
+Each feedback application is its own session of checks. The three-round cap applies to fix rounds within one request.
+
+## Never present a model with errors as finished
+
+A model is finished only when `npm run validate` prints `ok` for it and `summary.errors` is 0.
+
+- After the third fix round, run both commands one last time and stop, even if errors remain.
+- Report what remains: each remaining error with its rule or message, the element, the likely cause and the suggested fix from `references/rule-catalogue.md`.
+- State plainly that the model is not valid. Do not call it done, complete or ready.
+- Warnings do not block. Report them with an explanation and do not present them as errors.

package/skills/bpmn-ld/references/common-mistakes.md

@@ -0,0 +1,110 @@
+# Common modelling mistakes
+
+Mistakes that often appear in process models, how to repair each one in BPMN-LD, and whether the analyzer catches it. Rule identifiers are explained in `references/rule-catalogue.md`; worked examples are in `examples/positive/`.
+
+Each entry has the same fields:
+
+- Mistake: what the model does wrong.
+- Why it matters: what goes wrong when the process runs.
+- Fix in BPMN-LD: the change to make in the document.
+- Analyzer coverage: the rule that reports it, or a statement that the analyzer does not.
+
+## Splitting without merging
+
+Mistake: a gateway splits the flow into several branches, but the branches never come back together through a matching gateway, or they are joined by a gateway of the other type.
+
+Why it matters: the work after the branches runs once per branch, or a join waits for a branch that is never taken and the process stalls.
+
+Fix in BPMN-LD: give every split a converging gateway of the same type that all branches enter, and set `gatewayDirection` to `Diverging` on the split and `Converging` on the join. Use two `ParallelGateway` elements for branches that all run (`examples/positive/parallel-branches.jsonld`) and two `ExclusiveGateway` elements for a choice (`examples/positive/exclusive-choice.jsonld`). A branch that deliberately ends on its own may end in its own end event instead.
+
+Analyzer coverage: `split-join-exclusive-to-parallel`, `split-join-parallel-to-exclusive`, `gateway-diverging-too-few-outgoing` and `gateway-converging-too-few-incoming` report mismatched or incomplete gateways. A split whose branches are simply never merged is not reported as such; the branches show up as `node-dead-end` only when one of them stops without an end event.
+
+## Missing end events
+
+Mistake: a process or sub-process has no end event, or a branch stops at an activity with nothing after it.
+
+Why it matters: completion is only implicit, so a reader or tool cannot tell where the process finishes or which outcomes exist, and a sub-process may never hand control back.
+
+Fix in BPMN-LD: add an `EndEvent` to the scope and connect the last activity of each branch to one. Use a separate, named end event for each distinct outcome (`examples/positive/order-approval.jsonld`).
+
+Analyzer coverage: `end-event-missing` (warning) for a scope with no end event, `node-dead-end` (warning) for a flow node with no outgoing flow that is not an end event, and `node-cannot-reach-end` (warning) for a node from which no end event can be reached.
+
+## Too many or no start events
+
+Mistake: a process has no start event, or several plain start events that all start the same process without saying why.
+
+Why it matters: without a start event the process cannot begin and everything in it is unreachable; with several unexplained ones it is unclear which situation starts it and whether they start separate instances.
+
+Fix in BPMN-LD: give each process and sub-process one `StartEvent` connected to the first activity. When there are really several triggers, keep one start event per trigger and give each a typed event definition such as a message or timer, or use an instantiating gateway when the first of several events starts the process (`examples/positive/instantiating-gateway.jsonld`).
+
+Analyzer coverage: `start-event-missing` (error) for a process or sub-process with no start event. The analyzer does not report a scope that has more than one start event, so check that by reading the model.
+
+## Unlabelled decision branches
+
+Mistake: an exclusive gateway has several outgoing flows, but the flows carry no name and no condition, and no flow is marked as the default.
+
+Why it matters: a reader cannot tell which path is taken in which situation, and an engine cannot choose between the branches or has no path to take when no condition holds, so the process stalls or picks arbitrarily.
+
+Fix in BPMN-LD: phrase the gateway `name` as a question, give every outgoing `SequenceFlow` a short `name` that answers it, and put a `conditionExpression` on all but one of the flows. Name the remaining flow in the gateway's `default` so there is always a path to take (`examples/positive/exclusive-choice.jsonld`, `examples/positive/order-approval.jsonld`).
+
+Analyzer coverage: not detected by the analyzer; check by review. No rule reports an exclusive gateway whose outgoing flows lack names, conditions or a default flow, so read each gateway in the model.
+
+## Gateways doing the work
+
+Mistake: a gateway is treated as a step that performs or evaluates the work, for example a gateway named "Check credit" that also decides, instead of only routing on a result that already exists.
+
+Why it matters: a gateway only routes the flow; it takes no time, has no performer and records no result. Putting the work in it hides who does the work and what information the decision depends on.
+
+Fix in BPMN-LD: add a task before the gateway that does the work, such as a `UserTask` or `ServiceTask` named with a verb and an object, and connect it to the gateway with a `SequenceFlow`. Name the gateway as the question asked of that result and let its outgoing flows carry the answers (`examples/positive/order-approval.jsonld` has the review task before the "Approved?" gateway).
+
+Analyzer coverage: not detected by the analyzer; check by review. No rule judges what a gateway is named or whether a task precedes it, so check each diverging gateway for a task that produces the result it decides on.
+
+## Mixed levels of detail
+
+Mistake: one process mixes coarse steps with fine-grained ones, for example "Handle onboarding" next to "Click save in the form" in the same flow.
+
+Why it matters: the diagram is hard to read at a glance, steps cannot be compared or assigned consistently, and the detailed part cannot be reused, changed or measured separately from the overview.
+
+Fix in BPMN-LD: keep the parent process at one level and move the detailed steps into a `SubProcess`. Give the sub-process its own `StartEvent`, tasks and `EndEvent` in its `flowElements`, and connect the sub-process in the parent like any other activity (`examples/positive/sub-process.jsonld`).
+
+Analyzer coverage: not detected by the analyzer; check by review. No rule judges how detailed a step is, so compare the names in each flow and group the fine-grained ones. The analyzer does check that the sub-process you introduce has a start and an end event (`start-event-missing`, `end-event-missing`).
+
+## Wrong task type
+
+Mistake: every step is a generic `Task`, or a step uses a type that does not match who or what performs it, for example a `UserTask` for an automatic call.
+
+Why it matters: the type tells readers and engines whether a person, a system or a rule does the work. A wrong or generic type hides the performer, and an engine may wait for a person or run an automation that was never meant for that step.
+
+Fix in BPMN-LD: choose the specific type for each step. Use `UserTask` for work a person does in a system, `ManualTask` for work done without any system, `ServiceTask` for an automated call, `ScriptTask` for a script the engine runs, `BusinessRuleTask` for evaluating a decision rule, `SendTask` for sending a message and `ReceiveTask` for waiting for one (`examples/positive/task-implementation.jsonld` shows user and service tasks, `examples/positive/script-task.jsonld` a script task and `examples/positive/task-message-references.jsonld` send and receive tasks).
+
+Analyzer coverage: not detected by the analyzer; check by review. No rule judges whether a task type fits the work. The analyzer only checks that a `SendTask` or `ReceiveTask` with a `messageRef` has a matching message flow (`task-message-without-message-flow`).
+
+## Exceptions on the happy path
+
+Mistake: error, timeout or cancellation handling is drawn as ordinary gateways and tasks in the main flow, for example a gateway after every task asking "Did it fail?".
+
+Why it matters: the normal route is buried under checks, so the main purpose of the process is hard to see. Gateways also test only after the task has finished, so they cannot react while it is still running, such as when a deadline passes.
+
+Fix in BPMN-LD: keep the main flow for the normal case and attach a `BoundaryEvent` to the activity, with `attachedToRef` set to the activity id and an event definition such as `TimerEventDefinition` or `ErrorEventDefinition`. Connect the boundary event with a `SequenceFlow` to the handling steps. A boundary event interrupts the activity by default; set `cancelActivity` to `false` when the activity should keep running while the exception is handled (`examples/positive/boundary-event.jsonld`, `examples/positive/escalation.jsonld`).
+
+Analyzer coverage: not detected by the analyzer; check by review. No rule reports exception checks modelled as gateways. The analyzer does treat a boundary event as part of the flow, so a boundary event whose host cannot be reached is reported as `node-unreachable`.
+
+## Solid arrows between pools
+
+Mistake: a `SequenceFlow` is drawn from an element in one participant (pool) to an element in another, for example from "Send order" in the customer's process straight to "Receive order" in the shop's process.
+
+Why it matters: a sequence flow only orders work inside one process. Between participants the two sides are separate processes run by separate parties, and the only way they interact is by sending messages, so a solid arrow misstates how they are coupled.
+
+Fix in BPMN-LD: keep each `SequenceFlow` inside the `flowElements` of the process that owns both of its ends. Connect the participants with a `MessageFlow` in the `messageFlows` of the `Collaboration`, with `sourceRef` and `targetRef` pointing at the sending and receiving elements, or at the participants when the exchange is not tied to one step. Use a `SendTask` and a `ReceiveTask` or message events as the ends (`examples/positive/collaboration.jsonld`).
+
+Analyzer coverage: not detected by the analyzer; check by review. No rule reports a sequence flow whose source and target are in different participants, so check that every sequence flow stays within one process. The analyzer does check that a `SendTask` or `ReceiveTask` with a `messageRef` has a matching message flow (`task-message-without-message-flow`).
+
+## Spaghetti layout
+
+Mistake: the diagram is placed by hand with coordinates, so flows cross, loop back over other elements and the main path is hard to follow.
+
+Why it matters: a diagram that cannot be read at a glance hides the process it describes, and hand-placed coordinates drift out of date whenever the model changes.
+
+Fix in BPMN-LD: leave the diagram out while building the model and let the layout command place it. Run `npm run layout -- <file> -o <out.jsonld>` to write the model with a laid-out diagram, or `npm run export -- --layout <work>/positive/<name>.jsonld -o <work>/<name>.bpmn` to lay out and export in one step. Existing diagram content is kept; adding `--force` to either command replaces it by a fresh full layout, so use `--force` only when the layout should be redone.
+
+Analyzer coverage: not detected by the analyzer; check by review. The analyzer looks at the process structure, not at the diagram, so look at the laid-out result and keep the flow direction consistent.

package/skills/bpmn-ld/references/explain-and-document.md

@@ -0,0 +1,36 @@
+# Explain and document an existing model
+
+Use this when the user gives a model and asks what it does, or asks for documentation of it. Read the model; do not change it.
+
+## Get a BPMN-LD model
+
+- A BPMN-LD file (`.jsonld`): read it directly.
+- A BPMN 2.0 XML file (`.bpmn`, `.xml`): convert it first, from the repository root, into a scratch directory:
+
+  ```
+  npm run convert -- <work>/<name>.bpmn -o <work>/positive/<name>.jsonld
+  ```
+
+  Exit code 0 means the file was written. Conversion `warning:` lines go to standard error; they name XML constructs that were not carried over, so mention them when they affect the explanation. Exit code 2 means unusable input (missing file, malformed XML, not BPMN): report it and stop. Explain the converted file, never the XML.
+
+## Explain in plain language
+
+1. Read the whole model first: processes, participants, lanes, flow nodes and sequence flows. Follow `sourceRef` and `targetRef` to trace paths from each start event.
+2. Start with one or two sentences saying what the process achieves and what triggers it.
+3. Walk the steps in the order they happen. Say who or what performs a step from its type: a user task is done by a person, a service task by a system, a sub-process groups further steps.
+4. Explain every gateway: an exclusive gateway chooses one path, a parallel gateway runs all paths at once, and say what each outgoing flow means using its `name` and `conditionExpression`; name the default flow.
+5. Describe how the process can end, one end event per outcome.
+6. Use the exact name of every named element (the `name` property), so the reader can find it in the model. Mention every named element: events, tasks, gateways, sequence flows, participants and lanes. Use plain words around the names and avoid identifiers, IRIs and JSON-LD terms unless asked.
+7. Do not invent behaviour the model does not state. Say so when a name or condition is missing, and say which element it concerns, by `id`.
+
+## Documentation structure
+
+When the user wants documentation, write Markdown (or prose when asked) with these sections:
+
+- A heading with the process name and a short summary.
+- Steps: a numbered list in execution order, each naming the element exactly.
+- Decisions: each gateway with its outcomes.
+- Outcomes: the end events and what each means.
+- Notes: conversion warnings, unnamed elements and anything uncertain.
+
+Write the documentation to the path the user gives, or present it in the reply.

package/skills/bpmn-ld/references/modify-existing-model.md

@@ -0,0 +1,49 @@
+# Modify an existing model
+
+Use this when the user gives a model, as BPMN-LD or BPMN 2.0 XML, and asks for a change. Edit the model in place; never regenerate it from scratch.
+
+## Get a BPMN-LD model
+
+- A BPMN-LD file (`.jsonld`): copy it to `<work>/positive/<name>.jsonld` and edit the copy.
+- A BPMN 2.0 XML file (`.bpmn`, `.xml`): convert it first, from the repository root:
+
+  ```
+  npm run convert -- <work>/<name>.bpmn -o <work>/positive/<name>.jsonld
+  ```
+
+  Exit code 0 means the file was written. Conversion `warning:` lines go to standard error and name XML constructs that were not carried over (`incoming` and `outgoing` children are derived and not kept); report those that affect the change. Exit code 2 means unusable input: report it and stop. Existing diagram data (`bpmndi:`) is converted to `BPMNDiagram`, `BPMNShape` and `BPMNEdge` nodes with the same coordinates. The converted file points its `@context` at the hosted `combined.jsonld`, which the validation commands cannot fetch: replace that first `@context` entry with the two entries `<repo>/contexts/core.jsonld` and `<repo>/contexts/di.jsonld` (absolute path of the repository root, as in `template.jsonld`). A model with diagram data needs the `di.jsonld` context. Edit the converted file, never the XML.
+
+## Edit in place
+
+1. Make exactly the requested change and nothing else. Do not reformat, reorder, rename or re-id other elements.
+2. Preserve identifiers: every existing `id` stays as it is, and so do `sourceRef`, `targetRef`, `attachedToRef` and `default` values that point at untouched elements. Give new elements new unique `id` values in the style of the existing ones.
+3. Preserve extensions: keep every property with a prefix or absolute IRI (for example `acme:priority`) and the prefix declarations in the `@context`, on every element, including those you change.
+4. Preserve existing diagram data: do not edit, move, resize, delete or re-id any `BPMNShape`, `BPMNEdge`, their `bounds` or `waypoints`. Do not write coordinates for new elements by hand.
+5. When a change removes an element, remove its own shape and edges together with it. When a change rewires a flow, its existing edge keeps its old waypoints; say so in the report instead of editing it.
+6. Keep the structure of the document: nested stays nested, `@graph` stays `@graph`.
+
+## Lay out only what is missing
+
+Layout completes partial diagram data: it appends shapes and edges only for the flow nodes and sequence flows that lack them and never modifies existing ones (see `docs/conventions/layout.md`). To get a file with the completed diagram:
+
+```
+npm run layout -- <work>/positive/<name>.jsonld -o <work>/<name>-laid-out.jsonld
+```
+
+Do not use `--force`: it replaces the whole diagram with a fresh layout and so discards the existing coordinates. Only use it when the user explicitly asks for the layout to be redone.
+
+## Re-check and export
+
+1. `npm run validate -- <work>` and `npm run analyze -- <work>/positive/<name>.jsonld --format json`; fix errors as in the generate workflow, within the same three-round cap.
+2. Export with layout of the missing parts, then run the external checks:
+
+   ```
+   npm run export -- --layout <work>/positive/<name>.jsonld -o <work>/<name>.bpmn --json
+   npm run check-xml -- <work>/<name>.bpmn --json
+   ```
+
+3. Compare with the original: every element you were not asked to change has the same properties, and every original shape and edge has the same `bounds` and `waypoints`.
+
+## Report
+
+State the path of the modified model, which elements were changed, added or removed by `id`, the results of validate, analyze and check-xml, the path of the exported `.bpmn` file, and any assumptions.