# Changelog

## Score

- CAI 54 → 54 (+0.1)
- Rubric changed (rubric-2026.08.18 → rubric-2026.08.19) — scores are not directly comparable.

## Lenses

- Code Health 76 → 76 (+0.0)
- Architecture 100 → 100 (+0.0)
- Maturity 51 → 51 (+0.4)
- Readiness 74 → 74 (+0.0)
- Security 57 → 57 (+0.0)
- Performance 48 → 48 (+0.0)

## Resolved (5)

- 'Defer' and 'Create' have overlapping signatures and semantics. Both allow creating a UniTask from a factory. 'Defer' is typically used for deferred execution, but 'Create' also accepts a factory. This creates confusion about when to use 'Create' vs 'Defer'.
- Further orphaned files (smaller)
- The 'Create' method name is overloaded with significantly different semantics. Some overloads create a task from a factory function, while others (like the one taking a state and a factory) are functionally identical to 'Defer' or 'Lazy' patterns. Specifically, 'Create' is used for immediate execution or deferred execution, but the naming doesn't clearly distinguish between 'create a new task now' vs 'create a task that will be executed later'.
- The method 'SuppressCancellationThrow' exists on both 'UniTask' and 'UniTask<T>'. However, the return type is different: 'UniTask' returns 'UniTask' (ignoring the result), while 'UniTask<T>' returns a tuple with a boolean flag. This inconsistency in return types for the same logical operation (suppressing cancellation exceptions) is confusing.
- The method names 'AsUniTaskAsyncEnumerable' and 'AsAsyncEnumerable' are inconsistent with the type names. 'AsUniTaskAsyncEnumerable' converts a standard IAsyncEnumerable to UniTask's IUniTaskAsyncEnumerable. 'AsAsyncEnumerable' converts UniTask's type to the standard IAsyncEnumerable. The naming convention 'As[Type]' is used, but the target type name in the method name is inconsistent (sometimes including 'UniTask', sometimes not).

## New (4)

- Inconsistent naming for conversion methods. `AsUniTaskAsyncEnumerable` converts a standard `IAsyncEnumerable` to a UniTask-specific interface, while `AsUniTask` converts a `ValueTask` to a `UniTask`. The verb `As` is used for both, but the target types are different (interface vs struct). More importantly, `UniTaskValueTaskExtensions.AsUniTask` converts from `ValueTask`, whereas `AsyncEnumerableExtensions.AsUniTaskAsyncEnumerable` converts from `IAsyncEnumerable`. The naming convention `As[TargetType]` is used, but the source types are disparate standard library types. This is acceptable, but `AsUniTask` is a very generic name that could conflict with other conversions.
- Redundant methods for running synchronous actions on the thread pool. `Run` takes an `Action` and returns a `UniTask`. `Void` takes an `Action` (or `Func` with state) and returns `void` (or `UniTaskVoid`). `Action` takes an `Action` and returns an `Action` (a delegate). These three methods all essentially schedule a synchronous action to run on the thread pool, but with different return types and signatures. `Run` is for fire-and-forget or awaiting, `Void` is for fire-and-forget without a task, `Action` is for getting a delegate. The distinction between `Run` and `Void` is subtle and confusing.
- Semantic overlap and confusion between factory methods. `Create` and `Defer` both accept a factory function to produce a `UniTask`, but `Defer` explicitly implies lazy evaluation (not executing until awaited), whereas `Create` is ambiguous about when the factory runs. `Lazy` is a specialized form of `Defer` for single-shot caching. The naming `Create` vs `Defer` is confusingly similar in intent (both create tasks), yet behave differently regarding execution timing.
- redundant comment (src/UniTask.NetCoreTests/ChannelTest.cs)