src/Bmotion/Bit.Bmotion.Demos/Pages/AnimatePresencePage.razor-37-37 (1)

37-37: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

IsPresent="true" defeats AnimatePresence exit animations for list items.

The IsPresent prop is hardcoded to true, which means the exit animation will never play when items are removed from the list. AnimatePresence needs IsPresent to toggle to false before the item is removed from the DOM.

Consider binding IsPresent to a dictionary that tracks pending removals, or refactor to wrap the entire @foreach loop so that AnimatePresence can detect membership changes in _items.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion.Demos/Pages/AnimatePresencePage.razor` at line 37,
The AnimatePresence usage currently hardcodes IsPresent="true", which prevents
exit animations from running; change AnimatePresence/IsPresent so IsPresent is
driven by state: either bind IsPresent to a boolean lookup (e.g., a
Dictionary<Guid,bool> like pendingRemoval[item.Id]) and flip it to false before
removing from _items, or instead move the AnimatePresence wrapper to surround
the entire `@foreach` over _items so membership changes in _items are detected
automatically; update the removal logic (the method that removes items) to first
set pendingRemoval[item.Id] = false (or remove the item from whatever
presence-tracking collection) and only after the exit animation completes
actually remove the item from _items.

src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs-145-148 (1)

145-148: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Rotation property handling differs between serialization methods.

In ToCssStyleString(), when both Rotate and RotateZ are set, they're merged into a single rotate() transform using RotateZ ?? Rotate (Line 146). However, in ToJsDictionary(), both properties are added separately if set (Lines 91, 94). This creates different behavior between server-side and client-side rendering, potentially causing a visual jump when JavaScript takes over.

♻️ Proposed fix to align both methods

-if (Rotate.HasValue) d["rotate"] = Rotate.Value;
+if (Rotate.HasValue && !RotateZ.HasValue) d["rotate"] = Rotate.Value;

Or alternatively, emit both in CSS as well (though this may be less clear):

-if (Rotate.HasValue || RotateZ.HasValue)
-    transforms.Add($"rotate({RotateZ ?? Rotate}deg)");
+if (Rotate.HasValue && !RotateZ.HasValue)
+    transforms.Add($"rotate({Rotate.Value}deg)");
+if (RotateZ.HasValue)
+    transforms.Add($"rotate({RotateZ.Value}deg)");

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs` around lines 145 - 148, The
server CSS and client JS disagree because ToCssStyleString() collapses Rotate
and RotateZ into one rotate(...) transform while ToJsDictionary() currently adds
both separately; update ToJsDictionary() so it mirrors ToCssStyleString() by
adding a single rotate entry using RotateZ ?? Rotate (and avoid emitting both
rotate and rotateZ keys), and ensure RotateX/RotateY handling remains unchanged;
modify the logic around where rotate/RotateZ/Rotate are added in
ToJsDictionary() to use the merged value (RotateZ ?? Rotate) and remove the
duplicate emission of both properties.

src/Bmotion/Bit.Bmotion/Components/Motion.cs-498-499 (1)

498-499: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Viewport.Once precedence is not respected on leave.

Line 498 checks only !Once. When Viewport is set, docs say Viewport.Once should win; deactivation should use the effective once value (Viewport?.Once ?? Once).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/Motion.cs` around lines 498 - 499, The
leave handler currently checks only the local Once flag; change it to use the
effective once value from Viewport if present: replace the condition that uses
!Once with one that evaluates !(Viewport?.Once ?? Once) so the deactivation call
in the block (await Engine.DeactivateGestureLayerAsync(_id, "inview")) respects
Viewport.Once; reference symbols: WhileInView, Once, Viewport,
Engine.DeactivateGestureLayerAsync, _id, "inview".

src/Bmotion/Bit.Bmotion/Services/MotionValue.cs-32-33 (1)

32-33: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Enumerate a subscriber snapshot before awaiting callbacks.

At Lines 32–33, callbacks can subscribe/unsubscribe while iterating, which can throw InvalidOperationException and stop notification flow.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/MotionValue.cs` around lines 32 - 33, The
loop over _subscribers in the MotionValue notification method can throw
InvalidOperationException if subscribers change during iteration; fix by
enumerating a snapshot (e.g., create a copy of _subscribers via ToList() or
ToArray()) into a local variable and iterate over that snapshot when awaiting
each subscriber (use the same local name like subscribers and await each
sub(value)), ensuring you reference the same method in MotionValue that
currently contains "foreach (var sub in _subscribers) await sub(value);".

src/Bmotion/Bit.Bmotion/Engine/ColorInterpolator.cs-45-48 (1)

45-48: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Prevent exceptions on invalid hex colors in Parse.

At Lines 45–48, malformed hex input throws instead of returning null. That breaks Lerp’s fallback behavior (return to) and can interrupt animation updates.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/ColorInterpolator.cs` around lines 45 - 48,
The Parse method currently assumes the hex substrings are valid and uses
Convert.ToInt32(h[..2], 16) etc., which throws on malformed input; update Parse
to first validate h.Length (must be >=6 and <=8) and then use safe parsing
(int.TryParse or equivalent with NumberStyles.HexNumber and
CultureInfo.InvariantCulture) for each substring used in Convert.ToInt32(h[..2],
16), Convert.ToInt32(h[2..4], 16), Convert.ToInt32(h[4..6], 16) and the optional
alpha slice (h[6..8]); if any TryParse fails, return null so Lerp’s fallback
behavior remains intact. Ensure the alpha branch still divides by 255.0 when
parsing succeeds.

src/Bmotion/Bit.Bmotion/Services/MotionValue.cs-67-82 (1)

67-82: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Validate transform ranges for minimum length and segment validity.

Current checks only compare lengths. With fewer than 2 points, Line 81 can index out of range; with repeated adjacent input points, Line 77 can divide by zero.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/MotionValue.cs` around lines 67 - 82, The
Map function's validation is insufficient: before using inputRange and
outputRange, ensure they each have at least 2 points (inputRange.Length >= 2)
and that inputRange is strictly monotonic (e.g., for all i inputRange[i+1] !=
inputRange[i], ideally inputRange[i+1] > inputRange[i]) to avoid index issues
and division by zero in the loop inside Map; if these checks fail throw
ArgumentException with a clear message. Add these validations alongside the
existing length-equality check (referencing inputRange, outputRange and the
local Map(T v) function) so the loop and the denominator (inputRange[i + 1] -
inputRange[i]) are guaranteed non-zero. Ensure error messages mention which
condition failed (too few points or non-increasing/repeated input range points).

src/Bmotion/Bit.Bmotion/Services/MotionValue.cs-25-25 (1)

25-25: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Avoid fire-and-forget async work in Value setter.

Line 25 drops the SetAsync task, so subscriber exceptions become unobserved and rapid sets can interleave unpredictably. This needs an explicit update model (e.g., async-only setter path or synchronized queue).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/MotionValue.cs` at line 25, The Value
property's setter currently does a fire-and-forget call to SetAsync (set => _ =
SetAsync(value)), causing unobserved exceptions and race conditions; change the
update model by removing the async fire-and-forget from the setter: either make
the property setter synchronous and call a synchronous helper (e.g., implement a
SetSync method that awaits or locks and updates the backing field), or mark the
setter obsolete/private and expose an explicit async API that callers must await
(keep public Task SetAsync(T value) as the single update path); if concurrency
is a concern, serialize updates inside SetAsync using a SemaphoreSlim or a
dedicated request queue to ensure ordered, awaited execution and to surface
exceptions from SetAsync to callers (refer to SetAsync and the Value property to
apply these changes).

src/Bmotion/Bit.Bmotion/Components/Motion.cs-112-116 (1)

112-116: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Prevent AdditionalAttributes from overriding the generated element id.

At Lines 112–116, an incoming id in AdditionalAttributes can replace _id, breaking the engine/interop contract that targets this element by _id.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/Motion.cs` around lines 112 - 116,
AdditionalAttributes can contain an "id" that overrides the generated _id;
before calling builder.AddMultipleAttributes(seq++, AdditionalAttributes) remove
any "id" key from AdditionalAttributes (or pass a filtered collection that
excludes the "id" key) so the previously set builder.AddAttribute(seq++, "id",
_id) remains authoritative; update the code around the builder.AddAttribute /
builder.AddMultipleAttributes calls to filter out the "id" entry (e.g. call
AddMultipleAttributes with AdditionalAttributes.Where(kvp => kvp.Key != "id") or
copy and Remove("id")).

src/Bmotion/Bit.Bmotion/wwwroot/BitBmotion.js-124-129 (1)

124-129: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

unregisterElement references an undefined viewport observer variable.

Line 128 uses _vpObserver, but only _vpObservers exists. This throws during unregister/teardown and leaves viewport tracking state partially cleaned.

Suggested patch

-    if (_vpObserver && el) _vpObserver.unobserve(el);
+    if (el) _vpObservers.forEach(obs => obs.unobserve(el));

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/wwwroot/BitBmotion.js` around lines 124 - 129, The
unregisterElement function uses a non-existent _vpObserver variable; fix it to
use the actual _vpObservers collection: retrieve the observer for the element
via _vpObservers.get(elementId), call observer.unobserve(el) if both observer
and el exist, and then remove that observer entry from _vpObservers (in addition
to the existing _vpRefs.delete and _runCleanup calls) so viewport tracking is
fully cleaned up.

src/Bmotion/Bit.Bmotion/wwwroot/BitBmotion.js-218-236 (1)

218-236: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Pan delta is always zero due state update order.

At Lines 225 and 234–235, lastX/lastY are overwritten before delta is emitted, so OnPanMove receives deltaX=0 and deltaY=0 every time.

Suggested patch

     const onMove = (e) => {
         const dx = e.clientX - startX, dy = e.clientY - startY;
+        const deltaX = e.clientX - lastX, deltaY = e.clientY - lastY;
         const now = Date.now(), dt = now - lastT;
         if (dt > 0) {
-            velX = (e.clientX - lastX) / dt * 1000;
-            velY = (e.clientY - lastY) / dt * 1000;
+            velX = deltaX / dt * 1000;
+            velY = deltaY / dt * 1000;
         }
-        lastX = e.clientX; lastY = e.clientY; lastT = now;
+        lastX = e.clientX; lastY = e.clientY; lastT = now;
@@
             dotnetRef.invokeMethodAsync('OnPanMove',
                 e.clientX, e.clientY,
-                e.clientX - lastX, e.clientY - lastY,
+                deltaX, deltaY,
                 e.clientX - startX, e.clientY - startY,
                 velX, velY);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/wwwroot/BitBmotion.js` around lines 218 - 236, In
onMove, the code updates lastX/lastY/lastT before calling
dotnetRef.invokeMethodAsync('OnPanMove'), which makes the emitted delta values
zero; compute deltaX and deltaY (e.g., const deltaX = e.clientX - lastX; const
deltaY = e.clientY - lastY) and compute velX/velY using lastX/lastY/lastT first,
then call OnPanMove with those computed deltaX/deltaY and velX/velY, and only
after the invoke update lastX = e.clientX; lastY = e.clientY; lastT = now (or
alternatively move the existing lastX/lastY/lastT assignments to after the
invoke).

src/Bmotion/Bit.Bmotion/Engine/EasingFunctions.cs-70-76 (1)

70-76: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Fix the cubic-bezier derivative used by Newton iteration.

At Line 73, dbx omits the x2 contribution in the final term, so the solver can converge to an incorrect u and return wrong easing values for some curves.

Suggested patch

-                double dbx = 3 * (1 - u) * (1 - u) * x1 + 6 * u * (1 - u) * x2 - 6 * u * (1 - u) * x1 + 3 * u * u;
+                double dbx = 3 * (1 - u) * (1 - u) * x1
+                           + 6 * u * (1 - u) * (x2 - x1)
+                           + 3 * u * u * (1 - x2);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/EasingFunctions.cs` around lines 70 - 76, The
Newton iteration's derivative calculation for the cubic-bezier is incorrect;
replace the dbx assignment in the loop (the line that assigns to dbx using
variables u, x1, x2) with the true derivative of x(u): dbx = 3 * ( (1 - u) * (1
- u) * x1 + 2 * (1 - u) * u * x2 + u * u ); this uses the correct contributions
from x1 and x2 during the Newton step so the solver in the loop converges to the
right u.

src/Bmotion/Bit.Bmotion/Engine/ElementAnimationState.cs-49-55 (1)

49-55: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

SetInstant changes can be lost before they are emitted as CSS updates.

Line 51 returns null when there are no active drivers, and Line 54 clears _dirtyProps each tick. That drops dirty-only updates created by SetInstant (Lines 147-173), so instant style changes may never reach output.

Suggested fix

-        if (_activeAnims.Count == 0 && !_isDragging) return null;
-
-        _transformDirty = _isDragging; // drag always refreshes transform
-        _dirtyProps.Clear();
+        if (_activeAnims.Count == 0 && !_isDragging && !_transformDirty && _dirtyProps.Count == 0)
+            return null;
+
+        var pendingProps = _dirtyProps.Count > 0 ? _dirtyProps.ToArray() : Array.Empty<string>();
+        bool pendingTransformDirty = _transformDirty;
+
+        _transformDirty = _isDragging || pendingTransformDirty; // preserve pending instant updates
+        _dirtyProps.Clear();
+        foreach (var prop in pendingProps) _dirtyProps.Add(prop);

Also applies to: 74-74, 147-173

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/ElementAnimationState.cs` around lines 49 -
55, The Tick method currently returns null early and clears _dirtyProps each
tick which causes SetInstant changes (created by SetInstant) to be dropped
before being emitted; modify Tick (method Tick) so it only returns null when
there are no active drivers, not dragging, AND _dirtyProps is empty (or
alternatively move _dirtyProps.Clear to after emission), ensuring _dirtyProps is
preserved until the CSS updates are emitted for SetInstant; update the logic
around the early return and the placement of _dirtyProps.Clear so
SetInstant-produced dirty properties survive the tick that emits them.

src/Bmotion/Bit.Bmotion/Engine/InertiaDriver.cs-27-27 (1)

27-27: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Guard invalid inertia time constants before integration.

At Line 27, _timeConstantSec can be <= 0. Then Line 55 divides by it inside Math.Exp, which can produce NaN/Infinity and prevent convergence.

Suggested fix

-        _timeConstantSec = config.TimeConstant / 1000.0;
+        _timeConstantSec = Math.Max(config.TimeConstant / 1000.0, 0.001);

Also applies to: 55-55

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/InertiaDriver.cs` at line 27, The code assigns
_timeConstantSec = config.TimeConstant / 1000.0 and later uses it inside
Math.Exp causing NaN/Infinity if <= 0; add a guard in the InertiaDriver
constructor (where _timeConstantSec is set) to validate config.TimeConstant > 0
and either throw ArgumentException or replace with a small positive epsilon
(e.g. 1e-6) to avoid division by zero, and also add a defensive check right
before the Math.Exp usage (the integration/update method that computes the exp
factor) to handle non-positive _timeConstantSec by using the same epsilon or
early-return behavior; reference the field _timeConstantSec and the
integration/update method that computes Math.Exp so both assignment and usage
are fixed.

src/Bmotion/Bit.Bmotion/Engine/ElementAnimationState.cs-119-128 (1)

119-128: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

New AnimateTo calls can strand previous completion awaiters.

Line 127 overwrites _completionSource unconditionally. If another animation starts before the prior one finishes, the old TaskCompletionSource may never complete.

Suggested fix

-        _completionSource = completionSource;
+        if (_completionSource != null && !ReferenceEquals(_completionSource, completionSource))
+            _completionSource.TrySetCanceled();
+        _completionSource = completionSource;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/ElementAnimationState.cs` around lines 119 -
128, The AnimateTo method overwrites the field _completionSource
unconditionally, which can leave previously supplied TaskCompletionSource
instances never completed; before assigning _completionSource in AnimateTo,
check if an existing _completionSource is present and complete it (e.g., call
TrySetCanceled or TrySetResult) to ensure awaiting callers aren't stranded, then
assign the new completion source; update any related cleanup logic that
completes _completionSource on animation end to handle the new behavior so no
double-completion or race occurs.

src/Bmotion/Bit.Bmotion/Engine/AnimationEngine.cs-97-101 (1)

97-101: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

onComplete task is not properly awaited/observed.

At Line 100, ContinueWith(_ => onComplete(), ...) creates a nested task chain that is dropped. Exceptions from onComplete can become unobserved.

Suggested fix

-            _ = tcs.Task.ContinueWith(_ => onComplete(), TaskScheduler.Default);
+            _ = Task.Run(async () =>
+            {
+                await tcs.Task.ConfigureAwait(false);
+                await onComplete().ConfigureAwait(false);
+            });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/AnimationEngine.cs` around lines 97 - 101, The
continuation created with tcs.Task.ContinueWith(_ => onComplete(), ...) drops
the nested task so exceptions from onComplete go unobserved; fix by awaiting the
continuation instead of dropping it — replace the ContinueWith call with
explicit awaits (await tcs.Task; await onComplete();) after
EnsureLoopRunningAsync() so the onComplete() Task is awaited and any exceptions
are observed (refer to the local tcs variable, the onComplete delegate, and the
EnsureLoopRunningAsync() call).

src/Bmotion/Bit.Bmotion/Components/AnimatePresence.razor.cs-30-66 (1)

30-66: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

ExitBeforeEnter is currently a no-op.

The parameter is publicly documented, but the enter/exit state transitions never read it, so behavior is identical whether it is true or false. Please either implement the delayed-enter branch or remove the parameter until it is supported.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/AnimatePresence.razor.cs` around lines 30
- 66, The ExitBeforeEnter parameter is unused; update the lifecycle logic in
OnParametersSet and the OnAllExitsComplete handler so that when ExitBeforeEnter
is true new children do not render until exiting children finish: in
OnParametersSet, when transitioning from present->not present keep current
behavior, but when transitioning from not present->present check ExitBeforeEnter
— if true set a flag (e.g., _deferEnter = true) and do not set _shouldRender =
true, otherwise proceed with current re-enter branch (set _presenceCtx.IsExiting
= false, _presenceCtx.Reset(), _shouldRender = true); in OnAllExitsComplete (the
method subscribed in OnInitialized) clear _presenceCtx.IsExiting, set
_deferEnter = false and set _shouldRender = true so entering children render,
and ensure _prevIsPresent is updated appropriately after these transitions so
state remains consistent.

src/Bmotion/Bit.Bmotion/Services/AnimationControls.cs-35-41 (1)

35-41: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Complete() does not implement its documented behavior.

The method claims to snap elements to end values, but it currently performs the same operation as Stop() (snap to current/intermediate values). This breaks the public API contract and should be implemented distinctly (or the contract/docs adjusted to match actual behavior).

src/Bmotion/Bit.Bmotion/Services/ScrollTracker.cs-24-56 (1)

24-56: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Repeated ObserveAsync calls accumulate observers but overwrite callback state.

Each new observe call replaces _onScroll but keeps previous subscriptions active. This can cause duplicate event streams and unexpected callback routing over time. Either enforce single active subscription (replace old before adding new) or track callbacks per subscription key.

Proposed fix (single-active-subscription semantics)

 public async Task ObserveAsync(string? containerId, Func<ScrollInfo, Task> onChange)
 {
     ObjectDisposedException.ThrowIf(_disposed, this);
+
+    foreach (var key in _subscriptionKeys)
+        await _interop.UnobserveScrollAsync(key);
+    _subscriptionKeys.Clear();
+
     _onScroll = onChange;
     var key = await _interop.ObserveScrollAsync(containerId, _dotnet!);
     if (key != null) _subscriptionKeys.Add(key);
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/ScrollTracker.cs` around lines 24 - 56, The
ObserveAsync method currently overwrites _onScroll while leaving previous
subscriptions in _subscriptionKeys active; change ObserveAsync (and use the
corresponding MotionInterop unobserve method) to first remove any existing
subscriptions before adding the new one: call the interop unobserve function for
each key in _subscriptionKeys (e.g., UnobserveScrollAsync or the appropriate
counterpart on MotionInterop) and clear _subscriptionKeys, then set _onScroll to
the new callback and add only the freshly returned key; ensure
ObjectDisposedException checks and _dotnet usage remain unchanged and that you
only keep a single active subscription key in _subscriptionKeys.

src/Bmotion/Bit.Bmotion/Components/AnimatePresence.razor.cs-64-75 (1)

64-75: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Guard OnAllExitsComplete against stale callbacks after re-entry.

After Reset() on re-entry, late NotifyExitComplete(...) calls from prior exiting children can still trigger AllExitsComplete, and this handler then forces _shouldRender = false even when content is present again.

Proposed fix

 public partial class AnimatePresence : ComponentBase
 {
+    private bool _awaitingExitCompletion;

     protected override void OnParametersSet()
     {
         if (_prevIsPresent && !IsPresent)
         {
             _presenceCtx.IsExiting = true;
+            _awaitingExitCompletion = true;
             _shouldRender = true;
         }
         else if (!_prevIsPresent && IsPresent)
         {
             _presenceCtx.IsExiting = false;
             _presenceCtx.Reset();
+            _awaitingExitCompletion = false;
             _shouldRender = true;
         }

         _prevIsPresent = IsPresent;
     }

     private void OnAllExitsComplete()
     {
+        if (!_awaitingExitCompletion || IsPresent) return;
+        _awaitingExitCompletion = false;
         _shouldRender = false;
         _presenceCtx.IsExiting = false;
         InvokeAsync(StateHasChanged);
     }
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/AnimatePresence.razor.cs` around lines 64
- 75, OnAllExitsComplete must ignore stale callbacks after a re-entry: add an
early-return guard at the top of OnAllExitsComplete that checks the current
presence context state (for example, if (!_presenceCtx.IsExiting) return;) so
that after Reset() or re-entry late NotifyExitComplete calls do not flip
_shouldRender to false; leave the rest of the method (setting _shouldRender =
false, _presenceCtx.IsExiting = false, InvokeAsync(StateHasChanged)) unchanged.

src/Bmotion/Bit.Bmotion.Demos/wwwroot/css/app.css-5-7 (1)

5-7: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Consider providing a visible focus indicator for accessibility.

Removing outline: none on h1:focus eliminates the keyboard navigation focus indicator. Users navigating with keyboard need visual feedback when focus moves to headings. Consider replacing with a custom focus style instead of removing it entirely, e.g., outline: 2px solid #0071c1; outline-offset: 2px;.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion.Demos/wwwroot/css/app.css` around lines 5 - 7, The
h1:focus rule currently removes the keyboard focus indicator; update the CSS
rule for h1:focus (or use h1:focus-visible) to provide a visible focus style
instead of outline: none — for example set outline: 2px solid `#0071c1` and
outline-offset: 2px (or a similarly high-contrast, accessible color/width) so
keyboard users see clear focus on headings.

src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs-158-160 (1)

158-160: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add missing OutlineColor to CSS string serialization.

OutlineColor is serialized in ToJsDictionary() (Line 102) but is missing from ToCssStyleString(). This creates an inconsistency where server-side rendered initial styles won't include outline color, potentially causing a flash of unstyles content.

🎨 Proposed fix

 if (BorderColor != null) sb.Append($"border-color:{BorderColor};");
+if (OutlineColor != null) sb.Append($"outline-color:{OutlineColor};");
 if (Fill != null) sb.Append($"fill:{Fill};");

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs` around lines 158 - 160, The
CSS serializer ToCssStyleString is missing the OutlineColor property causing
inconsistency with ToJsDictionary; update the ToCssStyleString method (near the
lines that append BorderColor, Fill, Stroke) to append OutlineColor when set
(e.g., if (OutlineColor != null) sb.Append($"outline-color:{OutlineColor};");)
so server-side rendered styles include outline color just like ToJsDictionary
does.

src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs-163-163 (1)

163-163: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add missing BoxShadow to CSS string serialization.

BoxShadow is serialized in ToJsDictionary() (Line 108) but is missing from ToCssStyleString(). This inconsistency means server-side rendered initial styles won't include box shadows.

🎨 Proposed fix

 if (BorderRadius != null) sb.Append($"border-radius:{BorderRadius};");
+if (BoxShadow != null) sb.Append($"box-shadow:{BoxShadow};");
 if (PathLength.HasValue)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs` at line 163,
ToCssStyleString() is missing serialization for the BoxShadow property (it’s
present in ToJsDictionary()), so add a check similar to BorderRadius that
appends the CSS box-shadow rule; specifically, in ToCssStyleString() add
something like: if (BoxShadow != null) sb.Append($"box-shadow:{BoxShadow};"); so
server-rendered CSS includes the same box shadow output as ToJsDictionary().

src/Bmotion/Tests/Bit.Bmotion.Tests/Bit.Bmotion.Tests.csproj-4-4 (1)

4-4: ⚠️ Potential issue | 🟡 Minor

Update .NET 10.0 availability concern.

Bit.Bmotion.Tests.csproj targets net10.0;net9.0;net8.0. .NET 10 (net10.0) is publicly released, so the “may not be available yet” concern is not valid. Keep/ensure CI and dev machines have a .NET 10 SDK installed (e.g., SDK version shipped with the current .NET 10 servicing, such as 10.0.301).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Tests/Bit.Bmotion.Tests/Bit.Bmotion.Tests.csproj` at line 4, The
TargetFrameworks element in Bit.Bmotion.Tests.csproj should retain net10.0
(i.e., keep "net10.0;net9.0;net8.0") because .NET 10 is publicly released;
remove any comment or conditional that treats net10.0 as unavailable and ensure
the TargetFrameworks entry includes net10.0. Also update CI/dev environments to
install/use a .NET 10 SDK (for example 10.0.301) so builds and tests can run
against the net10.0 target.

src/Bmotion/Bit.Bmotion/Models/LayoutOptions.cs-10-11 (1)

10-11: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix documentation/code inconsistency.

The comment on Line 10 states "Default: false" but the property initializer on Line 11 sets Enabled = true. These are inconsistent.

Since this is an opt-in options class (users only provide LayoutOptions when they want layout animations), having Enabled = true by default makes sense. Please update the comment to match the code:

-    /// <summary>Enable automatic layout animations. Default: false.</summary>
+    /// <summary>Enable automatic layout animations. Default: true.</summary>
     public bool Enabled { get; set; } = true;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/LayoutOptions.cs` around lines 10 - 11, The
XML doc for the LayoutOptions.Enabled property is incorrect; change its summary
to reflect the actual default (true) by updating the comment on the Enabled
property so it reads "Default: true." Target the property named Enabled on the
LayoutOptions class and only modify the <summary> text to match the initializer
(public bool Enabled { get; set; } = true;).

src/Bmotion/Bit.Bmotion/Models/TransitionConfig.cs-183-213 (1)

183-213: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Properties dictionary is shallow-copied, not deep-cloned.

Line 211 copies the Properties dictionary reference rather than creating a new dictionary. If code mutates the cloned config's Properties, it will affect the original. This may violate the stated intent on lines 178-181 to avoid "mutating the original's fields."

🛡️ Proposed fix to deep-clone the Properties dictionary

         DelayChildren = DelayChildren,
         When = When,
-        Properties = Properties,
+        Properties = Properties == null ? null : new Dictionary<string, TransitionConfig>(Properties.Select(kv => new KeyValuePair<string, TransitionConfig>(kv.Key, kv.Value.Clone()))),
         OnUpdate = OnUpdate,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/TransitionConfig.cs` around lines 183 - 213,
TransitionConfig.Clone currently shallow-copies the Properties dictionary
(Properties = Properties) which lets mutations on the clone affect the original;
change Clone to create a new dictionary instance and copy each entry into it,
deep-cloning common mutable value types where appropriate (e.g., if a value is
an array clone it with ((T[])value).Clone(), if it implements ICloneable call
Clone(), otherwise copy the value reference), then assign that new dictionary to
the Properties property; update the Clone method in class TransitionConfig to
use this new dictionary so the cloned config has its own independent Properties
collection.

src/Bmotion/Bit.Bmotion/Components/Motion.cs-581-581 (1)

581-581: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Tap listener activation should include OnTapCancel.

Line 581 enables tap listeners for WhileTap/OnTapStart/OnTap only. If only OnTapCancel is provided, tap events are never attached.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/Motion.cs` at line 581, The tap listener
activation condition in Motion.cs currently checks WhileTap, OnTapStart, and
OnTap only, so add OnTapCancel to the predicate so tap handlers are enabled when
only OnTapCancel is provided; update the conditional that sets d["tap"] (the
line referencing WhileTap, OnTapStart, OnTap) to also include OnTapCancel.

src/Bmotion/Bit.Bmotion/Services/AnimationController.cs-44-47 (1)

44-47: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Handle null passed to Stop(params string[] properties).

If a caller passes null explicitly, properties.Length throws. This should be treated the same as “no properties”.

Proposed fix

 public void Stop(params string[] properties)
 {
     if (_elementId == null) return;
-    _engine.Stop(_elementId, properties.Length > 0 ? properties : null);
+    _engine.Stop(_elementId, properties is { Length: > 0 } ? properties : null);
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/AnimationController.cs` around lines 44 -
47, The Stop method can throw when a caller explicitly passes null for the
params array; update AnimationController.Stop to treat a null properties
argument the same as no properties by checking properties == null ||
properties.Length == 0 before calling _engine.Stop so you pass null when there
are no properties, e.g. compute a local props variable (or conditional) and call
_engine.Stop(_elementId, props); keep the existing early return for _elementId
and reference the Stop method and _engine.Stop call when making the change.

src/Bmotion/Bit.Bmotion/Components/MotionConfig.razor-28-37 (1)

28-37: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Validate TransitionSpeed to prevent invalid negative durations.

TransitionSpeed is applied as a multiplier downstream; negative values can produce invalid transition timings. Guard this at the config boundary.

Proposed fix

 protected override void OnParametersSet()
 {
+    if (TransitionSpeed < 0)
+        throw new ArgumentOutOfRangeException(nameof(TransitionSpeed), "TransitionSpeed must be >= 0.");
+
     _ctx.DefaultTransition  = Transition;
     _ctx.ReduceMotion       = ReduceMotion;
     _ctx.TransitionSpeed    = TransitionSpeed;
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/MotionConfig.razor` around lines 28 - 37,
OnParametersSet currently assigns TransitionSpeed directly to
_ctx.TransitionSpeed allowing negative values; add validation in OnParametersSet
to clamp or reject negatives (e.g., if TransitionSpeed < 0 then set
_ctx.TransitionSpeed = 0 or reset TransitionSpeed to 1.0) before assigning to
the MotionConfigContext. Update the code that sets _ctx.TransitionSpeed in
OnParametersSet to use the validated/clamped value and keep the public property
TransitionSpeed unchanged except for validation here.

src/Bmotion/Bit.Bmotion.Demos/Pages/Keyframes.razor (1)

75-75: 💤 Low value

Remove empty @code block.

The empty @code { } block serves no purpose and can be removed for cleaner code.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion.Demos/Pages/Keyframes.razor` at line 75, Remove the
unnecessary empty Razor code block by deleting the standalone "`@code` { }"
declaration (the empty `@code` block in the Keyframes component) so the file no
longer contains an unused code region.

src/Bmotion/README.md (1)

115-123: 💤 Low value

Add language identifier to fenced code block.

The fenced code block listing event callbacks should specify a language (e.g., text) to satisfy markdown linters and improve documentation consistency.

📝 Suggested fix

-```
+```text
 OnHoverStart / OnHoverEnd
 OnTapStart / OnTap / OnTapCancel
 OnFocusStart / OnFocusEnd
 OnPanStart / OnPan / OnPanEnd         (PanInfo)
 OnDragStart / OnDrag / OnDragEnd
 OnAnimationStart / OnAnimationComplete
 OnViewportEnter / OnViewportLeave
 ```

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/README.md` around lines 115 - 123, Update the fenced code block
that lists the event callbacks to include a language identifier (e.g., change
the opening triple backticks from ``` to ```text) so markdown linters recognize
it; ensure the closing triple backticks remain unchanged and no other text is
modified.

Source: Linters/SAST tools

src/Bmotion/Bit.Bmotion/Models/AnimationTarget.cs (2)

8-21: ⚡ Quick win

Consider adding state validation.

The class design implies exactly one of Props, Variant, or IsDisabled should be set, but there's no enforcement. A default-constructed AnimationTarget or one created via object initializer could have all properties null/false, creating an invalid state. Consider making the constructor private and only exposing the implicit operators, or adding validation in a constructor.

♻️ Proposed fix to prevent invalid states

-public sealed class AnimationTarget
+public sealed class AnimationTarget  
 {
+    private AnimationTarget() { }
+    
     /// <summary>Direct set of animation properties.</summary>
     public AnimationProps? Props { get; private init; }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationTarget.cs` around lines 8 - 21, The
class allows invalid combinations of Props/Variant/IsDisabled; add a single
private ctor that enforces exactly one of Props != null, Variant != null, or
IsDisabled == true and throws ArgumentException for invalid combos, then expose
public static factory methods (e.g., AnimationTarget.FromProps(AnimationProps
props), AnimationTarget.FromVariant(string variant), AnimationTarget.Disabled())
that call the private ctor to create valid instances; update or add any existing
implicit operators to use these factories and leave the init-only properties
private so instances can only be created via the validated ctor/factories
(ensure HasProps and IsVariant remain derived properties).

---

29-30: 💤 Low value

Clarify the semantics of true conversion.

When true is passed, an empty AnimationProps instance is created. Since an empty AnimationProps has no properties set, it's unclear what would animate. Consider whether this behavior is intentional or if true should map to a different state (e.g., a default animation or be treated as invalid).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationTarget.cs` around lines 29 - 30, The
implicit bool->AnimationTarget conversion currently maps true to an empty
AnimationProps which is ambiguous; update the implicit operator
AnimationTarget(bool value) to either (preferred) initialize Props with a
sensible default animation (e.g., AnimationProps.Default or new AnimationProps {
Duration = X, Easing = Y } — pick existing defaults in the project or add a
static Default on AnimationProps) so a true value means “enabled with default
animation”, or (alternatively) make the operator throw an
InvalidOperationException to force callers to supply explicit props; also update
the XML comment on the implicit operator and add/adjust tests to reflect the
chosen semantics.

src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs (1)

129-175: Keyframes are not rendered in server-side CSS.

The Keyframes dictionary (which can override single-value properties) is handled in ToJsDictionary() but not in ToCssStyleString(). This means keyframe-based animations won't have any server-side rendering, which could cause a flash of unstyled content (FOUC) before JavaScript initializes. Consider whether this is acceptable or if keyframes should fallback to their first value in the CSS string.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs` around lines 129 - 175,
ToCssStyleString() currently ignores the Keyframes dictionary so server-rendered
CSS can miss initial values; update ToCssStyleString() to honor Keyframes as a
fallback source for any property not explicitly set (mirroring how
ToJsDictionary() uses Keyframes): when computing transforms and simple CSS
properties (X/Y/Z, Scale/ScaleX/ScaleY, Rotate/RotateX/RotateY/RotateZ,
SkewX/SkewY, Perspective, Opacity, BackgroundColor, Color, BorderColor, Fill,
Stroke, Width, Height, BorderRadius, PathLength, and any CssVars keys) check
Keyframes for an entry and use its first keyframe value if the explicit property
is null/empty, then format that value the same way the method currently formats
explicit properties (e.g., produce
translate/translate3d/scale/rotate/skew/perspective strings and apply
culture-invariant numeric formatting); keep existing behavior when explicit
properties exist and ensure PathLength clamping and stroke-dashoffset
calculation still use the chosen (explicit or keyframe) value.

src/Bmotion/Bit.Bmotion/Models/MotionVariants.cs (1)

12-16: ⚡ Quick win

Consider documenting the overwrite behavior or adding validation.

The Add method silently overwrites any existing variant with the same name (case-insensitive). While this might be intentional for a fluent API, it could mask configuration errors where a developer accidentally uses the same variant name twice.

Consider either:

1. Documenting this behavior in the XML comments
2. Adding validation to prevent silent overwrites

📝 Option 1: Document the behavior

+    /// <summary>
+    /// Adds or updates a variant with the specified name.
+    /// If a variant with the same name already exists, it will be overwritten.
+    /// </summary>
     public MotionVariants Add(string name, AnimationProps props)

🛡️ Option 2: Add validation

     public MotionVariants Add(string name, AnimationProps props)
     {
+        if (_variants.ContainsKey(name))
+            throw new ArgumentException($"A variant with the name '{name}' already exists.", nameof(name));
         _variants[name] = props;
         return this;
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/MotionVariants.cs` around lines 12 - 16, The
Add method in MotionVariants currently overwrites existing entries in the
_variants dictionary; change Add(string name, AnimationProps props) to validate
first and prevent silent overwrites by checking whether _variants already
contains the provided name (respecting the dictionary's case-insensitivity) and
throwing an ArgumentException or InvalidOperationException with a clear message
if it exists; alternatively (if you prefer keeping overwrite semantics)
add/update the XML doc comment on the MotionVariants.Add method to explicitly
state that calling Add will replace any existing variant with the same name and
consider providing a separate AddOrReplace/Replace method for explicit
replacement.

src/Bmotion/Bit.Bmotion/Models/PanInfo.cs (1)

10-19: 💤 Low value

Consider removing redundant default initializers.

The = new() initializers on lines 10, 13, 16, and 19 are redundant. The downstream consumer (Motion.OnPanMove) always constructs PanInfo with explicit property initialization, so these defaults are never used. Removing them simplifies the model and signals that callers must supply values.

Alternatively, consider making these properties init-only to prevent mutation after construction.

♻️ Proposed cleanup

-    public PointInfo Point { get; set; } = new();
+    public PointInfo Point { get; set; }

-    public PointInfo Delta { get; set; } = new();
+    public PointInfo Delta { get; set; }

-    public PointInfo Offset { get; set; } = new();
+    public PointInfo Offset { get; set; }

-    public PointInfo Velocity { get; set; } = new();
+    public PointInfo Velocity { get; set; }

Or for immutability:

-    public PointInfo Point { get; set; } = new();
+    public PointInfo Point { get; init; }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/PanInfo.cs` around lines 10 - 19, Remove the
redundant "= new()" default initializers from the PanInfo properties and make
them init-only to enforce construction-time assignment and immutability: change
the Point, Delta, Offset, and Velocity properties to use "get; init;"
(referencing the PanInfo class and its Point, Delta, Offset, Velocity
properties) so callers like Motion.OnPanMove must supply values at construction
and cannot mutate them afterward.

src/Bmotion/Bit.Bmotion/Context/PresenceContext.cs (1)

22-27: 💤 Low value

Completion counter may exceed child count if NotifyExitComplete is called for unregistered children.

The comparison on line 25 uses >= which guards against over-counting, but if NotifyExitComplete is called for a child not in _children or after the list has been modified, the event may fire prematurely or multiple times. This is likely fine if AnimatePresence strictly controls the registration/notification lifecycle, but consider adding a guard to ensure child is registered before incrementing.

🛡️ Proposed defensive check

     internal void NotifyExitComplete(Motion child)
     {
+        if (!_children.Contains(child)) return;
         _completedExits++;
         if (_completedExits >= _children.Count)
             AllExitsComplete?.Invoke();
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Context/PresenceContext.cs` around lines 22 - 27,
NotifyExitComplete currently increments _completedExits unconditionally which
can over-count if called for unregistered or duplicate children; update
NotifyExitComplete(Motion child) to first verify the child is registered (e.g.,
if (_children.Contains(child)) { ... }) before incrementing, and guard against
double-counting by either removing the child from _children when counted or
tracking completed items with a HashSet (e.g., completedChildren.Add(child) and
only increment when it was not already present); after the guarded increment,
keep the existing check to invoke AllExitsComplete when _completedExits reaches
_children.Count (or use completedChildren.Count for the HashSet approach).

src/Bmotion/README.md-3-3 (1)

3-3: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Clarify the JavaScript dependency claim to avoid contradictory docs.

The README currently says “zero JavaScript dependencies” while also documenting an auto-loaded JS bridge. Consider rephrasing to “no manual JS wiring” or “no app-authored JS required.”

Suggested wording patch

-A Blazor-native animation library inspired by [Framer Motion](https://www.framer.com/motion/). Springs, gestures, layout animations, variants, and keyframes - **zero JavaScript dependencies**. All animation math runs in C# via WebAssembly.
+A Blazor-native animation library inspired by [Framer Motion](https://www.framer.com/motion/). Springs, gestures, layout animations, variants, and keyframes - **no app-authored JavaScript required**. All animation math runs in C# via WebAssembly.
@@
-The browser bridge (`BitBmotion.js`) ships as a static web asset of the package and is
-imported automatically the first time an animation runs, so no manual `<script>` tag is
-required.
+The internal browser bridge (`BitBmotion.js`) ships as a static web asset of the package and is
+imported automatically the first time an animation runs, so no manual `<script>` tag is required.

Also applies to: 46-48

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/README.md` at line 3, The README contradicts itself by claiming
"zero JavaScript dependencies" while also documenting an auto-loaded JS bridge.
Rephrase the dependency claim in the file at lines 3 and also at lines 46-48
(which have similar wording) to clarify that no manual JavaScript wiring or
app-authored JavaScript is required, rather than claiming zero JavaScript
dependencies altogether. Use language like "no manual JS wiring" or "no
app-authored JS required" to accurately reflect that internal JavaScript is
auto-loaded but users do not need to write or manage JavaScript code themselves.

src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs-113-115 (1)

113-115: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Enforce the documented CssVars key contract.

CssVars is documented as requiring keys that start with --, but invalid keys are currently serialized as regular CSS properties. This can silently override unrelated styles instead of behaving as custom properties.

Suggested fix

         if (CssVars != null)
             foreach (var kv in CssVars)
-                d[kv.Key] = kv.Value;
+            {
+                if (!kv.Key.StartsWith("--", StringComparison.Ordinal))
+                    throw new ArgumentException("CssVars keys must start with '--'.", nameof(CssVars));
+                d[kv.Key] = kv.Value;
+            }
@@
         if (CssVars != null)
             foreach (var kv in CssVars)
-                sb.Append($"{kv.Key}:{kv.Value};");
+            {
+                if (!kv.Key.StartsWith("--", StringComparison.Ordinal))
+                    throw new ArgumentException("CssVars keys must start with '--'.", nameof(CssVars));
+                sb.Append($"{kv.Key}:{kv.Value};");
+            }

Also applies to: 172-174

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/AnimationProps.cs` around lines 113 - 115, The
CssVars dictionary is being serialized without validating that keys follow the
documented contract of starting with `--` (CSS custom property format). This can
cause invalid keys to override unrelated styles. Add validation in both
locations where CssVars are processed (lines 113-115 and lines 172-174) to check
that each key in CssVars starts with `--` before adding it to the dictionary d.
Either skip keys that don't meet this requirement or throw an appropriate
exception to enforce the contract and prevent silent style overrides.

src/Bmotion/Bit.Bmotion/Models/LayoutOptions.cs-20-24 (1)

20-24: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Align Transition default documentation with the actual declaration.

The comment says this defaults to a snappy spring, but this property is declared nullable with no in-type default initializer.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/LayoutOptions.cs` around lines 20 - 24, The
XML documentation comment for the Transition property in LayoutOptions claims it
"Defaults to a snappy spring," but the property is declared as TransitionConfig?
(nullable) with no initializer, meaning it has no actual default value. Update
the documentation comment to accurately reflect that this property is nullable
and either describe the actual default behavior when null, or remove the claim
about defaulting to a snappy spring. Alternatively, if a snappy spring should
truly be the default, add an initializer to provide that default value.

src/Bmotion/Bit.Bmotion/Models/DragOptions.cs-21-21 (1)

21-21: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Clamp Elastic to the documented 0..1 range before serialization.

Elastic is documented as bounded, but ToJsObject() currently forwards any value as-is.

Suggested fix

-            ["dragElastic"] = Elastic,
+            ["dragElastic"] = Math.Clamp(Elastic, 0d, 1d),

Also applies to: 53-53

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/DragOptions.cs` at line 21, The Elastic
property is documented as bounded to a 0..1 range, but the ToJsObject() method
does not enforce this constraint before serialization. Modify the ToJsObject()
method to clamp the Elastic property value to the 0..1 range using Math.Max and
Math.Min before including it in the serialized output. Apply the same clamping
logic to the other property mentioned at line 53 that has similar bounded
documentation.

src/Bmotion/Bit.Bmotion/Services/MotionAnimateService.cs-55-61 (1)

55-61: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add upfront selector validation in AnimateAsync(string selector, ...).

Line 60 forwards selector directly; null/whitespace should fail fast with a clear argument exception.

Proposed fix

     public async ValueTask<AnimationControls> AnimateAsync(
         string selector,
         AnimationProps keyframes,
         TransitionConfig? transition = null)
     {
+        if (string.IsNullOrWhiteSpace(selector))
+            throw new ArgumentException("Selector must be non-empty.", nameof(selector));
+
         var ids = await _interop.ResolveOrRegisterBySelectorAsync(selector);
         return StartAnimations(ids, keyframes, transition);
     }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/MotionAnimateService.cs` around lines 55 -
61, The AnimateAsync method accepts a selector string parameter but passes it
directly to _interop.ResolveOrRegisterBySelectorAsync without validation. Add
upfront validation in the AnimateAsync method to check if the selector parameter
is null or empty/whitespace, and throw an ArgumentException with a descriptive
message if validation fails. This should occur before calling
ResolveOrRegisterBySelectorAsync to fail fast with clear error information.

src/Bmotion/Bit.Bmotion/Services/AnimationController.cs-20-20 (1)

20-20: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Validate elementId in BindTo before storing it.

Line 20 accepts empty/whitespace IDs, which can surface later as runtime failures in engine/interop calls.

Proposed fix

-    public void BindTo(string elementId) => _elementId = elementId;
+    public void BindTo(string elementId)
+    {
+        if (string.IsNullOrWhiteSpace(elementId))
+            throw new ArgumentException("Element id must be non-empty.", nameof(elementId));
+        _elementId = elementId;
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/AnimationController.cs` at line 20, The
BindTo method in the AnimationController class does not validate the elementId
parameter before storing it, allowing empty or whitespace values to be assigned
to the _elementId field. This leads to runtime failures when the invalid ID is
used later in engine or interop calls. Add validation logic at the start of the
BindTo method to check if elementId is null, empty, or whitespace, and throw an
appropriate exception (such as ArgumentException or ArgumentNullException) with
a descriptive message if validation fails. Only assign the value to _elementId
if validation passes.

src/Bmotion/Bit.Bmotion/Engine/TransformComposer.cs-41-43 (1)

41-43: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Avoid emitting identity scale(1) in Build.

Line 41-43 currently adds scale(...) even when the value is 1, which contradicts the “empty when identity” contract and causes unnecessary style churn.

Proposed fix

-        if (t.TryGetValue("scale", out double scale))
-            parts.Add($"scale({scale})");
+        if (t.TryGetValue("scale", out double scale) && scale != 1)
+            parts.Add($"scale({scale})");

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/TransformComposer.cs` around lines 41 - 43,
The TransformComposer Build method is currently adding scale(1) to the parts
list even when the scale value is 1, which contradicts the contract to return
empty content for identity values. Modify the condition in the if statement that
checks t.TryGetValue("scale", out double scale) to additionally verify that
scale is not equal to 1 before calling parts.Add. This prevents unnecessary
style output when the scale transform is the identity value.

src/Bmotion/Tests/Bit.Bmotion.Tests/Engine/TransformComposerTests.cs (1)

44-48: ⚡ Quick win

Add an identity test case for uniform scale.

Build_AllIdentityValues_ReturnsEmpty is a great guard, but it doesn’t include ["scale"] = 1. Adding that case will better lock the identity contract.

Suggested test addition

 [TestMethod]
 public void Build_AllIdentityValues_ReturnsEmpty()
 {
     var t = new Dictionary<string, double> { ["x"] = 0, ["y"] = 0, ["rotate"] = 0 };
     Assert.AreEqual(string.Empty, TransformComposer.Build(t));
 }
+
+[TestMethod]
+public void Build_UniformScaleIdentity_ReturnsEmpty()
+{
+    var t = new Dictionary<string, double> { ["scale"] = 1.0 };
+    Assert.AreEqual(string.Empty, TransformComposer.Build(t));
+}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Tests/Bit.Bmotion.Tests/Engine/TransformComposerTests.cs` around
lines 44 - 48, The test method `Build_AllIdentityValues_ReturnsEmpty` currently
only tests identity values for x, y, and rotate, but omits the scale property.
Add the scale identity value (scale = 1) to the Dictionary initialization in
this test method to ensure the identity contract is fully validated across all
transform properties. This will strengthen the test coverage by verifying that
the TransformComposer.Build method correctly returns an empty string when all
properties including scale are at their identity values.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/Bmotion/Bit.Bmotion/Models/BmotionAnimationProps.cs (1)

169-176: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Path drawing output is still using the broken dash math.

Line 174/175 and Line 234/235 still emit normalized dash values that don’t reliably produce progressive SVG path drawing. This is the same unresolved issue previously reported, now duplicated in both CSS emitters (ToCssStyleString and ToCssStyleDictionary).

Also applies to: 229-236

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/BmotionAnimationProps.cs` around lines 169 -
176, The path drawing output contains broken dash math that does not reliably
produce progressive SVG path drawing, and this issue is duplicated across two
CSS emitter methods. In the ToCssStyleString method (around lines 169-176 with
stroke-dasharray and stroke-dashoffset calculations), fix the normalized dash
value calculations used in the stroke-dasharray and stroke-dashoffset
assignments to use correct math for progressive path drawing. Then apply the
same corrected formula to the duplicate code in ToCssStyleDictionary method
(around lines 229-236) which has the identical stroke-dasharray and
stroke-dashoffset calculations. Both methods must use consistent and correct
dash math to ensure reliable progressive SVG path drawing behavior.

src/Bmotion/Bit.Bmotion/Models/BmotionTransitionConfig.cs (1)

20-23: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Enforce the documented cubic-bezier invariant at assignment time.

Line 20 documents a strict 4-value bezier contract, but Line 22 currently accepts any array and Line 129 clones it unchanged. Please validate EaseCubicBezier as either null or exactly 4 finite values to prevent invalid transition configs from reaching runtime.

Proposed minimal fix

-    public double[]? EaseCubicBezier { get; set; }
+    private double[]? easeCubicBezier;
+    public double[]? EaseCubicBezier
+    {
+        get => easeCubicBezier;
+        set
+        {
+            if (value is not null && (value.Length != 4 || value.Any(v => !double.IsFinite(v))))
+                throw new ArgumentException("EaseCubicBezier must contain exactly 4 finite values [x1, y1, x2, y2].");
+            easeCubicBezier = value;
+        }
+    }

Also applies to: 129-129

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/BmotionTransitionConfig.cs` around lines 20 -
23, The EaseCubicBezier property currently lacks validation despite its
documentation requiring exactly 4 finite values in the format [x1, y1, x2, y2].
Add validation logic to the EaseCubicBezier property setter (around line 22) to
ensure the assigned value is either null or an array with exactly 4 finite
numeric values; reject any other input. Additionally, ensure the cloning
operation at line 129 also validates the array to maintain the invariant, so
invalid configs cannot persist through serialization or copying operations.

src/Bmotion/Bit.Bmotion.Demos/Pages/AnimatePresencePage.razor-47-48 (1)

47-48: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add an accessible name to the remove button.

At Line 47–48, the icon-only ✕ button has no explicit accessible label, so screen readers may announce it ambiguously. Add an aria-label (and mirror the same change in the _listCode snippet around Line 170–171 for consistency).

Suggested fix

-                        <button style="background:none;border:none;color:`#ff4785`;cursor:pointer;font-size:1.1rem"
-                                `@onclick`="@(() => RemoveItem(item.Id))">✕</button>
+                        <button style="background:none;border:none;color:`#ff4785`;cursor:pointer;font-size:1.1rem"
+                                aria-label="@($"Remove {item.Label}")"
+                                title="@($"Remove {item.Label}")"
+                                `@onclick`="@(() => RemoveItem(item.Id))">✕</button>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion.Demos/Pages/AnimatePresencePage.razor` around lines
47 - 48, The remove button displaying the ✕ icon lacks an accessible label for
screen readers. Add an aria-label attribute to the button element in the
RemoveItem button (around lines 47-48) with a descriptive label such as "Remove
item". Apply the same aria-label attribute to the corresponding remove button in
the _listCode snippet (around lines 170-171) to maintain consistency across both
locations.

src/Bmotion/Bit.Bmotion/Components/BmotionConfig.razor-35-35 (1)

35-35: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Guard TransitionSpeed against non-finite values.

TransitionSpeed < 0 ? 0 : TransitionSpeed still allows NaN/Infinity, which can break downstream duration calculations.

Suggested fix

-        _ctx.TransitionSpeed    = TransitionSpeed < 0 ? 0 : TransitionSpeed;
+        _ctx.TransitionSpeed = double.IsFinite(TransitionSpeed)
+            ? Math.Max(0, TransitionSpeed)
+            : 1.0;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Components/BmotionConfig.razor` at line 35, The guard
for TransitionSpeed in the BmotionConfig.razor component only checks if the
value is negative but allows non-finite values like NaN and Infinity to pass
through, which can break downstream duration calculations. Modify the assignment
of _ctx.TransitionSpeed to validate not only that it is non-negative but also
that it is a finite number by using a method like double.IsFinite() in addition
to the negative check, defaulting to 0 for any invalid values.

src/Bmotion/Bit.Bmotion/Services/BmotionValue.cs-68-76 (1)

68-76: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Validate subscriber callbacks for null.

Adding null callbacks currently defers failures to notification time; reject invalid registrations immediately.

Suggested fix

     public IDisposable Subscribe(Func<T, Task> callback)
     {
+        ArgumentNullException.ThrowIfNull(callback);
         _subscribers.Add(callback);
         return new Subscription(() => _subscribers.Remove(callback));
     }

     public IDisposable Subscribe(Action<T> callback)
-        => Subscribe(v => { callback(v); return Task.CompletedTask; });
+    {
+        ArgumentNullException.ThrowIfNull(callback);
+        return Subscribe(v => { callback(v); return Task.CompletedTask; });
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/BmotionValue.cs` around lines 68 - 76, Both
Subscribe method overloads accept null callbacks without validation, allowing
the failure to be deferred until notification time instead of rejecting the
invalid registration immediately. Add null validation at the start of each
Subscribe overload to throw ArgumentNullException if the callback parameter is
null. Apply this check to the async version Subscribe(Func<T, Task> callback)
and the synchronous convenience overload Subscribe(Action<T> callback) before
the callback is used or added to the collection.

src/Bmotion/Bit.Bmotion/Services/BmotionScrollTracker.cs-47-47 (1)

47-47: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Reject null onChange at subscription time.

Failing fast here avoids deferred null callback failures during scroll events.

Suggested fix

     public async Task ObserveAsync(string? containerId, Func<BmotionScrollInfo, Task> onChange)
     {
+        ArgumentNullException.ThrowIfNull(onChange);
         ObjectDisposedException.ThrowIf(_disposed, this);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Services/BmotionScrollTracker.cs` at line 47, Add a
null guard at the start of the ObserveAsync method to validate that the onChange
parameter is not null. If onChange is null, throw an ArgumentNullException with
an appropriate parameter name. This prevents deferred failures when the callback
is invoked during scroll events by catching the issue early at subscription
time.

src/Bmotion/Bit.Bmotion/Models/BmotionDragOptions.cs-7-8 (1)

7-8: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

XML docs contradict the actual API contract.

Line 7 says Null = both axes, but Axis is a non-nullable BmotionDragAxis (Line 8) and defaults to Both. Please align the comment to avoid misleading IntelliSense/API usage.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Models/BmotionDragOptions.cs` around lines 7 - 8, The
XML documentation on the Axis property in BmotionDragOptions contradicts the
actual implementation. The property is non-nullable with a default value of
BmotionDragAxis.Both, not nullable. Update the summary documentation for the
Axis property to remove the reference to "Null = both axes" and instead clarify
that the property defaults to Both when not explicitly set, reflecting the
actual non-nullable contract of the property.

src/Bmotion/Bit.Bmotion/Context/BmotionConfigContext.cs-17-22 (1)

17-22: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Reject negative TransitionSpeed values.

Line 21 accepts any double; negative speeds break the documented timing contract and can silently collapse animations instead of scaling them.

Suggested fix

-public double TransitionSpeed { get; set; } = 1.0;
+private double _transitionSpeed = 1.0;
+public double TransitionSpeed
+{
+    get => _transitionSpeed;
+    set => _transitionSpeed = value < 0
+        ? throw new ArgumentOutOfRangeException(nameof(value), "TransitionSpeed must be >= 0.")
+        : value;
+}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Context/BmotionConfigContext.cs` around lines 17 -
22, The TransitionSpeed property currently accepts any double value without
validation, but negative speeds are invalid according to the documented contract
and will cause animations to malfunction. Add validation to the TransitionSpeed
property setter to reject negative values by throwing an appropriate exception
(such as ArgumentException or ArgumentOutOfRangeException) when a negative value
is assigned, ensuring that only non-negative values are accepted.

src/Bmotion/Bit.Bmotion/Engine/BmotionElementAnimationState.cs-494-497 (1)

494-497: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Cast<string>() may throw if not all elements are strings.

The check oa[0] is string only verifies the first element. If subsequent elements are non-strings, Cast<string>() will throw InvalidCastException.

Proposed fix

         if (value is object[] oa && oa.Length > 0 && oa[0] is string)
         {
-            result = oa.Cast<string>().ToArray();
+            if (oa.All(x => x is string))
+            {
+                result = oa.Cast<string>().ToArray();
+                return true;
+            }
-            return true;
+            return false;
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/BmotionElementAnimationState.cs` around lines
494 - 497, The current code validates only the first element with `oa[0] is
string`, but `Cast<string>()` will throw `InvalidCastException` if any
subsequent element is not a string. Fix this by adding a validation check that
ensures ALL elements in the `oa` array are strings before calling
`Cast<string>()`. Use `oa.All(x => x is string)` in addition to (or instead of)
the existing `oa[0] is string` check to validate the entire array before the
cast operation.

src/Bmotion/Bit.Bmotion/Engine/BmotionCssFormat.cs-17-19 (1)

17-19: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix the precision contract mismatch in Num(double).

Line 17 says “full round-trip precision,” but Line 19 formats with "G6" (lossy). Either change the format to a round-trip one ("R"/"G17") or update the XML summary to match the intended compact formatting.

💡 Minimal fix (doc-aligned)

-    /// <summary>Formats a double as an invariant-culture string with full round-trip precision.</summary>
+    /// <summary>Formats a double as a compact invariant-culture string (6 significant digits).</summary>
     public static string Num(double value)
         => value.ToString("G6", CultureInfo.InvariantCulture);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion/Engine/BmotionCssFormat.cs` around lines 17 - 19, The
`Num(double)` method has a contract mismatch between its XML documentation and
implementation. The documentation states it provides "full round-trip
precision," but the implementation uses `"G6"` format which is lossy and not
full round-trip. Either replace the format string `"G6"` with `"R"` (or `"G17"`)
to achieve actual round-trip precision, or update the XML summary comment to
accurately describe the lossy `"G6"` compact formatting behavior to match the
intended implementation.

src/Bmotion/Bit.Bmotion.Demos/Pages/DragPage.razor (1)

53-54: Use OnDragStart to avoid redundant per-frame status updates during drag.

OnDrag fires continuously while dragging and sets _dragInfo to the same "Dragging…" value each frame, causing unnecessary renders. Move this status update to OnDragStart, which fires only once at drag initiation, keeping OnDragEnd for the "Released" state.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Bmotion/Bit.Bmotion.Demos/Pages/DragPage.razor` around lines 53 - 54, The
OnDrag event handler fires continuously during drag operations, causing
redundant per-frame updates to _dragInfo with the "Dragging…" status and
unnecessary renders. Add an OnDragStart event binding to the component and
create a HandleDragStart method that sets _dragInfo to "Dragging…" once at drag
initiation. Remove or refactor the HandleDrag method to eliminate the redundant
status update, keeping only the necessary drag tracking logic. Keep
HandleDragEnd for setting the "Released" state when the drag completes.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes