/**
 * The composition-root impl of the two flag-on `createProjectFrontDoor` seams
 * (`dispatch-create-by-engine` `CreateFrontDoorDeps`). These live outside the
 * pure orchestrator so it stays injectable and I/O-free: `FxCore` wires these
 * real handlers, the orchestrator's tests wire fakes.
 *
 * - `scaffoldV4`     — the `engine: "v4"` hand-off: build a v3 `GeneratorContext`
 *                      over the create floor and render the authored declarative
 *                      package through the v4 distribution channel.
 * - `applyV3PreFill` — the `engine: "v3"` adapter: translate the Q1 dimension
 *                      picks the v4 selector collected onto the v3
 *                      `QuestionNames.*` so `createProject`'s `QuestionMW` skips
 *                      Q1 and asks only Q2 (dispatch-create-by-engine INV-5).
 */
import { CreateProjectResult, FxError, Inputs, Result, UserInteraction } from "@microsoft/teamsfx-api";
import { ResolvedV4ChannelPackage, scaffoldDeclarativeFromV4Channel } from "../component/generator/v4TemplateBridge";
import { Answers, BuildTarget } from "../v4";
/**
 * The one module function `scaffoldV4` hands the located package to, behind the
 * repo's `*Deps` seam so a test can stub the channel render without I/O (the v4
 * named export is otherwise a read-only binding).
 */
export declare const scaffoldV4Deps: {
    scaffoldDeclarativeFromV4Channel: typeof scaffoldDeclarativeFromV4Channel;
};
/**
 * The `engine: "v4"` hand-off. The orchestrator has already collected the
 * package's own answers (Q2, via `runCreateInputs`); this validates the create
 * floor (`folder` / `app-name`), then renders the located `create/<templateId>`
 * declarative package onto disk via the v4 distribution channel.
 *
 * Mirrors the legacy customized-generator validation and tracking-id tail so a
 * v4 scaffold yields the same `CreateProjectResult` shape as every other create path.
 */
export declare function scaffoldV4(inputs: Inputs, target: BuildTarget, answers: Answers, flagReader?: (name: string) => boolean, resolvedPackage?: ResolvedV4ChannelPackage): Promise<Result<CreateProjectResult, FxError>>;
/**
 * The `engine: "v4"` create-floor collection. The front door owns Q1/Q2, so the
 * remaining surface floor is collected directly here instead of routing through
 * any legacy question-tree traversal.
 */
export declare function collectCreateFloor(inputs: Inputs, ui: UserInteraction): Promise<Result<undefined, FxError>>;
/**
 * The `engine: "v3"` adapter (dispatch-create-by-engine INV-5). Translate the Q1
 * dimension picks the v4 selector collected (`target.answers`) onto the v3
 * `QuestionNames.*` so `createProject`'s `QuestionMW` skips Q1 and asks only Q2.
 *
 * It does **not** set `QuestionNames.TemplateName`: a preset single-select answer
 * still fires its `onDidSelection` during the v3 walk (`questionVisitor`), and
 * the deepest preset dimension's callback sets `TemplateName` to the route's
 * `templateId` — while `traverse`'s `TemplateName` short-circuit (checked only at
 * entry) does not fire, so the non-preset Q2 (app name / language / folder) is
 * still asked.
 *
 * Each `projectType` family translates its selector dimension ids onto the v3
 * `QuestionNames.*` (the ids diverge per family; the maps above own each rename).
 * `graph-connector-type` carries no capability dimension (its v3 node is a group),
 * so it pre-fills `ProjectType` only and the v3 walk asks its Q2 group. Setting
 * only `ProjectType` for any not-yet-expanded dimension is safe: the v3 walk
 * re-asks the un-preset dimensions rather than mis-scaffolding.
 */
export declare function applyV3PreFill(inputs: Inputs, target: BuildTarget): void;
//# sourceMappingURL=createFrontDoorAdapters.d.ts.map