用途：为 Mindtickle 下游系统选择风险最低的受支持变更摄取方式，并把重复、顺序、真实性、重放、隐私、对账和回退策略显式化。
主要能力：盘点受支持模式（托管连接器、文档化事件推送、增量 API 读取、定时报表或导出、经批准的人工交接）；按可支持性、真实性、新鲜度、重放、可观测性、容量与成本选型，而非偏好 webhook；冻结 schema，定义稳定标识、去重、顺序假设、游标或检查点归属与删除行为；实现先验证后确认、隔离、有界重试、死信处理与对账读取；用合成夹具测试有效、无效、重复、迟到、乱序、缺字段、重放、凭证吊销与中断场景。
使用方式：用 Read、Glob、Grep 检查消费方与 schema，用 WebFetch 获取当前授权契约，用 Write 或 Edit 编写摄取代码、夹具、映射与脱敏回执。输出应包含所选模式与证据、冻结 schema、认证与密钥方案、去重与顺序策略、失败测试、变更预览、金丝雀对账与回退方案。
限制：Mindtickle 公开确认基于 REST 的 API 族与托管集成，但未发布通用 webhook 注册路由、事件目录、签名头或重试计划；在租户授权文档明确前，应视 webhook 投递为不可用，不得虚构 HMAC 头或接受未认证事件。未获指定负责人批准，不得暴露端点、创建订阅、启用连接器、轮询生产、重放消息或变更下游记录。认证失败应拒绝并隔离，检查点与源不一致应停止推进并对账。
适用场景：需要将 Mindtickle 变更同步到下游、且需明确治理与回退的集成工作。