docs-check-kibana-oas
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<!-- Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
or more contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright
ownership. Elasticsearch B.V. licenses this file to you under
the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License. -->
<!-- Copyright Elasticsearch B.V.,并/或根据一项或多项贡献者许可协议获得
Elasticsearch B.V. 许可。有关版权归属的更多信息,请参阅随本作品
分发的 NOTICE 文件。Elasticsearch B.V. 根据 Apache License,
Version 2.0(“许可证”)向您许可本文件;除遵守许可证的约定外,
您不得使用本文件。您可以在以下位置获取许可证副本:
http://www.apache.org/licenses/LICENSE-2.0
除非适用法律另有规定或另有书面同意,否则本软件按许可证
“AS IS”基础分发,不提供任何明示或暗示的担保。请参阅许可证
中关于特定语言下权限和限制的条款。 -->
Check Kibana OAS
检查 Kibana OAS
You are reviewing a Kibana PR from against the Elastic API docs checklist, core guidelines, and Kibana quickstart. Output a concrete action list. Every item names the file and line to change.
elastic/kibana你正在依据 Elastic API 文档检查清单、核心指南和 Kibana 快速入门指南,审查来自 的 Kibana PR。输出一份具体的行动清单。每个条目都要指明需要修改的文件和行号。
elastic/kibanaInput
输入
$ARGUMENTS/docs-check-kibana-oas 289719/docs-check-kibana-oas https://github.com/elastic/kibana/pull/289719/docs-check-kibana-oas https://github.com/elastic/kibana/pull/289719/changes
If no PR number is given, ask for one.
$ARGUMENTS/docs-check-kibana-oas 289719/docs-check-kibana-oas https://github.com/elastic/kibana/pull/289719/docs-check-kibana-oas https://github.com/elastic/kibana/pull/289719/changes
如果未提供 PR 编号,则向用户询问。
Key principle: YAML is generated, TypeScript is the source of truth
核心原则:YAML 是生成的,TypeScript 是事实来源
The files under (, ) are auto-generated from TypeScript route definitions. CI regenerates them on push. Use the YAML diff to detect problems (missing , wrong stability label, empty values), but every action you output must point at the TypeScript source that generates it. Never suggest manually editing the YAML.
oas_docs/output/kibana.yamlkibana.serverless.yamlx-stateoas_docs/output/kibana.yamlkibana.serverless.yamlx-stateWorkflow
工作流
1. Fetch the PR
1. 获取 PR
bash
gh pr diff <PR_NUMBER> --repo elastic/kibana
gh pr view <PR_NUMBER> --repo elastic/kibana --json title,body,files,headRefNameSave the full diff. You will scan it multiple times.
bash
gh pr diff <PR_NUMBER> --repo elastic/kibana
gh pr view <PR_NUMBER> --repo elastic/kibana --json title,body,files,headRefName保存完整 diff。你会多次扫描它。
2. Check out the PR branch
2. 检出 PR 分支
Find a local Kibana clone. Check, in order:
- Current working directory (if it is inside a repo)
kibana ~/elastic/kibana
Then check out the PR branch:
bash
cd <KIBANA_DIR> && gh pr checkout <PR_NUMBER>If no local clone is found at either location, tell the user and ask them for the path to their Kibana checkout.
Read the actual source files from this checkout for exact line numbers. Never compute line numbers from diff hunk headers.
按以下顺序查找本地 Kibana 克隆:
- 当前工作目录(如果位于 仓库中)
kibana ~/elastic/kibana
然后检出 PR 分支:
bash
cd <KIBANA_DIR> && gh pr checkout <PR_NUMBER>如果这两个位置都没有本地克隆,请告知用户,并要求用户提供 Kibana 检出目录的路径。
从该检出副本读取实际源文件,以获取准确的行号。绝不能根据 diff hunk header 计算行号。
3. Classify the changes
3. 对变更进行分类
From the diff, sort changed files into:
- Route definitions: files under
.tsregisteringserver/routes/endpointsrouter.versioned.* - Schema definitions: files with
.ts/schema.object/ etc. used in route validationschema.maybe - Generated YAML: — scan for diagnostic signals only
oas_docs/output/ - Example files: YAML under
routes/examples/ - Other: types, tests, mocks — note but do not audit
根据 diff,将变更文件分为以下类别:
- 路由定义:在 下注册
server/routes/端点的router.versioned.*文件.ts - Schema 定义:在路由验证中使用 /
schema.object等的schema.maybe文件.ts - 生成的 YAML:——仅用于扫描诊断信号
oas_docs/output/ - 示例文件:下的 YAML
routes/examples/ - 其他:类型、测试、mock——记录但不审查
4. Audit
4. 审查
Apply every rule from the rules section below against the diff. Use the generated YAML as a cross-check signal. If the YAML looks wrong (missing , empty , wrong label), trace it back to the TypeScript source to find the root cause.
x-statex-stateFor every finding, read the actual file from the checked-out branch to confirm the exact line number. Point at the line where the developer needs to make the change.
将规则部分中的每条规则应用到 diff 上。使用生成的 YAML 作为交叉检查信号。如果 YAML 看起来有问题(缺少 、 为空、标签错误),则回溯到 TypeScript 源文件以找出根本原因。
x-statex-state对于每项发现,都要从检出的分支读取实际文件,以确认准确的行号。指出开发者需要进行修改的那一行。
5. Cross-check sibling routes
5. 交叉检查同级路由
When the PR adds a new route to an existing resource, read the existing routes from the checked-out branch to compare conventions. Look for patterns like narrative doc links, tag usage, or example files that siblings use but the new route does not.
当 PR 为现有资源添加新路由时,从检出的分支读取该资源的现有路由,以比较约定。查找同级路由采用而新路由缺少的模式,例如叙述性文档链接、标签用法或示例文件。
6. Output
6. 输出
Print a flat action list, then a summary. Be terse. No diagnosis essays.
先输出扁平的行动项列表,然后输出摘要。保持简洁。不要撰写诊断说明文章。
Linking to files
文件链接
Every file reference must be a clickable markdown link into the PR's "Files changed" view:
https://github.com/elastic/kibana/pull/<PR_NUMBER>/files#diff-<SHA256_OF_PATH>Compute the anchor:
bash
echo -n "<full-repo-relative-path>" | shasum -a 256 | cut -c1-64Link like:
[agents.ts:689](https://github.com/elastic/kibana/pull/290353/files#diff-<hash>)If you cannot compute the hash, link to the PR files page with the bare path.
每个文件引用都必须是可点击的 Markdown 链接,并指向 PR 的“Files changed”视图:
https://github.com/elastic/kibana/pull/<PR_NUMBER>/files#diff-<SHA256_OF_PATH>计算锚点:
bash
echo -n "<full-repo-relative-path>" | shasum -a 256 | cut -c1-64链接格式如下:
[agents.ts:689](https://github.com/elastic/kibana/pull/290353/files#diff-<hash>)如果无法计算哈希,则使用裸路径链接到 PR 文件页面。
Format
格式
undefinedundefinedOAS review — PR #<NUMBER>
OAS review — PR #<NUMBER>
<PR title>
<PR title>
Actions
Actions
-
❌ Addto availability — agents.ts:689
stability→availability: { since: '9.5.0' }availability: { stability: 'experimental', since: '9.5.0' } -
❌ Add description forpath param — agents.ts:140 Path parameters must have
user_id.meta: { description: '...' } -
❌ Add narrative doc link — attachments.ts:105 Sibling conversation routes link to the agent chat docs. Consider adding a similar link.
-
❌ Summary exceeds 45 characters — agents.ts:684→ shorten to ~40 chars.
'Get all agent builder conversation attachments for a user'
-
❌ Addto availability — agents.ts:689
stability→availability: { since: '9.5.0' }availability: { stability: 'experimental', since: '9.5.0' } -
❌ Add description forpath param — agents.ts:140 Path parameters must have
user_id.meta: { description: '...' } -
❌ Add narrative doc link — attachments.ts:105 Sibling conversation routes link to the agent chat docs. Consider adding a similar link.
-
❌ Summary exceeds 45 characters — agents.ts:684→ shorten to ~40 chars.
'Get all agent builder conversation attachments for a user'
Passes
Passes
- ✅ and
summarypresent — agents.ts:684description - ✅ Path params have — agents.ts:700
meta.description - ✅ Tags include — agents.ts:680
oas-tag - ✅ Example file referenced — agents_get.yaml
- ✅ and
summarypresent — agents.ts:684description - ✅ Path params have — agents.ts:700
meta.description - ✅ Tags include — agents.ts:680
oas-tag - ✅ Example file referenced — agents_get.yaml
Verdict
Verdict
N actions (X required, Y suggested)
Rules:
- ❌ for actions the author needs to address
- ✅ for passes — list briefly, one line each
- Tag pre-existing issues as "(pre-existing)" so the PR author knows what they introduced vs. inherited
- Always include the before → after when the fix is a one-liner
- Every file reference is a markdown link to the PR files view
---N actions (X required, Y suggested)
规则:
- ❌ 用于作者需要处理的操作项
- ✅ 用于已通过项——每项简要列出,一行一项
- 将既有问题标记为“(pre-existing)”,以便 PR 作者了解哪些问题是本次引入的,哪些是继承而来的
- 如果修复只需一行更改,始终包含更改前 → 更改后的内容
- 每个文件引用都必须是指向 PR 文件视图的 Markdown 链接
---Rules
规则
These rules come from the Elastic API docs checklist, the core guidelines, the organize and annotate guide, and the Kibana quickstart. They also incorporate conventions observed across existing Kibana routes.
1. Route-level availability (lifecycle status)
1. 路由级 availability(生命周期状态)
Every new route MUST have in its block with both and . This powers the version badges and tech preview labels in the published API docs.
availabilityoptionsstabilitysinceValid values and their rendered labels:
stability| Value | Rendered label | Meaning |
|---|---|---|
| Experimental | Can change or be removed in future versions |
| Technical preview | Pre-release, may change |
| Generally available | Stable for production use (default if omitted, but be explicit) |
since'9.2.0'Correct pattern:
typescript
router.versioned.get({
path: '...',
options: {
tags: ['...', 'oas-tag:Agent builder'],
availability: {
stability: 'experimental',
since: '9.6.0',
},
},
})What to flag:
- ❌ block missing entirely
availability - ❌ missing from
stabilityavailability - ❌ missing from
sinceavailability - ❌ has an invalid value
stability
每个新路由都必须在 块中提供 ,并同时包含 和 。它们用于在已发布的 API 文档中生成版本徽章和技术预览标签。
optionsavailabilitystabilitysince有效的 值及其渲染标签:
stability| 值 | 渲染后的标签 | 含义 |
|---|---|---|
| Experimental | 未来版本中可能更改或移除 |
| Technical preview | 预发布阶段,可能会发生更改 |
| Generally available | 可稳定用于生产环境(省略时默认如此,但仍应显式声明) |
since'9.2.0'正确模式:
typescript
router.versioned.get({
path: '...',
options: {
tags: ['...', 'oas-tag:Agent builder'],
availability: {
stability: 'experimental',
since: '9.6.0',
},
},
})需要标记的问题:
- ❌ 完全缺少 块
availability - ❌ 中缺少
availabilitystability - ❌ 中缺少
availabilitysince - ❌ 使用了无效值
stability
2. Route summary
2. 路由 summary
Every new route MUST have a . Summaries appear in IDEs, search results, and documentation overviews.
summarySummary guidelines:
- 5–45 characters — keep it short because space is limited in many contexts
- Start with a verb — "Get", "Create", "Update", "Delete"
- Use basic verbs — "Get" not "Retrieve", "Update" not "Modify"
- Include articles — "Delete a space", "Delete spaces"
- Sentence case — capitalize only the first word and proper nouns
- No trailing period
What to flag:
- ❌ missing
summary - ❌ Summary exceeds 45 characters
- ❌ Summary does not start with a verb
- ❌ Summary uses title case or ends with a period
每个新路由都必须有 。摘要会出现在 IDE、搜索结果和文档概览中。
summary摘要指南:
- 5–45 个字符——保持简短,因为许多场景中的显示空间有限
- 以动词开头——使用“Get”,而不是“Retrieve”;使用“Update”,而不是“Modify”
- 使用基本动词——使用“Get”,而不是“Retrieve”;使用“Update”,而不是“Modify”
- 包含冠词——“Delete a space”、“Delete spaces”
- 句首大写——仅第一个单词和专有名词使用大写
- 结尾不要加句号
需要标记的问题:
- ❌ 缺少
summary - ❌ 摘要超过 45 个字符
- ❌ 摘要未以动词开头
- ❌ 摘要使用标题式大小写或以句号结尾
3. Route description
3. 路由 description
Every new route MUST have a . Descriptions support markdown formatting and should cover:
description- Purpose and impact: what does this operation do and why would a user need it?
- Prerequisites or context: what should users know before calling this endpoint?
- Constraints: valid values, formats, size limits, rate limits
- Relationships: how parameters interact, how multiple values are handled
A good description adds detail beyond the summary. A bad description just restates it.
Good:
'Create a new conversation with an agent. The conversation persists across sessions and can be shared with other users via access control. To learn more, refer to the [agent chat documentation](https://www.elastic.co/docs/...).'Bad: (restates the summary, adds nothing)
'Creates a conversation.'What to flag:
- ❌ missing
description - ❌ Description is just a copy or restatement of the summary
- ❌ Description omits constraints or prerequisites that a user would need
每个新路由都必须有 。描述支持 Markdown 格式,并应涵盖:
description- 用途和影响:此操作执行什么工作,以及用户为什么需要调用它?
- 前置条件或上下文:用户调用此端点前需要了解什么?
- 约束条件:有效值、格式、大小限制、速率限制
- 关联关系:参数如何交互,以及如何处理多个值
好的描述会在摘要之外提供更多细节。不好的描述只是重复摘要。
好:
'Create a new conversation with an agent. The conversation persists across sessions and can be shared with other users via access control. To learn more, refer to the [agent chat documentation](https://www.elastic.co/docs/...).'不好:(重复摘要,没有增加任何信息)
'Creates a conversation.'需要标记的问题:
- ❌ 缺少
description - ❌ 描述只是复制或重复摘要
- ❌ 描述省略了用户需要了解的约束条件或前置条件
4. Narrative documentation link
4. 叙述性文档链接
Route descriptions should include a trailing sentence linking to the relevant narrative docs page. This is a convention observed across existing Kibana routes. It is most important when sibling routes on the same resource already include such a link.
Pattern:
typescript
description:
'List all conversations. To learn more, refer to the [agent chat documentation](https://www.elastic.co/docs/...).',How to check: compare against sibling routes. If other routes on the same resource include a "To learn more..." or "refer to the docs" link and the new route does not, flag it.
What to flag:
- ❌ Missing narrative doc link when siblings include one (warning, not error — the link might not exist yet for a brand-new feature)
路由描述应在末尾包含一个指向相关叙述性文档页面的句子。这是现有 Kibana 路由中观察到的约定。当同一资源的同级路由包含此类链接时,尤为重要。
模式:
typescript
description:
'List all conversations. To learn more, refer to the [agent chat documentation](https://www.elastic.co/docs/...).',检查方法:与同级路由进行比较。如果同一资源上的其他路由包含“To learn more...”或“refer to the docs”链接,而新路由没有,则进行标记。
需要标记的问题:
- ❌ 当同级路由包含链接时,新路由缺少叙述性文档链接(警告,非错误——全新功能可能尚不存在对应链接)
5. Tags
5. 标签
Routes MUST have at least one entry in their array. Tags group APIs by feature in the published docs.
oas-tag:tagsTag guidelines:
- Use sentence case: not
'oas-tag:Agent builder''oas-tag:agent builder' - Use consistent tag names across related routes
- One per route for clean navigation
oas-tag
What to flag:
- ❌ No in the tags array
oas-tag:* - ❌ Tag name uses inconsistent casing vs. sibling routes
- ❌ Multiple entries on a single route
oas-tag:
路由的 数组中至少要有一个 项。标签用于在已发布的文档中按功能对 API 进行分组。
tagsoas-tag:标签指南:
- 使用句首大写形式:,而不是
'oas-tag:Agent builder''oas-tag:agent builder' - 相关路由使用一致的标签名称
- 每个路由使用一个 ,以保持导航清晰
oas-tag
需要标记的问题:
- ❌ 数组中没有
tagsoas-tag:* - ❌ 标签名称的大小写与同级路由不一致
- ❌ 单个路由中有多个 项
oas-tag:
6. Path parameter descriptions
6. 路径参数描述
Every path parameter MUST have in its schema definition.
meta: { description: '...' }Correct pattern:
typescript
params: schema.object({
conversation_id: schema.string({
meta: { description: 'The unique identifier of the conversation.' },
}),
}),What to flag:
- ❌ A path parameter has no or no
metainsidedescriptionmeta
每个路径参数都必须在 schema 定义中包含 。
meta: { description: '...' }正确模式:
typescript
params: schema.object({
conversation_id: schema.string({
meta: { description: 'The unique identifier of the conversation.' },
}),
}),需要标记的问题:
- ❌ 路径参数没有 ,或
meta中没有metadescription
7. Property descriptions
7. 属性描述
Every new request body, query, or response property MUST have .
meta: { description: '...' }A good property description explains what the value controls, its format, and any constraints:
- ❌ — vague, no constraints, no default
'The page size.' - ✅
'The maximum number of results to return. Must be between 1 and 1000. Defaults to 20.'
What to flag:
- ❌ New property has no at all
meta - ❌ exists but has no
metadescription - ❌ Description is a single generic phrase that restates the property name (for example, on a property called
'The name.')name
每个新的请求体、查询或响应属性都必须包含 。
meta: { description: '...' }好的属性描述应说明该值控制什么、采用什么格式,以及有哪些约束:
- ❌ ——描述含糊,没有约束或默认值
'The page size.' - ✅
'The maximum number of results to return. Must be between 1 and 1000. Defaults to 20.'
需要标记的问题:
- ❌ 新属性完全没有
meta - ❌ 存在 ,但其中没有
metadescription - ❌ 描述只是用通用短语重复属性名称,例如在名为 的属性上使用
name'The name.'
8. Enum value descriptions
8. 枚举值描述
When a property uses or to define a fixed set of values, each value should be described, either in the property description or in the individual schema options.
schema.oneOfschema.literalSkip documenting values that are self-explanatory:
- /
true,false/asc,desc/enabled— obvious from the namedisabled - /
read/write— not obvious; what doesadmingrant beyondadmin?write - /
low/medium— not obvious; what concretely changes at each level?high
What to flag:
- ❌ Enum values with no descriptions when the meaning or behavioral difference is unclear from the name
当属性使用 或 定义固定值集合时,应为每个值提供说明,说明可以放在属性描述中,也可以放在各个 schema 选项中。
schema.oneOfschema.literal无需说明含义显而易见的值:
- /
true、false/asc、desc/enabled——名称本身已足够明确disabled - /
read/write——并不明显;admin除了admin之外还授予什么权限?write - /
low/medium——并不明显;每个级别具体会改变什么?high
需要标记的问题:
- ❌ 枚举值的含义或行为差异无法从名称中明确判断,却没有相应说明
9. Default values
9. 默认值
Optional parameters and properties should document their defaults. In Kibana route schemas, this means using or documenting the server-side default in the description.
schema.maybe(schema.string({ defaultValue: '...' }))Correct pattern:
typescript
page_size: schema.maybe(
schema.number({
defaultValue: 20,
meta: { description: 'Number of results per page. Defaults to 20.' },
})
),When the default is set server-side (not in the schema), document it in the description instead:
'Sort order. The server defaults to descending if not specified.'How to check: compare against sibling routes on the same resource. If a sibling documents its default but the new route does not, flag it.
page_sizeWhat to flag:
- ❌ Optional parameter with an undocumented default when the behavior changes based on the value
可选参数和属性应记录默认值。在 Kibana 路由 schema 中,这意味着使用 ,或在描述中注明服务器端默认值。
schema.maybe(schema.string({ defaultValue: '...' }))正确模式:
typescript
page_size: schema.maybe(
schema.number({
defaultValue: 20,
meta: { description: 'Number of results per page. Defaults to 20.' },
})
),当默认值在服务器端设置(而非在 schema 中设置)时,应在描述中记录:
'Sort order. The server defaults to descending if not specified.'检查方法:比较同一资源上的同级路由。如果同级路由记录了 的默认值,而新路由没有,则进行标记。
page_size需要标记的问题:
- ❌ 可选参数的行为会随取值而变化,却没有记录默认值
10. Property-level availability
10. 属性级 availability
When a new property is added to an existing route's schema, and that property ships in a later version than the route itself, the property MUST have its own with and .
meta.availabilitystabilitysinceHow to detect: look for added or fields inside an existing route's validation block. If the route has and the new property ships in , the property needs its own availability.
schema.maybe(...)schema.object(...)since: '9.2.0''9.6.0'Correct pattern:
typescript
new_field: schema.maybe(
schema.string({
meta: {
availability: { stability: 'experimental', since: '9.6.0' },
description: 'Description of the new field.',
},
})
),What to flag:
- ❌ New property on an older route has no
meta.availability - ❌ Property has but is missing
availabilityorstabilitysince
当现有路由的 schema 中新增了属性,且该属性的发布版本晚于路由本身的版本时,该属性必须具有自己的 ,其中包含 和 。
meta.availabilitystabilitysince检测方法:查看现有路由验证块中新增的 或 字段。如果路由的 为 ,而新属性在 发布,则该属性需要自己的 availability。
schema.maybe(...)schema.object(...)since'9.2.0''9.6.0'正确模式:
typescript
new_field: schema.maybe(
schema.string({
meta: {
availability: { stability: 'experimental', since: '9.6.0' },
description: 'Description of the new field.',
},
})
),需要标记的问题:
- ❌ 旧路由上的新属性没有
meta.availability - ❌ 属性有 ,但缺少
availability或stabilitysince
11. Deprecation
11. 弃用
Deprecated routes or properties should be marked. In Kibana, the route's supports a flag, and property descriptions should explain the deprecation.
optionsdeprecatedWhat to flag:
- ❌ A property or route is described as deprecated in comments or description text but has no marker
deprecated: true - ❌ Deprecated property has no description explaining what to use instead
已弃用的路由或属性应进行标记。在 Kibana 中,路由的 支持 标志,属性描述则应说明弃用情况。
optionsdeprecated需要标记的问题:
- ❌ 属性或路由在注释或描述文本中被说明为已弃用,但没有 标记
deprecated: true - ❌ 已弃用的属性没有说明应改用什么的描述
12. Response examples
12. 响应示例
New routes SHOULD have an example file referenced via . Examples significantly improve API documentation usability.
oasOperationObjectInline TypeScript examples (type-checked at dev time):
typescript
.addVersion({
version: '2023-10-31',
options: {
oasOperationObject: () => ({
requestBody: {
content: {
'application/json': {
examples: {
example1: {
summary: 'An example request',
value: { name: 'Example' } as MyType,
},
},
},
},
},
}),
},
})YAML file examples:
typescript
import path from 'node:path';
.addVersion({
version: '2023-10-31',
options: {
oasOperationObject: () => path.join(__dirname, 'examples/my_route.yaml'),
},
})Example YAML structure (in ):
server/routes/examples/yaml
requestBody:
content:
application/json:
examples:
example1:
summary: Example request
description: An example of creating a resource
value:
name: 'Example'
responses:
200:
content:
application/json:
examples:
success:
summary: Successful response
value:
id: '12345'
name: 'Example'Example guidelines:
- Use realistic data, not placeholders
- Write clear summaries (under 45 characters) for each example
- Include at least one success response example (HTTP 200)
- Consider adding for cURL and Console examples
x-codeSamples
What to flag:
- ❌ No reference (warning — strongly recommended)
oasOperationObject - ❌ Example file contains placeholder or empty values
- ❌ No response example for the success case
新路由应当通过 引用一个示例文件。示例可显著提升 API 文档的可用性。
oasOperationObject内联 TypeScript 示例(开发时进行类型检查):
typescript
.addVersion({
version: '2023-10-31',
options: {
oasOperationObject: () => ({
requestBody: {
content: {
'application/json': {
examples: {
example1: {
summary: 'An example request',
value: { name: 'Example' } as MyType,
},
},
},
},
},
}),
},
})YAML 文件示例:
typescript
import path from 'node:path';
.addVersion({
version: '2023-10-31',
options: {
oasOperationObject: () => path.join(__dirname, 'examples/my_route.yaml'),
},
})示例 YAML 结构(位于 ):
server/routes/examples/yaml
requestBody:
content:
application/json:
examples:
example1:
summary: Example request
description: An example of creating a resource
value:
name: 'Example'
responses:
200:
content:
application/json:
examples:
success:
summary: Successful response
value:
id: '12345'
name: 'Example'示例指南:
- 使用真实数据,而不是占位值
- 为每个示例编写清晰的摘要(少于 45 个字符)
- 至少包含一个成功响应示例(HTTP 200)
- 可以考虑为 cURL 和 Console 示例添加
x-codeSamples
需要标记的问题:
- ❌ 没有引用 (警告——强烈建议添加)
oasOperationObject - ❌ 示例文件包含占位值或空值
- ❌ 成功情况没有响应示例
13. Operation ID (advisory only — do not include in the Actions list)
13. Operation ID(仅供参考——不要加入 Actions 列表)
Public routes can optionally set an explicit . SDK and CLI generators use this ID as the method/command name; if omitted, the generator derives one from the method and path (for example, ), which is often unclear.
operationIdpost-fooCorrect pattern:
typescript
router.versioned.post({
path: '/api/foo',
access: 'public',
summary: 'Create a foo resource',
operationId: 'create-foo',
options: { ... },
});Guidelines:
- Use kebab-case names, for example
verb-resource,create-foo,get-foo.delete-foo - Keep operation IDs stable across versions of the same route — don't rename gratuitously.
This is a suggestion, not a compliance rule — do not add it to the ❌ Actions list or count it against the verdict. Only raise it as a one-line side note ("Consider adding an explicit ") when the user specifically asks about SDK/CLI generation, operation IDs, or when a route in the diff already sets one inconsistently with the kebab-case convention.
operationIdverb-resource公开路由可以选择显式设置 。SDK 和 CLI 生成器会将此 ID 用作方法或命令名称;如果省略,生成器会从方法和路径推导出一个名称,例如 ,而这种名称通常不够清晰。
operationIdpost-foo正确模式:
typescript
router.versioned.post({
path: '/api/foo',
access: 'public',
summary: 'Create a foo resource',
operationId: 'create-foo',
options: { ... },
});指南:
- 使用 kebab-case 的 名称,例如
verb-resource、create-foo、get-foodelete-foo - 同一路由在不同版本间保持 operation ID 稳定——不要随意重命名
这只是一项建议,并非合规规则——不要将其加入 ❌ Actions 列表,也不要计入结论。仅当用户明确询问 SDK/CLI 生成、operation ID,或 diff 中的某个路由已设置了一个与 kebab-case 约定不一致的 ID 时,才以一行旁注提出。旁注内容为 。
verb-resource"Consider adding an explicit operationId"14. Cross-check: generated YAML as a diagnostic signal
14. 交叉检查:把生成的 YAML 作为诊断信号
The YAML files under are auto-generated. Never suggest editing the YAML directly. Every fix goes in the TypeScript source.
oas_docs/output/Use the YAML values to detect problems:
x-stateYAML | TypeScript meaning |
|---|---|
| |
| |
| |
| Normal for |
| Missing |
| Missing entirely | Missing |
What to flag (always pointing at the TypeScript file):
- ❌ Empty or missing → trace to the TS route and flag missing
x-stateoravailabilitystability - ❌ YAML label does not match TS stability → flag the TS mismatch
- The serverless YAML omitting is expected, not a finding
added in
oas_docs/output/使用 YAML 中的 值检测问题:
x-stateYAML | TypeScript 含义 |
|---|---|
| |
| |
| |
| 对 |
| TypeScript 的 |
| 完全缺失 | TypeScript 中缺少 |
需要标记的问题(始终指向 TypeScript 文件):
- ❌ 为空或完全缺失 → 回溯到 TS 路由,并标记缺少
x-state或availabilitystability - ❌ YAML 标签与 TS 中的 stability 不匹配 → 标记 TS 中的不一致之处
- serverless YAML 省略 属于预期行为,不是问题
added in