LS5011: One Message Maps to Two Use Cases

Reference#

What the Rule Enforces#

LS5011 enforces Point Code and Tests up to Records (litespec/core/system#point-code-and-tests-up-to-records). It runs in every layer, where the generator writes the registry mapping each marked handler's message type to its use case. Its category is LiteSpec.Traceability.

What the Rule Reports#

The generator maps each marked handler's message type to the handler's use case, so the pipeline reads the permission the use case grants and the audit action it names from the message. A message two marked handlers serve with different use cases takes no entry, and the rule reports it, naming both handlers. The diagnostic has no source location, because the clash lives in the marks across the handlers.

Failing Example#

Two command handlers serve SubmitExpenseCommand: one carries use-case/spending.submit-expense and the other carries use-case/spending.approve-expense, so the message takes no entry and the rule reports both handlers.

Passing Example#

One command handler serves SubmitExpenseCommand with use-case/spending.submit-expense, so the message maps to that use case and the rule stays silent. Two handlers serving one message with the same use case take one entry and the rule stays silent.

How to Fix#

Move one of the two handlers to its own message, or mark both handlers with the one use case the message serves, so the message maps to one use case.

Notes#

What the Rule Ignores#

The rule ignores a handler with no use-case mark or with two, which takes no entry without a report. It stays silent when no .litespec/project.json is in reach, or when the docs root it names cannot be resolved; the CLI owns that configuration error.

Severity#

The rule is an error whenever it fires, because the pipeline cannot read the message's permission or audit action until the message maps to one use case. An .editorconfig entry for the rule id overrides it.