You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+11-3Lines changed: 11 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -171,6 +171,7 @@ For this app:
171
171
- GitHub is the backlog, not the product: use issues and PRs only to drive task scope and traceability, and never copy GitHub issue text, labels, workflow language, or tracker metadata into production code, runtime snapshots, or user-facing UI
172
172
- never claim an epic is complete until its current GitHub scope is verified against the live issue graph; check which issues are real children versus issues that merely depend on the epic or belong to a different parent epic
173
173
- Desktop responsiveness is a product requirement: avoid synchronous probe, filesystem, network, or process work on UI-facing construction and navigation paths so the app stays fast and immediately reactive
174
+
- Prefer async end-to-end application code: do not introduce new synchronous methods for provider probing, filesystem access, process execution, persistence, startup work, or orchestration flows; expose async `Task`/`ValueTask` APIs instead so the shell never depends on blocking calls
174
175
- Prefer a thin desktop presentation layer over UI-owned orchestration: long-running work, background coordination, and durable session state should live in `DotPilot.Core` services and persistence boundaries, while the Uno UI mainly renders state and forwards operator commands
175
176
- Uno controls and page code-behind must not cast `DataContext` to concrete view-model/model types or invoke orchestration methods directly; route framework events through bindable commands, attached behaviors, dependency properties, or other presentation-safe seams so the view stays decoupled from runtime logic
176
177
- Do not invent a repo-specific product framing such as "workbench" unless the active issue or feature spec explicitly uses it; implement the app features described in the backlog instead of turning internal implementation language into the product narrative
@@ -179,6 +180,12 @@ For this app:
179
180
- When the product creates or configures agents, workflows, or similar runtime assets from operator intent, route that intent through a built-in system agent or equivalent orchestration tool that understands the available providers, tools, and policies instead of scattering that decision logic across UI forms
180
181
- The product must always have a sensible default system agent path: a fresh app state should not leave the operator without an obvious usable agent, and runtime defaults should pick an available provider/model combination or degrade to the deterministic debug agent without blocking the UI
181
182
- 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
183
+
- Starting a chat with an agent must eagerly create both the persisted session row and the backing runtime/provider conversation in one flow; opening chat may not defer the real session start to the first sent message
184
+
- Closing a session must tear down its backing runtime/provider conversation as part of the same Core-owned flow so local providers do not keep orphaned live sessions after the UI removes them
185
+
- Provider, runtime, and model-load failures during send or session startup must surface immediately as operator-visible errors in the chat experience; do not leave the transcript or shell looking like the session is still running after the failure path has already completed
186
+
- Loading overlays and startup spinners must represent active work only; after the first startup hydration attempt finishes, the shell must leave the loading state even if hydration failed, and then surface the failure as normal product state instead of spinning indefinitely
187
+
- Startup hydration must be truly background-only: provider readiness warm-up may run in parallel after launch, but it must not gate shell interactivity behind a modal or full-screen overlay while the background task is still running
188
+
- Long-lived runtime coordination and durable shell/session/provider state should prefer Orleans grain ownership over ad hoc singleton services when that flow is meant to be actor-like, keyed, and independently refreshed; do not keep recreating in-process coordinator objects for concepts the user has already asked to model as Orleans grains
182
189
- 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.
183
190
- 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
184
191
- 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.
@@ -188,9 +195,10 @@ For this app:
188
195
- 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
189
196
- 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
190
197
- 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
191
-
- Do not add cache layers for provider CLIs, model catalogs, workspace projections, or similar environment state unless the user explicitly asks for caching; prefer direct reads from the current source of truth
192
-
- Current repository policy is stricter than the default: do not keep provider-status caches, workspace/session in-memory mirrors, or app-preference caches at all unless the user explicitly asks to bring a specific cache back
193
-
- The current explicit exception is startup readiness hydration: the app may show a splash/loading state at launch, probe installed provider CLIs and related metadata once during that startup window, and then reuse that startup snapshot until an explicit refresh or provider-setting change invalidates it
198
+
- Do not add cache layers for provider CLIs, model catalogs, workspace projections, or similar environment state unless the user explicitly asks for caching; when caching is explicitly requested, keep it scoped, named, and owned by the real runtime source instead of scattering mirrors through the UI
199
+
- Provider CLI initialization is now an explicit caching exception: `DotPilot.Core` should own one startup snapshot/cache for provider readiness and CLI metadata, seed the app from it, and refresh or invalidate it only on explicit operator refresh, provider-setting changes, or the next app start
200
+
- Provider readiness startup work must be a Core-owned startup task fan-out: launch one bounded probe per provider/CLI in parallel, use aggressive timeouts, and degrade fast to cached/partial results instead of serially blocking the shell
201
+
- UI startup must stay thin: page load, view activation, and code-behind must not orchestrate provider probing, hydration, or startup coordination; they may only observe Core-owned startup state and render it
194
202
- Provider CLI probing must not rerun as a side effect of ordinary screen binding or MVUX state re-evaluation; normal shell loads should share one in-flight probe and only reprobe on explicit refresh or provider-setting changes
195
203
- Expected cancellation from state re-evaluation or navigation must not be logged as a product failure; reserve failure logs for real errors, not superseded async loads
196
204
- Runtime and orchestration flows must emit structured `ILogger` logs for provider readiness, agent creation, session creation, send execution, and failure paths; ad hoc console-only startup traces are not enough to debug the product
Copy file name to clipboardExpand all lines: DotPilot.Core/AGENTS.md
+9-4Lines changed: 9 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,8 +26,8 @@ Stack: `.NET 10`, class library, non-UI contracts, orchestration, persistence, a
26
26
- Keep this project free of `Uno Platform`, XAML, brushes, and page/view-model concerns.
27
27
- Keep app-shell, app-host, and application-configuration types out of this project; those belong in `DotPilot`.
28
28
- Do not keep UI-only preference models or shell interaction settings here; if a setting exists only to control presentation behavior such as composer key handling, it belongs in `DotPilot`.
29
-
- Do not add cache-specific abstractions, services, or snapshot layers here by default; `DotPilot.Core` should read from the real source of truth unless the user explicitly asks for a cache boundary.
30
-
-Keep provider readiness, workspace/session projections, and similar environment state uncached by default; do not add in-memory mirrors or snapshot caches unless the user explicitly asks for that tradeoff.
29
+
- Do not add cache-specific abstractions, services, or snapshot layers here by default; when the user explicitly asks for a cache boundary, keep it small, runtime-owned, and tied to one real source of truth instead of creating broad mirror layers.
30
+
-Provider readiness is now an explicit runtime-owned cache boundary: keep one startup snapshot/cache for provider CLI metadata and readiness in `DotPilot.Core`, and invalidate it only on explicit refresh, provider-setting changes, or the next app start.
31
31
- Do not introduce fabricated role enums, hardcoded tool catalogs, skill catalogs, or encoded capability tags for agents unless the product has a real backing registry and runtime implementation for them.
32
32
- Organize code by vertical feature slice, not by shared horizontal folders such as generic `Services` or `Helpers`.
33
33
-`DotPilot.Core` is the default non-UI home, not a permanent dumping ground: when a feature becomes large enough to justify its own architectural boundary, extract it into a dedicated DLL that references `DotPilot.Core`
@@ -44,8 +44,13 @@ Stack: `.NET 10`, class library, non-UI contracts, orchestration, persistence, a
44
44
- operational/system folders such as `AgentBuilder`, `ChatSessions`, `Providers`, and `HttpDiagnostics`
45
45
- 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
46
46
- Keep provider-independent testing seams real and deterministic so CI can validate core flows without external CLIs.
47
-
- 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.
48
-
- 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.
47
+
- Keep provider readiness probing explicit and coalesced: ordinary workspace reads may share one in-flight startup-owned snapshot read, but normal navigation must not fan out into repeated PATH/version probing loops.
48
+
- Provider initialization must be a Core-owned startup task fan-out: probe each provider/CLI in parallel, bound every probe with a timeout, and return partial/cached startup state instead of serially blocking the desktop shell.
49
+
- Keep Core flows async-first: provider, persistence, filesystem, process, and orchestration paths should expose async `Task`/`ValueTask` APIs instead of new synchronous methods so callers do not reintroduce blocking behavior above the Core boundary.
50
+
- Session lifecycle is Core-owned: creating a chat session must eagerly create the provider/runtime conversation, and closing a session must dispose or terminate the backing provider/runtime state instead of leaving teardown to the Uno layer or to eventual process cleanup.
51
+
- Send-time runtime failures must be persisted as explicit session error state before the Core flow returns failure to the shell; do not let provider/model-load exceptions disappear into logs while the transcript still looks active.
52
+
- Startup hydration state must distinguish "still running" from "finished but failed"; Core startup coordinators must not keep the shell blocked in a loading state after the initial attempt has already ended.
53
+
- When startup hydration, provider readiness state, session lifecycle, or similar long-lived runtime coordination is meant to be actor-owned, model it with Orleans grains keyed by the real runtime identity instead of singleton coordinators plus local locks.
49
54
- 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.
50
55
- Treat superseded async loads as cancellation, not failure; Core services should not emit error-level noise for expected state invalidation or navigation churn.
0 commit comments