Automatic register lookup reaches the constructs bound to its transition

[TIVMOF]

This PR:

• fixes resolves: writes its status through updateProperties, which publishes nothing - so it cannot trigger generates:/postings: #6805

Problem

resolves: persists everything it decides — the resolved relation, the outcome: trace and the found:/notFound:/ambiguous: status — through a single updateProperties call, which publishes no event at all. The constructs that react to a status change (generates: and postings: bound to event: { onTransition: ... }) listen on -transitioned, and the only publishers of that topic were SetField, Transition and Generate. Resolve was not among them; it does not reference Producer anywhere.

So an automatic resolution wrote the status to the database and told nobody, while a manual transitions: button on the same entity reached every consumer — the automation's primary path silently doing nothing, its manual fallback working, and no log line either way. Both constructs use the same Fine/VehicleAssignment/Declaration domain as their worked examples in the assistant guide, about a thousand lines apart, and the composition those examples imply did not work.

Change

Resolve.java.template publishes -transitioned after the write, guarded on a status having actually been written — a lookup that only filled a relation transitioned nothing and announces nothing. It follows Transition and Generate rather than SetField: those two are the non-BPMN publishers, using a plain reload-then-Producer.sendToTopic, whereas SetField's Process.executeAfterCommit only makes sense inside a Flowable command, which a MessageHandler is not. The publish guard is the same status != null as the write guard, so it can never fire without a committed write.

The documentation line in GenerateOnEvent.java.template is corrected while here. It described -transitioned as "the channel every status write publishes", which is not true: a plain REST update() publishes only -updated, and a targeted updateProperty/updateProperties write publishes nothing unless its own template does. It now names the four workflow-routed sources and states explicitly what it is not.

Coverage

resolves: had no IntentEmissionCoverageIT entry, so the status-write path was exercised end to end nowhere. It now has one: a self-contained register scenario (Zone match key, Inspector resolved value, Duty register, Patrol record, PatrolReport downstream target) plus a generates: bound to event: { onTransition: Patrol, when: "Status == POSTED" }.

The last entity is the point. Asserting only that Inspector was filled in would have passed with the bug present — the row was always written, it just was not announced. The assertion that matters is that a PatrolReport exists, which is only possible if -transitioned was published. Duty carries two non-overlapping windows for one zone with the patrol's date inside the second, so resolving to inspector 2 proves the validity period decided it rather than the zone alone.

An emission-layer assertion checks the generated AssignInspectorResolve.java publishes on the right topic and — by index comparison — that the publish sits under the status guard.

Testing

The whole fixture parses through the real IntentParser, which is what enforces the resolves: rules (the register must hold exactly one to-one to the set: target, bounds must be dates, match keys must exist, the status must be reachable). That check rejected the first draft with duplicate entity [Visit] — the fixture already had one — hence Patrol.

Resolve.java.template was rendered through a real Velocity engine in both branches: the publish appears with writesStatus=true, is absent with false, zero unresolved ${...} either way. GenerateOnEvent.java.template was rendered in both isCreate branches, since the doc edit sits inside an #if/#else.

The integration test has not been executed. mvn -P quick-build install -pl tests/tests-integrations -am fails offline in engine-camel (the camel-component-maven-plugin cannot resolve AbstractGenerateMojo), which is environmental and unrelated to this change. The assertions are validated at the layers reachable without a running app — YAML parse, intent parse, template render, formatter — but the HTTP round-trip and the timing of the asynchronous resolution need a CI run before merge.

🤖 Generated with Claude Code

[delchev]

Merged current master into the branch to clear the conflicts (pushed to TIVMOF:fix/resolve-status; the PR is mergeable again). Three conflicts, all your additions meeting master's:

1. GenerateOnEvent.java.template — feat(intent): a create-from on the process-step axis, and an opt-in append cardinality (#6800) #6824 split the topic bullet into a three-way step / create / transition branch while this PR corrected the transition wording (the -transitioned channel is what the workflow routes, not every status write). Master's structure kept, your wording applied to the transition branch.
2. The emission-IT fixture — both sides appended entities and seeds to the same shared model. Both kept; the entry-statuses rows keep master's stage: classification (from The event-driven create-from guard is existence-only - a voided target blocks its replacement forever #6814) rather than the older unclassified copies of the same three rows this branch carried.
3. The emission-IT runtime — both sides appended an assertion method and its call. Both kept, in the order written.

Heads-up on (3): the closing brace of the last method sits outside git's conflict region — shared by both sides — so splicing the blocks left assertResolveTransitionRuntime() unterminated even though the markers were gone. javac caught it; the fix is folded into the merge commit.

Verified on the merged tree before pushing: IntentEmissionCoverageIT green (127 s, both your assertResolveTransitionRuntime and master's assertGeneratesStepAxisRuntime), compile + formatter:validate clean. CI is re-running the rest.