/**
 * Domain naming
 *
 * Single source of truth for turning a file path into a business-domain
 * name. Used by both the dependency-graph cluster naming (`suggestDomainName`)
 * and the repository-mapper domain inference (`inferDomains`) so the two never
 * diverge — a divergence that previously made Java/Kotlin projects collapse all
 * source into a reverse-DNS org root like "springframework" (issue #138).
 */
import type { ScoredFile } from '../../types/index.js';
export type DomainFileRole = 'defining' | 'supporting' | 'excluded';
export type DomainFileRoleReason = 'production-source' | 'test-file' | 'config-file' | 'generated-file' | 'tooling-file' | 'fixture-tree' | 'documentation-file';
export interface DomainFileClassification {
    role: DomainFileRole;
    reason: DomainFileRoleReason;
}
/**
 * Directory segments that should never be used as a domain name when deriving
 * one from a path. Covers generic source roots plus language build layouts
 * (Maven/Gradle `src/main/java`, Go `pkg`/`internal`) and reverse-DNS package
 * roots (`com`, `org`, `io`, …) so that Java/Kotlin/Go projects don't get
 * nonsense domains like "main", "java", "com", or "springframework".
 */
export declare const DOMAIN_NOISE_DIRS: Set<string>;
/**
 * Directory roles are candidate evidence, never a denylist. A nested candidate
 * with one of these exact names needs an independent boundary to survive
 * reconciliation; a top-level owner with the same name remains valid.
 */
export declare const DOMAIN_TECHNICAL_ROLES: Set<string>;
/**
 * Derive a business-domain name from a directory's path segments by walking
 * from the deepest (most specific) segment outward, skipping build-layout and
 * reverse-DNS package noise. Returns null when no meaningful segment exists
 * (e.g. a file sitting directly in a noise root), letting the caller fall back.
 *
 * `src/main/java/com/example/inventory` → `inventory`
 * `org/springframework/samples/petclinic/owner` → `owner`
 */
export declare function deriveDomainFromPath(dirParts: string[]): string | null;
/**
 * Select a stable ownership root for one source tree. Package-oriented JVM
 * layouts keep the leaf-business-package behaviour; module-oriented trees use
 * the first meaningful segment below their source root (and optional `core`
 * wrapper), so implementation children do not become sibling domains.
 */
export declare function deriveDomainOwnershipFromPath(dirParts: string[], extension?: string): string | null;
/** True when a nested candidate name denotes an architectural role. */
export declare function isTechnicalDomainRole(name: string): boolean;
export declare function isDocumentationFile(path: string): boolean;
/**
 * Classify whether an analyzed file may define, only support, or never affect a domain.
 *
 * Documentation is `supporting`, never `defining`: prose describes a system, it
 * does not implement one, so a requirement can never be anchored to it. Because
 * a candidate whose files are all non-defining is already dropped as
 * `non-defining-only`, this alone stops a documentation-only tree from being
 * promoted to a domain the spec workflows would then offer as a target. It stays
 * `supporting` rather than `excluded` so a code domain keeps its docs as
 * footprint evidence (change: stop-specifying-documentation-as-behavior).
 */
export declare function classifyDomainFile(file: ScoredFile): DomainFileClassification;
//# sourceMappingURL=domain-naming.d.ts.map