refactor!: run the Camunda 7/8 engine rules as bpmnlint rules (experiment)

CONTRIBUTING.md

@@ -53,16 +53,16 @@ them on a private corpus without copying it into the repository, are described i
   | `domain/commands/` | the commands a caller can ask for (`EditCommand`: `AddElement`, `PlaceShapes`, ...), the ops JSON of `apply` and its aliases |
   | `domain/diagram/` | the drawing (BPMN DI): `di/` reads and writes planes, frames, groups and the checkpoint every engine shares, `layout/` holds the engines (`clean/` redraws with `FullLayout`, `incremental/` keeps a hand-made drawing), `DrawnDiagram` is the drawing the diagram commands change, `commands/` holds one handler per diagram command (`ShapePlacement`, `ShapeAlignment`, `SpaceInsertion`, ...) and `DiagramCommands`, which dispatches them; `BatchDrawing` is all a batch does to the drawing |
   | `domain/editing/` | what changes the model, one folder per concern: `elements/` (add, remove, retype, move, order, placement, artifacts, pools, lanes), `connections/` (connect, associations, sequence flows, bridges, flow ids, split), `properties/` (set, value coercion, the set keys, nested slots, vendor elements, decision links), `events/` (triggers, event definitions, root elements, the event-gateway rule), `extensions/` (ext), `ids/` (id renames); a command is a class created with the `EditSession` (`new ElementCreation(edit).add(op)`, `new Connections(edit).connect(op)`, ...) |
-  | `domain/validation/` | structural validation (`StructuralValidator`, `FlowOrder`), the validator hook, the `FindingBaseline` a write compares with and the `FindingMatcher` that tells the same finding before and after an edit; `profiles/` holds the engine rules that load on demand |
+  | `domain/validation/` | structural validation (`StructuralValidator`, `FlowOrder`), the validator hook, the `FindingBaseline` a write compares with and the `FindingMatcher` that tells the same finding before and after an edit; `PlatformCheck` adds the Camunda 7 / 8 findings of the injected `EngineLint` |
   | `domain/views/` | the read views (`show`, `find`, `--around`, `--context`) and `DrawableDoc`, a document ready to draw (one without a diagram laid out in memory) |
   | `domain/batch/` | one batch of commands on a document in memory: `EditBatch` (guard, commands, validation, layout, kept text, result), `ModelCommands` hands each model command to its domain service and `BatchDrawing` (`domain/diagram/`) lays the drawing out between them; the top of the domain, nothing imports it back |
   | `application/port/in/` | one contract per use case, the way in: an interface with its `Command` and `Result` (`EditDocumentUseCase`, `RelayoutDiagramUseCase`, `ValidateDocumentUseCase`, `ShowModelUseCase`, ...), also for a pure query that needs no outbound port |
-  | `application/port/out/` | what the application needs from outside, named after what it does: `DocumentPort` (load a document, resolve where a result goes, save it), `LoadProjectSettingsPort` (the `.bpmnlintrc`), `RenderDiagramPort` (a plane as SVG), `WriteImagePort` |
+  | `application/port/out/` | what the application needs from outside, named after what it does: `DocumentPort` (load a document, resolve where a result goes, save it), `LoadProjectSettingsPort` (the `.bpmnlintrc`), `RenderDiagramPort` (a plane as SVG), `EngineLintPort` (the Camunda 7 / 8 rules), `WriteImagePort` |
   | `application/service/` | one service per use case that implements its contract (`EditDocumentService implements EditDocumentUseCase`): load, let the domain work, save, all through the outbound ports; a query asks the domain and returns its answer |
   | `adapters/in/cli/` | the driving adapter: the `Cli` (commander, streams, exit codes, errors) and one class per command; it knows the use cases only by their contracts and reaches the domain only through them; from the domain it takes the command vocabulary to check its flags (errors, op rules, flag values) |
   | `adapters/in/report/` | what a use case's result looks like to the one who asked: text and JSON reports (`MutationText`, `MutationReportBuilder`, `ValidationText`, ...), the views as text, and the reference the guide and `bpmn kinds` print; the CLI prints them and `index.ts` / `api.ts` return them |
-  | `adapters/out/bpmnlint/` | the injected bpmnlint as a validator of the domain, browser-safe: `BpmnlintConfigResolution` (the effective `.bpmnlintrc`), `BpmnlintValidator`, `IdConventionsReader` (the id conventions of `element-id-naming`) |
-  | `adapters/out/files/` | the driven adapters on disk, Node only: `FileDocumentStore`, `BpmnlintProjectSettings` (loads the `.bpmnlintrc` and its plugins for `adapters/out/bpmnlint/`), `FileImageWriter` (PNG via resvg) |
+  | `adapters/out/bpmnlint/` | the injected bpmnlint as a validator of the domain, browser-safe: `BpmnlintConfigResolution` (the effective `.bpmnlintrc`), `BpmnlintValidator`, `IdConventionsReader` (the id conventions of `element-id-naming`); `BpmnlintEngineLint`, the Camunda 7 / 8 rules (the `EngineLintPort`), which loads `engine/` on demand: camunda-compat's rules (`compatRules`) and bpmn-cli's own rules (seventy for Camunda 7, fifty for Camunda 8: `engine/rules/c7|c8/`, one rule per file and one check per rule, next to the `support/` helpers of that engine, the shared helpers in `engine/rules/support/`, the rule bases both engines share in `engine/rules/`; a rule is named after what must hold, the id `<engine>-<subject>-<requirement>` and the class `<Engine><Subject><Requirement>Rule` in a file of its name (`c7-message-needs-name`, `C7MessageNeedsNameRule.ts`), the requirement `needs-<part>` for what must be there, `no-<part>` for what must not, or `known`, `valid`, `unique`, `allowed`, `supported`, `placement`, `resolves` for a value, a name or a place the engine accepts; it declares one `code` and `impact` in `defineRule`, several rules may share a code; an abstract base without `defineRule` (`C7ExecutableRule`, `C8FeelRule`, ...) holds what two or more rules check alike; the rules on what a typed parse drops read the file as written through `WrittenModel`, written on `EngineRule` of `@miragon/bpmnlint-plugin-rules/engine` and run in one walk with its `lint`), mapped to `W_C7_*` / `W_C8_*` by the engine run in `engine/run/` (`EngineRun`, `EngineFindings`, `EngineCodes`, `EngineHint`; `CompatVerdicts` holds where bpmn-cli reads camunda-compat differently); `engine/` gets the core from `engine-kit.ts` (a rule chunk must not import the entry) |
+  | `adapters/out/files/` | the driven adapters on disk, Node only: `FileDocumentStore`, `BpmnlintProjectSettings` (loads the `.bpmnlintrc` and its plugins for `adapters/out/bpmnlint/`), `FileImageWriter` (PNG) |
   | `adapters/out/document/` | `DocumentStore`, what the file store and the in-memory store share behind the `DocumentPort`: a source parsed into a `Doc`, the lossless check, the target of a write and whether to write; browser-safe |
   | `adapters/out/render/` | the SVG renderer behind the `RenderDiagramPort`, browser-safe: `SvgRenderer` (the port), `DocRenderer` (one plane, start to end), `crop/` (which part of the plane), `paint/` (the shapes, connections and labels as SVG), `compose/` (frame, scale, badges, tiles) |
   | `adapters/out/memory/` | the driven adapters of the in-memory API: `NoDocumentFiles`, `NoProjectSettings` |
@@ -119,9 +119,10 @@ them on a private corpus without copying it into the repository, are described i
 
 `bpmn-moddle` (the semantic model; `moddle` for its types), `@resvg/resvg-wasm` (the PNG rasteriser of
 `bpmn render`), `commander` (the CLI only), and `bpmnlint` (pinned to `11.15.0`) with
-`@miragon/bpmnlint-plugin-rules` (pinned to `0.12.1`: bpmnlint's rules, camunda-compat and
-Miragon's rules behind one resolver), loaded only when a `.bpmnlintrc` applies (see
-[bpmnlint](docs/bpmnlint.md)). Both are pinned exactly: they decide which findings an agent sees,
+`@miragon/bpmnlint-plugin-rules` (bpmnlint's rules, camunda-compat and Miragon's rules behind one
+resolver). They run when a `.bpmnlintrc` applies (see [bpmnlint](docs/bpmnlint.md)), and the plugin's
+`./camunda-7` and `./camunda-8` entries are the Camunda 7 / 8 rules of every check, loaded on demand
+(see [Camunda 7 and Camunda 8](docs/camunda.md#where-the-checks-come-from)). Both are pinned exactly: they decide which findings an agent sees,
 the tests pin those findings, and bpmn-cli uses bpmnlint's `Linter` beyond its documented API.
 
 `camunda-bpmn-moddle` (pinned to `8.0.1`) is a development dependency: its Camunda 7 descriptor

docs/bpmnlint.md

@@ -52,6 +52,11 @@ and `@miragon/rules` come with bpmn-cli and need no install.
 Keep the `moddleExtensions` entry. Without it camunda-compat sees no `camunda:` or `zeebe:`
 properties and reports them missing, as bpmnlint does in CI.
 
+bpmn-cli runs camunda-compat and the Miragon engine layer for every Camunda 7 / 8 file anyway, as
+its `W_C7_*` / `W_C8_*` findings ([Camunda 7 and Camunda 8](camunda.md#where-the-checks-come-from)).
+Extend them in the `.bpmnlintrc` when CI runs `npx bpmnlint` too: the same findings are then listed
+twice, once under their code and once under the rule name.
+
 ::: warning Untrusted repositories
 A `.bpmnlintrc` can name plugins of the repository, and `bpmn validate` then runs their code, as
 `npx bpmnlint` would. In a repository you do not trust, pass `--no-lint-config`. See