@namzu/cli 26.2.0 → 27.0.0

package/dist/tui/provider-list.d.ts

@@ -1,19 +1,47 @@
 /**
- * The rows the provider picker lists: what this machine already has, then what
- * it could have if the operator supplied a credential.
+ * The rows the provider picker lists: one per vendor, each saying what this
+ * machine can currently do with it.
  *
- * The second half is the point. The picker used to list only what discovery
- * found, so the one provider an operator had SAVED and held a key for — but had
- * not yet exported as an environment variable — appeared nowhere on a screen
- * that exists to choose a provider. There was no row to select and therefore no
- * way to type its key: a list that showed four providers had no fifth row for
- * the fifth one, and the screen's other exit (a sign-in) is a different kind of
- * credential entirely.
+ * ## One vendor is one row
+ *
+ * The screen used to draw a row per provider id, so one vendor could be two
+ * rows: the session on the device under the subscription's own label, and below
+ * it the same vendor's name asking for the key it did not need. The operator
+ * holding the key had to work out which of the two rows was theirs.
+ *
+ * Rows are grouped by `ProviderRegistryEntry.vendor` — a field on the registry
+ * rather than a table here, because which ids are one vendor is a fact about
+ * the providers and the picker is only the first surface to need it; see
+ * `VENDOR_NAMES` for that field and for which ids are one vendor. A vendor
+ * whose ids reach the same service through different credentials is one row,
+ * which is the shape one entry in this registry has had all along: a single id
+ * taking an API key, a token variable, or a signed-in session. A vendor with
+ * two catalogues keeps two rows, because merging those would put a product
+ * decision inside a screen about credentials.
+ *
+ * ## What a row says, and what it holds
+ *
+ * The second column is what the machine has, not what the ideal setup is: the
+ * source of a session discovery found (`Codex session · this device`), or — when
+ * nothing was found for that vendor — the variable that would set it up
+ * (`needs OPENAI_API_KEY`). The variable is named rather than "not configured"
+ * because it is the one action that both makes the provider work now and keeps
+ * it working after a restart.
+ *
+ * Every way in that this build can offer is below in `paths`, in the order the
+ * screen offers them: what is already detected, then the API key, then — where
+ * nothing works yet — a sign-in the registry declares. A row with ONE way in
+ * leads straight to that way's flow, exactly as it did before this file grouped
+ * anything — Enter on an unconfigured row opens its paste field, Enter on a
+ * detected one opens its models. A row with SEVERAL cannot answer Enter by
+ * itself, so the screen asks how the operator means to use it; that is the only
+ * place this change added a step to, and it is a count of WAYS rather than of
+ * ids — see `rowNeedsChoice` and `vendorPaths`.
  *
  * ## What is added, and what is deliberately not
  *
- * A provider joins the list only when **this build can construct it** and it
- * **takes a credential the operator can type** — the registry's
+ * A vendor joins the list only when **this build can construct something in it**
+ * and it **takes a credential the operator can type** — the registry's
  * `constructible` and `acceptsTypedCredential` flags, read together and read
  * from the registry rather than listed here. Entering a key for anything else
  * produces a row that leads nowhere, which is worse than an absent row:
@@ -22,58 +50,189 @@
  *    region, a session token, or a role the SDK assumes) rather than one
  *    string. A single API-key field cannot express it, so the picker does not
  *    offer it.
- *  - `http` is a generic endpoint whose base URL is half the
- *    credential. A key with nowhere to send it is not a setup.
- *  - `lmstudio` cannot be constructed by this build at all.
- *  - `ollama` needs a local server, not a secret.
- *  - `codex` needs a device-code sign-in, which this screen already offers
- *    with `l` and names on the sign-in screen. It is skipped here so that one
- *    provider is not offered two different ways to be set up.
+ *  - `http` is a generic endpoint whose base URL is half the credential. A key
+ *    with nowhere to send it is not a setup.
+ *  - `lmstudio` cannot be constructed by this build at all. Discovery may still
+ *    find it, and a row for something genuinely on the machine stays on the
+ *    machine's list — it just refuses, with the reason, when accepted.
+ *  - `ollama` needs a local server, not a secret. A running server is how
+ *    discovery finds it, and that is the only way it is listed.
+ *
+ * The sign-in inside a vendor row is not a second way to set that vendor up
+ * beside the first; it is the same path `l` reaches today, offered where the
+ * operator is already looking. Nothing here starts a credential flow of its
+ * own: a path names a provider the rest of the screen already knows how to
+ * handle.
  *
  * `provider-list.test.ts` asserts that exclusion list by NAME, so a registry
  * flag that flips turns the test red instead of silently adding or dropping a
  * row.
  */
-import { type DetectedProvider, type ProviderId, type ProviderRegistryEntry } from '../integrations/providers/index.js';
+import { type DetectedProvider, type ProviderId, type ProviderRegistryEntry, type VendorId } from '../integrations/providers/index.js';
 /**
- * One row of the picker.
+ * One way this build can be set up to use a vendor.
  *
- * The two arms are rendered differently and behave differently on Enter, which
- * is why this is a union rather than a `DetectedProvider` with an optional key:
- * the second arm has no `source`, no `apiKey` and no alternatives, and a type
- * that pretended otherwise would let a caller ask a provider with no credential
- * what models it has.
+ * A union rather than a `ProviderRegistryEntry` with flags, because the three
+ * lead to three different places and carry three different things: a detected
+ * source leads to a model listing that only exists because a credential was
+ * found, a credential leads to the field that takes one, and a sign-in leads to
+ * an operation that is not a value at all. A type that flattened them would let
+ * a caller ask a path that has no credential what models it has.
  */
-export type ProviderListRow = {
+export type VendorPath = 
+/** Something on this machine already works. */
+{
     readonly kind: 'detected';
     readonly detected: DetectedProvider;
-} | {
-    readonly kind: 'unconfigured';
+}
+/** A provider whose credential the operator can type into the paste field. */
+ | {
+    readonly kind: 'credential';
+    readonly entry: ProviderRegistryEntry;
+}
+/** A Namzu-owned sign-in — the operation `l` starts today. */
+ | {
+    readonly kind: 'sign-in';
     readonly entry: ProviderRegistryEntry;
 };
-/** The provider a row is about, whichever kind of row it is. */
-export declare function rowProviderId(row: ProviderListRow): ProviderId;
+/** The provider a path is about, whichever kind of path it is. */
+export declare function pathProviderId(path: VendorPath): ProviderId;
+/**
+ * One row of the picker: a vendor, what this machine has for it, and every way
+ * in this build can offer.
+ *
+ * `detected` is kept beside `paths` rather than folded into it because the two
+ * answer different questions. `paths` is what the row can DO — and a detected
+ * provider this build cannot construct is therefore not a path, since following
+ * it only reaches a refusal — while `detected` is what the machine HAS, which
+ * is what the row's second column reports and what the refusal names. A row
+ * that dropped the second would hide a discovery that genuinely happened.
+ */
+export interface VendorRow {
+    readonly vendor: VendorId;
+    /** What the row is called, from the registry's one name for that vendor. */
+    readonly label: string;
+    /** What this machine has for the vendor, in discovery order. */
+    readonly detected: readonly DetectedProvider[];
+    /** The ways in, in the order the screen offers them. */
+    readonly paths: readonly VendorPath[];
+}
 /**
  * Providers this screen can set up by taking a credential from the operator.
  *
- * Derived from the registry, in registry order. Four of the twelve entries have
+ * Derived from the registry, in registry order. Five of the twelve entries have
  * a driver in this repository and are not listed here, for the reasons in the
- * module comment.
+ * module comment. `codex` is not among them either, and for a different reason:
+ * it takes no typed credential at all, and it is offered instead as the
+ * sign-in path of the vendor row it shares with the key entry beside it.
  */
 export declare function settableProviders(): readonly ProviderRegistryEntry[];
+/**
+ * Every way one vendor can be used, in the order the screen offers them:
+ * what is already detected, then the API key, then — where nothing works yet —
+ * a sign-in the registry declares.
+ *
+ * `entries` is passed rather than looked up so this can be read by a test
+ * against a vendor no registry holds — the shape of the answer is a fact about
+ * the flags, and the alternative is a rule only checkable by editing the
+ * registry.
+ *
+ * ## What counts as a second way in
+ *
+ * Not a second id — a second WAY. One entry can take an API key AND be found as
+ * a signed-in session, and a machine in that state has two genuinely different
+ * ways to use it: keep using the session discovery found, or enter a key of
+ * one's own. The same is true of a vendor whose free catalogue works without a
+ * credential. So the key path is offered beside what was found whenever what was
+ * found is not itself a key — a signed-in session is a different way in, and a
+ * key that discovery already hands over is the same way twice.
+ *
+ * "Is what was found a key?" is asked with the predicate the sign-in screen
+ * already decides it by (`signedInSubscriptionProviders`), rather than a second
+ * opinion written here: an OAuth token in an environment variable is a session
+ * on that screen and must be one here too, or the two screens would disagree
+ * about the same machine.
+ *
+ * ## Why a sign-in is offered only where nothing works yet
+ *
+ * A sign-in is how a vendor with nothing becomes usable. A vendor that is
+ * already usable has no such gap, and the operator who wants a SECOND way in —
+ * a Namzu-owned session beside the key they exported — is asking for something
+ * else: `l` starts one from any screen, and the footer says so. Offering it
+ * here as well would put a question in front of every operator whose key works
+ * and stop them answering it, once per launch, to serve a case that has another
+ * door. The vendor with a signed-in session and no key still shows both, which
+ * is the case this row was reported for.
+ *
+ * `includeUnconfigured` is false on the signed-in-subscription screen, which
+ * offers only sessions that are already usable; an API key path there would
+ * contradict that screen's one sentence.
+ */
+export declare function vendorPaths(entries: readonly ProviderRegistryEntry[], detected: readonly DetectedProvider[], includeUnconfigured: boolean): readonly VendorPath[];
 /**
  * The full list, detected first and in the order discovery produced.
  *
- * Detected rows are passed through untouched: same order, same source text,
- * same numbering. Appending is what keeps that promise — anything that sorted,
- * merged or grouped the two together would move a row the operator has already
- * learned the position of.
+ * A vendor takes the position of the first provider detected for it, so the
+ * detected block keeps discovery's order and one vendor never appears in it
+ * twice. The block below keeps registry order — the order of the entries that
+ * can be set up, which is the order the screen drew those rows in before
+ * anything was grouped.
  *
  * `includeUnconfigured` is false on the signed-in-subscription screen, which
- * offers only sessions that are already usable; a row needing a key contradicts
- * that screen's one sentence.
+ * offers only sessions that are already usable.
+ */
+export declare function providerListRows(detected: readonly DetectedProvider[], includeUnconfigured?: boolean): readonly VendorRow[];
+/**
+ * Whether anything on this row can be used at all.
+ *
+ * False means the row is a discovery this build cannot construct — the one case
+ * where the screen may list something it must then refuse, rather than a row
+ * that needs a credential first.
+ */
+export declare function rowIsUsable(row: VendorRow): boolean;
+/**
+ * Whether entering the row has to ask how the operator means to use it.
+ *
+ * True exactly when the row has more than one way in — by the ways that exist,
+ * and not by how many registry ids they come from. One id can have two ways (a
+ * signed-in session beside an API key) and two ids can share one way, so
+ * counting ids answered the wrong question in both directions: it asked nothing
+ * about a vendor that had a session AND a key to choose between, and it would
+ * have asked twice about two ids that were one and the same key.
+ *
+ * A row with ONE way is not asked. That is the common case and the one the
+ * owner's rule protects: nothing stands between the operator and their model
+ * list when there is nothing to choose, and Enter goes on meaning what it has
+ * always meant — the detected session's models, or the field that takes the
+ * credential this row is missing.
+ */
+export declare function rowNeedsChoice(row: VendorRow): boolean;
+/**
+ * The entry a typed credential would be taken for on this row, if there is one.
+ *
+ * Asked of the whole vendor and not of the row's paths, deliberately: `k` takes
+ * a credential for the provider under the cursor so it can be used for THIS
+ * session, which is meaningful even when that provider is already detected and
+ * therefore has no credential path — a detected vendor is not one whose key the
+ * operator may not replace for the next hour.
+ *
+ * `acceptsTypedCredential` alone, and not `constructible` beside it, because
+ * this is the question `k` has always asked of the highlighted row. A detected
+ * provider this build cannot construct still takes a typed credential, and
+ * answering "it does not" would be false about the provider to make a point
+ * about the build — which is the refusal the row itself gives when it is
+ * accepted, in the words `unsupportedProviderMessage` writes.
+ */
+export declare function typedCredentialEntry(row: VendorRow | undefined): ProviderRegistryEntry | undefined;
+/**
+ * What a row with nothing detected is missing, named as the thing to act on.
+ *
+ * Null for a vendor whose members take no typed credential — a local server, or
+ * a vendor this build cannot construct — because those rows have a source
+ * column that says something else and a sentence here would name a variable
+ * nobody can use.
  */
-export declare function providerListRows(detected: readonly DetectedProvider[], includeUnconfigured?: boolean): readonly ProviderListRow[];
+export declare function rowCredentialNeed(row: VendorRow): string | null;
 /**
  * What an unconfigured row is missing, named as the thing to act on.
  *
@@ -89,6 +248,10 @@ export declare function providerListRows(detected: readonly DetectedProvider[],
  * future entry without one prints a sentence rather than "needs undefined".
  */
 export declare function credentialNeed(entry: ProviderRegistryEntry): string;
+/** Whether a row is about a given provider id — detected there, or a way in. */
+export declare function rowHasProvider(row: VendorRow, id: string): boolean;
+/** The index of the row holding a provider, or -1 when no row does. */
+export declare function rowIndexOfProvider(rows: readonly VendorRow[], id: string | null | undefined): number;
 /**
  * Where the cursor starts.
  *
@@ -100,7 +263,9 @@ export declare function credentialNeed(entry: ProviderRegistryEntry): string;
  * `detected`, so it used to fall through to row 1: the picker opened saying
  * "no credential found" for the saved provider with the cursor elsewhere. Now the
  * highlighted row IS the row that needs the key, which is also the row `k`
- * targets.
+ * targets. Both lookups ask the row, not the vendor: a saved `codex` and a
+ * saved subscription id and a saved key id are the same row, and either one
+ * lands the cursor on it.
  */
-export declare function initialProviderRow(rows: readonly ProviderListRow[], currentProvider: string | null | undefined, keyEntryFor: ProviderId | null | undefined): number;
+export declare function initialProviderRow(rows: readonly VendorRow[], currentProvider: string | null | undefined, keyEntryFor: ProviderId | null | undefined): number;
 //# sourceMappingURL=provider-list.d.ts.map

package/dist/tui/provider-list.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"provider-list.d.ts","sourceRoot":"","sources":["../../src/tui/provider-list.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAmCG;AAEH,OAAO,EAEN,KAAK,gBAAgB,EAErB,KAAK,UAAU,EACf,KAAK,qBAAqB,EAC1B,MAAM,oCAAoC,CAAA;AAE3C;;;;;;;;GAQG;AACH,MAAM,MAAM,eAAe,GACxB;IAAE,QAAQ,CAAC,IAAI,EAAE,UAAU,CAAC;IAAC,QAAQ,CAAC,QAAQ,EAAE,gBAAgB,CAAA;CAAE,GAClE;IAAE,QAAQ,CAAC,IAAI,EAAE,cAAc,CAAC;IAAC,QAAQ,CAAC,KAAK,EAAE,qBAAqB,CAAA;CAAE,CAAA;AAE3E,gEAAgE;AAChE,wBAAgB,aAAa,CAAC,GAAG,EAAE,eAAe,GAAG,UAAU,CAE9D;AAED;;;;;;GAMG;AACH,wBAAgB,iBAAiB,IAAI,SAAS,qBAAqB,EAAE,CAIpE;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,gBAAgB,CAC/B,QAAQ,EAAE,SAAS,gBAAgB,EAAE,EACrC,mBAAmB,UAAO,GACxB,SAAS,eAAe,EAAE,CAY5B;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,cAAc,CAAC,KAAK,EAAE,qBAAqB,GAAG,MAAM,CAInE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,kBAAkB,CACjC,IAAI,EAAE,SAAS,eAAe,EAAE,EAChC,eAAe,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAC1C,WAAW,EAAE,UAAU,GAAG,IAAI,GAAG,SAAS,GACxC,MAAM,CAUR"}
+{"version":3,"file":"provider-list.d.ts","sourceRoot":"","sources":["../../src/tui/provider-list.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAqEG;AAEH,OAAO,EAEN,KAAK,gBAAgB,EAErB,KAAK,UAAU,EACf,KAAK,qBAAqB,EAE1B,KAAK,QAAQ,EAGb,MAAM,oCAAoC,CAAA;AAE3C;;;;;;;;;GASG;AACH,MAAM,MAAM,UAAU;AACrB,+CAA+C;AAC7C;IAAE,QAAQ,CAAC,IAAI,EAAE,UAAU,CAAC;IAAC,QAAQ,CAAC,QAAQ,EAAE,gBAAgB,CAAA;CAAE;AACpE,8EAA8E;GAC5E;IAAE,QAAQ,CAAC,IAAI,EAAE,YAAY,CAAC;IAAC,QAAQ,CAAC,KAAK,EAAE,qBAAqB,CAAA;CAAE;AACxE,8DAA8D;GAC5D;IAAE,QAAQ,CAAC,IAAI,EAAE,SAAS,CAAC;IAAC,QAAQ,CAAC,KAAK,EAAE,qBAAqB,CAAA;CAAE,CAAA;AAEtE,kEAAkE;AAClE,wBAAgB,cAAc,CAAC,IAAI,EAAE,UAAU,GAAG,UAAU,CAE3D;AAED;;;;;;;;;;GAUG;AACH,MAAM,WAAW,SAAS;IACzB,QAAQ,CAAC,MAAM,EAAE,QAAQ,CAAA;IACzB,4EAA4E;IAC5E,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAA;IACtB,gEAAgE;IAChE,QAAQ,CAAC,QAAQ,EAAE,SAAS,gBAAgB,EAAE,CAAA;IAC9C,wDAAwD;IACxD,QAAQ,CAAC,KAAK,EAAE,SAAS,UAAU,EAAE,CAAA;CACrC;AAED;;;;;;;;GAQG;AACH,wBAAgB,iBAAiB,IAAI,SAAS,qBAAqB,EAAE,CAIpE;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,wBAAgB,WAAW,CAC1B,OAAO,EAAE,SAAS,qBAAqB,EAAE,EACzC,QAAQ,EAAE,SAAS,gBAAgB,EAAE,EACrC,mBAAmB,EAAE,OAAO,GAC1B,SAAS,UAAU,EAAE,CA4BvB;AAED;;;;;;;;;;;GAWG;AACH,wBAAgB,gBAAgB,CAC/B,QAAQ,EAAE,SAAS,gBAAgB,EAAE,EACrC,mBAAmB,UAAO,GACxB,SAAS,SAAS,EAAE,CA6BtB;AAED;;;;;;GAMG;AACH,wBAAgB,WAAW,CAAC,GAAG,EAAE,SAAS,GAAG,OAAO,CAEnD;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,cAAc,CAAC,GAAG,EAAE,SAAS,GAAG,OAAO,CAEtD;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,oBAAoB,CACnC,GAAG,EAAE,SAAS,GAAG,SAAS,GACxB,qBAAqB,GAAG,SAAS,CAGnC;AAED;;;;;;;GAOG;AACH,wBAAgB,iBAAiB,CAAC,GAAG,EAAE,SAAS,GAAG,MAAM,GAAG,IAAI,CAG/D;AAED;;;;;;;;;;;;;GAaG;AACH,wBAAgB,cAAc,CAAC,KAAK,EAAE,qBAAqB,GAAG,MAAM,CAInE;AAED,gFAAgF;AAChF,wBAAgB,cAAc,CAAC,GAAG,EAAE,SAAS,EAAE,EAAE,EAAE,MAAM,GAAG,OAAO,CAKlE;AAED,uEAAuE;AACvE,wBAAgB,kBAAkB,CACjC,IAAI,EAAE,SAAS,SAAS,EAAE,EAC1B,EAAE,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GAC3B,MAAM,CAGR;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,kBAAkB,CACjC,IAAI,EAAE,SAAS,SAAS,EAAE,EAC1B,eAAe,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAC1C,WAAW,EAAE,UAAU,GAAG,IAAI,GAAG,SAAS,GACxC,MAAM,CAMR"}