check-doc-component-consistency

name	check-doc-component-consistency
description	只做组件文档与源码实现的一致性核对或最小修正。用户要求核对 props、events、slots、methods、默认值、命名是否准确，但未要求迁移文档结构、重排 Demo 或升级到新规范时调用。

文档与实现一致性校对技能

用于系统校对组件文档与组件源码实现是否一致，输出差异清单并给出最小改动修正方案。

默认遵循 wot-ui-component-baseline 中的共享约束。

何时使用

• 用户要求“检查文档和组件实现是否一致”。
• 用户反馈“文档参数/事件与实际行为不符”。
• 用户要求“只做核对，不做大规模迁移重构”。
• 在发版前做组件 API 文档一致性巡检。

何时不要使用

• 用户明确要求“迁移到新文档规范”。
• 用户要求重排 Demo 章节结构或调整 Attributes/Options 表结构。
• 用户要新建或重构 Demo 页。

以上场景应优先使用 migrate-component-doc 或 create-demo-page。

校对范围

• Attributes（props 名称、类型、默认值、可选值、平台限制）
• Events（事件名、参数签名、触发时机）
• Slots（插槽名、作用域参数）
• Methods（对外暴露方法与入参）
• 示例代码（是否可映射到真实能力与当前 API）

核心规则

1. 以组件源码为事实来源，文档向源码对齐。
2. 仅报告可证实差异，不做主观推断。
3. 无源码依据的文档能力标记为“待确认/建议删除”。
4. 保持最小修改原则，优先修正文案与 API 表，不无关重排结构。

执行步骤

1. 定位目标组件源码与对应文档文件。
2. 提取源码 API：props / emits / slots / expose methods。
3. 提取文档 API：Attributes / Events / Slots / Methods。
4. 逐项对比并输出差异：缺失、冗余、命名不一致、类型不一致、默认值不一致。
5. 给出修复建议并直接生成可应用的文档改动。
6. 进行一次诊断或构建检查，确保文档可通过校验。

输出格式

• 一致性结论（通过 / 不通过）
• 差异清单（按模块分组）
• 已修复项与未修复项
• 风险说明（若存在待确认能力）

示例触发语句

• “帮我校对一下 picker 文档和组件实现是否一致”
• “检查 upload 的 events 和 methods 文档是不是准确”
• “这个组件文档有点旧，先做一致性核查并修正”