# Changelog

## Score

- CAI 47 → 38 (-9.5)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 44 → 44 (-0.2)
- Architecture 84 → 84 (+0.0)
- Maturity 61 → 59 (-2.2)
- Readiness 33 → 18 (-15.4)
- Security 100 → 70 (-30.1)

## Resolved (4)

- Inconsistent casing in class name: 'clsApi' vs 'ClsApi'. The namespace `Case.DimensionOverrides.API` uses `clsApi` while `Case.ParallelWalls.API` uses `ClsApi`. This is a casing inconsistency for the same conceptual class (API helper).
- Inconsistent naming for local settings fields across different form classes. While '_s' is a common abbreviation, it is not descriptive. In other parts of the codebase (e.g., `Case.ApplySysOrient.Data.clsSettings`), the class name is explicit. Using a generic abbreviation like '_s' for a field holding a specific configuration object reduces readability and consistency with more descriptive naming conventions found elsewhere (e.g., `_cmd`, `_fd`, `_e` which are also abbreviations but context-specific). However, the primary inconsistency here is the mix of descriptive class names in Data layers vs abbreviated field names in UI layers. A more significant inconsistency is found in the API layer.
- Members sharing a duplicated core (4 members, 50+ identical tokens) (2015/Case.RoomSync/Case.RoomSync/UI/form_Sync.vb)
- Typo in method name: 'ChechHidden' appears to be a misspelling of 'CheckHidden'. While 'ShowMessage' is a different concept, the presence of a clear typo in a public/internal API surface suggests a lack of proofreading consistency within the codebase.

## New (188)

- Consistent naming for Culture properties across all Resources classes. No inconsistency.
- Consistent naming for ResourceManager fields. No inconsistency.
- EmptyCatchBlock (2015/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2015/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2015/Case.ViewCreator/Case.ViewCreator/Forms/form_Main.cs)
- EmptyCatchBlock (2016/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2016/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2016/Case.ViewCreator/Case.ViewCreator/Forms/form_Main.cs)
- EmptyCatchBlock (2017/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2017/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2017/Case.ViewCreator/Case.ViewCreator/Forms/form_Main.cs)
- EmptyCatchBlock (2018/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2018/Case.ViewCreator/Case.ViewCreator/Classes/Entry/app.cs)
- EmptyCatchBlock (2018/Case.ViewCreator/Case.ViewCreator/Forms/form_Main.cs)
- High CVE: [GHSA redacted] (2015/Case.Subs.KeyMatcher/packages.config)
- High CVE: [GHSA redacted] (Case.AppsRibbon.2017/packages.config)
- Inconsistent naming for local settings fields across different form classes. While '_s' is a common abbreviation, the codebase also uses more descriptive names like '_cmd' for command data and 'defaultInstance' for settings. However, since '_s' is used consistently across multiple forms for the same type (`clsSettings`), this is actually a consistent convention within the UI layer. No inconsistency found here as the pattern is uniform.
- Inconsistent naming for the resource culture field/property. Some classes use a field named 'resourceCulture' (e.g., `UngroupAll`), while others use a property named 'Culture' (e.g., `ApplySysOrient`). These represent the same concept (the current culture for resource lookup) but are named differently.
- Inconsistent naming for the resource manager field/property. Some classes use a field named 'resourceMan' (e.g., `FamilySubcategories`), while others use a property named 'ResourceManager' (e.g., `Navis2BCF`). These represent the same concept.
- Leaked secret: hardcoded-credential (2015/Case.ApplySysOrient/API/clsAPI.cs)
- …and 168 more