Schedule Calendar Response Documentation Design

Goal

Complete the response field definition and response example for /openapi/v3/schedules/plans/calendar/month/get in the open-platform API documentation.

Source of truth

The response contract follows the existing backend DTOs:

• CalendarOfMonthDTO: year, month, and dayList.
• DayStatusOfMonthDTO: dayOfMonth and existPreTasks.
• existPreTasks is 0 when no schedule task exists for the day and 1 when a schedule task exists.

The documentation will not introduce fields that are absent from the backend contract, such as date, preTaskCount, or planUuidList.

Scope

Modify only these four existing documentation sources:

1. openApiJson/zh_CN/OpenAPI V3 Service/Schedules/Get Schedule Calendar By Month.json
2. openApiJson/en_US/OpenAPI V3 Service/Schedules/Get Schedule Calendar By Month.json
3. md/zh_CN/OpenAPI V3 Service/Schedules/Get Schedule Calendar By Month.md
4. md/en_US/OpenAPI V3 Service/Schedules/Get Schedule Calendar By Month.md

The two JSON files will define the response envelope and nested response fields with their types, examples, and localized descriptions. The two Markdown files will replace the empty data response example with a complete June 2026 example containing days 1 through 30.

Response definition

The response keeps the existing {code, data, msg} envelope:

Field	Type	Description
code	integer	Business status code; 0 means success.
msg	string	Business status message.
data	object	Monthly schedule calendar data.
data.year	integer	Returned year.
data.month	integer	Returned month.
data.dayList	object[]	Daily schedule status list in ascending date order.
data.dayList[].dayOfMonth	integer	Day of the selected month.
data.dayList[].existPreTasks	integer	0 means no schedule tasks; 1 means schedule tasks exist.

The nested array item is represented using the existing YApi-style items.properties structure so that the current API template can render the nested fields without runtime component changes.

Response example

The current request example queries June 2026. The response example will therefore contain:

{
    "code": 0,
    "data": {
        "dayList": [
            {
                "dayOfMonth": 1,
                "existPreTasks": 0
            }
        ],
        "month": 6,
        "year": 2026
    },
    "msg": "success"
}

The actual documentation example will list all 30 days of June and include both existPreTasks values to make the meaning of the flag clear. The Chinese and English examples will use identical JSON data.

Validation

Validation will be limited to the documentation repository:

• Parse both modified JSON files with Node.js.
• Verify the nested response fields and leaf examples exist in both locale files.
• Verify both Markdown response blocks contain dayList, month, year, and exactly 30 day entries.
• Run yarn build with the repository's documented Node.js requirement.
• Run git diff --check before committing the implementation changes.

No runtime code or business behavior changes are required, so no new unit-test source is added. The existing documentation build is the regression gate for these source-data changes.

Constraints

• Keep the existing file structure, field naming, and formatting style.
• Keep Chinese and English schemas structurally identical.
• Do not modify backend repositories or generated backend Swagger files.
• Keep the implementation limited to the requested endpoint.