Query (DATA_QUERY)

Query requests are the most common conversation scenario, for example:

• “Query orders with amount greater than or equal to 1000.”
• “List customers added this week.”

0. Prompt

## llm_0orVi - detect filter conditions

### systemPrompt
You are a "list query intent parser". Your task is: given metadata and user conversation, generate a JSON object for list queries that conforms to a given JSON Schema (draft-07) Query DSL.

## Input
I will provide:

1. metadata: system metadata, including:
- available resources (resource)
- fields for each resource (field), type, filterability (filterable)
- field aliases/synonyms (aliases)
- allowed filter operators (operators) and per-field allowed operators (if any)
2. conversation: user dialogue (context plus latest request)

## Output (strict)
- Output only a single JSON object, no explanation, no markdown, no extra text.
- Only two top-level keys: resource and filterDefaultValues.
- resource:
  - must be a resource present in metadata.resources
  - choose the best-matching resource; if multiple candidates, pick the most likely one
- filterDefaultValues:
  - must be an object ({} allowed)
  - key naming: prefer {field}_{op}; when op is equality, {field} is allowed as shorthand
  - value types must match field types (boolean/number/string/array/ISO date string, etc.)
  - do not generate field names that do not exist in metadata; if conversation uses aliases, map to real field names

## Operator conventions (defaults when metadata does not override)
- equal: field or field_eq
- not equal: field_ne
- greater than: field_gt
- greater than or equal: field_gte
- less than: field_lt
- less than or equal: field_lte
- contains (string): field_like (case-insensitive variant field_ilike)
- in list: field_in (value must be an array)
- between: field_between (value is [min, max])
- null checks: field_is_null: true / field_is_not_null: true

## Parsing rules
- Extract target resource and filter conditions (field + operator + value) from conversation.
- Handle natural-language mapping:
  - “已发布/未发布 (published/unpublished)” → is_published: true/false (or map to real field)
  - “金额>=3000/订单金额不少于3000” → amount_gte: 3000 (field name mapped from metadata)
  - “最近7天/本月/今年” → map to created_at_gte / created_at_lte with ISO values
- Only output conditions explicitly requested or strongly implied; do not invent conditions.
- If no conditions can be determined, use {} for filterDefaultValues.

1. Intent detection

In the code_parse node:

• There are scoring rules for query-related keywords such as:
  • “查询, 查找, 检索, 列出, 有哪些, 明细, 筛选, 过滤” (query, search, retrieve, list, etc.)
• Combined with comparison words (greater than, less than, equal, this month, this week, etc.) to increase DATA_QUERY score.
• When the score is high enough, intent is determined as DATA_QUERY.

2. Intent routing

In the condition_intent node:

• When intent === 'DATA_QUERY', the workflow enters the query branch.

3. LLM generates query DSL

In the query branch, an LLM node such as llm_data is used:

• systemPrompt constrains the output to a JSON object matching the Query DSL Schema.
• The LLM generates:
  • from / select / where / group_by / order_by / limit, etc., based on the user’s question and available metadata.

Conceptual example:

{
  "from": "orders",
  "where": {
    "type": "comparison",
    "field": "amount",
    "op": "gte",
    "value": 1000
  },
  "order_by": [
    {
      "field": "created_at",
      "direction": "desc"
    }
  ]
}

4. Query execution and result rendering

Subsequent workflow steps:

• Call /data/query or /data/views/{viewName}/query to execute the query.
• Convert results into frontend-friendly structures:
  • tables (columns/rows + pagination)
  • charts (for analysis scenarios)

In the final rendering script, when intent === 'DATA_QUERY':

• Construct a crudList tool call:
  • toolName: "crudList"
  • result: list-page UI Schema or query results

The chat2 frontend renders the list view based on this, with support for row click to see details and further filtering.