# Narrow the plugin to a credential provider for the harness's own Copilot route

DeepSeek Harness ships a `github-copilot` provider through `@deepseek-ai/dsh-llm-pi-ai`, mounted by default via the `dsh-base` bundle. It carries 32 models across three wire formats — including native `anthropic-messages` for Claude — with per-model cost, context windows, and the same request-image pipeline this plugin implements. What it cannot do is sign in: `llm-pi-ai` registers its login flows behind `ctx.inject(['authorization'], …)`, and `AuthorizationService` is an abstract class with no implementation and no bundle mounting it anywhere in the harness. Its login capability currently exists only in unit tests.

This plugin therefore stops being an LLM adapter and becomes the credential provider for that route. It keeps the device flow, its login UI, and its commands; it drops the adapter registration, both wire serializers, the SSE translation, the block stream, the model catalog discovery, the token exchange, and the whole request-image pipeline. The handoff is one credential record: a `grant` at `llm-pi-ai/github-copilot` whose payload is `{ type: 'oauth', refresh: <long-lived GitHub OAuth token> }`. Everything downstream — exchange, refresh, endpoint derivation, model filtering — belongs to pi-ai from that point on.

The handoff was verified end to end before this decision, not assumed. A hand-written record carrying only `refresh` was placed in the real credential file, and `dsh --profile headless` answered a task through the pi-ai route on a profile that does not install this plugin. Reading the file back showed pi-ai had filled in `access`, `expires`, and `availableModelIds` (14, matching the account's picker-enabled models) and persisted them through `credentials.modifyRecord` — so refresh does not need the missing authorization service. The derived endpoint was `proxy.business.githubcopilot.com`, correct for a Business account, despite the catalog declaring the individual endpoint.

The cost is real and accepted. The provider id changes from `github-copilot-official` to `github-copilot`, invalidating stored model references. Enforcement of GitHub's published per-model vision limits (`max_prompt_images`, `max_prompt_image_size`, `supported_media_types`) is lost, since pi-ai's catalog does not carry those fields; this is the only capability measurement showed to be genuinely unique, as the account's model list proved to be a strict subset of pi-ai's catalog and the absent `Copilot-Vision-Request` header proved to have no effect. The compat surface is not eliminated but exchanged: the `@deepseek-ai/dsh-llm` peer dependency disappears — with it the entire class of breakage that forced v0.4.3, v0.4.4, and v0.4.5 — and is replaced by a dependency on pi-ai's grant format and record scope, which is an internal convention carrying no version guarantee. Writes should be read back and exercised once, so a format change fails loudly instead of leaving a broken credential.

This decision has a known expiry. `AuthorizationService` exists as an abstract class, so the harness plainly intends to supply an implementation. When one ships and a bundle mounts it, pi-ai's Copilot route becomes usable without this plugin and the remaining justification narrows to the per-model vision limits alone — likely not enough to keep a parallel plugin alive. Re-open this decision when `rg 'extends AuthorizationService'` over the harness, `grep dsh-authorization` over the bundle patches, or `dsh web --dump-config | grep authorization` produces a hit.

Once implemented, ADR-0001 (request-image overflow policy) describes machinery this plugin no longer contains. It is left in place as the record of why that policy was chosen while the adapter existed.

## Compatibility addendum — `dsh-v0.1.5-rc.1`

The Harness now ships a concrete `AuthorizationService`, and `llm-pi-ai` registers
its provider-native sign-in flows whenever that service is mounted. However,
neither the `dsh-base` nor `dsh-web-app` bundle patch mounts
`@deepseek-ai/dsh-authorization`, so the default Web composition still has no
sign-in surface. This plugin remains necessary for that composition: it runs the
device flow and writes the same `llm-pi-ai/github-copilot` grant record.

The plugin must not register a second authorization flow for that record. In a
composition which explicitly mounts authorization, `llm-pi-ai` owns that flow;
duplicating it would be rejected as `DUPLICATE_FLOW`. Re-open this ADR when a
shipped bundle mounts authorization, not merely when the service package exists.