import { Page } from '@playwright/test';

/** Every packaged `.feature`, for `defineBddConfig({ features })`. */
declare const mcpFeatures: string;
/**
 * The base `defineBddConfig({ featuresRoot })` must be given, and it is NOT
 * optional decoration.
 *
 * bddgen mirrors each feature's path RELATIVE TO `featuresRoot` under
 * `outputDir`. Left unset it defaults to the config's own directory, so a
 * feature living under `node_modules/...` compiles to a path Playwright then
 * IGNORES, because its default `testIgnore` excludes `**\/node_modules/**`.
 *
 * The result is the worst kind of green: bddgen reports the features compiled,
 * Playwright collects zero specs from them, and the run passes with the whole
 * packaged suite silently absent.
 *
 * A host running SEVERAL packaged suites gives `featuresRoot` the directory they
 * all sit under, since bddgen takes exactly one — and that is safe to do,
 * because a feature outside it is a hard exit from bddgen, never a quiet
 * omission.
 */
declare const mcpFeaturesRoot: string;
/**
 * Every packaged step definition, for `defineBddConfig({ steps })`.
 *
 * COMPILED JavaScript, and that is the reason this package has a build step at
 * all while everything else it exports is raw `.ts` through the `exports` map.
 * Those entries are consumed by an application's BUNDLER, which transpiles
 * whatever it is pointed at. These are loaded by NODE — `playwright.config.ts`
 * imports this module, and bddgen imports the step files — and Node refuses to
 * strip types from anything under `node_modules`
 * (`ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING`). Playwright's own TS transform
 * does not rescue them either; it skips `node_modules` by design.
 *
 * The host's own steps glob must ALSO be listed — that is where its
 * `defineMcpConnectWorld` call lives, and playwright-bdd imports every step
 * file before any scenario runs, which is what makes the registration land in
 * time in every worker.
 */
declare const mcpSteps: string;

/**
 * The port a HOST implements to run the packaged AI-connect journeys.
 *
 * These journeys were written because the walkthrough they cover was tested
 * NOWHERE. `./react` ships the whole flow — the landing, the assistant picker,
 * the endpoint to copy, the configure and connect steps, the confirmation and
 * its re-test — and twenty test ids go with it. Not one of them appeared in
 * this package's own suite, and not one appeared in the origin host's specs
 * either: that host's `ai.e2e.ts` drives its OWN plan lock and upsell modal,
 * reaching only `ai-onboarding` and the status board on the way past.
 *
 * So the flow a store owner actually walks was covered by nothing, in either
 * repo. That is the gap the `e2e` capability exists to convert into a
 * declaration rather than an omission nobody can see.
 *
 * What stays the host's: how it signs an owner in, where it mounts the flow,
 * and which assistant its `hosts` config offers — the guides are REQUIRED
 * config (FUT-760), so the package has no assistant of its own to name.
 */
/** Facts about the host that the assertions have to name. */
interface McpConnectFixtures {
    /**
     * The id of an assistant the host offers whose guide has NO `pluginUrl`.
     *
     * The flow BRANCHES on that field: a guide carrying one gets `InstallStep`
     * (a single "open the install link" button), and a guide without one gets
     * the three-step manual path — copy the endpoint, configure, connect. These
     * journeys walk the MANUAL path, so the host has to point at a guide that
     * takes it. Naming the branch here rather than guessing keeps the scenario
     * from failing in a host whose first assistant happens to ship a plugin.
     */
    manualHostId: string;
    /** The endpoint URL that host serves, as it is rendered for copying. */
    endpointUrl: string;
}
/** What a host must be able to do for these journeys to run in it. */
interface McpConnectWorld {
    /**
     * Put the browser in a known signed-in state as somebody who may connect an
     * assistant, with the flow's progress RESET to its first run.
     *
     * The reset is load-bearing rather than hygiene: the wizard persists its step
     * through `@12-apps/onboarding`, so a scenario that advanced it would hand
     * the next one a flow resuming from the middle — and the landing step, which
     * two of these scenarios assert, would never render.
     */
    signInAsOwner(page: Page): Promise<void>;
    /** Land on the screen that mounts `AiIntegrationOnboarding`. */
    openAiIntegrationScreen(page: Page): Promise<void>;
    fixtures: McpConnectFixtures;
}
/**
 * Install the host's implementation. Call this from a module inside the host's
 * OWN steps glob — playwright-bdd imports every step file before any scenario
 * runs, so a top-level call there is registered in time, in every worker.
 */
declare function defineMcpConnectWorld(world: McpConnectWorld): void;
/**
 * The installed world, or a refusal naming the fix.
 *
 * Throws rather than returning null: a step that ran against an absent world
 * would fail on whatever it touched next, somewhere unrelated to the actual
 * mistake, which is a diagnosis nobody should have to make twice.
 */
declare function mcpConnectWorld(): McpConnectWorld;

export { type McpConnectFixtures, type McpConnectWorld, defineMcpConnectWorld, mcpConnectWorld, mcpFeatures, mcpFeaturesRoot, mcpSteps };