Adding Chronicle silently changes how a command's key is resolved

[woksin]

Background

Arc resolves a command's key from System.ComponentModel.DataAnnotations.KeyAttribute or ICanProvideKeyForCommand, but only in an application without Chronicle — with Chronicle, EventSourceValuesProvider resolves the key from Cratis.Chronicle.Keys.KeyAttribute, a property assignable to EventSourceId, or ICanProvideEventSourceId.

ARCCHR0008 covers the case where someone reaches for the wrong [Key] in a project that already references Chronicle.

Problem

It cannot cover the transition. An application that correctly uses the data annotations [Key] today, and adds Chronicle later, gets no warning — Chronicle takes over key resolution, finds no key property on those commands, invents a fresh event source id for each, and every read model keyed by them resolves to nothing.

What surfaces is ReadModelDoesNotExistForCommand — "The command targets an entity that does not exist" — on requests whose entity exists perfectly well. Nothing points at the attribute, and the commands were not touched by the change that broke them.

ARCCHR0008 does fire once Chronicle is referenced, so the diagnostic exists — but it appears as a warning on code the author did not just write, mixed in with everything else adding Chronicle reports at once. There is nothing tying it to "you have just changed how keys are resolved".

Proposed direction

This belongs with the MissingWithChronicleAnalyzer story rather than with ARCCHR0008 on its own — that analyzer already reasons about the wiring-level question of whether Chronicle is set up in a project that uses it. Some options:

• Word ARCCHR0008 so it reads as a resolution change rather than a typo, naming both attributes and what happens at runtime if it is left alone.
• Report it once at the wiring level — "this application resolves keys through Chronicle; N commands declare their key the other way" — rather than once per property, so the count is visible when adding WithChronicle().
• A code fix that swaps the using and the attribute, which makes the transition mechanical.

Acceptance criteria

• Adding Chronicle to an application whose commands declare their key with the data annotations attribute surfaces the change in a way that names the consequence, not only the attribute.
• Nothing is reported for an application that has no Chronicle, where the data annotations attribute is correct.
• An Entity Framework Core read model's [Key] is never reported.

References

• Source/DotNET/Chronicle.CodeAnalysis/CommandDataAnnotationsKeyAnalyzer.cs — the current rule.
• Source/DotNET/Chronicle.CodeAnalysis/MissingWithChronicleAnalyzer.cs — the wiring-level analyzer this likely belongs with.
• Documentation/backend/chronicle/code-analysis/ARCCHR0008.md
• Documentation/backend/chronicle/read-models/other-providers.md#declaring-the-key-without-chronicle