Add parallel-safety audit agentic workflow for MSTest test suites (⚠️ requires lock generation on aligned toolchain)

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Amaury Levé (Evangelink)]

⚠️ BLOCKING — this workflow is INERT until its lock is generated on the aligned CI toolchain

Do not merge expecting /parallel-audit to work yet. gh-aw runs the compiled *.lock.yml, not the markdown source. This PR intentionally ships sources only — no *.lock.yml, and agentic_commands.yml is left at the origin/main baseline — so there is currently nothing for gh-aw to execute. The lock must be generated on the aligned CI toolchain (the github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 step used by agentics-maintenance) and committed before this workflow does anything. Merging as-is ships a green-CI, inert workflow that looks complete. No CI gate enforces lock freshness (checked check-vendored-files.yml), so this caveat is the only guard — treat it as blocking.

Why the lock is not committed here — the local gh aw build corrupts two pinned actions on compile

Compiling with this environment's gh aw v0.83.1 build rewrites two security-relevant pins away from the repo-aligned values. Both are confirmed by regenerating a known-good baseline and full-file-diffing it (the reliable falsification — compiler_version asserts an identity claim, not the emitted bytes):

1. actions/checkout downgraded v7.0.1 → v7.0.0. On framework-injected steps (patch-context / threat-detection / create-PR) the build emits actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 instead of the aligned 3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 ([main] Update checkout and align agentic workflows #10174). .github/aw/actions-lock.json keys its override by version string and holds only an actions/checkout@v7.0.1 entry, so the injected v7.0.0 request key-misses and the CLI's stale built-in SHA wins. 9c091bb appears in 0 of 30 committed baseline locks.
2. github/gh-aw-actions/setup un-pinned from its SHA to a mutable tag. Regenerating the router rewrote the baseline's immutable github/gh-aw-actions/setup@8bdba8075360648fe6802302a5b4e016361dc6ac # v0.83.1 to a bare github/gh-aw-actions/setup@v0.83.1 — a mutable ref, which is a worse supply-chain regression than a version delta (the resolved commit can change under the tag).

Both are legitimate-looking outputs of the toolchain, not hand errors — which is exactly why shipping a locally-generated lock is the wrong move. Editing actions-lock.json can't fix#1 (the injected version label is baked into the binary), and gh extension upgrade aw fails under SAML (HTTP 403), so the local build can't be corrected in place. The correct fix is to generate the lock on the CI-pinned setup action, which self-heals both pins.

Repo-wide hazard (bigger than this PR)

Anyone who runs gh aw compile on any agentic workflow in this repo with this local CLI build will silently (1) downgrade actions/checkout v7.0.1 → v7.0.0 and (2) un-pin github/gh-aw-actions/setup from its SHA to a mutable @v0.83.1 tag in every lock they rewrite — a supply-chain-pin regression that could land unnoticed in an unrelated PR. The mechanism is the version-keyed override in .github/aw/actions-lock.json. One-command reproduction: gh aw compile add-tests --strict then git diff yields exactly the checkout SHA/version lines changed, byte-identical otherwise. Tracked independently of this change in #10258; the durable fix is to compile only on the CI-pinned github/gh-aw-actions/setup@8bdba80… rather than a local build.

---

What this adds

A parallel-safety audit for .NET/MSTest test suites, delivered as a gh-aw agentic workflow: a PR trigger (parallel-safety-audit.md, on test/**) and a /parallel-audit slash command (parallel-safety-audit-command.md), sharing one analysis body (shared/parallel-safety-audit-shared.md).

It answers a question no existing skill or analyzer asks: "will this suite break, or fail to speed up, when run in parallel?" The same call site can be perfectly testable, not a smell, and still race the moment [Parallelize] is enabled.

What it does that the analyzers cannot

Today only MSTEST0073 (PreferConstantForResourceLockAnalyzer) ships on main; the dedicated parallel-safety analyzers MSTEST0074–0077 are in flight (branch dev/amauryleve/parallel-safety-analyzers) and are cited throughout as a forthcoming compile-time complement, not active coverage. Even once they ship, the analyzers see the call; the audit reasons about the resource and the suite's actual configuration:

• Path & key tracing — follows a path/key through helpers, consts, fixture fields and config to decide whether two tests can actually collide, then flags category B only with evidence of colliding I/O ("constructed and then written to"). MSTEST0077 deliberately owns only the narrow direct-literal→mutating-API case after it produced 8/8 false positives on pure-value paths.
• Declaration reconciliation (the unique output) — under-declaration (mutates global state, no [ResourceLock]), over-declaration, ordinal key near-misses ("my-db" vs "my_db", case-only diffs), and read-set coverage gaps followed through the call graph into unchanged production code.
• Over-serialization ranked by speedup arithmetic — findings are ranked by the estimated gain from removing a lock: what the suite reaches today, 1 / (s + (1 - s)/N), against N if the serialized fraction s were eliminated. There is deliberately no cutoff, because the gain grows with worker count — s = 0.02 is worth ~14% at N = 8 but ~60% at N = 32. (An earlier revision used s > 1/N as a break-even test; that is wrong, since it describes when the 1/s ceiling binds rather than whether fixing s pays — at N = 8, s = 0.10 sits below 1/N yet still caps the suite at ~4.7x against a possible 8x.) The class-level-lock finding is gated to MethodLevel, where it actually costs something.
• Scope-aware severity — it reads the assemblies for off / ClassLevel / MethodLevel + worker count rather than assuming the ClassLevel default; a MethodLevel suite has live intra-class races a ClassLevel one does not.
• PR-delta awareness — extracts the HEAD-side changed line ranges so a call site the PR actually touched is a primary finding, while a pre-existing one in the same file is reported only as context (a one-line edit must not light up every legacy method).
• Engine detection — distinguishes an MSTest host from a non-parallel TestContainer host, so it does not cry wolf on code that has no scheduler.

It encodes the culture rule TFM-aware: flag process-wide DefaultThreadCurrent[UI]Culture on every target; on all testfx TFMs (.NET Core 5+/.NET FW ≥4.6) Thread.CurrentThread.Current[UI]Culture and CultureInfo.Current[UI]Culture share ExecutionContext-flowed storage and are not flagged as a live race — the pooled-thread forward-leak only applies on .NET FW <4.6, verified against the suite's actual TFM. Header banner notes that a suite opting in via .runsettings only gets zero analyzer coverage even after 0074–0077 ship (no analyzer reads runsettings XML) — making the audit the sole net there; the MSTestParallelizeScope MSBuild-property opt-in is analyzer-visible because Parallelize.targets emits a real [assembly: Parallelize] via WriteCodeFragment.

Placement

.agents/skills/ is gh-copilot-curate-managed, so a hand-added skill there would be overwritten by gh copilot-curate update. This ships as a repo-local gh-aw workflow instead. The analysis prose in the shared body is written to be portable upstream to a dotnet-test plugin SKILL.md — arguably its best long-term home.

Dogfood — four verdicts on live specimens

Verified against real assembly opt-ins: Microsoft.Testing.Extensions.UnitTests and MSTest.Acceptance.IntegrationTests both carry [assembly: Parallelize(Scope = MethodLevel, Workers = 0)]; TestFramework.UnitTests has no opt-in (TestContainer host).

#	Specimen	Verdict	Fix
1	MSTest.Acceptance.IntegrationTests/TelemetryTests.cs:16	[B/D · Warning · High]	Eliminate, don't lock — all methods write the same bin/Release/<tfm> tree (Path.Combine(AssetFixture.MTPProjectPath,…) at 28/68/94). Give each test a unique output root (TestContext.TestTempDirectory), drop [DoNotParallelize] → full parallelism recovered.
2	Microsoft.Testing.Extensions.UnitTests/AzureFoundryChatClientProviderTests.cs:16	[D · Warning · High]	Correct today, but [DoNotParallelize]defers the class to a serial tail. Swap to [ResourceLock(WellKnownResources.EnvironmentVariables)] — same mutual exclusion on the three AZURE_OPENAI_* vars, no deferral, bounded read-set.

Two non-findings — presented as prominently, because they are the strongest evidence the audit reasons about context:

• TestFramework.UnitTests/…/ExecutableConditionAttributeTests.cs:121 → [A · Info · readiness-only]. Real PATH mutation (lines 121/152) that would race under MSTest MethodLevel — but the suite is TestContainer-based (line 15) with no parallel scheduler, so there is no live race today and the forthcoming MSTEST0074 wouldn't apply either. Not silently dropped: the report states the inapplicability, the exact trigger that would make it live (ported to an MSTest [assembly: Parallelize] project), and the port-time fix (coarse [ResourceLock(EnvironmentVariables)], because the code shells out to child processes that inherit the whole PATH). A naive API scan would flag this identically to Porting latest changes. #2; engine-awareness is the difference.
• Category C: none. The [assembly: Parallelize] / [ResourceLock] occurrences in ParallelExecutionTests/ResourceLockExecutionTests are synthetic test-asset payloads generated inside the acceptance tests, correctly excluded — a naive scan would report the feature's own fixtures as suite findings.

Notes for reviewers

• Generate the lock on the aligned CI toolchain and commit it before treating this workflow as functional — see the blocking section above. Do not compile it locally (that re-introduces both pin corruptions).
• Please do not self-merge; no reviewers added deliberately — accepting the sources-only/blocking-lock posture should be a conscious maintainer call.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com
Copilot-Session: 9081c4a5-25b8-4527-aa8f-db8d6678456f

[Copilot]

Pull request overview

Adds an agentic workflow that audits MSTest suites for parallel-safety.

Changes:

• Adds automatic and /parallel-audit workflows.
• Introduces shared audit logic and generated workflow locks.
• Registers and documents the slash command.

Show a summary per file

File	Description
.github/workflows/shared/parallel-safety-audit-shared.md	Defines extraction, analysis, and reporting logic.
.github/workflows/parallel-safety-audit.md	Configures automatic PR audits.
.github/workflows/parallel-safety-audit.lock.yml	Compiled automatic workflow.
.github/workflows/parallel-safety-audit-command.md	Configures the slash command.
.github/workflows/parallel-safety-audit-command.lock.yml	Compiled command workflow.
.github/workflows/agentic_commands.yml	Registers command routing.
.github/workflows/README.md	Documents the workflows.

Review details

• Files reviewed: 5/7 changed files
• Comments generated: 10
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:277

• This precedence rule conflates runsettings with MSBuild generation. Runsettings override the assembly [Parallelize] workers/scope (TestExecutionManager.Parallelization.cs:135-145), but the MSBuild properties emit another assembly attribute rather than overriding a source attribute, and assembly-level [DoNotParallelize] independently keeps CanParallelizeAssembly false. As written, the auditor can report parallelism as enabled when it is actually off or when declarations conflict.

2. **Which scope?** `[Parallelize]`'s default `Scope` is **`ClassLevel`**, not
`MethodLevel`. Record the effective scope: `off`, `ClassLevel`, or
`MethodLevel`. Runsettings / MSBuild overrides win over the attribute.

.github/workflows/shared/parallel-safety-audit-shared.md:428

• Two tests reading the same stable file are not a filesystem collision. Requiring merely that a constructed path is “read from ... by more than one test” will flag shared read-only fixtures and recommend unnecessary isolation/locking. Require convergent paths with at least one mutating operation (write/delete/move/replace), while treating concurrent readers as safe unless mutation is also possible.

- `Path.Combine(Path.GetTempPath(), <constant>)` and other **path construction**
— the classic collision, *but only if the constructed path is then read from
or written to by more than one test.* Trace the value: if it is only hashed,
compared, returned from a mock, or used as a sentinel that is never opened, it
is **not a finding.** Require evidence of **actual colliding I/O** before

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:282

• An explicit worker count of 1 cannot execute two chunks concurrently: the adapter creates exactly parallelWorkers tasks (TestExecutionManager.Parallelization.cs:216-220). The current severity rules still classify MethodLevel, Workers = 1 conflicts as High/Critical and report over-serialization, producing false live-risk and throughput findings. Treat one worker as readiness-only while retaining the configured scope for context.

3. **Workers.** `[Parallelize(Workers = 0)]` means "one worker per logical
processor"; a positive N pins the count. Record N (or "CPU count") — you
need it for the speedup arithmetic in category D.

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:242

• The delta rule is incorrect when the PR changes scheduling itself. Adding [assembly: Parallelize] or switching to MethodLevel makes unchanged test methods newly concurrent, yet all of their hazards are capped at Info here (and an assembly-attribute-only edit may reach the fallback). Treat a parallelization opt-in/scope change as widening the primary audit surface to the affected assembly; keep this narrow rule for ordinary test edits.

 modified in each changed test file. A finding is a **primary** finding only when
the unsafe call site falls inside one of these ranges (or inside a test method
whose body the PR touched). An unsafe call site that lies **outside** every
changed range is *pre-existing*: report it at most as **context / Info** ("this
file already contains …"), never as though the PR introduced it. A one-line edit
must not light up every legacy method in the file.

.github/workflows/shared/parallel-safety-audit-shared.md:436

• This fix is not valid for every resource listed above. [ResourceLock] coordinates only inside the current test-host process (ResourceLockAttribute.cs:22-24), while registry state is shared across processes; serializing one assembly therefore does not protect concurrent test hosts. Separate process-local state from OS-global resources and recommend per-test resource names, process isolation, an interprocess lock, or removal for the latter.

 MSTEST0076's blanket call with a TFM judgement.
- `Console.SetOut` / `SetError` / `SetIn`; `Console.OutputEncoding` /
`ForegroundColor` / other console state. (The `Console.Set*` writers will also
be covered by **MSTEST0074** when undeclared, once that analyzer ships — see the
analyzer-gate note; it is not on `main` yet.)

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:505

• This entry-point filter excludes changes confined to lifecycle/fixture code or class-level declarations. For example, adding Environment.SetEnvironmentVariable to [TestInitialize], or changing a class-level [ResourceLock], enters the changed-range file but is never audited unless a test body also changed. Start from every changed test-relevant member/declaration, then trace its affected tests.

For each changed test method — either decorated with `[TestMethod]`,
`[DataTestMethod]`, or any attribute deriving from them (testfx has
`[STATestMethod]`, `[UITestMethod]`, `[IterativeTestMethod]`, project-local
`MyTestMethodAttribute : TestMethodAttribute`, etc.), **or**, in a
`TestContainer`-derived class, any public parameterless `void`/`Task` method

.github/workflows/shared/parallel-safety-audit-shared.md:760

• The PR description still says splitting pays only when s > 1/N and that a 2% lock should be ignored, while this corrected logic explicitly rejects that threshold and shows it can matter at higher worker counts. Update the PR description to match the implemented Amdahl-based ranking so reviewers are not promised the opposite behavior.

 `N = 8` but ~60% at `N = 32`. In particular do **not** use `s > 1/N` as a

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (2)

.github/workflows/shared/parallel-safety-audit-shared.md:773

• This formula treats the lock under review as the suite's only serialized work. If other locks, fixture setup, or deferred tests contribute a residual serial fraction, eliminating this lock does not raise speedup to N, so the reported “expected gain” and ranking are overstated. Account for the residual serial fraction, or explicitly label the comparison with N as an upper bound.

- **Rank category D by speedup arithmetic.** Estimate `s`, the fraction of total
suite time the lock serializes, then compare what the suite can reach today,
`1 / (s + (1 - s)/N)`, against `N` if `s` were eliminated. Rank findings by that
**gain** and state it. There is **no fixed cutoff** below which a lock is safe

.github/workflows/shared/parallel-safety-audit-shared.md:807

• Restricting this table to assemblies that have findings leaves a successful no-findings audit with no scope row, even though the rules below require the detected scope to be reported. Include every audited assembly so the report remains scope-aware when the finding count is zero or a configuration change is found safe.

**Parallelization** — one row per test assembly the findings touch (Step 0 resolves this per assembly, so never collapse several projects into one state):

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[Copilot]

Review details

Comments suppressed due to low confidence (1)

.github/workflows/shared/parallel-safety-audit-shared.md:625

• The restoration guidance needs a special case for class-lifetime state. Under MethodLevel, a class-level resource lock is acquired and released for each method chunk (ResourceLockAttribute.cs:40-43), so state set in [ClassInitialize] and restored only in [ClassCleanup] remains exposed between chunks; another test can acquire the same key and observe it. Require per-test restoration, elimination, or non-parallel execution for that pattern.

**A lock alone is only half the fix — it must be paired with restoration.** A
resource lock is released when the scheduling **chunk** ends, so it prevents
*concurrent* interference but does nothing about *sequential* contamination: the

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 3
• Review effort level: Medium

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Medium