JasperFx 2.55.0

One additive feature completing the Event Modeling hotspot story, one defect fix in application-assembly detection, and the first documentation for the Event Model. Minor rather than patch because the overlay and EventModelDescriptor both gain public surface; nothing is removed, renamed or obsoleted, and every existing constructor and JSON payload round-trips unchanged.

Prose hotspots declared in the overlay (#690 — PR #695)

HotspotOrigin.Prose has existed since #687 as a reserved form — a hotspot a source could emit but nobody could author. #689 made a pending specification is a hotspot the primary mechanism and deliberately deferred this one; this adds the authoring surface.

• EventModelSliceBuilder.Hotspot(text) attaches a HotspotDescriptor.Prose to that slice. It renders as a Hotspot element in the wireframe lane in the canonical magenta, exactly like a pending-spec hotspot — and a slice that is nothing but a hotspot still renders one element, which is the point for a slice you have thought about but not built.
• EventModelBuilder.Hotspot(text) attaches to the model instead, for a question that is not about any one slice, through a new additive EventModelDescriptor.Hotspots.

Both fold the way everything else in the model does: unioned across sources, deduplicated on origin plus text, order preserved. Prose and a pending specification that happen to share a string stay two distinct hotspots, because they mean two different things.

Prose is the escape valve, not the default, and the XML docs on both methods say so. A pending-specification hotspot is evidence: it appears because a real spec is failing or unbound, and it retires itself the day that stops being true. Prose has no lifecycle — nothing retires it but you. Once a question is sharp enough to name a scenario, write the pending spec instead.

Application-assembly detection no longer adopts generated code (#697 — PR #698)

Ports the one fix from JasperFx/wolverine#4024 that JasperFx needed.

DetermineCallingAssembly skipped System* / Microsoft* / test runners / Critter Stack assemblies and nothing else. But AssemblyGenerator names its output with Path.GetRandomFileName() and loads it from a stream, so runtime-compiled assemblies carry a random 8.3-style name and an empty Location — and a walk running during code generation would find one sitting immediately outside the JasperFx frames and adopt it.

The noisy symptom is a false ApplicationAssemblyReuseWarning: instrumenting a fully green 2495-test Wolverine suite produced 44 of them, 41 blamed on generated assemblies, and every one a false positive. The serious symptom is silent — the same walk picks the assembly used for type discovery, so adopting a generated assembly means scanning one that holds none of the application's types, and the only evidence is a handler, document or projection mysteriously not being found.

The walk now skips IsDynamic and empty-Location assemblies. The Location half is switched off under a single-file publish, where every bundled assembly reports an empty Location including the real application assembly; there the walk falls through to Assembly.GetEntryAssembly(), which is the correct answer for a single-file app anyway.

The other two fixes in that Wolverine PR were checked and do not apply here: AddJasperFx already captures the registration assembly eagerly before deferring into optionsBuilder.Configure, and establishApplicationAssembly already runs the divergence check on the branch that adopts RememberedApplicationAssembly. That matters beyond this release — #697 was the stated blocker for consolidating Wolverine onto the shared JasperFxOptions.ApplicationAssemblyReuseWarning, and it is now clear.

Event Modeling documentation (PR #696)

The semantic model shipped across #687, #689 and #690 with nothing but XML docs behind it. There is now a documentation section — overview, the overlay API, hotspots, and the wire descriptors — modelling Wolverine's IncidentService sample end to end.

Every snippet is compile-checked out of DocSamples, which had silently stopped compiling: it used Microsoft.NET.Sdk.Web, whose OutputType defaults to Exe, and there is no Program.Main in it. It is back on Microsoft.NET.Sdk and now in jasperfx.slnx, so the samples are built on every CI run and a sample that drifts from the API fails the build.

Package versions

JasperFx, JasperFx.Events, JasperFx.Events.ComplianceTests, JasperFx.Events.SourceGenerator, JasperFx.SourceGenerator and JasperFx.Aspire go to 2.55.0. JasperFx.RuntimeCompiler is on its own version track and is unchanged at 5.0.0.