[flashduty]

Daily api-review audit (--mode generate --scope all --auto). It picked up two public-surface drifts where the backend on origin/main is ahead of the specs, and nothing else.

• Audit window: implementation commits after the previous run 2026-10-23T08:04:06Z → 2026-10-26T08:00Z, docs baseline main 3aa5f4f5. Every commit in the window, merge commits included, was diffed against its first parent and filtered against the public surface (auth == "all", not /event/push/, module not hidden).
• Operation surface: registry has 385 public rows, docs have 384 operations; the only difference is the known unresolved POST /channel/incident/daily-counts (handler still only on fc-event origin/dev). So no operation was added or removed — docs.json pages, docs.json redirects and both api-catalog.mdx were deliberately left untouched, and scripts/api_path_redirects.py --check still exits 0.

Per-module operation changes

Module	added	updated	removed
on-call	0	0	0
monitors	0	0	0
rum	0	5	0
platform	0	0	0
safari	0	2	0

Total: 0 added, 7 updated, 0 removed. Diff is +132 / −4 over 6 files.

What changed, and the Go anchor for each

rum — /rum/dashboard/{create,get,list,update,restore}

fc-rum PR #394 (785db1d, merged 2026-10-25) made a dashboard belong to exactly one application:

• types/dashboard/contract.go — CreateInput gains ApplicationID string \json:"application_id"`, ResourceandListItemgainapplication_id, ListInputgains an optionalapplication_id`.
• types/dashboard/validate.go — CreateInput.Validate rejects an empty application_id or one longer than 64 bytes (maxApplicationIDBytes = 64), so the create field is required with minLength implied by "1 to 64 bytes"; ReadsOnly additionally requires every query in definition to read that same application.

Applied: application_id added to RumDashboardCreateRequest (required), RumDashboardResource (required), RumDashboardListItem (required) and RumDashboardListRequest (optional), plus the request/200 examples that must carry the newly required key, plus one Usage bullet on create for the same-application rule.

safari — /safari/session/{get,list}

• fc-safari PR #1634 (ff8f1900, merged 2026-10-25) — types/session.go#SessionItem gains TurnInFlight bool \json:"turn_in_flight"`with noomitempty, and cmd/api/sessions/sessions.go fills it on both the get (:518) and list (:710`) paths.

Applied: SessionItem gains turn_in_flight (required, next to is_running) and both response examples carry it.

Examples

The dev API is not reachable from this environment (it cannot reference the credential environment variables), so every request and 200 example touched here was constructed from the schema, not captured. Values are coherent across the pair: the RUM application id qLpu24Dz4CAzWsESPbJYWA already used by the dashboard definition examples, and the existing UUIDv7 dashboard id. Both language files share the same example values, as required.

Verification

• python3 -c "import json; json.load(...)" on all 6 files: OK.
• python3 scripts/lint_openapi.py: OK: 12 spec files, no violations.
• python3 scripts/api_path_redirects.py --check: exit 0.
• Nav/catalog coverage for rum and safari: none missing in docs.json and in both api-catalog.mdx.
• EN/ZH structural parity: identical paths, schemas, required, enums and types; only human text differs (description, tags, x-enumDescriptions).
• Split vs consolidated deep compare (sort-key, key-order-insensitive): the only remaining difference is the known DutyError.reason hand edit in the consolidated files, carrying x-flashduty-preserve-absence: true — left alone on purpose, recorded here for adjudication.
• Key order was preserved by in-place insertion only (every touched file round-trips byte-identically through json.dumps(indent=2, ensure_ascii=False) before the edit), so the diff contains no re-sorting.
• mint broken-links could not be run (Mintlify CLI is not installed here); it is not needed either — no page, path or anchor was added or removed.

Overlap with open PRs — please read

• docs(api): RUM query time range alignment and caching #1131 (draft, docs/rum-query-time-alignment) already adds disable_cache to RumDataQueryDefinition and the caching/alignment prose for /rum/data/query and /rum/facet/count. fc-rum 4e883e9 does add that field, but it is already covered by that PR, so this PR does not duplicate it. FYI: that branch currently fails the same lint this PR passes — applying its diff to main yields 8 description-too-long violations (the new prose sits in the operation description instead of x-mint.content). Whoever owns the draft needs to move the text before it can merge.
• docs(api-reference): daily api-review 2026-10-23 — incident labels, invite schedule_id, reorder example #1128 is the previous daily api-review PR and is still open. It touches on-call files only; this PR does not touch on-call, so they should merge cleanly in either order.

Considered and deliberately not changed

• fc-event e7d6fbae dropped Title from the incident list filter and made labels/fields exact-match; fc-event e4835ebd made /alert/list match a plain title as a substring and caps a title search to 7 days. Both fields are apidoc:"omit" in the handler, and the specs document neither, so no spec change follows from either commit.
• EscalateRuleItem.channel_name, MetricsBase.account_id, A2AAgentItem.description, PersonItem.*, AlertRule.investigation_targets: present in Go but either never filled on the wire (channel_name is only ever assigned for other item types), or deliberately excluded (A2AAgentItem.description carries a comment saying OpenAPI/SDK/CLI no longer expose it), or the docs schema that would carry them is unreferenced legacy next to the live one (AlertRuleV2 already documents investigation_targets). No change.
• fc-safari expires_at_sec (credits grant) and fc-pgy wallet end_time are on jwt/none routes, RunRequest.config_only is on the internal run path; config_only/config_target are not app_key-callable, so they are out of the public surface.
• monit-webapi execution-history storage work (docs(api): document app-key license listing #179) exposes no public endpoint, and the on-call/calendar mapping defect noted in earlier rounds still stands (report only, skill body untouched).

Unresolved (not written into any spec)

• POST /channel/incident/daily-counts — registry row is Auth: "all", but the handler and route exist only on fc-event origin/dev; no path was fabricated for it.