make-app-approval

Make App Approval Generation and Initiation-Side Adaptation

Turn the confirmed functional plan into approval navigation decisions, and let business forms enable approval creation and status display according to runtime configuration. Each app keeps only one "My Approvals"; business objects still use their own record lists.

Work Order

1. Extract business objects, actual user write actions, and approval handling capabilities from the confirmed plan, and read the default generation rules. First give the business rationale for generating or not generating; do not merely search for words such as "form" or "submit". If the plan does not state whether write/approval capabilities exist, confirm only this missing fact and do not add features on your own.
2. Investigate the host navigation and routing, Schema adaptation, ordinary creation and details, field renderers, request layer, record creation/attachment/Lookup chains, and tests. Describe the files to be changed, reuse points, and verification plan; preserve the existing business lists, layouts, and layering.
3. When the plan triggers generation and includes business creation capabilities, even if no process is currently bound, also read the initiation-side contract and generate runtime dual branches; when business lists/details exist, read process status display. Handle individual integrations according to the corresponding contract. First distinguish between "generating adaptation capabilities" and "the current object allows first initiation"; do not omit adaptation code just because there is no key at generation time. Plans with only approval handling and no creation page do not add business creation features.
4. Integrate into the existing UI → Service → Make call chain. Place approval configuration and save orchestration in the Hook/Service, keep field sets and state transitions as pure logic; desktop and mobile share business logic and each reuse existing Views.
5. Follow the verification scenarios to add failing tests first, then implement minimally; check the ordinary creation regression and approval field authorization consistency between UI/Service. Report the checks actually executed and items not verified; do not treat documentation checks as real approval integration testing.

Boundaries That Must Be Maintained

• Navigation is a plan decision. It can be triggered by business add, entry, edit-save, or an explicit approval handling requirement; binding a process first is not required. After there are no tasks, all processes are disabled, or unbinding occurs, the generated entry and historical access paths are still retained.
• Creation is a runtime decision. Only when the successfully obtained Schema object contains a valid bpmDefinitionKey does it enter the approval creation branch. Configuration read failure is an error state and must not be equated with not bound.
• Approval creation fields are authorized independently. Use bpm-start-config.fields 's complete field metadata and readable/editable, and no longer intersect with the ordinary IAM field set or createFields . The app, object, creation operation, associated target, and backend final authorization are still retained.
• Saving and first initiation are separate. Ordinary save does not initiate; when the user chooses save and initiate, first obtain the saved record ID, then initiate for the first time. Failure recovery must not duplicate creation or uploads, and configuration changes must not automatically submit historical records.
• Status comes from the record. qfei_process_instance_status It is a read-only system field; do not create a DSL business field with the same name, and do not derive process status from business status, task results, lock fields, or the current binding.
• Editing existing records preserves the existing contract. Do not extend create-initiation field permissions to ordinary editing; records under approval, in returned runtime state, or explicitly locked must not bypass the lock through ordinary editing, quick editing, or batch entry points. The terminal-state editing policy follows the host's confirmed contract, and this skill does not rewrite it separately.

Coordination with Existing Skills

Placement	Responsibility
makeui	Shell, navigation position, Drawer/mobile task page, existing field controls, and Tag appearance; this skill determines approval branches and field sources
make-app-permission	Ordinary IAM and application/object/operation permissions; this skill defines the approval create-initiation field branch and does not replace the ordinary permission algorithm
make-app-service	API contract, adaptation, cache isolation, errors, and cancellation; this skill provides Workflow initiation parameters and failure semantics
make-app-actions	Ordinary record operation entry points, pre-checks, and batch capabilities; consume the same lock determination and do not duplicate approval task actions
canvas-table-integration	Read-only system columns in the desktop list; mobile reuses cards and does not add a new table for status display
makedsl	Business object modeling; do not add business fields for process status or locks, and do not generate process definitions

Delivery Scope for This Phase

Deliver navigation generation decisions and host entry points, approval create-initiation fields, save/first initiation, the process status field in business lists and details, and the status Tag after the detail title.

The undo/withdraw buttons and interfaces, installation and upgrade of the My Approvals npm package, task lists/task handling details, approval comments and actions, approval history, and process diagrams are not in this phase. An existing task center only reconnects to existing routes; when there is no task center, retain the real capability boundary according to the default generation rules, do not duplicate a set of pages, and do not add unverified npm APIs.