# Changelog

## Score

- CAI 53 → 53 (-0.0)

## Lenses

- Code Health 82 → 82 (+0.0)
- Architecture 87 → 85 (-1.3)
- Maturity 63 → 63 (-0.1)
- Readiness 38 → 38 (+0.0)
- Security 55 → 55 (+0.0)
- Domain Modelling 100 → 100 (+0.0)
- Performance 80 → 80 (+0.0)

## Resolved (6)

- Ambiguous intent between 'create' and 'edit'. 'create' takes an 'Into' descriptor and returns the object. 'edit' has two overloads: one taking an optional existing object (likely for updating in-place or creating if nil), and one taking an 'Into' descriptor and an ObjectID (likely for fetching and updating). The naming 'edit' for a creation-like operation (when passed nil) and a fetch+update operation is confusing and inconsistent with standard CRUD semantics where 'create' is distinct from 'update'.
- Documentation: no project overview (docs/Classes/AsynchronousDataTransaction.html)
- Duplication of 'fetchExisting' across 'BaseDataTransaction' and 'DataStack'. While 'DataStack' is the entry point, 'BaseDataTransaction' (which is used within 'DataStack.perform') also exposes the exact same 'fetchExisting' signatures. This suggests that 'fetchExisting' is a read-only operation that shouldn't necessarily be part of a 'Transaction' interface, or that 'DataStack' is duplicating functionality that should be internal to the transaction context. It creates confusion about whether 'fetchExisting' is a transactional operation or a direct store access.
- Inconsistent naming and return types for import operations. 'importObject' has two overloads: one returning 'O?' and one returning 'Void'. 'importUniqueObject' returns 'O?'. 'importObjects' returns '[O]'. 'importUniqueObjects' returns '[O]'. The distinction between 'importObject' and 'importUniqueObject' is not clear from the names alone (is 'Unique' about uniqueness constraints or about upserting?). The return type inconsistency (Void vs Optional) for 'importObject' is also confusing.
- Inconsistent naming between 'fetchOne' and 'fetchExisting'. 'fetchOne' takes a 'From' and 'FetchClause' (query-based), while 'fetchExisting' takes an Object, ID, or Collection (identity-based). However, 'fetchExisting' is also present on 'DataStack' with the same signatures. The distinction between 'fetchOne' (query) and 'fetchExisting' (identity) is good, but the presence of 'fetchExisting' on both 'DataStack' and 'BaseDataTransaction' is redundant if 'DataStack' delegates to the transaction. More importantly, 'fetchOne' and 'fetchExisting' serve different purposes, but the naming 'fetchExisting' is non-standard compared to 'fetch' or 'getById'.
- Inconsistent parameter types for 'delete'. One overload takes a collection of ObjectIDs, another takes a collection of Objects (S), and a third takes two optional Objects. This forces the caller to know the specific type of collection or object to use the correct overload, rather than having a unified 'delete' interface that accepts either IDs or Objects via a common protocol or generic constraint.