loopengine 0.1.2 → 0.1.4

package/dist/web/global-config.js

@@ -0,0 +1,67 @@
+import { getComposioAuthStatus } from '../core/gateway-tools.js';
+// One entry per provider agent-config.ts's own AgentModelConfig union
+// actually supports (see its own doc comment) — kept here, not derived
+// from that type, since there's no runtime list to introspect a TS
+// union from; adding a fourth provider means one more line here and one
+// more arm in that union, not a rewrite.
+const KNOWN_PROVIDERS = [
+    { provider: 'anthropic', envVar: 'ANTHROPIC_API_KEY' },
+    { provider: 'openai', envVar: 'OPENAI_API_KEY' },
+    { provider: 'deepseek', envVar: 'DEEPSEEK_API_KEY' },
+];
+/** Every registered agent's resolved model, alongside whether each
+ * supported provider actually has credentials available in this
+ * process's environment — an operator's first question when a request
+ * fails isn't "what does this one agent request?" (Overview's own Model
+ * section already answers that) but "is this deployment even set up to
+ * call that provider at all?". Read-only: providers/env vars are wired
+ * into the actual model-call modules (model-calls/*.ts), not something
+ * this page can add support for by itself. An agent with a custom
+ * `createModelCall` (no `config.model`) is skipped — there's no
+ * provider/model pair to report for it, the same "custom" case
+ * describeAgent's own model field already carves out.
+ *
+ * Takes the registered agent names and a config lookup as parameters,
+ * rather than importing core/agent-registry.ts's listAgents/getEntry
+ * directly — that module is this repo's own reference app, not part of
+ * the published package (see index.ts's own header comment), and its
+ * top-level-await agent scan is resolved relative to *its own* file
+ * location, which would be meaningless run from inside node_modules.
+ * Every caller already has its own local registry's listAgents/getEntry
+ * on hand (adapters/http.ts, in this repo or a scaffolded project alike)
+ * to pass straight through. */
+export function describeModelProviders(agentNames, getConfig) {
+    const providers = KNOWN_PROVIDERS.map(({ provider, envVar }) => ({
+        provider,
+        envVar,
+        configured: Boolean(process.env[envVar]),
+    }));
+    const agents = [];
+    for (const name of agentNames) {
+        const config = getConfig(name);
+        if (config?.model) {
+            agents.push({ agent: name, provider: config.model.provider, model: config.model.model ?? '(provider default)' });
+        }
+    }
+    return { providers, agents };
+}
+/** The provider-level counterpart to gateway-tools.ts's own registry
+ * (which is scoped to one agent's chosen tools within an already-
+ * connected provider) — this is "is Composio itself usable from this
+ * machine at all", not "what has agent X registered". Nango/Arcade/
+ * Scalekit are listed as not-yet-supported placeholders, matching
+ * gateway-tools.ts's own header comment about them slotting in later as
+ * thin mcpplug ToolSource adapters once this mechanism is proven —
+ * shown so the Gateways panel isn't silently missing them, not because
+ * there's anything to check for them yet. */
+export async function describeGateways(cliCommand = 'composio') {
+    const composio = await getComposioAuthStatus(cliCommand);
+    return {
+        gateways: [
+            { provider: 'composio', supported: true, connected: composio.connected, email: composio.email, org: composio.org },
+            { provider: 'scalekit', supported: false, connected: false },
+            { provider: 'nango', supported: false, connected: false },
+            { provider: 'arcade', supported: false, connected: false },
+        ],
+    };
+}

package/dist/web/playground.d.ts

@@ -0,0 +1 @@
+export declare const playgroundHtml: string;