/**
 * Locate an AOT object's XML file on disk, by type and name.
 *
 * This lived in the MODIFY tool, and four read-only tools (tableInfo, enumInfo,
 * queryInfo, viewInfo) imported it from there — so reading a table pulled in the
 * whole write path, its bridge adapter and its op-spec registry. It answers a
 * question about where metadata lives, which is a util's job, not a tool's.
 */
/**
 * Resolve a MODEL DESCRIPTOR's path: <root>/<Package>/Descriptor/<Model>.xml.
 *
 * Deliberately NOT an entry in the table above. Every type there lives at
 * <Package>/<Model>/Ax<Type>/<Name>.xml; a descriptor is one level shallower and
 * sits beside the model folder rather than inside it, so a 'Descriptor' entry
 * would have both functions build a path that does not exist.
 *
 * The <Package> segment is resolved the same way, though — package == model is
 * the common case, not the rule, and an ISV model inside a differently named
 * package has its descriptor under THAT package. findDescriptorPath does that
 * probe (and the bounded sweep behind it) against one root; this tries the
 * caller's root, then the custom write root, then the configured one, in the
 * same order findD365FileOnDisk prefers.
 *
 * Returns null when no descriptor exists under any of them — the caller reports
 * that rather than writing one, since a model without a descriptor is a wrong
 * path or a wrong model name, not a model waiting to be given a manifest.
 */
export declare function findModelDescriptorPath(modelName?: string, explicitPackagePath?: string): Promise<{
    filePath: string;
    packageName: string;
    model: string;
} | null>;
/**
 * Does the module being referenced actually exist on this box?
 *
 * A `<ModuleReferences>` entry is a package FOLDER name. A typo ("ApplicationSuit",
 * "Ledgers") is not rejected by anything: the descriptor is well-formed, xppc
 * resolves nothing extra through it, and the failure surfaces as the very
 * classStr/type error the reference was added to fix — with the descriptor now
 * looking like it was already handled.
 *
 * So the folder is probed under every configured root. The answer is a NOTE, not
 * a refusal: a package can legitimately be absent from a dev box and present on
 * the build agent (an ISV model installed later in the pipeline), and refusing
 * there would block a correct edit. When no root can be resolved at all, that is
 * said too — "not found" and "could not look" are different claims, and only one
 * of them is evidence of a typo.
 */
export declare function moduleExistenceNote(moduleName: string, explicitPackagePath?: string): Promise<string>;
/**
 * Filesystem fallback for findD365File.
 * Constructs the expected AOT file path from config/env and checks if it exists on disk.
 * This handles objects that were just created and are not yet indexed in the symbol database.
 */
export declare function findD365FileOnDisk(objectType: string, objectName: string, modelName?: string, explicitPackagePath?: string): Promise<string | null>;
/**
 * The read surface findD365FileViaIndex needs, stated structurally so a util does
 * not have to import the symbol index (and, through it, half the server) to ask
 * one question of it. XppSymbolIndex satisfies it as-is.
 */
export interface SymbolFileLookupSource {
    getReadDb(): {
        prepare(sql: string): {
            all(...params: any[]): any[];
        };
    };
}
/** Where the index says an object lives, once the path has been verified on disk. */
export interface IndexedObjectFile {
    filePath: string;
    model: string;
}
/**
 * Locate an object's XML through the SYMBOL INDEX rather than through the
 * configured model's folder layout.
 *
 * findD365FileOnDisk answers "where would an object of this name be, in the model
 * I am configured for" — which is the right question for a write and the wrong one
 * for a read. Reads span every model: get_object_info(include="xml") on a Microsoft
 * class, or on another custom model's class, hit the model-shaped lookup, missed,
 * and were answered with "pass options.modelName" — a whole round trip to supply a
 * fact the same server had already printed ("**Model:** Foundation") one call
 * earlier, and one the caller then has to GUESS. Observed 2026-09-07: three such
 * pairs in one session, one of which took three calls because the guess
 * ("Application Foundation") was wrong.
 *
 * The index stores some paths absolute and some relative to a packages root (582
 * of 60,918 classes on the production DB), so a relative row is resolved against
 * the same roots findD365FileOnDisk prefers. Every candidate is checked on disk
 * before it is returned: an index row whose file is gone is exactly the stale
 * state `search` already warns about, and returning its path would turn a clean
 * "not found" into "found it, but could not read it".
 */
export declare function findD365FileViaIndex(index: SymbolFileLookupSource, objectType: string, objectName: string, modelName?: string): Promise<IndexedObjectFile | null>;
/**
 * The models that hold an object of this type and name, for a "not found" message
 * that can name the answer instead of asking the caller to guess it.
 */
export declare function modelsHoldingObject(index: SymbolFileLookupSource, objectType: string, objectName: string, limit?: number): string[];
/**
 * The path an object's XML WOULD have, whether or not it exists yet.
 *
 * findD365FileOnDisk gates every candidate on fs.access and returns null when
 * none of them exists — correct for a lookup, and a dead end for the one
 * operation that legitimately targets a file that is not there yet:
 * add-diagnostic-suppression on a model that has never suppressed anything has
 * no {Model}_BPSuppressions.xml to find. Without this, that whole path was
 * reachable only by passing filePath by hand, and the tool answered the
 * documented call ("objectName is the file's own base name") with "File not
 * found — re-run action=create", which cannot create this type at all.
 *
 * Existence is what is dropped here, NOT the layout: the <Package> segment
 * still comes from PackageResolver (a package can differ from the model it
 * carries), and the write root is the same one findD365FileOnDisk prefers, so
 * the returned path lands where a real object of that type lives. The caller
 * still passes it through assertWritePathAllowed like any other write target.
 */
export declare function expectedD365FilePath(objectType: string, objectName: string, modelName?: string, explicitPackagePath?: string): Promise<string | null>;
//# sourceMappingURL=objectFileLookup.d.ts.map