@qingflow-tech/qingflow-app-user-mcp 1.0.0

package/skills/qingflow-app-user/references/record-patterns.md

@@ -0,0 +1,48 @@
+# Record Patterns
+
+If the task shifts into grouped analysis, ratio, ranking, trend, or any final statistical conclusion, switch to [$qingflow-record-analysis](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-analysis/SKILL.md).
+
+## Browse Pattern
+
+Use `record_browse_schema_get -> record_list` when:
+
+- the user wants to browse records
+- the target `record_id` is unknown
+- a delete target still needs confirmation
+- the user needs sample rows or a small export
+
+## Detail Pattern
+
+Use `record_browse_schema_get -> record_get` when:
+
+- the exact `record_id` is known
+- the user needs one record in detail
+- a write target needs verification before action
+
+## Insert Pattern
+
+Use `record_insert_schema_get -> record_insert`.
+
+1. Confirm the target app
+2. Read `required_fields`, `optional_fields`, `runtime_linked_required_fields`, and `payload_template`
+3. Build a field-title keyed `fields` map
+4. If lookup fields are ambiguous, stop and ask for confirmation
+5. Run `record_insert`
+
+## Update Pattern
+
+Use `record_update_schema_get -> record_update`.
+
+1. Confirm the target app and `record_id`
+2. Read `writable_fields` and `payload_template`
+3. Update only fields present in `writable_fields`
+4. Let MCP auto-select the first matched accessible view that can execute the payload
+5. Run `record_update`
+
+## Delete Pattern
+
+Use `record_list / record_get -> record_delete`.
+
+1. Confirm the exact `record_id`
+2. Run `record_delete`
+3. Do not invent range deletes from guessed browse results

package/skills/qingflow-app-user/references/workflow-usage.md

@@ -0,0 +1,26 @@
+# Workflow and Task Usage Actions
+
+Use these when the user is operating inside an existing process, not redesigning it.
+
+Examples:
+
+- add a comment to a record
+- approve or reject a workflow task
+- transfer a task
+- roll back a task
+- list todo, initiated, done, or cc tasks
+- inspect workload by worksheet or workflow node
+- urge a pending task
+
+Rules:
+
+- if the user starts from inbox, todo, workload, cc, or bottleneck language, use `task_*` first
+- use `task_summary` for headline counts
+- use `task_list` for flat browsing
+- use `task_facets` when worksheet or workflow-node buckets matter
+- treat task counts as task-center counts, not record counts
+- switch to `record_*` only after locating the exact business record behind a task
+- identify the exact target first
+- for approve or reject, identify the exact `workflow_node_id` first; prefer task-center results or current audit info, then use `task_approve` or `task_reject`
+- avoid usage-side workflow actions on ambiguous records
+- summarize the final action and target task ids or record ids

package/skills/qingflow-record-analysis/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: qingflow-record-analysis
+description: Analyze Qingflow record data safely after the MCP is already connected and authenticated. Use when the user wants grouped distributions, ratios, averages, rankings, trends, insights, or any final statistical conclusion across an existing app's data. Do not use this skill for schema changes, app design, or ordinary record CRUD unless they are strictly supporting an analysis flow.
+metadata:
+  short-description: Analyze Qingflow record data with schema-first DSL execution
+---
+
+# Qingflow Record Analysis
+
+This skill is for final statistical conclusions only.
+Assumes MCP is connected, authenticated, and on the correct workspace.
+Analysis tasks must start with `app_get`, then `record_browse_schema_get(view_id=...)`. Read top-level `fields` and `suggested_*`, then build field_id-based DSLs only.
+Analysis tasks must start with `record_browse_schema_get`.
+If `app_get.accessible_views` marks a view with `analysis_supported=false`, do not use that view for `record_list` or `record_analyze`. `boardView` and `ganttView` are special UI views, not list/analyze targets.
+
+## Step 1: `app_get` → Step 2: `record_browse_schema_get(view_id=...)` → Step 3: build DSL → Step 4: `record_analyze`
+
+This is the ONLY execution order. Never skip `app_get` when the browse range is unclear. Never call `record_analyze` without a browse schema.
+
+Core tools: `app_get`, `record_browse_schema_get`, `record_analyze`. Use `record_list`/`record_get` only for post-analysis samples; task/comment work stays in [$qingflow-task-ops](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-task-ops/SKILL.md).
+
+---
+
+## DSL Contract
+
+### DSL FORMAT (CRITICAL — read this FIRST)
+
+### ✅ Correct vs ❌ Wrong — learn from these before building ANY DSL
+
+**dimension item:**
+```
+✅ CORRECT:  { "field_id": 9500572, "alias": "报价类型" }
+❌ WRONG:    9500572                          ← bare integer, not a dict
+❌ WRONG:    "报价类型"                        ← string, not a dict
+❌ WRONG:    { "field_id": 9500572, "title": "报价类型" }  ← "title" is forbidden
+```
+
+**metric item — the key is `op`, NOT `type`/`agg`/`aggregation`:**
+```
+✅ CORRECT:  { "op": "count", "alias": "记录数" }
+✅ CORRECT:  { "op": "sum", "field_id": 7, "alias": "总金额" }
+❌ WRONG:    { "type": "count" }               ← "type" is NOT a valid key
+❌ WRONG:    { "agg": "count" }                ← "agg" is NOT a valid key
+❌ WRONG:    { "aggregation": "count" }         ← "aggregation" is NOT a valid key
+```
+
+**filter item — the key is `op`, NOT `operator`:**
+```
+✅ CORRECT:  { "field_id": 2, "op": "between", "value": ["2024-03-01", "2024-03-31"] }
+✅ CORRECT:  { "field_id": 5, "op": "eq", "value": "已完成" }
+❌ WRONG:    { "field_id": 2, "operator": "between", "value": [...] }  ← "operator" is forbidden
+❌ WRONG:    { "field_id": 2, "op": ">=", "value": "2024-03-01" }      ← ">=" is not valid, use "gte"
+```
+
+**sort item:**
+```
+✅ CORRECT:  { "by": "记录数", "order": "desc" }     ← "by" references an alias
+❌ WRONG:    { "by": 9500572, "order": "desc" }       ← field_id not allowed in sort
+```
+
+### Allowed keys per item (ANY other key = error)
+
+| Item | Allowed keys only |
+|------|-------------------|
+| dimension | `field_id`, `alias`, `bucket` |
+| metric | `op`, `field_id`, `alias` |
+| filter | `field_id`, `op`, `value` |
+| sort | `by`, `order` |
+
+### `op` values
+
+- metrics: `count`, `sum`, `avg`, `min`, `max`, `distinct_count`
+- filters: `eq`, `neq`, `in`, `not_in`, `gt`, `gte`, `lt`, `lte`, `between`, `contains`, `is_null`, `not_null`
+- For `count` metric: do NOT pass `field_id`. For all others: `field_id` is required.
+- If `metrics` is omitted or `[]`, defaults to `[{"op":"count","alias":"记录数"}]`.
+
+---
+
+See [references/dsl-templates.md](references/dsl-templates.md) for complete copy-paste templates.
+
+**Typical summary / distribution:**
+```json
+{
+  "dimensions": [{ "field_id": FIELD_ID_FROM_SCHEMA, "alias": "维度名" }],
+  "metrics": [{ "op": "count", "alias": "记录数" }],
+  "sort": [{ "by": "记录数", "order": "desc" }],
+  "limit": 50,
+  "strict_full": true
+}
+```
+
+**Typical time-filter / trend:**
+```json
+{
+  "dimensions": [{ "field_id": TIME_FIELD_ID, "alias": "月份", "bucket": "month" }],
+  "metrics": [{ "op": "count", "alias": "记录数" }],
+  "filters": [{ "field_id": TIME_FIELD_ID, "op": "between", "value": ["2024-03-01", "2024-03-31"] }],
+  "sort": [{ "by": "月份", "order": "asc" }],
+  "limit": 24,
+  "strict_full": true
+}
+```
+
+Top-level arguments:
+
+- `app_key`: required.
+- `dimensions`: `[]` = whole-table summary; `[{...}]` = grouped.
+- `strict_full`: `true` for final conclusions. `false` allows partial results.
+- `limit`: limits returned rows only, not scan scope.
+- `view_id`: the canonical browse selector. Prefer choosing it from `app_get.accessible_views`.
+- Prefer `view_id` entries where `analysis_supported=true`. If a view is `boardView` or `ganttView`, switch to a system or table-style custom view before calling `record_analyze`.
+- If a chosen `view_id` is `custom:*`, treat the output as analysis over an unverified saved-filter scope unless `verification.view_filter_verified=true`. For critical conclusions, prefer `system:all` plus explicit filters in the DSL.
+- `bucket` in dimensions: only for `suggested_time_fields`. Values: `day`/`week`/`month`/`quarter`/`year`/`null`.
+
+---
+
+## RULES
+
+- 渗透率 / 转化率 / 占比类结论必须先定义分子和分母。
+- Do not claim a metric you did not query.
+- Derived ratios must be computed outside the DSL.
+- Before choosing a DSL shape, first decide whether the question needs `count`, `sum`, `avg`, `distinct_count`, `ratio`, or `ranking`.
+- Rankings must come from structured sorted results.
+- For partial answers, explicitly disclose which parts are complete and which parts remain unresolved.
+- Complex answers should default to `先结构、后解读`.
+- `between`: pass a two-item array.
+- Sort entries must reference an alias already defined in `dimensions` or `metrics`.
+- Final wording should stay as close as possible to schema titles.
+- Do not pass field titles, aliases, or guessed ids.
+- If `completeness.statement_scope=returned_groups_only` or `completeness.rows_truncated=true`, downgrade wording to returned groups only.
+- One DSL per question. Multiple small DSLs > one overloaded request.
+- `record_list` is NEVER the basis for final statistics.
+- Set `alias` for any metric you will sort by, compare, or quote.
+
+---
+
+## OUTPUT
+
+- Final answer must show concrete numbers.
+- If `result.rows` exists, list each returned row; if there are more than 20 rows, show Top 20 and say so.
+- 占比 = 行指标值 / `result.totals.metric_totals` 总值；如 `metric_totals` 缺失，用各行之和作分母。
+- Prefer the structured `ranking` block when it exists.
+- `safe_for_final_conclusion=true` → `全量可信结论`
+- Otherwise → `初步观察`
+- `rows_truncated=true` → 用 `前 N 个分组`, 不用 `全部`/`所有`
+
+## Feedback Escalation
+
+- If the desired analysis still cannot be completed because of missing capability, unsupported analysis shape, or an obviously awkward workflow after reasonable attempts, summarize the exact gap.
+- Ask whether the user wants you to submit product feedback.
+- Only after explicit user confirmation, call `feedback_submit`.
+
+## Resources
+
+- DSL templates: [references/dsl-templates.md](references/dsl-templates.md)
+- Analysis patterns: [references/analysis-patterns.md](references/analysis-patterns.md)
+- Confidence reporting: [references/confidence-reporting.md](references/confidence-reporting.md)
+- Analysis gotchas: [references/analysis-gotchas.md](references/analysis-gotchas.md)

package/skills/qingflow-record-analysis/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Qingflow Record Analysis"
+  short_description: "Analyze Qingflow record data with schema-first DSL execution"
+  default_prompt: "Use $qingflow-record-analysis for grouped distributions, ratios, rankings, trends, and final statistical conclusions in Qingflow apps. Start with record_browse_schema_get, build one or more field_id-based DSLs, then run record_analyze. Treat record_list as sample-only when capped or paged, and separate full conclusions from sample observations."

package/skills/qingflow-record-analysis/references/analysis-gotchas.md

@@ -0,0 +1,145 @@
+# Analysis Gotchas
+
+## Do not skip schema
+
+If the task is analysis-style and you jump straight to `record_list` or `record_analyze`, you are already off the stable path.
+
+Correct recovery:
+
+1. `record_browse_schema_get`
+2. inspect the schema and choose fields
+3. build one or more small DSLs
+4. run `record_analyze`
+
+The schema here is applicant-node visible-only. If a field is absent, treat it as not available to the current user rather than switching to guessed ids or builder-side memory.
+
+## Normalize relative time phrases before building the DSL.
+
+Examples:
+
+- `最近一个完整自然月` -> convert to an explicit full-month date range
+- `上个月` -> convert to a concrete month range
+- `最近30天` -> convert to exact start/end dates
+
+Do not pass vague time phrases or impossible dates into MCP.
+
+## Do not treat 200-row list output as full data
+
+`record_list` can hit:
+
+- `row_cap=200`
+- `row_cap_hit=true`
+- `sample_only=true`
+
+When this happens, it is sample-only evidence.
+
+It is not acceptable to use that result alone for:
+
+- 平均值
+- 占比
+- 排名
+- 趋势
+- 地域分布
+- “基于全部数据”的 business insight
+
+## Do not mix full analyze totals with sample rows
+
+If `record_analyze` gives full-population coverage, but list rows are capped, do not merge them into one final statement.
+
+Split them into:
+
+- `全量可信结论`
+- `样本观察`
+
+## Do not present truncated grouped rows as a full grouped list
+
+If `completeness.rows_truncated=true` or `completeness.statement_scope=returned_groups_only`:
+
+- do not say `各部门`
+- do not say `所有分组`
+- do not say `完整名单`
+
+Correct recovery:
+
+- do not describe the answer as complete grouped coverage
+- keep the wording inside the returned group scope
+
+## Do not guess fields under ambiguity
+
+If the field is uncertain:
+
+- do not bounce across tools
+- do not guess ids
+- do not switch from one read tool to another by trial and error
+- do not keep retrying different guessed field names in a loop
+
+Correct recovery:
+
+1. `record_browse_schema_get`
+2. if several plausible candidates remain, ask the user to confirm from a short list
+3. build the DSL only after the field is clear
+
+If the intended field is absent from the schema altogether, stop and explain that it is not visible in the current applicant-node permission scope.
+
+Examples of the right recovery question:
+
+- “我找到两个可能的字段：`线索来源`、`来源渠道`。你要按哪个字段统计？”
+- “目前最像‘来源’的字段有这三个：`来源`、`来源渠道`、`获客来源`。请确认你要按哪个字段分析。”
+
+## Do not try to control paging manually
+
+`record_analyze` hides paging and scan budget on purpose.
+
+- Do not invent `page_size`
+- Do not invent `requested_pages`
+- Do not invent `scan_max_pages`
+- Do not invent `auto_expand_pages`
+
+When the result is incomplete:
+
+1. narrow the scope with views or filters
+2. reduce the analysis problem into smaller DSLs
+3. keep the answer at `初步观察` or `部分结果` if completeness is still not enough
+
+## Do not guess metric semantics from loose business wording
+
+Before building the DSL, first decide whether the question needs:
+
+- `count`
+- `sum`
+- `avg`
+- `distinct_count`
+- a ratio with numerator + denominator
+- a sorted ranking result
+
+Do not jump straight from words like `数量`, `人数`, `单量`, or `金额` to one assumed metric.
+
+## Do not hide partial completion
+
+If the user asked for several outputs and only part of them is stable:
+
+- say which parts are complete
+- say which parts are still unresolved
+- do not present the answer as fully finished
+
+## Do not send unsupported formula or div-style metrics into `record_analyze`.
+
+Examples to avoid:
+
+- `{"op":"div", ...}`
+- metric items with `formula`, `expr`, `numerator`, or `denominator`
+
+Correct recovery:
+
+1. query the source metrics with separate DSLs
+2. confirm both sides are complete and compatible
+3. compute the derived ratio outside MCP in the reasoning layer
+
+## Do not call something a ratio without the denominator
+
+If the user asks for penetration / conversion / 占比:
+
+1. define numerator
+2. define denominator
+3. query both sides explicitly
+4. only then compute and report the ratio

package/skills/qingflow-record-analysis/references/analysis-patterns.md

@@ -0,0 +1,125 @@
+# Analysis Patterns
+
+## When to use this skill
+
+Use this skill when the user asks for:
+
+- 分布
+- 占比
+- 平均值
+- 排名 / top-N
+- 趋势
+- 洞察
+- 最终统计结论
+- 全量范围内的 business summary
+
+## Canonical analysis sequence
+
+1. `record_browse_schema_get`
+2. decide whether the question needs `count`, `sum`, `avg`, `distinct_count`, `ratio`, or `ranking`
+3. build one or more field_id-based DSLs
+4. `record_analyze`
+5. `record_list` only for sample inspection
+
+Result reading order:
+
+1. `result.rows`
+2. `result.totals.metric_totals`
+3. `ranking`
+4. `ratios`
+5. `completeness`
+6. `presentation`
+
+Treat `record_browse_schema_get` as the browse-schema source of truth. Missing fields are permission boundaries, not invitations to guess hidden ids.
+
+## Distribution / ratio pattern
+
+1. Run `record_browse_schema_get`
+2. Inspect candidate fields and aliases
+3. If several plausible candidates remain, stop and ask the user to confirm the field from a short list
+4. Build a DSL with:
+   - one dimension
+   - `count`
+   - sort by the count alias
+5. Run `record_analyze`
+6. Report:
+   - `result.totals.metric_totals`
+   - `safe_for_final_conclusion`
+   - `completeness.statement_scope`
+   - `completeness.warnings`
+7. If grouped rows are truncated, describe the answer as `主要分组` or `已返回分组中`, not `各部门` or `全部`
+
+## penetration / conversion / share-of-total pattern
+
+1. Run `record_browse_schema_get`
+2. Write down the business definition in plain language:
+   - numerator
+   - denominator
+   - grouping dimension, if any
+3. Build separate DSLs when numerator and denominator are not the same filtered population
+4. Query the numerator first
+5. Query the denominator second
+6. Only compute the ratio outside MCP after both source results are complete and use compatible scopes
+7. If the denominator is missing, do not call the output `渗透率`, `转化率`, `占比`, or `%`
+
+## Average / ranking pattern
+
+1. Run `record_browse_schema_get`
+2. Choose one dimension field and one numeric metric field
+3. Build a DSL with:
+   - `dimensions=[...]`
+   - `metrics=[count,sum]` or `metrics=[count,avg,min,max]`
+4. Run `record_analyze`
+5. If the answer uses ranking language, make the ranking come from structured sorted results
+6. Prefer the structured `ranking` block when it exists instead of inferring order from loose text
+7. Use list mode only to inspect examples after the aggregate result is understood
+
+## Trend pattern
+
+1. Run `record_browse_schema_get`
+2. Choose a date/time field from `suggested_time_fields`
+3. Build a DSL with `bucket=day|week|month|quarter|year`
+4. Run `record_analyze`
+5. Treat the result as final only if `safe_for_final_conclusion=true`
+6. If the user asked for a relative time phrase such as `最近一个完整自然月`, translate it into an explicit legal date range before building the DSL
+
+## Sample inspection pattern
+
+Only use `record_list` after schema/analyze when you need:
+
+- example rows
+- spot checks
+- representative samples
+- manual inspection of records behind an aggregate bucket
+
+Never use list mode alone to justify final averages, shares, rankings, or regional distribution claims.
+
+## Statement-to-query discipline
+
+- If you want to say `单量低` or `volume low`, query `count`
+- If you want to say `金额高`, query `sum`
+- If you want to say `客单价高`, query `avg` or trusted `sum + count`
+- If you want to say `增长` or `下降`, query a time bucket
+- If you want to say `渗透率` or `占比`, query both numerator and denominator
+- If you want to say `各部门` / `全部渠道` / `完整名单`, make sure `completeness.statement_scope=full_population` and `completeness.rows_truncated=false`
+- If you want to say `Top N` or `排名`, make sure the result is explicitly sorted and the conclusion follows that returned order
+- If the task is complex, default to `先结构、后解读`
+
+## Ambiguous field recovery
+
+If the user asks for something like “来源分布” or “类型占比” and the exact field is unclear:
+
+1. run `record_browse_schema_get`
+2. inspect titles, aliases, and suggested fields
+3. if one candidate is clearly dominant, proceed
+4. if multiple candidates are still plausible, ask the user to confirm which field they want
+
+Do not keep retrying different guessed field names in a loop.
+
+## Partial completion discipline
+
+If the user asked for several conclusions and only some of them are fully supported:
+
+1. state which parts are complete
+2. state which parts are still unresolved
+3. do not present the answer as fully complete

package/skills/qingflow-record-analysis/references/confidence-reporting.md

@@ -0,0 +1,92 @@
+# Confidence Reporting
+
+## Required output structure
+
+When analysis is intended as a final answer, use this order:
+
+1. `全量可信结论`
+2. `样本观察`
+3. `待验证假设`
+
+## Full conclusion gate
+
+Only write `全量可信结论` when:
+
+- `record_browse_schema_get` was used
+- the analysis path used one or more `record_analyze` calls
+- every key analysis result has `safe_for_final_conclusion=true`
+- `safe_for_final_conclusion=true is necessary but not sufficient`
+- no key result depends on an invalid time phrase, an undefined denominator, or an unsupported derived metric
+- the result is not just a capped list sample
+
+## Sample observation gate
+
+Put evidence into `样本观察` when:
+
+- it came from `record_list`
+- the tool reports `row_cap_hit`
+- the tool reports `sample_only`
+- the result is compact/capped and not complete
+
+## Downgrade rule
+
+If `record_browse_schema_get` was not used for an analysis task, downgrade the overall framing to `初步观察` instead of `洞察` or `结论`.
+
+## Anti-mixing rule
+
+Do not combine:
+
+- full totals from `record_analyze`
+- sample-only details from `record_list`
+
+into one sentence like “基于全部数据分析...”.
+
+Instead:
+
+- full totals and distributions go into `全量可信结论`
+- illustrative rows go into `样本观察`
+
+## Semantic gate
+
+Even when `safe_for_final_conclusion=true`, do not overstate the answer if:
+
+- the metric definition is incomplete
+- the denominator was not queried
+- the conclusion mentions trend but no time bucket was queried
+- the conclusion mentions单量/volume but no `count` metric was queried
+- the conclusion depends on a derived metric the DSL cannot natively express
+- `completeness.statement_scope=returned_groups_only`
+- `completeness.rows_truncated=true`
+
+## Grouped enumeration gate
+
+If grouped rows were truncated:
+
+- do not call the grouped output `各部门`, `全部渠道`, `完整名单`, or `所有分组`
+- use `已返回分组中`, `主要分组`, or `前 N 个分组`
+- keep full-population statements only for metrics that still cover the full analyzed population
+
+## Partial completion disclosure
+
+If the user asked for multiple conclusions but only some are complete:
+
+- explicitly disclose which parts are complete
+- explicitly disclose which parts are not yet complete
+- do not collapse the answer into one all-clear conclusion
+
+## Example skeleton
+
+### 全量可信结论
+
+- `result.totals.metric_totals=...`
+- `safe_for_final_conclusion=true`
+- 这里写最终业务结论
+
+### 样本观察
+
+- 以下来自样本明细浏览，不作为最终统计结论
+- 这里写代表性样本现象
+
+### 待验证假设
+
+- 这里写还需要进一步验证的推测

package/skills/qingflow-record-analysis/references/dsl-templates.md

@@ -0,0 +1,93 @@
+# DSL Templates
+
+Use these copy-paste templates after `record_browse_schema_get`.
+
+## Whole-table summary
+
+```json
+{
+  "dimensions": [],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "strict_full": true
+}
+```
+
+## Distribution / ranking
+
+```json
+{
+  "dimensions": [
+    { "field_id": 9500572, "alias": "报价类型" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "sort": [
+    { "by": "记录数", "order": "desc" }
+  ],
+  "limit": 50,
+  "strict_full": true
+}
+```
+
+## Time-filtered distribution
+
+```json
+{
+  "app_key": "YOUR_APP_KEY",
+  "dimensions": [
+    { "field_id": 9500572, "alias": "维度名" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "filters": [
+    { "field_id": 3, "op": "between", "value": ["2024-03-01", "2024-03-31"] }
+  ],
+  "sort": [
+    { "by": "记录数", "order": "desc" }
+  ],
+  "limit": 50,
+  "strict_full": true
+}
+```
+
+## Monthly trend
+
+```json
+{
+  "dimensions": [
+    { "field_id": 3, "alias": "月份", "bucket": "month" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "sort": [
+    { "by": "月份", "order": "asc" }
+  ],
+  "limit": 24,
+  "strict_full": true
+}
+```
+
+## Cross analysis with sum
+
+```json
+{
+  "dimensions": [
+    { "field_id": 2, "alias": "状态" },
+    { "field_id": 5, "alias": "负责人" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" },
+    { "op": "sum", "field_id": 7, "alias": "总金额" }
+  ],
+  "sort": [
+    { "by": "记录数", "order": "desc" }
+  ],
+  "limit": 100,
+  "strict_full": true
+}
+```