@evandu/super-pi 0.1.132 → 0.1.133

package/dist/client/index.html

@@ -8,7 +8,7 @@
     <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-ChyemF2I.js"></script>
+    <script type="module" crossorigin src="/assets/index-YEN4ysHF.js"></script>
     <link rel="stylesheet" crossorigin href="/assets/index-D3MEG8uH.css">
   </head>
   <body>

package/dist/server/agents.js

@@ -447,7 +447,27 @@ export async function readAgents(directory, options = {}) {
             throw error;
         }
         for (const file of entries.filter((name) => name.toLowerCase().endsWith(".md")).sort()) {
-            const source = await readFile(join(dir, file), "utf8");
+            // A FILE THAT CANNOT BE READ IS THE SAME KIND OF PROBLEM AS ONE THAT CANNOT BE PARSED.
+            //
+            // The function's own reason for existing says it plainly: "one typo in one agent must not take
+            // down the picker and hide every other agent with it". A file that cannot be READ is at least as
+            // ordinary as that - on Windows "another program has this file open" is a Tuesday, not an
+            // emergency - and it used to be the one unguarded step in this loop: the parse failure below is
+            // collected as a problem, while the read failure was thrown, so a single locked file emptied the
+            // whole directory. Four callers ate that: the main agent's own definition (the turn could not
+            // start), the roster handed to sub-agents on every turn, the roster used when dispatching one,
+            // and the picker (which came back with an empty agent list).
+            let source;
+            try {
+                source = await readFile(join(dir, file), "utf8");
+            }
+            catch (error) {
+                const fileId = file.replace(/\.md$/i, "");
+                if (!seenIds.has(fileId)) {
+                    problems.push({ file, message: `读取失败：${error instanceof Error ? error.message : String(error)}` });
+                }
+                continue;
+            }
             const parsed = parseDefinition(file, source);
             if ("message" in parsed) {
                 const fileId = file.replace(/\.md$/i, "");

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

@@ -23,8 +23,31 @@ export type FeishuStatus = {
     identity?: "user" | "bot";
     /** Whether the agent can read and write documents right now. */
     connected: boolean;
+    /**
+     * WHICH STEP OF THE GUIDE THE PERSON IS ON.
+     *
+     * 1 = install the CLI, 2 = connect the account, 3 = ready. The panel draws the three steps and
+     * marks this one, so "what do I do now" is answered by where the cursor is rather than by a
+     * sentence the person has to interpret.
+     */
+    step: 1 | 2 | 3;
     /** What to do next, in one sentence. */
     message: string;
+    /** The CLI's own words, when it had something to say about the situation. */
+    detail?: string;
+    /** The CLI's own hint, which usually names the exact command to run. */
+    hint?: string;
+    /** Whether the check actually reached Feishu. */
+    verified?: boolean;
+    /**
+     * WHETHER THE APPLICATION ITSELF HAS TO BE REBUILT.
+     *
+     * Distinct from "step 2": a person whose application is fine but who has not logged in still
+     * needs step 2, while a person whose credential was refused needs a NEW application. Telling
+     * those two apart is what keeps a transient network failure from being answered by "let me
+     * create you another application".
+     */
+    rebuild?: boolean;
 };
 /** The outcome of starting the connect flow. */
 export type FeishuConnectResult = {
@@ -50,35 +73,59 @@ export declare class FeishuService {
     private readonly cli;
     /** The device code of a login that is waiting for the person to authorize it. */
     private pendingDeviceCode?;
+    /** Whether an application registration is running and waiting for the browser confirmation. */
+    private pendingAppCreation;
     constructor(cli?: FeishuCli);
     /**
      * WHAT THE CLI CAN DO RIGHT NOW.
      *
-     * The three states a person can be in, and what each one means for the agent:
+     * The states a person can be in, and what each one means for the agent:
      *
      * - The CLI is not installed: nothing works, and the fix is one command.
      * - The CLI has no application: `config init --new` creates one through a browser confirmation,
      *   so the developer console is never visited.
-     * - The CLI has an application but no person logged in: the agent can still act as the
-     *   application, but it cannot reach that person's own documents until they authorize it.
+     * - The application exists but its credential is no longer accepted: the CLI says
+     *   `verify_failed` and names the reason, and the fix is a new application - which is the same
+     *   browser confirmation, so it stays one button.
+     * - The application works but no person is logged in: the agent can act as the application, but
+     *   it cannot reach that person's own documents until they authorize it.
      */
     status(): Promise<FeishuStatus>;
+    /**
+     * CHECKS THE CONNECTION, and says whether it actually works.
+     *
+     * The status already verifies; this is the same answer shaped for a button, so that a person can
+     * ask "it still doesn't work, why?" and get the CLI's own verdict rather than a guess.
+     */
+    verify(): Promise<{
+        ok: boolean;
+        message: string;
+        detail?: string;
+        hint?: string;
+    }>;
     /**
      * STARTS THE CONNECT FLOW.
      *
      * Two steps, and which one runs is decided by what the CLI already has:
      *
-     * - No application: `config init --new` registers one through a browser confirmation. It BLOCKS
-     *   until the person confirms, so it runs in the background and the URL is taken from its output.
-     * - An application but no person: `auth login --no-wait --json` asks for a device code and hands
-     *   back the URL to open. The code is kept here until the person says they are done.
+     * - No application, or one whose credential no longer works: `config init --new` registers a
+     *   fresh application through a browser confirmation. It BLOCKS until the person confirms, so it
+     *   runs in the background and the URL is taken from its output. The broken case goes here too,
+     *   because a new application is the one repair that needs no secret to be typed into a form.
+     * - A working application but no person: `auth login --no-wait --json` asks for a device code
+     *   and hands back the URL to open. The code is kept here until the person says they are done.
      */
     connect(): Promise<FeishuConnectResult>;
     /**
-     * FINISHES THE LOGIN, once the person says they authorized it.
+     * FINISHES THE FLOW, once the person says they are done.
+     *
+     * TWO KINDS OF "DONE", and the difference is what the CLI is waiting for:
      *
-     * The device code is handed back to the CLI, which completes the exchange and stores the token
-     * in the keychain. Super Pi never sees the token itself.
+     * - An application is being registered: `config init --new` finishes by itself once the person
+     *   confirms in the browser, so there is nothing to hand back. The status is re-read and the
+     *   answer is whether the application showed up.
+     * - A login is being authorized: the device code is handed back to the CLI, which completes the
+     *   exchange and stores the token in the keychain. Super Pi never sees the token itself.
      */
     completeConnect(): Promise<FeishuConnectResult>;
     /**

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

@@ -17,19 +17,24 @@ export class FeishuService {
     cli;
     /** The device code of a login that is waiting for the person to authorize it. */
     pendingDeviceCode;
+    /** Whether an application registration is running and waiting for the browser confirmation. */
+    pendingAppCreation = false;
     constructor(cli = new FeishuCli()) {
         this.cli = cli;
     }
     /**
      * WHAT THE CLI CAN DO RIGHT NOW.
      *
-     * The three states a person can be in, and what each one means for the agent:
+     * The states a person can be in, and what each one means for the agent:
      *
      * - The CLI is not installed: nothing works, and the fix is one command.
      * - The CLI has no application: `config init --new` creates one through a browser confirmation,
      *   so the developer console is never visited.
-     * - The CLI has an application but no person logged in: the agent can still act as the
-     *   application, but it cannot reach that person's own documents until they authorize it.
+     * - The application exists but its credential is no longer accepted: the CLI says
+     *   `verify_failed` and names the reason, and the fix is a new application - which is the same
+     *   browser confirmation, so it stays one button.
+     * - The application works but no person is logged in: the agent can act as the application, but
+     *   it cannot reach that person's own documents until they authorize it.
      */
     async status() {
         const status = await this.cli.status();
@@ -39,59 +44,121 @@ export class FeishuService {
                 userReady: false,
                 botReady: false,
                 connected: false,
-                message: "没有检测到官方飞书 CLI（lark-cli）。请先在终端运行 npm i -g @larksuite/cli 装上它，再回到这里点「连接飞书账号」。如果已经装了但 Super Pi 找不到（两边的 PATH 不一样），用环境变量 SUPER_PI_FEISHU_CLI 指向它的完整路径再重启 Super Pi。",
+                step: 1,
+                message: "还没有安装官方飞书 CLI。在终端里跑一次 npm i -g @larksuite/cli 就行，装完回到这里点「连接飞书账号」。",
+                ...(status.hint ? { hint: status.hint } : {}),
             };
         }
+        const common = {
+            installed: true,
+            ...(status.version ? { version: status.version } : {}),
+            ...(status.appId ? { appId: status.appId } : {}),
+            ...(status.verified !== undefined ? { verified: status.verified } : {}),
+            ...(status.note ? { detail: status.note } : {}),
+        };
         if (!status.appId) {
             return {
-                installed: true,
-                ...(status.version ? { version: status.version } : {}),
+                ...common,
+                userReady: false,
+                botReady: false,
+                connected: false,
+                step: 2,
+                message: "CLI 已就绪，还差一个应用。点「连接飞书账号」，浏览器里确认一下就有了——不用去开发者后台注册。",
+            };
+        }
+        // A CREDENTIAL THE CLI KNOWS IS BROKEN is the case a plain status would have hidden: the local
+        // file still holds an app, so the panel would have said "已配置", and every document call
+        // would have failed. The CLI's own verdict is the one that can be acted on.
+        const broken = status.botStatus === "verify_failed" || (status.verified === true && !status.botReady && !status.userReady);
+        if (broken) {
+            return {
+                ...common,
                 userReady: false,
                 botReady: false,
                 connected: false,
-                message: "飞书 CLI 已就绪，但还没有应用。点「连接飞书账号」，它会给你一个浏览器链接，确认之后应用就建好了——不用去开发者后台注册。",
+                step: 2,
+                rebuild: true,
+                message: `应用的凭据已经失效：${trimSentence(status.botMessage ?? "飞书拒绝了这次验证")}。点「连接飞书账号」会重新走一遍确认流程、建一个可用的应用。`,
+                ...(status.hint ? { hint: status.hint } : {}),
+            };
+        }
+        if (status.verified === false) {
+            return {
+                ...common,
+                userReady: false,
+                botReady: false,
+                connected: false,
+                step: 2,
+                message: "没能连上飞书（本地配置读到了，但验证请求没出去）。检查一下网络，然后点「测试连接」重试。",
+                ...(status.hint ? { hint: status.hint } : {}),
             };
         }
         if (!status.userReady) {
             return {
-                installed: true,
-                ...(status.version ? { version: status.version } : {}),
-                appId: status.appId,
+                ...common,
                 userReady: false,
                 botReady: status.botReady,
                 connected: false,
+                step: 2,
                 ...(status.identity ? { identity: status.identity } : {}),
-                message: "应用已配置，但还没有登录你的账号。点「连接飞书账号」用浏览器授权，授权之后 Agent 就能以你的身份读写你自己的文档，不用逐篇加协作者。",
+                message: "应用已经能用，但还没登录你的账号。点「连接飞书账号」在浏览器里授权一下，授权之后 Agent 就能以你的身份读写你自己的文档，不用逐篇加协作者。",
+                ...(status.hint ? { hint: status.hint } : {}),
             };
         }
         return {
-            installed: true,
-            ...(status.version ? { version: status.version } : {}),
-            appId: status.appId,
+            ...common,
             userReady: true,
             botReady: status.botReady,
             connected: true,
             identity: status.identity ?? "user",
+            step: 3,
             message: "已连接：Agent 会以你的身份读写飞书云文档。",
         };
     }
+    /**
+     * CHECKS THE CONNECTION, and says whether it actually works.
+     *
+     * The status already verifies; this is the same answer shaped for a button, so that a person can
+     * ask "it still doesn't work, why?" and get the CLI's own verdict rather than a guess.
+     */
+    async verify() {
+        const status = await this.status();
+        if (status.connected) {
+            return {
+                ok: true,
+                message: status.message,
+                ...(status.detail ? { detail: status.detail } : {}),
+            };
+        }
+        return {
+            ok: false,
+            message: status.message,
+            ...(status.detail ? { detail: status.detail } : {}),
+            ...(status.hint ? { hint: status.hint } : {}),
+        };
+    }
     /**
      * STARTS THE CONNECT FLOW.
      *
      * Two steps, and which one runs is decided by what the CLI already has:
      *
-     * - No application: `config init --new` registers one through a browser confirmation. It BLOCKS
-     *   until the person confirms, so it runs in the background and the URL is taken from its output.
-     * - An application but no person: `auth login --no-wait --json` asks for a device code and hands
-     *   back the URL to open. The code is kept here until the person says they are done.
+     * - No application, or one whose credential no longer works: `config init --new` registers a
+     *   fresh application through a browser confirmation. It BLOCKS until the person confirms, so it
+     *   runs in the background and the URL is taken from its output. The broken case goes here too,
+     *   because a new application is the one repair that needs no secret to be typed into a form.
+     * - A working application but no person: `auth login --no-wait --json` asks for a device code
+     *   and hands back the URL to open. The code is kept here until the person says they are done.
      */
     async connect() {
         const status = await this.status();
         if (!status.installed) {
             return { ok: false, message: status.message };
         }
-        if (!status.appId) {
+        // Step 2 is "connect the account"; the application part of it is missing or broken when the
+        // person has no application OR when the one they have was refused by Feishu.
+        if (!status.appId || status.rebuild) {
             const verificationUri = await this.cli.startAppCreation();
+            this.pendingAppCreation = true;
             return {
                 ok: true,
                 step: "app",
@@ -119,12 +186,31 @@ export class FeishuService {
         }
     }
     /**
-     * FINISHES THE LOGIN, once the person says they authorized it.
+     * FINISHES THE FLOW, once the person says they are done.
      *
-     * The device code is handed back to the CLI, which completes the exchange and stores the token
-     * in the keychain. Super Pi never sees the token itself.
+     * TWO KINDS OF "DONE", and the difference is what the CLI is waiting for:
+     *
+     * - An application is being registered: `config init --new` finishes by itself once the person
+     *   confirms in the browser, so there is nothing to hand back. The status is re-read and the
+     *   answer is whether the application showed up.
+     * - A login is being authorized: the device code is handed back to the CLI, which completes the
+     *   exchange and stores the token in the keychain. Super Pi never sees the token itself.
      */
     async completeConnect() {
+        if (this.pendingAppCreation) {
+            this.pendingAppCreation = false;
+            const status = await this.status();
+            if (status.appId) {
+                return {
+                    ok: true,
+                    message: "应用建好了。接下来点「连接飞书账号」授权你的账号，Agent 就能以你的身份读写文档了。",
+                };
+            }
+            return {
+                ok: false,
+                message: "还没看到应用建好。请确认浏览器里的确认已经提交（有时要等 CLI 写完钥匙串），然后再点一次「我已完成」。",
+            };
+        }
         if (!this.pendingDeviceCode) {
             return { ok: false, message: "没有待完成的登录。点「连接飞书账号」重新开始。" };
         }
@@ -235,8 +321,16 @@ export class FeishuService {
         throw new Error(`未知的飞书工具操作：${action}`);
     }
 }
-/** The message of a failure, whatever shape the failure has. */
-function messageOf(error) {
+/**
+ * A SENTENCE WITHOUT ITS OWN FULL STOP.
+ *
+ * The CLI writes English sentences that end in a period, and this service writes Chinese ones that
+ * end in 。 — so a message pasted in verbatim reads "invalid.。点「重新连接」".
+ */
+function trimSentence(text) {
+    return text.trim().replace(/[.\s]+$/, "");
+}
+/** The message of a failure, whatever shape the failure has. */ function messageOf(error) {
     if (error instanceof FeishuCliError)
         return error.message;
     if (error instanceof Error)

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

@@ -1132,9 +1132,17 @@ export class RunService {
                 // `active: true` on every delta is not a field Pi sent - it is the conclusion Super Pi draws from
                 // having received one. Pi announces the END of reasoning with `thinking_end` and puts nothing on
                 // the delta, so these two halves together are the whole lifecycle.
-                onThinking: (delta) => {
+                onThinking: async (delta) => {
                     if (!delta)
                         return;
+                    // THINKING IS THE MODEL PRODUCING SOMETHING, SO THE TURN IS RUNNING. The contract above
+                    // says a turn moves from `waiting` to `running` once the model has produced ANY signal -
+                    // "regardless of shape" - and a thinking delta is the same signal as a text delta: it is Pi
+                    // yielding data back. Only two shapes promoted the turn (text and a tool-call notice), so a
+                    // model that thinks before it answers sat in `waiting` for the whole of its reasoning: the
+                    // panel said 「等待 LLM 返回」 while the model was plainly working, and - because the stop
+                    // button appears while a turn is in flight - the reader had no way to stop it for exactly
+                    // as long as the thinking lasted.
                     const newBlock = thinkingAnswerAt !== spoken || thinkingInterrupted;
                     if (newBlock) {
                         thinkingBlock++;
@@ -1145,6 +1153,12 @@ export class RunService {
                     this.store.setThinkingActiveLive(conversation.id, assistant.id, true);
                     thought += delta.length;
                     this.store.appendThinkingDeltaLive(conversation.id, assistant.id, delta, spoken, newBlock);
+                    // THE PROMOTION COMES AFTER THE DELTA IS IN THE STORE, so the state snapshot it broadcasts
+                    // carries the same thinking the client is about to receive as a live event. Promoting first
+                    // broadcast a snapshot WITHOUT this delta, and the client - which prefers the live body only
+                    // while the conversation is running - took that stale snapshot, lost the thinking block's
+                    // boundary, and dropped a tool call out of the block it belonged to.
+                    await promoteToRunning();
                     this.broadcaster.broadcast({ type: "message.thinking", conversationId: conversation.id, messageId: assistant.id, delta, active: true, at: spoken, blockIndex: thinkingBlock });
                     scheduleCheckpoint();
                 },

package/dist/server/feishu-cli.d.ts

@@ -64,6 +64,16 @@ export type FeishuCliStatus = {
     identity?: FeishuIdentity;
     /** Feishu's own "what to do about it", when the CLI had something to say. */
     hint?: string;
+    /** The CLI's own summary of the situation, when it has one. */
+    note?: string;
+    /** The state of each identity, as the CLI words it: ready, missing, verify_failed, ... */
+    botStatus?: string;
+    userStatus?: string;
+    /** What the CLI says about each identity, in its own words. */
+    userMessage?: string;
+    botMessage?: string;
+    /** Whether the check actually reached Feishu, rather than only reading the local credential. */
+    verified?: boolean;
 };
 /** The outcome of a CLI call, in the shape this product speaks in. */
 export declare class FeishuCliError extends Error {
@@ -139,8 +149,14 @@ export declare class FeishuCli {
     /**
      * WHAT THE CLI KNOWS ABOUT ITSELF.
      *
-     * `auth status` is the one command that answers without touching the network unless asked to
-     * verify, so it is what the panel polls.
+     * THE VERIFY IS ON, and that is the whole point of asking the CLI at all. Without `--verify` the
+     * CLI only reads its local credential and reports the application as "ready" — which is what it
+     * said on a machine whose App Secret had expired, and which would have left the panel claiming
+     * everything was fine while every document call failed. With `--verify` the CLI asks Feishu, and
+     * the answer distinguishes the states a person can act on: `ready`, `missing`, `verify_failed`.
+     *
+     * When the verification cannot reach Feishu at all (no network), the plain status is read
+     * instead, and `verified: false` says so rather than pretending.
      */
     status(): Promise<FeishuCliStatus>;
     /**

package/dist/server/feishu-cli.js

@@ -198,38 +198,72 @@ export class FeishuCli {
     /**
      * WHAT THE CLI KNOWS ABOUT ITSELF.
      *
-     * `auth status` is the one command that answers without touching the network unless asked to
-     * verify, so it is what the panel polls.
+     * THE VERIFY IS ON, and that is the whole point of asking the CLI at all. Without `--verify` the
+     * CLI only reads its local credential and reports the application as "ready" — which is what it
+     * said on a machine whose App Secret had expired, and which would have left the panel claiming
+     * everything was fine while every document call failed. With `--verify` the CLI asks Feishu, and
+     * the answer distinguishes the states a person can act on: `ready`, `missing`, `verify_failed`.
+     *
+     * When the verification cannot reach Feishu at all (no network), the plain status is read
+     * instead, and `verified: false` says so rather than pretending.
      */
     async status() {
         const version = await this.version();
         if (!version)
             return { installed: false, userReady: false, botReady: false };
+        const read = async (args) => this.run(args, { timeoutMs: 30_000 });
         let envelope;
+        let verified = true;
         try {
-            envelope = await this.run(["auth", "status", "--json"], { timeoutMs: 30_000 });
+            envelope = await read(["auth", "status", "--verify", "--json"]);
+            // The CLI answers a failed verification with an error envelope. That is not the same as a
+            // credential that Feishu refused - it means the question was never answered - so the local
+            // status is read instead and the panel is told that Feishu was never asked.
+            if (envelope.ok === false) {
+                envelope = await read(["auth", "status", "--json"]);
+                verified = false;
+            }
         }
         catch (error) {
-            return {
-                installed: true,
-                version,
-                userReady: false,
-                botReady: false,
-                ...(error instanceof FeishuCliError ? { hint: error.message } : {}),
-            };
+            try {
+                envelope = await read(["auth", "status", "--json"]);
+                verified = false;
+            }
+            catch {
+                return {
+                    installed: true,
+                    version,
+                    userReady: false,
+                    botReady: false,
+                    ...(error instanceof FeishuCliError ? { hint: error.message } : {}),
+                };
+            }
         }
         const identities = pick(envelope.data ?? envelope, "identities");
         const user = identities?.user;
         const bot = identities?.bot;
         const identity = asString(envelope.identity) ?? pick(envelope.data ?? envelope, "identity");
+        const appId = asString(pick(envelope.data ?? envelope, "appId", "app_id"));
+        const note = asString(pick(envelope.data ?? envelope, "note"));
+        // THE HINT OF THE IDENTITY THAT IS FAILING. Both identities carry a hint, and the wrong one
+        // sends the person to the wrong command: the application's hint says "log in" when the real
+        // problem is that the credential was refused, and the user's hint says "check the credential"
+        // when all that is missing is a login.
+        const failing = bot?.available !== true ? bot : user;
         return {
             installed: true,
             version,
-            ...(asString(pick(envelope.data ?? envelope, "appId", "app_id")) ? { appId: asString(pick(envelope.data ?? envelope, "appId", "app_id")) } : {}),
+            ...(appId ? { appId } : {}),
             userReady: user?.available === true,
             botReady: bot?.available === true,
             ...(identity === "user" || identity === "bot" ? { identity } : {}),
-            ...(asString(user?.hint) ?? asString(bot?.hint) ? { hint: (asString(user?.hint) ?? asString(bot?.hint)) } : {}),
+            ...(asString(user?.status) ? { userStatus: asString(user?.status) } : {}),
+            ...(asString(bot?.status) ? { botStatus: asString(bot?.status) } : {}),
+            ...(asString(user?.message) ? { userMessage: asString(user?.message) } : {}),
+            ...(asString(bot?.message) ? { botMessage: asString(bot?.message) } : {}),
+            ...(asString(failing?.hint) ? { hint: asString(failing?.hint) } : {}),
+            ...(note ? { note } : {}),
+            verified,
         };
     }
     /**

package/dist/server/feishu-config.d.ts

@@ -0,0 +1,68 @@
+import type { FeishuDomain } from "./feishu.js";
+/**
+ * THE FEISHU CREDENTIALS, and where they live.
+ *
+ * WHY A FILE IN THE DATA DIRECTORY AND NOT A FIELD IN THE APP STATE. The App State is broadcast to
+ * every browser that connects, and it is written to disk in a form that is meant to be readable.
+ * A secret does not belong there - the same rule the provider registry follows, where the API key
+ * lives in `<dataDir>/providers.json` with restrictive permissions and the browser is told only
+ * that a key exists.
+ *
+ * WHY THE ENVIRONMENT OVERRIDES THE FILE. A deployment that provisions the credential through the
+ * environment should not have to write a file as well, and the environment is the harder thing to
+ * override accidentally. The file is the fallback, not the other way round.
+ *
+ * WHY THERE IS ONE SET OF CREDENTIALS FOR THE WHOLE SERVER. Feishu credentials belong to an
+ * application inside one enterprise, and Super Pi runs on one person's machine. A per-workspace
+ * credential would be a second enterprise's application, and the user of that workspace would have
+ * to be handed a secret they never asked for.
+ */
+export type FeishuConfig = {
+    /** The application's App ID. */
+    appId?: string;
+    /** The application's App Secret. Never leaves the server. */
+    appSecret?: string;
+    /** Which Feishu the calls go to. */
+    domain?: FeishuDomain;
+};
+/** Where the credentials come from, for the panel to show. */
+export type FeishuConfigSource = "environment" | "file" | "none";
+export declare class FeishuConfigStore {
+    private readonly file;
+    constructor(file: string);
+    /**
+     * The credentials in force, and where they came from.
+     *
+     * The environment wins over the file, and the file is read only when the environment has not
+     * said anything - so a machine that provisions the credential through the environment never
+     * touches the file at all.
+     */
+    read(): Promise<{
+        config: FeishuConfig;
+        source: FeishuConfigSource;
+    }>;
+    /**
+     * The file's own contents, and only its own contents.
+     *
+     * A file that cannot be read is a file that is not there, and a file that cannot be parsed is a
+     * file this server did not write. Both are reported rather than thrown: a broken credential
+     * file must not stop the server from starting.
+     */
+    private readFile;
+    /**
+     * Writes the credentials.
+     *
+     * The write is atomic (a temporary file and a rename) so a crash cannot leave half a JSON file
+     * behind, and the file's mode is 0600 so that a secret is not readable by every account on the
+     * machine. On Windows the mode is not enforced the same way, and there is nothing this code can
+     * do about that.
+     */
+    write(config: FeishuConfig): Promise<void>;
+}
+/**
+ * The domain a name means, defaulting to Feishu.
+ *
+ * A name this does not recognise is Feishu rather than an error: the domain is a convenience for
+ * Lark users, and refusing to start over a typo in it would be worse than trying Feishu.
+ */
+export declare function domainOf(value: string | undefined): FeishuDomain;