import type { TrazumConfig } from './config-schema.js'; import type { PricingCatalogue } from './pricing.js'; /** * Finding and reading `trazum.config.json`. * * Split from the schema in `config-schema.ts` because this is the only half * that touches the filesystem, and the split is load-bearing: `apps/web` * bundles `@trazum/core` for the browser, where a single `node:fs` import * anywhere in the graph fails the build. Reachable only through * `@trazum/core/node`, which the CLI imports and the web app does not. */ export interface LoadedConfig { config: TrazumConfig; /** Absolute path the config came from, or null when none was found. */ path: string | null; /** * Prices to work from: the bundled catalogue, with the config's `pricing` * overlay applied if it named one. Always present, so a caller never has to * decide which of two sources to use. */ pricing: PricingCatalogue; /** Absolute path the overlay came from, or null when there was none. */ pricingPath: string | null; } export interface LoadConfigOptions { /** Directory to start the upward search from. Defaults to the process cwd. */ from?: string; /** * An explicit path. Given one, no search happens and a missing file is an * error: somebody who names a config file is not asking for defaults. */ explicit?: string; } /** * Finds and reads the nearest config file. * * The search walks **upward from the working directory**, which is what makes * `cd packages/thing && trazum check prompt.txt` pick up the repository's * config. It stops at the first hit, at a directory containing `.git`, or after * `MAX_CONFIG_SEARCH_DEPTH` levels — a bound rather than an unlimited climb to * the filesystem root. * * Finding nothing is not an error: the tool is useful with no config at all, * and returning `{config: {}, path: null}` lets the caller say so. */ export declare function loadConfig(options?: LoadConfigOptions): Promise; //# sourceMappingURL=config.d.ts.map