update: config, fix: bug

.agents/skills/subject-schema-manager/SKILL.md

+---
+name: subject-schema-manager
+description: Sync Stream Subject definitions from the API into project documentation, remove unreferenced object sections, and apply confirmed object/field/configuration changes through the documented Subject API.
+---
+
+# Subject Schema Manager
+
+Use this skill when the user asks to synchronize Subject/object documentation or asks the AI to create, update, or configure Stream Subjects and fields.
+
+## Source of truth
+
+- The live Subject API is authoritative for object and field structure.
+- Read the repository's `SUBJECT_API.md`, `SUBJECT_CONFIGURATION.md`, `record-api.md`, and `subjectsDefinition.md` before acting. Prefer `src/services/record-api.md` and `src/services/subjectsDefinition.md` when the files exist there.
+- `subjectsDefinition.md` is a versioned, human-readable snapshot generated from the API. It is not a runtime API client.
+- Form resources are managed by `/form`; do not treat a `form` field as a Subject dependency.
+
+## Modes
+
+### `sync`
+
+Use for requests to update object documentation or remove copied-project objects.
+
+1. Discover Subject roots from static Subject constants and literal Subject API calls in the project's source. Prefer explicit roots supplied by the user or the script's `--roots` option when discovery is ambiguous.
+2. Exchange the supplied ticket for a token using `POST /auth/login` with `{ "type": "ticket", "ticket": "..." }`. Never put the ticket or token in a file, generated Markdown, or normal command output.
+3. Fetch each root with `GET /subject/{subject}`. Recursively follow every non-empty `field.settings.subject` on `reference`, `subject`, or other fields. Stop at cycles after documenting the object once.
+4. Rebuild only the managed object-definition block in `subjectsDefinition.md`. The block must contain the root objects, every recursively referenced object, complete field properties, and dependency edges. Object sections outside the current dependency closure are removed from the managed block.
+5. Do not mutate remote objects in this mode. A missing/ambiguous `settings.subject` is documented as unresolved; never invent a target object.
+
+Run the deterministic helper from the project root:
+
+```bash
+node .agents/skills/subject-schema-manager/scripts/subject_schema_manager.mjs sync \
+  --project "$PWD" --ticket-stdin
+```
+
+Use `--check` for a read-only diff. The helper discovers the API base URL from `--base-url`, `STREAMS_API_URL`, or an absolute proxy target in `.umirc.ts`.
+
+### `apply`
+
+Use for requests that create objects, create/update fields, or update object configuration.
+
+1. Inspect the API docs and produce an exact operation plan containing object names, field aliases, payloads, and dependency order. Include a concise human-readable summary and ask for explicit confirmation before any remote mutation.
+2. After confirmation, write the plan as JSON outside the repository (for example `/tmp/subject-schema-plan.json`) and run the helper with `--confirmed --plan-file`. Pass the ticket via `SUBJECT_TICKET` or `--ticket-stdin`; never hardcode it.
+3. The helper validates aliases and payloads, previews new objects with `POST /subject?preview=true`, then executes only the bounded operations in the plan:
+   - object create: `POST /subject`
+   - object update: `PUT /subject/{subject}`
+   - field create: `POST /subject/{subject}/field`
+   - field update: `PUT /subject/{subject}/field/{field}`
+   - field import/reorder when explicitly present in the plan
+4. Remote object/field deletion is never implied by documentation cleanup. It requires explicit user intent and the helper's destructive-operation flag.
+5. After successful mutations, re-fetch the complete dependency closure and run the same documentation sync using the authenticated token. Report successes and any partial-failure operation; there is no automatic rollback.
+
+Run:
+
+```bash
+node .agents/skills/subject-schema-manager/scripts/subject_schema_manager.mjs apply \
+  --project "$PWD" --plan-file /tmp/subject-schema-plan.json \
+  --ticket-stdin --confirmed
+```
+
+The plan format is documented in [references/plan-schema.md](references/plan-schema.md). Do not use a generic arbitrary-URL request list; keep mutations within the documented Subject operations.
+
+## Safety and documentation rules
+
+- A plan confirmation authorizes only the listed operations. Do not add inferred fields, dependencies, or destructive operations after confirmation.
+- Validate `select.settings.options`, `reference/subject settings.subject`, `required`, `multiple`, and `primary` against the API response or the confirmed plan.
+- Use IDs for `reference` and `user` values, ISO 8601 for dates, and preserve `form` values as `{ form, data, settings? }`.
+- If the API or local docs conflict, stop before mutation and show the exact conflict.
+- If a business workflow or state rule changes, update the module's business-flow document separately; schema synchronization alone does not authorize workflow changes.

.agents/skills/subject-schema-manager/agents/openai.yaml

+interface:
+  display_name: "Subject Schema Manager"
+  short_description: "Sync Subject docs and apply confirmed schema plans"
+  default_prompt: "Use $subject-schema-manager to sync current Subject definitions or apply a confirmed object/field configuration plan."

.agents/skills/subject-schema-manager/references/plan-schema.md

+# Subject Mutation Plan
+
+`apply` accepts a JSON file containing only the explicitly approved Subject API operations. Keep
+the file outside the repository when it contains environment-specific values.
+
+```json
+{
+  "version": 1,
+  "operations": [
+    {
+      "op": "create_subject",
+      "subject": {
+        "name": "customers",
+        "title": "Customers",
+        "type": "normal",
+        "access": "public",
+        "fields": [],
+        "views": []
+      }
+    },
+    {
+      "op": "update_subject",
+      "subject": "orders",
+      "patch": {"title": "Orders", "history": true}
+    },
+    {
+      "op": "create_field",
+      "subject": "orders",
+      "field": {
+        "name": "customer",
+        "label": "Customer",
+        "type": "reference",
+        "required": false,
+        "multiple": false,
+        "settings": {"subject": "customers"}
+      }
+    },
+    {
+      "op": "update_field",
+      "subject": "orders",
+      "field": "status",
+      "patch": {
+        "label": "Order status",
+        "settings": {"options": [{"label": "Open", "value": "open"}]}
+      }
+    },
+    {
+      "op": "import_fields",
+      "subject": "orders",
+      "fields": [{"name": "amount", "label": "Amount", "type": "number"}]
+    },
+    {
+      "op": "reorder_fields",
+      "subject": "orders",
+      "fields": ["order_no", "customer", "status", "amount"]
+    }
+  ]
+}
+```
+
+Supported operation names are `create_subject`, `update_subject`, `create_field`, `update_field`,
+`import_fields`, `reorder_fields`, `delete_subject`, and `delete_field`. Object and field aliases
+must contain only letters, digits, `_`, or `-`. `update_subject.patch` and `update_field.patch`
+must contain only the properties supported by the corresponding API endpoints in
+`SUBJECT_API.md`; the helper rejects arbitrary URLs or methods.
+
+Creation of an object is always sent to `POST /subject?preview=true` before any mutating request.
+Deletion operations are accepted only with the command-line flag `--allow-remote-delete` in
+addition to `--confirmed`. A deletion may set `force: true` and `confirm` where the API requires
+it; `confirm` must exactly equal the alias being deleted. Documentation synchronization alone
+never creates a deletion plan.

AGENTS.md

@@ -111,6 +111,12 @@ AI 在编写 API 调用或数据转换逻辑时，必须遵守：
 - 审计材料中心模块 - 请阅读 `/src/pages/project_manager_xy/audit-material-center.business-flow.md`
 - 模板来源说明 - 如需确认旧项目上下文，可参考 `/src/pages/project_manager_xy/project-management.business-flow.md`
 
+## Subject Schema Skill
+
+- 项目内置 `.agents/skills/subject-schema-manager/` 用于从 Subject API 同步 `src/services/subjectsDefinition.md`，并按已确认计划创建、更新或删除 Subject 与字段。
+- 同步文档使用 `node .agents/skills/subject-schema-manager/scripts/subject_schema_manager.mjs sync --project "$PWD" --ticket-stdin`；远程变更必须先展示计划并在确认后使用 `apply --plan-file ... --confirmed`。
+- ticket 仅允许通过 `SUBJECT_TICKET` 或标准输入传入，不得写入仓库、计划文件或普通日志。删除对象或字段必须显式提供 destructive 操作和确认值。
+
 ## 获取当前登录用户信息
 
 可使用 src/hooks/user.jsx 中的 hook useUserInfo 数据结构如下 { "username": "yang_admin", "password_changed": true, "token_expires_at": null, "\_id": "69b12a47e92b1de77c94a9f5", "display_name": "杨康", "type": "admin", "avatar": null, "profile": {}, "groups": [ { "\_id": "649e5a55ad1c1038911baabd", "name": "default", "display_name": "默认用户组", "users": [ { "_id": "649e5a55ad1c1038911baac0", "username": "system", "display_name": "系统" } ], "settings": {} } ], "applications": [ { "name": "fund_audit", "title": "数智报告平台", "groups": [ "default" ], "roles": [ "成员" ], "permissions": [] }, { "name": "aml_tables", "title": "反洗钱数据表", "groups": [ "default" ], "roles": [ "管理" ], "permissions": [] } ] }

SUBJECT_CONFIGURATION.md

+# Object Configuration Migration
+
+对象、字段、视图和 ticket 换 token 的完整 HTTP API 参考见 [SUBJECT_API.md](./SUBJECT_API.md)。本文保留配置包迁移的详细说明。
+
+The object configuration package moves metadata between Streams environments. It does not move records, database IDs, object members, tags, categories, connector settings, credentials, or existing external database tables.
+
+## Workflow
+
+1. Select one or more normal, embedded, or external objects in Admin > Object Management and choose `Export Configuration`.
+2. Referenced objects are included automatically. The selected objects are listed in `selected_subjects`; dependency objects follow them in `subjects`.
+3. In the target environment choose `Import Configuration` and select the JSON file.
+4. Review the precheck. Only a package with no blocking issues can be applied.
+5. The import uses `upsert`: matching objects and fields are updated, new ones are created, and target-only fields and views are preserved.
+
+For an external object, create and enable a DM8 connector in the target environment before import. Its stable `connector.name` must match the alias exported in `external.connector`. A new external object provisions a new managed table using the `dm_<subject.name>` convention; import never adopts, binds to, or overwrites a pre-existing physical table.
+
+## Stable identifiers
+
+The following identifiers are portable business codes and must not be replaced with database IDs:
+
+- object: `subject.name`
+- field: `field.name`
+- select option: `field.settings.options[].value`
+- reference target: `field.settings.subject`
+- external connector: `subject.external.connector` (`connector.name`)
+
+For example:
+
+```json
+{
+  "kind": "streams.subject-configuration",
+  "version": 1,
+  "selected_subjects": ["orders"],
+  "include_dependencies": true,
+  "subjects": [
+    {
+      "name": "orders",
+      "title": "Orders",
+      "type": "normal",
+      "fields": [
+        {
+          "name": "status",
+          "label": "Status",
+          "type": "select",
+          "settings": {
+            "options": [
+              {"label": "Open", "value": "open"}
+            ]
+          }
+        },
+        {
+          "name": "customer",
+          "label": "Customer",
+          "type": "reference",
+          "settings": {"subject": "customers"}
+        }
+      ],
+      "views": []
+    },
+    {
+      "name": "customers",
+      "title": "Customers",
+      "type": "normal",
+      "fields": [],
+      "views": []
+    }
+  ]
+}
+```
+
+An external object only exports its connector alias:
+
+```json
+{
+  "name": "external_orders",
+  "title": "External Orders",
+  "type": "external",
+  "external": {
+    "connector": "business_dm"
+  },
+  "fields": [],
+  "views": []
+}
+```
+
+The package never contains the connector host, account, password, settings, runtime state, physical table metadata, or records.
+
+## API
+
+- `POST /subject/configuration/export` with `{subjects: ["orders"], include_dependencies: true}`
+- `POST /subject/configuration/import/preview` with `{mode: "upsert", package: {...}}`
+- `POST /subject/configuration/import` with `{mode: "upsert", package: {...}}`
+
+The import order is normal object shells, complete new external objects, object properties, normal fields, reference fields, and views. A new external object is created once with its complete field definition so the managed table is provisioned once. This also allows circular references between objects to be imported after referenced object names exist.
+
+External-object precheck blocks import when:
+
+- `external.connector` is missing or invalid;
+- the same-alias connector does not exist, is inactive, or is not DM8-compatible;
+- the target table for a new external object already exists;
+- an existing external object's connector alias differs from the package;
+- an existing external object is not in the `ready` state;
+- an external field change is not supported by the managed-table schema.
+
+## Deliberate limitations in V1
+
+- Records are never included.
+- Connector settings and credentials are never included; target connectors are resolved by alias.
+- Existing physical tables are never adopted or overwritten by configuration import.
+- Members, tags, and categories are reported as warnings and are not imported.
+- Upsert never deletes fields or views that only exist in the target environment.

pnpm-workspace.yaml

+allowBuilds:
+  "@heroui-pro/react": true
+  "@zowe/secrets-for-zowe-sdk": true
+  core-js: false
+  core-js-pure: false
+  es5-ext: false
+  esbuild: true

public/manifest.json

 {
   "name": "audit_material_manager",
-  "version": "1.1.1",
+  "version": "1.1.4",
   "build": "abc",
   "description": "merge master",
   "date": "2025-07-14 19:27:20",
-  "author": "yang"
+  "author": "yang",
+  "spa": true
 }