/**
 * graph:unexpected-coupling — flag **package dependency cycles** (A→B→A).
 *
 * ADR-0001 (governing): this gate ships exactly ONE project-agnostic signal —
 * a bounded, breakable package cycle. The statistical "coupling outlier" (a
 * package-pair edge count far above the distribution) is a **ranking** → a
 * dashboard insight, NOT a gate rule — it is deliberately NOT emitted here.
 * No declared-layering input is read; the rule runs with zero project-specific
 * config and never bakes in this repo's layer names (that kills genericity).
 *
 * Reads the `packageCoupling` feature column's directed package `edge` rows
 * (Phase C, derived from `dependencies[]`/resolved call edges). A package cycle
 * is a pair of distinct packages A, B with BOTH A→B and B→A present. Detecting
 * the 2-cycle is a bounded membership check over the edge set — NOT an in-rule
 * Tarjan (the SCC algorithm is Phase C's job). One signal per unordered
 * package-pair-cycle; base `high` (bounded — reaches zero when the cycle is
 * broken).
 *
 * De-dup with graph:cycle: that rule reports per-SCC at function granularity;
 * this rule reports per-package-pair at package granularity. Distinct `ruleId`
 * + distinct `code` location → distinct fingerprints (never collide). The two
 * are cross-linked via metadata (`relatedSccCount` here ↔ `relatedPackageCycle`
 * there).
 *
 * Emitted severity routes through the opt-in `applySeverityOverride` clamp
 * (ADR-0005).
 */
export declare const unexpectedCouplingRule: import("../types.js").Rule;
//# sourceMappingURL=unexpected-coupling.d.ts.map