diff --git a/docs/rules/Moq1100.md b/docs/rules/Moq1100.md
index 51b52041e..efe9c9324 100644
--- a/docs/rules/Moq1100.md
+++ b/docs/rules/Moq1100.md
@@ -108,32 +108,26 @@ mock.Setup(x => x.TryProcess(out It.Ref<int>.IsAny))
     .Returns(true);
 ```
 
-## Known Limitations
+## Coverage Notes
 
 ### Generic Callback Syntax
 
-This analyzer does **not** currently validate type parameter mismatches when using the explicit generic `.Callback<T>()` syntax. For example:
+This analyzer validates type parameter mismatches in both lambda parameter inference and explicit generic `.Callback<T>()` syntax. For example:
 
 ```csharp
-// This will NOT trigger a diagnostic (current limitation)
-mock.Setup(x => x.DoWork("test")) // DoWork takes a string parameter
-    .Callback<int>(wrongTypeParam => { }); // Using int instead of string - no warning!
+// This WILL trigger Moq1100 - type mismatch detected
+mock.Setup(x => x.DoWork("test"))
+    .Callback<int>(wrongTypeParam => { });
 ```
 
-**Best Practice:** Use lambda parameter inference instead of explicit generic syntax to get full validation:
+**Recommended:** Use lambda parameter inference for clarity and readability:
 
 ```csharp
-// ✅ Recommended: Let the compiler infer parameter types
-mock.Setup(x => x.DoWork("test"))
-    .Callback(param => { }); // Type is inferred correctly as string
-
-// ✅ Also recommended: Explicitly type the lambda parameter
+// Preferred style - clear and validated
 mock.Setup(x => x.DoWork("test"))
-    .Callback((string param) => { }); // Type validation works correctly
+    .Callback((string input) => { });
 ```
 
-**Rationale:** The explicit generic `.Callback<T>()` syntax is rarely used in practice. Analysis of open-source Moq usage found zero instances of this pattern. The recommended lambda parameter inference approach provides full type safety and validation coverage.
-
 ## Suppress a warning
 
 If you just want to suppress a single violation, add preprocessor directives to
diff --git a/tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodAnalyzerTests.cs b/tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodAnalyzerTests.cs
index 2dc220835..4005518e7 100644
--- a/tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodAnalyzerTests.cs
+++ b/tests/Moq.Analyzers.Test/CallbackSignatureShouldMatchMockedMethodAnalyzerTests.cs
@@ -218,26 +218,17 @@ public void TestMethod()
     }
 
     /// <summary>
-    /// Test to document the known limitation with generic callback validation.
-    /// This test documents that .Callback&lt;T&gt;() with wrong type parameters is NOT currently validated.
-    /// This is an accepted limitation as the explicit generic syntax is rarely used in practice.
+    /// Verifies that <c>.Callback{T}()</c> with a wrong type parameter produces a diagnostic.
+    /// The analyzer uses symbol-based resolution of the generic type argument to validate the
+    /// callback parameter type. It correctly detects the type mismatch between <c>.Callback{int}()</c>
+    /// and the mocked method parameter type (<c>string</c>).
     /// </summary>
-    /// <remarks>
-    /// <para>
-    /// Analysis shows zero real-world usage of the explicit generic .Callback&lt;T&gt;() syntax in open-source projects.
-    /// The recommended approach is to use lambda parameter inference which provides full type validation:
-    /// <c>.Callback(param => { })</c> or <c>.Callback((string param) => { })</c>.
-    /// </para>
-    /// <para>
-    /// See docs/rules/Moq1100.md "Known Limitations" section for best practices.
-    /// </para>
-    /// </remarks>
     /// <param name="referenceAssemblyGroup">The Moq version reference assembly group.</param>
     /// <returns>A task representing the asynchronous unit test.</returns>
     [Theory]
     [InlineData("Net80WithOldMoq")]
     [InlineData("Net80WithNewMoq")]
-    public async Task GenericCallbackValidation_CurrentLimitation_IsDocumented(string referenceAssemblyGroup)
+    public async Task GenericCallbackWithWrongType_ProducesDiagnostic(string referenceAssemblyGroup)
     {
         const string source = """
             using Moq;
@@ -252,15 +243,14 @@ public class TestClass
                 public void TestGenericCallback()
                 {
                     var mock = new Mock<IFoo>();
-                    // Note: This does NOT trigger a diagnostic (known limitation)
-                    // Best practice: Use .Callback(param => { }) instead of .Callback<T>(param => { })
+                    // .Callback<int>() mismatches the mocked method parameter type (string).
+                    // The analyzer detects this via symbol-based resolution of the generic type argument.
                     mock.Setup(x => x.DoWork("test"))
-                        .Callback<int>(wrongTypeParam => { }); // Generic syntax not validated
+                        .Callback<int>({|Moq1100:wrongTypeParam|} => { });
                 }
             }
             """;
 
-        // This test documents the known limitation - no diagnostic is expected
         await AnalyzerVerifier.VerifyAnalyzerAsync(source, referenceAssemblyGroup);
     }
 }