SchemaDataValidator warns "has no member" for every property of camelCase data it has just matched and validated

[matt-edmondson]

What's wrong

SchemaDataValidator.ValidateObject (Schema/Models/SchemaDataValidator.cs:176-196) handles member names inconsistently:

• TryGetMemberProperty (L209-221) finds a member case-insensitively. Its doc comment says it accepts "the casing the serializer would have written".
• accountedFor is a default HashSet<string> (ordinal comparison) filled with member.Name.
• The unknown-property loop (L191-196) then warns about every property name not in accountedFor. That check is case-sensitive.

Failure scenario

Class Player has members Id and Name. The data is {"id": 1, "name": "x"}, which is what System.Text.Json writes with camelCase naming.

1. Both members are found and validated.
2. The validator then also warns Class 'Player' has no member 'id' and … no member 'name'.

Every member of every object in a camelCase data file produces a false warning, which buries any real ones.

Suggested fix

Record the property name that actually matched: have TryGetMemberProperty return it and add that to accountedFor. Alternatively, construct accountedFor with StringComparer.OrdinalIgnoreCase.

Acceptance criteria

• Validating {"id":1} against a class with member Id produces no issues.
• A genuinely unknown property ({"Id":1,"extra":2}) still produces the warning.
• Tests cover both.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Low. The output is only wrong warnings: validation itself is correct and nothing is rejected. The cost is noise, which buries real warnings for anyone whose data is camelCase. The fix is a one-line change of comparer, or returning the name that matched.
• Area / suggested assignment: SchemaDataValidator.ValidateObject / TryGetMemberProperty
• Duplicates: none found.
• In progress: no. PR Bump ktsu.AppDataStorage and 27 others #221 is a dependency bump.

---

Generated by Claude Code