@evandu/super-pi 0.1.124 → 0.1.126

package/dist/client/index.html

@@ -8,8 +8,8 @@
     <link rel="alternate icon" href="/favicon.ico" />
     <link rel="apple-touch-icon" href="/favicon.svg" />
     <title>Super Pi</title>
-    <script type="module" crossorigin src="/assets/index-LL00oFAG.js"></script>
-    <link rel="stylesheet" crossorigin href="/assets/index-4kjGwKOr.css">
+    <script type="module" crossorigin src="/assets/index-Dp0610g1.js"></script>
+    <link rel="stylesheet" crossorigin href="/assets/index-09I_ABgJ.css">
   </head>
   <body>
     <div id="root"></div>

package/dist/server/application/provider-service.d.ts

@@ -56,6 +56,20 @@ export declare class ProviderService {
      */
     disable(providerId: string): Promise<PublicProvider[]>;
     enable(providerId: string): Promise<PublicProvider[]>;
+    /**
+     * Repairs Pi's model configuration: the empty fields Pi's schema refuses are dropped, and nothing
+     * else in the file is touched.
+     *
+     * WHY IT IS WORTH A BUTTON. Pi validates the WHOLE `models.json`, so one entry with an empty
+     * `baseUrl` takes every custom provider out of every picker - and nothing on screen says so,
+     * because the settings panel reads the file leniently and lists them as if they worked. The repair
+     * restores the file Pi will accept, which is the difference between "my provider is gone" and
+     * "your file had an empty field".
+     */
+    repair(): Promise<{
+        fixed: string[];
+        providers: PublicProvider[];
+    }>;
     /**
      * Adds a provider, or adds a model to one, or updates one.
      *

package/dist/server/application/provider-service.js

@@ -135,6 +135,22 @@ export class ProviderService {
         await this.afterChange();
         return this.list();
     }
+    /**
+     * Repairs Pi's model configuration: the empty fields Pi's schema refuses are dropped, and nothing
+     * else in the file is touched.
+     *
+     * WHY IT IS WORTH A BUTTON. Pi validates the WHOLE `models.json`, so one entry with an empty
+     * `baseUrl` takes every custom provider out of every picker - and nothing on screen says so,
+     * because the settings panel reads the file leniently and lists them as if they worked. The repair
+     * restores the file Pi will accept, which is the difference between "my provider is gone" and
+     * "your file had an empty field".
+     */
+    async repair() {
+        const result = await this.registry.repairModelsConfig();
+        if (result.changed)
+            await this.afterChange();
+        return { fixed: result.fixed, providers: await this.list() };
+    }
     /**
      * Adds a provider, or adds a model to one, or updates one.
      *

package/dist/server/command-handler.js

@@ -122,6 +122,12 @@ export class CommandHandler {
             await this.providerService.enable(command.providerId);
             return;
         }
+        if (command.type === "providers.repair") {
+            if (!this.providerService)
+                throw new Error("供应商功能不可用");
+            await this.providerService.repair();
+            return;
+        }
         if (command.type === "providers.fetch") {
             if (!this.providerService)
                 throw new Error("供应商功能不可用");

package/dist/server/pi-session.d.ts

@@ -77,6 +77,15 @@ export interface SdkCatalog {
         provider: string;
         modelId: string;
     }): Promise<string[] | undefined>;
+    /**
+     * WHAT PI SAYS IS WRONG WITH ITS OWN MODEL CONFIGURATION, verbatim.
+     *
+     * Pi validates the WHOLE `models.json` against a schema, and one entry it refuses takes every
+     * custom provider out of every picker - while a lenient reader of the same file still lists them
+     * all. Pi's own words are the only ones that name the offending field, so they are what the
+     * settings panel shows instead of a guess.
+     */
+    configError(): string | undefined;
 }
 /**
  * Builds a zero-process catalog reader.

package/dist/server/pi-session.js

@@ -89,6 +89,7 @@ export async function createSdkCatalog(cwd) {
     const levelsByModel = new Map();
     return {
         models,
+        configError: () => modelRuntime.getError?.(),
         ...(settingsManager.getDefaultProvider?.() && settingsManager.getDefaultModel?.()
             ? {
                 defaultModel: {

package/dist/server/providers.d.ts

@@ -65,14 +65,29 @@ export type ProviderDefinition = {
     hasAuthKey?: boolean;
     models: ProviderModelDefinition[];
     /**
-     * TRUE when the provider is one of PI'S OWN - a built-in such as `kimi-coding` - rather than one
-     * written into `models.json`.
+     * The fields in this provider's `models.json` entry that Pi's own schema refuses - today, an
+     * empty string where Pi asks for at least one character.
      *
-     * WHY THE PANEL CARES. A built-in provider has no entry in `models.json` to edit: its models live
-     * in Pi's own catalogue and the only thing a person has configured for it is the CREDENTIAL in
-     * `auth.json`. So a built-in can be turned off (the credential goes) but it has no address and no
-     * model list of its own to show, and saying so is the difference between a panel that describes
-     * reality and one that pretends a built-in is a custom provider with an empty address.
+     * WHY THE PANEL CARES. Pi validates the WHOLE file, so one bad entry takes every custom
+     * provider out of every picker, while this panel - which reads the file leniently - still lists
+     * them all. Naming the field is what turns "my provider is gone" into "your file has an empty
+     * baseUrl".
+     */
+    invalidFields?: string[];
+    /**
+     * The key is written into `models.json` itself rather than into `auth.json`.
+     *
+     * Pi's own documentation leads with it (`"apiKey": "$MY_KEY"`), and it is the only way to point a
+     * provider at a key that lives in the environment. It matters here because such a provider IS
+     * offered by Pi when the variable is set - so the panel must not tell the person it has no
+     * credential, and must not warn that Pi will not offer it.
+     */
+    keyInModelsJson?: boolean;
+    /**
+     * TRUE when the provider is one of Pi's own, with no entry in `models.json`.
+     *
+     * Its models come from Pi itself and the only thing a person has configured for it is the
+     * credential, so it can be switched off but has no address to edit.
      */
     builtin?: boolean;
     /**
@@ -222,6 +237,23 @@ export declare class ProviderRegistry {
     removeCredential(providerId: string): Promise<void>;
     /** Forgets a disabled provider without restoring anything: the permanent form of "off". */
     forgetDisabled(providerId: string): Promise<void>;
+    /**
+     * Removes the empty fields Pi's schema refuses, so the file is accepted again.
+     *
+     * WHY THIS IS A REPAIR AND NOT A DELETE. An empty `baseUrl` is not a provider with no address -
+     * it is a value Pi refuses, and Pi refuses the WHOLE FILE when it sees one. The fix is to drop
+     * the empty field (leaving the provider exactly as it was otherwise), NOT to remove the provider:
+     * the person wrote it, and an override-only entry - one that only adds models to a built-in - has
+     * no address at all, which is legal as long as the field is ABSENT rather than empty.
+     *
+     * NOTHING ELSE IN THE FILE IS TOUCHED. The entries are read as raw JSON and written back with
+     * only the offending fields removed, so a comment-free copy of a hand-written file stays a
+     * hand-written file.
+     */
+    repairModelsConfig(): Promise<{
+        fixed: string[];
+        changed: boolean;
+    }>;
     /** Writes the registry. The key lives here, so the file is 0600. */
     save(providers: ProviderDefinition[]): Promise<void>;
     /**

package/dist/server/providers.js

@@ -167,6 +167,21 @@ async function writeJsonAtomic(path, value) {
         throw error;
     }
 }
+/**
+ * The fields of a `models.json` provider entry that Pi's schema refuses.
+ *
+ * PI'S RULE, NOT OURS: `baseUrl`, `name` and `api` are optional, but when they are present they
+ * need at least one character. An empty string is not "absent" - it is a value Pi rejects, and Pi
+ * rejects the WHOLE FILE when it finds one, which is why one bad entry can empty every picker.
+ */
+function invalidModelFields(entry) {
+    const fields = [];
+    for (const field of ["name", "baseUrl", "api"]) {
+        if (entry[field] === "")
+            fields.push(field);
+    }
+    return fields;
+}
 /**
  * The provider entry Super Pi writes into Pi's `models.json`, MERGED into what was already there.
  *
@@ -200,7 +215,10 @@ function toPiProvider(provider, existing) {
         return {
             ...priorModel,
             id: model.id,
-            name: model.name ?? model.id,
+            // NEVER AN EMPTY STRING. Pi's schema asks for at least one character, and one empty name
+            // invalidates the WHOLE models.json - which takes every custom provider out of every picker
+            // with nothing but "must not have fewer than 1 characters" to explain it.
+            name: model.name || model.id,
             reasoning: model.reasoning ?? false,
             input: model.imageInput ? ["text", "image"] : ["text"],
             contextWindow: model.contextWindow ?? DEFAULT_CONTEXT_WINDOW,
@@ -320,6 +338,17 @@ export class ProviderRegistry {
                 // this file, and reporting "no key" for a provider Pi is happily using is a lie the panel
                 // would then show next to a working model.
                 hasAuthKey: Boolean(piAuth[pId] || backup?.apiKey),
+                // A KEY WRITTEN IN models.json IS A CREDENTIAL TOO, and it is the one Pi's own docs lead
+                // with (`"apiKey": "$MY_KEY"`). Without this, such a provider is reported as having no
+                // credential - and the panel then says "Pi will not offer it", which is wrong exactly when
+                // the environment variable is set and Pi is offering it right now.
+                ...(typeof rec.apiKey === "string" && rec.apiKey ? { keyInModelsJson: true } : {}),
+                // THE FIELDS PI WILL REFUSE. Pi validates the WHOLE models.json against a schema where an
+                // empty string is not a value ("must not have fewer than 1 characters"), and one bad entry
+                // invalidates the file - which takes EVERY custom provider out of every picker while this
+                // panel, which reads the file leniently, still lists them all. Naming the offending fields
+                // is what turns "my provider vanished" into "your file has an empty baseUrl".
+                ...(invalidModelFields(rec).length ? { invalidFields: invalidModelFields(rec) } : {}),
                 models,
             });
         }
@@ -480,6 +509,63 @@ export class ProviderRegistry {
             throw new Error(`供应商「${providerId}」没有被停用`);
         await this.writeRegistry({ disabled: next });
     }
+    /**
+     * Removes the empty fields Pi's schema refuses, so the file is accepted again.
+     *
+     * WHY THIS IS A REPAIR AND NOT A DELETE. An empty `baseUrl` is not a provider with no address -
+     * it is a value Pi refuses, and Pi refuses the WHOLE FILE when it sees one. The fix is to drop
+     * the empty field (leaving the provider exactly as it was otherwise), NOT to remove the provider:
+     * the person wrote it, and an override-only entry - one that only adds models to a built-in - has
+     * no address at all, which is legal as long as the field is ABSENT rather than empty.
+     *
+     * NOTHING ELSE IN THE FILE IS TOUCHED. The entries are read as raw JSON and written back with
+     * only the offending fields removed, so a comment-free copy of a hand-written file stays a
+     * hand-written file.
+     */
+    async repairModelsConfig() {
+        const modelsPath = piModelsPath(this.piDir);
+        const raw = (await readJsonFile(modelsPath));
+        if (!raw || !raw.providers || typeof raw.providers !== "object")
+            return { fixed: [], changed: false };
+        const fixed = [];
+        let changed = false;
+        const providers = { ...raw.providers };
+        for (const [providerId, value] of Object.entries(providers)) {
+            if (!value || typeof value !== "object" || Array.isArray(value))
+                continue;
+            const entry = { ...value };
+            let touched = false;
+            for (const field of invalidModelFields(entry)) {
+                delete entry[field];
+                fixed.push(`${providerId}.${field}`);
+                touched = true;
+            }
+            if (Array.isArray(entry.models)) {
+                let modelsTouched = false;
+                const models = entry.models.map((model) => {
+                    if (!model || typeof model !== "object" || Array.isArray(model))
+                        return model;
+                    const record = { ...model };
+                    if (record.name === "") {
+                        delete record.name;
+                        fixed.push(`${providerId}.models.name`);
+                        modelsTouched = true;
+                    }
+                    return record;
+                });
+                if (modelsTouched)
+                    entry.models = models;
+                touched = touched || modelsTouched;
+            }
+            if (touched) {
+                providers[providerId] = entry;
+                changed = true;
+            }
+        }
+        if (changed)
+            await writeJsonAtomic(modelsPath, { ...raw, providers });
+        return { fixed, changed };
+    }
     /** Writes the registry. The key lives here, so the file is 0600. */
     async save(providers) {
         await this.writeRegistry({ providers });
@@ -535,6 +621,8 @@ export function publicProviders(providers) {
         baseUrl: provider.baseUrl,
         api: provider.api,
         hasKey: Boolean(provider.apiKey || provider.hasAuthKey),
+        ...(provider.keyInModelsJson ? { keyInModelsJson: true } : {}),
+        ...(provider.invalidFields?.length ? { invalidFields: [...provider.invalidFields] } : {}),
         ...(provider.builtin ? { builtin: true } : {}),
         ...(provider.disabled ? { disabled: true } : {}),
         models: provider.models.map(model => ({

package/dist/server/runtime.js

@@ -2445,6 +2445,11 @@ export class PiRpcRuntime {
                 source: "pi",
                 models,
                 levels: levelNames,
+                // PI'S OWN VERDICT ON ITS OWN CONFIGURATION. It belongs on the catalog because the catalog is
+                // what the picker shows, and a picker that is missing a provider without saying why is the
+                // hardest kind of missing: Pi rejects a whole models.json over one bad field, so EVERY
+                // custom provider disappears at once and the only explanation is somewhere else entirely.
+                ...(reader.configError?.() ? { configError: reader.configError() } : {}),
                 defaultModel: pick(reader.defaultModel ? describeModel({ provider: reader.defaultModel.provider, id: reader.defaultModel.modelId, name: reader.defaultModel.modelId }) : undefined),
                 defaultThinkingLevel: reader.defaultThinkingLevel ?? levelNames[0],
                 fetchedAt: new Date().toISOString(),

package/dist/server/types.d.ts

@@ -405,6 +405,17 @@ export type PublicProvider = {
     baseUrl: string;
     api: string;
     hasKey: boolean;
+    /**
+     * TRUE when the key lives in `models.json` itself (Pi's `"apiKey": "$MY_KEY"` form) rather than
+     * in `auth.json`. It is a credential all the same, so the panel must not report it as missing.
+     */
+    keyInModelsJson?: boolean;
+    /**
+     * The fields of this provider's `models.json` entry that Pi's schema refuses (an empty string
+     * where Pi asks for at least one character). Pi rejects the WHOLE file over one of them, so every
+     * custom provider leaves the picker at once.
+     */
+    invalidFields?: string[];
     /**
      * TRUE when the provider is one of Pi's own, with no entry in `models.json`.
      *
@@ -436,6 +447,13 @@ export type ModelCatalog = {
     defaultThinkingLevel?: string;
     fetchedAt: string;
     error?: string;
+    /**
+     * What Pi says is wrong with its own model configuration, in Pi's own words.
+     *
+     * Pi validates the whole `models.json`, so one entry it refuses empties every picker of custom
+     * providers. This is the only place that says which field is at fault.
+     */
+    configError?: string;
 };
 export type Conversation = {
     id: string;
@@ -995,7 +1013,16 @@ export type ClientCommandBody =
     modelId: string;
 }
 /** Asks for the providers Super Pi manages. The answer carries no key. */
+/**
+ * Repairs Pi's model configuration: the empty fields Pi's schema refuses are dropped from
+ * `models.json`, and nothing else in the file is touched.
+ *
+ * Pi validates the whole file, so one refused entry takes every custom provider out of every
+ * picker. This is the way back.
+ */
  | {
+    type: "providers.repair";
+} | {
     type: "providers.fetch";
 }
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evandu/super-pi",
-  "version": "0.1.124",
+  "version": "0.1.126",
   "description": "Web control plane and companion for Pi",
   "license": "MIT",
   "type": "module",