@josephyan/qingflow-app-builder-mcp 1.1.25 → 1.1.27

package/skills/qingflow-app-builder/references/build-single-app.md

@@ -0,0 +1,138 @@
+# Build Single App
+
+Use this when the user asks for one app/form, or gives one `app_key`.
+If the request contains several related business objects, use [build-complete-system.md](./build-complete-system.md).
+
+## Main Chain
+
+```text
+app_resolve / app_get
+-> app_schema_apply(fields + form.sections)
+-> app_views_apply(views[])
+-> workflow only when requested or required
+-> readback/verify
+```
+
+This is the only recommended chain for a new single app. Do not split layout into a routine second step.
+
+## Required Shape
+
+- Resolve the target package/app with `app_resolve`, `app_get`, or `package_get`.
+- Create or update business fields with `app_schema_apply`.
+- Put form layout directly in `form.sections` in the schema payload.
+- Exactly one readable top-level field must have `as_data_title: true`.
+- Do not create platform fields: `数据ID`, `编号`, `申请人`, `申请时间`, `创建人`, `创建时间`, `提交人`, `提交时间`, `更新时间`, `更新人`, `当前流程状态`, `当前处理人`, `当前处理节点`, `流程标题`.
+- Create at least one business view when the user-facing list/table/card experience matters.
+- If a view needs business actions, put the action configuration directly inside the view item with `action_buttons`.
+
+## Schema Payload Pattern
+
+```json
+{
+  "package_id": 123,
+  "create_if_missing": true,
+  "apps": [
+    {
+      "client_key": "contract",
+      "app_name": "合同",
+      "icon": "document-text",
+      "color": "blue",
+      "add_fields": [
+        {"name": "合同名称", "type": "text", "required": true, "as_data_title": true},
+        {"name": "合同编号", "type": "text"},
+        {"name": "合同状态", "type": "select", "options": ["草稿", "审批中", "已生效", "已终止"]},
+        {"name": "合同金额", "type": "amount"},
+        {"name": "负责人", "type": "member"},
+        {"name": "签署日期", "type": "date"},
+        {"name": "合同说明", "type": "multiline"},
+        {"name": "合同附件", "type": "attachment"}
+      ],
+      "form": {
+        "sections": [
+          {"title": "基础信息", "rows": [["合同名称", "合同编号"], ["合同状态", "负责人"]]},
+          {"title": "金额与时间", "rows": [["合同金额", "签署日期"]]},
+          {"title": "补充信息", "rows": [["合同说明"], ["合同附件"]]}
+        ]
+      }
+    }
+  ]
+}
+```
+
+Agent-friendly field type aliases are allowed: `multiline -> long_text`, `select -> single_select`, `amount -> amount`. Readback may show canonical types; do not treat that as a mismatch.
+
+## View Payload Pattern
+
+- Use `app_views_apply(views=[...])`.
+- Do not create platform default views named `全部数据`, `我的数据`, `我发起的`, `待办`, `已办`, or `抄送`.
+- Use business-specific view names.
+- `filters` are fixed saved filters.
+- `query_conditions` are frontend query panel fields.
+- Put button configuration in `action_buttons`.
+
+```json
+{
+  "views": [
+    {
+      "operation": "upsert",
+      "app_key": "APP_KEY",
+      "name": "合同执行视图",
+      "type": "table",
+      "columns": ["合同名称", "合同状态", "合同金额", "负责人", "签署日期"],
+      "filters": [
+        {"field_name": "合同状态", "operator": "neq", "value": "已终止"}
+      ],
+      "query_conditions": {
+        "enabled": true,
+        "rows": [["合同名称", "合同状态"], ["负责人", "签署日期"]]
+      },
+      "action_buttons": [
+        {
+          "text": "查看合同模板",
+          "action": "link",
+          "url": "https://example.com/contract-template",
+          "placement": "detail"
+        }
+      ]
+    },
+    {
+      "operation": "upsert",
+      "app_key": "APP_KEY",
+      "name": "合同状态看板",
+      "type": "board",
+      "group_by": "合同状态",
+      "columns": ["合同名称", "合同金额", "负责人", "签署日期"],
+      "query_conditions": {
+        "enabled": true,
+        "rows": [["合同名称", "负责人"]]
+      }
+    }
+  ]
+}
+```
+
+## Workflow
+
+Only add workflow when the user asks for approval, fill, copy, reminders, process routing, or task handling.
+
+- Create an explicit business status `select` field first, such as `状态`, `处理状态`, `审批状态`, or `流程阶段`.
+- Do not create platform workflow system fields such as `当前流程状态`, `当前处理人`, `当前处理节点`, or `流程标题`.
+- If no workflow is requested, report it as not requested/not configured.
+
+## Readback And Verification
+
+After writing:
+
+- read fields and confirm `as_data_title`
+- read layout and confirm important fields are placed
+- read views and confirm business view keys exist
+- verify publish/live status only when required by the user or task
+
+If a write returns `partial_success`, `write_executed=true`, or `safe_to_retry=false`, read back before retrying. Retry only verified missing or incorrect slices.
+
+## Stop Conditions
+
+- If the task actually needs multiple business objects, switch to the complete-system guide.
+- If a same/similar app already exists and the user did not explicitly say update, extend, or create new, stop and ask which target to use.
+- Do not create `V2`, `测试`, timestamp, or random-suffix apps to bypass duplicate names in a real business package.
+- If the same validation error repeats twice, re-read `builder_tool_contract` instead of guessing.

package/skills/qingflow-app-builder/references/create-app.md

@@ -6,17 +6,16 @@ This playbook follows the current public builder surface, not legacy package hel
 Do not use this playbook when the user is really asking for a system/package with multiple forms or modules. In that case:
 
 1. read or create the package through `package_get` / `package_apply`
-2. create the related apps in one `app_schema_apply(package_id=..., apps=[...])` call
+2. create related apps together with one `app_schema_apply(apps=[...])`
 3. keep package ownership on the public `package_id` path instead of a separate attach step
-4. add same-call relation fields with `target_app_ref` when one new app references another new app; use `target_app_key` only after the target app already exists or readback confirms it
-5. choose explicit non-template `icon + color` for each new package/app
+4. add relation fields between apps
 
 Hierarchy reminder:
 
 - package -> app -> field -> relation
 - another business object is another app, not a text field
 
-If creating a brand new package would help, ask the user to confirm package creation first. After confirmation, create it through `package_apply(package_name=..., icon=..., color=...)`.
+If creating a brand new package would help, ask the user to confirm package creation first. After confirmation, create it through `package_apply(create_if_missing=true, package_name=...)`.
 
 ## Minimal sequence
 
@@ -37,25 +36,12 @@ then do not treat that as one app.
 
 Use this pattern instead:
 
-1. `package_get` or `package_apply(package_name=..., icon=..., color=...)`
-2. for a multi-app system, run one `app_schema_apply` with `package_id` and `apps[]`
+1. `package_get` or `package_apply(create_if_missing=true, package_name=...)`
+2. for a multi-app system, run one `app_schema_apply` with `apps[]`
 3. use `apps[].client_key` plus relation field `target_app_ref` when one new app references another new app
 
-If that multi-app call times out, returns `partial_success`, returns `write_executed=true`, has `safe_to_retry=false`, or has incomplete readback, do not decide that the create failed. Run `readback_before_retry`: read the package, resolve each intended app by package/name or returned app key, read fields, and retry only verified missing apps or fields. Do not rebuild the same complete system as separate single-app creates, and do not create `V2`, `测试`, timestamp, or random-suffix apps to bypass duplicate names.
-
 ## Example
 
-When designing fields, do not add platform system fields such as `数据ID`, `编号`, `申请人`, `申请时间`, `创建人`, `创建时间`, `提交人`, `提交时间`, `更新时间`, `更新人`, `当前流程状态`, `当前处理人`, `当前处理节点`, or `流程标题`. Qingflow provides them automatically; create only business fields.
-
-Field authoring rules:
-
-- Use intuitive field types in drafts: `text`, `multiline`, `select`, `multi_select`, `number`, `amount`, `date`, `datetime`, `member`, `department`, `attachment`, `relation`.
-- The tool normalizes aliases before writing: `multiline -> long_text`, `select -> single_select`, `checkbox -> multi_select`, `currency -> amount`, `mobile -> phone`. Readback may show canonical types; that is not a failed write.
-- Every new app must have exactly one top-level `as_data_title: true` field. `as_data_cover: true` is optional and only valid on a top-level `attachment`.
-- Select fields must define `options` during schema design. Options may be strings or objects such as `{"label": "进行中"}`; sample data must use those labels or ids.
-- Relation fields must use `target_app_ref` for same-batch apps or `target_app_key` for existing apps, plus object selectors: `display_field: {"name": "..."}` and `visible_fields: [{"name": "..."}]`. Do not write bare strings for display/visible field selectors.
-- Do not impose a one-relation-field-per-app limit. Model the real business links and let backend validation/readback decide.
-
 Create a new package only after the user confirms package creation:
 
 ```json
@@ -64,8 +50,7 @@ Create a new package only after the user confirms package creation:
   "arguments": {
     "profile": "default",
     "package_name": "研发项目管理",
-    "icon": "briefcase",
-    "color": "azure"
+    "create_if_missing": true
   }
 }
 ```
@@ -91,16 +76,21 @@ Apply schema for a new app:
     "profile": "default",
     "app_name": "客户订单",
     "package_id": 1218950,
-    "icon": "delivery-box-1",
-    "color": "emerald",
+    "create_if_missing": true,
     "publish": true,
     "add_fields": [
       {"name": "订单编号", "type": "text", "required": true, "as_data_title": true},
       {"name": "客户名称", "type": "text", "required": true},
       {"name": "订单封面", "type": "attachment", "as_data_cover": true},
       {"name": "订单金额", "type": "amount"},
-      {"name": "状态", "type": "select", "options": [{"label": "草稿"}, {"label": "进行中"}, {"label": "已完成"}], "required": true}
+      {"name": "状态", "type": "single_select", "options": ["草稿", "进行中", "已完成"], "required": true}
     ],
+    "form": {
+      "sections": [
+        {"title": "基础信息", "rows": [["订单编号", "客户名称"], ["状态"]]},
+        {"title": "金额与附件", "rows": [["订单金额"], ["订单封面"]]}
+      ]
+    },
     "update_fields": [],
     "remove_fields": []
   }
@@ -115,22 +105,24 @@ Apply schema for multiple apps in one call:
   "arguments": {
     "profile": "default",
     "package_id": 1218950,
+    "create_if_missing": true,
     "publish": true,
     "apps": [
       {
         "client_key": "customer",
         "app_name": "客户",
-        "icon": "business-personalcard",
-        "color": "emerald",
+        "icon": "user-group",
+        "color": "blue",
         "add_fields": [
           {"name": "客户名称", "type": "text", "required": true, "as_data_title": true}
-        ]
+        ],
+        "form": {"sections": [{"title": "基础信息", "rows": [["客户名称"]]}]}
       },
       {
         "client_key": "order",
         "app_name": "订单",
         "icon": "delivery-box-1",
-        "color": "blue",
+        "color": "green",
         "add_fields": [
           {"name": "订单编号", "type": "text", "required": true, "as_data_title": true},
           {
@@ -140,7 +132,8 @@ Apply schema for multiple apps in one call:
             "display_field": {"name": "客户名称"},
             "visible_fields": [{"name": "客户名称"}]
           }
-        ]
+        ],
+        "form": {"sections": [{"title": "基础信息", "rows": [["订单编号", "关联客户"]]}]}
       }
     ]
   }
@@ -153,11 +146,11 @@ Data title is required: mark exactly one top-level field with `as_data_title: tr
 
 ### `APP_NOT_FOUND`
 
-For new apps, submit `app_schema_apply` with `package_id + app_name + icon + color`. For existing apps, resolve and pass the real `app_key`.
+Expected on create. Continue with `create_if_missing=true`.
 
 ### `CREATE_APP_ROUTE_NOT_FOUND`
 
-The create route did not resolve in the current backend route context. In Wingent Momo runtime, first retry the same `app_schema_apply` after confirming the injected session is still active. Only run `workspace_select` if a business tool explicitly reports a missing or wrong workspace.
+The create route did not resolve in the current backend route context. Re-run `workspace_select`, then retry the same `app_schema_apply`.
 
 ### Hierarchy modeling mistake
 

package/skills/qingflow-app-builder/references/environments.md

@@ -16,7 +16,7 @@ If the user did not specify an environment, default to `prod`.
 Use test for:
 
 - first application of a new `SolutionSpec`
-- trying builder apply flows end-to-end with readback verification, or `solution_install` when the user is installing an existing packaged solution
+- trying `solution_build_all(..., verify=true)`
 - package initialization and schema evolution experiments
 - mock data creation, with at least `5` records per relevant entity unless the user asks for fewer
 

package/skills/qingflow-app-builder/references/gotchas.md

@@ -3,7 +3,7 @@
 ## Auth and workspace
 
 - `auth_*` success does not mean a workspace is selected
-- In Wingent Momo runtime, do not run `workspace_select` before builder work. Re-run it only after an explicit auth/route recovery or when a business tool reports the workspace is missing.
+- Re-run `workspace_select` after auth changes or route changes
 
 ## Package ownership
 
@@ -17,14 +17,13 @@
 - Another app is not a field
 - If the user names multiple forms/modules that relate to each other, create multiple apps and connect them with relation fields
 - Do not use child app names like “项目/需求/任务/缺陷/团队” as plain text fields inside one app
-- For a complete system, the main creation path is one multi-app `app_schema_apply(package_id=..., apps=[...])` with stable `apps[].client_key` values and same-call relation fields using `target_app_ref`
-- Use `target_app_key` only for an app that already exists or has been confirmed by readback
 
-## Auto publish
+## Publish
 
-- `app_schema_apply`, `app_layout_apply`, `app_flow_apply`, and `app_views_apply` publish by default
-- For those four tools, pass `publish=false` only when the user explicitly wants to leave changes in draft
-- `app_custom_buttons_apply` and `app_associated_resources_apply` publish after at least one write succeeds and do not accept `publish=false`
+- Always pass `publish: true` explicitly on `app_schema_apply`, `app_layout_apply`, `app_flow_apply`, `app_views_apply`, and `portal_apply` — do not rely on the default
+- Pass `publish: false` on those five tools only when the user explicitly wants to leave changes in draft
+- `app_associated_resources_apply` publishes after at least one write succeeds and does not accept a `publish` parameter
+- `app_charts_apply` is immediate-live and has no publish step
 - `app_publish_verify` is for explicit final verification, not the default next step after every write
 
 ## BI Reports
@@ -33,29 +32,18 @@
 - Use `app_associated_resources_apply` only when an existing BI report or view needs to appear in the Qingflow app associated-resource area or a specific view.
 - `app_charts_apply` currently creates/updates app-source BI reports only (`dataSourceType=qingflow`); dataset BI reports can only be attached when they already exist.
 - Creating a chart with `app_charts_apply` does not automatically show it in the Qingflow app UI; attach it separately if display is required.
-- Main chart config should use semantic `metric`, `metrics`, `group_by`, and `where`; avoid raw `indicator_field_ids`, `selectedMetrics`, and QingBI filter matrices unless diagnosing or preserving existing raw config.
 - `target` and `table` remain compatibility aliases for QingBI `indicator` and `detail`; use the real QingBI chart type when you need a specific type such as `summary`, `columnar`, `stacked_bar`, `scatter`, or `dualaxes`.
-- Use `app_get_fields.chart_fields` as the source for dimensions, metrics, and filters. Record schema fields or normal form fields are not enough for chart apply.
-- Use `target` / `indicator` for one metric card; do not use `summary` for a single KPI.
 
-## Custom buttons
+## View actions
 
-- For ordinary view-specific business buttons, use `app_views_apply` with `action_buttons`; do not use legacy `app_views_apply.buttons` unless you are maintaining an old full-replacement patch.
-- Use `app_custom_buttons_apply` for advanced button creation/update/removal and view placement: custom style/icon, cross-view reuse, deleting button bodies, bulk binding reorder, or exact qRobot/wings configs.
-- When changing one existing button parameter, use `patch_buttons` with `set/unset`. Do not send a partial `upsert_buttons` object and expect the backend to preserve hidden required fields.
-- `addData` / `add_data` creates a related/downstream Qingflow record; use current-record `field_mappings` only on `detail` or `list`. `link` only opens a URL. `qRobot`/`wings` require user-provided exact config and must not be invented.
-- For add-data buttons, prefer semantic `trigger_add_data_config.target_app_key`, `field_mappings`, and `default_values`.
+- Put business actions directly in the target view's `action_buttons`.
+- For add-data actions, use semantic `target_app_key`, `field_mappings`, and `default_values`.
 - Do not handwrite raw `que_relation` unless you are preserving an existing backend config. If `field_mappings` and `que_relation` are mixed, the tool blocks the write.
 - `field_mappings.source_field` can use source app fields and supported system fields such as `数据ID` (`field_id=-17`) and `编号` (`field_id=0`).
 - To fill a target relation field with the current source record, map `{"source_field": "数据ID", "target_field": "目标引用字段"}`. Use `default_values` only for static constants.
-- Do not put current-record `field_mappings` on a `header` button; `header` has no current row. Use `detail` or `list` for current-record add-data actions.
-- Do not model approval, rejection, close-task, or status transition as a generic `link` button. Use workflow/task behavior, or `qRobot`/`wings` only when the user provides existing automation config.
 - For field type compatibility, read `references/match-rules.md`.
-- Use `header` for global actions with no current-row context, `detail` for safest current-record actions, and `list` for row/list actions.
-- `view_configs[].buttons` is required in merge mode. Do not send a view config with only `view_key`; it is blocked to avoid no-op writes and accidental publish.
+- Default button placements are `header` and `detail`; these map to the frontend's header and detail button areas.
 - Builder view configs use raw `view_key` from `app_get.views[].view_key`; do not prefix it with `custom:`. The `custom:<viewKey>` form is for record-data `view_id`.
-- View button bindings merge by default. Use `view_configs[].mode="replace"` to replace the full set, or pass an explicit empty `buttons: []` when you intend to clear all custom button bindings for that view.
-- Advanced view button bindings can include `button_limit`, `button_formula`, `button_formula_type`, and `print_tpls`, but keep ordinary buttons simple unless the user asks for conditional visibility or print templates.
 - `placement=list` configures row/list buttons. The tool maps it to the backend `INSIDE` button position, not a raw `LIST` config type.
 
 ## Associated resources
@@ -76,18 +64,11 @@
 
 ## Partial update discipline
 
-- Existing views, custom buttons, associated resources, and charts support the same public partial pattern: `patch_*[].set` plus optional `patch_*[].unset`.
+- Existing views, associated resources, and charts support the same public partial pattern: `patch_*[].set` plus optional `patch_*[].unset`.
 - The backend may still save a full payload. The MCP/CLI patch path is responsible for reading current config and preserving fields the user did not mention.
-- Do not use `upsert_views`, `upsert_buttons`, `upsert_resources`, or `upsert_charts` for a tiny parameter replacement unless you are deliberately providing the full desired target config.
+- Do not use `upsert_views`, `upsert_resources`, or `upsert_charts` for a tiny parameter replacement unless you are deliberately providing the full desired target config.
 - `app_layout_apply(mode=merge)` is already a safe layout merge path; `mode=replace` is full layout replacement.
-- `portal_apply` without `sections` is base-info-only. Supplying `sections` replaces the portal sections list; use `patch_sections[]` for one-section updates.
-- PC portal layout is 24-column. Group components by the same `y`: all components in that row must have the same `rows`, and their `cols` should sum to 24 unless the user explicitly wants blank space.
-- Standard workbench heights: metric cards `rows=5`, BI charts `rows=7`, data views `rows=11`.
-- Business-entry `grid` sections must include real `config.items[]`; an empty grid container is not a valid business entrance.
-- Build portals only after referenced apps, raw `view_key`s, and chart ids/keys are known by readback. Intended names are not enough.
-- Use standard order: business entry -> metric cards -> BI charts -> concrete data views.
-- Do not use platform default views such as `全部数据` / `我的数据` as the main portal views.
-- Do not use portal `source_type: "filter"` as the normal automation path; it is raw/unstable and not part of the unified filter DSL.
+- `portal_apply` without `sections` is base-info-only. Supplying `sections` replaces the portal sections list.
 - `app_flow_apply` is intentionally replace-only for the public linear workflow graph.
 
 ## Workflow dependencies
@@ -104,16 +85,9 @@
 ## Retry discipline
 
 - If a write returns `partial_success`, read back before retrying
-- If multi-app schema apply times out, returns `write_executed=true`, returns `safe_to_retry=false`, or has incomplete readback, treat it as `write_may_have_succeeded`; the next action is `readback_before_retry`
-- `readback_before_retry` means read package/app/fields first, classify which intended apps and relation fields actually exist, and retry only the verified missing slice
 - Do not repeat create steps after `app_key` already exists
-- Do not split a complete-system schema create into single-app rebuilds until readback proves exactly what is missing
-- Do not bypass duplicate/conflict states by inventing `V2`, `测试`, timestamp, or random-suffix app names in a real business package
 - For backend rejects, keep the retry narrow: retry only the failed tool, not the whole chain
 - For `VALIDATION_ERROR`, do not keep guessing. Reuse `suggested_next_call`, `canonical_arguments`, `allowed_keys`, and `allowed_values` first.
-- For `builder_tool_contract`, read the returned `json_paths` first. Successful contract data is under `$.contract`; `allowed_values` uses flat dotted keys such as `["field.type"]`, not nested objects. Do not read successful field enums from top-level `allowed_values`.
-- For `workspace_icon_catalog_get`, read icon candidates from `$.icon_names` and colors from `$.icon_colors`.
-- For builder apply responses, read returned `json_paths` first. Stable fields are `$.summary` and `$.resources[]`; use `resources[].id/key/name` before legacy top-level fields.
 - For layout `VALIDATION_ERROR`, also inspect `section_allowed_keys`, `section_aliases`, and `minimal_section_example`. If the same layout-shape error repeats twice, stop free-form retries and re-read `builder_tool_contract(app_layout_apply)`.
 - For flow work, do not replay internal keys from old logs or plan outputs. Public builder calls should stay on:
   - `assignees.role_ids` / `assignees.member_uids` / `assignees.member_emails`

package/skills/qingflow-app-builder/references/match-rules.md

@@ -1,19 +1,13 @@
 # Builder Match Rules
 
-Use this reference for builder-side field matching rules in custom buttons and associated view/report filters.
+Use this reference for builder-side field matching rules in view actions and associated view/report filters.
 
 This is not the same thing as `record_access` analysis filters or normal view `filters`.
 
-Unified public semantics:
-
-- Fixed filters use `field_name + operator + value/values`, for example view `filters` and chart `filters`.
-- Current-record context matches use `target_field + operator + source_field/value`, for example associated resource `match_mappings` and add-data button mappings.
-- Do not handwrite `judgeType`, `judgeValues`, or `matchRules`; the CLI compiles them for the target backend protocol.
-
 ## Where These Rules Apply
 
-- `app_custom_buttons_apply.upsert_buttons[].trigger_add_data_config.field_mappings`
-- `app_custom_buttons_apply.patch_buttons[].set.trigger_add_data_config.field_mappings`
+- `app_views_apply.views[].action_buttons[].field_mappings`
+- `app_views_apply.patch_views[].set.action_buttons[].field_mappings`
 - `app_associated_resources_apply.upsert_resources[].match_mappings`
 - `app_associated_resources_apply.patch_resources[].set.match_mappings`
 
@@ -30,7 +24,7 @@ System fields can participate in mappings:
 
 Explicit selectors such as `{"field_id": -17}` and `{"field_id": 0}` are allowed and remove ambiguity.
 
-## Custom Buttons
+## View Actions
 
 Use `field_mappings` for dynamic values copied from the current source record:
 
@@ -49,21 +43,25 @@ Use `field_mappings` for dynamic values copied from the current source record:
 
 Use `default_values` only for static constants. Do not use `default_values` as the preferred way to pass the current record.
 
-For an existing button, put the same semantic config under `patch_buttons[].set`:
+For an existing view, patch the view's action list through `patch_views[].set.action_buttons`:
 
 ```json
 {
-  "button_id": 3858041,
+  "view_key": "VIEW_KEY",
   "set": {
-    "trigger_add_data_config": {
-      "target_app_key": "WORKLOG_APP",
-      "field_mappings": [
-        {"source_field": "数据ID", "target_field": "关联员工"}
-      ],
-      "default_values": {
-        "状态": "待提交"
+    "action_buttons": [
+      {
+        "text": "新建工时",
+        "action": "add_data",
+        "target_app_key": "WORKLOG_APP",
+        "field_mappings": [
+          {"source_field": "数据ID", "target_field": "关联员工"}
+        ],
+        "default_values": {
+          "状态": "待提交"
+        }
       }
-    }
+    ]
   }
 }
 ```
@@ -86,15 +84,6 @@ Use `match_mappings` for associated view/report filters:
 
 Dynamic conditions use `source_field`; static conditions use `value`.
 
-Recommended operators are `eq`, `neq`, `in`, `contains`, `gte`, `lte`, `is_empty`, and `not_empty`; aliases such as `equal`, `equals`, `=`, `!=`, `any_of`, `one_of`, and `empty` are accepted. `field_name` and `field` can be used as aliases for `target_field`. Static single-value filters should use `value`; a single-item `values` array is also accepted.
-
-Examples:
-
-```json
-{"target_field": "客户ID", "operator": "eq", "source_field": "数据ID"}
-{"target_field": "状态", "operator": "eq", "value": "有效"}
-```
-
 For an existing associated resource, put the same filter mapping under `patch_resources[].set`:
 
 ```json

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

@@ -39,14 +39,14 @@ It is not a user-facing product spec. It exists to prevent skill drift.
   - `app_layout_apply`
   - `app_flow_apply`
   - `app_views_apply`
-  - `app_custom_buttons_apply`
   - `app_associated_resources_apply`
   - `app_charts_apply`
   - `portal_apply`
   - `app_publish_verify`
 - `portal_apply` edit mode may omit `sections` for base-info-only updates
 - `app_charts_apply.visibility` is a public capability and should be treated as a base-only visibility update
-- Existing object parameter replacement should use `patch_views`, `patch_buttons`, `patch_resources`, and `patch_charts`; `upsert_*` is for creation or full target config
+- View actions are declared through `app_views_apply` `action_buttons`
+- Existing object parameter replacement should use `patch_views`, `patch_resources`, and `patch_charts`; `upsert_*` is for creation or full target config
 - `app_get.editability` uses:
   - `can_edit_app_base`
   - `can_edit_form`

package/skills/qingflow-app-builder/references/solution-playbooks.md

@@ -2,16 +2,6 @@
 
 Use these when you need a quick reminder of the standard v2 builder sequences.
 
-## Create a complete system / app package
-
-1. `package_get` or `package_apply`
-2. one multi-app `app_schema_apply(package_id=..., apps=[...])`
-3. use stable `apps[].client_key` values and relation `target_app_ref` for same-call app references
-4. use returned/readback `app_key` values for layout, views, workflow, charts, buttons, associated resources, and portal work
-5. `app_publish_verify` only when the user asks for explicit live verification or a final verification pass is required
-
-If the multi-app schema write times out or returns `partial_success`, `write_executed=true`, `safe_to_retry=false`, or incomplete readback, the next action is `readback_before_retry`: read package/app/fields first, then retry only verified missing pieces. Do not repeat the whole apps payload, split into single-app rebuilds, or create `V2` / `测试` / random-suffix apps to dodge duplicate names.
-
 ## Create a new app in an existing package
 
 1. `package_get`