用途：这是一个面向数据仓库导入完整性的侦察技能。仓库导入指外部系统（如 Postgres CDC、Stripe、Hubspot、webhook 推送）按计划把数据持续写入 PostHog；导入失败往往很隐蔽——PostHog 其余部分照常运行，仪表盘仍在，但背后的仓库表已悄悄过期，每个错过的同步周期都会形成永久缺口。该技能负责捕捉导入违背承诺的时刻。
主要能力：区分“已配置同步”与“实际在同步”、“承诺新鲜度”与“实际新鲜度”。已启用（should_sync: true）且符合 sync_frequency 的 schema 属基线；已启用却 Failed、卡在 Running 数小时、或名义 Completed 但 last_synced_at 远落后于节奏的 schema 才是信号。暂停的 schema、计费限制状态、从未配置的草稿源属操作者选择，不算异常。次要通道是优化机会：当导入正常时，观察团队如何查询仓库，针对反复出现、多用户、集中在单表或单一查询形态的耗时查询，建议建模优化。
使用方式：通过 SQL 扫描 system.source_schemas 等元数据表获取导入清单，再用 REST 接口下钻。例如用 SELECT status, count() AS schemas, uniq(source_id) AS sources FROM system.source_schemas WHERE should_sync AND deleted = 0 GROUP BY status 判断是否有已启用导入。候选 schema 用 external-data-schemas-list（需带 search 过滤）取 sync_frequency 与 latest_error，用 external-data-sources-retrieve {source_id} 确认连接级状态，用 external-data-sources-webhook-info-retrieve {source_id} 检查 webhook 通道。报告通过 scout-emit-report / scout-edit-report 直接撰写，已覆盖的缺口应编辑而非新建。
适用场景：源级 Error 级联、schema 失败与卡死、Completed 但落后节奏的静默过期、绿色状态下的 webhook 失效、行量骤降、物化视图失败，以及查询优化建议。
限制：活动历史为可选能力，不可用或拒绝访问时应停止使用该读取器，不重试、不绕过、不为此提交缺工具报告。优化通道仅在完整性通道安静时运行，存在 P1/P2 导入缺口时跳过。查询日志分析需加多个过滤条件，且结构化洞察节点不记录 SQL 文本，覆盖有限。所有发现均为假设，需人工验证。具体字段、状态映射、评审路由与去重规则由 harness 提示承载，本资料未完整提供。