Form designer

form-designer

Design, read, and normalize SmartCMP Angular form schema JSON only. It does not submit requests or save changes.

Boundaries

• No submit/approve/status workflows.
• No CMP form writes: no POST, PUT, PATCH, DELETE, publish, save, or delete.
• Form URLs are read-only source material.

Workflow

• New form: if the user gave enough fields, do not read CMP or call datasource tools. Build complete schema_json, then call smartcmp_design_form_schema with mode=new.
• Bare form edit/design URL: inspect only. Call smartcmp_read_form_schema; do not design.
• URL plus full field-set or schema-shape changes: treat this as new-form generation with one extra read step. First call smartcmp_read_form_schema to understand the current form, then generate a fresh complete replacement schema from the user's latest requirements and call design with mode=regenerate. Use the old schema only as context; do not patch, splice, or preserve existing fields/JavaScript unless the user explicitly asks to keep them.
• URL plus deterministic projection/composition changes: after the read step, call smartcmp_design_form_schema with mode=modify, form_url, and value_expressions_json. This lets the tool load the source schema and replace the target expression with the hardened runtime expression instead of asking the LLM to hand-copy the old schema or JavaScript.
• mode=modify is only for complete caller-provided JSON, deterministic catalog_fields_json insertion, or deterministic value_expressions_json updates into a supplied schema_json or form_url source. Never call mode=modify with only mode or only insertion/update JSON; that would create an incomplete replacement schema.
• If a read result warns that a field expression is not function(model, sourceParams, schema, unused, cfg), do not answer by hand-writing a replacement schema_json with another legacy signature such as function(formInRet, schemas, widget, injection). For catalog/model value rewrites, use value_expressions_json; for custom JavaScript, provide a complete modern-signature expression that writes model[fieldKey].
• If read/design output reports designMode, modelKeys, or componentCount, tell the user the source form has visual-designer/model state that can preserve stale runtime values even when the schema expression changes. The generated schema is still a manual replacement draft; SmartCMP persistence and visual designer state must be reviewed in CMP.

General JavaScript Form Extensions

Use this skill for general SmartCMP form JavaScript extension work. The scripts provide generic validation, normalize structure, preserve unknown keys, and warn about JavaScript risk; they must not perform business semantic inference from field labels, expression substrings, or familiar variable names.

Prefer explicit field-level JavaScript for dynamic behavior. When the user asks for computed values, visibility, linkage, validation, or non-catalog model reads, generate the requested JavaScript directly under the relevant SmartCMP key, usually config.value.expression with source: "mock" and method: "mock" for computed values. Service-catalog context reads are the exception: do not hand-write sourceParams.<key>, sourceParams['<key>'], or label-based guesses such as sourceParams['业务组']; use value_expressions_json with catalog aliases so _catalog_fields.py and the generated fallback paths decide the runtime source. The LLM owns the business meaning of the generated JavaScript; the script layer is not the source of business semantics.

Catalog context is reference/catalog metadata for generating JavaScript, not a fixed synchronization feature. catalog-provided context values are read-only inputs to the generated expression. Do not add projection source values as form fields unless the user explicitly asks to show or edit them. Do not rely on catalog_fields_json to satisfy catalog context needs; use it only when the user explicitly asks to insert or display a SmartCMP standard catalog field.

value_expressions_json is an optional compatibility helper for deterministic projection/composition cases that already fit its limited data shape. In plain terms, value_expressions_json is an optional compatibility helper, not the default design path. Do not use value_expressions_json as the default path for general SmartCMP JavaScript work, and do not force a custom JavaScript request into this helper. When using this helper, keep these contracts:

• Service-catalog context derived fields are not general custom JavaScript. If the user asks a target field to be filled from standard service-catalog context, use value_expressions_json with field/$field catalog aliases unless the user provides complete custom JavaScript that reads verified paths instead of direct sourceParams keys.
• User-enumerated fields are visible by default. Do not mark requested fields as hidden, titleless, off-screen, or non-editable unless the user explicitly asks for hidden or technical behavior. Field names do not imply hidden compatibility behavior by themselves.
• value_expressions_json is always a JSON array string. For one computed target, pass a one-element array.
• A form field is a user-facing/request parameter in schema.properties. A source value used only to compute another field is not a form field.
• When the user enumerates fields or gives a field count, pass requested_fields_json with exactly those top-level business form field keys, in order. Every item must be a non-empty string. This is for any number of fields; do not include source/dependency values used only by value_expressions_json, and do not include hidden SmartCMP technical fields such as schemaFormValid. The design tool rejects missing requested fields.
• Exact field-set constraints can be expressed in any wording or language. Infer them from the user's intended scope, not by matching a fixed keyword list. When the user constrains the exact field set or field count, schema.properties and fieldsets contain exactly those requested business form fields plus any hidden SmartCMP technical fields added by the design tool.
• fieldKey is always the exact requested target field. There is no default target.
• Use valueType when the backend requires the submitted parameter type: string, jsonString, object, or array. object/array submit raw structured model[fieldKey] values while the schema field stays a type: "string" / widget.id: "string" control so SmartCMP executes config.value.expression; jsonString submits valid JSON text; string submits formatted text. If omitted, the tool infers object or array from an existing target field schema type before falling back to string.
• Choose exactly one value shape per request: top-level fields for a flat object, or compose for the exact nested object/array/string structure the target field should receive. Never send both fields and compose for the same fieldKey.
• fields maps unique output labels to source reads and is only a shorthand for flat JSON such as {"名称":"..."}. Each item uses a label plus either field for a catalog alias or path for an exact model path. Do not repeat label to imply a parent key or group.
• compose is the target output structure itself. Plain object keys become literal output keys; source reads must be single-key leaf markers using field/$field, path/$path, $literal, or $concat.
• For any nested, grouped, array, or complex concatenation request, copy the requested output structure into compose before resolving source reads. Decompose complex output into leaf source reads, then combine those leaves with the surrounding JSON structure or $concat.
• When the final target value is a single formatted string, use one top-level $concat containing literal text and source marker leaves. Do not model that final string as a plain object unless the user explicitly asks for JSON object output.
• Do not invent helper metadata, placeholders, or alternate mini-languages inside value_expressions_json; if a key is not one of the supported source markers, the tool treats it as output data.
• Source reads use field/$field for known catalog aliases with fallback candidate paths, or path/$path for exact model paths with no parent-path fallback.
• Do not add source/dependency values as form fields unless the user explicitly asks to show or edit those values.
• Preserve requested visibility and titles. Value-expression target fields stay executable scalar controls; use valueType for the runtime submitted value type instead of turning the schema field into an object or array container. Do not default value-expression target fields to hidden, titleless, or non-editable.
• Return an empty string until at least one source value resolves.

Only these catalog aliases are supported: name/名称, owners/所有者, projects/应用系统, businessGroup/业务组.

For custom JavaScript, provide a complete function string under config.value.expression with source: "mock" and method: "mock". The design tool rejects literal ellipsis placeholder JavaScript. Keep Chinese labels as literal UTF-8 text, not Unicode escape sequences.

Common Widget Contracts

Use the SmartCMP widget shape, not generic web-control names:

• Text input: type: "string" with widget.id: "string".
• Number input: type: "number" with widget.id: "number" and range validation when known.
• Checkbox: type: "boolean" with widget.id: "checkbox".
• Select: type: "string", format: "uiselect", widget.id: "select", and default: null when a placeholder should show.
• Multi-select: type: "array" or type: "string", format: "uiselect", widget.id: "select", plus selectMode: "multiple".
• Static options: use field-level selectDatas with display labels and stored values; do not hide option data inside widget.
• Tables: top-level table fields use type: "array" with widget.id: "table-head"; row schema lives under items.properties, and items.fieldsets lists row columns.
• User-facing text should prefer i18nTitle, i18nPlaceholder, and i18nDescription when Chinese/English rendering matters.
• Required fields use required/isRequired; keep schema.required consistent when the target renderer expects root required lists.
• Description-only Angular2 schemas still need non-empty properties; add a hidden placeholder property instead of returning a schema with only description text.

Schema Rules

• Root: type: object with properties and widget.id: "object".
• properties and fieldsets must match the requested business form-field set; computed-value dependencies do not expand that set, and hidden SmartCMP technical fields such as schemaFormValid are the only allowed tool-added exception.
• When adding fields through catalog_fields_json or value_expressions_json, the generated target fields must also be present in root fieldsets.
• Root fieldsets use the catalog-request-compatible id fieldset-default; requested business fields use stable 1-based top-level index values in display order, while hidden SmartCMP technical fields do not participate in business field indexing.
• Top-level fields: stable id, numeric index, matching type, and widget.id (string, not text, for string inputs).
• Include config.visibility.allowInRequest and allowInApproval unless the user supplied different visibility.
• Preserve unknown keys, hidden, condition, fieldsets, selectDatas, value, and items.

Output

Return the exact normalized schema text from smartcmp_design_form_schema as a fenced json block. All string values inside the returned JSON are opaque. Do not add, remove, rename, move, summarize, or abbreviate any property or string value. Do not summarize, abbreviate, reorder, rename, or replace long JavaScript strings with ....

For URL-based regenerate or modify work, state that the result is a replacement schema for manual review and copying. Do not imply that the tool saved, updated, or published the CMP form.