@josephyan/qingflow-app-user-mcp 0.2.0-beta.2 → 0.2.0-beta.21

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

@@ -0,0 +1,253 @@
+---
+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
+
+## Overview
+
+This skill is for record analysis inside existing Qingflow apps. Use it when the task is about `分析 / 洞察 / 分布 / 占比 / 平均 / 排名 / 趋势 / 所有 / 全部 / 全国 / 高价值` or any final statistical conclusion.
+
+This skill assumes the MCP is already connected and authenticated. If not, switch to `$qingflow-mcp-setup` first. If the task is about creating, updating, deleting, or approving records rather than analyzing them, switch back to `$qingflow-app-user`.
+
+Before running analysis in `prod`, confirm the intended environment and compare `request_route` with the browser route if browser parity matters.
+
+## Tool Scope
+
+Use these tools as the core analysis surface:
+
+- `record_schema_get`
+- `record_analyze`
+
+Use `record_list` or `record_get` only when you need sample rows or a specific supporting example after the main analysis path.
+
+## Hard Rules
+
+- Analysis tasks must start with `record_schema_get`
+- Build one or more small DSLs, then run `record_analyze` separately for each question
+- DSL field references must use `field_id` only
+- Normalize relative time phrases into explicit legal date ranges before building the DSL
+- If the user asks for `最近一个完整自然月 / 上个月 / 最近30天 / 本季度 / 去年同期`, first convert that phrase into concrete dates, then verify the dates are legal before calling MCP
+- Never send impossible dates such as `2026-02-29`; if the intended month is February 2026, the legal upper bound is `2026-02-28`
+- If the schema still leaves multiple plausible fields, stop and ask the user to confirm from a short candidate list instead of guessing
+- Do not keep retrying different guessed field names in a loop
+- `record_list` is never the basis for a final statistical conclusion
+- If `record_list` is capped or paged, treat it as sample-only evidence
+- Do not mix full totals from `record_analyze` with sample-only list observations as one combined `全量结论`
+- Do not manually tune paging or scan-budget parameters for analysis; `record_analyze` hides them
+- For final conclusions, prefer `strict_full=true`
+- Before choosing a DSL shape, first decide whether the question needs `count`, `sum`, `avg`, `distinct_count`, `ratio`, or `ranking`
+- Do not guess a metric just because the user said `数量`, `单量`, `人数`, or `金额`
+- If one business question depends on multiple metrics, split it into smaller structured questions and build multiple focused DSLs
+- `渗透率 / 转化率 / 占比类结论必须先定义分子和分母`
+- Do not claim a metric you did not query.
+- Derived ratios must be computed outside the DSL after trusted numerator and denominator queries complete; do not invent `div`, `formula`, or expression metrics inside `record_analyze`
+- If the requested business question requires unsupported derived math, split it into multiple DSLs and compute the final ratio only in the reasoning layer after the source metrics are confirmed
+- If the user asks for multiple conclusions and only part of them is completed reliably, explicitly disclose which parts are complete and which parts remain unresolved
+
+## Standard Operating Order
+
+For analysis:
+
+1. Confirm target app and environment
+2. Run `record_schema_get`
+3. Inspect fields, aliases, suggested dimensions, suggested metrics, and suggested time fields
+4. Generate one or more field_id-based DSLs
+5. Run `record_analyze` once per DSL
+6. Run `record_list` only if you still need sample rows, examples, or manual inspection
+7. Before answering, separate:
+   - `全量可信结论`
+   - `样本观察`
+   - `待验证假设`
+
+## Semantic Guardrails
+
+- If the user asks for penetration, conversion, share-of-total, win rate, non-standard ratio, or any `%` metric, first write down:
+  - numerator definition
+  - denominator definition
+  - whether each side needs its own DSL
+- If you cannot name the denominator from real schema fields and filters, do not use words like `渗透率`, `转化率`, `占比`, `比例`, or `%`
+- If a field is still ambiguous after `record_schema_get`, do not guess; either select one unique `field_id` from the schema or ask the user to confirm from a short candidate list
+- If a statement depends on `count`, query `count`
+- If a statement depends on total amount, query `sum`
+- If a statement depends on average level, query `avg` or derive it from trusted `sum + count`
+- If a statement depends on trend, query a time dimension with `bucket`
+- If a statement depends on a ratio that the DSL cannot express directly, run the numerator and denominator separately, then compute the ratio outside MCP only after both sides are complete and compatible
+- Rankings must come from structured sorted results, not from loose natural-language restatement
+- When grouped rows are truncated, describe them as `已返回分组中` or `主要分组`
+- If `presentation.rows_truncated=true` or `presentation.statement_scope=returned_groups_only`, do not use words like `各部门`、`所有分组`、`完整名单`、`全部渠道`
+- If grouped rows are truncated, explicitly downgrade the wording to `前 N 个分组` or `主要分组`, never `全部`
+- Complex answers should default to `先结构、后解读`: present the table / metrics / ordering first, then add concise interpretation
+- Final wording should stay as close as possible to schema titles, dimension aliases, and metric aliases; do not rename the business object or field title unless the user asked for a rewrite
+
+## DSL Contract
+
+Use `record_schema_get` as the source of truth for every DSL field reference:
+
+- Use `fields[].field_id` in `dimensions[].field_id`, `metrics[].field_id`, and `filters[].field_id`
+- Treat `suggested_dimensions`, `suggested_metrics`, and `suggested_time_fields` as hints, not as executable DSL by themselves
+- Do not pass field titles, aliases, or guessed ids where `field_id` is required
+
+The `record_analyze` call should be built from this argument shape:
+
+```json
+{
+  "app_key": "APP_1",
+  "dimensions": [],
+  "metrics": [],
+  "filters": [],
+  "sort": [],
+  "limit": 50,
+  "strict_full": true,
+  "view_key": null,
+  "view_name": null,
+  "output_profile": "normal"
+}
+```
+
+Top-level argument rules:
+
+- `app_key`: required. The target Qingflow app.
+- `dimensions`: required list. Use `[]` for whole-table summary. Use one item per grouping dimension for grouped analysis.
+- `metrics`: optional list. If omitted or empty, `record_analyze` defaults to a single `count` metric.
+- `filters`: optional list. Filters restrict the analyzed dataset before results are interpreted.
+- `sort`: optional list. Sorting applies to result rows, not raw source rows.
+- `limit`: positive integer. It only limits returned result rows; it does not reduce the internal scan scope.
+- `strict_full`: boolean. Prefer `true` for final conclusions. If `true`, incomplete scans return an error; if `false`, incomplete scans return partial results.
+- `view_key` / `view_name`: optional. Use a view to narrow scope before analysis. Prefer `view_key` when both are available.
+- `output_profile`: `normal` or `verbose`. Prefer `normal` unless you are debugging completeness or route issues.
+
+Item contracts:
+
+- `dimensions` item:
+  - shape: `{ "field_id": 2, "alias": "状态", "bucket": null }`
+  - `field_id`: required integer from `record_schema_get`
+  - `alias`: optional but recommended; if omitted, the field title becomes the alias
+  - `bucket`: optional; allowed values are `day`, `week`, `month`, `quarter`, `year`, or omitted / `null`
+  - `bucket` may only be used on fields from `suggested_time_fields`
+- `metrics` item:
+  - shape: `{ "op": "sum", "field_id": 7, "alias": "总金额" }`
+  - `op`: one of `count`, `sum`, `avg`, `min`, `max`, `distinct_count`
+  - `field_id`: required for `sum`, `avg`, `min`, `max`, `distinct_count`; do not pass it for `count`
+  - `alias`: optional but strongly recommended because `sort.by` must reference aliases
+- `filters` item:
+  - shape: `{ "field_id": 2, "op": "eq", "value": "进行中" }`
+  - `field_id`: required integer from `record_schema_get`
+  - `op`: optional; defaults to `eq`
+  - supported ops: `eq`, `neq`, `in`, `not_in`, `gt`, `gte`, `lt`, `lte`, `between`, `contains`, `is_null`, `not_null`
+  - value rules:
+    - `eq`, `neq`, `gt`, `gte`, `lt`, `lte`, `contains`: pass a single scalar value
+    - `in`, `not_in`: pass an array
+    - `between`: pass a two-item array like `[min, max]`
+    - `is_null`, `not_null`: omit `value`
+- `sort` item:
+  - shape: `{ "by": "记录数", "order": "desc" }`
+  - `by`: required and must reference an alias already defined in `dimensions` or `metrics`
+  - `order`: optional; use `asc` or `desc`; default is `asc`
+  - do not sort by raw field title or `field_id`
+
+Practical rules:
+
+- Keep one DSL focused on one question. Prefer multiple small DSLs over one overloaded request.
+- Always set explicit aliases for metrics you may sort by, compare, or quote in the final answer.
+- For trend analysis, use one time dimension with `bucket`, then sort by that time alias ascending.
+- For cross analysis, use multiple `dimensions` and a small set of metrics.
+- Do not attempt formulas, joins, having clauses, cohort analysis, or manual paging controls in this DSL.
+- Do not pass unsupported keys such as `formula`, `expr`, `numerator`, `denominator`, `left`, `right`, or `operator` inside metric items.
+
+## Minimal DSL Templates
+
+Summary:
+
+```json
+{
+  "dimensions": [],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "filters": [],
+  "sort": [],
+  "limit": 1,
+  "strict_full": true
+}
+```
+
+Single-dimension distribution:
+
+```json
+{
+  "dimensions": [
+    { "field_id": 2, "alias": "状态" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "filters": [],
+  "sort": [
+    { "by": "记录数", "order": "desc" }
+  ],
+  "limit": 50,
+  "strict_full": true
+}
+```
+
+Time trend:
+
+```json
+{
+  "dimensions": [
+    { "field_id": 3, "alias": "月份", "bucket": "month" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" }
+  ],
+  "filters": [],
+  "sort": [
+    { "by": "月份", "order": "asc" }
+  ],
+  "limit": 24,
+  "strict_full": true
+}
+```
+
+Two-dimensional cross analysis:
+
+```json
+{
+  "dimensions": [
+    { "field_id": 2, "alias": "状态" },
+    { "field_id": 5, "alias": "负责人" }
+  ],
+  "metrics": [
+    { "op": "count", "alias": "记录数" },
+    { "op": "sum", "field_id": 7, "alias": "总金额" }
+  ],
+  "filters": [],
+  "sort": [
+    { "by": "记录数", "order": "desc" }
+  ],
+  "limit": 100,
+  "strict_full": true
+}
+```
+
+## Output Gate
+
+- Only write `全量可信结论` when the supporting `record_analyze` calls report `completeness.status=complete` and `safe_for_final_conclusion=true`
+- If any key analysis call is incomplete, downgrade the answer to `初步观察` or `部分结果`
+- Treat `safe_for_final_conclusion=true` as necessary but not sufficient when the metric definition is incomplete or grouped rows are truncated
+- If `presentation.statement_scope=returned_groups_only`, you may still give full-population conclusions about totals or ratios, but not a full grouped enumeration claim
+- If aggregate-style output is full but list evidence is sample-only, split the answer into:
+  - `全量可信结论`
+  - `样本观察（不作为最终结论）`
+  - optional `待验证假设`
+
+## Resources
+
+- 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)
+- Shared environment guidance: [/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-app-user/references/environments.md](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-app-user/references/environments.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_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,141 @@
+# 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_schema_get`
+2. inspect the schema and choose fields
+3. build one or more small DSLs
+4. run `record_analyze`
+
+## 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 `presentation.rows_truncated=true` or `presentation.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_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
+
+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,113 @@
+# Analysis Patterns
+
+## When to use this skill
+
+Use this skill when the user asks for:
+
+- 分布
+- 占比
+- 平均值
+- 排名 / top-N
+- 趋势
+- 洞察
+- 最终统计结论
+- 全量范围内的 business summary
+
+## Canonical analysis sequence
+
+1. `record_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
+
+## Distribution / ratio pattern
+
+1. Run `record_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:
+   - `scanned_count`
+   - `safe_for_final_conclusion`
+   - `presentation.statement_scope`
+   - `completeness.local_filtering_applied` when it affects how the result should be framed
+7. If grouped rows are truncated, describe the answer as `主要分组` or `已返回分组中`, not `各部门` or `全部`
+
+## penetration / conversion / share-of-total pattern
+
+1. Run `record_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_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. Use list mode only to inspect examples after the aggregate result is understood
+
+## Trend pattern
+
+1. Run `record_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 `presentation.statement_scope=full_population` and `presentation.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_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_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_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
+- `presentation.statement_scope=returned_groups_only`
+- `presentation.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
+
+### 全量可信结论
+
+- `scanned_count=1134`
+- `safe_for_final_conclusion=true`
+- 这里写最终业务结论
+
+### 样本观察
+
+- 以下来自样本明细浏览，不作为最终统计结论
+- 这里写代表性样本现象
+
+### 待验证假设
+
+- 这里写还需要进一步验证的推测

package/src/qingflow_mcp/__init__.py

@@ -2,4 +2,4 @@ from __future__ import annotations
 
 __all__ = ["__version__"]
 
-__version__ = "0.2.0b2"
+__version__ = "0.2.0b21"