component-docs

组件文档

根据组件自身资料编写的草稿条目。缺失信息会标出，不会补写。不会评价设计，也不会发布任何内容。标题顺序和完整示例见 references/doc-format.md。

步骤

1. 将 references/doc-format.md 中的九个标题粘贴到草稿中，暂不填写内容。
2. 找到组件。阅读其代码、props 类型、样式和 stories，并将每项记录为一条 Sources 行。
3. 通过调用位置搜索或根据请求，找到两个实际用例。实际用例只有一个或没有时，按下方的停止表处理。
4. 追踪每个示例、变体、prop、状态和 token 分别来自哪个资料来源。资料来源之间的每处分歧都要在 Conflicts 下列出一行，并附上用于裁定的规则原文，或写上“没有规则，未作选择”。
5. 根据资料来源中的事实填写每个部分，逐字复制 token 名称和示例代码。
6. 最后编写 Usage rules。每条规则格式为 rule/<component>-<slug>，并包含条件、操作、理由、依据（两个调用位置、一项附路径的测量结果、一条有名称的原则或当事人的原话），以及一行 Don't:，其中要附上违反该规则的真实代码。无法用代码片段反例说明的规则应删除。
7. 每个判断各用一行填写 Guessed at。对照下方的 Done 清单重新阅读草稿。

输出

依次输出条目、Sources、Conflicts、Guessed at，以及仅在规则新增问题时才输出的 Gates（问题及其默认值）。单独运行时，会保存到 docs/system/<name>.md，并在第 1 行写入草稿注释，同时为每个缺失的示例文件写入内容。回复开头说明路径、条目涵盖的内容及其状态，然后最多提出三个带默认值的问题，并提供一条当事人可粘贴以继续下一步的提示词。

停止条件

搜索后仍缺失的内容	停止原因
代码	没有其他资料来源能说明变体、props 或行为
变体列表（props 类型或 stories）	猜测的列表描述的是另一个组件
任何用例，无论实际还是计划中的	虚构的用例看起来像真实用例，读者会优先照抄

props 类型中没有变体 prop 时，变体列表为空。变体一栏填写“无”，流程继续。一个实际用例、计划中的用例和已弃用的前代组件都应标明其性质，不会导致停止。停止时应返回停止原因、截至目前各部分找到的事实，以及解除阻塞所需的最简回复（“一个屏幕名称、组件被放入该屏幕的原因，以及所展示的变体”）。

规则

• 绝不编写没有列出资料来源的变体、prop、token 名称、示例或用例。计划中的用例必须标明为计划中。
• 绝不为让某个部分看起来完整而虚构状态或优先顺序。
• 看起来像 bug 的行为应按实际情况记录，并在发给负责人的 Defect: 行中说明对用户造成的问题以及最小修复方案。
• 可单独使用的部分应在 Description 下添加 ### Parts 小节。复合组件（如带有 Tab 的 Tabs）作为一个条目记录。
• 不要编辑正在编写文档的代码、stories 或规范。
• 回复中的计数取自保存文件中草稿注释下方的 grep -o 结果。

完成标准

每个变体、prop、token 和示例都有一条 Sources 行。每条 Usage rule 都有依据和 Don't: 行。每处冲突都已列出。九个标题按顺序齐全；没有资料来源的部分应写明 Not applicable: <reason>。