Add ASP.NET Core adversarial fix workflows

[PureWeen]

Add ASP.NET Core adversarial fix workflows

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. This draft adds repository tooling for maintainer review and does not change ASP.NET Core product behavior.

Description

This adds two discoverable Copilot skills for ASP.NET Core fix work:

• fix-challenge reviews an existing PR, issue fix, or local diff and produces one evidence-backed recommendation.
• fix-issue starts from an issue with no existing fix, develops independent candidate mechanisms, and requires candidate-independent red/green proof before recommending a production fix.

Both workflows use a shared, non-discoverable candidate contract under eng/fix-workflows/candidate. This keeps candidate behavior consistent without exposing a third user-facing skill.

For local, stateless, low-risk changes, fix-challenge uses a bounded two-candidate path. Lifecycle, concurrency, compatibility, serialization, interop, security, protocol, performance, and other material risks use a deeper path with adversarial narrowing and focused empirical proof.

Candidate sessions are always read-only. Both workflows are local-only by default. fix-issue permits the final orchestrator to commit, push, or open a PR only when the caller explicitly requests those actions after synthesis and validation. Issue comments or mutations require separate explicit authorization.

Broader goal

The goal is to learn where repository-specific guidance, independent alternatives, better evidence collection, and focused validation can make agents more reliable when reviewing or developing ASP.NET Core fixes. The workflows calibrate effort to risk while preserving disagreement and proof limitations.

See the other ASP.NET Core PRs created by @PureWeen with the agentic-workflows label for related work.

How to use it

Review an existing fix:

/fix-challenge Review dotnet/aspnetcore PR #12345

Develop a fix from an issue:

/fix-issue Fix dotnet/aspnetcore issue #12345 and leave the proposed patch local

Use fix-challenge when a fix or diff already exists. Use fix-issue when starting from a natural issue without exposing candidates to a known solution.

What's included

• Two discoverable workflow skills: fix-challenge and fix-issue
• One shared non-discoverable candidate protocol
• Deterministic evaluation cases, fixtures, and governance metadata
• Portable PowerShell validation and strict Vally specifications

Hosted automation and retained run output are not part of this contribution.

Validation

• Portable deterministic reviewer tests: 9 passed
• Deterministic eval validation: 50 cases, including 13 held-out cases
• Strict Vally 0.13.0 lint: passed for all four specifications
• Skill discovery, runtime staging, model-policy, path, artifact-schema, whitespace, and excluded-content checks: passed

No model or judge calls were rerun for this update.

Current limitations

The checked-in model policy is provisional and publicly anchored to the commit that first published its selection summary. It is based on one trial per model and case and should not be read as population-level evidence that one model is generally better than another. Authoritative runtime-model and cost telemetry were unavailable, so hosted runs remain explicitly non-comparable for model-performance claims.

Procedural candidate isolation with withheld peer outputs is not a filesystem, network, credential, or security boundary.

PRs used during development

#63826, #65578, #66246, #66894, #67589, #68037, #68078, #68081, #68110, #68114, #68116, #68146, #68222, #68254, #68279, #68281, #68317, #68344, #68365, #68453, #68471, #68504, #68540