import { type ServiceArtefact } from "@fjall/util";
import type { DeployCallbacks } from "../../types/callbacks.js";
import type { DeployServices } from "../serviceFactory.js";
import type { DockerBuildProducts } from "./dockerBuildHelper.js";
import type { PublishedLambdaVersion } from "../../services/infrastructure/LambdaService.js";
/**
 * Collect `ServiceArtefact[]` for a successful FULL deploy from the build
 * step's products plus a best-effort post-deploy ECS resolution (the same
 * export-name binding `deployCodeOnly` uses). Full deploys roll images via
 * CFN `<Service>ImageTag` parameters, so the live task definition is only
 * knowable by describing the services AFTER the deploy.
 *
 * Best-effort by contract: a resolution, binding or describe failure
 * degrades the artefact (ECS-resolved `serviceName` falls back to the
 * build's manifest service name; `taskDefinitionArn` stays absent) and
 * warns — it NEVER fails a deploy that already succeeded. Returns `[]` when
 * the deploy pushed no images (welcome-image seed, legacy fallback,
 * infra-only).
 *
 * `contentHashTagsByService` keys are a mix of ECS service names and Lambda
 * `image` build keys (several Lambda functions may share one key). Keys that
 * match a container-Lambda manifest entry are expanded into one artefact PER
 * ACTUAL FUNCTION NAME (there is no ECS task-definition/live-service concept
 * for them); keys naming an ECS manifest service emit an ECS artefact — and
 * a key that is both (a deliberately shared build) emits both kinds.
 */
export declare function collectFullDeployArtefacts(services: DeployServices, appName: string, build: DockerBuildProducts | undefined, callbacks: DeployCallbacks, cdkOutPath: string, publishedLambdaVersions?: Record<string, PublishedLambdaVersion>, abortSignal?: AbortSignal): Promise<ServiceArtefact[]>;