Use semantic, unambiguous names for every externally visible identifier (API parameters/endpoints, config/env vars, and build/version tags). Names must reflect meaning and supported behavior; if an operation is not supported, document that constraint next to the relevant field/behavior.

Application rules:

• API naming: prefer consistent, descriptive snake_case names for parameters (e.g., parent_id, file_ids, page_size, orderby, desc) and keep them aligned with the actual request/response contract.
• API constraints: when behavior is restricted, state it explicitly (e.g., “Changing file extensions is not supported.”) so users don’t infer unsupported semantics from the parameter/field naming.
• Build/release naming: standardize version tag labels so stability and feature set are obvious.
  • Use vX.Y.Z for stable releases.
  • Use vX.Y.Z-slim for stable “slim” variants.
  • Use dev (not ambiguous labels like dev1) for development images.
  • Use nightly for nightly builds.

Example (Docker tag standard):

RAGFLOW_IMAGE=infiniflow/ragflow:v0.14.1
RAGFLOW_IMAGE=infiniflow/ragflow:v0.14.1-slim
RAGFLOW_IMAGE=infiniflow/ragflow:dev
RAGFLOW_IMAGE=infiniflow/ragflow:nightly

Example (API constraint wording):

POST /api/v1/file/rename
Body: { "file_id": "...", "name": "new_name.txt" }
Note: Changing file extensions is not supported.