/**
 * A framework-defaults subdirectory, wherever it actually lives.
 *
 * These used to be `path.storagePath('framework/defaults/<sub>')` and nothing
 * else, which is correct for a vendored app and fatal for one consuming the
 * framework as packages. An app that has dropped `storage/framework/` still has
 * the identical files in `@stacksjs/defaults`, but boot never looked there: the
 * scan was handed a path that did not exist, and `scanDirExportsDetailed` in
 * bun-plugin-auto-imports THROWS on a missing directory rather than returning
 * nothing. The API then dies at startup with
 *
 *   Failed to scan directory .../storage/framework/defaults/functions
 *
 * which is not caught by the tolerance already added around these scans,
 * because the throw happens inside the plugin.
 *
 * Vendored first, so an app with the tree behaves exactly as before and this
 * cannot change what an existing project resolves. Package second. `undefined`
 * when neither exists, which callers drop from the scan list — a framework
 * default that is genuinely absent is not an error, it just contributes no
 * auto-imports.
 *
 * Resolving via `package.json` is deliberate: `@stacksjs/defaults` publishes no
 * `.` export, so the bare specifier does not resolve, and these are data
 * directories rather than modules. Inside this monorepo the specifier lands on
 * the workspace package, which holds only build files — no `functions/`, no
 * `app/` — so the lookup misses and the vendored branch wins, which is what we
 * want when developing the framework itself.
 *
 * The one exception to vendored-first is a tree the installed package has
 * already moved past. `buddy upgrade` is the only thing that writes
 * `storage/framework/defaults`, so bumping `stacks` in package.json and running
 * `bun install` leaves a copy of an older release sitting in front of the one
 * the app actually declared. That copy is a cache, not source, and preferring
 * it means booting code from a release nobody asked for. Only a recorded
 * version that disagrees with the installed one flips the order: an unstamped
 * tree, a framework checkout, and a linked checkout all keep resolving exactly
 * as before. See `inspectDefaultsProvenance`.
 */
export declare function frameworkDefaultsDir(sub: string): string | undefined;
/**
 * The precedence rule on its own, so it can be pinned without a project on
 * disk. Vendored wins unless it is a copy of a release the app has already
 * moved past, and a missing side never beats a present one.
 */
export declare function resolveDefaultsDir(vendored: string | undefined, packaged: string | undefined, vendoredIsStale: boolean): string | undefined;
/**
 * Every directory the auto-import manifest is generated from.
 *
 * Shared by the generator and the staleness check below so the two can
 * never disagree about what the manifest is derived from.
 */
export declare function autoImportSourceDirs(): string[];
/**
 * Has anything the manifest is built from changed since it was written?
 *
 * The manifest used to be regenerated only when it was missing, so once
 * written it never refreshed. Files moved, were renamed, or were deleted
 * underneath it and the stale entries survived: a project on a
 * months-old manifest carried exports pointing at paths that no longer
 * existed, plus duplicates when a file was moved into a subdirectory of
 * the same name (`functions/commerce/products.ts` becoming
 * `functions/commerce/products/products.ts` produced two `useProducts`
 * exports and the `Cannot export a duplicate name` warning on every boot).
 *
 * Regenerating unconditionally is not the alternative: a watcher on the
 * auto-imports directory sees the write, restarts, writes again, and the
 * dev server loops. Comparing mtimes only writes when something actually
 * moved, and the manifest is the newest file afterwards, so the next boot
 * is a no-op and the loop cannot start.
 */
export declare function autoImportsAreStale(): boolean;
/**
 * Generate runtime auto-import files for Bun runtime execution.
 * This creates index files that can be imported to get all auto-imports,
 * including defineModel()-based model definitions and resource functions.
 */
export declare function generateAutoImportFiles(): Promise<void>;
/**
 * Initialize auto-imports for both bundler and runtime.
 *
 * Scans defineModel() model files and resource functions, making them
 * available globally without explicit imports.
 */
export declare function initiateImports(): void;
/** Generate TypeScript declarations for the globals injected by the server. */
export declare function generateServerAutoImportTypes(): Promise<void>;
/**
 * Import and inject all auto-imports into globalThis for runtime access.
 * Call this early in your application startup.
 *
 * This makes all models, plus framework primitives used by actions
 * (Action, response, schema, Auth), available globally, matching the
 * "no imports needed" ergonomics of framework default actions.
 */
export declare function injectGlobalAutoImports(): Promise<void>;
/**
 * Generate a runtime index file for defineModel() models.
 * These use `export default defineModel(...)`, so we re-export each default as a named export.
 *
 * Each entry is either a plain string (recursive scan) or `{ dir, recursive: false }`
 * for non-recursive scans. The defaults root passes the non-recursive form so
 * that feature-module subdirs (commerce/, Content/, …) only ship when the
 * project opted into them via config.
 */
declare type ScanEntry = string | { dir: string, recursive: boolean }