import type { DomainName } from "../constants.js";
/**
 * Pre-composed domain sets ("profiles") for `BOOND_MCP_PROFILE`.
 *
 * Why: `BOOND_MCP_DOMAINS` is the precise tool, but composing it means knowing
 * all 38 domain names *and* which ones a job actually needs (a recruiter needs
 * `positionings` and `actions`, not just `candidates`). With on-demand tool
 * discovery in clients, narrowing the surface is still the highest-leverage
 * knob — so it has to be usable in one env var, without a trip to TOOLS.md.
 *
 * Each profile is a job-shaped bundle, not a security tier: see
 * `docs/access-control.md`, this layer hides tools from the model, it does not
 * revoke BoondManager rights. Combine with `BOOND_MCP_READ_ONLY` /
 * `BOOND_MCP_OPERATIONS` (orthogonal axis) to bound what can be written.
 *
 * `application` is in every profile on purpose: it backs dictionary resolution
 * (state/type labels) and `current-user`, which many tools and prompts depend
 * on. `workflows` is listed wherever prompt mirrors make sense; it is not
 * strictly required (workflow tools follow their source prompt's domains, not
 * the allow-list), but keeping it explicit documents the intent and survives a
 * future change of that rule.
 *
 * There is no blanket "`resources` everywhere" rule — the rule is **per
 * profile, check the prompt count**. 8 of the 11 prompts orchestrate
 * `resources` (`synthese_equipe`, `staffing_disponible`, `fiche_consultant`,
 * `recherche_profil_competences`, …) and a prompt is cut as soon as ONE of its
 * domains is filtered out, so leaving `resources` out of `recruiting` / `sales`
 * bought ~10 fewer tools and cost most of their runbooks — the wrong trade for a
 * layer whose whole point is ergonomics. It is also what those jobs actually
 * need: a recruiter matches candidates against internal staff, a salesperson
 * staffs a deal. `finance` and `admin` deliberately do NOT include it: neither
 * has a runbook that touches `resources` (`finance`'s only prompt,
 * `factures_a_relancer`, spans `invoices` + `application`), so it would add
 * tools and no capability. When adding a profile, count the prompts it keeps —
 * not just the tools.
 */
declare const PROFILE_TABLE: {
    /** Recrutement / sourcing : viviers, positionnements, suivi d'activité. */
    readonly recruiting: readonly ["candidates", "positionings", "opportunities", "contacts", "companies", "documents", "actions", "resources", "forms", "alerts", "application", "workflows"];
    /**
     * Avant-vente / commerce : pipeline, comptes, commandes. `absences` and
     * `timesheets` are here for `recap_hebdo` (issue #260): its runbook reads the
     * team's absences and CRA in one call each, and a prompt is cut as soon as
     * one of its domains is filtered — without them the profile would keep the
     * tools and lose the runbook, the trade this file's header argues against.
     */
    readonly sales: readonly ["opportunities", "companies", "contacts", "actions", "projects", "orders", "products", "reporting", "resources", "absences", "timesheets", "invoices", "alerts", "application", "workflows"];
    /**
     * Gestion / compta : facturation client et fournisseur, encaissements.
     * `timesheets` and `deliveries` are here for `preparation_facturation`
     * (issue #259): billing starts from validated CRA and running deliveries.
     */
    readonly finance: readonly ["invoices", "payments", "orders", "purchases", "provider-invoices", "expenses", "projects", "companies", "reporting", "timesheets", "deliveries", "alerts", "application", "workflows"];
    /**
     * Delivery / staffing : missions, CRA, absences, validations. `contracts`
     * for `alertes_contrats` (issue #253): contract and probation ends are the
     * delivery manager's calendar.
     */
    readonly delivery: readonly ["projects", "deliveries", "resources", "timesheets", "absences", "planning-absences", "validations", "contracts", "inactivities", "groupments", "forms", "alerts", "application", "workflows"];
    /** Administration de l'outil : référentiels d'organisation et journaux. */
    readonly admin: readonly ["accounts", "agencies", "business-units", "poles", "roles", "logs", "webhooks", "flags", "alerts", "application"];
};
/** Profile name literals (`"recruiting" | "sales" | …`). */
export type ProfileName = keyof typeof PROFILE_TABLE;
/**
 * The profile bundles. Keyed by `string` for iteration/lookup convenience;
 * `ProfileName` above keeps the literal union available for typed callers (an
 * index signature on the exported value would erase it).
 */
export declare const PROFILES: Readonly<Record<string, readonly DomainName[]>>;
/** Canonical list of profile names, for error messages and docs. */
export declare const PROFILE_NAMES: readonly ProfileName[];
/**
 * Case-insensitive profile lookup (`Finance`, `FINANCE` → `finance`).
 *
 * `Object.hasOwn` is what makes this safe: a plain `PROFILES[name]` returns
 * `Object.prototype`'s own properties for `BOOND_MCP_PROFILE=constructor`
 * (`toString`, `valueOf`, `hasOwnProperty`, `__proto__`…) — a truthy non-array
 * that skips the caller's warn-and-ignore branch and then throws
 * `TypeError: … is not iterable` at startup, i.e. a dead server instead of the
 * documented warning.
 */
export declare function resolveProfile(name: string): readonly DomainName[] | undefined;
export {};
//# sourceMappingURL=profiles.d.ts.map