/**
 * Closed value sets for the enum-typed metadata properties the XML builders
 * write as raw text.
 *
 * Why this exists: the D365FO deserializer DROPS an element whose value is not a
 * member of the target enum — it does not fail. So `entityCategory:"Masters"`,
 * `cardinality:"OneToMany"` or `contextType:"Role"` were written verbatim, the
 * build stayed green, and the property silently took its default. Nothing
 * anywhere reported it. Validating here turns that into a refusal before a byte
 * is written.
 *
 * Every set below is the metamodel's own, read by reflection over
 * Microsoft.Dynamics.AX.Metadata[.Core].dll in PackagesLocalDirectory\bin — not
 * transcribed from documentation. Two of them contradicted what this repo had
 * been documenting: EntityCategory's member is `Parameters` (not `Parameter`)
 * and it also has `Configuration`.
 */
/** Microsoft.Dynamics.AX.Metadata.Core.MetaModel.EntityCategory */
export declare const ENTITY_CATEGORIES: readonly ['Master', 'Configuration', 'Transaction', 'Reference', 'Document', 'Parameters'];
/** Microsoft.Dynamics.AX.Metadata.Core.MetaModel.Cardinality (relation, local side) */
export declare const RELATION_CARDINALITIES: readonly ['NotSpecified', 'ZeroOne', 'ExactlyOne', 'ZeroMore', 'OneMore'];
/** Microsoft.Dynamics.AX.Metadata.Core.MetaModel.RelatedTableCardinality — a
 *  SMALLER set than Cardinality: the related side cannot be ZeroMore/OneMore. */
export declare const RELATED_TABLE_CARDINALITIES: readonly ['NotSpecified', 'ZeroOne', 'ExactlyOne'];
/** Microsoft.Dynamics.AX.Metadata.Core.MetaModel.RelationshipType */
export declare const RELATIONSHIP_TYPES: readonly ['NotSpecified', 'Association', 'Composition', 'Link', 'Specialization', 'Aggregation'];
/** Microsoft.Dynamics.AX.Metadata.Core.MetaModel.SecurityPolicyContextType */
export declare const SECURITY_POLICY_CONTEXT_TYPES: readonly ['ContextString', 'RoleName', 'RoleProperty'];
/** Microsoft.Dynamics.AX.Metadata.Core.MetaModel.EntryPointType — the
 *  <ObjectType> of an AxSecurityEntryPointReference. */
export declare const SECURITY_ENTRY_POINT_TYPES: readonly ['None', 'MenuItemDisplay', 'MenuItemOutput', 'MenuItemAction', 'ServiceOperation'];
/**
 * Decide `<UseEnumValue>` for an AxEnum. Explicit `<Value>` elements are ALWAYS
 * written for a member whose number is not 0.
 *
 * The rule this replaces suppressed every `<Value>` whenever the resolved mode
 * was UseEnumValue=No, on the premise that "plain 0,1,2 numbering states nothing
 * the order does not". THE PREMISE IS FALSE. An `<AxEnumValue>` with no `<Value>`
 * child is **0** — not "the next ordinal" — so a four-member ladder written that
 * way has every member equal to 0. It compiles with 0 errors, passes xppbp, and
 * looks right in a golden diff, while `enum2int()` returns 0 for every member.
 * Only the runtime oracle caught it (the 2026-08-31 capture run of
 * L3-enum-field-form-downgrade-guard: expected False, actual True, with
 * enum2int(cur) = enum2int(orig()) = 0 on a Gold row).
 *
 * Two oracles, because a claim about the compiler needs the compiler:
 *
 *   • A census of the 3,913 AxEnum files in PackagesLocalDirectory: of the 3,818
 *     with two or more members, exactly SIX omit `<Value>` everywhere, and all
 *     six are extensible. Zero non-extensible multi-member enums ship the
 *     all-zero shape. The shipped convention is the .NET one — omit the 0,
 *     spell out every other number — and 154 files pin numbers that positions
 *     would not give (AtlIntercompanyOrderType: PurchaseOrder=2, SalesOrder=1),
 *     which is only meaningful if `<Value>` is what decides.
 *   • xppc on this VM (fm-mcp, 2026-09-01), two probes in one build:
 *       - IsExtensible=true + UseEnumValue=No + explicit non-positional values
 *         → compiles clean. So `<Value>` is NOT forbidden on an extensible enum,
 *         and it does NOT "force UseEnumValue=Yes at compile time" as the
 *         knowledge entry claimed.
 *       - IsExtensible=true + UseEnumValue=Yes (the negative control)
 *         → "UseEnumValue property must be set to 'No' when the IsExtensible
 *           property is 'True'". The probe discriminates; the rule below is the
 *         half that is real.
 *
 * So there is exactly ONE contradiction left to refuse: isExtensible together
 * with useEnumValue:true, which is the combination xppc names. Explicit values
 * with either setting are written, not dropped and not refused.
 */
export declare function resolveEnumValueMode(enumName: string, properties: Record<string, any> | undefined, values: Array<{
    name?: string;
    value?: number;
}>): {
    useEnumValue: 'Yes' | 'No';
};
/**
 * Canonicalize `value` against `allowed` (case-insensitively, the way
 * Enum.TryParse(…, ignoreCase: true) does on the C# side) and throw naming the
 * whole set when it is not a member. Returns `fallback` for an absent value, so
 * a property that is optional stays optional.
 */
export declare function assertKnownEnumValue(propertyName: string, value: unknown, allowed: readonly string[], fallback: string): string;
//# sourceMappingURL=axEnumProperties.d.ts.map