From 58b05c46e0c84d9d19d35d07182e322ae7ddf070 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Tue, 28 Jul 2026 14:25:03 +0000 Subject: [PATCH 1/2] Initial plan From d98366389efb5b5c2a2725db1e950b9c6e0a9eae Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Tue, 28 Jul 2026 14:30:36 +0000 Subject: [PATCH 2/2] Add Platform crypto-config caution to ci-failure-fix Step 5.2 Co-authored-by: kotlarmilos <11523312+kotlarmilos@users.noreply.github.com> --- .github/workflows/ci-failure-fix.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/workflows/ci-failure-fix.md b/.github/workflows/ci-failure-fix.md index a229fc48424d14..97c34d62e8fd5a 100644 --- a/.github/workflows/ci-failure-fix.md +++ b/.github/workflows/ci-failure-fix.md @@ -208,6 +208,8 @@ Always try to produce a real candidate change first. Read every file you would m **Already-rooted test-assembly caution.** For any failing leg, when the symptom is a type, assembly, or method *missing at run time* (a `FileNotFoundException` for a `*.TestAssembly.dll`, a reflection lookup returning null, a missing logging/DI provider), first inspect the harness and project sources for existing roots and for whether the missing artifact is already present in the app/layout. If the test assembly or member is already rooted, do **not** propose another `[DynamicDependency]`, `.rd.xml`/`ILLink.Descriptors.xml` root, or `TrimmerRootAssembly` — the change is a no-op reviewers will reject. Similarly, if the assembly is already copied into the app bundle/layout, do **not** propose an additional bundle-copy. Only add a root or copy step when source confirms it is missing. Otherwise pin a concrete product-side root cause, or treat it as no-producible-diff and route to Branch COMMENT (Step 5.5). +**Platform crypto-config caution.** When a `System.Security.Cryptography.*` test fails only on a specific distro/OS crypto configuration (AzureLinux/mariner, `linux_musl`, FIPS, or an OpenSSL-provider variant) and the candidate change would hard-code a platform-specific crypto expectation — a key-size floor, algorithm availability, cipher enable/disable, or a per-distro test-expectation change — do **not** open a confident (Branch FIX) PR. The correct behavior depends on the distro's crypto provider configuration, which is a security-area-owner decision, so a guessed expectation change will be rejected. Route to Branch COMMENT (Step 5.5, loop-in), or Branch HELP (Step 5.4) only when you name the specific platform crypto configuration as the explicit open question for a human to confirm. + Once you have a candidate diff, classify it: **Confident (Branch FIX, Step 5.3)** — ALL of: