@mrclrchtr/supi-code-intelligence 6.4.0 → 7.0.0

package/node_modules/@mrclrchtr/supi-lsp/README.md

@@ -22,11 +22,11 @@ npm install @mrclrchtr/supi-lsp
 
 The runtime starts an installed server when the project contains a matching file type and, where configured, a root marker. Some built-in servers use extension-based discovery without a root marker. Built-in command names must be on `PATH`; a configured absolute command path is also supported. This table describes diagnostic support, not the full semantic feature set. A push server can still provide hover, definitions, references, symbols, and refactors.
 
-The table records an initialize-handshake audit performed on 2026-08-21 against the locally installed server versions. The handshake is authoritative and can report a different mode after an upgrade; treat rows marked `unverified` as unknown until a probe confirms them. Pull-capability facts come from the official LSP specification (pull diagnostics are a 3.17 feature; 3.18 is the current specification at microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification).
+The table is a historical initialize-handshake audit performed on 2026-08-21 against the locally installed server versions. It is not a current retest. The TypeScript row also records a separate issue 407 adapter verification on 2026-09-13. That verification did not retest the other server binaries; their audit versions and statuses remain historical. The handshake is authoritative and can report a different mode after an upgrade; treat rows marked `unverified` as unknown until a probe confirms them. Pull-capability facts come from the official LSP specification (pull diagnostics are a 3.17 feature; 3.18 is the current specification at microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification).
 
 | Language | Server binary | Pull diagnostics (probe) | Built-in SuPi mode | Notes |
 |---|---|---|---|---|
-| TypeScript / JavaScript | `typescript-language-server` 5.3.0 | No (confirmed) | Push | No `diagnosticProvider` in the initialize result. |
+| TypeScript / JavaScript | `typescript-language-server` 5.3.0 (audit, 2026-08-21); 6.0.0 (adapter verification, 2026-09-13) | No standard pull in the recorded checks | TypeScript request adapter when eligible; push observation otherwise | The 5.3.0 capability row is historical. The 6.0.0 adapter is described below. |
 | Python | `pyright-langserver` 1.1.411 | Dynamic-only pull (confirmed) | Pull | No static `diagnosticProvider` in the initialize result; registers `textDocument/diagnostic` dynamically after `initialized`. The #320 handshake inspected only the initialize result and missed the registration. |
 | Rust | `rust-analyzer` 0.0.0 (2026-08-10) | No (confirmed) | Push | No `diagnosticProvider` in the initialize result. |
 | Go | `gopls` v0.23.0 | Conditional (confirmed) | Push | Default is push; `initializationOptions.pullDiagnostics: true` makes gopls advertise `diagnosticProvider`. Keep push while golang/go#70199 stays open; initial pull support tracked in golang/go#53275. gopls v0.23.0 pull reports omit the `kind` discriminator (`""`) and `resultId`; SuPi tolerates the empty-kind full report. |
@@ -46,23 +46,43 @@ SuPi advertises static and dynamic pull support. It advertises server-requested
 
 A server gets pull diagnostics when it declares a valid `diagnosticProvider` during initialization. A server also gets pull diagnostics after it registers `textDocument/diagnostic`. The pull support stays active until the server removes the registration. SuPi validates registration parameters. Invalid parameters do not enable pull support. SuPi ignores other registration methods.
 
-When a server sends `workspace/diagnostic/refresh`, SuPi returns `null` immediately. It then refreshes the owning client's tracked documents in the background. The refresh covers open, cached, and failed tracked documents. SuPi does not add workspace-wide `workspace/diagnostic` pulls.
+When a server sends `workspace/diagnostic/refresh`, SuPi returns `null` immediately. It then invalidates diagnostic evidence only and refreshes the owning client's tracked documents in the background. Unchanged open documents keep their input synchronization; SuPi sends no no-op `didChange`, `didClose`, or `didOpen`. It uses native pull or the tested TypeScript request adapter when available. Push-only routes keep partial or unconfirmed evidence. Actual disk changes use the normal document synchronization path. Overlapping refresh requests share one active pass and one newer pending demand; an active diagnostic transport stays owned until it settles. The refresh covers open, cached, and failed tracked documents. SuPi does not add workspace-wide `workspace/diagnostic` pulls.
 
 Protocol support is separate from the configured mode. A server may support pull diagnostics and still use SuPi's push mode because the built-in configuration does not enable pull mode.
 
 The LSP 3.18 specification adds `Diagnostic.message` markup content, guarded by the client capability `textDocument.diagnostic.markupMessageSupport`; SuPi's validator already accepts plaintext and markdown messages but does not advertise the capability. Other 3.18 features (snippet text edits, inline completion, folding-range refresh, multi-range formatting) are outside the diagnostic surface and are not implemented.
 
-Pull diagnostics use `textDocument/diagnostic`, so the client can tie a report to the current request. Push diagnostics are asynchronous and can omit a document version. After a workspace change, SuPi may report push-only diagnostics as partial or unavailable when it cannot prove that the result matches the current document. It does not treat missing fresh evidence as a clean file.
+### Diagnostic evidence policy
 
-Unversioned pushes are accepted for an open document when they arrive after the document's sync moment (the client-side instant the `didChange` or `didOpen` that produced them was sent) and are re-stamped with the current synchronization; unversioned pushes for closed or untracked URIs, and pushes that arrive before a sync moment, stay fail-closed. On push-only routes, the first valid publication for a synchronization is tentative. A later valid publication for the same synchronization confirms it, and every publication restarts the quiet period. If no publication arrives, the existing bounded reopen path may ask the server to publish on `didOpen`; a tentative timeout does not reopen that document. In a mixed batch, silent documents can still use the reopen path. Non-empty tentative diagnostics are visible as partial evidence, but they do not enter the confirmed path. An empty tentative publication cannot establish a clean file and stays unavailable until a diagnostic republish arrives. Repeated unchanged queries share the tentative publication's wait age instead of starting a new full wait. A late republish promotes the cache without a new refresh.
+See [`ADR 0022`](../../docs/adr/0022-request-confirmed-lsp-agnostic-diagnostics.md) for the decision record. SuPi uses one shared diagnostic engine with optional internal request adapters. It selects one source for each file:
 
-Server readiness follows LSP work-done progress: a created progress token is pending and never blocks readiness; an observed `begin` marks active work and makes the client not ready until its `end` or the bounded per-token timeout.
+| Source | Used when | Evidence result |
+|---|---|---|
+| Native LSP pull | A valid static or dynamic `diagnosticProvider` applies to the file. | A validated current report can confirm that file. |
+| TypeScript request | The supported TypeScript route advertises `typescript.tsserverRequest` and the file type matches its configuration. | A complete validated phase collection can confirm that file. |
+| Ambient push | No request source applies, or a request collection fails and a push is available. | Observation only; non-empty data may be partial, but it cannot confirm clean. |
+
+Native pull uses `textDocument/diagnostic`. The client validates full and unchanged reports, carries result IDs, and applies a report only when the document synchronization and evidence revision are current. A valid native provider has priority over the TypeScript adapter when both apply. The adapter is internal and does not change the server's advertised capabilities.
+
+The TypeScript adapter was verified with `typescript-language-server` 6.0.0 and TypeScript 6.0.3. It uses the running server's tsserver through `workspace/executeCommand` and `typescript.tsserverRequest`. It collects `syntacticDiagnosticsSync`, `semanticDiagnosticsSync`, and `suggestionDiagnosticsSync` in order, then validates and combines all three phases. It uses execution target `0` and does not start a second compiler. Conversion validates positions and categories and carries supported tags and related information. A missing, failed, malformed, cancelled, or superseded phase does not establish request evidence.
+
+This adapter applies only when the command is `typescript-language-server`, the route advertises `typescript.tsserverRequest`, and the file suffix matches the route's `fileTypes`. The 6.0.0 verification does not retest other server binaries. Do not infer request support from a language name. Other routes need a valid native pull provider or remain on the ambient push path.
+
+Push diagnostics are asynchronous and may omit a document version. An unversioned push for an open document is accepted only after that document's local sync moment; pushes for closed or untracked URIs, and pushes before that moment, stay fail-closed. This gate blocks some stale messages. It does not confirm diagnostic completion. Every accepted push remains observed or tentative. A document version, publication count, quiet interval, or later republish does not confirm it. Non-empty push diagnostics may be returned as partial evidence. An empty push stays unconfirmed or unavailable. Ambient pushes do not replace request-confirmed cache entries.
+
+A request is file-scoped. A successful TypeScript collection confirms only the requested file and current document generation. It is not a check of every file in a TypeScript program, a workspace, or all language servers. Workspace refresh reports exact tracked-file coverage for `requested`, `confirmed`, `unconfirmed`, `failed`, and `removed` documents. A missing or removed file is reported in that refresh and is not kept in later tracked-file snapshots. A broad `code_health` maintenance pass can refresh active tracked files outside a requested directory; its refresh-attempt evidence is separate from the later diagnostic result scope and coverage. `code_health` keeps these coverage states separate from diagnostic entries.
 
-A workspace diagnostic refresh returns exact coverage counts for requested, confirmed, unconfirmed, failed, and removed tracked documents. `code_health` marks tracked-file diagnostics as complete when each requested document is confirmed or known to be removed. It shows non-empty tentative diagnostics as partial entries, reports the same coverage counts in summary and detailed views, and explains when a diagnostic republish is needed. A refresh attempt does not prove fresh evidence by itself. A removed file is reported by the refresh that finds it and is not retained in later tracked-file snapshots.
+Refresh and file collection share synchronization, evidence-revision, deadline, cancellation, cache, and response-validation rules. Duplicate requests for one route, file, synchronization, and revision share one job. The scheduler runs one request at a time per client route and allows at most 32 pending jobs. Refresh collection is sequential and stops at its shared deadline; unfinished files remain explicit in the coverage counts. The default refresh budget is 3,000 ms and the default push quiet window is 200 ms. The quiet window only ends an observation wait; it cannot confirm diagnostics.
 
-An explicit diagnostic refresh also returns a bounded process-crash report. It gives exact recovered, skipped, failed, and exhausted route counts, up to 16 route entries, and an omitted-entry count. Each entry names the server and workspace-relative root. A skipped route recommends an exact-file refresh; a failed or exhausted route recommends a workspace reload. A failed entry may include only the caught error message, limited to 512 characters. Broad refreshes select only routes whose root overlaps the requested directory and use retained tracked-file paths from the crash snapshot. Exact-file readiness reports only the file's route. Recovery does not cold-start routes, consume an attempt for a skip, or add a second attempt.
+Caller cancellation or deadline stops only that caller's wait. Explicit diagnostic requests use an owned transport lifetime: supersession drops queued jobs and stops future adapter phases but does not cancel an active protocol request. The route stays occupied until actual settlement or connection disposal. The owner timeout attempts protocol cancellation but does not prove that the backend stopped. The owner bound is at least 30 seconds (or a larger collection budget). A result from an obsolete document generation is discarded. Ordinary semantic requests still pass caller cancellation to the protocol transport.
 
-An explicit recovery pass restarts a push-only client only on a protocol-stall signal (a readiness stall, or repeated JSON-RPC request failures) — never on unconfirmed evidence alone, because the reopen-resync fallback recovers unconfirmed documents without discarding warm server state. It never restarts a pull-capable client because push evidence is absent, and it never restarts a client during passive health display. Each client route restarts at most once per workspace invalidation generation. The replacement process has a fixed startup bound of 5 seconds; exceeding the bound fails closed as start-failed without retry. Recovery telemetry records the outcome, elapsed time, attempted clients, restart count, the bounded server names involved, and the stall signal that triggered a restart, without changing the evidence semantics of the result.
+If another request first opens a document during an active semantic or diagnostic request, the client can synchronize and repeat the request once. The retry retains the caller's original signal and deadline. Content, workspace, close, and lifecycle changes still reject stale results. A diagnostic retry collects new request evidence; it does not promote an old cache. This retry is not route recovery. A second enrollment during the retry still rejects the result. Semantic failure reasons state whether the retry failed or was exhausted. The `semantic-request.enrollment-retry` debug event records retry start and outcome with the public call's opaque operation ID, when supplied. A completed RPC alone does not establish accepted semantic evidence.
+
+Diagnostic collection does not close and reopen a document to obtain confirmation. It does not send a no-op `didChange` for that purpose. Refresh retains unchanged documents and their current server state, and resynchronizes changed or invalidated documents. A client restart may reopen tracked documents to restore client state; that is recovery, not diagnostic confirmation.
+
+Server readiness follows LSP work-done progress: a created progress token is pending and never blocks readiness; an observed `begin` marks active work and makes the client not ready until its `end` or the bounded per-token timeout.
+
+An explicit diagnostic refresh retries failed startup and exhausted process-crash routes in scope. It returns separate bounded startup-retry and process-crash reports. Healthy routes are reused, and process readiness is not diagnostic evidence. Recovery keeps the ADR 0020 rule: restart a push-only route only for a protocol-stall signal, not for unconfirmed evidence. A route with native pull or the TypeScript request adapter is not restarted because an ambient push is absent. Passive health display does not restart routes.
 
 ### Optional diagnostic configuration
 
@@ -102,6 +122,8 @@ Set `lsp.exclude` in project or global SuPi configuration:
 
 An exact semantic request can still route an excluded file when a compatible server is available. This does not add the file to automatic work. Configured diagnostic suppression still applies to diagnostic output.
 
+Tsconfig and jsconfig filtering applies only to TypeScript and JavaScript-family files (`.ts`, `.tsx`, `.mts`, `.cts`, `.js`, `.jsx`, `.mjs`, and `.cjs`). Other-language diagnostics are not filtered by a nearby TypeScript or JavaScript project config. Automatic path exclusions and configured diagnostic suppression still apply. A single-file health result omits the `Tsconfig` coverage line for other languages.
+
 ### Custom server configuration
 
 A custom server needs a command and at least one file type:
@@ -166,11 +188,11 @@ Retained and persisted LSP debug events may identify local workspaces, servers,
 - `method` — exact LSP method, e.g. `textDocument/hover`
 - `root` — server root, absolute where present
 
-`runtime.transition` events carry `cwd` and a bounded `servers` array (name, status, ready, and an optional process-crash status reason; at most 16 entries) alongside the aggregate counts. `readiness.*` events carry `cwd`, `server`, and `root`; their messages and data never embed raw progress-token values. `request.timing` events carry the exact `method`, `server`, and `cwd`, plus the JSON-RPC error code: the server-reported code for failed requests, and the defined constant `-32095` (`LSP_REQUEST_TIMEOUT_ERROR_CODE`) for local timeouts; cancellations carry no code. `diagnostics.timing` events carry `cwd`, `server`, and a workspace-relative `file` for `sync-file` operations; `refresh-open` stays aggregate. `runtime.recovery` events carry `cwd`, bounded server and route-root identity, an outcome, and elapsed time for process-crash recovery. Diagnostic recovery events keep their existing bounded attempted/restarted server names. `capability.transition` events fire only on semantic ready↔pending transitions and carry `cwd` and the ready state — never for initialize, registration, or unregistration traffic. Code-intelligence events (`code-operation.*`, `workflow.timing`, `ast-scan.timing`) carry `cwd` only.
+`runtime.transition` events carry `cwd` and a bounded `servers` array (name, status, ready, and an optional process-crash status reason; at most 16 entries) alongside the aggregate counts. `readiness.*` events carry `cwd`, `server`, and `root`; their messages and data never embed raw progress-token values. `request.timing` events carry the exact `method`, `server`, and `cwd`, plus the JSON-RPC error code: the server-reported code for failed requests, and the defined constant `-32095` (`LSP_REQUEST_TIMEOUT_ERROR_CODE`) for local timeouts; cancellations carry no code. `diagnostics.timing` events carry `cwd`, `server`, and a workspace-relative `file` for `sync-file` operations; `refresh-open` stays aggregate. Their `collection` value identifies the source, such as `pull`, `typescript`, `mixed`, or `push`. `diagnostics.publication` keeps bounded publication counts for observation; a count or late publication does not promote confirmation. `runtime.recovery` events carry `cwd`, bounded server and route-root identity, an outcome, and elapsed time for process-crash recovery. Diagnostic recovery events keep their existing bounded attempted/restarted server names. `capability.transition` events fire only on semantic ready↔pending transitions and carry `cwd` and the ready state — never for initialize, registration, or unregistration traffic. Code-intelligence events (`code-operation.*`, `workflow.timing`, `ast-scan.timing`) carry `cwd` only.
 
 `ProjectServerInfo.statusReason` is present only for process-crash recovery states: `process-crashed`, `process-crash-recovery-pending`, or `process-crash-recovery-exhausted`. An LSP route is one configured server and workspace root. A route stays in `error` status for all three states.
 
-Semantic evidence operations recover each required, previously running crashed route and wait for the shared replacement. Scoped workspace-symbol operations select routes by operation support and root intersection; unscoped operations select every known supporting route. Required routes start in parallel. File diagnostics can also recover their route. An explicit broad diagnostic refresh can recover crashed routes that retain tracked files in its scope. Server inventory, workspace readiness, and passive diagnostic snapshots do not start recovery. Recovery never cold-starts a route that did not initialize successfully.
+Semantic evidence operations recover each required, previously running crashed route and wait for the shared replacement. Scoped workspace-symbol operations select routes by operation support and root intersection; unscoped operations select every known supporting route. Required routes start in parallel. File diagnostics can also recover their route. An explicit health refresh can retry failed startup and crashed routes in its scope, including routes without retained files, and can discover configured servers that are now available in Pi's environment. Server inventory, workspace readiness, and passive diagnostic snapshots do not start recovery. A healthy route is reused, and an explicit refresh can restore its automatic process-crash attempt budget after observing readiness. Ordinary semantic and diagnostic requests keep the automatic recovery limit. Recovery never claims diagnostic evidence from process readiness alone.
 
 Identity strings — `cwd`, `server`, `file`, `method`, and `root` — are bounded to 512 UTF-16 code units (marker included; truncation appends `…`) and server lists to 16 entries. No raw protocol dumps, request/response params, diagnostic text, progress tokens, or unbounded file lists are recorded; `openFiles` stays a count. Identity fields are intentionally **not** secret-redacted — the debug registry still redacts secret keys and values, but server names, workspace-relative files, and method names pass through unredacted so local protocol failures stay diagnosable. The supi-debug package documents this disclosure for retained and persisted events.
 
@@ -194,7 +216,7 @@ if (state.kind === "ready") {
 
 Runtime methods use raw 0-based LSP positions. `toLspPosition()` converts user-facing 1-based coordinates. Read-only semantic and diagnostic methods return `CodeQueryResult<T>` so completed empty protocol responses remain distinct from partial or unavailable requests. A ready runtime owner may contain only lazy routes: workspace semantic readiness requires at least one active ready client, while file readiness requires the routed client for that file to start successfully. Empty client sets and failed routes are unavailable, not vacuously ready.
 
-Semantic and explicit diagnostic operations accept optional shared `CodeRequestControl` metadata. The semantic adapter preserves the exact value through `WorkspaceLspRuntime`. The signal maps to LSP protocol cancellation (`$/cancelRequest`) and the absolute deadline bounds every request and readiness wait. The opaque Debug Operation ID reaches sanitized request and diagnostic timing events. Ambient readiness, lifecycle, capability, and push-diagnostic events have no Debug Operation ID.
+Semantic and explicit diagnostic operations accept optional shared `CodeRequestControl` metadata. The semantic adapter preserves the exact value through `WorkspaceLspRuntime`. Semantic requests pass caller cancellation to the LSP transport. Explicit diagnostic requests use the owned transport lifetime described above: caller cancellation or a caller deadline ends only that caller's wait, and supersession does not cancel an active protocol request. The route stays occupied until actual settlement or connection disposal; an owner timeout attempts protocol cancellation but does not prove that the backend stopped. The opaque Debug Operation ID reaches sanitized request and diagnostic timing events. Ambient readiness, lifecycle, capability, and push-diagnostic events have no Debug Operation ID.
 
 ## Startup performance
 
@@ -237,7 +259,7 @@ See [`docs/adr/0016-workspace-lsp-runtime-interface.md`](../../docs/adr/0016-wor
 
 ## Source
 
-- `src/client/` — protocol client, transport, refresh, and requests
+- `src/client/` — protocol client, transport, diagnostic request adapters, refresh, and requests
 - `src/config/` — server configuration and protocol types
 - `src/diagnostics/` — stale diagnostics and workspace sentinels
 - `src/manager/` — package-internal server pool and routing, diagnostic, and recovery mechanics

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-code-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-code-runtime",
-  "version": "6.4.0",
+  "version": "7.0.0",
   "description": "Shared workspace context and capability contracts for code intelligence",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-code-runtime/src/types.ts

@@ -234,7 +234,14 @@ export type CalleeDepth = "direct" | "deep";
  */
 export interface CalleesData {
   enclosingScope: { name: string; startLine: number; endLine: number };
-  callees: Array<{ name: string; startLine: number }>;
+  /** Distinct call sites with 1-based UTF-16 start coordinates. */
+  callees: Array<{
+    name: string;
+    /** Optional syntax-shortened label for presentation; does not replace `name`. */
+    displayName?: string;
+    startLine: number;
+    startCharacter: number;
+  }>;
   depth: CalleeDepth;
 }
 

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-core/README.md

@@ -21,6 +21,7 @@ pnpm add @mrclrchtr/supi-core
 ## Package surfaces
 
 - `@mrclrchtr/supi-core/api` — reusable helpers for other packages and extensions
+- `@mrclrchtr/supi-core/llm` — PI-owned direct model requests and JSON helpers
 - `@mrclrchtr/supi-core/report` — shared text/report rendering helpers for TUI and plain-text summaries
 
 ## What you get from the API
@@ -48,6 +49,13 @@ Config file locations:
 
 - `wrapExtensionContext()` — wrap injected text in SuPi's `<extension-context>` tag
 
+### Model requests
+
+- `completeModelRequest(ctx, model, context, options)` — complete through PI's model registry with stable feature affinity. PI owns auth and endpoint resolution.
+- `callWithJsonResponse()` — retry a registry request, extract JSON, and validate it with TypeBox.
+
+`completeModelRequest()` requires a stable `affinityScope`. It keeps cache retention defaults, does not include prompt content in the affinity ID, and adds OpenCode headers only when the provider or exact model endpoint matches OpenCode. Pass `maxTokens: model.maxTokens` when a caller needs the model's declared output cap without using PI private modules.
+
 ### Shared registries
 
 - context-provider registry for `/supi-context`

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-core",
-  "version": "6.4.0",
+  "version": "7.0.0",
   "description": "Shared settings, configuration, reporting, and session infrastructure",
   "license": "MIT",
   "repository": {

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-core/src/footer-registry.ts

@@ -2,17 +2,24 @@
 //
 // Extensions register pre-styled text chunks with a placement hint
 // ("stats" for the metrics line, "status" for the extension status line).
-// The custom footer in supi-extras (or PI's built-in footer) reads these
-// contributions and renders them alongside the built-in metrics.
+// The custom footer in supi-extras reads these contributions and renders them
+// alongside the built-in metrics. Extensions can use PI's status API as a
+// fallback when the custom footer is not installed.
 
 import { createRegistry } from "./registry-utils.ts";
 
+/** Event emitted when a dynamic footer contribution needs a new render. */
+export const FOOTER_INVALIDATE_EVENT = "supi:footer:invalidate";
+
 /** Where the contribution should appear in the footer. */
 export type FooterPlacement = "stats" | "stats-end" | "status";
 
 /** A single footer contribution registered by an extension. */
 export interface FooterContribution {
-  /** Unique key for this contribution. Re-registering with the same key replaces it. */
+  /**
+   * Unique key for this contribution. Re-registering with the same key replaces it.
+   * A same-key Pi status is treated as this contribution's built-in-footer fallback.
+   */
   key: string;
   /** Which footer line this belongs on. */
   placement: FooterPlacement;

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-core/src/index.ts

@@ -15,6 +15,8 @@ export * from "./debug.ts";
 // biome-ignore lint/performance/noReExportAll: intentional convenience barrel
 export * from "./footer-registry.ts";
 // biome-ignore lint/performance/noReExportAll: intentional convenience barrel
+export * from "./llm.ts";
+// biome-ignore lint/performance/noReExportAll: intentional convenience barrel
 export * from "./model-selection.ts";
 // biome-ignore lint/performance/noReExportAll: intentional convenience barrel
 export * from "./path.ts";

package/node_modules/@mrclrchtr/supi-lsp/node_modules/@mrclrchtr/supi-core/src/llm.ts

@@ -1,12 +1,131 @@
-import { complete } from "@earendil-works/pi-ai/compat";
+import { createHash } from "node:crypto";
+import type {
+  Api,
+  AssistantMessage,
+  Context,
+  Model,
+  ModelsApiStreamOptions,
+  ProviderHeaders,
+} from "@earendil-works/pi-ai";
 import type { ExtensionContext } from "@earendil-works/pi-coding-agent";
 import type { TSchema } from "typebox";
 import { Value } from "typebox/value";
 
 // Shared LLM utilities for SuPi extensions.
 //
-// Provides retry logic, structured LLM call helpers, and other
-// common patterns for extensions that interact with AI models.
+// Provides PI-owned model requests, retry logic, structured LLM call helpers,
+// and other common patterns for extensions that interact with AI models.
+
+const MODEL_REQUEST_NAMESPACE = "supi-direct-model-request-v1";
+
+/**
+ * Options for {@link completeModelRequest}.
+ *
+ * Authentication, provider environment, and session identity stay under PI
+ * control. The feature supplies a stable scope for its prompt stream.
+ */
+export type CompleteModelRequestOptions<TApi extends Api = Api> = Omit<
+  ModelsApiStreamOptions<TApi>,
+  "apiKey" | "env" | "sessionId"
+> & {
+  /** Stable feature scope. Do not include prompt, turn, or retry data. */
+  affinityScope: string;
+  /** PI owns these fields, including for APIs with open-ended option types. */
+  apiKey?: never;
+  env?: never;
+  sessionId?: never;
+};
+
+function createModelRequestAffinityId(
+  sessionId: string,
+  affinityScope: string,
+  model: Model<Api>,
+): string {
+  const material = JSON.stringify([
+    MODEL_REQUEST_NAMESPACE,
+    sessionId,
+    affinityScope,
+    model.provider,
+    model.id,
+  ]);
+  const digest = createHash("sha256").update(material, "utf8").digest("hex");
+  return `supi-${digest.slice(0, 56)}`;
+}
+
+function isOpenCodeModel(model: Model<Api>): boolean {
+  if (model.provider === "opencode" || model.provider === "opencode-go") return true;
+
+  try {
+    return new URL(model.baseUrl).hostname === "opencode.ai";
+  } catch {
+    return false;
+  }
+}
+
+function hasHeader(headers: ProviderHeaders, name: string): boolean {
+  const lowerName = name.toLowerCase();
+  return Object.keys(headers).some((headerName) => headerName.toLowerCase() === lowerName);
+}
+
+function addOpenCodeDefaultHeaders(
+  model: Model<Api>,
+  affinityId: string,
+  headers: ProviderHeaders,
+): ProviderHeaders {
+  if (!isOpenCodeModel(model)) return headers;
+
+  const result = { ...headers };
+  if (!hasHeader(result, "x-opencode-session")) {
+    result["x-opencode-session"] = affinityId;
+  }
+  if (!hasHeader(result, "x-opencode-client")) {
+    result["x-opencode-client"] = "pi";
+  }
+  return result;
+}
+
+/**
+ * Complete a direct request through PI's model registry.
+ *
+ * PI resolves authentication, provider headers, environment, and the
+ * effective endpoint. This helper adds one stable opaque session identity for
+ * the feature prompt stream and applies the OpenCode compatibility defaults.
+ * It does not retry, validate output, or present errors.
+ *
+ * When `maxTokens` is omitted, the underlying registry receives no explicit
+ * output cap. A caller that needs the selected model's declared cap can pass
+ * `maxTokens: model.maxTokens` without importing PI internals.
+ */
+export async function completeModelRequest<TApi extends Api>(
+  ctx: ExtensionContext,
+  model: Model<TApi>,
+  context: Context,
+  options: CompleteModelRequestOptions<TApi>,
+): Promise<AssistantMessage> {
+  const { affinityScope, transformHeaders: callerTransformHeaders, ...requestOptions } = options;
+  const safeRequestOptions = { ...requestOptions };
+  delete safeRequestOptions.apiKey;
+  delete safeRequestOptions.env;
+  delete safeRequestOptions.sessionId;
+
+  const affinityId = createModelRequestAffinityId(
+    ctx.sessionManager.getSessionId(),
+    affinityScope,
+    model,
+  );
+  const transformHeaders = async (headers: ProviderHeaders): Promise<ProviderHeaders> => {
+    const transformed = callerTransformHeaders ? await callerTransformHeaders(headers) : headers;
+    return addOpenCodeDefaultHeaders(model, affinityId, transformed);
+  };
+
+  // Restore PI's conditional provider-option type after removing owned fields.
+  return ctx.modelRegistry.complete(model, context, {
+    ...safeRequestOptions,
+    signal: safeRequestOptions.signal ?? ctx.signal,
+    sessionId: affinityId,
+    transformHeaders,
+  } as unknown as ModelsApiStreamOptions<TApi>);
+}
 
 /**
  * Options for {@link withRetry}.
@@ -122,6 +241,8 @@ export function extractJsonFromResponse<T extends TSchema>(
 export interface CallWithJsonResponseOptions {
   /** The prompt to send to the LLM. */
   prompt: string;
+  /** Stable feature scope for request affinity. Do not include prompt or retry data. */
+  affinityScope: string;
   /** Optional data context appended to the prompt. */
   dataContext?: string;
   /** Maximum tokens for the response. Default: 4096 */
@@ -135,8 +256,9 @@ export interface CallWithJsonResponseOptions {
 /**
  * Call the LLM with a prompt and validate the JSON response against a TypeBox schema.
  *
- * Handles model resolution, auth, retry via `withRetry`, text extraction,
- * JSON regex matching, and TypeBox validation.
+ * Handles model resolution, retry via `withRetry`, text extraction, JSON
+ * matching, and TypeBox validation. The request itself stays under PI
+ * registry authority through {@link completeModelRequest}.
  *
  * Returns `null` when:
  * - No model is available
@@ -145,7 +267,7 @@ export interface CallWithJsonResponseOptions {
  * - JSON doesn't match the schema
  * - The request is aborted
  *
- * @param ctx - The extension context for model resolution and auth.
+ * @param ctx - The extension context for model selection and PI registry access.
  * @param options - Call options including prompt, schema, and retry config.
  * @param schema - TypeBox schema to validate the JSON response against.
  * @returns The parsed and validated result, or `null`.
@@ -155,14 +277,18 @@ export async function callWithJsonResponse<T extends TSchema>(
   options: CallWithJsonResponseOptions,
   schema: T,
 ): Promise<{ parsed: import("typebox").Static<T> } | null> {
-  const { prompt, dataContext, maxTokens = 4096, systemPrompt = "", retries = 2 } = options;
+  const {
+    prompt,
+    affinityScope,
+    dataContext,
+    maxTokens = 4096,
+    systemPrompt = "",
+    retries = 2,
+  } = options;
 
   const model = ctx.model ?? ctx.modelRegistry.getAvailable()[0] ?? null;
   if (!model) return null;
 
-  const auth = await ctx.modelRegistry.getApiKeyAndHeaders(model);
-  if (!auth.ok || !auth.apiKey) return null;
-
   const fullPrompt = dataContext
     ? `${prompt}
 
@@ -171,8 +297,9 @@ ${dataContext}`
     : prompt;
 
   const response = await withRetry(
-    async () => {
-      return complete(
+    async () =>
+      completeModelRequest(
+        ctx,
         model,
         {
           systemPrompt,
@@ -185,13 +312,11 @@ ${dataContext}`
           ],
         },
         {
-          apiKey: auth.apiKey,
-          headers: auth.headers,
+          affinityScope,
           signal: ctx.signal,
           maxTokens,
         },
-      );
-    },
+      ),
     { retries, baseDelayMs: 1000, signal: ctx.signal },
   );
 

package/node_modules/@mrclrchtr/supi-lsp/node_modules/ignore/index.js

@@ -16,7 +16,9 @@ const REGEX_LITERAL_SPECIAL = /[.*+?()[\]{}^$|\\/]/
 // A line of only spaces is blank -- the trailing-space trimming empties it --
 //   but a line holding a tab is a pattern for a tab-named path, since git
 //   never trims a tab.
-const REGEX_TEST_BLANK_LINE = /^ +$/
+// A leading BOM is removed during compilation, so reject a line that would
+//   become empty after removing it and trimming spaces.
+const REGEX_TEST_BLANK_LINE = /^\uFEFF? *$/
 const REGEX_INVALID_TRAILING_BACKSLASH = /(?:[^\\]|^)\\$/
 const REGEX_REPLACE_LEADING_EXCAPED_EXCLAMATION = /^\\!/
 const REGEX_REPLACE_LEADING_EXCAPED_HASH = /^\\#/

package/node_modules/@mrclrchtr/supi-lsp/node_modules/ignore/legacy.js

@@ -29,7 +29,9 @@ var REGEX_LITERAL_SPECIAL = /[.*+?()[\]{}^$|\\/]/;
 // A line of only spaces is blank -- the trailing-space trimming empties it --
 //   but a line holding a tab is a pattern for a tab-named path, since git
 //   never trims a tab.
-var REGEX_TEST_BLANK_LINE = /^ +$/;
+// A leading BOM is removed during compilation, so reject a line that would
+//   become empty after removing it and trimming spaces.
+var REGEX_TEST_BLANK_LINE = /^\uFEFF? *$/;
 var REGEX_INVALID_TRAILING_BACKSLASH = /(?:[^\\]|^)\\$/;
 var REGEX_REPLACE_LEADING_EXCAPED_EXCLAMATION = /^\\!/;
 var REGEX_REPLACE_LEADING_EXCAPED_HASH = /^\\#/;

package/node_modules/@mrclrchtr/supi-lsp/node_modules/ignore/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ignore",
-  "version": "7.0.8",
+  "version": "7.0.9",
   "description": "Ignore is a manager and filter for .gitignore rules, the one used by eslint, gitbook and many others.",
   "types": "index.d.ts",
   "files": [

package/node_modules/@mrclrchtr/supi-lsp/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mrclrchtr/supi-lsp",
-  "version": "6.4.0",
+  "version": "7.0.0",
   "description": "Language Server Protocol runtime for SuPi code intelligence",
   "license": "MIT",
   "repository": {
@@ -37,8 +37,8 @@
     "vscode-jsonrpc": "^9.0.0",
     "vscode-languageserver-protocol": "^3.18.0",
     "vscode-languageserver-types": "^3.18.0",
-    "@mrclrchtr/supi-code-runtime": "6.4.0",
-    "@mrclrchtr/supi-core": "6.4.0"
+    "@mrclrchtr/supi-code-runtime": "7.0.0",
+    "@mrclrchtr/supi-core": "7.0.0"
   },
   "bundledDependencies": [
     "@mrclrchtr/supi-code-runtime",

package/node_modules/@mrclrchtr/supi-lsp/src/api.ts

@@ -12,6 +12,7 @@ export {
   invalidateTsconfigCacheForConfig,
   invalidateTsconfigCacheForConfigDir,
   isProjectConfigFileName,
+  isTsconfigApplicableFile,
   type ScopeDecisionBasis,
 } from "./config/tsconfig-scope.ts";
 export type {
@@ -72,6 +73,10 @@ export type {
   RecoverDiagnosticsResult,
   RoutedMutationResponse,
   SemanticReadinessResult,
+  StartupRetryEntry,
+  StartupRetryNextAction,
+  StartupRetryOutcome,
+  StartupRetryReport,
   WorkspaceDiagnosticReport,
   WorkspaceDiagnosticSnapshot,
   WorkspaceDiagnosticSummaryEntry,
@@ -82,6 +87,7 @@ export type {
 export {
   clearWorkspaceLspRuntime,
   emptyProcessCrashRecoveryReport,
+  emptyStartupRetryReport,
   getWorkspaceLspRuntime,
   MAX_PROCESS_CRASH_RECOVERY_ENTRIES,
   setWorkspaceLspRuntimeState,