cartethyia 2.4.6 → 2.5.1

package/src/providers/integrations/qoder/qoder-realm.ts

@@ -0,0 +1,106 @@
+// Qoder realms: one vendor, two unrelated deployments.
+//
+// `qoder` (global / intl) and `qodercn` (China) share the wire protocol — COSY
+// signing, the scrambled body, the enveloped SSE stream — but nothing else
+// about the address: different gateway host, different openapi host, different
+// OAuth client id, different website, different UA, and a *different model
+// roster*. Treating them as one provider with a region flag is what made a CN
+// account dispatch to `*.qoder.sh` and be refused.
+//
+// Everything per-realm lives here so the adapter, the OAuth client, and the
+// discovery fetcher cannot drift apart on host, client id, or roster.
+//
+// Sourced from the donor hub `Public/qoder2api-hub` (`REALM_CONFIGS` in
+// `qoder_accounts.py`), which builds every upstream URL from this table.
+
+/** One Qoder deployment. */
+export type QoderRealm = "intl" | "cn";
+
+/** Per-realm upstream addresses and client identity. */
+export interface QoderRealmConfig {
+  /** Inference + model-list gateway host. */
+  readonly gateway: string;
+  /** Fallback gateway hosts, tried in order after `gateway`. */
+  readonly gatewayFallbacks: readonly string[];
+  /** Business API host (device token, userinfo, quota). */
+  readonly openapi: string;
+  /** Where the operator signs in. */
+  readonly website: string;
+  /** OAuth client id sent on the device-token exchange. */
+  readonly clientId: string;
+  /** Native redirect the desktop client registers. */
+  readonly redirectUri: string;
+  /** Upstream-facing User-Agent. */
+  readonly userAgent: string;
+}
+
+/** Chat + model-list paths, identical across realms. */
+export const QODER_CHAT_PATH =
+  "/algo/api/v2/service/pro/sse/agent_chat_generation?FetchKeys=llm_model_result&AgentId=agent_common&Encode=1";
+export const QODER_MODELS_PATH = "/algo/api/v2/model/list?Encode=1";
+
+/**
+ * Realm → deployment.
+ *
+ * `intl` carries two gateway fallbacks (`api2`, `api3`); `cn` has exactly one
+ * host and no resilience, which is upstream fact, not an oversight — the donor
+ * loops `gateway + gatewayFallbacks` and gets one candidate for CN.
+ */
+export const QODER_REALMS: Readonly<Record<QoderRealm, QoderRealmConfig>> = {
+  intl: {
+    gateway: "https://api1.qoder.sh",
+    gatewayFallbacks: ["https://api2.qoder.sh", "https://api3.qoder.sh"],
+    openapi: "https://openapi.qoder.sh",
+    website: "https://qoder.com",
+    clientId: "e883ade2-e6e3-4d6d-adf7-f92ceff5fdcb",
+    redirectUri: "qoder://aicoding.aicoding-agent/login-success",
+    userAgent: "Qoder/1.1.64",
+  },
+  cn: {
+    gateway: "https://gateway.qoder.com.cn",
+    gatewayFallbacks: [],
+    openapi: "https://openapi.qoder.com.cn",
+    website: "https://qoder.com.cn",
+    clientId: "1c5e33e1-364d-4ce6-b02c-acaa81274a5c",
+    redirectUri: "qoder-work-cn://",
+    userAgent: "QoderWork/1.1.64",
+  },
+};
+
+/** The realm one bundled provider id belongs to. */
+export function qoderRealmForProvider(providerId: string): QoderRealm {
+  return providerId === "qodercn" ? "cn" : "intl";
+}
+
+/** Gateway hosts for one realm, primary first. */
+export function qoderGatewayCandidates(realm: QoderRealm): readonly string[] {
+  const config = QODER_REALMS[realm];
+  return [config.gateway, ...config.gatewayFallbacks];
+}
+
+/**
+ * Model keys that exist in exactly one realm.
+ *
+ * From the donor's `INTL_EXCLUSIVE` / `CN_EXCLUSIVE` tables. A request for one
+ * of these on the wrong realm does not degrade — it is refused — so the roster
+ * each realm publishes is the authority, not a union.
+ */
+export const QODER_INTL_EXCLUSIVE: ReadonlySet<string> = new Set([
+  "fast",
+  "efficient",
+  "cmodel",
+  "smodel",
+  "ultimate",
+  "performance",
+]);
+
+export const QODER_CN_EXCLUSIVE: ReadonlySet<string> = new Set([
+  "q37fmodel",
+  "gm51model",
+]);
+
+/** True when this model key is served only by the other realm. */
+export function isForeignQoderModel(realm: QoderRealm, modelId: string): boolean {
+  const foreign = realm === "cn" ? QODER_INTL_EXCLUSIVE : QODER_CN_EXCLUSIVE;
+  return foreign.has(modelId.trim().toLowerCase());
+}

package/src/providers/integrations/qoder/qoder-virtual.ts

@@ -0,0 +1,77 @@
+// Qoder virtual models.
+//
+// Qoder's roster keys are opaque slots (`dfmodel`, `cmodel`, `smodel`) rather
+// than model names, so what the UI offers and what a caller would ask for are
+// two different vocabularies. A virtual id is the caller-facing name; it
+// resolves to a roster key before the request is built.
+//
+// This mirrors the Copilot Auto seam: a virtual id is a catalog row that
+// dispatch rewrites to a real `model_id` before the upstream call. The mapping
+// is deliberately static — Qoder publishes no endpoint that resolves a name to
+// a slot the way Copilot's `/auto` does, so there is nothing to ask at runtime.
+
+/** A virtual id and the roster key it stands for. */
+export interface QoderVirtualModel {
+  /** The id a caller sends and the catalog publishes. */
+  readonly id: string;
+  /** The roster key actually dispatched upstream. */
+  readonly target: string;
+  /** Name shown where a human picks a model. */
+  readonly displayName: string;
+}
+
+/**
+ * Virtual ids for every Qoder slot.
+ *
+ * `target` values are roster keys, so a virtual id is only valid while that key
+ * stays in the realm's roster. Discovery replaces the roster, and rows it drops
+ * would leave a virtual id pointing at nothing — dispatch surfaces that as an
+ * explicit error rather than sending an unknown key upstream.
+ */
+export const QODER_VIRTUAL_MODELS: readonly QoderVirtualModel[] = [
+  { id: "deepseek-v4.1-flash", target: "dfmodel", displayName: "DeepSeek-V4.1-Flash" },
+  { id: "deepseek-v4-pro", target: "dmodel", displayName: "DeepSeek-V4-Pro" },
+  { id: "cantus", target: "cmodel", displayName: "Cantus" },
+  { id: "sonus", target: "smodel", displayName: "Sonus" },
+  { id: "qwen3.8-max", target: "qmodel_38max", displayName: "Qwen3.8-Max" },
+  { id: "qwen3.8-flash", target: "qfmodel", displayName: "Qwen3.8-Flash" },
+  { id: "qwen3.7-max", target: "qmodel_latest", displayName: "Qwen3.7-Max" },
+  { id: "qwen3.7-plus", target: "qmodel", displayName: "Qwen3.7-Plus" },
+  { id: "kimi-k3", target: "kmodel_latest", displayName: "Kimi-K3" },
+  { id: "kimi-k2.8-preview", target: "kmodel", displayName: "Kimi-K2.8-Preview" },
+  { id: "glm-5.3", target: "gmodel", displayName: "GLM-5.3" },
+  { id: "glm-5.3-flash", target: "gfmodel", displayName: "GLM-5.3-Flash" },
+  { id: "minimax-m3", target: "mmodel", displayName: "MiniMax-M3" },
+];
+
+/** Virtual id → roster key. */
+const VIRTUAL_TARGETS: ReadonlyMap<string, string> = new Map(
+  QODER_VIRTUAL_MODELS.map((entry) => [entry.id, entry.target]),
+);
+
+/** Roster key → virtual id, for labelling a discovered row. */
+const VIRTUAL_BY_TARGET: ReadonlyMap<string, string> = new Map(
+  QODER_VIRTUAL_MODELS.map((entry) => [entry.target, entry.id]),
+);
+
+/**
+ * Resolves a caller-supplied model id to the roster key to dispatch.
+ *
+ * A non-virtual id is returned unchanged, so every existing caller and every
+ * discovered row keeps working: this is a translation of the new vocabulary,
+ * not a gate on the old one.
+ */
+export function qoderDispatchModelId(modelId: string): string {
+  const trimmed = modelId.trim();
+  return VIRTUAL_TARGETS.get(trimmed) ?? trimmed;
+}
+
+/** True when the id is a virtual name rather than a roster key. */
+export function isQoderVirtualModel(modelId: string): boolean {
+  return VIRTUAL_TARGETS.has(modelId.trim());
+}
+
+/** The virtual name for a roster key, when one exists. */
+export function qoderVirtualIdFor(target: string): string | undefined {
+  return VIRTUAL_BY_TARGET.get(target.trim());
+}