A zero is not a measurement until you have run the positive control

Everything below reads public files in dotnet/aspnetcore through the GitHub API. No clone, no build, no credentials beyond a logged-in gh. I ran each of these on 7 Nov 2026 against main. 1. The three rule lists, and the empty one gh api "repos/dotnet/aspnetcore/contents/eng/test-configuration.json?ref=main" \ -H 'Accept: application/vnd.github.raw' Swap ?ref=main for ?ref=release/11.0 to check the shipping branch. Both end the same way: "failOnRules": [ ], "quarantineRules": [ ] } quarantineRules is empty. failOnRules is empty. Count the rules and all 14 are in retryOnRules, with localRerunCount: 3 above them. So every rule in this file weakens a guard by allowing reruns; none of them switches a test off. That distinction is the whole point — a retried test still fails the build when it fails deterministically. Note the Accept: application/vnd.github.raw header. Without it the contents API hands you base64 and you have to pipe through base64 -d, whose flag differs across platforms. The raw header avoids that entirely. 2. Where quarantining actually happens gh api "search/code?q=QuarantinedTestAttribute+repo:dotnet/aspnetcore" --jq '.items[].path' That returns several paths; the definition is src/Testing/src/xunit/QuarantinedTestAttribute.cs. Quarantining in this repo is an attribute on the test, [QuarantinedTest("")], not a config entry. Two mechanisms, one word — which is how censuses end up conflating them. (Treat code-search totals as an index figure, not a count. If you need a number, clone and grep. Everything I assert below comes from a file I fetched and grepped myself.) 3. The claim, and the control that makes it mean something Issue 67517 proposed quarantining UserManagerTest. Check the paperwork first: gh api repos/dotnet/aspnetcore/issues/67517 --jq '{number,title,state}' gh api repos/dotnet/aspnetcore/pulls/67519 --jq '{number,state,merged,merged_at}' The issue is open. The PR is closed with "merged": false and "merged_at": null. So the proposal exists and the change does not. Now measure the source rather than trusting either: gh api "repos/dotnet/aspnetcore/contents/src/Identity/test/Identity.Test/UserManagerTest.cs?ref=main" \ -H 'Accept: application/vnd.github.raw' | grep -ac QuarantinedTest # 0 Do not stop here. A zero proves nothing on its own: a typo'd pattern, a stale path, or a file grep silently skipped all produce the same zero. Run the positive control — same pattern, same pipeline, a file where you know the thing exists: gh api "repos/dotnet/aspnetcore/contents/src/Components/test/E2ETest/Tests/TempDataCookieTest.cs?ref=main" \ -H 'Accept: application/vnd.github.raw' | grep -an QuarantinedTest # 129: [QuarantinedTest("https://github.com/dotnet/aspnetcore/issues/70085")] One hit, through the identical command. Now the zero is a measurement. The test file is unchanged, and grep -ac '\[Fact\]' on it returns 62 still-running facts. The -a is deliberate. grep treats a file containing a single NUL byte as binary and skips it without saying so — you get a zero that looks like an answer. -a forces text mode. Any time you pipe unknown bytes into grep and act on a zero, use it. 4. The same discipline on the Identity side gh api "repos/dotnet/aspnetcore/contents/src/Identity/Extensions.Core/src/Rfc6238AuthenticationService.cs?ref=main" \ -H 'Accept: application/vnd.github.raw' | grep -an 'Mod = \|for (var i = -2\|_timestep' You get const int Mod = 1000000, for (var i = -2; i