/**
 * Advisory detection for files that *look* vendored / external but
 * fell through the dxkit exclusion chain.
 *
 * The bundled `default-exclusions.gitignore` covers the common
 * conventions (`vendor/`, `third_party/`, `third-party/`, `vendored/`,
 * `playground/`, `lexical-playground/`, `node_modules/`, `dist/`, ...)
 * but no curated list can capture every customer's vendored-code
 * organization. A common case the bundled defaults deliberately do
 * NOT exclude is `libs/` — many real codebases (Lerna monorepos, Nx
 * workspaces, npm workspaces) host first-party packages under that
 * directory, so blanket-excluding it would silently hide legitimate
 * source.
 *
 * Instead of forcing a choice between "false-positive exclusions"
 * and "vendored files distorting metrics," this module surfaces
 * customer-visible guidance: when a path that LOOKS vendored slips
 * into a metric like `largestFiles`, the renderer appends a tip
 * pointing at the `.dxkit-ignore` escape hatch. Customers keep
 * authority over what's in scope; we keep the report honest by
 * naming what looks suspicious.
 *
 * Detection is conservative — only path segments that strongly
 * signal vendored code in the wild trigger the advisory. False-
 * positives are acceptable (the tip is advisory, not an action);
 * false-negatives just leave the metric as-is.
 */
/**
 * Check if a relative POSIX path contains a suspect-vendored token.
 * Anchors the check with leading slash so `/libs/` matches a directory
 * boundary, not a filename like `libs-helper.ts`.
 */
export declare function looksVendored(relPath: string): boolean;
/**
 * Filter a `largestFiles`-shaped list to entries that look vendored.
 * Used by report renderers to emit a single advisory block ("these
 * files look vendored; consider `.dxkit-ignore`") when the top-N
 * leaks suspect paths through.
 */
export declare function suspectVendoredEntries<T extends {
    path: string;
}>(files: ReadonlyArray<T>): T[];
//# sourceMappingURL=vendored-advisor.d.ts.map