/**
 * Effective org/workspace/project ids for *rendering / data scoping*, with the
 * URL taking priority over the committed selection (BOFF-2821):
 *
 *   route path `:id`  ›  `?workspace=` / `?org=` / `?project=` query  ›  selection
 *
 * Use this in pages/components that display or fetch workspace-scoped data, so a
 * deep-linked or path-scoped route shows *its* workspace even if it differs from
 * the ambient dropdown selection. It is READ-ONLY: it never writes back to
 * ActiveContext or the auth store (that one-way rule is what keeps the URL and
 * the stores from looping — see ActiveContextProvider).
 *
 * MUST be called inside the router (so `useParams`/`useSearchParams` resolve)
 * and under an ActiveContextProvider. The route-path lookup only contributes
 * when the matched route actually declares the param (e.g. `:workspaceId`); on
 * selection-scoped routes it falls through to the query, then the selection.
 *
 * Note: the context dropdown itself should keep showing the committed selection
 * (`useActiveContext`), NOT this effective value — the two can legitimately
 * diverge when a URL id is manually overridden.
 */
export interface EffectiveContext {
    organizationId: string | null;
    workspaceId: string | null;
    projectId: string | null;
}
/**
 * Pure priority resolver (path › query › selection) — extracted so the rule can
 * be unit-tested without a router. `pathParams` are the matched route params,
 * `getQuery` reads a `?` param, `selection` is the committed ActiveContext.
 */
export declare function resolveEffectiveContext(pathParams: {
    organizationId?: string;
    workspaceId?: string;
    projectId?: string;
}, getQuery: (key: string) => string | null, selection: EffectiveContext): EffectiveContext;
export declare function useEffectiveContext(): EffectiveContext;
/** Convenience: just the effective workspace id (path › query › selection). */
export declare function useEffectiveWorkspaceId(): string | null;
//# sourceMappingURL=useEffectiveContext.d.ts.map