import type { CreateFieldMetadata, CreateIssueType } from "../../domain/write.js";
import type { CredentialPort } from "../../ports/credentials.port.js";
import type { JiraCreateMetadataPort } from "../../ports/jira-create-metadata.port.js";
/**
 * Jira Cloud REST v3 create metadata, per project and per issue type.
 *
 * The two-endpoint form, not the aggregate `createmeta?expand=` one: the
 * aggregate endpoint is deprecated on Jira Cloud and returns every issue type's
 * every field in one document, which is both larger and less precise than the
 * question being asked. Planning wants one project's issue types, and then one
 * issue type's fields.
 *
 * `retry: false` throughout. These answers decide whether a create is possible
 * and what it will contain, so a retried-and-stale answer is worse than a
 * failure - the same reason `getTransitions` does not retry.
 *
 * Both mappers are defensive about shape. Jira omits fields it considers
 * irrelevant and different deployments populate different ones, so anything
 * unrecognised is dropped rather than guessed at: an entry JAM cannot read is
 * an entry JAM must not claim to have understood.
 */
export declare class JiraCloudCreateMetadataAdapter implements JiraCreateMetadataPort {
    private readonly client;
    constructor(credentials: CredentialPort, fetchImpl?: typeof fetch);
    getIssueTypes(projectKey: string): Promise<CreateIssueType[]>;
    getCreateFields(projectKey: string, issueTypeId: string): Promise<CreateFieldMetadata[]>;
}