dsh-any-deepseek 0.0.1 → 0.0.3

package/lib/adapter.d.ts

@@ -103,11 +103,21 @@ export declare class AnyDeepSeekAdapter extends LlmAdapter {
     constructor(deps: AdapterDeps);
     providerInfo(provider: string): LlmProviderInfo;
     /**
-     * Advertise exactly one model.
+     * Advertise exactly one model — **unconditionally**.
      *
-     * A relay that is missing a key still gets no catalog entry — the picker then hides the whole
-     * group, which is the harness's own convention for a dormant provider — but the settings page
-     * keeps its entry, so the user can go fix it.
+     * 🔴 **This used to require a resolvable key, and that was wrong.**
+     *
+     * The old rule was "a relay with no key gets no catalog entry; the picker then hides the whole
+     * group, which is the harness's convention for a dormant provider." That reasoning leaks the
+     * provider's *credentials* into its *identity*: the provider disappeared from the model picker
+     * exactly when the user most needed to see it — during first-run setup, before any key exists.
+     * Measured on a real host (owner report, 2026-10-19): with the only channel disabled, the
+     * catalog came back `[]`, so `any-deepseek` was registered but *invisible*, which reads as
+     * "the plugin did not install" no matter what the schema or the routes say.
+     *
+     * ⇒ The catalog answers "what does this provider serve", which is a property of the plugin.
+     * Key presence is answered per request (`MISSING_CREDENTIAL`) and per row in the panel
+     * (`keyConfigured`), where the user can actually act on it.
      */
     listModels(_provider: string): Promise<LlmModelInfo[]>;
     resolveModel(provider: string, model: string, _signal?: AbortSignal): Promise<LlmResolvedModelInfo>;

package/lib/client.js

@@ -199,15 +199,21 @@ window.__ModuleLoader__.load({
 			* Run one settings write and surface a refusal.
 			*
 			* A write can be refused for reasons the user can act on (read-only deployment, the settings
-			* service not composed, a revision conflict) and for reasons they cannot (transport). Both are
-			* facts. Silently discarding them is what makes a panel look alive while nothing is saved —
-			* which is exactly how this plugin's writes were failing without a trace.
+			* service not composed, a revision conflict, a field the host considers non-volatile) and for
+			* reasons they cannot (transport). Both are facts, and silently discarding them is what makes
+			* a panel look alive while nothing is saved.
+			*
+			* 🔴 **The refusal message must NOT name causes we have not checked.** This used to read
+			* "只读部署，或设置服务未启用" — and the one time it actually fired, the real cause was
+			* neither: `current` was missing `.volatile()` in the schema, three layers away. Naming two
+			* unchecked causes sent the investigation in the wrong direction. A refusal is a refusal:
+			* say that, and let the host's own error speak for itself.
 			* @param run - the write.
 			* @param context - what the user was trying to do.
 			*/
 			const write = (run, context = "保存失败") => {
 				run().then((accepted) => {
-					if (!accepted) setError(`${context}：宿主拒绝了这个修改（只读部署，或设置服务未启用）`);
+					if (!accepted) setError(`${context}：宿主拒绝了这个修改`);
 					else setError(null);
 				}, (cause) => {
 					setError(`${context}：${cause instanceof Error ? cause.message : String(cause)}`);

package/lib/config.d.ts

@@ -101,20 +101,39 @@ export interface PluginConfigInput {
 /**
  * Plugin configuration as the plugin reads it (schema OUTPUT).
  *
- * `channels` parses to a reference wrapper — created even when the user set nothing, so the
- * field is always present. Read it through {@link unwrapChannels}.
+ * `channels` and `current` parse to reference wrappers — created even when the user set
+ * nothing, so the fields are always present. Read them through {@link unwrap}.
+ *
+ * 🔴 **`current` is volatile too, and that is not cosmetic** — see the `.volatile()` note on
+ * `PluginConfigSchema`.
  */
 export interface PluginConfigValue {
     channels: Volatile<Record<string, ChannelConfigValue>>;
-    current: string;
+    current: Volatile<string>;
     usage: UsageConfigValue;
     fallback: string[];
 }
 /**
  * Plugin configuration schema.
  *
- * `channels` is volatile: the panel can only render and edit a field the harness sees as a
- * reference, and the runtime value arrives as a wrapper whose `.get()` returns the document.
+ * ## Why EVERY panel-writable field must be `.volatile()`
+ *
+ * The host projects an entry's Config into a settings form only for volatile fields, and its
+ * write path **refuses** any path outside one:
+ *
+ * ```js
+ * for (const path of paths) if (path.length && !isVolatilePath(schema, path))
+ *   throw new Error(`Config field "${path.join('.')}" is not volatile`)
+ * ```
+ *
+ * `channels` was volatile from the start, so channel edits worked. `current` was **not**, so
+ * every click on "设为当前" was rejected by the host — and the host's client-side form turns
+ * that refusal into a bare `false`, which the panel reported as "read-only deployment or the
+ * settings service is not enabled". **That message named two causes it had never checked.**
+ * The real cause was a schema annotation three layers away.
+ *
+ * ⇒ Rule: a field the panel writes must be `.volatile()`, and the runtime side must
+ * `unwrap()` it. Adding a writable field without both halves reproduces this bug silently.
  */
 export declare const PluginConfigSchema: SchemaOf<PluginConfigInput, PluginConfigValue>;
 /**

package/lib/index.js

@@ -72,12 +72,28 @@ const UsageConfigSchema = z.object({
 /**
 * Plugin configuration schema.
 *
-* `channels` is volatile: the panel can only render and edit a field the harness sees as a
-* reference, and the runtime value arrives as a wrapper whose `.get()` returns the document.
+* ## Why EVERY panel-writable field must be `.volatile()`
+*
+* The host projects an entry's Config into a settings form only for volatile fields, and its
+* write path **refuses** any path outside one:
+*
+* ```js
+* for (const path of paths) if (path.length && !isVolatilePath(schema, path))
+*   throw new Error(`Config field "${path.join('.')}" is not volatile`)
+* ```
+*
+* `channels` was volatile from the start, so channel edits worked. `current` was **not**, so
+* every click on "设为当前" was rejected by the host — and the host's client-side form turns
+* that refusal into a bare `false`, which the panel reported as "read-only deployment or the
+* settings service is not enabled". **That message named two causes it had never checked.**
+* The real cause was a schema annotation three layers away.
+*
+* ⇒ Rule: a field the panel writes must be `.volatile()`, and the runtime side must
+* `unwrap()` it. Adding a writable field without both halves reproduces this bug silently.
 */
 const PluginConfigSchema = z.object({
 	channels: z.dict(ChannelConfigSchema).default({}).volatile().description("渠道表：每行一个中转渠道"),
-	current: z.string().default("").description("当前使用的渠道 id"),
+	current: z.string().default("").volatile().description("当前使用的渠道 id"),
 	usage: UsageConfigSchema.default({ enabled: true }),
 	fallback: z.array(z.string()).default([]).description("预留：故障转移顺序（v1 未实现）")
 });
@@ -881,28 +897,32 @@ var AnyDeepSeekAdapter = class extends LlmAdapter {
 		};
 	}
 	/**
-	* Advertise exactly one model.
+	* Advertise exactly one model — **unconditionally**.
+	*
+	* 🔴 **This used to require a resolvable key, and that was wrong.**
+	*
+	* The old rule was "a relay with no key gets no catalog entry; the picker then hides the whole
+	* group, which is the harness's convention for a dormant provider." That reasoning leaks the
+	* provider's *credentials* into its *identity*: the provider disappeared from the model picker
+	* exactly when the user most needed to see it — during first-run setup, before any key exists.
+	* Measured on a real host (owner report, 2026-10-19): with the only channel disabled, the
+	* catalog came back `[]`, so `any-deepseek` was registered but *invisible*, which reads as
+	* "the plugin did not install" no matter what the schema or the routes say.
 	*
-	* A relay that is missing a key still gets no catalog entry — the picker then hides the whole
-	* group, which is the harness's own convention for a dormant provider — but the settings page
-	* keeps its entry, so the user can go fix it.
+	* ⇒ The catalog answers "what does this provider serve", which is a property of the plugin.
+	* Key presence is answered per request (`MISSING_CREDENTIAL`) and per row in the panel
+	* (`keyConfigured`), where the user can actually act on it.
 	*/
 	async listModels(_provider) {
-		const channels = this.deps.channels();
-		const withKey = [];
-		for (const channel of channels) {
-			const key = await this.deps.resolveKey(channel.apiKeyEnv);
-			if (key !== void 0 && key !== "") {
-				withKey.push({
-					provider: PROVIDER_ID,
-					id: ADVERTISED_MODEL_ID,
-					name: ADVERTISED_MODEL_NAME,
-					description: `via ${channel.label}`
-				});
-				break;
-			}
-		}
-		return withKey;
+		const selected = this.selected();
+		const first = this.deps.channels()[0];
+		const label = selected?.label ?? first?.label;
+		return [{
+			provider: PROVIDER_ID,
+			id: ADVERTISED_MODEL_ID,
+			name: ADVERTISED_MODEL_NAME,
+			description: label === void 0 ? "no channel configured yet" : `via ${label}`
+		}];
 	}
 	async resolveModel(provider, model, _signal) {
 		const channel = this.selected();
@@ -1592,8 +1612,8 @@ function apply(ctx, config) {
 		return enabledChannels(resolveChannels(map), map);
 	};
 	const current = () => {
-		const live = ctx.fiber?.config ?? config;
-		return typeof live.current === "string" ? live.current : void 0;
+		const value = unwrap((ctx.fiber?.config ?? config).current);
+		return typeof value === "string" ? value : void 0;
 	};
 	const adapter = new AnyDeepSeekAdapter({
 		channels,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-any-deepseek",
-  "version": "0.0.1",
+  "version": "0.0.3",
   "description": "One DeepSeek V4.1 Flash provider for DeepSeek Harness: paste a key per channel, switch channels manually, token usage booked per real upstream.",
   "license": "MIT",
   "repository": {