/**
 * The HOSTING-side manifest — the JSON the release intake actually parses.
 *
 * WHY THIS IS A SEPARATE MODULE, and it is the same reason `manifest-schema.ts` is one: the
 * browser deploy wizard must send the intake exactly what the CLI sends, and `upload.ts` imports
 * `node:fs`/`node:crypto` at module level, so a browser cannot import it at all. The alternative
 * was a second implementation in the wizard — and that is how the CLI and the wizard end up
 * disagreeing about a seller's own manifest, with only one of them being the version the security
 * review saw.
 *
 * WHAT WENT WRONG WITHOUT IT, recorded because the failure was silent and expensive: the wizard
 * forwarded the raw `clustly.yaml` TEXT as `manifest`, while the intake does `JSON.parse` on that
 * field. Every browser deploy therefore died at the last hop, and the marketplace's status mapper
 * turned the intake's `400` into "hosting is unavailable — try again shortly": a payload bug
 * wearing an outage's clothes, on a screen that had just uploaded the bundle successfully.
 *
 * NOTHING HERE MAY IMPORT `node:`.
 */
import { type ClustlyManifest } from "./manifest-schema";
/** Manifest framework → hosting runtime (mirrors the hosting agent-sdk's enum). */
export declare const FRAMEWORK_RUNTIMES: Record<string, string>;
/**
 * The hosting-side manifest the bundle ships under. `version` is derived from the bundle content
 * (deterministic: same bytes → same version → upstream idempotency dedupes a re-push).
 *
 * `openclawVersion` is required for the openclaw runtime and unavailable in a browser — hosting
 * pins a vetted engine release, and the CLI learns it by running `openclaw --version`. The wizard
 * therefore cannot deploy an openclaw project, and this says so in the seller's words rather than
 * letting the intake refuse it later.
 */
export declare function hostedManifest(manifest: ClustlyManifest, bundleSha256: string, openclawVersion?: string): string;