import type { Plugin } from 'vite';
export declare const SHELL_HTML_PATH: string;
export declare const DEFAULT_PRODUCTION_CSP: string;
export declare const DEFAULT_DEVELOPMENT_CSP: string;
/** Derives the meta-tag-safe policy from a resolved header policy — see `HEADER_ONLY_DIRECTIVES`. */
export declare function stripHeaderOnlyDirectives(policy: string): string;
export interface AppShellOptions {
    csp?: string | false;
}
export declare function resolveContentSecurityPolicy(configured: string | false | undefined, command: 'serve' | 'build'): string | false;
/** True iff `html` declares its own (non-framework-owned) CSP meta tag — see `resolveHeaderContentSecurityPolicy`. */
export declare function htmlDeclaresUserContentSecurityPolicy(html: string): boolean;
/**
 * Resolves the `Content-Security-Policy` *response header* policy — the
 * single source of truth for both the dev middleware
 * (vite-plugin/runtime-security.ts) and the packaged app's bundle metadata
 * (cli/bundle.ts's `metaJson`), so the two never diverge.
 *
 * Delegates to `resolveContentSecurityPolicy` for the actual policy string in
 * every case except one: when `security.csp` is unconfigured and the
 * project's `index.html` declares its own CSP meta tag, `applyContentSecurityPolicy`
 * defers to that user-owned tag and injects none of its own (see the
 * `configured === undefined` branch there). Emitting the framework default as
 * a header in that case would still layer on top of the user's meta policy —
 * browsers enforce multiple CSPs cumulatively — silently tightening (and
 * likely breaking) a policy the user believed they fully controlled. This
 * returns `false` (no header at all) in exactly that case so the user's meta
 * tag remains the sole, authoritative policy.
 */
export declare function resolveHeaderContentSecurityPolicy(configured: string | false | undefined, command: 'serve' | 'build', indexHtml: string | null): string | false;
export declare function applyContentSecurityPolicy(html: string, configured: string | false | undefined, command: 'serve' | 'build'): string;
/**
 * Framework-owned app shell (the Next.js model): user projects no longer
 * ship `index.html` or `src/main.tsx`. This plugin provides:
 *
 *  - `virtual:murasaki/client` — the createRoot bootstrap that `assets/app.html`
 *    points its `<script>` at.
 *  - dev: serves `assets/app.html` for HTML navigations. Requires
 *    `appType: 'custom'` (set below) to disable Vite's own index.html
 *    lookup/SPA-fallback so this plugin is the sole source of HTML.
 *
 * The build's HTML entry is wired separately, in cli/build.ts — Rollup's
 * html handling resolves an entry's emitted file name from its path
 * relative to `root`, ignoring any object-form input key, so an entry
 * living outside `root` (this shell ships inside the murasaki package, not
 * the user project) can't be pointed at directly here.
 *
 * Escape hatch: if the project has its own `index.html`, murasaki steps
 * aside and lets Vite serve it (so an app scaffolded before this model, or a
 * power user who wants to customize the HTML head, keeps working). The
 * framework shell is only used when the project has no index.html of its own
 * — kept in sync with the same check in cli/build.ts.
 */
export declare function appShellPlugin(options?: AppShellOptions): Plugin;
//# sourceMappingURL=shell.d.ts.map