ns-omp-provider-kiro 0.3.8 → 0.4.0

package/README.md

@@ -17,8 +17,8 @@ To build from a clone instead — for developing this package or
 `ns-kiro-core` before a release — install from the path:
 
 ```bash
-git clone git@github.com:ngosangns/ns-kiro-provider.git
-cd ns-kiro-provider && pnpm install && pnpm -r build
+git clone git@github.com:ngosangns/ns-bridge.git
+cd ns-bridge && pnpm install && pnpm -r build
 omp plugin install ./packages/omp-provider-kiro
 ```
 
@@ -59,4 +59,7 @@ upstream shows up without a release here.
 - `KIRO_DEBUG=1` writes a full request/response trace to
   `~/.ns-kiro-provider/logs/kiro-debug.log`, with credentials redacted.
 
-Part of [ns-kiro-provider](https://github.com/ngosangns/ns-kiro-provider).
+This is the recommended Kiro path in OMP. `ns-omp-provider` can also register a
+`kiro` provider, but leaves it off by default so the two never fight over the id.
+
+Part of [ns-bridge](https://github.com/ngosangns/ns-bridge).

package/dist/auth.d.ts

@@ -1,31 +1,8 @@
 import type { OAuthCredentials, OAuthLoginCallbacks } from "@oh-my-pi/pi-ai";
-/**
- * v0.1 establishes no browser flow of its own. Every interactive method Kiro
- * supports already lands a session in the kiro-cli store or the Kiro IDE token
- * file, so this reads one of those and refreshes it. The one credential with no
- * browser step — an API key — is accepted directly.
- */
+import { type ResolvedKiroRequestCredentials, resolveKiroRequestCredentials } from "ns-kiro-core";
+export type { ResolvedKiroRequestCredentials };
 export declare function loginKiro(callbacks: OAuthLoginCallbacks): Promise<OAuthCredentials>;
 export declare function refreshKiroCredentials(credentials: OAuthCredentials): Promise<OAuthCredentials>;
 export declare function getKiroApiKey(credentials: OAuthCredentials): string;
-/** The token, region, and profile one request runs on. */
-export interface ResolvedKiroRequestCredentials {
-    accessToken: string;
-    region: string;
-    profileArn?: string;
-}
-/**
- * Decide which credential a request or catalog fetch runs on.
- *
- * The key OMP resolves for the provider is the session this package returned
- * from `/login kiro` — but it is also `$KIRO_API_KEY` verbatim when that
- * variable is unset, and Kiro answers a bogus bearer with a 403 the core then
- * has to recover from. So a host key is trusted only when it is recognizably a
- * Kiro credential; anything else defers to the store, which is where the
- * session actually lives.
- *
- * The stored record also carries the region and the profile ARN, and passing
- * the ARN skips the ListAvailableProfiles round trip that a social login cannot
- * answer anyway.
- */
-export declare function resolveRequestCredentials(hostKey: string | undefined): Promise<ResolvedKiroRequestCredentials>;
+/** See {@link resolveKiroRequestCredentials}: which credential one request or catalog fetch runs on. */
+export declare const resolveRequestCredentials: typeof resolveKiroRequestCredentials;