/**
 * gbrain.js — knowledge-base (KB) skill, brokered through the control-plane.
 *
 * WHAT IT IS
 * ──────────
 * Gives an agent an ingest / query / delete surface over a per-tenant KNOWLEDGE
 * BASE (Postgres + pgvector). The brain is persisted as a Stores-v2 store whose
 * TYPE is the engine protocol — `postgres` — NOT `gbrain` (a product name never
 * belongs in a store `type`; `gbrain` is only THIS skill). Naming the type after
 * the protocol keeps the contract stable if the engine is ever swapped.
 *
 * ARCHITECTURE — brokered, NOT a direct sidecar dial (security)
 * ─────────────────────────────────────────────────────────────
 * The KB engine holds tenant data and is TOO heavy to bake into every run, so it
 * runs as an on-demand SIDECAR. But run containers are network-isolated by design
 * (they can reach ONLY the control-plane, never a datastore/sidecar). So this
 * skill does NOT dial the sidecar directly. It behaves EXACTLY like the
 * dataset-store skill: it hits the token-gated control-plane store API
 *
 *   POST {ZIBBY_ACCOUNT_API_URL}/datasets/stores/{storeId}/ingest {docs}
 *   POST {ZIBBY_ACCOUNT_API_URL}/datasets/stores/{storeId}/query  {query, topK}
 *   POST {ZIBBY_ACCOUNT_API_URL}/datasets/stores/{storeId}/delete {sourceIds}
 *
 * with the run's PROJECT_API_TOKEN (Bearer). The control-plane resolves +
 * authorizes the tenant from the token, then (postgres-store.js) launches/reuses
 * the sidecar on the ISOLATED infra network and proxies the call, deriving the
 * sidecar's `kbId` SERVER-SIDE from (account, project, storeId). The agent never
 * sees the sidecar URL or a kbId — the engine is never exposed to the run.
 *
 * STORES v2 — NAME-BASED RESOLUTION (the shared contract, same as dataset-store)
 * ─────────────────────────────────────────────────────────────────────────────
 * Stores are auto-provisioned at DEPLOY and resolved at runtime BY NAME via env:
 *   - The run carries one `ZIBBY_STORE__<name> = <storeId>` per bound store.
 *   - The agent reads the injected "AVAILABLE STORES" catalog (name + type +
 *     description), picks one, and passes the chosen logical `store` NAME.
 *   - That name→storeId env map is BOTH the allowlist AND the resolver.
 * A knowledge-base agent typically has ONE postgres store bound, so `store` may
 * be omitted and defaults to it.
 *
 * TIER / GATING
 * ─────────────
 * Tier ③ (heavy resident runtime → sidecar), but the sidecar is brokered by the
 * control-plane (above), not dialled by the run. Fully server-side, no user
 * connection → UNGATED. No-connection TOGGLEABLE via SKILL_META['gbrain'].
 */
export declare const gbrainSkill: any;
export default gbrainSkill;