# LS5011: One Message Maps to Two Use Cases

## Intent

LS5011 is a compiler check that reports a message two marked handlers serve with different use cases, because the registry answers each message's use case and grant from one entry. This page states what the rule reports, where the error sits, and how to give the message one use case.

## Reference

### What the Rule Enforces

LS5011 enforces [Point Code and Tests up to Records](https://litespec.dev/4.0.0/core/system.md#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.