some work around

Author: KSemenenko

.github/workflows/release-publish.yml

@@ -241,7 +241,7 @@ jobs:
         shell: bash
         working-directory: ./DotPilot
         run: |
-          dotnet publish DotPilot.csproj \
+          sudo dotnet publish DotPilot.csproj \
             -c Release \
             -f net10.0-desktop \
             -r linux-x64 \
@@ -254,6 +254,8 @@ jobs:
             -p:ApplicationDisplayVersion=${{ needs.prepare_release.outputs.release_version }} \
             -p:ApplicationVersion=${{ needs.prepare_release.outputs.application_version }}
 
+          sudo chown -R "$USER:$USER" ./bin/Release/net10.0-desktop/linux-x64
+
       - name: Stage Linux Release Asset
         shell: bash
         run: |

AGENTS.md

@@ -155,6 +155,7 @@ For this app:
 - architecture work must keep a vertical-slice shape: each feature owns its contracts, orchestration, and tests behind clear boundaries instead of growing a shared horizontal service layer
 - `DotPilot.Core` is the default home for non-UI code, but once a feature becomes large enough to deserve an architectural boundary, extract it into its own DLL instead of bloating `DotPilot.Core`
 - do not create or reintroduce generic project, folder, namespace, or product language named `Runtime` unless the user explicitly asks for that exact boundary; the default non-UI home is `DotPilot.Core`, and vague runtime naming is considered architectural noise in this repo
+- do not create or keep project, folder, or namespace names like `ControlPlaneDomain`; shared identifiers, contracts, models, and policies must live under explicit roots such as `Identifiers`, `Contracts`, `Models`, and `Policies` instead of behind a vague umbrella name
 - every new large feature DLL must reference `DotPilot.Core` for shared abstractions and contracts, and the desktop app should reference that feature DLL explicitly instead of dragging the feature back into the UI project
 - when a feature slice grows beyond a few files, split it into responsibility-based subfolders that mirror the slice's real concerns such as chat, drafting, providers, persistence, settings, or tests; do not leave large flat file dumps that force unrelated code to coexist in one directory
 - do not hide multiple real features under one umbrella folder such as `AgentSessions` when the code actually belongs to distinct features like `Chat`, `AgentBuilder`, `Settings`, `Providers`, or `Workspace`; use explicit feature roots and keep logs, models, services, and tests under the feature that owns them
@@ -180,7 +181,10 @@ For this app:
 - The deterministic debug provider is an internal fallback, not an operator-facing authoring choice: do not surface it as a selectable provider or suggested model in the `New agent` creation flow; if no real provider is enabled or installed, send the operator to provider settings instead of defaulting the form to debug
 - Do not invent agent roles, tool catalogs, skill catalogs, or capability tags in code or UI unless the product has a real backing registry and runtime path for them; absent a real implementation, leave those selections out of the product surface.
 - User-facing UI must not expose backlog numbers, issue labels, workstream labels, "workbench", "domain", or similar internal planning and architecture language unless a feature explicitly exists to show source-control metadata
-- Provider integrations should stay SDK-first: when Codex, Claude Code, GitHub Copilot, or debug/test providers already expose an `IChatClient`-style abstraction, build agent orchestration on top of that instead of inventing parallel request/result wrappers without a clear gap
+- Provider integrations must stay SDK-first: when Codex, Claude Code, GitHub Copilot, or debug/test providers already expose a `Microsoft Agent Framework` or `Microsoft.Extensions.AI` path, compose agent orchestration directly on that official surface instead of inventing parallel request/result abstractions.
+- Do not add or keep provider-specific wrapper chat clients, compatibility shims, or extra adapter layers for `Codex`, `Claude Code`, or `GitHub Copilot`; use the provider SDK and `Microsoft Agent Framework` integration path directly.
+- Do not use `AgentSessionProviderCatalog` or `AgentSessionCommandProbe` as provider-runtime indirection layers; provider registration, readiness, and session creation must come from the actual `Microsoft Agent Framework` plus provider SDK composition path.
+- For `Codex` and `Claude Code`, prefer `ManagedCode.CodexSharpSDK.Extensions.AgentFramework`, `ManagedCode.CodexSharpSDK.Extensions.AI`, `ManagedCode.ClaudeCodeSharpSDK.Extensions.AgentFramework`, and `ManagedCode.ClaudeCodeSharpSDK.Extensions.AI` when those packages are available in the repo, and use them as the primary integration path instead of building repo-local wrappers; remove `AI.Fluent.Assertions` usage instead of layering it beside the Agent Framework path.
 - Do not leave Uno binding on reflection fallback: when the shell binds to view models or option models, annotate or shape those types so the generated metadata provider can resolve them without runtime reflection warnings or performance loss
 - Persist app models and durable session state through `SQLite` plus `EF Core` when the data must survive restarts; do not keep the core chat/session experience trapped in seed data or transient in-memory catalogs
 - When agent conversations must survive restarts, persist the full `AgentSession` plus chat history through an Agent Framework history/storage provider backed by a local desktop folder; do not reduce durable conversation state to transcript text rows only
@@ -407,6 +411,7 @@ Ask first:
 - Keep `dotPilot` positioned as a general agent control plane, not a coding-only shell.
 - Keep the visible product direction aligned with desktop chat apps such as Codex and Claude: sessions first, chat first, streaming first, with repo and git actions as optional utilities inside a session instead of the primary navigation model.
 - Keep provider integrations SDK-first where good typed SDKs already exist.
+- Prefer `ManagedCode` provider SDK bridges for `Codex` and `Claude Code` when they already expose `Microsoft Agent Framework` and `Microsoft.Extensions.AI` integration points, instead of keeping parallel custom adapters or `AI.Fluent.Assertions` glue.
 - Keep evaluation and observability aligned with official Microsoft `.NET` AI guidance when building agent-quality and trust features.
 
 ### Dislikes
@@ -420,5 +425,7 @@ Ask first:
 - Switching desktop Uno pages into stacked or mobile-style responsive layouts during resize work unless the user explicitly asks for a different composition; desktop pages must stay desktop-first and protect geometry through sizing constraints instead.
 - Adding extra UI-test orchestration complexity when the actual goal is simply to run the tests and get an honest pass or fail result.
 - Planning `MLXSharp` into the first product wave before it is ready for real use.
+- Keeping `AI.Fluent.Assertions` in the provider/chat stack after an official `Microsoft Agent Framework` plus `ManagedCode` integration path is available.
+- Reintroducing `AgentSessionProviderCatalog`, `AgentSessionCommandProbe`, or provider-specific wrapper chat clients after the repo has official `Microsoft Agent Framework` plus provider SDK integration packages available.
 - Letting internal implementation labels such as `Workbench`, issue numbers, or architecture slice names leak into the visible product wording or navigation when the app should behave like a clean desktop chat client.
 - Leaving deprecated product slices, pages, view models, or contracts in place "for later cleanup" after the replacement direction is already chosen.

CodeMetricsConfig.txt

@@ -10,19 +10,22 @@
   -->
   <ItemGroup>
     <PackageVersion Include="coverlet.collector" Version="8.0.0" />
-    <PackageVersion Include="FluentAssertions" Version="6.12.0" />
-    <PackageVersion Include="ManagedCode.ClaudeCodeSharpSDK.Extensions.AI" Version="1.0.2" />
+    <PackageVersion Include="ManagedCode.ClaudeCodeSharpSDK.Extensions.AgentFramework" Version="1.1.0-rc4" />
+    <PackageVersion Include="ManagedCode.ClaudeCodeSharpSDK.Extensions.AI" Version="1.1.0" />
+    <PackageVersion Include="ManagedCode.CodexSharpSDK.Extensions.AgentFramework" Version="1.1.0-rc4" />
+    <PackageVersion Include="ManagedCode.CodexSharpSDK.Extensions.AI" Version="1.1.0" />
     <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="18.3.0" />
     <PackageVersion Include="Microsoft.Agents.AI" Version="1.0.0-rc4" />
+    <PackageVersion Include="Microsoft.Agents.AI.GitHub.Copilot" Version="1.0.0-preview.260311.1" />
     <PackageVersion Include="Microsoft.Agents.AI.Workflows" Version="1.0.0-rc4" />
     <PackageVersion Include="Microsoft.Orleans.Server" Version="10.0.1" />
     <PackageVersion Include="NUnit" Version="4.5.1" />
     <PackageVersion Include="NUnit3TestAdapter" Version="6.1.0" />
     <PackageVersion Include="GitHubActionsTestLogger" Version="3.0.1" />
     <PackageVersion Include="GitHub.Copilot.SDK" Version="0.1.32" />
     <PackageVersion Include="ManagedCode.Communication" Version="10.0.1" />
-    <PackageVersion Include="ManagedCode.ClaudeCodeSharpSDK" Version="1.0.2" />
-    <PackageVersion Include="ManagedCode.CodexSharpSDK" Version="1.0.1" />
+    <PackageVersion Include="ManagedCode.ClaudeCodeSharpSDK" Version="1.1.0" />
+    <PackageVersion Include="ManagedCode.CodexSharpSDK" Version="1.1.0" />
     <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="10.0.5" />
     <PackageVersion Include="Microsoft.EntityFrameworkCore.InMemory" Version="10.0.5" />
     <PackageVersion Include="Microsoft.EntityFrameworkCore.Sqlite" Version="10.0.5" />
@@ -31,4 +34,4 @@
     <PackageVersion Include="Uno.UITest.Helpers" Version="1.1.0-dev.70" />
     <PackageVersion Include="Xamarin.UITest" Version="4.3.4" />
   </ItemGroup>
-</Project>
+</Project>

Directory.Packages.props

@@ -13,7 +13,10 @@ Stack: `.NET 10`, class library, non-UI contracts, orchestration, persistence, a
 - `DotPilot.Core.csproj`
 - `AgentBuilder/{Configuration,Models,Services}/*`
 - `ChatSessions/{Commands,Configuration,Contracts,Diagnostics,Execution,Interfaces,Models,Persistence}/*`
-- `ControlPlaneDomain/{Identifiers,Contracts,Models,Policies}/*`
+- `Identifiers/*`
+- `Contracts/*`
+- `Models/*`
+- `Policies/*`
 - `HttpDiagnostics/DebugHttpHandler.cs`
 - `Providers/{Configuration,Infrastructure,Interfaces,Models,Services}/*`
 - `Workspace/{Interfaces,Services}/*`
@@ -33,16 +36,17 @@ Stack: `.NET 10`, class library, non-UI contracts, orchestration, persistence, a
 - do not leave extracted subsystem contracts half-inside `DotPilot.Core`; when a future subsystem is split into its own DLL, its feature-facing interfaces and implementation seams should move with it
 - keep feature-specific heavy infrastructure out of this project once it becomes its own subsystem; `DotPilot.Core` should stay cohesive instead of half-owning an extracted runtime
 - Do not collect unrelated code under an umbrella directory such as `AgentSessions`; split session, workspace, settings, providers, and host code into explicit feature roots when the surface grows.
-- Keep `ControlPlaneDomain` explicit too: identifiers belong under `Identifiers`, participant/provider/session DTOs under `Contracts`, cross-flow state under `Models`, and policy shapes under `Policies` instead of leaving one flat dump.
+- Do not introduce or keep a `ControlPlaneDomain` umbrella in this project; shared identifiers belong under `Identifiers`, participant/provider/session DTOs under `Contracts`, cross-flow state under `Models`, and policy shapes under `Policies`.
 - Keep contract-centric slices explicit inside each feature root: commands live under `Commands`, public DTO shapes live under `Contracts`, public service seams live under `Interfaces`, state records or enums live under `Models`, diagnostics under `Diagnostics`, and persistence under `Persistence`.
 - When a slice exposes `Commands` and `Results`, use the solution-standard `ManagedCode.Communication` primitives instead of hand-rolled command/result record types.
 - Keep the top level readable as two kinds of folders:
-  - shared/domain folders such as `ControlPlaneDomain` and `Workspace`
+  - shared roots such as `Identifiers`, `Contracts`, `Models`, `Policies`, and `Workspace`
   - operational/system folders such as `AgentBuilder`, `ChatSessions`, `Providers`, and `HttpDiagnostics`
 - keep this structure SOLID at the folder and project level too: cohesive feature slices stay together, but once a slice becomes too large or too independent, it should graduate into its own project instead of turning `DotPilot.Core` into mud
 - Keep provider-independent testing seams real and deterministic so CI can validate core flows without external CLIs.
 - Keep provider readiness probing explicit and coalesced: ordinary workspace reads may share one in-flight CLI probe, but normal navigation must not fan out into repeated PATH/version probing loops.
 - The approved caching exception in this project is startup readiness hydration: Core may keep one startup-owned provider/CLI snapshot after the initial splash-time probe, but it must invalidate that snapshot on explicit refresh or provider preference changes instead of drifting into a long-lived opaque cache layer.
+- Do not introduce or keep `AgentSessionProviderCatalog`, `AgentSessionCommandProbe`, or provider-specific wrapper chat clients in this project; provider session creation and readiness must compose directly from `Microsoft Agent Framework` plus the provider SDK extension packages.
 - Treat superseded async loads as cancellation, not failure; Core services should not emit error-level noise for expected state invalidation or navigation churn.
 
 ## Local Commands

DotPilot.Core/AGENTS.md

@@ -25,7 +25,7 @@ public static bool IsSystemAgent(string agentName)
 
     public static string GetDefaultModel(AgentProviderKind kind)
     {
-        return AgentSessionProviderCatalog.Get(kind).DefaultModelName;
+        return kind.GetDefaultModelName();
     }
 
     public static string CreateAgentDescription(string systemPrompt)

DotPilot.Core/AgentBuilder/Configuration/AgentSessionDefaults.cs

@@ -1,4 +1,3 @@
-using DotPilot.Core.ControlPlaneDomain;
 using ManagedCode.Communication.Commands;
 
 namespace DotPilot.Core.ChatSessions.Commands;

DotPilot.Core/ChatSessions/Commands/CreateSessionCommand.cs

@@ -1,5 +1,4 @@
 using System.Globalization;
-using DotPilot.Core.ControlPlaneDomain;
 using ManagedCode.Communication.Commands;
 
 namespace DotPilot.Core.ChatSessions.Commands;

DotPilot.Core/ChatSessions/Commands/SendSessionMessageCommand.cs

@@ -1,4 +1,3 @@
-using DotPilot.Core.ControlPlaneDomain;
 using ManagedCode.Communication.Commands;
 
 namespace DotPilot.Core.ChatSessions.Commands;

DotPilot.Core/ChatSessions/Commands/UpdateAgentProfileCommand.cs

@@ -17,7 +17,6 @@ public static IServiceCollection AddAgentSessions(
         services.AddDbContextFactory<LocalAgentSessionDbContext>(ConfigureDbContext);
         services.AddSingleton<LocalAgentSessionStateStore>();
         services.AddSingleton<LocalAgentChatHistoryStore>();
-        services.AddSingleton<LocalCodexThreadStateStore>();
         services.AddSingleton<IAgentProviderStatusReader, AgentProviderStatusReader>();
         services.AddSingleton<AgentPromptDraftGenerator>();
         services.AddSingleton<AgentExecutionLoggingMiddleware>();