.NET: Mark Magentic Orchestration Experimental

[lokitoth]

Motivation and Context

Magentic Orchestration for .NET is newly implemented and will be undergoing stabilization over the following several weeks. This will communicate this status clearly for the duration, similar to Handoff Orchestration.

Description

Mark Magentic Orchestration [Experimental] for the duration of this process.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• [ ] Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[Copilot]

Pull request overview

This PR aims to communicate the stabilization status of the newly implemented .NET Magentic orchestration by marking its API as experimental, consistent with how Handoff orchestration is currently staged.

Changes:

• Added System.Diagnostics.CodeAnalysis import to enable use of the [Experimental] attribute.
• Marked MagenticWorkflowBuilder with [Experimental(DiagnosticConstants.ExperimentalFeatureDiagnostic)].

[github-actions]

Automated Code Review

Reviewers: 4 | Confidence: 95%

✓ Correctness

The change correctly adds the [Experimental] attribute to MagenticWorkflowBuilder, following the same pattern used for HandoffWorkflowBuilder. The using directive is properly added, and DiagnosticConstants.ExperimentalFeatureDiagnostic is defined as an internal constant in the same assembly (HandoffWorkflowBuilder.cs:19, value "MAAIW001"). No correctness issues found.

✓ Security Reliability

This PR adds the [Experimental] attribute to MagenticWorkflowBuilder, mirroring the existing pattern used for HandoffWorkflowBuilder and other classes. The change is purely a compile-time metadata annotation using the existing DiagnosticConstants.ExperimentalFeatureDiagnostic constant ("MAAIW001") and has no runtime security or reliability implications.

✓ Test Coverage

This PR adds the [Experimental] attribute to MagenticWorkflowBuilder, following the same pattern already used by HandoffWorkflowBuilder and other classes in the project. The change is purely a compile-time diagnostic annotation and does not alter runtime behavior. No tests in the repository verify the presence of [Experimental] attributes on any class (including the already-marked HandoffWorkflowBuilder), so the absence of such a test here is consistent with the established codebase convention. No test coverage concerns are introduced by this change.

✗ Design Approach

The change moves Magentic in the right direction, but it only marks the builder type as experimental. That leaves several other public Magentic-facing types unannotated, so consumers can still depend on the feature's plan-review and event contracts without seeing the experimental diagnostic. Given the PR rationale is to communicate the unstable status clearly, and the repo's handoff rollout marks the full exposed surface instead of just one builder type, I would request a broader annotation pass.

Flagged Issues

• MagenticWorkflowBuilder is now marked experimental, but the rest of the public Magentic surface is still unannotated: MagenticPlanReviewRequest (MagenticPlanReviewRequest.cs:18), MagenticPlanReviewResponse (MagenticPlanReviewResponse.cs:15), MagenticProgressLedger (MagenticProgressLedger.cs:17), and the public Magentic event types (Specialized/Magentic/MagenticOrchestrator.cs:20,28,40,52). Consumers can still use these contracts without any experimental warning, which undercuts the stated goal. The existing handoff rollout shows the broader pattern: it marks both the builder and related types (HandoffWorkflowBuilder.cs:32-41, Specialized/HandoffMessagesFilter.cs:10,20).

---

Automated review by lokitoth's agents