| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| admin | ||
| ai | ||
| assistant | ||
| auth | ||
| clinical-gap | ||
| clinical-signals | ||
| facts | ||
| mcp | ||
| patient | ||
| persona | ||
| plan | ||
| plan-aggregate | ||
| realtime-coach | ||
| sync | ||
| weixin-aibot |
测试服实测(第二轮增量):cohort 列出 15,107 人,其中「复杂病例变了但人没来诊」的 19 人确实被 UNION 分支正确带进了 cohort,但他们的 host_follow_up_active 始终没更新。 根因在 loadTablesForCohort:主档 query 同时被注入 cursor 和 cohort 过滤 → WHERE last_visit_time > '2026-07-30 09:36' AND (patient_id,brand) IN (<本批 tuples>) 这些人末次就诊在几个月前 → 被 cursor 挡掉 → 主档整轮拉不到 → 不 upsert。 batch 日志早有征兆:cohort 726 人,fact_client_out 只回 675 行。 cohort 已经是比 cursor 更强的限定(它就是"本轮要处理哪些患者"的答案), 主档再叠 cursor 是多余且有害的。非 cohort 模式靠 reversePullPatientMaster 兜这个场景, cohort 模式此前无兜底 —— 与其再补一次反向拉,不如从源头去掉这个条件。⚠ ️ 这是**既有缺陷**,不是本次接入引入的:任何"事实变了但 last_visit_time 没变"的患者 (EMR 补写、预约改期),其主档在 cohort 模式下本来就整轮不更新。此前只表现为主档字段 偶尔陈旧、被 stub 兜住不易察觉;到了派生列(主档不拉 = 列不重算)才致命。 cursorAdvances 不受影响:bundle 水位写的是 run_start baseline,不取 max。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| admin | Loading commit data... | |
| ai | Loading commit data... | |
| assistant | Loading commit data... | |
| auth | Loading commit data... | |
| clinical-gap | Loading commit data... | |
| clinical-signals | Loading commit data... | |
| facts | Loading commit data... | |
| mcp | Loading commit data... | |
| patient | Loading commit data... | |
| persona | Loading commit data... | |
| plan | Loading commit data... | |
| plan-aggregate | Loading commit data... | |
| realtime-coach | Loading commit data... | |
| sync | Loading commit data... | |
| weixin-aibot | Loading commit data... |