QIQI Service Industry ERP Project Domain
This skill defines the dedicated command entry, analysis criteria and result judgment for the project domain. Current parameters are subject to the qiqi target leaf command
.
Domain Fact Boundaries
- Project is the collection scope for tasks, working hours and business-finance facts; the name only generates candidates, and a stable or unique code is required to confirm the project.
- Task may serve both project planning/WBS and daily execution purposes. The dedicated write path of this skill only processes task commands publicly available in the current runtime; planning levels, summary rules and dependency relationships must be confirmed by the current object metadata.
- Working Hours are the input facts that personnel allocate to projects or tasks on business natural days; the document stage, cost allocation and budget control rules are subject to the current enterprise configuration and cannot be directly inferred from a single registration.
- Business Analysis is carried out along four types of facts: budget, revenue, cost and cash; contracts, revenue recognition and invoicing do not equal collection; cost occurrence does not equal payment; budget does not equal execution.
Operation Entries When Current Profile Exposes the Project Domain
Only when
domain appears in
of the current profile, the corresponding leaf commands are read and used; if not exposed, report the capability gap and do not treat the following entries as fixed capabilities.
| Business Intent | Command Used |
|---|
| Create project tasks, daily tasks or subtasks | |
| Modify task business attributes | |
| Start a task | |
| Complete a task | |
| Log project or task working hours | |
Do not use
for starting and completing tasks. Do not establish a second execution path due to similar general action names.
Work Principles
- Use of the target profile to verify the current enterprise and user; do not repeat execution if the profile is clear and just verified.
- Use , , and to obtain unique references to projects, tasks and personnel as needed; directly check necessary records when stable references already exist.
- Clarify the project scope, business period, fact stage and integrity requirements before querying; process complete pagination and large outputs before forming statistical conclusions.
- Read the target leaf command before writing, and only send the minimum parameters required by the user's intent; unexpanded writable fields are handled according to "Write Protection".
- Verify results based on returned stable references, record stages and key fields. Query first instead of directly retrying when timeout or results are unclear.
Write Protection
- Project tasks, daily tasks and subtasks have different intents; do not downgrade project work to daily tasks when there is no project.
- Do not create placeholder projects, placeholder personnel or placeholder tasks to meet working hour registration requirements.
- Projects and parent tasks are structural contexts and are not repeatedly written as ordinary fields; status, source, audit and calculation fields are maintained by business rules.
- Report according to the returned facts when creating a task returns a draft or other stages, and do not describe creation success as submitted, started or completed.
- Each execution is an independent business intent; the CLI does not deduplicate between multiple calls. Re-running task creation or working hour registration will write another record; check business facts first before deciding when results are unclear.
- When explicitly processing multiple subtasks under the same parent task in batches, write operations such as starting and completing are serial by default; process the next item only after the previous result is clear to avoid concurrent write conflicts.
- Planned start, planned finish, actual start, actual finish and working hour dates are all business natural days; the specific format is subject to the current field and command description.
Unexpanded Writable Model Fields
This rule applies to task creation, task modification and working hour registration.
Model metadata determines whether a field exists, its technical name, data type and writability; command input definitions only determine which fields are expanded as first-level options. This section applies only when the field that the user needs to enter is defined and writable in the current model metadata but not expanded in the target command.
First confirm the field's technical name, data type and candidate values for reference, enumeration or boolean fields. Do not construct or write if the model metadata does not define it, or if it belongs to status, source, audit or calculation fields.
After confirmation, use
of the target command to pass the complete business parameter object;
is mutually exclusive with field-by-field options. When both expanded standard fields and unexpanded writable fields need to be written, put them into the same JSON object uniformly instead of splitting into unconfirmed command options.
On-Demand Reading
- Read task-workflows.md when you need to understand task intent, structure, planning and execution workflows.
- Read work-hours.md when you need to register or explain project input, working hour costs and billing basis.
- Read project-profit-analysis.md when users ask about project profits, spending directions, payment collection or cash status.
- Read project-budget-execution.md when users ask about budget amount, execution amount, variance or over-budget status.
Only read reference files required for the current task.