@josephyan/qingflow-app-user-mcp 0.2.0-beta.52 → 0.2.0-beta.54

package/README.md

@@ -3,13 +3,13 @@
 Install:
 
 ```bash
-npm install @josephyan/qingflow-app-user-mcp@0.2.0-beta.52
+npm install @josephyan/qingflow-app-user-mcp@0.2.0-beta.54
 ```
 
 Run:
 
 ```bash
-npx -y -p @josephyan/qingflow-app-user-mcp@0.2.0-beta.52 qingflow-app-user-mcp
+npx -y -p @josephyan/qingflow-app-user-mcp@0.2.0-beta.54 qingflow-app-user-mcp
 ```
 
 Environment:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@josephyan/qingflow-app-user-mcp",
-  "version": "0.2.0-beta.52",
+  "version": "0.2.0-beta.54",
   "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 = "0.2.0b52"
+version = "0.2.0b54"
 description = "User-authenticated MCP server for Qingflow"
 readme = "README.md"
 license = "MIT"

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

@@ -34,8 +34,9 @@ Route to exactly one of these specialized paths:
 - If the app is known but the available data range is unclear, call `app_get` first and inspect `accessible_views`
 - If the task is about browsing, reading, creating, updating, deleting, attachments, relations, subtable writes, member/department-field candidate lookup, code-block field execution, import templates, import capability discovery, import-file verification, authorized local file repair, import execution, or import status, switch to `$qingflow-record-crud`
 - If the task is about todo discovery, task context, approval actions, rollback or transfer, associated report review, or workflow log review, switch to `$qingflow-task-ops`
-- If the task is about creating new records or importing data, prefer `$qingflow-record-crud` under applicant-node schema semantics
-- If the task is about updating an existing record directly, require an explicit accessible `view_id` and then route to `$qingflow-record-crud`
+- If the task is about creating new records or importing data, prefer `$qingflow-record-crud` under applicant-node create semantics
+- If the task is about updating an existing record directly, route to `$qingflow-record-crud`, which uses `record_update` and defaults to `system:all` before requiring an explicit accessible `view_id`
+- If the task involves member, department, or relation fields and the user only has natural names/titles, still route to `$qingflow-record-crud`; direct write now supports backend-native auto resolution and may return `needs_confirmation` with candidates instead of failing blind
 - If the task is about subtable writes, still route to `$qingflow-record-crud`, but shape the payload through the parent subtable field `rows/tableValues`; do not route users toward top-level leaf selectors
 - 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 grouped distributions, ratios, rankings, trends, insights, or any final statistical conclusion, switch to `$qingflow-record-analysis`

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

@@ -11,20 +11,18 @@ For final statistics, grouped distributions, rankings, trends, or insight-style
 
 ## Write Preflight
 
-- `record_write` always performs internal static preflight before any apply
-- If `record_write` returns `ok=false`, the write was blocked and not executed
+- `record_insert`, `record_update`, and `record_delete` always perform internal static preflight before any apply
+- If a direct-write tool returns `ok=false`, the write was blocked and not executed
 - Use `record_schema_get` when field titles are uncertain instead of guessing ids
 - Prefer `verify_write=true` for complex, relation-heavy, subtable, or production writes
-- Even when `record_write` returns `ok=true`, it may still surface verification failures; do not report success before checking them
+- Even when a direct-write tool returns `ok=true`, it may still surface verification failures; do not report success before checking them
 
 ## Write Semantics
 
-- `insert` uses `values`
-- `update` uses `set`
-- `delete` uses `record_id` or `record_ids`
-- Do not send raw SQL strings
+- `record_insert` uses an applicant-node `fields` map
+- `record_update` uses a view-scoped `fields` map
+- `record_delete` uses `record_id` or `record_ids`
 - Do not fake formula or expression fields
-- Do not perform free-form bulk updates or deletes
 - Do not guess relation targets from display text; resolve the real `record_id` first
 
 ## Attachments

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

@@ -50,7 +50,7 @@ Production behavior:
 Production guardrails:
 
 - never assume a record id, app id, or workspace id
-- treat `record_write(operation="delete")` as high risk
+- treat `record_delete` as high risk
 - if the task can be answered read-only, do not write
 
 ## Reporting Rule

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

@@ -32,13 +32,13 @@ Prefer passing explicit `columns` when the user only needs a subset of fields.
 
 ## Write Pattern
 
-Use `record_schema_get -> record_write`.
+Use `record_schema_get -> record_insert / record_update / record_delete`.
 
 1. Confirm the target app
 2. Resolve fields with `record_schema_get`
 3. Decide whether the task is `insert`, `update`, or `delete`
-4. Build SQL-like JSON clauses
-5. Run `record_write`
+4. Build a field-title keyed `fields` map for insert/update
+5. Run `record_insert`, `record_update`, or `record_delete`
 6. If `ok=false`, explain `field_errors` first, then summarize blockers; stop because the write was not executed
 7. If `ok=true`, report the affected resource and any verification outcome
 8. For important writes, keep `verify_write=true`
@@ -47,11 +47,11 @@ Use `record_schema_get -> record_write`.
 
 ```json
 {
-  "operation": "insert",
-  "values": [
-    { "field_id": 12, "value": "测试客户" },
-    { "field_id": 18, "value": 1000 }
-  ],
+  "app_key": "APP_1",
+  "fields": {
+    "客户名称": "测试客户",
+    "合同金额": 1000
+  },
   "submit_type": "submit",
   "verify_write": true
 }
@@ -61,11 +61,12 @@ Use `record_schema_get -> record_write`.
 
 ```json
 {
-  "operation": "update",
+  "app_key": "APP_1",
   "record_id": 123,
-  "set": [
-    { "field_id": 18, "value": 2000 }
-  ],
+  "fields": {
+    "合同金额": 2000
+  },
+  "view_id": "system:all",
   "verify_write": true
 }
 ```
@@ -74,7 +75,7 @@ Use `record_schema_get -> record_write`.
 
 ```json
 {
-  "operation": "delete",
+  "app_key": "APP_1",
   "record_ids": [123, 124]
 }
 ```
@@ -88,7 +89,7 @@ Do not do this:
 - do not invent formulas or expressions
 - do not auto-fill missing required fields
 - do not guess relation targets without first resolving them
-- do not claim a blocked `record_write` was executed
+- do not claim a blocked direct write was executed
 
 ## Unsupported Direct Writes
 
@@ -99,10 +100,10 @@ Do not attempt direct app-user writes for these field types:
 - `35` image generation
 - `36` document parsing
 
-If the payload includes them, stop after the blocked `record_write` response and explain that the tool does not support a reliable direct write for those fields yet.
+If the payload includes them, stop after the blocked response and explain that the tool does not support a reliable direct write for those fields yet.
 
 ## Relation, Attachment, and Subtable Rules
 
 - Relation fields are record-id based. Resolve the referenced target first, then write the relation field with the real `record_id`.
-- Attachment fields are two-step: upload first with `file_upload_local`, then reuse the returned attachment payload in `record_write`.
+- Attachment fields are two-step: upload first with `file_upload_local`, then reuse the returned attachment payload in `record_insert` or `record_update`.
 - Subtable writes require the current schema shape; when updating existing subtable rows, preserve row ids if the current record exposes them.

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

@@ -1,6 +1,6 @@
 ---
 name: qingflow-record-crud
-description: Browse, read, create, update, delete, and import Qingflow records after the MCP is already connected and authenticated. Use when the user wants schema-first record CRUD, import-template verification/import execution, or SQL-like JSON DSL writes. Do not use this skill for task-center workflow actions or final statistical analysis.
+description: Browse, read, create, update, delete, and import Qingflow records after the MCP is already connected and authenticated. Use when the user wants schema-first record CRUD or import-template verification/import execution. Do not use this skill for task-center workflow actions or final statistical analysis.
 metadata:
   short-description: Schema-first Qingflow record CRUD and import
 ---
@@ -18,17 +18,20 @@ Use exactly one of these default paths:
 
 1. Browse records: `app_get -> record_schema_get(schema_mode="browse", view_id=...) -> record_list`
 2. Read one record: `app_get -> record_schema_get(schema_mode="browse", view_id=...) -> record_get`
-3. Insert records: `record_schema_get(schema_mode="applicant") -> record_write(operation="insert")`
-4. Update records: `app_get -> choose accessible view -> record_schema_get(schema_mode="browse", view_id=...) -> record_write(operation="update", view_id=...)`
-5. Run a code-block field: `record_schema_get(schema_mode="applicant") -> record_code_block_run`
-6. Import records: `record_import_template_get -> record_import_verify -> (optional authorized file repair) -> record_import_start -> record_import_status_get`
+3. Insert records: `record_schema_get(schema_mode="applicant") -> record_insert`
+4. Update records: `app_get -> choose accessible view -> record_schema_get(schema_mode="browse", view_id=...) -> record_update`
+5. Delete records: `record_list / record_get -> record_delete`
+6. Run a code-block field: `record_schema_get(schema_mode="applicant") -> record_code_block_run`
+7. Import records: `record_import_template_get -> record_import_verify -> (optional authorized file repair) -> record_import_start -> record_import_status_get`
 
 ## Core Tools
 
 - `record_schema_get`
 - `record_list`
 - `record_get`
-- `record_write`
+- `record_insert`
+- `record_update`
+- `record_delete`
 - `record_code_block_run`
 - `record_import_template_get`
 - `record_import_verify`
@@ -39,7 +42,7 @@ Use exactly one of these default paths:
 `record_schema_get(schema_mode="applicant")` exposes the current user's applicant-node visible write/create fields.
 Its top-level `fields` now list only direct applicant-write fields; subtable leaf columns stay under the parent subtable field's `write_format.subfields`.
 `record_schema_get(schema_mode="browse", view_id=...)` exposes browse-schema fields for the selected accessible view.
-In browse mode, `writable=true` means `record_write(operation="update", view_id=...)` can target that field in the selected view; `writable=false` means the chosen view blocks direct update for that field.
+In browse mode, `writable=true` means `record_update` can target that field in the selected view; `writable=false` means the chosen view blocks direct update for that field.
 Read top-level `fields` and `suggested_*`; if a field is missing, treat it as unavailable in the current permission scope.
 
 ## Supporting Tools
@@ -72,7 +75,7 @@ Use `record_member_candidates` / `record_department_candidates` as the default l
 10. If the request is analysis-like, switch to [$qingflow-record-analysis](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-record-analysis/SKILL.md)
 11. If the request is write-like, decide `insert / update / delete` before building any payload
 12. For `insert`, stay on `schema_mode="applicant"` and do not introduce any view selector
-13. For `update`, call `app_get` first, choose an accessible view, and carry that `view_id` into `record_write`
+13. For `update`, call `app_get` first, choose an accessible view, and carry that `view_id` into `record_update`
 14. For subtable writes, use the parent subtable field and submit `rows/tableValues`; do not treat subtable leaf titles as top-level write selectors
 15. If fields are still ambiguous after `record_schema_get`, ask the user to confirm from a short candidate list instead of guessing
 16. For high-risk writes or production changes, read the current state first whenever practical
@@ -92,7 +95,10 @@ Use `record_member_candidates` / `record_department_candidates` as the default l
 
 ## Record Write Rules
 
-Use `record_write` as the only default write tool.
+Use the three direct-write tools as separate paths:
+- `record_insert` for create
+- `record_update` for edit
+- `record_delete` for delete
 
 ### Write workflow
 
@@ -100,56 +106,43 @@ Use `record_write` as the only default write tool.
 2. Decide whether the task is `insert`, `update`, or `delete`
 3. If this is workflow work for an ordinary assignee, switch to [$qingflow-task-ops](/Users/yanqidong/Documents/qingflow-next/.codex/skills/qingflow-task-ops/SKILL.md) instead of forcing direct CRUD
 4. If this is `insert`, stay on applicant schema only and do not pass any `view_*` selector
-5. If this is `update`, choose an accessible view first, inspect `record_schema_get(schema_mode="browse", view_id=...)`, and pass that `view_id` into `record_write`
-6. For relation fields, read `target_app_key / target_app_name` from schema first
-7. For member fields with unknown ids, run `record_member_candidates`
-8. For department fields with unknown ids, run `record_department_candidates`
-9. For subtable writes, target the parent subtable field and fill `rows/tableValues`; subtable leaf titles are not valid top-level `record_write` selectors
-10. Build SQL-like JSON clauses
-11. Run `record_write`
+5. If this is `update`, choose an accessible view first, inspect `record_schema_get(schema_mode="browse", view_id=...)`, and pass that `view_id` into `record_update`
+6. For relation fields, read `target_app_key / target_app_name / searchable_fields` from schema first
+7. For member, department, and relation fields, natural strings are allowed; the write path now tries backend-native auto resolution before it asks for confirmation
+8. If a member or department field still needs explicit lookup, run `record_member_candidates` or `record_department_candidates`
+9. For subtable writes, target the parent subtable field and fill row objects or `tableValues`; subtable leaf titles are not valid top-level selectors
+10. Build a field-title keyed `fields` map
+11. Run `record_insert`, `record_update`, or `record_delete`
 12. If `ok=false`, explain `field_errors` first, then summarize blockers; do not report a write as executed
 13. If `ok=true`, report the affected `record_id` or created resource
 14. For important writes, keep `verify_write=true`
 
-### SQL-like JSON DSL
-
-The DSL is clause-shaped like SQL, but it is **not raw SQL text**.
-
-| operation | required shape | compact example |
-|-----------|----------------|-----------------|
-| `insert` | `values` | `{"operation":"insert","values":[{"field_id":12,"value":"测试客户"}]}` |
-| `update` | `record_id + set` | `{"operation":"update","record_id":123,"set":[{"field_id":18,"value":2000}]}` |
-| `delete` | `record_id` or `record_ids` | `{"operation":"delete","record_ids":[123,124]}` |
-
 ### Write discipline
 
-- `insert` uses `values`
-- `update` uses `set`
-- `delete` uses `record_id` or `record_ids`
-- `insert` strictly follows applicant-node write scope and does not accept `view_id / list_type / view_key / view_name`
-- `update` must carry an explicit `view_id / list_type / view_key / view_name`; prefer `view_id` chosen from `app_get.accessible_views`
+- `record_insert` uses an applicant-node `fields` map keyed by field title
+- `record_update` uses a view-scoped `fields` map keyed by field title
+- `record_delete` uses `record_id` or `record_ids`
+- `record_insert` strictly follows applicant-node write scope and does not accept `view_id / list_type / view_key / view_name`
+- `record_update` should receive an explicit `view_id`; if omitted, the tool tries `system:all` first and fails clearly when that view is not accessible
 - `update` should be treated as “view-scoped direct edit”, not as a task or approval shortcut
 - `record_schema_get(schema_mode="browse").fields[*].writable` is the contract for whether the selected view allows direct update on that field
-- subtable writes must go through the parent subtable field with `rows/tableValues`; top-level subtable leaf selectors now fail fast
-- Do not send raw SQL text
-- Do not invent formulas or expressions
-- Do not use free-form `WHERE` updates or deletes
+- subtable writes must go through the parent subtable field with row objects or `tableValues`; top-level subtable leaf selectors now fail fast
 - Do not auto-fill missing fields
-- Do not auto-resolve relation targets without first querying them
-- Do not assume member display names resolve automatically; `record_member_candidates` returns the current field candidate scope, and write paths now reject member values outside that scope when it is supported
-- Do not assume department names resolve automatically; `record_department_candidates` returns the current field candidate scope, and write paths now reject department values outside that scope when it is supported
+- Member, department, and relation fields may accept natural strings when the backend candidate scope resolves them uniquely
+- If any lookup field returns `status="needs_confirmation"`, stop and surface `confirmation_requests`; do not submit a partial write
+- For relation fields, use schema `searchable_fields` as the mental model for what the backend will search; do not invent a custom match-field title
 - For default-all member or department fields, prefer the field candidate tools; do not start with `directory_*`
 - Do not invent member or department ids/names when a candidate tool is available; choose an exact returned candidate item
-- If member or department candidate lookup fails, stop and surface the lookup error; do not retry the write with guessed ids or names
+- If member, department, or relation auto resolution fails, stop and surface the lookup error; do not retry the write with guessed ids or names
 - Do not assume `record_schema_get` is a builder/full-field schema.
 
 ### Complex field quick examples
 
-- `member`: `✅ {"field_id":5,"value":{"id":7,"value":"张三"}}` / `✅ {"field_id":5,"value":"张三"}` only when it exactly matches a current candidate / `❌ {"field_id":5,"value":"不存在的成员"}`
-- `department`: `✅ {"field_id":22,"value":{"id":336193,"value":"北斗组"}}` / `✅ {"field_id":22,"value":"北斗组"}` only when it exactly matches a current candidate / `❌ {"field_id":22,"value":"不存在的部门"}`
-- `relation`: `✅ {"field_id":25,"value":{"apply_id":5001}}` / `❌ {"field_id":25,"value":"客户A"}`
-- `attachment`: upload first, then `✅ {"field_id":13,"value":{"value":"https://.../a.pdf","name":"a.pdf"}}` / `❌ {"field_id":13,"value":"/tmp/a.pdf"}`
-- `subtable`: `✅ {"field_id":18,"value":{"rows":[{"产品名称":"企业版","数量":2}]}}` / `✅ {"field_id":18,"value":{"tableValues":[{"queId":101,"values":[{"value":"企业版"}]},{"queId":102,"values":[{"value":2}]}]}}` / `❌ {"field_id":101,"value":"企业版"}`
+- `member`: `✅ {"负责人":{"id":7,"value":"张三"}}` / `✅ {"负责人":"张三"}` when it resolves uniquely in backend scope / `⚠️ {"负责人":"张三"}` may return `needs_confirmation` when multiple candidates match
+- `department`: `✅ {"所属部门":{"id":336193,"value":"北斗组"}}` / `✅ {"所属部门":"北斗组"}` when it resolves uniquely in backend scope / `⚠️ {"所属部门":"研发部"}` may return `needs_confirmation` when paths collide
+- `relation`: `✅ {"关联客户":{"apply_id":5001}}` / `✅ {"关联客户":"客户A"}` when it resolves uniquely inside schema `searchable_fields` / `⚠️ {"关联客户":"客户A"}` may return `needs_confirmation` when multiple records match
+- `attachment`: upload first, then `✅ {"合同附件":{"value":"https://.../a.pdf","name":"a.pdf"}}` / `❌ {"合同附件":"/tmp/a.pdf"}`
+- `subtable`: `✅ {"销售明细":[{"产品名称":"企业版","数量":2}]}` / `✅ {"销售明细":{"tableValues":[{"queId":101,"values":[{"value":"企业版"}]},{"queId":102,"values":[{"value":2}]}]}}` / `❌ {"产品名称":"企业版"}`
 
 ## Code Block Rules
 
@@ -182,7 +175,7 @@ Use `record_code_block_run` when the user wants to run a form code-block field a
 
 ## Import Rules
 
-Use the import tools for file-based bulk data loading, not `record_write`.
+Use the import tools for file-based bulk data loading, not `record_insert` or `record_update`.
 
 ### Import workflow
 
@@ -215,14 +208,14 @@ Use the import tools for file-based bulk data loading, not `record_write`.
 - `record_list` returns browse/sample data, not final analysis conclusions
 - If `view_id` is a custom view, treat the result as convenience browse output only when `warnings` includes `CUSTOM_VIEW_FILTER_UNVERIFIED`. In that case do not state the saved filter result as a verified fact.
 - Prefer `system:all` plus explicit `where` filters whenever the user needs a trustworthy scoped dataset.
-- `record_write` always performs internal static preflight before any apply
-- `record_write insert` is validated strictly against applicant-node create scope
-- `record_write update` is validated against the selected view for field scope, then against real record edit permission
+- `record_insert`, `record_update`, and `record_delete` always perform internal static preflight before any apply
+- `record_insert` is validated strictly against applicant-node create scope
+- `record_update` is validated against the selected view for field scope, then against real record edit permission
 - if a subtable leaf is missing from applicant top-level schema, that is expected; inspect the parent subtable field's `write_format.subfields`
-- If `record_write` returns `ok=false`, the write was blocked and not executed
-- If `record_write` raises `WRITE_PERMISSION_DENIED`, explain that direct edit permission is missing and prefer task-center actions for ordinary workflow users
+- If a direct-write tool returns `ok=false`, the write was blocked and not executed
+- If a direct-write tool raises `WRITE_PERMISSION_DENIED`, explain that direct edit permission is missing and prefer task-center actions for ordinary workflow users
 - Prefer explaining `field_errors` before summarizing top-level blockers
-- If `record_write` returns `ok=true`, still check `verification` and `warnings` before claiming success
+- If a direct-write tool returns `ok=true`, still check `verification` and `warnings` before claiming success
 - Prefer canonical schema titles and aliases in your final wording
 - If only part of the requested work is completed, explicitly disclose which parts are done and which are not
 

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

@@ -1,5 +1,4 @@
 interface:
   display_name: "Qingflow Record CRUD"
   short_description: "Browse, read, and write Qingflow records with schema-first DSLs"
-  default_prompt: "Use $qingflow-record-crud for Qingflow record browsing, detail lookup, and record_write operations. Start with record_schema_get, choose record_list, record_get, or record_write, and keep analysis work in $qingflow-record-analysis."
-
+  default_prompt: "Use $qingflow-record-crud for Qingflow record browsing, detail lookup, and direct record edits. Start with record_schema_get, choose record_list, record_get, record_insert, record_update, or record_delete, and keep analysis work in $qingflow-record-analysis."

package/skills/qingflow-record-crud/references/data-gotchas.md

@@ -13,21 +13,19 @@ For final statistics, grouped distributions, rankings, trends, or insight-style
 
 ## Write Preflight
 
-- `record_write` always performs internal static preflight before any apply
-- If `record_write` returns `ok=false`, the write was blocked and not executed
+- `record_insert`, `record_update`, and `record_delete` always perform internal static preflight before any apply
+- If a direct-write tool returns `ok=false`, the write was blocked and not executed
 - Explain `field_errors` before summarizing blockers
 - Use `record_schema_get` when field titles are uncertain instead of guessing ids
 - Prefer `verify_write=true` for complex, relation-heavy, subtable, or production writes
-- Even when `record_write` returns `ok=true`, it may still surface verification failures; do not report success before checking them
+- Even when a direct-write tool returns `ok=true`, it may still surface verification failures; do not report success before checking them
 
 ## Write Semantics
 
-- `insert` uses `values`
-- `update` uses `set`
-- `delete` uses `record_id` or `record_ids`
-- Do not send raw SQL strings
+- `record_insert` uses an applicant-node `fields` map
+- `record_update` uses a view-scoped `fields` map
+- `record_delete` uses `record_id` or `record_ids`
 - Do not fake formula or expression fields
-- Do not perform free-form bulk updates or deletes
 - Do not guess relation targets from display text; resolve the real `record_id` first
 
 ## Attachments

package/skills/qingflow-record-crud/references/environments.md

@@ -44,7 +44,7 @@ Production behavior:
 Production guardrails:
 
 - never assume a record id, app id, or workspace id
-- treat `record_write(operation="delete")` as high risk
+- treat `record_delete` as high risk
 - if the task can be answered read-only, do not write
 
 ## Reporting Rule
@@ -55,4 +55,3 @@ For record CRUD operations, always report:
 - target app
 - operation type: read, create, update, or delete
 - affected record count or ids
-

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

@@ -35,13 +35,13 @@ Without `columns`, `record_get` still returns only applicant-node visible fields
 
 ## Write Pattern
 
-Use `record_schema_get -> record_write`.
+Use `record_schema_get -> record_insert / record_update / record_delete`.
 
 1. Confirm the target app
 2. Resolve fields with `record_schema_get`
 3. Decide whether the task is `insert`, `update`, or `delete`
-4. Build SQL-like JSON clauses
-5. Run `record_write`
+4. Build a field-title keyed `fields` map for insert/update
+5. Run `record_insert`, `record_update`, or `record_delete`
 6. If `ok=false`, explain `field_errors` first, then summarize blockers; stop because the write was not executed
 7. If `ok=true`, report the affected resource and any verification outcome
 8. For important writes, keep `verify_write=true`
@@ -50,11 +50,11 @@ Use `record_schema_get -> record_write`.
 
 ```json
 {
-  "operation": "insert",
-  "values": [
-    { "field_id": 12, "value": "测试客户" },
-    { "field_id": 18, "value": 1000 }
-  ],
+  "app_key": "APP_1",
+  "fields": {
+    "客户名称": "测试客户",
+    "合同金额": 1000
+  },
   "submit_type": "submit",
   "verify_write": true
 }
@@ -64,11 +64,12 @@ Use `record_schema_get -> record_write`.
 
 ```json
 {
-  "operation": "update",
+  "app_key": "APP_1",
   "record_id": 123,
-  "set": [
-    { "field_id": 18, "value": 2000 }
-  ],
+  "fields": {
+    "合同金额": 2000
+  },
+  "view_id": "system:all",
   "verify_write": true
 }
 ```
@@ -77,7 +78,7 @@ Use `record_schema_get -> record_write`.
 
 ```json
 {
-  "operation": "delete",
+  "app_key": "APP_1",
   "record_ids": [123, 124]
 }
 ```
@@ -92,7 +93,7 @@ Do not do this:
 - do not auto-fill missing required fields
 - do not guess relation targets without first resolving them
 - do not guess hidden or missing fields from prior builder knowledge; if the field is absent from applicant-node schema, stop and explain the permission boundary
-- do not claim a blocked `record_write` was executed
+- do not claim a blocked direct write was executed
 
 ## Unsupported Direct Writes
 
@@ -103,12 +104,12 @@ Do not attempt direct writes for these field types:
 - `35` image generation
 - `36` document parsing
 
-If the payload includes them, stop after the blocked `record_write` response and explain that the tool does not support a reliable direct write for those fields yet.
+If the payload includes them, stop after the blocked response and explain that the tool does not support a reliable direct write for those fields yet.
 
 ## Relation, Attachment, and Subtable Rules
 
 - Relation fields are record-id based. Resolve the referenced target first, then write the relation field with the real `record_id`.
-- Attachment fields are two-step: upload first with `file_upload_local`, then reuse the returned attachment payload in `record_write`.
+- Attachment fields are two-step: upload first with `file_upload_local`, then reuse the returned attachment payload in `record_insert` or `record_update`.
 - Subtable writes require the current schema shape; when updating existing subtable rows, preserve row ids if the current record exposes them.
 
 ### Quick field examples

package/src/qingflow_mcp/server.py

@@ -53,7 +53,8 @@ If an accessible view has `analysis_supported=false`, do not use it for `record_
 
 ## Schema-First Rule
 
-Call `record_schema_get(schema_mode="applicant")` before `record_write`.
+Call `record_schema_get(schema_mode="applicant")` before `record_insert`.
+Call `record_schema_get(schema_mode="applicant")` before `record_code_block_run`.
 Call `app_get` first when the data range is unclear, then use `record_schema_get(schema_mode="browse", view_id=...)` before `record_list`, `record_get`, or `record_analyze`.
 
 - All `field_id` values must come from the schema response.
@@ -94,7 +95,9 @@ Analysis answers must include concrete numbers. When applicable, include percent
 ## Record CRUD Path
 
 `app_get -> record_schema_get(schema_mode="browse", view_id=...) -> record_list / record_get`
-`record_schema_get(schema_mode="applicant") -> record_write`
+`record_schema_get(schema_mode="applicant") -> record_insert`
+`app_get -> record_schema_get(schema_mode="browse", view_id=...) -> record_update`
+`record_list / record_get -> record_delete`
 `record_schema_get(schema_mode="applicant") -> record_code_block_run`
 
 - Use `columns` as `[{{field_id}}]`
@@ -102,14 +105,12 @@ Analysis answers must include concrete numbers. When applicable, include percent
 - Use `order_by` items as `{{field_id, direction}}`
 - Legacy forms such as bare integer `field_id`, `fieldId`, `operator`, `values`, or `order` may still parse, but they are compatibility-only and not the canonical DSL
 
-`record_write` uses SQL-like JSON clauses:
-
-- `insert` -> `values`
-- `update` -> `record_id + set`
-- `delete` -> `record_id` or `record_ids`
+- `record_insert` uses an applicant-node `fields` map keyed by field title.
+- `record_update` uses a view-scoped `fields` map keyed by field title.
+- `record_delete` deletes by `record_id` or `record_ids`.
 
 - Read relation targets from `record_schema_get.target_app_key` / `target_app_name` before preparing relation writes.
-- If a member or department field id is known but candidate ids are not, use `record_member_candidates` or `record_department_candidates` before `record_write`.
+- If a member or department field id is known but candidate ids are not, use `record_member_candidates` or `record_department_candidates` before `record_insert` or `record_update`.
 - For default-all member or department fields, prefer those field candidate tools instead of starting with `directory_*`.
 
 ## Code Block Path

package/src/qingflow_mcp/server_app_user.py

@@ -41,7 +41,8 @@ If an accessible view has `analysis_supported=false`, do not use it for `record_
 
 ## Schema-First Rule
 
-Call `record_schema_get(schema_mode="applicant")` before `record_write`.
+Call `record_schema_get(schema_mode="applicant")` before `record_insert`.
+Call `record_schema_get(schema_mode="applicant")` before `record_code_block_run`.
 Call `app_get` first when the data range is unclear, then use `record_schema_get(schema_mode="browse", view_id=...)` before `record_list`, `record_get`, or `record_analyze`.
 
 - All `field_id` values must come from the schema response.
@@ -82,7 +83,9 @@ Analysis answers must include concrete numbers. When applicable, include percent
 ## Record CRUD Path
 
 `app_get -> record_schema_get(schema_mode="browse", view_id=...) -> record_list / record_get`
-`record_schema_get(schema_mode="applicant") -> record_write`
+`record_schema_get(schema_mode="applicant") -> record_insert`
+`app_get -> record_schema_get(schema_mode="browse", view_id=...) -> record_update`
+`record_list / record_get -> record_delete`
 `record_schema_get(schema_mode="applicant") -> record_code_block_run`
 
 - Use `columns` as `[{{field_id}}]`
@@ -90,14 +93,12 @@ Analysis answers must include concrete numbers. When applicable, include percent
 - Use `order_by` items as `{{field_id, direction}}`
 - Legacy forms such as bare integer `field_id`, `fieldId`, `operator`, `values`, or `order` may still parse, but they are compatibility-only and not the canonical DSL
 
-`record_write` uses SQL-like JSON clauses:
-
-- `insert` -> `values`
-- `update` -> `record_id + set`
-- `delete` -> `record_id` or `record_ids`
+- `record_insert` uses an applicant-node `fields` map keyed by field title.
+- `record_update` uses a view-scoped `fields` map keyed by field title.
+- `record_delete` deletes by `record_id` or `record_ids`.
 
 - Read relation targets from `record_schema_get.target_app_key` / `target_app_name` before preparing relation writes.
-- If a member or department field id is known but candidate ids are not, use `record_member_candidates` or `record_department_candidates` before `record_write`.
+- If a member or department field id is known but candidate ids are not, use `record_member_candidates` or `record_department_candidates` before `record_insert` or `record_update`.
 - For default-all member or department fields, prefer those field candidate tools instead of starting with `directory_*`.
 
 ## Code Block Path