docs: deleted old handover

This commit is contained in:
David Kaya
2026-03-22 19:43:53 +01:00
parent 4a229a1f88
commit 6a6fd35361
-209
View File
@@ -1,209 +0,0 @@
# Handover: Copilot version + account context UI
This document is for the frontend/UX agent that will extend the existing Copilot connection UI.
## Goal
Build on top of the current Settings → `AI Provider``Connection` view so it can show:
- whether the installed Copilot CLI is current or outdated
- which GitHub account Copilot is currently using
- organization context when it can be discovered
Do **not** add provider-secret management for this flow. Kopaya still relies on the system-installed GitHub Copilot CLI.
## Backend changes now implemented
### 1. `SidecarCapabilities.connection` has new structured fields
File: `src/shared/contracts/sidecar.ts`
New payload shape:
```ts
connection: {
status: 'ready' | 'copilot-cli-missing' | 'copilot-auth-required' | 'copilot-error';
summary: string;
detail?: string;
copilotCliPath?: string;
checkedAt: string;
copilotCliVersion?: {
status: 'latest' | 'outdated' | 'unknown';
installedVersion?: string;
latestVersion?: string;
detail?: string;
};
account?: {
authenticated: boolean;
login?: string;
host?: string;
authType?: string;
statusMessage?: string;
organizations?: string[];
};
}
```
### 2. Version state is now resolved by the sidecar
Files:
- `sidecar/src/Kopaya.AgentHost/Services/CopilotConnectionMetadataResolver.cs`
- `sidecar/src/Kopaya.AgentHost/Services/SidecarProtocolHost.cs`
The sidecar now runs `copilot version` and classifies the result as:
- `latest`: the CLI explicitly reported that the install is current
- `outdated`: the CLI reported that a newer version is available
- `unknown`: the version command timed out, failed, or did not return a recognizable update state
Important nuance:
- this **does not** change `connection.status`
- `connection.status` still means install/auth/model-list health
- version freshness is a separate concern and should be rendered separately in the UI
### 3. Account context is now resolved by the sidecar
Files:
- `sidecar/src/Kopaya.AgentHost/Services/CopilotConnectionMetadataResolver.cs`
- `sidecar/src/Kopaya.AgentHost/Services/SidecarProtocolHost.cs`
The sidecar now uses the Copilot SDK auth-status call to populate:
- `account.authenticated`
- `account.login`
- `account.host`
- `account.authType`
- `account.statusMessage`
### 4. Organization context is best-effort
When the Copilot auth status provides a login + host, the sidecar also makes a best-effort `gh` CLI lookup for org memberships:
- it verifies the `gh` authenticated user matches the Copilot login on the same host
- if that succeeds, it fetches `user/orgs`
- those org logins are returned as `account.organizations`
Important nuance:
- `organizations` may be missing entirely
- that can mean `gh` is not installed, not authenticated, lacks `read:org`, timed out, or the accounts did not match
- the frontend should treat organizations as optional enhancement data, not a guaranteed field
## Files changed
Backend / shared contracts:
- `src/shared/contracts/sidecar.ts`
- `sidecar/src/Kopaya.AgentHost/Contracts/ProtocolModels.cs`
- `sidecar/src/Kopaya.AgentHost/Services/SidecarProtocolHost.cs`
- `sidecar/src/Kopaya.AgentHost/Services/CopilotConnectionMetadataResolver.cs`
Tests:
- `sidecar/tests/Kopaya.AgentHost.Tests/SidecarProtocolHostTests.cs`
- `sidecar/tests/Kopaya.AgentHost.Tests/CopilotConnectionMetadataResolverTests.cs`
## Validation status
Validated successfully after the change:
- `bun test`
- `dotnet test sidecar\Kopaya.AgentHost.slnx -p:BaseOutputPath="<session-sidecar-build-path>"`
## Current renderer state
There is already a Copilot settings surface:
- `src/renderer/components/SettingsPanel.tsx`
- `src/renderer/components/CopilotStatusCard.tsx`
Current behavior:
- shows connection readiness / missing CLI / auth required / generic error
- shows model count, CLI path, and checked timestamp
- **does not yet render** the new `copilotCliVersion` or `account` fields
## Recommended frontend follow-up
### 1. Show the active GitHub account prominently
Good options:
- a compact identity row like `davidkaya · github.com`
- a small pill/chip under the connection status
- a labeled metadata grid in the expanded details area
Suggested fallback behavior:
- if `account.login` exists, show it
- if `account.host` exists, show it next to the login
- if `account.statusMessage` exists but login is missing, use that as secondary text
### 2. Show CLI freshness as a separate badge/state
Recommended mapping:
- `latest` → subtle positive/neutral badge like `Up to date`
- `outdated` → amber warning badge like `Update available`
- `unknown` → low-emphasis muted label like `Version unknown`
Good details to show in the expanded area:
- installed version
- latest version (when known)
- raw `detail` text only as secondary / technical detail
### 3. Show organizations only when present
If `account.organizations` exists and has values:
- render them as small pills/tags
- cap the visible count if the list is long
- consider `+N more` if there are many
If it is missing:
- do not show an empty placeholder
- fall back to host/account info instead
### 4. Keep account/version separate from the main connection summary
Do **not** overload the existing top-level connection state.
Recommended mental model:
- main status row = “Can Kopaya use Copilot right now?”
- version badge = “Should the CLI be updated?”
- account info = “Who is Kopaya connected as?”
- org pills = “What org context is discoverable?”
## Suggested UI copy
For account:
- `Signed in as davidkaya`
- `github.com`
For version:
- `Copilot CLI is up to date`
- `Copilot CLI update available`
- `Could not determine Copilot CLI version`
For orgs:
- `Organizations`
## Non-goals of this backend change
Still not implemented:
- an in-app `copilot update` action
- an in-app `copilot login` action
- direct provider credentials for OpenAI / Anthropic / Google
- guaranteed authoritative “active organization” selection semantics
The new org data is “best effort discovered context,” not a firm entitlement model.