/**
 * Cross-recipe apply-ordering for `compileRecipeSet`.
 *
 * Two layers:
 *   - **Coarse rank** (`RECIPE_APPLY_RANK`) orders ACROSS kinds — a page
 *     after its page template, a site after its site template.
 *   - **Intra-rank topo-sort** (`stableTopologicalSortWithinRanks`)
 *     orders WITHIN a rank by each recipe's outbound cross-recipe handle
 *     references, so a referencing recipe applies after its referent
 *     even when file-glob order would put it first.
 *
 * The reference inventory comes from the shared `recipeReferences()`
 * accessor — the same one the cross-recipe validator consumes — so the
 * two stay in lockstep automatically (a new reference site added there
 * is picked up by BOTH the topo-sort and validation without a second
 * edit here).
 */
import type { Recipe } from "../schema/recipe.js";
/**
 * Cross-recipe apply-ordering rank, by recipe kind. `compileRecipeSet`
 * stably sorts per-recipe IRs by this rank so every recipe is applied
 * after the definitions it references:
 *
 *   0  definitions — templates, sections, enums, workflows: referenced
 *      by everything, reference nothing cross-recipe forward.
 *   1  content items + placeholders — reference rank-0 templates.
 *   2  partial designs — place components, bind shared content items.
 *   3  page designs + pages — reference page templates, partials,
 *      content items.
 *   4  site templates — reference page templates + page designs.
 *   5  sites — instance a site template, point at an initial page.
 *
 * The rank is coarse — it orders ACROSS kinds, not within. Intra-rank
 * forward references (e.g. one component's `insertOptions` naming
 * another) still rely on the executor's `crossRecipeRefs` path seeding.
 */
export declare const RECIPE_APPLY_RANK: Record<Recipe["kind"], number>;
/**
 * The set of in-set cross-recipe dependency handles for a single recipe.
 *
 * Thin wrapper over the shared `recipeReferences()` inventory — pulls
 * the `handle` of every outbound reference (validated or topo-only),
 * de-dupes, and drops self-references. (Validation runs separately and
 * asserts every handle resolves to an extant recipe of the right kind;
 * this extractor assumes input has already been validated and doesn't
 * re-check.)
 *
 * When the surrounding recipe `set` is provided, page-tree nesting edges
 * derived from `itemPath` are included too (see
 * `pageAncestorDependencies`) — a page nested under another page's path
 * depends on that ancestor even though no handle reference exists.
 *
 * Exported for `recipe list --json`: the emitted `dependsOn` edges are
 * exactly the edges this module's topo-sort schedules by, so a batch
 * driver partitioning the set into parallel waves works from the same
 * graph the sequential apply order derives from.
 */
export declare const extractRecipeDependencies: (recipe: Recipe, set?: readonly Recipe[]) => readonly string[];
/**
 * A recipe's in-set dependencies as a true APPLY-ORDER graph — what a batch
 * driver schedules on directly, across ranks, without re-deriving anything.
 * Distinct from {@link extractRecipeDependencies} (raw references) in two ways:
 *
 *   - **Forward refs dropped.** `recipeReferences()` emits every handle a
 *     recipe names, including ones that apply LATER (a `site-template` at
 *     rank 4 lists its `dictionaries` at rank 6). Those are references, not
 *     "apply-after" edges — treating them as dependencies would invert the
 *     apply order — so only backward / same-rank edges (`depRank <= selfRank`)
 *     survive. Rank order encodes the forward direction.
 *   - **Implicit `dictionary → site` injected.** A dictionary's items land
 *     under `<site>/Dictionary`, whose bucket SXA scaffolds during
 *     `CreateSiteFromTemplate`; but the dictionary's `site` field is usually
 *     omitted (it targets the deploy-target site), so `recipeReferences()`
 *     emits no edge. Injected here to every in-set site, mirroring the coarse
 *     rank barrier ("sites before dictionaries"). This is the ONLY implicit
 *     cross-rank apply-order dependency — pages / content-items / enumerations
 *     target the pre-existing deploy-target site, not an in-set `SiteRecipe`.
 *
 * The emitted graph is a superset-safe over-approximation at worst (a
 * dictionary depends on every in-set site, not only its host), never an
 * under-approximation — so a driver may drop the coarse rank barrier and
 * schedule purely on these edges without reordering risk.
 */
export declare const applyOrderDependencies: (recipe: Recipe, set: readonly Recipe[]) => string[];
/**
 * Order recipes by apply-rank, then topologically by intra-rank
 * cross-recipe dependencies. Producer recipes push before the recipes
 * that reference them.
 *
 * The sort is stable: unrelated recipes keep their file-glob order, and
 * cross-rank dependencies are handled by the coarse rank — within-rank
 * topology only matters when two recipes of the same kind reference each
 * other (e.g. a component-template referencing a content-template at
 * rank 0).
 */
export declare const stableTopologicalSortWithinRanks: (recipes: readonly Recipe[]) => readonly Recipe[];