feat(camunda-process-test): add Web Modeler scenario file support

[HanselIdes]

Summary

• Adds references/web-modeler-scenarios.md — self-contained one-shot guide for running Web Modeler-exported scenario files as integration tests
• Updates SKILL.md step 1 (Detect) to scan for * test scenarios.json files alongside BPMNs and route to the new reference
• Updates references/setup.md with the connectors bundle image version constraint and a pointer to the failsafe setup

What the new reference covers

Detection — format fingerprint distinguishing WM scenario files from hand-authored .test.json: processId at root, no $schema, metadata.coveredFlowNodes per test case. Names both supported resource layouts (src/main/resources/ in a standard Maven module, ../resources/ for the sibling test/ harness).

Cluster architecture decision — table of three modes (ephemeral Testcontainers, remote-shared, remote-WM-cluster), tradeoffs, and where the decision is persisted in the repo (application-integration.yml Spring profile, committed).

Templates — two Java *IT.java templates (failsafe, not surefire):

• Ephemeral: @SpringBootTest(camunda.process-test.connectors-enabled=true) + @TestDeployment + 60s timeout
• Remote cluster: no @TestDeployment + 120s timeout + env var table for credentials

pom.xml additions — a <testResource> with integration-scenarios and a maven-failsafe-plugin snippet, both inside <build>.

Troubleshooting table — WM-specific failure rows (element ID drift, timeout, image version, missing env vars).

Validated against

Built and tested the ephemeral pattern on solutions/vehicle-eligibility-check/ in HanselIdes/camunda-8-tutorials: NhtsaIntegrationIT.java runs 2 scenarios from Vehicle Eligibility Check test scenarios.json against the real NHTSA API — Tests run: 2, Failures: 0.

> Open question on this claim. The review found that the connectors property in the guide was wrong (see below). If io.camunda.process.test.connectors-enabled never enabled connectors, this run should not have passed — so either the tutorial project sets the correct key and the guide transcribed it wrong, or something else was carrying it. Needs a check against what NhtsaIntegrationIT actually sets before this section can be treated as confirming the corrected template.

Changed during review

Property names, verified against docs.camunda.io rather than against what the repo already said.

• CPT properties are camunda.process-test.*, not io.camunda.process.test.*. The latter is the Java package CPT's classes live in, not the Spring prefix. The guide contradicted itself: the application-integration.yml snippet already used camunda.process-test.runtime-mode while the @SpringBootTest block beside it used io.camunda.process.test.connectors-enabled. Spring ignores an unknown property silently, so the failure mode was connectors never starting and a connector job never completing.
• Client addresses sit directly under camunda.client; camunda.client.zeebe.* is the older Spring Zeebe SDK shape. The OIDC key is auth.issuer-url, not auth.issuer. Added rest-address — the client prefers REST over gRPC by default, so remote mode with only a gRPC address configures the hop it does not use.
• runtime-mode values lowercased to managed / remote, as the docs write them.
• Env vars are CAMUNDA_GRPC_ADDRESS / CAMUNDA_REST_ADDRESS, matching camunda-job-workers/references/worker-sdk-spring.md instead of introducing a second convention for the same value.

Real defects in the snippets.

• The pom snippet was missing its <build> wrapper. Maven ignores <testResources> and <plugins> declared anywhere else, silently — so the snippet produced a valid POM where scenarios never reached the test classpath and failsafe never ran. That is the "WM scenario file not discovered" symptom this guide's own troubleshooting table attributes to a missing <targetPath>.
• The <include> glob needed **/. A Maven * does not cross directories, so a scenario exported next to a BPMN in a subfolder of src/main/resources was never copied.
• The <testResource> directory was wrong for both layouts, then documented for only one. It started as ../src/main/resources, which is correct for neither a standard Maven module nor the sibling test/ harness (setup.md#nodejs-project-layout reads from ../resources). It now defaults to src/main/resources and carries the harness path as an actual commented-out <directory> line rather than as prose, so a harness reader swaps a line instead of translating a sentence. Two active <directory> elements would be invalid, so the keep-exactly-one constraint is stated.
• The Docker Hub tag check interpolated an undefined ${TAG}. Confirmed by running it: with TAG empty the URL collapses to the tag-listing endpoint, which returns 200 for every image, so the check reported "exists" for anything.
• @TestDeployment now uses the processes/ prefix, matching the scaffold layout in setup.md.
• The scenario-file example is fenced jsonc, since it carries a /* … */ comment and was not parseable as json.

Progressive disclosure.

• Two integration-test-only sections moved out of setup.md (failsafe plugin, connectors bundle image version) into web-modeler-scenarios.md, which is loaded on demand. SKILL.md routes to setup.md unconditionally, so every CPT task was reading 52% more of a page whose additions only matter for integration tests. This took the unconditionally-loaded path from +3,606 to +1,588 bytes over main, and the rocket-launch cost gate responded immediately — see the eval discussion in the thread.

Documentation accuracy.

• The guide referred to a camunda.version property that setup.md never defines — it pins camunda-process-test.version. The two now agree, with the upstream name noted where it differs.
• SKILL.md's reference blurbs promised "agentic evaluation assertions" in authoring.md and "evaluation assertions" in test-context.md; neither page has that content, so both read as they do on main again.
• Parameterized test display names set in both templates, so CI names the scenario that failed instead of an index.
• Earlier rounds: dropped the "in CI/CD" overclaim from the title, de-duplicated the connectors-bundle tag guidance from four places to one, corrected the tag-coverage claim after it turned out to be false, and stopped hard-coding the sibling-harness path for the integration profile.

Pushed back on one finding. Copilot asked me to hedge the camunda.client.prefer-rest-over-grpc default on the grounds that nothing in this repo supports it. The claim is correct per the properties reference and hedging it would weaken the reason rest-address is mandatory; the sentence now cites the reference inline instead.

Follow-ups filed, not fixed here

• camunda-process-test: connectors-runtime.md uses io.camunda.process.test.* as the Spring property prefix #92 — connectors-runtime.md on main carries the same wrong CPT property prefix. Also raises whether an eval should assert the emitted CPT config, since this skill ships these snippets into real projects.
• camunda-job-workers: worker-sdk-spring.md uses the pre-8.8 camunda.client.zeebe.* property nesting #93 — camunda-job-workers/references/worker-sdk-spring.md uses the pre-8.8 camunda.client.zeebe.* nesting.

Known blocker

license/cla is red. fd79eb3 and 849bac30 are authored by Claude <noreply@anthropic.com>, which cannot sign; the check was green through 20a5f2d and every other commit is authored normally. Fixing it means re-authoring those two commits, squash-merging, or allowlisting the address. Rewriting history on this branch is deliberately left to @HanselIdes.

🤖 Generated with Claude Code

[HanselIdes]

@huygur — Claude-generated skill update, closes epic 3498.

This adds guidance for running Web Modeler-exported test scenario files in CI/CD as a first-class workflow in the camunda-process-test skill.

One thing worth a close look: the detection pattern. Web Modeler exports files named <Process Name> test scenarios.json (space before test, no dot). The existing hand-authored CPT format is <processId>.test.json (dot before test). The Maven glob in the new reference uses * test scenarios.json — the space is literal and intentional, so the pattern won't accidentally match .test.json files. Flagging it because it's subtle and easy to misread.

[HanselIdes]

@HanselIdes one thing I need your call on, and one suggestion.

references/judge-configuration.md doesn't exist. This branch added three links to it — the "Agentic exception" scope bullet, the Java-fallback line in step 4, and a References entry — but never added the file. It isn't on main either, and the branch's own base didn't have those links, so it looks like content that leaked in from another branch rather than anything to do with Web Modeler scenarios.

I removed all three and restored main's wording for the two prose spots, because dangling links fail waza check link health and the agentic-judge material is out of scope for this PR. If that page is coming in a PR of your own, nothing is lost — re-add the links there. If you'd rather it land here, say so and I'll write the reference instead.

Suggestion: after the main merge this branch now carries the camunda-process-test outcome eval, and the change touches SKILL.md step 1 (Detect). Worth applying evals:run before merge to confirm the added WM-scenario routing doesn't move the baseline.

For context on the rest: three review threads addressed and resolved, one commit pushed, plus a merge of main (the branch was 135 commits behind, which predated the reference-file split). The connectors-bundle tag claim was wrong and is corrected — details in the thread on setup.md.

---

Generated by Claude Code

[Copilot]

Pull request overview

Adds documentation and guidance to support running Web Modeler–exported CPT scenario files (the * test scenarios.json envelope) as integration tests, and wires that guidance into the camunda-process-test skill’s detection and setup references.

Changes:

• Add a new one-shot reference guide for detecting and executing Web Modeler scenario files, including cluster-mode templates and Maven wiring.
• Update the skill’s “Detect” step to recognize * test scenarios.json files and route users to the new reference instead of authoring .test.json suites.
• Expand setup guidance with a failsafe plugin snippet and connectors bundle image version constraints for connector-enabled runs.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
skills/camunda-process-test/SKILL.md	Adds detection guidance for Web Modeler scenario exports and links the new reference in the skill’s reference list.
skills/camunda-process-test/references/web-modeler-scenarios.md	New end-to-end guide for running Web Modeler scenario exports via failsafe, including templates for managed vs remote runtime modes.
skills/camunda-process-test/references/setup.md	Adds failsafe guidance for *IT.java and documents connectors bundle image tag constraints and overrides.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

🧪 Eval results

Triggers 1/1 · Outcomes 2/2 — ✅ all passed. Non-blocking signal (doesn't block merge).

Model anthropic/claude-sonnet-4-6 · 346,639 tokens [I: 29, CW: 57,201, CR: 280,964, O: 8,445]
I input · CW cache-write · CR cache-read · O output. Cost gate keys on I+O; CW/CR are diagnostic.

Outcome evals

Eval	Outcome	I+O (vs baseline)
camunda-process-test	✅ 1/1	✅ 2k (-11% vs 3k)
rocket-launch	✅ 1/1	✅ 6k (+25% vs 5k)

Trigger evals (skill routing)

Skill	Routing
camunda-process-test	✅ 3/3

Per-eval token usage and full logs → run summary

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

skills/camunda-process-test/references/web-modeler-scenarios.md:231

• Calling out a specific NullPointerException for a missing ZEEBE_GRPC_ADDRESS is overly specific and may not match the actual failure mode (often it surfaces as a config/connection error). A more generic symptom keeps this troubleshooting tip accurate across versions and configurations.

| Remote mode: `NullPointerException` on `ZEEBE_GRPC_ADDRESS` | Environment variable not set | Set the required env vars (see table above) |

skills/camunda-process-test/references/web-modeler-scenarios.md:82

• In the pom.xml snippet, the default <directory> value points to ../src/main/resources, which is only correct for the sibling test/ harness layout. For a standard Maven module where tests live in the same module, the typical path is src/main/resources, so the snippet is likely to be copy/pasted incorrectly.

    <directory>../src/main/resources</directory>   <!-- adjust to project layout -->

skills/camunda-process-test/references/web-modeler-scenarios.md:228

• This troubleshooting row refers to metadata.coveredFlowNodes, but earlier the document states CPT ignores metadata at runtime. As written, this is internally inconsistent and may mislead readers about what can actually fail at runtime.

This issue also appears on line 231 of the same file.

| Element ID in `metadata.coveredFlowNodes` not found in BPMN | BPMN was modified after the scenario was exported from Web Modeler | Re-export the scenario from Web Modeler, or update element IDs manually |

skills/camunda-process-test/references/setup.md:198

• This section hard-codes a few specific version examples of missing camunda/connectors-bundle tags. Those specifics are likely to become outdated and turn the guidance into a maintenance liability; the key point is that pre-release tag coverage is incomplete.

The reason is tag coverage, not tag absence: `camunda/connectors-bundle` does publish `-rc*`, `-alpha*`, and `SNAPSHOT` tags, but not for every version `camunda/camunda` has. `8.7.0-alpha3-rc2`, `8.8.0-alpha3-rc3`, and `8.6.12-rc1` all exist for `camunda/camunda` with no connectors-bundle counterpart. When the derived tag doesn't exist, the test fails at startup with `ContainerFetchException` for `camunda/connectors-bundle:<version>`.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ HanselIdes
❌ claude
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[HanselIdes]

Picked up the four suppressed comments from the last Copilot review (fd79eb3). They never became threads, so they were sitting unaddressed behind the "generated no new comments" summary.

1. testResource path — real, and worse than reported. Copilot flagged ../src/main/resources as only correct for the sibling harness. It isn't correct for that layout either: setup.md#nodejs-project-layout says the harness reads process files from ../resources. So the snippet was wrong for both supported layouts. Now defaults to src/main/resources (standard Maven module, where WM exports the file) and points at the harness layout for the alternative. Same defect class as the Step 2 path you already had me fix in r3747542357 — that fix landed one instance and missed this one.

2. metadata.coveredFlowNodes troubleshooting row — real contradiction. The same page states CPT does not read or enforce metadata, so a stale ID under metadata cannot be a runtime failure. The actual failure is a scenario instruction targeting an element ID that no longer exists. Row retargeted, with an explicit note that metadata is not the cause.

3. NullPointerException on ZEEBE_GRPC_ADDRESS — generalised. I could not verify that specific exception, and asserting a precise failure mode I haven't reproduced is how the connectors-bundle claim went wrong earlier in this PR. Now describes the symptom as a failure resolving the cluster address.

4. Hard-coded missing tags — half right, and it collides with an earlier request. Those versions exist because @maff pushed back on an unevidenced claim and evidence was the fix; deleting them would walk that back. But the staleness point is fair, because pre-release tags are pruned independently per image. Resolved by shipping the check instead of the list:

curl -sf "https://hub.docker.com/v2/repositories/camunda/connectors-bundle/tags/${TAG}" >/dev/null \
  && echo "exists" || echo "missing — pin a GA version or override the tag"

Verified live before documenting it — 8.8.0 → exists, 8.6.12-rc1 → missing, junk tag → missing. One verified example stays in the prose; the reader can now re-derive the rest instead of trusting a list that ages.

Validation skipped: make lint SKILL=camunda-process-test could not run — waza is not on PATH in this environment and it installs as an azd extension, which is also absent. Changes are Markdown-only in one skill. CI runs the same check.

@HanselIdes one thing for you, since it needs a maintainer call: finding 1 is a behavioural failure mode an eval would catch — an agent following the old snippet writes a <directory> that silently keeps the scenario file off the classpath, which surfaces as "@TestCaseSource found nothing" rather than an error. If you want that covered, evals:run on this PR plus a scenario asserting the right testResource directory per layout would do it. I didn't add one unprompted.

---

Generated by Claude Code

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

skills/camunda-process-test/references/web-modeler-scenarios.md:195

• Same as the ephemeral template: set the parameterized test display name so the WM scenario name appears in test output (matches the style used in references/setup.md).

    @ParameterizedTest

skills/camunda-process-test/references/web-modeler-scenarios.md:148

• For consistency with the existing CPT template in references/setup.md, set the parameterized test display name so CI output shows the scenario name (otherwise failures are harder to map back to the WM test case).

This issue also appears on line 195 of the same file.

    @ParameterizedTest

skills/camunda-process-test/references/web-modeler-scenarios.md:157

• This note uses a shorthand property name (connectors-enabled=true), but the actual Spring property key (as shown in the snippet above and in references/connectors-runtime.md) is io.camunda.process.test.connectors-enabled=true. Using the full key here avoids readers searching for a non-existent property.

- `connectors-enabled=true` starts the `camunda/connectors-bundle` container so the HTTP JSON connector and other outbound connectors execute for real.

skills/camunda-process-test/references/setup.md:196

• The property key here is abbreviated as connectors-enabled=true, but the actual Spring property (used elsewhere in this skill) is io.camunda.process.test.connectors-enabled=true. Spelling out the full key reduces ambiguity for readers configuring CPT.

If `connectors-enabled=true` is set, CPT pulls `camunda/connectors-bundle:<camunda.version>`. Prefer a GA release for `camunda.version`.

[HanselIdes]

Closing the eval question I raised above: not adding one — correctness evals aren't supported yet, so there's nothing for the classpath failure mode to hook into. No evals:run label needed on this PR.

That leaves this PR at correction-only, which is the right shape without an eval safety net. Every change is a fix to something demonstrably wrong, each verified against a source rather than reasoned about:

• the testResource path, against this skill's own setup.md#nodejs-project-layout
• the metadata troubleshooting row, against the statement on the same page that CPT ignores metadata
• the connectors property key, against connectors-runtime.md and the snippet directly above it
• the parameterized-test display name, against the existing ProcessTest template
• the connectors-bundle tag claim, against a live Docker Hub query

CI green on 849bac3: waza check, skill:camunda-process-test, scenario:rocket-launch, and the sandbox build all pass.

Ready for maintainer review — @maff, the two threads you opened are the ones that started this, and both are resolved.

---

Generated by Claude Code

[HanselIdes]

FYI @maff I'm trying to clear out some WIP, so I put Claude on driving convergence and addressing comments. Closing this is at best a distracting quick win, so please protect your focus + context and don't feel this needs to be reviewed quickly

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (7)

skills/camunda-process-test/references/web-modeler-scenarios.md:208

• The required env var table should match the YAML snippet and the repo’s other Spring client docs (CAMUNDA_GRPC_ADDRESS / CAMUNDA_REST_ADDRESS naming). As written, readers may set ZEEBE_GRPC_ADDRESS but keep CAMUNDA_GRPC_ADDRESS in their local tooling, or vice-versa.

| Variable | Description |
|----------|-------------|
| `ZEEBE_GRPC_ADDRESS` | gRPC endpoint, e.g. `https://abc.zeebe.camunda.io:443` |
| `CAMUNDA_CLIENT_ID` | OAuth client ID |

skills/camunda-process-test/references/setup.md:197

• This section assumes camunda.version exists, but earlier in this guide the dependency example uses camunda-process-test.version. Clarify that the connectors-bundle tag follows the CPT dependency version (whatever property the project uses) so readers don’t go hunting for an undefined camunda.version.

## Connectors bundle image version

If `io.camunda.process.test.connectors-enabled=true` is set, CPT pulls `camunda/connectors-bundle:<camunda.version>`. Prefer a GA release for `camunda.version`.

skills/camunda-process-test/references/web-modeler-scenarios.md:233

• This troubleshooting row refers to ZEEBE_GRPC_ADDRESS, but the guide’s config/env-var naming should be consistent (and elsewhere in the repo Spring examples use CAMUNDA_GRPC_ADDRESS). Update the variable name here to match the rest of the page.

| Remote mode: startup fails resolving the cluster address | A required environment variable is unset, so the client has no address to connect to | Set the required env vars (see table above) |
| Remote mode: process not found | BPMN not deployed to target cluster, or wrong cluster credentials | Deploy via Web Modeler or `c8ctl deploy`; verify `ZEEBE_GRPC_ADDRESS` points to the right cluster |
| WM scenario file not discovered by `@TestCaseSource` | File not on classpath, or `<targetPath>` missing from pom.xml | Confirm the `<testResource>` block in pom.xml uses `<targetPath>integration-scenarios</targetPath>` and the glob matches the filename |

skills/camunda-process-test/references/web-modeler-scenarios.md:86

• The Maven <includes> pattern <include>* test scenarios.json</include> only matches files in the root of src/main/resources. If Web Modeler exports scenarios next to BPMN/DMN inside a subfolder (e.g. src/main/resources/processes/), the file won’t be copied into test resources and @TestCaseSource won’t discover it. Use a recursive include pattern.

    <includes>
      <include>* test scenarios.json</include>       <!-- space before "test" is literal; matches WM pattern, not .test.json -->
    </includes>

skills/camunda-process-test/references/web-modeler-scenarios.md:66

• This guide introduces ZEEBE_GRPC_ADDRESS, but other repo docs standardize on CAMUNDA_GRPC_ADDRESS for Spring client configuration (see camunda-job-workers/references/worker-sdk-spring.md). Aligning env var names avoids two parallel conventions for the same value.

This issue also appears in the following locations of the same file:

• line 205
• line 231

    zeebe:
      grpc-address: ${ZEEBE_GRPC_ADDRESS:}
    auth:

skills/camunda-process-test/references/web-modeler-scenarios.md:159

• This note assumes the project defines camunda.version, but the CPT setup guide in this repo uses other property names (e.g. camunda-process-test.version). To prevent copy/paste confusion, describe the tag source as “the CPT dependency version on the classpath” (and optionally mention both common property names).

- `io.camunda.process.test.connectors-enabled=true` starts the `camunda/connectors-bundle` container so the HTTP JSON connector and other outbound connectors execute for real.
- The connectors bundle image tag is derived from `camunda.version` in `pom.xml`, so `camunda.version` must be a version that image was published for — see the version guidance in [setup.md](setup.md).
- 60 seconds is a safe default timeout for a single external HTTP call. Increase it if the process has multiple sequential connector calls.

skills/camunda-process-test/references/setup.md:62

• This paragraph references “the version” without tying it back to the property name used in the snippet above (camunda-process-test.version). Adding the property name(s) here will make it clearer what readers should pin in pom.xml, especially since later sections refer to camunda.version.

This issue also appears on line 194 of the same file.

Use 8.9+ — the instruction-based `.test.json` format (`CREATE_PROCESS_INSTANCE`, `COMPLETE_JOB`, …) requires it.

**Use a GA release, aligned with the version the target production cluster runs.** If connectors are enabled, the version also has to be one the connectors bundle image was published for — see [Connectors bundle image version](#connectors-bundle-image-version) below.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

skills/camunda-process-test/references/web-modeler-scenarios.md:74

• This sentence asserts a specific default (camunda.client.prefer-rest-over-grpc defaults to true) but there’s no supporting reference elsewhere in this repo. To avoid potentially incorrect guidance across versions, consider wording this as a requirement to supply both addresses for remote mode without claiming the default behavior.

`rest-address` is not optional for remote mode: the client prefers REST over gRPC by default (`camunda.client.prefer-rest-over-grpc` defaults to `true`), so a remote runtime configured with only a gRPC address has no address for the calls it actually makes.

skills/camunda-process-test/references/web-modeler-scenarios.md:66

• This comment states that camunda.client.zeebe.* nesting is "pre-8.8" and "not the current" config shape, but elsewhere in this repo the Spring YAML example uses camunda.client.zeebe.grpc-address/rest-address (e.g. camunda-job-workers/references/worker-sdk-spring.md). Consider rephrasing this to avoid asserting a single canonical property shape, since it can vary by dependency/version.

This issue also appears on line 74 of the same file.

    # Addresses sit directly under camunda.client. The camunda.client.zeebe.*
    # nesting is the pre-8.8 Spring Zeebe SDK shape and is not the current one.
    grpc-address: ${CAMUNDA_GRPC_ADDRESS:}

skills/camunda-process-test/SKILL.md:201

• These reference descriptions mention "agentic evaluation assertions" / "evaluation assertions", but the linked docs don’t appear to contain that content (e.g. references/authoring.md has no "agentic" section). Please adjust the descriptions to match the current contents, or add the referenced material in the linked pages.

- [authoring.md](references/authoring.md) — `.test.json` schema, full 8.9 instruction reference, Java fallback, agentic evaluation assertions
- [test-context.md](references/test-context.md) — `CamundaProcessTestContext` Java API surface (job/decision/child-process mocking, time control, conditional behavior, evaluation assertions)

skills/camunda-process-test/references/setup.md:204

• The Docker Hub tag check uses ${TAG} but never defines it. If TAG is unset, this will likely hit the /tags/ listing endpoint and incorrectly print "exists". Define TAG explicitly and use the per-tag endpoint so the check is reliable.

curl -sf "https://hub.docker.com/v2/repositories/camunda/connectors-bundle/tags/${TAG}" >/dev/null \
  && echo "exists" || echo "missing — pin a GA version or override the tag"

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (4)

skills/camunda-process-test/references/web-modeler-scenarios.md:82

• The pom.xml snippet is missing the required <build> wrapper. <testResources> and <plugins> must live under <build> in Maven, otherwise readers may paste this into the wrong place and get an invalid POM.

### Step 3 — Update `pom.xml`

Two additions are needed: a `<testResource>` block to put the WM scenario file on the classpath, and the `maven-failsafe-plugin` so the integration test class runs on `mvn verify` but not `mvn test`.

skills/camunda-process-test/references/web-modeler-scenarios.md:142

• @TestDeployment resource paths should match the classpath layout described in setup.md (src/main/resources/processes/...). Using bare filenames here can mislead readers into omitting the processes/ prefix and getting FileNotFoundException at runtime.

@CamundaSpringProcessTest
@TestDeployment(resources = {"MyProcess.bpmn", "my-decision.dmn"})
public class MyProcessIntegrationIT {

skills/camunda-process-test/references/setup.md:175

• This section says to add maven-failsafe-plugin to pom.xml, but Maven requires it under <build><plugins>. Calling that out explicitly helps avoid invalid POM placement when readers copy/paste.

## Failsafe plugin (integration tests)

When adding an `*IT.java` class alongside `ProcessTest.java` (e.g. a Web Modeler integration test), add `maven-failsafe-plugin` to `pom.xml`. Surefire runs `*Test.java` on `mvn test`; failsafe runs `*IT.java` on `mvn verify`.

skills/camunda-process-test/references/web-modeler-scenarios.md:21

• The example is fenced as json but contains a /* ... */ comment, which makes it invalid JSON. This is easy for readers to copy/paste into tooling and then hit parse errors.

    {
      "name": "Happy path",
      "instructions": [ /* standard CPT 8.9 instructions */ ],
      "metadata": {
        "processInstanceId": 1234567890,

[HanselIdes]

Evals are green — and no baseline bump was needed

Pushed 6736344 (step 1 of the plan above). The cost gate did not just clear, it went back under baseline:

[PASS] timer-countdown: bpmn_lint_clean=1.00 cpt_scorer=1.00 process_deployed_on_cluster=1.00
outcome: 1/1 sample(s) passed every gating scorer (≥ 1.0)

cost gate — input+output (baseline × 1.5):
  [PASS] timer-countdown: io 4826 / ceiling 7305 (baseline 4870)

	baseline	0821176 (fail)	6736344 (pass)
io (gate)	4870	9313	4826
output	4,854	9,293	4,810
cache-write	19,496	43,553	25,237
wall clock	—	3:48	2:32

That is the diagnosis confirmed. If this had been variance, moving content between reference files would not have moved the number back onto baseline — it landed within 1% of it, on the run right after the change. The driver was setup.md growing 52% on a page SKILL.md routes to unconditionally.

So step 2 is off the table: do not run evals:regenerate-baselines. There is nothing to absorb. The PR's added content is now where it belongs — behind on-demand loading — and a plain CPT task pays for none of it.

What moved

## Failsafe plugin (integration tests) and ## Connectors bundle image version are out of setup.md and into web-modeler-scenarios.md, which is loaded on demand and is already the integration-testing page. The failsafe section was near-duplicated by Step 3 there, so it collapsed to a two-line pointer keeping the one fact unique to it (surefire owns *Test.java, failsafe owns *IT.java). Cross-references repointed; I verified every link and anchor under the skill resolves.

Net effect on the unconditionally-loaded path (SKILL.md + setup.md): +1,588 bytes over main, down from +3,606. Most of what remains is the Detect-step routing and the reference-list entry, which have to be there for the feature to be discoverable at all.

Current state

Every check on 6736344 is green — waza check, all three eval jobs, sandbox build. The only red left is license/cla, which is the authorship issue and still needs your call (re-author fd79eb3 + 849bac30 and force-push, squash-merge, or allowlist the address).

Copilot has been asked for a review of the refactor commit; I will handle whatever it returns.

One thing worth taking from this beyond the PR: the gate did its job. It caught a progressive-disclosure regression that no reviewer flagged across four rounds — Copilot read these files repeatedly and never mentioned that integration-test detail was sitting on the unconditional setup path. That is an argument for keeping the cost gate strict rather than widening it.

---

Generated by Claude Code

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

skills/camunda-process-test/references/web-modeler-scenarios.md:94

• In the pom.xml snippet, the comment mentions the sibling test/ harness uses ../resources, but the <directory> line is still src/main/resources. For the harness layout, copying WM scenario files will fail unless readers notice they must change <directory> to ../resources. Make the alternative explicit on the <directory> line to avoid a silent misconfiguration.

      <!-- standard Maven module: where WM exported the file.
           Sibling test/ harness: ../resources (setup.md#nodejs-project-layout) -->
      <directory>src/main/resources</directory>
      <targetPath>integration-scenarios</targetPath>

skills/camunda-process-test/references/web-modeler-scenarios.md:9

• The detection fingerprint hard-codes src/main/resources/ as the only “resources directory”, but this skill also supports the sibling test/ harness layout where BPMN/DMN (and WM scenarios) live under ../resources/. As written, this can mislead Node.js/harness users into thinking WM scenario files can’t exist in their layout.

This issue also appears on line 91 of the same file.

- **Location**: alongside BPMN/DMN in the project's resources directory (`src/main/resources/`, not `src/test/`)

[HanselIdes]

Green, with one correction to what I said above

5ce5a86 addresses Copilot's last two findings (the detection fingerprint and the <directory> line both named only src/main/resources, which reads as "not your layout" to anyone on the sibling test/ harness setup.md scaffolds). Every check is green: waza check, all three eval jobs, sandbox build.

But the cost number moved again, and it changes the read. Full sequence:

commit	io	ceiling	output	result
baseline (epochs=3)	4870	—	4,854	—
0821176	9313	7305	9,293	fail
6736344 (section move)	4826	7305	4,810	pass
5ce5a86 (comment lines only)	6506	7305	6,481	pass, 89% of ceiling

5ce5a86 adds a handful of comment lines to an on-demand file and nothing to the unconditional path, yet io went 4826 → 6506. That is a ~35% swing from variance alone.

So I overstated it when I said the 4826 run "confirmed the diagnosis" and that regeneration was off the table. What is actually established:

• The structural half is real and is fixed. Moving those sections took the unconditional path from +3,606 to +1,588 bytes over main, and the number responded immediately. That was a genuine progressive-disclosure regression worth fixing on its own merits, independent of the gate.
• The variance half is larger than I implied. At ±35% on a single sample, no one run is a measurement. The current pass at 89% of ceiling is not comfortable, and an unlucky sample could trip this again without anything changing in the PR.

What I would do

Land it. The content is now in the right place, quality scorers are 1.00 across every run, and the remaining exposure is a flaky gate rather than a regression being papered over.

Do not regenerate the baseline. It would raise the ceiling to accommodate variance the content no longer causes, and it would bake in whatever the sampled run happened to spend.

The durable fix is the gate's sampling, not this PR. The baseline was recorded at epochs=3 while PR CI runs max_samples: 1, so a single draw is compared against a three-epoch mean × 1.5. Either running the PR gate at epochs>=3, or making the ceiling variance-aware, would stop this class of false red for every future PR. Happy to open an issue proposing that if you want it tracked — say the word and I will, with these four data points as the evidence.

Where the PR stands

Six commits from this run. Everything Copilot raised across five rounds is fixed or answered with evidence in-thread. All checks green except license/cla, which is still the authorship issue and still your call: re-author fd79eb3 + 849bac30 and force-push, squash-merge, or allowlist Claude <noreply@anthropic.com>.

The other open item is unchanged — whether NhtsaIntegrationIT in the tutorial repo sets camunda.process-test.connectors-enabled, which is what would confirm the corrected template against a real run. Follow-ups #92 and #93 remain filed and independent.

Not merging, not marking ready for review.

---

Generated by Claude Code

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

skills/camunda-process-test/references/web-modeler-scenarios.md:95

• The pom.xml snippet says “Pick the line for your layout … standard Maven module -> src/main/resources / sibling test/ harness -> ../resources”, but only shows the src/main/resources option. Readers using the sibling test/ harness are likely to copy/paste without realizing they must change <directory> to ../resources.

      <!-- Where WM exported the file. Pick the line for your layout:
             standard Maven module -> src/main/resources
             sibling test/ harness -> ../resources  (setup.md#nodejs-project-layout) -->
      <directory>src/main/resources</directory>
      <targetPath>integration-scenarios</targetPath>

[HanselIdes]

Round on 5ce5a86 came back with one suppressed finding, on the <directory> line for the third time. Taken in d8650fd, and this is where I stop.

Fixed — web-modeler-scenarios.md:95, only one layout's <directory> was shown.

The comment named both paths, but only src/main/resources existed as an element, so a reader on the sibling test/ harness had to translate prose into the line they needed. The alternative is now the literal element, commented out directly beneath:

<!-- Where WM exported the file. Keep exactly one of these two lines:
     the first for a standard Maven module, the second for the sibling
     test/ harness (setup.md#nodejs-project-layout). -->
<directory>src/main/resources</directory>
<!-- <directory>../resources</directory> -->

The constraint is stated because two active <directory> elements in one <testResource> is not valid, so "keep exactly one" has to be explicit once the second line is visible. Verified the snippet still parses as well-formed XML.

Why this is the last round. This is the third review to land on this one line, and each round moved it: ../src/main/resources (wrong for both layouts) → src/main/resources plus a prose note → both paths named in the comment → the alternative as an actual line. The remaining objection was about prominence rather than correctness, and there is nothing left to make more prominent — a single-valued element cannot show two options any other way. Per the loop's stop condition, that is converged.

The other finding from the previous round, the detection fingerprint at line 9, was already fixed by 5ce5a86; verified against the file at HEAD, which now names src/main/resources/ and ../resources/ with the setup.md anchor.

Validation: markdown-only. The XML snippet was parsed to confirm well-formedness. waza check still cannot run here — it installs as an azd extension and neither is on PATH — so CI covers it, as on the previous rounds.

Unchanged and still yours, @HanselIdes:

1. license/cla is red, and I have not touched it. fd79eb3 and 849bac30 are authored by Claude <noreply@anthropic.com>, which cannot sign; the bot reads every commit in the PR. Today's commits including this one are authored by you with a Co-Authored-By trailer, matching the rest of the branch, but that does not retroactively fix those two. Re-authoring and force-pushing, squash-merging, or allowlisting the address all work — rewriting history on your branch is your call.
2. The validation claim. If io.camunda.process.test.connectors-enabled never enabled connectors, the PR's green NHTSA run should not have been green. Worth checking what NhtsaIntegrationIT in HanselIdes/camunda-8-tutorials actually sets, since that decides whether the corrected template is confirmed or merely differently wrong. The "Validated against" section is untouched pending your answer.
3. Follow-ups camunda-process-test: connectors-runtime.md uses io.camunda.process.test.* as the Spring property prefix #92 and camunda-job-workers: worker-sdk-spring.md uses the pre-8.8 camunda.client.zeebe.* property nesting #93 remain filed and independent of this PR.

Not merging, not marking ready for review.

---

Generated by Claude Code

[HanselIdes]

Correction to the SHA above: the fix is 5125e6e, not d8650fd. I amended my own commit immediately after pushing it, because d8650fd typed a references/ edit as docs(...), which CONTRIBUTING.md explicitly reserves for repo-level files ("SKILL.md and references/ files are the product, not documentation") — and its subject ran to 85 characters against the ~70 guideline. It is now fix(camunda-process-test): show the harness <directory> line. Content is identical.

Scope of that force-push, since history rewriting on this branch is your call and I want to be precise about what I touched: only my own tip commit, seconds old, nothing built on it. fd79eb3 and 849bac30 — the two CLA-blocking commits — are untouched, and the decision on them is still yours.

Note 5ce5a86 carries the same mis-typed docs(camunda-process-test) prefix from an earlier round. I left it alone rather than rewrite a commit that was already pushed and reviewed; if you squash-merge it becomes moot, and if you rebase-merge it is worth fixing in the same pass as the CLA re-authoring.

---

Generated by Claude Code