@josephyan/qingflow-app-builder-mcp 0.2.0-beta.71 → 0.2.0-beta.73

package/README.md

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@josephyan/qingflow-app-builder-mcp",
-  "version": "0.2.0-beta.71",
+  "version": "0.2.0-beta.73",
   "description": "Builder MCP for Qingflow app/package/system design and staged solution workflows.",
   "license": "MIT",
   "type": "module",

package/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "qingflow-mcp"
-version = "0.2.0b71"
+version = "0.2.0b73"
 description = "User-authenticated MCP server for Qingflow"
 readme = "README.md"
 license = "MIT"

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

@@ -48,7 +48,7 @@ Default modeling rules:
 
 - Authentication and workspace: `auth_*`, `workspace_*`
 - File upload: `file_upload_local`
-- Resource resolve/read: `package_list`, `package_resolve`, `package_create`, `builder_tool_contract`, `member_search`, `role_search`, `app_resolve`, `app_read_summary`, `app_read_fields`, `app_read_layout_summary`, `app_read_views_summary`, `app_read_flow_summary`, `app_read_charts_summary`, `portal_list`, `portal_get`, `portal_read_summary`, `view_get`, `chart_get`
+- Resource resolve/read: `package_list`, `package_resolve`, `package_create`, `builder_tool_contract`, `member_search`, `role_search`, `app_resolve`, `app_get`, `app_get_fields`, `app_get_layout`, `app_get_views`, `app_get_flow`, `app_get_charts`, `portal_list`, `portal_get`, `view_get`, `chart_get`
 - Resource patch: `app_schema_apply`, `app_layout_apply`, `app_flow_apply`, `app_views_apply`, `app_charts_apply`, `portal_apply`, `package_attach_app`, `app_release_edit_lock_if_mine`, `role_create`
 - Publish and verify: `app_publish_verify`
 
@@ -59,11 +59,10 @@ Note:
 - `app_schema_apply` / `app_layout_apply` / `app_flow_apply` / `app_views_apply` publish by default; pass `publish=false` only when you intentionally want to leave changes in draft.
 - `app_charts_apply` is immediate-live and does not publish; it resolves targets by `chart_id` first and then exact unique chart name.
 - `portal_apply` uses replace semantics for sections; remove a section by omitting it from the next full sections list. `publish=false` only guarantees draft/base-info updates, and `chart_ref/view_ref` resolve by `id/key` first and exact unique name second.
-- `app_read_charts_summary` is the compact discovery path for current chart inventory; use it before `app_charts_apply` when you need exact `chart_id` values.
-- `chart_get` returns one chart's base info, config, and concrete chart data; prefer it over low-level `qingbi_report_*` reads in public builder flows.
+- `app_get_charts` is the compact discovery path for current chart inventory; use it before `app_charts_apply` when you need exact `chart_id` values.
+- `chart_get` returns one chart's base info and config only; public builder flows should treat data reads as user-side access, not builder config access.
 - `portal_list` is the discovery path for accessible portals.
-- `portal_read_summary` is the compact discovery path for portal draft/live summaries; it returns section summaries, not the raw dash payload.
-- `portal_get` returns portal-level detail plus a component inventory; it does not inline chart/view detail.
+- `portal_get` returns portal-level config detail plus a component inventory; it does not inline chart/view detail or user-side chart/view data.
 - `view_get` returns one view's definition detail only; use `record_list` separately when you need rows from that view.
 - `app_schema_apply` / `app_layout_apply` / `app_flow_apply` / `app_views_apply` now perform planning, normalization, and dependency checks internally; when prechecks block, read the returned blocking issues and `suggested_next_call` directly from the apply result.
 - If you are unsure about a public builder tool's keys, aliases, presets, or minimal legal shape, call `builder_tool_contract` instead of guessing.
@@ -108,7 +107,7 @@ For builder work:
    - one app: continue with `app_resolve`
    - multi-app package/system: create or resolve the package, then create each app separately before adding relations
 3. Resolve the target app with `app_resolve` if the request is an update. Use exactly one selector mode: `app_key`, or `app_name + package_tag_id`.
-4. Read only the smallest summary you need: `app_read_summary`, `app_read_fields`, `app_read_layout_summary`, `app_read_views_summary`, `app_read_flow_summary`, `app_read_charts_summary`, `portal_read_summary`.
+4. Read only the smallest config slice you need: `app_get`, `app_get_fields`, `app_get_layout`, `app_get_views`, `app_get_flow`, `app_get_charts`, `portal_get`.
 5. Use `app_schema_apply` for create/upsert/remove field work. It publishes by default after the patch lands; noop schema requests do not publish.
 6. If the app must belong to a package, use `package_attach_app` explicitly after schema work with `tag_id + app_key` unless readback already shows the target `tag_id`.
 7. Use `app_layout_apply` only when the user is explicitly changing layout. Prefer the default `mode=merge`; use `mode=replace` only when you intend to place every field explicitly. It publishes by default after the patch lands; noop layout requests do not publish.
@@ -120,16 +119,16 @@ For builder work:
 For view work, keep the order strict:
 
 1. `builder_tool_contract`
-2. `app_read_fields`
-3. `app_read_views_summary`
+2. `app_get_fields`
+3. `app_get_views`
 4. `app_views_apply`
-5. `app_read_views_summary` again whenever `app_views_apply` returns `failed` or `partial_success`
+5. `app_get_views` again whenever `app_views_apply` returns `failed` or `partial_success`
 
 For flow work, keep the order strict:
 
 1. `builder_tool_contract`
-2. `app_read_fields`
-3. `app_read_flow_summary`
+2. `app_get_fields`
+3. `app_get_flow`
 4. `role_search` or `member_search` if assignees need to come from the directory
 5. `role_create` if the user wants a reusable role and no suitable role exists yet
 6. Start from a canonical preset when possible
@@ -143,10 +142,10 @@ For flow work, keep the order strict:
    - support `assignees.member_names` / `assignees.member_emails` / `assignees.member_uids`
 10. When a node must edit specific fields, declare `permissions.editable_fields`
 11. `app_flow_apply`
-12. `app_read_flow_summary` after apply whenever the user asked for verification or apply returns `partial_success`
-13. Use `app_read_charts_summary` before chart work whenever exact current `chart_id` values matter
+12. `app_get_flow` after apply whenever the user asked for verification or apply returns `partial_success`
+13. Use `app_get_charts` before chart work whenever exact current `chart_id` values matter
 14. Use `app_charts_apply` for QingBI chart creation and updates, not raw `qingbi_report_*` writes
-15. Use `portal_read_summary` before portal work whenever exact current draft/live section inventory matters
+15. Use `portal_get` before portal work whenever exact current portal config and section inventory matter
 16. Use `portal_apply` for builder-side portal work; treat sections as a full replacement list
 
 For additive work on existing systems:
@@ -201,7 +200,7 @@ For additive work on existing systems:
 - Treat post-write readback as the source of truth, not just write status codes
 - For views, a top-level `VIEW_APPLY_FAILED` does not prove all requested views failed. Read back the view list and verify which views actually landed.
 - For views, “view exists” is not the same as “filters are active”. If `app_views_apply` returns `partial_success`, `views_verified=false`, or `details.filter_mismatches`, report the view as created but the filters as unverified until readback confirms them.
-- If multiple views share the same name, do not guess which one to update. Read `view_key` from `app_read_views_summary` and pass it explicitly in `upsert_views[]`.
+- If multiple views share the same name, do not guess which one to update. Read `view_key` from `app_get_views` and pass it explicitly in `upsert_views[]`.
 - In final user-facing summaries, distinguish clearly between:
   - contract is visible / canonical shape is known
   - apply precheck succeeded
@@ -218,13 +217,13 @@ For additive work on existing systems:
 - Create one package: `package_create`
 - Read one public tool contract: `builder_tool_contract`
 - Resolve one app: `app_resolve`
-- Read one app summary: `app_read_summary`
-- Read fields only: `app_read_fields`
-- Read layout summary: `app_read_layout_summary`
-- Read views summary: `app_read_views_summary`
-- Read flow summary: `app_read_flow_summary`
-- Read chart summary: `app_read_charts_summary`
-- Read portal summary: `portal_read_summary`
+- Read one app summary: `app_get`
+- Read fields only: `app_get_fields`
+- Read layout summary: `app_get_layout`
+- Read views summary: `app_get_views`
+- Read flow summary: `app_get_flow`
+- Read chart summary: `app_get_charts`
+- Read portal config: `portal_get`
 - Search members for workflow assignees: `member_search`
 - Search roles for workflow assignees: `role_search`
 - Create reusable workflow role: `role_create`

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

@@ -117,7 +117,7 @@ The create route did not resolve in the current backend route context. Re-run `w
 
 ### `PACKAGE_ATTACH_FAILED`
 
-Do not retry schema creation. Re-run only `package_attach_app`, then verify with `app_read_summary`.
+Do not retry schema creation. Re-run only `package_attach_app`, then verify with `app_get`.
 
 ### Hierarchy modeling mistake
 

package/skills/qingflow-app-builder/references/flow-actors-and-permissions.md

@@ -17,8 +17,8 @@ Use this when the workflow needs real assignees or node-level editable field per
 
 ## Recommended order
 
-1. `app_read_fields`
-2. `app_read_flow_summary`
+1. `app_get_fields`
+2. `app_get_flow`
 3. `role_search`
 4. `member_search` when the user explicitly names people
 5. `role_create` when no reusable role exists and the user wants role-based routing
@@ -119,5 +119,5 @@ Use this when the workflow needs real assignees or node-level editable field per
 
 ### `UNKNOWN_FLOW_FIELD`
 
-- reread fields with `app_read_fields`
+- reread fields with `app_get_fields`
 - only pass real current field names to `permissions.editable_fields`

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

@@ -27,10 +27,10 @@
 ## Readback scope
 
 - Prefer summary reads over large raw payloads
-- Use `app_read_fields` before schema or view work
-- Use `app_read_layout_summary` before layout work
-- Use `app_read_flow_summary` before workflow work
-- Use `app_read_views_summary` before view work
+- Use `app_get_fields` before schema or view work
+- Use `app_get_layout` before layout work
+- Use `app_get_flow` before workflow work
+- Use `app_get_views` before view work
 
 ## Workflow dependencies
 
@@ -53,7 +53,7 @@
 - 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`
   - `permissions.editable_fields`
-- For view work, treat `columns` as the only canonical public key. `app_read_views_summary` and `app_views_apply` should all be read and written in that shape.
+- For view work, treat `columns` as the only canonical public key. `app_get_views` and `app_views_apply` should all be read and written in that shape.
 - For layout work, treat `title + rows` as the only canonical public section shape. `fields`, `field_ids`, and `columns` may appear in legacy/internal shapes, but they are not the preferred public write shape.
 - A created view is not enough to claim a filter succeeded. When `app_views_apply` returns `partial_success`, `views_verified=false`, or `details.filter_mismatches`, treat the view as present but the filter as unverified.
 - If duplicate view names exist, do not retry by name. Read the exact `view_key` and target that one.

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

@@ -13,20 +13,20 @@ Use these when you need a quick reminder of the standard v2 builder sequences.
 ## Update fields on an existing app
 
 1. `app_resolve`
-2. `app_read_fields`
+2. `app_get_fields`
 3. `app_schema_apply`
 
 ## Rework layout
 
-1. `app_read_layout_summary`
+1. `app_get_layout`
 2. `app_layout_apply`
 
 Prefer `mode=merge`. Use `mode=replace` only when every field placement is intentional.
 
 ## Add or update workflow
 
-1. `app_read_fields`
-2. `app_read_flow_summary`
+1. `app_get_fields`
+2. `app_get_flow`
 3. `role_search` or `member_search`
 4. `role_create` if the business wants a reusable role and no good exact role exists
 5. `app_flow_apply`
@@ -36,8 +36,8 @@ If it reports `FLOW_ASSIGNEE_REQUIRED`, resolve roles or members first and retry
 
 ## Add or update views
 
-1. `app_read_fields`
-2. `app_read_views_summary`
+1. `app_get_fields`
+2. `app_get_views`
 3. `app_views_apply`
 
 For both workflow and view work, prefer `suggested_next_call` over re-guessing arguments after a validation failure.
@@ -46,8 +46,8 @@ For both workflow and view work, prefer `suggested_next_call` over re-guessing a
 
 Prefer these fields after writes:
 
-- `app_read_summary.tag_ids`
-- `app_read_summary.publish_status`
-- `app_read_layout_summary.unplaced_fields`
-- `app_read_views_summary.views`
-- `app_read_flow_summary.nodes`
+- `app_get.tag_ids`
+- `app_get.publish_status`
+- `app_get_layout.unplaced_fields`
+- `app_get_views.views`
+- `app_get_flow.nodes`

package/skills/qingflow-app-builder/references/tool-selection.md

@@ -31,13 +31,13 @@ If the user asks for multiple forms/modules that relate to each other, this is a
 
 ## Summary reads
 
-- `app_read_summary`: overall app health, publish state, counts
-- `app_read_fields`: field names, types, required flags, section ids
-- `app_read_layout_summary`: sections, rows, unplaced fields
-- `app_read_views_summary`: current view names, types, columns, group-by
-- `app_read_flow_summary`: workflow enabled state, nodes, transitions
-- `app_read_charts_summary`: current chart ids, names, types, order
-- `portal_read_summary`: current draft/live portal metadata and compact section inventory
+- `app_get`: overall app config health, publish state, counts, and builder editability
+- `app_get_fields`: field names, types, required flags, section ids
+- `app_get_layout`: sections, rows, unplaced fields
+- `app_get_views`: current view names, types, columns, group-by
+- `app_get_flow`: workflow enabled state, nodes, transitions
+- `app_get_charts`: current chart ids, names, types, order
+- `portal_get`: current portal config detail and component inventory
 
 ## Apply tools
 
@@ -64,17 +64,17 @@ These execute normalized patches and publish by default unless `publish=false`.
 - Create a brand new multi-app system/package:
   `package_create/resolve -> per-app app_schema_apply -> package_attach_app per app -> relation field patches`
 - Update fields on an existing app:
-  `app_resolve -> app_read_fields -> app_schema_apply`
+  `app_resolve -> app_get_fields -> app_schema_apply`
 - Tidy layout:
-  `app_read_fields -> app_read_layout_summary -> builder_tool_contract (if shape is unclear) -> app_layout_apply`
+  `app_get_fields -> app_get_layout -> builder_tool_contract (if shape is unclear) -> app_layout_apply`
 - Add workflow:
-  `builder_tool_contract -> app_read_fields -> app_read_flow_summary -> role_search/member_search -> app_flow_apply -> app_read_flow_summary`
+  `builder_tool_contract -> app_get_fields -> app_get_flow -> role_search/member_search -> app_flow_apply -> app_get_flow`
 - Add views:
-  `builder_tool_contract -> app_read_fields -> app_read_views_summary -> app_views_apply -> app_read_views_summary`
+  `builder_tool_contract -> app_get_fields -> app_get_views -> app_views_apply -> app_get_views`
 - Add QingBI charts:
-  `builder_tool_contract -> app_read_fields -> app_read_charts_summary -> app_charts_apply -> app_read_charts_summary`
+  `builder_tool_contract -> app_get_fields -> app_get_charts -> app_charts_apply -> app_get_charts`
 - Create or update a portal:
-  `builder_tool_contract -> portal_read_summary -> portal_apply -> portal_read_summary`
+  `builder_tool_contract -> portal_get -> portal_apply -> portal_get`
 
 ## Avoid
 

package/skills/qingflow-app-builder/references/update-flow.md

@@ -5,8 +5,8 @@ Use this when the app already exists and the task is only about workflow.
 ## Minimal sequence
 
 1. `builder_tool_contract(tool_name="app_flow_apply")`
-2. `app_read_fields`
-3. `app_read_flow_summary`
+2. `app_get_fields`
+3. `app_get_flow`
 4. `role_search` or `member_search`
 5. `role_create` if the user wants a reusable directory role and no good role exists
 6. start from a canonical preset when possible
@@ -17,7 +17,7 @@ Use this when the app already exists and the task is only about workflow.
    Do not add a second approval/fill node with a new id unless you are intentionally replacing the skeleton.
    The MCP now auto-aligns the simplest single-node preset overrides, but still prefer explicit preset ids so the merged graph stays predictable.
 9. `app_flow_apply`
-10. `app_read_flow_summary` when apply returns `partial_success` or the user asked for verification
+10. `app_get_flow` when apply returns `partial_success` or the user asked for verification
 
 If you are unsure about presets or node shapes, call `builder_tool_contract(tool_name="app_flow_apply")` before guessing.
 
@@ -102,7 +102,7 @@ Preferred recovery:
 
 1. use the returned `suggested_next_call`
 2. apply the minimal schema patch
-3. rerun `app_read_fields`
+3. rerun `app_get_fields`
 4. rerun `app_flow_apply`
 
 ### `INVALID_FLOW_EDGE`
@@ -115,7 +115,7 @@ The workflow referenced a field name that does not exist, often in:
 
 - `permissions.editable_fields`
 
-Call `app_read_fields` and retry with the exact field names returned by the app.
+Call `app_get_fields` and retry with the exact field names returned by the app.
 
 ### `FLOW_NODE_TYPE_UNSUPPORTED`
 

package/skills/qingflow-app-builder/references/update-layout.md

@@ -4,8 +4,8 @@ Use this when fields already exist and the task is only about form grouping or o
 
 ## Minimal sequence
 
-1. `app_read_fields`
-2. `app_read_layout_summary`
+1. `app_get_fields`
+2. `app_get_layout`
 3. `builder_tool_contract` when the section shape is not already obvious
 4. `app_layout_apply`
 
@@ -38,7 +38,7 @@ Apply a custom layout with the canonical public section shape:
 
 ### `UNKNOWN_LAYOUT_FIELD`
 
-At least one field name does not exist. Re-read with `app_read_fields`.
+At least one field name does not exist. Re-read with `app_get_fields`.
 
 ### `DUPLICATE_LAYOUT_FIELD`
 
@@ -50,7 +50,7 @@ Only happens in `mode=replace`. Switch to `mode=merge` unless you intend to plac
 
 ### `LAYOUT_APPLY_FAILED`
 
-Re-read with `app_read_layout_summary`. Check `current_field_names`, `request_id`, and `suggested_next_call`.
+Re-read with `app_get_layout`. Check `current_field_names`, `request_id`, and `suggested_next_call`.
 
 ### `VALIDATION_ERROR`
 

package/skills/qingflow-app-builder/references/update-schema.md

@@ -5,7 +5,7 @@ Use this when the app already exists and the task is only about fields.
 ## Minimal sequence
 
 1. `app_resolve`
-2. `app_read_fields`
+2. `app_get_fields`
 3. `app_schema_apply`
 
 ## Example
@@ -14,7 +14,7 @@ Read current fields first:
 
 ```json
 {
-  "tool_name": "app_read_fields",
+  "tool_name": "app_get_fields",
   "arguments": {
     "profile": "default",
     "app_key": "APP_123"
@@ -48,7 +48,7 @@ Apply the patch:
 
 ### `FIELD_NOT_FOUND`
 
-The selector did not match current schema. Re-read with `app_read_fields` and use `name`, `field_id`, or `que_id`.
+The selector did not match current schema. Re-read with `app_get_fields` and use `name`, `field_id`, or `que_id`.
 
 ### `DUPLICATE_FIELD`
 
@@ -56,7 +56,7 @@ The field already exists with a different shape. Switch from `add_fields` to `up
 
 ### `SCHEMA_APPLY_FAILED`
 
-Treat it as uncertain write state. Read back with `app_read_fields` before retrying.
+Treat it as uncertain write state. Read back with `app_get_fields` before retrying.
 
 ## Notes
 

package/skills/qingflow-app-builder/references/update-views.md

@@ -5,10 +5,10 @@ Use this when the task is only about table, card, board, or gantt views.
 ## Minimal sequence
 
 1. `builder_tool_contract(tool_name="app_views_apply")`
-2. `app_read_fields`
-3. `app_read_views_summary`
+2. `app_get_fields`
+3. `app_get_views`
 4. `app_views_apply`
-5. `app_read_views_summary` again whenever apply returns `failed` or `partial_success`
+5. `app_get_views` again whenever apply returns `failed` or `partial_success`
 
 If you are unsure about keys or view types, call `builder_tool_contract(tool_name="app_views_apply")` before guessing.
 
@@ -27,7 +27,7 @@ Canonical rules before any example:
 - Treat `fields` only as a legacy alias the MCP may normalize, not as the preferred shape
 - Use `filters` with canonical keys `field_name`, `operator`, `value`/`values`
 - For gantt, use `start_field`, `end_field`, and optionally `title_field`
-- If `app_read_views_summary` shows duplicate view names, include `view_key` in `upsert_views[]` and update that exact target
+- If `app_get_views` shows duplicate view names, include `view_key` in `upsert_views[]` and update that exact target
 
 Apply a default table view:
 
@@ -136,7 +136,7 @@ Do not repeat `app_views_apply` with guessed keys. First:
 
 1. check `suggested_next_call`
 2. reuse `canonical_arguments` if present
-3. call `app_read_views_summary` to see whether any requested views landed anyway
+3. call `app_get_views` to see whether any requested views landed anyway
 4. if needed, call `builder_tool_contract`
 5. retry only the minimal failed view patch
 
@@ -155,8 +155,8 @@ Do not tell the user the filter is active until the readback verification matche
 
 - `fields` is accepted as an alias for `columns`, but skill examples should still use `columns`
 - `column_names` should not appear in skill examples
-- `app_read_views_summary` should be treated as canonical readback and now returns `columns`
-- If `app_views_apply` returns `AMBIGUOUS_VIEW`, stop and re-run `app_read_views_summary`; then retry with the exact `view_key`
+- `app_get_views` should be treated as canonical readback and now returns `columns`
+- If `app_views_apply` returns `AMBIGUOUS_VIEW`, stop and re-run `app_get_views`; then retry with the exact `view_key`
 - `filters` are ANDed together as one flat condition group
 - `app_views_apply` publishes by default
 - For select-style filters, success means the backend preserved the option value in readback, not just that the view name now exists

package/src/qingflow_mcp/backend_client.py

@@ -4,6 +4,7 @@ from dataclasses import dataclass
 from threading import Event
 from time import sleep
 from typing import Any
+from urllib.parse import urlsplit, urlunsplit
 from uuid import uuid4
 
 import httpx

package/src/qingflow_mcp/builder_facade/models.py

@@ -187,7 +187,8 @@ class FlowConditionRulePatch(StrictModel):
             return value
         payload = dict(value)
         if "value" in payload and "values" not in payload:
-            payload["values"] = [payload.pop("value")]
+            raw_value = payload.pop("value")
+            payload["values"] = list(raw_value) if isinstance(raw_value, list) else [raw_value]
         raw_operator = payload.get("operator", payload.get("op"))
         if isinstance(raw_operator, str):
             normalized = raw_operator.strip().lower()
@@ -238,7 +239,8 @@ class ViewFilterRulePatch(StrictModel):
             return value
         payload = dict(value)
         if "value" in payload and "values" not in payload:
-            payload["values"] = [payload.pop("value")]
+            raw_value = payload.pop("value")
+            payload["values"] = list(raw_value) if isinstance(raw_value, list) else [raw_value]
         raw_operator = payload.get("operator", payload.get("op"))
         if isinstance(raw_operator, str):
             normalized = raw_operator.strip().lower()
@@ -1092,7 +1094,8 @@ class ChartFilterRulePatch(StrictModel):
             return value
         payload = dict(value)
         if "value" in payload and "values" not in payload:
-            payload["values"] = [payload.pop("value")]
+            raw_value = payload.pop("value")
+            payload["values"] = list(raw_value) if isinstance(raw_value, list) else [raw_value]
         raw_operator = payload.get("operator", payload.get("op"))
         if isinstance(raw_operator, str):
             normalized = raw_operator.strip().lower()
@@ -1338,7 +1341,7 @@ class PortalApplyRequest(StrictModel):
 FieldPatch.model_rebuild()
 
 
-class AppReadSummaryResponse(StrictModel):
+class AppGetResponse(StrictModel):
     app_key: str
     title: str | None = None
     app_icon: str | None = None
@@ -1349,39 +1352,48 @@ class AppReadSummaryResponse(StrictModel):
     view_count: int = 0
     workflow_enabled: bool = False
     verification_hints: list[str] = Field(default_factory=list)
+    editability: dict[str, bool | None] = Field(default_factory=dict)
 
 
-class AppFieldsReadResponse(StrictModel):
+class AppGetFieldsResponse(StrictModel):
     app_key: str
     fields: list[dict[str, Any]] = Field(default_factory=list)
     field_count: int = 0
 
 
-class AppLayoutReadResponse(StrictModel):
+class AppGetLayoutResponse(StrictModel):
     app_key: str
     sections: list[dict[str, Any]] = Field(default_factory=list)
     unplaced_fields: list[str] = Field(default_factory=list)
     layout_mode_detected: str = "empty"
 
 
-class AppViewsReadResponse(StrictModel):
+class AppGetViewsResponse(StrictModel):
     app_key: str
     views: list[dict[str, Any]] = Field(default_factory=list)
 
 
-class AppFlowReadResponse(StrictModel):
+class AppGetFlowResponse(StrictModel):
     app_key: str
     enabled: bool = False
     nodes: list[dict[str, Any]] = Field(default_factory=list)
     transitions: list[dict[str, Any]] = Field(default_factory=list)
 
 
-class AppChartsReadResponse(StrictModel):
+class AppGetChartsResponse(StrictModel):
     app_key: str
     charts: list[dict[str, Any]] = Field(default_factory=list)
     chart_count: int = 0
 
 
+AppReadSummaryResponse = AppGetResponse
+AppFieldsReadResponse = AppGetFieldsResponse
+AppLayoutReadResponse = AppGetLayoutResponse
+AppViewsReadResponse = AppGetViewsResponse
+AppFlowReadResponse = AppGetFlowResponse
+AppChartsReadResponse = AppGetChartsResponse
+
+
 class PortalListResponse(StrictModel):
     items: list[dict[str, Any]] = Field(default_factory=list)
     total: int = 0
@@ -1415,7 +1427,7 @@ class PortalGetResponse(StrictModel):
 
 
 class ViewGetResponse(StrictModel):
-    viewgraph_key: str
+    view_key: str
     base_info: dict[str, Any] = Field(default_factory=dict)
     config: dict[str, Any] = Field(default_factory=dict)
     questions: list[dict[str, Any]] = Field(default_factory=list)
@@ -1426,7 +1438,6 @@ class ChartGetResponse(StrictModel):
     chart_id: str
     base: dict[str, Any] = Field(default_factory=dict)
     config: dict[str, Any] = Field(default_factory=dict)
-    data: dict[str, Any] = Field(default_factory=dict)
 
 
 class SchemaPlanRequest(StrictModel):