/**
 * d365fo_file(action="delete") — remove an AOT object from the model.
 *
 * The counterpart to `create`, and it has to undo BOTH halves of what create
 * did: the XML file on disk, and the `<Content Include>` entry that makes the
 * element part of a Visual Studio project. Deleting only the file leaves an
 * include pointing at nothing — VS reports it, nothing else does, and the next
 * developer to open the project gets a load error for an object that was
 * intentionally removed weeks earlier.
 *
 * It un-registers from EVERY project of the model that lists the object, not
 * just the active one. An element may legitimately belong to several .rnrproj of
 * one model (see registerFileInActiveProject for the measurement behind that),
 * so cleaning only the active project is exactly the case that leaves a dangling
 * include behind.
 *
 * Guards, in order, and none of them optional:
 *   • grounding — the gate create and modify apply to *-extension objects, under
 *     GROUNDING_ENFORCE=true. Exempting the one action that cannot be undone
 *     would mean an agent barred from CREATING an extension without a prepare
 *     token is free to DELETE one;
 *   • the object must resolve to a real file — a name that matches nothing is
 *     reported as ❌, never as "done" (a silent no-op reads as a successful
 *     delete and the object is still in the build);
 *   • path containment — the target must sit under a configured
 *     <PackagesLocalDirectory>/<Package>/<Model>/Ax<Type>/<File>.xml layout, so
 *     an explicit filePath cannot traverse out of the metadata tree;
 *   • objectType against the file's own Ax<Type> folder — everything downstream
 *     trusts objectType, and axFolderForObjectType answers 'AxClass' for anything
 *     it does not recognise, so a mismatch would delete this file and un-register
 *     a different object;
 *   • model ownership — a file in a standard Microsoft model is refused
 *     outright, and one owned by a different CUSTOM model than the write anchor
 *     goes through the same cross-model refusal every write does.
 *
 * There is no bridge path: MetadataWriteService exposes no delete, and going
 * through the provider would be worse anyway — the file and the project entry
 * are what "deleted" means here, and both are on disk.
 */
import type { CallToolRequest } from '@modelcontextprotocol/sdk/types.js';
import type { XppServerContext } from '../../types/context.js';
export declare function handleDeleteD365File(request: CallToolRequest, context?: XppServerContext): Promise<{
    content: Array<{
        type: string;
        text: string;
    }>;
    isError?: boolean;
}>;
//# sourceMappingURL=deleteD365File.d.ts.map