import type { ResourceDefinition } from "@uipath/resource-builder-sdk/solution";
/**
 * Pure, dependency-free matching primitives for local solution resources.
 * A leaf module on purpose: `sync-resources-from-bindings` and
 * `resource-mutations` both re-export from here (so existing callers keep
 * their import paths), while `commands/resource-add.ts` imports it directly —
 * which lets its spec run the REAL matcher without mocking this module.
 */
/**
 * Normalize a folder path for comparisons. `.` and `solution_folder` both
 * encode "no folder" (tenant/root scope) — collapsing them to undefined lets
 * us compare a binding's folder against an existing resource's folder
 * consistently regardless of which placeholder either side carries.
 */
export declare function normalizeFolderPath(path: string | undefined): string | undefined;
/**
 * Find a solution resource matching (kind, name | name_<N>, normalized
 * folder). Kind + name are compared case-insensitively; the suffix variants
 * match because SDK's `addResourceWithUniqueName` may have suffixed an
 * earlier add/import of the same name. With a solution-relative `folderPath`
 * (`.` / `solution_folder` / undefined) only root-scope resources match.
 *
 * Single source of truth for "does an in-solution resource already cover
 * this (kind, name, folder)?" — used by the refresh import guard (UV-15289),
 * the virtual idempotency check, and `resources add --source local`.
 */
export declare function findMatchingLocalResource(resources: ResourceDefinition[], kind: string, name: string, folderPath: string | undefined): ResourceDefinition | undefined;
/**
 * Find the member artefact declaration covering (kind, name | name_<N>) —
 * folder-agnostic on purpose.
 *
 * A solution provisions its own members wherever it is installed, so a
 * binding that names a member must resolve to that member's declaration no
 * matter which cloud folder the binding points at. Without this, a binding
 * carrying a real folder (the folder the solution is deployed into) escapes
 * the solution-relative guard, the RCS lookup finds the DEPLOYED member, and
 * every `pack`/`upload` imports it as a fresh `name_<N>` clone plus a
 * feed-pinned package declaration (UV-15817).
 */
export declare function findMatchingMemberResource(resources: ResourceDefinition[], kind: string, name: string, memberProjectKeys: ReadonlySet<string>): ResourceDefinition | undefined;
/**
 * Collect the imported `name_<N>` clones of member artefact declarations — the
 * ones an earlier `pack`/`upload` accumulated before the guard above existed.
 *
 * This list gets deleted, so every condition is there to keep a resource the
 * author meant to keep out of it. A clone must:
 *
 * - not be an artefact declaration itself (no `projectKey`) — those belong to
 *   a project and the SDK refuses to delete them anyway;
 * - carry a `package`-kind dependency. An import of a deployed project drags
 *   the feed package in with it; a `resources add --source local` stub has no
 *   dependencies at all. This is what separates a clone from a `name_<N>`
 *   resource an author created on purpose, and root scope cannot: the SDK
 *   homes an import in `solution_folder` too and records its cloud folder in
 *   `debug_overwrites.json` instead;
 * - match a member declaration on both `kind` and `type`. RCS matched the
 *   deployed copy by name and kind, so it is the same project type — a stub
 *   added by hand carries no subtype;
 * - carry a *strictly* suffixed variant of that member's name. The bare name
 *   is the member's own declaration, and `addResourceWithUniqueName` always
 *   suffixes an import that collides with it.
 */
export declare function findMemberCloneResources(resources: ResourceDefinition[], memberProjectKeys: ReadonlySet<string>): ResourceDefinition[];