@qingflow-tech/qingflow-app-user-mcp 1.0.4 → 1.0.5

package/README.md

@@ -3,13 +3,13 @@
 Install:
 
 ```bash
-npm install @qingflow-tech/qingflow-app-user-mcp@1.0.4
+npm install @qingflow-tech/qingflow-app-user-mcp@1.0.5
 ```
 
 Run:
 
 ```bash
-npx -y -p @qingflow-tech/qingflow-app-user-mcp@1.0.4 qingflow-app-user-mcp
+npx -y -p @qingflow-tech/qingflow-app-user-mcp@1.0.5 qingflow-app-user-mcp
 ```
 
 Environment:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@qingflow-tech/qingflow-app-user-mcp",
-  "version": "1.0.4",
+  "version": "1.0.5",
   "description": "Operational end-user MCP for Qingflow records, tasks, comments, and directory workflows.",
   "license": "MIT",
   "type": "module",

package/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "qingflow-mcp"
-version = "1.0.4"
+version = "1.0.5"
 description = "User-authenticated MCP server for Qingflow"
 readme = "README.md"
 license = "MIT"
@@ -29,6 +29,7 @@ dependencies = [
   "openpyxl>=3.1,<4.0",
   "pydantic>=2.8,<3.0",
   "pycryptodome>=3.20,<4.0",
+  "pypdf>=5.0,<6.0",
   "python-socketio[client]>=5.11,<6.0",
 ]
 

package/skills/qingflow-app-user/SKILL.md

@@ -54,7 +54,7 @@ Route to exactly one of these specialized paths:
 - If the task involves member, department, or relation fields and the user only has natural names/titles, keep the same route; direct write now supports backend-native auto resolution and may return `needs_confirmation` with candidates instead of failing blind
 - If the task involves linked visibility, upstream/downstream field dependencies, reference-driven auto fill, or formula-driven defaulting, keep the same insert/update route and read field-level `linkage` from the schema before composing payloads
 - If the task is about subtable writes, still route to the matching insert/update skill, but shape the payload as parent subtable field -> row array; do not route users toward top-level leaf selectors
-- If the task is insert-focused and readback consistency matters, keep the same route and prefer `record_get / record_list` with `output_profile="normalized"` after the write
+- If the task is insert-focused and readback/detail context matters, keep the same route and prefer the single-record detail readback after the write; use normalized list readback only when batch row shape is needed
 - If the user sounds like an ordinary workflow assignee rather than a system operator, prefer `$qingflow-task-ops` over direct record mutation whenever both paths could fit
 - If the task is about task discovery by natural language query, still route to `$qingflow-task-ops`; `task_list --query` now uses backend search first and only falls back to local matching when backend returns zero rows
 - If the task is about grouped distributions, ratios, rankings, trends, insights, or any final statistical conclusion, switch to `$qingflow-record-analysis`
@@ -68,6 +68,7 @@ Route to exactly one of these specialized paths:
 - if the task can stay read-only, do not write or act
 - if the task involves a user-uploaded import file, do not modify the file unless the user explicitly authorizes repair or normalization
 - if the task involves record import, call `app_get` first and inspect `data.import_capability` before template download, file repair, or import start
+- if a record detail includes images or attachments, prefer the single-record detail tool's local paths: images from `media_assets.items[].local_path`, documents/tables from `file_assets.items[].local_path` and `extraction.text_path`; remote Qingflow file URLs are not stable direct-read targets
 - if the current MCP capability is unsupported, the workflow is awkward, or the user's need still cannot be satisfied after reasonable use, summarize the gap, ask whether to submit feedback, and call `feedback_submit` only after explicit user confirmation
 
 ## Shared Helper

package/skills/qingflow-app-user/references/data-gotchas.md

@@ -4,10 +4,12 @@ For final statistics, grouped distributions, rankings, trends, or insight-style
 
 ## Record Reads
 
-- `record_list` is for browsing, export, and sample inspection only
-- `record_get` is for one exact record
+- For analysis-style reads, use `record_access` through [$qingflow-record-analysis](../../qingflow-record-analysis/SKILL.md)
+- `record_list` is for browsing and sample inspection only
+- `record_get` is for one exact record and downloads readable detail-page images into `media_assets.items[].local_path` plus attachments/documents/tables into `file_assets.items[].local_path`
 - Use `record_browse_schema_get` when field titles are uncertain instead of guessing ids
 - Do not present paged browse output as if it were a grouped or full-population conclusion
+- Use `record_export_direct` only when the user explicitly asks for export/download/Excel output
 
 ## Direct Writes
 
@@ -27,3 +29,4 @@ For final statistics, grouped distributions, rankings, trends, or insight-style
 
 - Subtable payloads stay under the parent table field as a row array
 - Attachment fields are two-step: upload first, then write the returned upload payload
+- For reads, attachment/rich-text images returned by `record_get` should be opened from local `media_assets` paths, and non-image files should be read from `file_assets` local paths or `extraction.text_path`, instead of remote file URLs

package/skills/qingflow-app-user/references/public-surface-sync.md

@@ -8,11 +8,13 @@ It is not a user-facing product spec. It exists to prevent skill drift.
 ### User data
 
 - Read range first with `app_get`, then `record_browse_schema_get(view_id=...)`
+- Treat `record_browse_schema_get.fields` as the selected Qingflow table view header schema; `record_access.fields` and `record_list` field selectors must stay aligned with it.
 - Standard flows:
-  - browse / export detail: `app_get -> record_browse_schema_get -> record_list / record_get`
+  - analyze: `app_get -> record_browse_schema_get -> record_access -> Python`
+  - browse detail: `app_get -> record_browse_schema_get -> record_list / record_get`
+  - explicit export/download/Excel: `view_get -> record_export_*` or `record_export_direct`
   - insert: `record_insert_schema_get -> record_insert`
   - update: `record_update_schema_get -> record_update`
-  - analyze: `app_get -> record_browse_schema_get -> record_analyze`
 
 ### Tasks
 
@@ -55,7 +57,7 @@ It is not a user-facing product spec. It exists to prevent skill drift.
 - Package public tools: do not regress to `package_create` / `package_attach_app` as the public default story
 - App editability: do not let `can_edit_form` imply app base-info writes
 - Portal and chart visibility: keep the public story on `portal_apply` / `app_charts_apply`, not low-level internal writes
-- Analysis fallback: standard path stays `record_analyze`, but complex tables may require explicit fallback modes
+- Analysis path: standard path stays `record_access -> Python`
 
 ## Release Checklist For Skill Maintenance
 

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

@@ -10,6 +10,14 @@ Use `record_browse_schema_get -> record_list` when:
 - the target `record_id` is unknown
 - a delete target still needs confirmation
 - the user needs sample rows or a small export
+- the user gives fuzzy text such as a company, project, bug, or contract name
+
+For fuzzy lookup, pass `query` and optional `query_fields`. `record_list` returns at most 10 `data.items`, plus `data.pagination.total_count` and `lookup.next_action`.
+
+- `lookup.next_action="record_get"`: read the single returned item with `record_get`
+- `lookup.next_action="ask_user"`: ask the user to choose from returned `data.items`
+- `lookup.next_action="refine_query"`: ask for a narrower keyword or add `query_fields`
+- `lookup.next_action="broaden_query"`: remove overly narrow fields or ask for another clue
 
 ## Detail Pattern
 
@@ -18,6 +26,7 @@ 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
+- the user needs images or attachments shown on the detail page; read downloaded images from `media_assets.items[].local_path`, and read documents/tables from `file_assets.items[].local_path` or `extraction.text_path`
 
 ## Insert Pattern
 

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

@@ -1,200 +1,137 @@
 ---
 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.
+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, comparisons, or any final statistical conclusion across an existing app's data. Default to schema-first record_access CSV retrieval plus local Python/pandas; do not use export tools unless the user explicitly asks for a file download.
 metadata:
-  short-description: Analyze Qingflow record data with schema-first DSL execution
+  short-description: Analyze Qingflow record data with record_access CSV and Python
 ---
 
 # 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.
+Use this skill only for final statistical conclusions: counts, distributions, ratios, averages, rankings, trends, comparisons, and analysis reports.
 
-## Step 1: `app_get` → Step 2: `record_browse_schema_get(view_id=...)` → Step 3: build DSL → Step 4: `record_analyze`
+Default path, every time:
 
-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 or an explicit fallback. Task/comment work stays in [$qingflow-task-ops](../qingflow-task-ops/SKILL.md).
-
-## Execution Modes
-
-Choose the lightest mode that can still support a trustworthy conclusion:
-
-1. `server_aggregate`
-   - Default and preferred path
-   - Use `record_analyze` directly after `app_get -> record_browse_schema_get`
-
-2. `client_aggregate_from_record_list`
-   - Allowed fallback when `record_analyze` is unstable, unsupported on the target view, or the table is complex enough that service-side aggregation is not trustworthy
-   - Still requires `app_get -> record_browse_schema_get` first
-   - Use only after disclosing that the result is a fallback built from detail rows
-
-3. `cross_app_manual_reconcile`
-   - Use when the question depends on joining multiple apps, organization-history alias mapping, or other business logic that current public tools do not express directly
-   - Be explicit that the conclusion is based on manual reconciliation rules, not one single DSL execution
-
-## Fallback Ladder
-
-Trigger a fallback when any of these are true:
-
-- `record_analyze` is unstable or cannot complete the scan reliably
-- the target view is unsupported for analysis
-- field semantics are ambiguous enough that a server aggregate would be misleading
-- the question requires cross-app reconciliation
-- the question depends on organization-tree scope, historical department aliases, or other business rules that are not first-class MCP filters
-
-When you fall back:
-
-1. Keep the standard read order: `app_get -> record_browse_schema_get`
-2. State which fallback mode you chose
-3. State whether the result is still full-scope or only a verified subset
-4. State the time field, organization scope, and any alias mapping used
-5. Prefer concrete numbers plus a conservative conclusion over broad wording
-
----
-
-## DSL Contract
-
-### DSL FORMAT (CRITICAL — read this FIRST)
+```text
+app_get -> record_browse_schema_get(view_id=...) -> record_access -> Python/pandas -> final answer
+```
 
-### ✅ Correct vs ❌ Wrong — learn from these before building ANY DSL
+`record_access` may appear either as an MCP tool or as a CLI subcommand. If the active client does not expose an MCP `record_access` tool, do not switch to aggregate helpers. Use the CLI entry instead:
 
-**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
+```bash
+qingflow record --help
+qingflow record access --help
+qingflow record access --app-key APP_KEY --view-id VIEW_ID --columns-file columns.json --where-file where.json --order-by-file order_by.json --json
 ```
 
-**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
-```
+The CLI command is under the `record` command group, so the discovery path is: first inspect `qingflow record --help`, then inspect `qingflow record access --help`.
+
+## Hard Rules
+
+- Never start analysis from `record_list`, export, QingBI, or guessed field ids.
+- Never conclude `record_access` is unavailable just because it is not visible as a top-level MCP tool; check the CLI path `qingflow record access`.
+- Never call `record_access` before `record_browse_schema_get`.
+- Use only field ids returned by `record_browse_schema_get.fields`.
+- If `app_get.accessible_views[].analysis_supported=false`, do not use that view for `record_access`.
+- Prefer an explicit time range or business filter. If the user gives none and the table may be large, ask for scope or use a clearly provided month/quarter/year.
+- Read every CSV shard in `record_access.files[].local_path` with Python. Do not print raw CSV or load raw rows into model context.
+- Before final analysis, run a field-quality profile in pandas: row count, null rate, distinct count, and period coverage for candidate grouping fields.
+- Do not use a high-missing field as the main conclusion dimension. If a candidate dimension is sparse, downgrade it to an `已填写样本观察` and choose a cleaner semantic fallback when available.
+- Full final conclusions require `record_access.complete=true` and `record_access.safe_for_final_conclusion=true`.
+- `record_list` is only for sample inspection after the aggregate result is understood.
+- `record_get` is only for single-record detail verification, logs, references, images, or readable attachments. Read images from `media_assets.items[].local_path`; read documents/tables from `file_assets.items[].local_path` and `extraction.text_path`.
+- `record_export_direct` is only for explicit export/download/Excel requests.
+- `chart_get` / QingBI is only for user-provided report URLs or chart ids.
+
+## Tool Selection
+
+| Need | Tool |
+|---|---|
+| Batch analysis, statistics, comparison, report | `record_access -> Python` |
+| Browse a few example rows | `record_list` |
+| Inspect one record, logs, references, images, attachments | `record_get` |
+| User asks to export/download/Excel | `record_export_direct` |
+| User gives report URL or chart id | `chart_get` |
+| Todo/workflow task actions | `$qingflow-task-ops` |
+
+## Standard Procedure
+
+1. Run `app_get` and choose a table-style `view_id` from `accessible_views`.
+2. Run `record_browse_schema_get(app_key, view_id)`.
+3. Decide metric intent before fetching data: `count`, `sum`, `avg`, `distinct_count`, ratio, ranking, trend, or comparison.
+4. Choose minimal `record_access.columns`, plus `where` and `order_by`.
+5. Run `record_access` through MCP if visible, otherwise through `qingflow record access`.
+6. Read all returned CSV files in Python; use `fields[]` only when field-id metadata is needed.
+7. Run field-quality checks for all candidate dimensions.
+8. Compute results in pandas.
+9. Report numbers with scope, field choices, field-quality caveats, completeness, and business assumptions.
+
+Use field-id DSLs only:
 
-**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"
+```json
+{
+  "app_key": "APP_KEY",
+  "view_id": "system:all",
+  "columns": [{ "field_id": 2 }, { "field_id": 18 }],
+  "where": [{ "field_id": 2, "op": "between", "value": ["2026-05-01", "2026-05-31"] }],
+  "order_by": [{ "field_id": 2, "direction": "asc" }]
+}
 ```
 
-**sort item:**
-```
-✅ CORRECT:  { "by": "记录数", "order": "desc" }     ← "by" references an alias
-❌ WRONG:    { "by": 9500572, "order": "desc" }       ← field_id not allowed in sort
-```
+Never pass `page`, `page_size`, `limit`, `max_rows`, `timeout`, or `profile` to `record_access`.
 
-### Allowed keys per item (ANY other key = error)
+CSV columns are already readable and field-id anchored, for example `项目状态__field_343283094`. Do not expect separate `schema.json` or `README.md` files.
 
-| Item | Allowed keys only |
-|------|-------------------|
-| dimension | `field_id`, `alias`, `bucket` |
-| metric | `op`, `field_id`, `alias` |
-| filter | `field_id`, `op`, `value` |
-| sort | `by`, `order` |
+For CLI use, write JSON argument files instead of embedding large JSON in shell text:
 
-### `op` values
+```bash
+qingflow record access \
+  --app-key APP_KEY \
+  --view-id system:all \
+  --columns-file columns.json \
+  --where-file where.json \
+  --order-by-file order_by.json \
+  --json
+```
 
-- 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":"记录数"}]`.
+## Status Handling
 
----
+Read `record_access.status` before reading files or writing conclusions.
 
-See [references/dsl-templates.md](references/dsl-templates.md) for complete copy-paste templates.
+- `status=success`, `complete=true`, `safe_for_final_conclusion=true`: full-scope answer is allowed.
+- `status=needs_scope`: no CSV was written. Ask for a time/business range or retry with a user-provided period using `scope.suggested_time_fields`.
+- `status=partial`: read returned files only as a subset. Do not give a full-population conclusion.
+- `complete=false`, `truncated=true`, or `safe_for_final_conclusion=false`: answer as `初步观察` or ask for a narrower scope.
 
-**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
-}
-```
+## Business Context
 
-**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
-}
-```
+If the question mentions department, team, region, owner group, stage, product line, or a named business scope, check whether aliases or child scopes matter before concluding. Use explicit mappings provided by the user or local context; otherwise ask a short clarification.
 
-Top-level arguments:
+Example: if `烈焰组` and `飓风组` are sub-departments of `北斗部门`, apply that mapping in Python and state it in the answer.
 
-- `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`.
+## Output Shape
 
----
+Default to:
 
-## 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 not the default basis for final statistics. Use it only in an explicit fallback mode and disclose that fallback in the final answer.
-- Set `alias` for any metric you will sort by, compare, or quote.
+1. `结论`
+2. `关键数据`
+3. `口径与范围`
+4. `可信度 / 限制`
 
----
+Concrete numbers are mandatory. Ratios require both numerator and denominator. Trends require a time field and explicit date range. Rankings must come from a sorted pandas result.
+If a requested dimension has poor quality, say so explicitly and provide the nearest reliable fallback dimension, for example platform or product instead of a mostly empty module field.
 
-## OUTPUT
-
-- Final answer must show concrete numbers.
-- Final answer must state which execution mode was used whenever the answer is not a straightforward `server_aggregate`
-- 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 个分组`, 不用 `全部`/`所有`
-- If you used a fallback mode, explicitly disclose:
-  - whether this is full-scope or a manually curated subset
-  - which time field was used
-  - which organization scope was used
-  - whether any historical department aliases or cross-app joins were applied
+## References
 
-## Feedback Escalation
+Load only what is needed:
 
-- 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`.
+- Data access status machine: [references/data-access-playbook.md](references/data-access-playbook.md)
+- Python/pandas templates: [references/pandas-recipes.md](references/pandas-recipes.md)
+- Analysis patterns: [references/analysis-patterns.md](references/analysis-patterns.md)
+- Business mappings and scope: [references/business-context.md](references/business-context.md)
+- Confidence and final wording: [references/confidence-reporting.md](references/confidence-reporting.md)
+- Common mistakes: [references/analysis-gotchas.md](references/analysis-gotchas.md)
+- Report templates: [references/report-format.md](references/report-format.md)
 
-## Resources
+## Feedback Escalation
 
-- Shared public-surface baseline: [public-surface-sync.md](../qingflow-app-user/references/public-surface-sync.md)
-- 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)
+If the desired analysis cannot be completed because of missing capability, unsupported data shape, or an awkward workflow after reasonable attempts, summarize the exact gap and ask whether to submit product feedback. Only after explicit user confirmation, call `feedback_submit`.

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

@@ -1,4 +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."
+  short_description: "Analyze Qingflow record data with record_access CSV and Python"
+  default_prompt: "Use $qingflow-record-analysis for grouped distributions, ratios, rankings, trends, and final statistical conclusions in Qingflow apps. Start with app_get and record_browse_schema_get, run record_access with field_id-based columns/where/order_by, then analyze every returned CSV shard with Python. Always run field-quality checks before choosing final grouping dimensions, and downgrade sparse dimensions to filled-sample observations. If record_access is not visible as an MCP tool, discover and use the CLI path qingflow record --help -> qingflow record access --help. Treat record_list as sample-only."