import type { MetaData, MetaRequirement } from "@metaobjectsdev/metadata";
/** The shape an app's `filter` receives. Never the node itself. */
export interface RequirementView {
    /** "functional" | "architectural" — the check-polarity axis. */
    readonly subType: string;
    /** 1 solution · 2 segment · 3 service · 4 object · 5 member. Undefined on an
     *  unlevelled architectural requirement (the original flat policy form). */
    readonly level: number | undefined;
    readonly status: string | undefined;
    /** Dotted path from the root through nesting ancestors — hierarchy is nesting. */
    readonly path: string;
    /** DISTINCT `type.subType` concerns among the resolved targets. */
    readonly implementedByTypes: readonly string[];
}
export interface ResolvedClaim {
    /** The reference exactly as authored, for the doc comment. */
    readonly ref: string;
    readonly node: MetaData;
    readonly concern: string;
}
export interface WalkedRequirement {
    readonly node: MetaRequirement;
    readonly view: RequirementView;
    readonly targets: readonly ResolvedClaim[];
}
/** `<type>.<subType>` — the key a renderer map is looked up by. */
export declare function concernOf(node: MetaData): string;
/**
 * The concern key for a requirement that resolves NO targets.
 *
 * Doubles as the catch-all renderer key, deliberately: a requirement with nothing
 * to fan out over falls through to whatever the app registered as its default.
 */
export declare const NO_CONCERN = "*";
/**
 * Depth-first walk of every `requirement.*` node, nested ones included.
 *
 * Unresolvable `@implementedBy` references are skipped rather than thrown on —
 * resolution severity is `meta verify`'s job (it depends on `@status`, which is why
 * it cannot live in the loader), and codegen must not fail a build over a
 * diagnostic another command owns.
 */
export declare function walkRequirements(root: MetaData): WalkedRequirement[];
/**
 * Group a requirement's targets by distinct concern — the fan-out unit.
 *
 * One entry per distinct `type.subType`, NOT one per target: a single architectural
 * requirement claimed by 123 entities must emit one stub, not 123, which is the
 * hostile-first-contact outcome FR-038 §10 exists to avoid.
 *
 * A requirement resolving NO targets still yields exactly ONE group. That is not a
 * degenerate case: `REQUIREMENT_LINK_FLOOR_LEVEL` forbids `@implementedBy` below L4,
 * so every L1–L3 requirement resolves nothing — and an application that chooses to
 * cover L3 would otherwise get silence instead of a stub.
 */
export declare function groupByConcern(w: WalkedRequirement): Map<string, ResolvedClaim[]>;
//# sourceMappingURL=requirement-walk.d.ts.map