tests: one behavioral IT per feature for amend, cascade, numbering and the check gate (#7162)

[delchev]

The gap

Four recent features were pinned only by assertions over EMITTED SOURCE - contains("UnitOfWork.run("), contains("itemsRepository.delete(stale)"), flowable:async attributes, descriptor keys. That compiles the generated code and exercises none of it, which is why several defects filed alongside #7162 were invisible to CI.

Each feature now has one IT on the IntentGeneratesItemsIT model - write the intent, call the Generate endpoint the IDE calls, publish, and drive the claim over REST through the published application.

What each one asserts

IntentPostingAmendIT (#7071) - the documented amend loop, walked as a user walks it: issue a document, reject it, edit the amount, issue again. The post is rewritten in place with the new amounts (same entry, never a second one); a redelivery with nothing edited changes nothing, so the loop is not "rewrite on every event"; and once the created entry has left the status the posting created it in, the divergence is reported and the entry left alone for a correcting entry. Before the fix the handler answered the second issue with its idempotency test and left a DRAFT entry 60.00 short of the document it referenced - with nothing anywhere saying so.

IntentCompositionCascadeIT (#7100) - three runtime claims, one fixture. A deleted master's children are gone; the roll-up over them relinquished what it counted, which is what proves they left through their own repositories rather than one SQL statement (the same defect with the rows hidden); a sibling declaring whenMasterDeleted: refuse stops the delete and the trip keeps its legs; and a refusal one level down - a leg carrying a note - rolls the whole cascade back, including the sibling leg the cascade had already deleted.

IntentNumberingPartitionIT (#7101) - two companies allocate from one per: Company series and both start at 1, interleaved so the counters are shown to run independently. The second series is the control and reproduces the mechanism: with no init: on the partition relation its documents run the tenant-wide base row up, and the partition materialized for the second company afterwards forks from that counter (#6517) - exactly what the init: series did before the fix. It also keeps the four assertions above from passing on a build that had simply stopped partitioning.

IntentCheckGateRefusalIT (#7063) - a check-gated approval is refused as the 400 the task completion returns, carrying the authored message; the document stays DRAFT and the task is still the approver's to retry, not a dead-letter incident only an administrator can find. The gate is reached by two routes - one hop on the approve arm, two on the arm behind the rating resolver (the node the shared visited set of #7139 left asynchronous) - and route 1's customer is deliberately unrated, so that route is the only way to the gate and cannot be silently taken by the other. The ungated reject branch of the same decision is the control.

Verification

All four run green together (-Dit.test="IntentCompositionCascadeIT,IntentNumberingPartitionIT,IntentPostingAmendIT,IntentCheckGateRefusalIT"), and each was run against a mutated build so it is not a test that cannot fail:

IT	mutation	result
IntentCheckGateRefusalIT	completingTransactionNodes bypassed (pre-#7065)	red at route 1's refusal
IntentNumberingPartitionIT	applyDefaults neutered (the #7147 regression the issue names)	red at "a company that has issued nothing must start at 1" - got 2
IntentCompositionCascadeIT	deleteOwnedChildren neutered (pre-#7100)	red at the orphaned legs

IntentPostingAmendIT was not mutation-tested; its three outcomes are distinguished by the assertions themselves (one entry, unchanged amounts, the reported divergence read off the handler's log).

mvn formatter:validate clean on the touched module.

Fixes #7162

🤖 Generated with Claude Code