@josephyan/qingflow-app-builder-mcp 0.2.0-beta.67 → 0.2.0-beta.69

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -3,13 +3,13 @@
3
3
  Install:
4
4
 
5
5
  ```bash
6
- npm install @josephyan/qingflow-app-builder-mcp@0.2.0-beta.67
6
+ npm install @josephyan/qingflow-app-builder-mcp@0.2.0-beta.69
7
7
  ```
8
8
 
9
9
  Run:
10
10
 
11
11
  ```bash
12
- npx -y -p @josephyan/qingflow-app-builder-mcp@0.2.0-beta.67 qingflow-app-builder-mcp
12
+ npx -y -p @josephyan/qingflow-app-builder-mcp@0.2.0-beta.69 qingflow-app-builder-mcp
13
13
  ```
14
14
 
15
15
  Environment:
@@ -23,6 +23,7 @@ This package bootstraps a local Python runtime on first install and then starts
23
23
  Bundled skills:
24
24
 
25
25
  - `skills/qingflow-app-builder`
26
+ - `skills/qingflow-app-builder-code-integrations`
26
27
 
27
28
  Note:
28
29
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@josephyan/qingflow-app-builder-mcp",
3
- "version": "0.2.0-beta.67",
3
+ "version": "0.2.0-beta.69",
4
4
  "description": "Builder MCP for Qingflow app/package/system design and staged solution workflows.",
5
5
  "license": "MIT",
6
6
  "type": "module",
package/pyproject.toml CHANGED
@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
4
4
 
5
5
  [project]
6
6
  name = "qingflow-mcp"
7
- version = "0.2.0b67"
7
+ version = "0.2.0b69"
8
8
  description = "User-authenticated MCP server for Qingflow"
9
9
  readme = "README.md"
10
10
  license = "MIT"
@@ -0,0 +1,137 @@
1
+ ---
2
+ name: qingflow-app-builder-code-integrations
3
+ description: Configure Qingflow code block and Q-Linker fields through the builder surface when the task involves input field insertion, alias parsing, target field binding, or troubleshooting broken code/q-linker form configurations. Use after MCP is connected and authenticated, especially for CRM-style scoring, lookup, and enrichment forms.
4
+ metadata:
5
+ short-description: Configure Qingflow code blocks and Q-Linkers safely
6
+ ---
7
+
8
+ # Qingflow App Builder Code Integrations
9
+
10
+ Use this skill when the user wants to build or repair:
11
+ - `code_block` fields
12
+ - `q_linker` fields
13
+ - output alias parsing
14
+ - target field binding
15
+ - form configurations that depend on code block or Q-Linker relations
16
+
17
+ Do not use this skill for MCP setup, generic field CRUD, or runtime execution debugging unless those are strictly supporting code block or Q-Linker configuration work.
18
+
19
+ ## Core Rule
20
+
21
+ Treat code blocks and Q-Linkers as **integration fields**, not ordinary fields.
22
+
23
+ For both of them, the public builder request may look like one step, but the real backend form structure has multiple layers. Never invent a new backend meaning. Only compile into the backend structures that already exist.
24
+
25
+ ## Mental Model
26
+
27
+ ### Code block
28
+
29
+ There are three conceptual layers:
30
+
31
+ 1. Code block field itself
32
+ 2. Parsed output aliases
33
+ 3. Target field bindings
34
+
35
+ Current builder support:
36
+ - configure the code block field itself
37
+ - configure input insertion into code content
38
+ - configure alias parsing
39
+
40
+ Important:
41
+ - keep `qf_output = {...}` as a plain assignment
42
+ - do not emit `const qf_output =` or `let qf_output =`
43
+
44
+ ### Q-Linker
45
+
46
+ There are two conceptual layers:
47
+
48
+ 1. Q-Linker field itself via `remoteLookupConfig`
49
+ 2. Target field bindings via relation-default + `questionRelations(relationType=Q_LINKER)`
50
+
51
+ Current builder support:
52
+ - one-step high-level config through `q_linker_binding`
53
+ - internal compilation into existing backend payloads
54
+
55
+ ## Operating Order
56
+
57
+ For code block or Q-Linker work, use this order:
58
+
59
+ 1. Resolve the app and read fields:
60
+ - `app_resolve`
61
+ - `app_read_fields`
62
+ 2. Confirm the target field set already exists.
63
+ 3. Apply schema updates with `app_schema_apply`.
64
+ 4. Read fields again and verify:
65
+ - field type
66
+ - alias config
67
+ - target field binding shape
68
+ 5. For page-safety checks, use user-side schema or insert checks:
69
+ - `record_insert_schema_get`
70
+ - optional safe `record_insert`
71
+
72
+ Do not treat raw apply success as enough. Always re-read the field config.
73
+
74
+ ## Code Block Rules
75
+
76
+ Read [references/code-block.md](references/code-block.md) before changing a code block field.
77
+
78
+ Use builder high-level config only for:
79
+ - input field insertion
80
+ - code content
81
+ - alias parsing
82
+ - auto trigger
83
+ - custom button text
84
+
85
+ When binding outputs to target fields, do not guess payload shape from memory. Follow the current builder implementation and the readback shape.
86
+
87
+ Hard rules:
88
+ - target fields must already exist
89
+ - keep target field types business-compatible
90
+ - if a page starts hanging on “关联中”, inspect whether the target field default type or relation config was written incorrectly
91
+
92
+ ## Q-Linker Rules
93
+
94
+ Read [references/q-linker.md](references/q-linker.md) before changing a Q-Linker field.
95
+
96
+ First-stage stable support is only:
97
+ - custom mode
98
+ - request config
99
+ - alias parsing
100
+ - target field binding
101
+ - auto trigger / button text
102
+
103
+ Do not generate:
104
+ - template mode
105
+ - openApp/light-wing branches
106
+ - subtable table-match bindings
107
+
108
+ Hard rules:
109
+ - `outputs[*].target_field` is required
110
+ - use only supported target field types
111
+ - on rebinding, old target fields must be restored from relation-default to safe default type
112
+ - `resultFormatPath` must preserve backend-required alias metadata
113
+
114
+ ## Verification Checklist
115
+
116
+ After each code block or Q-Linker change, verify all of these:
117
+
118
+ - `app_read_fields` shows the intended field type
119
+ - the high-level config is readable and stable
120
+ - target fields still have valid types
121
+ - insert schema can be opened
122
+ - record insert does not get blocked by malformed integration config
123
+
124
+ If the task explicitly includes runtime verification, keep it separate from configuration verification.
125
+
126
+ ## Common Pitfalls
127
+
128
+ - Writing code block code with `const qf_output =`
129
+ - Treating a Q-Linker or code block binding as a plain field default
130
+ - Forgetting to restore old target fields after unbinding
131
+ - Using unsupported target field types
132
+ - Assuming apply success means the form page can open
133
+
134
+ ## References
135
+
136
+ - Code block details: [references/code-block.md](references/code-block.md)
137
+ - Q-Linker details: [references/q-linker.md](references/q-linker.md)
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Qingflow Code Integrations"
3
+ short_description: "Configure Qingflow code block and Q-Linker fields safely"
4
+ default_prompt: "Use $qingflow-app-builder-code-integrations when configuring Qingflow code block or Q-Linker fields, especially when input insertion, alias parsing, target field binding, or page-safety verification matter."
@@ -0,0 +1,40 @@
1
+ # Code Block Builder Notes
2
+
3
+ ## What Builder Should Configure
4
+
5
+ - code block field type
6
+ - code content
7
+ - inserted input fields inside code content
8
+ - alias parsing
9
+ - auto trigger
10
+ - custom button text
11
+
12
+ ## Stable Writing Rules
13
+
14
+ - Always emit `qf_output = {...}`
15
+ - Never emit `const qf_output = {...}`
16
+ - Never emit `let qf_output = {...}`
17
+
18
+ ## Useful CRM Pattern
19
+
20
+ Inputs:
21
+ - customer name
22
+ - source
23
+ - budget
24
+ - timing
25
+ - decision-maker flag
26
+
27
+ Outputs:
28
+ - score
29
+ - level
30
+ - priority
31
+ - summary
32
+ - next follow date
33
+
34
+ ## Safe Verification
35
+
36
+ - `app_read_fields`
37
+ - `record_insert_schema_get`
38
+ - optional `record_code_block_run`
39
+
40
+ Treat configuration verification and runtime verification as separate checks.
@@ -0,0 +1,74 @@
1
+ # Q-Linker Builder Notes
2
+
3
+ ## What Builder Should Configure
4
+
5
+ - `remoteLookupConfig`
6
+ - alias parsing
7
+ - target field binding
8
+ - auto trigger
9
+ - custom button text
10
+
11
+ ## Current Supported Scope
12
+
13
+ - custom mode only
14
+ - standard request fields
15
+ - alias path parsing
16
+ - target field binding to existing ordinary fields
17
+
18
+ ## Recommended Public APIs For Samples
19
+
20
+ ### Httpbin
21
+
22
+ - URL: `https://httpbin.org/get`
23
+ - Good for:
24
+ - query echo
25
+ - request URL echo
26
+
27
+ Useful paths:
28
+ - `$.args.keyword`
29
+ - `$.url`
30
+
31
+ ### Open-Meteo Geocoding
32
+
33
+ - URL: `https://geocoding-api.open-meteo.com/v1/search`
34
+ - Good for:
35
+ - place normalization
36
+ - country
37
+ - lat/lng summary
38
+
39
+ Useful paths:
40
+ - `$.results[0].name`
41
+ - `$.results[0].country`
42
+ - `$.results[0].latitude`
43
+ - `$.results[0].longitude`
44
+
45
+ ## Target Field Rules
46
+
47
+ Prefer:
48
+ - text
49
+ - long text
50
+ - number
51
+ - amount
52
+ - date
53
+ - datetime
54
+ - single select
55
+ - multi select
56
+ - boolean
57
+
58
+ Avoid:
59
+ - q_linker
60
+ - code_block
61
+ - relation
62
+ - subtable
63
+ - attachment
64
+ - member
65
+ - department
66
+ - address
67
+
68
+ ## Safe Verification
69
+
70
+ - `app_read_fields`
71
+ - `record_insert_schema_get`
72
+ - `record_insert`
73
+
74
+ This verifies that the configuration does not break the form page, even before runtime execution is tested.