docs(api): api-review daily audit 2026-10-13 — localize Monitors zh 200 descriptions, refresh work-item Usage

[flashduty]

Scope

api-review --mode generate --scope all --auto (daily audit).

Source baselines: fc-pgy f10b35ad · fc-event 994b1dd5b · fc-oncall f54dee6 · fc-rum c9d1923 · fc-statuspage 69ca45f · monit-webapi 79dbc4e · fc-datasource c4c17f9 · go-pkg 7189310.
Docs baseline: e6fe2537 (main).

Operation changes

Module	added	updated	removed
Monitors	0	18 (zh responses.200.description only)	0
On-call	0	3 (Usage text, EN + ZH)	0
Platform / RUM / AI SRE	0	0	0

Diff: 4 files, 42 insertions / 42 deletions (84 changed lines — inside the round's 100-line ceiling).

No path or schema key was added, removed, or reordered (verified mechanically: parallel walk of HEAD vs working tree reports 0 structural issues; the only removed lines in the whole diff are the 42 intended ones).

What changed, and the evidence

1. Chinese specs: 18 Monitors operations had the English 200 description left untranslated (72 lines).
/monit/dashboard/* (17) and /monit/folder/list (1) carried "description": "Success" in monitors.openapi.zh.json, while the other 22 operations in the same file, and every other zh module (on-call 200, platform 28, rum 39, safari 51), use "成功". The dashboard family was authored 2026-10-05 (47ce7008) without zh localization. Aligned both the rendered split and the consolidated copy so they stay identical.

2. On-call SPLIT: three /incident/work-item/* Usage bullets predated AI SRE assignee support (6 lines).
The split files (what Mintlify renders) still said "At least one of incident_id, post_mortem_id, or assignee_id is required" and "Assignees must be active members…". The consolidated copy already carried the corrected text; the split did not. Every claim in the corrected text is verified against fc-event origin/main:

• structs/work_item.go — WorkItemAssigneeRef{Type, ID omitempty}, WorkItemAssigneeTypePerson = "person", WorkItemAssigneeTypeAISRE = "ai_sre" (an ai_sre entry keeps ID 0, i.e. omits id).
• logic/post_incident/work_item.go:946 — "incident_id, post_mortem_id, assignee_id, or assignee_type=ai_sre is required"; work_item_validate.go:17 restricts assignee_type to person|ai_sre.
• logic/post_incident/work_item_validate.go:147 — "assignees and assignee_ids cannot both be set".

Paths touched: /incident/work-item/list, /incident/work-item/create, /incident/work-item/assignees/reset (EN + ZH).

Findings recorded, deliberately NOT fixed in this round

1. Same seven operations' SPLIT response examples omit assignees, which WorkItemItem lists in required (/incident/work-item/{list,create,update,complete,convert,post-mortem/bind,assignees/reset}; 9 example objects per language). The consolidated already has the field. Reconciling costs ~216 changed lines in either direction, and the direction is contested: rule 7 makes the split authoritative, while the Go source (assignees ∈ WorkItemItem.required) puts the field in both outputs. Needs a human call (likely a full regeneration or a dedicated PR), so it is reported rather than fixed inside a budgeted round.
2. DutyError.properties.reason is a marked hand-edit. Present in the consolidated copy (EN+ZH) and in monitors.openapi.en/zh.json, absent from the on-call / platform / rum / safari splits. It carries x-flashduty-preserve-absence: true, and go-pkg/srv/error.go:177 defines Error with only code, message, raw_message, HTTPStatusCode — no reason. Per the skill's rule, marked hand-edits are left alone and the conflict is recorded. Note the user-visible consequence: the Monitors tab documents reason, the other four tabs do not.
3. Unresolved registry row (unchanged, no operation emitted): POST /channel/incident/daily-counts (channel:read:incidentDailyCounts, Auth: "all", fc-pgy/logic/api/api_test.go:637) still has no handler on fc-event origin/main; the implementation exists only on feature branches. No path fabricated.
4. Account-level rate-limit cells remain out of sync with the registry's AQps/AQpm (147 of 365 operations, measured 2026-10-12). This is a disclosure-policy question, not drift, and rewriting it is ~588 lines across two languages — it needs a decision before any PR.
5. GET /monit/prometheus/api/v1/label/:label_name/values in the registry is the same operation as the spec's {label_name} path (fc-pgy registers colon-style params); mapped, not drift.

Verification performed

• All 13 files under api-reference/ parse with json.load; openapi.legacy.zh.json untouched.
• Round-trip determinism: re-serializing each committed file with json.dumps(..., ensure_ascii=False, indent=2) is byte-identical, so the diff contains only intended edits.
• Structural check (HEAD → working tree) on all four changed files: 0 key-order/key-set changes, 0 type changes; value changes limited to exactly 18+18 zh descriptions and 3+3 x-mint.content strings.
• docs.json and {en,zh}/openapi/api-catalog.mdx were not touched — no page was added or removed, and all 365 operations remain reachable from both the nav allow-list and both catalogs.
• mint broken-links was not run: no Node/npm/Mintlify toolchain is present in this environment. Nothing in this diff adds or changes a link target, and no href was edited.