import type { AppDatabase, FilesAdapter, StoreOps } from "./core/index.js";
import { type EraseAppSql, type HostedStore, type VendoStore } from "./store/index.js";
/** A host may also pass hostedStore({...}) explicitly via createVendo({ store }).
    Recognised by the erase cascade it carries over the store wire — the one
    door no local `VendoStore` shape offers — so the automations notice and the
    /tick sweep know they are talking to Vendo Cloud. */
export declare function isHostedStore(store: VendoStore): store is HostedStore;
/** ADAPTER RULE, store seam (cloned from selectConnections): persistence is
    one VendoStore; which implementation composes is decided HERE. Precedence,
    top to bottom:
      1. an explicitly passed store always wins (BYO — the host's own Postgres
         or PGlite via createStore, the hard BYO rule);
      2. VENDO_API_KEY makes the Cloud hosted store the default for the seam
         the host left unfilled (VENDO_CONSOLE_URL overrides the console base) —
         Vendo data lives with Vendo, tenant = the key's org, resolved
         server-side on every call;
      3. the local createStore default (02-store §4 re-derived: encryption is
         a production-owned concern — with VENDO_STORE_ENCRYPTION_KEY set,
         stored secrets encrypt at rest; without it, dev mode stores locally
         unencrypted (the data dir is gitignored) while production secret
         writes fail closed with instructions).
    The adapters themselves never read the environment. */
/** ADAPTER RULE, files seam (build contract §3.4): the one place a
    `FilesAdapter` is chosen. Explicit `files:` wins (BYO — any S3-compatible
    bucket, or the host's own); unset, the store's `vendo_blobs` backs it up
    to `FILES_STORE_MAX_BYTES`, and the over-cap error names `files:` by name.

    Deliberately NOT defaulted at each call site. The workspace writes blobs and
    the erase cascade deletes them, and if those two ever resolve separately, a
    host who wires `files:` gets rows deleted and objects left behind forever.
    One resolution, returned beside the store it may be backed by, so every
    consumer is handed the same instance. */
/** Which of the two backings that resolution landed on — the same vocabulary
    the boot summary's `files` row prints, so the upload door can name where a
    refused file would have gone. */
export type FilesVenue = "byo" | "store";
/**
 * Can this store keep a harness turn's transcript at all?
 *
 * Asked by attempting the transcript door and catching ITS refusal, rather than
 * re-deriving the rule here: `threadMessageStore` already knows every shape that
 * can serve one (Vendo's own tables, or an adapter that speaks StoreOps), and a
 * second copy of that knowledge would drift from it. Construction only — a
 * property read, never I/O — so it is safe where `createVendo` runs at module
 * init (Workers).
 *
 * One caller left: the `vendo_delegate` gate below. It used to pick the chat
 * route too, back when a deployment that failed this kept the shipped
 * `agent.stream` path; that second engine is gone, so a store that fails here
 * cannot serve chat either and says so on its own.
 */
export declare function storeServesHarnessTurns(store: VendoStore): boolean;
/** ADAPTER RULE, the ops half of the SAME seam: one store, one named-operation
    surface, chosen here beside it. A store that carries its own `ops` wins —
    `VendoStore.ops` is declared optional for exactly this, and the hosted
    store's client is the same `vendo/store-wire@1` the local backend would be
    re-encoding, one hop shorter. A store with a SQL handle gets the local
    backend over it, holding THE files adapter so app files and blobs land in
    the one place the erase cascade reads — and THE app-database door, for the
    same reason: an app's own data is not a `vendo_*` row, so an erase without
    it answers a deletion request with a receipt and leaves every app table
    standing.

    `undefined` for a store with NEITHER — the same three-way answer
    `@vendoai/vendo/store`'s own `backendOf` gives, and the reason this resolves the
    handle here instead of calling `createStoreOps` unconditionally: that call
    opens the handle eagerly, so composition would crash at boot for a host
    whose store has none, where today it refuses at the op that needed one. */
export declare function selectStoreOps(store: VendoStore, files: FilesAdapter, appSql: EraseAppSql | undefined): StoreOps | undefined;
export declare function selectStore(configured: VendoStore | undefined, configuredFiles: FilesAdapter | undefined, configuredAppDatabase: AppDatabase | undefined): {
    store: VendoStore;
    /** THE files adapter for this deployment. Every consumer takes it from here. */
    files: FilesAdapter;
    /** THE 42-op surface for this deployment, over that same store and adapter —
        absent when the store offers neither its own ops nor a SQL handle. */
    ops: StoreOps | undefined;
};
/** The hosted-store automations notice, printed at most once per process. */
export declare function reportHostedStoreOnce(): void;