Interface INull

API documentation for the property.

This is the standard OpenAPI description field that will be displayed in Swagger UI, SDK documentation, and other API documentation tools. Focus on explaining the property from an API consumer's perspective.

Content Guidelines

• WHAT: What this property represents in the business domain
• WHY: Why this property exists and when it's used
• Constraints: Validation rules, value ranges, or format requirements visible to API consumers
• Relationships: If referencing another entity, explain the semantic relationship

For Nullability Mismatch (DB non-null → DTO nullable/optional)

When the database column is non-null but the DTO property is nullable or optional, briefly explain why:

• "Optional - defaults to 'user' if not provided."
• "Optional - server generates UUID if not provided."
• "Optional for update operations."

Format Requirements

• MUST be written in English
• Should be organized into multiple paragraphs for complex properties
• Use clear, precise language accessible to API consumers
• Do NOT include implementation details (use x-autobe-specification)

Discriminator value of the type.

CRITICAL: This MUST be a SINGLE string value, NOT an array. The type field identifies the JSON Schema type and must be exactly one of: "boolean", "integer", "number", "string", "array", "object", or "null".

❌ INCORRECT: type: ["string", "null"] // This is WRONG! ✅ CORRECT: type: "string" // For nullable string, use oneOf instead

If you need to express a nullable type (e.g., string | null), you MUST use the IOneOf structure:

{
  "oneOf": [{ "type": "string" }, { "type": "null" }]
}
Copy

NEVER use array notation in the type field. The type field is a discriminator that accepts only a single string value.

Implementation specification for this property.

This is an AutoBE-internal field (not exposed in standard OpenAPI output) that provides detailed implementation guidance for downstream agents (Realize Agent, Test Agent, etc.).

Include HOW this property value should be retrieved or computed:

• Source database column or related table
• Any transformation logic between DB and DTO (e.g., type casting, formatting)
• Computation formula for derived values (e.g., price * quantity)
• Join conditions if data comes from related tables
• Validation rules enforced at the service layer
• Edge cases (nulls, defaults, empty values)

The specification must be precise enough for Realize Agent to implement the data retrieval or computation logic without ambiguity.

MUST be written in English. Never use other languages.