learn(load-test): the 6-session cap and 2-4 h stop of an unlicensed local runtime

CHANGELOG.md

@@ -19,6 +19,7 @@ Sections dated before 2026-09-19 predate the cycle and stay as they are. Named m
 
 ## Unreleased
 
+- learn(load-test): **trap 9, an unlicensed local runtime caps concurrent sessions at 6 ("Maximum number of sessions exceeded!") and stops itself after a random 2 to 4 hours, both reading as the app failing under load; more than 6 users needs a licensed runtime or a cloud sandbox.** Text only, ondemand skill. Source: a personal licence-budget gate written after parallel journey runs hit both — MendixMau
 - learn(unit-test): the unit-test skill names the per-flow `Unit flows:` list next to `Unit modules:`, so whether a flow gets a test reads the same in both places (follow-up to #435) — MendixMau
 - learn(load-test): **new on-demand skill for load testing a page without correlating Mendix's client protocol by hand: Playwright records the real `/xas/` calls, a probe maps each opaque `runtimeOperation` to its microflow through Jaeger, and the chosen call is replayed with the session's own cookie and CSRF token.** Ten field traps (HTTP 200 on a failed action, caught REST errors under a green microflow span, the wrong call hammered, a recording that still held the previous page, a tracing check that failed open, a harness that throttled itself, harness vs app limits, requests vs users, sampled trace counts, empty data) and a four-line report that says what the run does not prove. Routed ondemand for lead, test and review; no instrument ships yet and the roadmap's "no load testing" line is reworded. Field evidence: a warehouse demo app, Mendix 11, 16 runs 2026-09-09 to 2026-10-08, bursts of 1000 and 2000 concurrent calls on one session — MendixMau
 - new(process-map): **Process map: one swimlane map per business process, each step on its wireframe once screens exist, every open question and ASSUMED decision pinned to the step it is about; drawn twice, a draft at Stage 2 close without screens (pass 1, shown at CAC-3) and the full map at Stage 3 with screens (pass 2, walked at the Stage 3 gate close-out).** `skills/process-map.md` (when, model, anchoring, build, verify by looking) and `project-bin/process-map.js` (`validate`, `anchor`, `build`; Node stdlib, deterministic) with its template. Named "map" because "process" in the progress report means the toolkit's own stages, while this shows the app's business process. With no wireframes, a step may name a screen that is not drawn yet or have none, and a person step stays a person step; once a wireframe exists `validate` fails a step page with no wireframe, a use case on no process and not standalone, a decision with one outcome, two steps in one cell. `anchor` places items mechanically (named microflow, listed or named use case, named screen, overlapping source lines) and keeps judged placements by fingerprint, so a reworded question is unplaced again instead of silently wrong; global buckets are allowed and counted. Wired into the Stage 3 Agent produces and Surface rows, a `process-map` opt-in manifest row (an existing model counts as opting in), the `swimlanes` opt-in row (the model discharges it), CAC-3 and CAC-4, and a check_stage_3 FAIL when the map is older than its model, its anchors or a wireframe. `tests/wave2/test-process-map.sh` on a synthetic order approval fixture with its own committed BRD, covering both passes. Field evidence: a requirements-driven rebuild POC, 2026-10-16, where the reviewer could not tell where the sixty questions fit; the map placed 102 items with 0 unplaced. — MendixMau

skills/load-test.md

@@ -99,11 +99,18 @@ degrade each other (measured: both lost their navigation menu), which reads as "
 slow". End every session afterwards with `helpers.logout` (the xas logout action, with the token); closing the browser context
 leaves it alive against the runtime's session cap.
 
-**9. The trace store samples.** Jaeger's query caps at a few hundred traces; one burst makes
+**9. A local app without a licence caps sessions at 6.** A trial runtime allows 6 concurrent
+users ("Maximum number of sessions exceeded!") and stops itself after a random 2 to 4 hours
+("LicenseService: Maximum run time exceeded"). Both read as the app failing under load. On a
+local trial, more than 6 sessions is not a test: use a licensed runtime or a cloud sandbox for
+user counts above 6, and check uptime before a long run. Concurrent *requests* on one session
+hit no such cap in the field runs: the 1000 and 2000 bursts ran on one session.
+
+**10. The trace store samples.** Jaeger's query caps at a few hundred traces; one burst makes
 far more. Read server-side percentiles, never counts, and never read "0 ERROR spans" as "no
 request failed" above the cap.
 
-**10. An empty database is a different app.** A p95 on 50 rows says nothing about 5 million.
+**11. An empty database is a different app.** A p95 on 50 rows says nothing about 5 million.
 State the row counts of the entities the page reads, and look at the query plan or missing
 indexes before blaming the runtime. This is the honest half of "load testing is theatre".