import { LitElement, PropertyValues } from 'lit';
import { C as ConfigContext, V as ValidationDisplayMode } from './config.context.d-BvU9r-Mg.js';
import { V as ValidatableInteraction } from './interaction.interface.d-CvjHM2bi.js';
import { g as ResponseVariable, B as BaseType } from './item.types.d-DuVR0ZVK.js';

/**
 * What a choice element should render and behave as. The same element — `qti-simple-choice`,
 * `qti-hottext` — is a radio in one interaction and a checkbox in another. It cannot know this
 * by itself.
 *
 * Note "drag" is deliberately *not* a choiceRole. In `qti-match-interaction` the same element
 * type is a drag in one match-set and a drop target in the other, so draggability is positional,
 * not a property of the interaction. It is derived from `draggablesSelector` instead. It is also
 * not a valid ARIA role, so it may only ever be a custom state.
 */
type ChoiceRole = 'radio' | 'checkbox';
/**
 * State an interaction publishes to the choice elements inside it.
 *
 * Provided by the `qti-*-interaction`, never by `qti-assessment-item`: interactions must work
 * standalone — in a plain form, in a story, in a vendor's app — with no QTI ancestor. Consumers
 * must therefore tolerate its absence and fall back to a sensible default:
 *
 *   const role = this.interactionContext?.choiceRole ?? null;
 */
interface InteractionContext {
    /** `null` when the interaction assigns no particular role to its choices. */
    choiceRole: ChoiceRole | null;
    /**
     * The selector this interaction uses to recognise its draggable chips. An element tests
     * itself with `this.matches(draggablesSelector)` and takes `:state(chip)` if it matches.
     *
     * Published rather than pushed because draggability can be positional: match-interaction's
     * selector distinguishes the source match-set from the target one, so two elements of the
     * same tag get different answers.
     */
    draggablesSelector: string | null;
}
declare const interactionContext: {
    __context__: Readonly<InteractionContext>;
};

/**
 * Shared QTI interaction base. Formative correction behavior is supplied by the
 * `@qti-components/corrections` package.
 */
declare abstract class Interaction extends LitElement implements ValidatableInteraction {
    #private;
    private get _context();
    /**
     * Delivery configuration, from the nearest provider — `qti-test` or `qti-item`.
     *
     * **Public so it can be assigned directly, which is the development-time route.** An interaction
     * has to work standalone, and in a story or a spec there is usually no provider above it — so
     * setting the field is all that is needed:
     *
     *     orderInteraction.configContext = { allowReorder: false, validationDisplayMode: 'none' };
     *
     * With no provider, nothing ever overwrites it. That is the whole contract, and its limit: where a
     * provider DOES exist it re-emits on its next update and wins, because `@consume` writes this same
     * field. There is no merging — set the value on the provider in that case.
     *
     * In a lit-html template, bind it as a property rather than assigning after the fact:
     *
     *     html`<qti-order-interaction .configContext=${{ allowReorder: false }}>…`
     *
     * The binding is committed on the detached template clone, before the fragment is inserted, so it
     * is in place by `connectedCallback` — which matters for anything that reads config on connect.
     *
     * It was `protected`, which fooled nobody: every caller reached it anyway through an
     * `as any` / `as { configContext?: … }` cast. Public says what was already true and removes the
     * casts, rather than pretending at an encapsulation the type system was the only thing enforcing.
     */
    configContext: ConfigContext;
    protected _interactionContext: Readonly<InteractionContext>;
    static formAssociated: boolean;
    protected _internals: ElementInternals;
    get internals(): ElementInternals;
    responseIdentifier: string;
    disabled: boolean;
    readonly: boolean;
    name: any;
    /** Extension point used by wrappers that should not register as candidate inputs. */
    protected get registersWithItem(): boolean;
    get isInline(): boolean;
    get responseVariable(): ResponseVariable | undefined;
    abstract validate(): boolean;
    get value(): string | null;
    set value(val: string | null);
    abstract get response(): string | string[] | null;
    abstract set response(val: string | string[] | null);
    reportValidity(): boolean;
    protected get validationDisplayMode(): ValidationDisplayMode;
    protected resolveAllowReorder(options?: {
        defaultWhenUnset?: boolean;
    }): boolean;
    protected resolveDisableAfterMaxReached(options?: {
        defaultWhenUnset?: boolean;
    }): boolean;
    protected setInteractionValidity(isValid: boolean, validityMessage?: string, anchor?: HTMLElement | null, options?: {
        suppressInline?: boolean;
    }): void;
    protected updateInlineValidationMessage(): void;
    protected clearInlineValidationMessage(): void;
    protected getValidationMessageElement(): HTMLElement | null;
    reset(): void;
    formResetCallback(): void;
    connectedCallback(): void;
    saveResponse(value: string | string[], state?: string | null): void;
    constructor();
    /**
     * Optional lifecycle bridge for interaction subclasses that do not need changed-property data.
     *
     * The parameter is `PropertyValues`, matching LitElement, and NOT `PropertyValues<this>`.
     * The polymorphic `this` narrowed the parameter per subclass, which made every interaction
     * class structurally incompatible with `LitElement` — so `Constructor<LitElement>`, the
     * standard constraint for a Lit mixin, rejected all of them and consumers could not wrap an
     * interaction in a mixin without casting. `this` buys nothing in a parameter position and
     * costs contravariant compatibility with the base class.
     *
     * Still optional, so subclasses that ignore the argument can override with `firstUpdated()`.
     */
    protected firstUpdated(_changedProperties?: PropertyValues): void;
}

/**
 * The value of a variable with `record` cardinality: its fields by field identifier.
 *
 * Field values are kept the way every other response value is kept, as QTI string literals — a
 * float is `"4.12"`, a point is `"455 250"` — with a list-valued field as an array of them.
 */
type RecordValue = Record<string, string | string[] | null>;
/** A record's field values with the base type each `qti-value` declared for its field. */
interface RecordFieldValues {
    value: RecordValue;
    baseTypes: Record<string, BaseType>;
}
/** Whether a variable value is a record: a plain object, not a list and not NULL. */
declare const isRecordValue: (value: unknown) => value is RecordValue;
/**
 * Reads the field values of a record out of `qti-value field-identifier="…" base-type="…"`
 * elements, as found in a `qti-correct-response` or `qti-default-value` of a record declaration.
 *
 * A value without a `field-identifier` is not a record field and is skipped. A field without a
 * `base-type` gets no entry in `baseTypes`, so a reader can tell "declared string" from "unknown".
 */
declare const readRecordFieldValues: (valueElements: Iterable<Element>) => RecordFieldValues;
/**
 * A best guess at a record field's base type, for when the declaration does not say.
 *
 * A record field value carries no type of its own once it is stored, and a record response
 * declaration has no `base-type`, so this is the fallback. A number is a float (or an integer
 * when given as a whole JS number), two numbers separated by whitespace are a point, and
 * anything else is a string.
 */
declare const inferRecordFieldBaseType: (value: unknown) => BaseType;

export { type ChoiceRole as C, Interaction as I, type RecordFieldValues as R, type InteractionContext as a, type RecordValue as b, interactionContext as c, isRecordValue as d, inferRecordFieldBaseType as i, readRecordFieldValues as r };