3351c68d10
PP-03 凭据泄露处置： - 清除 wiki + 2 份历史文档中的 Redis 明文密码与公网 IP（4 文件 5 处） - wiki 新增安全告警 + 症状导航条目 - 核实降级：泄露旧密码已失效，HMS 连本地 Redis，云端闲置；公网已关闭 系统深度分析（9 维度 + 6 主题多专家组）： - docs/discussions/2026-06-25-analysis/ 新增 7 文件 - 综合 6.8/10，4 CRITICAL，TOP 12 痛点，4 阶段路线图 wiki 关键数字校正（PP-02/05a fix 触发）： - 迁移数 175→176（m20260626_000170） - 症状导航新增 device_readings 分区硬截止 + claim_next 注入修复条目
193 lines
23 KiB
Markdown
193 lines
23 KiB
Markdown
# HMS 健康管理平台 — 项目负责人决策简报
|
||
|
||
> 日期: 2026-06-25 | 分支: feat/media-library-banner | 阶段: V1 CONDITIONAL GO（上线临门一脚）
|
||
> 范围: 9 维度评分 → TOP 12 痛点收敛为 TOP 5 决策项 → 6 主题战略 → 4 阶段路线图 → TOP 7 行动建议
|
||
> 面向: V1 上线后 6-12 个月演进，不重复上线前就绪度讨论
|
||
> 证据口径: 所有论断附 `文件路径:行号` 或 grep 结果，基于 feat/media-library-banner 分支实测
|
||
|
||
---
|
||
|
||
## 一、执行摘要
|
||
|
||
HMS 是一个工程完成度相当高的医疗 SaaS 平台：后端架构分层严格（L1/L2/L3 + 无环依赖图 + Outbox 事件总线 + 双层多租户），PII 加密与 V2 审计 CRITICAL 修复已达企业级，AI 模块 4 Provider + ReAct + RAG 工程完成度高，前端架构成熟、小程序并发治理扎实。**综合评分 6.8 / 10（B）**，处于「可支撑 V1 上线，但距生产级品质与主动关怀引擎定位还差关键闭环」的阶段。
|
||
|
||
本次分析发现的核心张力是：**多处宣称已完成的自动化链路实际断裂，且真相源（wiki）与代码系统性漂移，叠加支撑层（DevOps 4.2 / 测试 5.5）严重缺位，使上层可靠性无护栏兜底**。最尖锐的 4 个 CRITICAL 级问题中，3 个是「文档说已修复、代码说没有」——死信重试从未接线（PP-01）、AI 分析队列只入队不消费（PP-05）、RLS 误记 FORCE（PP-07）；第 4 个是生产 Redis 密码明文进 git 追踪的 wiki（PP-03）。叠加 2026-09-01 确定性硬截止的 device_readings 分区过期（PP-02），HMS 当前处于「能上线，但上线后 3 个月内有 4 个定时炸弹」的状态。
|
||
|
||
**决策层结论：V1 可按计划上线，但上线前必须完成 Phase 0 护航清单（≤2 周），否则上线后 MTTR 不可控、客户基于错误假设运营、AI 主动关怀承诺空转。**
|
||
|
||
---
|
||
|
||
## 二、综合评分
|
||
|
||
### 综合分: **6.8 / 10 (B)**
|
||
|
||
加权规则：后端架构 / 安全合规 / 数据层 权重高（×1.3）；后端业务 / Web / 小程序 / AI 权重中（×1.0）；测试 / DevOps 低分但权重中（×0.9，避免低分区过度拉低但保留短板信号）。
|
||
|
||
### 维度评分表
|
||
|
||
| # | 维度 | 分数 | 一句话定位 |
|
||
|---|------|------|-----------|
|
||
| 1 | 后端架构 | **8.0** | 全系统最扎实：L1/L2/L3 分层严格 + 无环依赖（Kahn 拓扑）+ Outbox 持久化 + 双层多租户；扣分在死信未接线（events.rs:382 零调用）+ module.rs 918 行超限 + 4/8 模块 register_event_handlers 空壳 |
|
||
| 2 | 后端业务实现 | **7.5** | CAS 并发控制与事务边界扎实（积分/库存/排班/签到全部 update_many+version）；扣分在 check-then-insert 竞态 + 状态白名单不一致 + VersionMismatch 无重试 + points/alert/stats 无单测 |
|
||
| 3 | 数据层 | **7.3** | schema/软删除/UUIDv7/SQL 注入防护优秀，JSONB GIN 在 risk_service 落地；扣分在分区无自愈（PP-02）+ RLS 缺 FORCE（PP-07）+ 连接池 SET 串扰（PP-08）+ pg_trgm 装了没用 + m000109 down 迁移静默失效 |
|
||
| 4 | 安全合规 | **7.3** | PII 加密（AES-256-GCM + KEK/DEK + HMAC 盲索引）企业级 + V2 CRITICAL 已修；硬伤：Redis 密码泄露（PP-03）+ token 黑名单非分布式 + 患者姓名明文（PP-12）+ 无数据导出 |
|
||
| 5 | AI 能力 | **6.5** | 4 Provider + ReAct + RAG + 引用溯源工程完成度高（17.7k LOC/196 测试）；半成品自动化（AnalysisQueue 死存储 PP-05 + SSE token len/4 计量失真 + 无主动触达） |
|
||
| 6 | Web 前端 | **7.2** | 架构成熟（routeConfig + DEV 校验 + 6 store + token 预刷新 + any 16→1）；僵尸 UI（6 条 navigate 死链 PP-09 + value=0 占位）+ i18n 全缺 + AuthButton 仅 28% |
|
||
| 7 | 小程序端 | **7.0** | 并发治理/AES 缓存/BLE 离线缓冲生产级；扣分在告警角标写错 Tab（PP-06）+ 11 页缺 elder-mode（与 wiki 不符）+ setTimeout 未治理 + BLE 基础设施 0 单测 |
|
||
| 8 | DevOps 与可观测性 | **4.2** | 备份加密 + Prometheus 指标 + TLS + 安全头已加固；三支柱全残（无 Alertmanager/Grafana/日志聚合/追踪 PP-04）+ 无 CD + 单副本 + 迁移在启动路径 |
|
||
| 9 | 测试与质量保障 | **5.5** | 1031 测试函数 + 真实 PG 集成测试是基线；金字塔失衡（无覆盖率工具 + CI 不跑 E2E + CI 集成仅覆盖 erp-server + erp-health 29 service 零内联测试 PP-10） |
|
||
|
||
**核心张力：** 架构层（8.0）与支撑层（DevOps 4.2 / 测试 5.5）落差达 3.8 分——「上层的可靠性没有底层的护栏兜底」，这正是潜伏故障（PP-01/PP-05）能流入仓库的根因，也是历史 24% fix 提交率的系统性成因。
|
||
|
||
---
|
||
|
||
## 三、TOP 5 最紧迫痛点（决策优先级排序）
|
||
|
||
> 从 TOP 12 收敛为决策层必须亲自盯的 5 项。每项标注「为什么是决策项而非技术项」。
|
||
|
||
### PP-03 [CRITICAL/立即] 生产 Redis 密码明文进 git 追踪的 wiki（含公网 IP），凭据已实际泄露
|
||
`wiki/infrastructure.md:35/57` 直接写明 `redis://:redis_KBCYJk@129.204.154.246:6379`，git ls-files 确认被追踪。**影响：** Redis 承载限流 token bucket、DEK 缓存、微信 session_key、token 黑名单——接管 Redis = 绕过限流暴破 + 解密微信手机号 + 登出失效。这是唯一一个「已在进行中」的合规事件，每拖一天风险递增，医疗 SaaS 凭据泄露触发等保三级 / 个保法合规事件。**为什么是决策项：** 触碰 CLAUDE.md §3.7「密钥禁止硬编码」铁律，且凭据已暴露给所有仓库访问者（含未来成员/外包），需立即轮换 + git filter-repo 清洗历史，是法律层面的强制义务。
|
||
|
||
### PP-02 [CRITICAL/立即] device_readings 分区硬编码到 2026-08，2026-09-01 起 BLE 数据上传全线中断（确定性硬截止）
|
||
`migration/m20260426_000073_create_device_readings.rs:42-47` 静态建 4 个分区，全仓 grep `PARTITION OF`/`create_partition`/`pg_partman` 无任何未来分区自动创建机制。**影响：** 这是确定性故障而非概率性 bug——今天 2026-06-25 距硬截止仅 ~10 周，发生在 V1 上线后 3 个月、客户已依赖数据时点。Veepoo M2 管线是患者端核心卖点，中断即产品不可用，且影响信任度与续约。**为什么是决策项：** 时间窗固定、影响面 100% 患者端、客户感知度极高，必须在上线前或上线后 2 周内补建未来分区。
|
||
|
||
### PP-01 [CRITICAL/立即] 死信重试函数从未接线，业务关键链路「死信即终点」
|
||
`crates/erp-core/src/events.rs:382` 定义了 `retry_dead_letters`，但 grep 全 crates/ 该符号仅命中定义处，`erp-server/src/tasks.rs` 未注册调度。**影响：** 危急值告警 / 积分发放 / 预约提醒 / article 推送 / follow_up 触发积分——任一因瞬时故障（DB 超时、网络抖动）失败即永久滞留 dead_letter_events 表，wiki 还误记为「每小时定时任务已修复」。**为什么是决策项：** 触碰 CLAUDE.md「每个事件必须有消费者」铁律，文档与代码漂移使团队基于错误假设运营，事故发生时无告警无重试无人工介入流程，MTTR 不可控。
|
||
|
||
### PP-04 [CRITICAL/立即] 可观测性三支柱全残缺，生产处于「盲飞」状态
|
||
`docker/prometheus/alerts.yml` 有 12 条告警规则但 `docker/` 下 grep alertmanager/loki/jaeger 0 命中——规则只写入 TSDB 无任何通知出口；`docker/grafana/provisioning/` 为空目录；日志仅 stdout 无聚合；30+ 文件含 tracing:: 宏但无 trace_id 贯穿。**影响：** 配合 PP-01/PP-02/PP-05 等潜伏故障，数据库宕机、5xx 飙升、Redis 不可达等 critical 告警完全无人知晓，事故发生到客户投诉之间团队毫无察觉，跨模块医疗业务无 trace_id 无法还原请求路径。**为什么是决策项：** 这是 DevOps 4.2 分的根本原因，也是 V1 上线后 6-12 个月最大的运营风险，决定上线后「是睡觉还是救火」。
|
||
|
||
### PP-09 [HIGH/立即] Web 工作台 4 个 Dashboard 共 6 条 navigate 指向不存在路由 + value={0} 占位
|
||
AdminDashboard.tsx:51 `navigate('/health/follow-ups')`、DoctorDashboard 同样指向 `/health/lab-reports`/`/health/vital-signs`、OperatorDashboard:69 等 3 处 `navigate('/health/points')`——对照 App.tsx:296-359 路由表均不存在，PrivateRoute 未匹配前缀默认 403；叠加 AdminDashboard.tsx:88 `value={healthDataStats ? 0 : 0}` 死代码占位。**影响：** 影响 100% 角色、100% 用户、上线即暴露——管理员/医生/运营/护士首屏点击核心数据卡片全部跳 403，「咨询待回复」「线下活动」恒显示 0。医疗管理后台展示假数据是信任度致命伤。**为什么是决策项：** 这是当前未提交改动（统计仪表盘重构）引入的新缺陷，必须在合并前修复，否则首日客户演示即翻车。
|
||
|
||
---
|
||
|
||
## 四、6 主题一句话战略
|
||
|
||
| # | 主题 | 一句话战略 |
|
||
|---|------|-----------|
|
||
| T1 | **稳定性与上线护航** | 以「确定性故障自愈」为核心（PP-01 死信接线 + PP-02 分区补建 + PP-05 AI 队列通电），配合迁移解耦启动路径 + cron_heartbeat 进就绪门禁 + Alertmanager 三级告警，把「上线即救火」变成「上线即睡觉」。详见 `01-stability.md` |
|
||
| T2 | **技术债与架构演进** | 把五类结构性缺陷（事件契约/模块边界/后台任务/多租户隔离/schema 演进）从「文档约定 + 人肉记忆」升级为「编译期/CI 可校验的类型契约 + 机制层防护」（FORCE RLS + SET LOCAL + TaskRegistry + Schema 注册表），为 2-3 年后微服务化打下「可演进而非可重写」的地基。详见 `02-architecture.md` |
|
||
| T3 | **AI 智能化纵深** | 以「闭合已存在但空转的能力」为第一性原理分三步走——通电（PP-05 AnalysisQueue 消费者）→ 可信（双层记忆 + 引用溯源 + RAG 评估集）→ 可度量（真实 token 成本 + 建议转化率仪表盘），把 HMS 从「医生敲回车才出报告」进化为「感知→推理→行动→复盘」的主动关怀引擎。详见 `03-ai-depth.md` |
|
||
| T4 | **多端体验统一** | 以「行为契约一致」取代「像素级对齐」作为多端度量：同一份设计 Token 单源 + 同一份交互契约 + 同一类语义组件（AlertCard/EmptyState/VitalCard），先根治 PP-09 死链与 PP-06 角标错位（0.5 人日/项速赢），再以 CI 可校验的硬约束让设计系统从审美问题升级为医疗可见性错误防线。详见 `04-multidevice-ux.md` |
|
||
| T5 | **医疗合规与数据治理** | 把 HMS 从「修漏洞式合规」升级为「可举证的持续合规闭环」：以 PII 加密对称（患者姓名加密 PP-12）+ 数据分类分级引擎 + 数据主体权利履行通道（个保法 §45/§47 + 病历 15 年留存）+ 审计哈希链接线（verify_hash_chain 零调用修复）为四大支柱，输出机器可验证的合规证据链。详见 `05-compliance.md` |
|
||
| T6 | **商业增长与 SaaS 规模化** | 缝合现有但分散的半成品（ai_usage 配额引擎 + points 6 表 + EventBus + AnalysisQueue）为三根商业主线——统一计量计费中枢 + 配置化交付蓝图（实施周期 3-5 人天降小时级）+ 主动关怀行为飞轮，在签第 2-5 个客户前确立计量与分层的数据基础，避免陷入「每客户一份定制合同」的项目制泥潭。详见 `06-saas-growth.md` |
|
||
|
||
---
|
||
|
||
## 五、分阶段路线图
|
||
|
||
### Phase 0 — 上线护航（0-2 周，T-0 到 T+2w）
|
||
**目标：消灭 4 个 CRITICAL 定时炸弹，确保上线即不崩。**
|
||
|
||
- [ ] **PP-03 Redis 凭据应急轮换** — 立即改 .env.production 注入新密码 + 重建 Redis 数据 + git filter-repo 清洗历史 + 通知仓库访问者 + 审计 Redis 访问日志（1 人日止血，filter-repo 留待正常窗口）
|
||
- [ ] **PP-01 死信重试接线** — erp-server/tasks.rs 注册 `start_retry_dead_letters` 每小时调度（复用已实现 events.rs:382）+ 补集成测试 + 修正 wiki 误记（2-3 人日，代码已实现 90% 差最后 10% 接线）
|
||
- [ ] **PP-02 分区自愈** — 短期：手动写 m000170 用 generate_series 补建 2026_09~2027_06 分区（2 人日，确定性硬截止解除）；中期：引入 pg_partman 或 start_partition_maintenance 定时任务
|
||
- [ ] **PP-09 工作台死链修复** — 修正 4 个 Dashboard 的 navigate 路径（如 `/health/follow-ups` → `/health/follow-up-tasks`）+ 清理 value={0} 占位 + routeConfig 增加 DEV 期 navigate 目标存在性校验（0.5 人日，影响 100% 角色）
|
||
- [ ] **PP-07 RLS 补 FORCE** — 单个迁移 ALTER TABLE ... FORCE ROW LEVEL SECURITY 遍历所有 tenant_id 表（沿用 m000088 DO 块模板，1 人日，立即堵死 owner-bypass 路径）
|
||
- [ ] **wiki 真相源全量校正** — 至少修正 PP-01/PP-07(RLS FORCE)/长者模式 83%(实非 100%)/Testcontainers(实本地 PG) 四处误记 + cron_heartbeat 进 /health/ready（速赢，2-3 人日）
|
||
|
||
### Phase 1 — 稳固期（1-3 个月，T+1M 到 T+3M）
|
||
**目标：建立可观测性与测试门禁，让生产「可见」、回归「可防」。**
|
||
|
||
- [ ] **PP-04 可观测性三件套** — Alertmanager + 企微/钉钉 webhook 通知路由（先只开 SEV-1 避免狼来了）+ Grafana provisioning（DB/Redis/HTTP/EventBus 4 个 dashboard）+ Loki 日志聚合 + trace_id 贯穿（4-6 人日）
|
||
- [ ] **PP-10 覆盖率门禁** — tarpaulin 接入 CI + service 层 ≥60% 门禁 + erp-health 29 service 补内联单测 + E2E 进 CI + erp-health/tests/ 进 CI（4-6 周）
|
||
- [ ] **PP-06 告警角标修复** — useAlertPolling 改按 pagePath 动态查找 Tab 索引 + 补 elder-mode 11 页缺失 + setTimeout 统一走 useSafeTimeout + BLE 基础设施补单测（5-7 人日）
|
||
- [ ] **PP-08 多租户连接池串扰修复** — 会话变量改 SET LOCAL 事务作用域 或 per-request 连接 + 跨租户并发集成测试（2.5 周，机制层消灭跨租户泄漏窗口）
|
||
- [ ] **PP-05 AI 队列消费者 MVP** — claim_next 参数化 + SKIP LOCKED 加固 + 至少实现健康告警→AI 评估→患者推送 1 条完整链路（先 truncate 历史积压避免 Ollama OOM）
|
||
- [ ] **PP-11 迁移解耦启动路径** — 独立 migrate 子命令（从 main.rs:233 剥离）+ 30 分钟回滚能力 + 破坏性 DDL expand/contract 三步走（8-12 人日）
|
||
|
||
### Phase 2 — 深化期（3-6 个月，T+3M 到 T+6M）
|
||
**目标：从「被动工具」跨越到「主动关怀引擎」，补齐合规通道。**
|
||
|
||
- [ ] **AI 主动关怀闭环** — 5 条 AnalysisQueue 链路全部接消费者（告警/化验/透析/巡护/高风险）+ 每日扫描主动触达患者 + Orchestrator 上下文压缩 + SSE token 精确计量 + 双层长期记忆（11 周，AI 主题举措 1-2）
|
||
- [ ] **PP-12 合规通道** — 患者数据导出 API（个保法 §45）+ 删除/留存策略引擎（病历 15 年 vs 个保法 §47 法律冲突的 anonymize 中间态）+ 患者姓名加密 + name_hash 盲索引 + DEK 轮换闭环（12-15 人日）
|
||
- [ ] **PP-11 CD pipeline** — GitHub Actions build/push/deploy workflow + 蓝绿/灰度发布 + 双副本（+30% 资源成本）+ PG advisory lock 选主（防后台任务多副本重复执行）
|
||
- [ ] **性能索引治理** — pg_trgm 索引在患者/医生姓名模糊搜索落地 + JSONB GIN 覆盖率从 5% 提到关键查询 80% + 慢查询监控 + 物化视图（Dashboard DB CPU 降 50%+）
|
||
- [ ] **多端体验统一** — 设计 Token 单源（DTCG JSON 代码生成）+ 跨端语义组件契约（AlertCard/EmptyState/VitalCard）+ Web i18n 框架（187 处硬编码文案）+ AuthButton 28%→70% + Web Vitals 监控
|
||
|
||
### Phase 3 — 规模化（6-12 个月，T+6M 到 T+12M）
|
||
**目标：多副本 HA + 分布式安全 + SaaS 计量化 + 医疗合规认证就绪。**
|
||
|
||
- [ ] **高可用与分布式安全** — 应用多副本 + PG 主从 + Redis 哨兵/集群 + 满足 99.9% SLA + token 黑名单迁 Redis + DB/Redis 连接 TLS + 会话密钥分布式存储 + 密钥轮换自动化
|
||
- [ ] **统一计量计费中枢（SaaS 主题）** — Metering Hub（每 AI 分析/告警/咨询/上传可计量可计费）+ 配置化交付蓝图（Tenant Blueprint + Onboarding，实施周期降小时级）+ 套餐分层 Feature Gating
|
||
- [ ] **医疗合规认证** — ICD 编码校验 + 药品编码 + 等保三级测评准备 + 个保法合规审计 + 病历留存策略引擎 + 数据分类分级引擎（字段级 ABAC）+ 审计哈希链完整性举证
|
||
- [ ] **AI 能力深化** — ReAct Agent 多轮工具调用稳定化 + Function Calling 双层记忆 + 知识库 V2 + 多模态（化验单图像识别）+ RAG 评估闭环 + Provider FC 集成测试 + 成本真相化
|
||
- [ ] **生态扩展预留** — 白标皮肤（branding_json + 主题注入）+ 开放 API（API Key 吊销/轮换/审计）+ ISV 生态接入基础
|
||
|
||
---
|
||
|
||
## 六、TOP 7 行动建议（给项目负责人）
|
||
|
||
> 可执行、有优先级、有截止时点、有负责人。
|
||
|
||
1. **【今天】启动 Redis 凭据泄露应急响应（PP-03）** — 立即轮换密码 + 改 .env.production 注入 + 重建 Redis 数据 + git filter-repo 清洗历史 + 通知所有仓库访问者 + 审计 Redis 访问日志。这是唯一一个「已在进行中」的合规事件，每拖一天风险递增，属法律层面强制义务。**负责人：安全/DevOps。**
|
||
|
||
2. **【本周】修复 3 个 CRITICAL 定时炸弹（PP-01/PP-02/PP-07）** — 死信重试接线 + 分区补建迁移 + RLS 补 FORCE。这三项均「代码已实现 90%，差最后 10% 接线」，投入小、收益大，且能立即修正 wiki 真相源漂移。**负责人：后端架构。**
|
||
|
||
3. **【本周】冻结统计仪表盘重构分支合并，直到 PP-09 修复** — 当前未提交改动（AdminDashboard/DoctorDashboard/OperatorDashboard/NurseDashboard x4）引入了 6 条死链 navigate + value={0} 占位，合并前必须通过「navigate 目标存在性」DEV 校验。影响 100% 角色首屏，上线即暴露。**负责人：前端。**
|
||
|
||
4. **【本月】做一次 wiki 真相源全量校正 + cron_heartbeat 进就绪门禁** — 至少修正 4 处误记（retry_dead_letters/RLS FORCE/长者模式 100%/Testcontainers），并在 CI 增加 doc-vs-code 一致性校验；cron_heartbeat 接入 /health/ready（>2×周期返回 503 触发 nginx 摘流）是所有后续观测/告警的门禁基线，零依赖 1-2 人日。**负责人：架构。**
|
||
|
||
5. **【Phase 1】把可观测性三件套（PP-04）列为上线后第一优先** — Alertmanager + Grafana + Loki，这是 DevOps 4.2 分的根本短板，也是 PP-01/PP-02/PP-05 这类潜伏故障能在生产盲飞数月的直接原因。先只开 SEV-1 避免告警风暴。**负责人：DevOps。**
|
||
|
||
6. **【Phase 1】建立测试覆盖率门禁（PP-10）** — tarpaulin + service 层 ≥60% 门禁 + E2E 进 CI + erp-health/tests/ 进 CI。历史 24% fix 提交率的根因是回归防护薄弱，没有门禁则 6-12 个月演进速度被测试债务持续拖累，AI Agent/Provider/SSE 链路演进尤其危险。**负责人：测试。**
|
||
|
||
7. **【Phase 0-1】把 PP-05 AI 队列消费者作为「主动关怀引擎」承诺的兑现起点** — claim_next 参数化（消除 format! 拼 tenant_id 的 SQL 注入铁律违反）+ 至少打通 1 条「健康告警→AI 评估→患者推送」完整链路。客户基于「主动关怀」承诺付费，目前 AnalysisQueue 是死存储，这是续约与口碑的核心，也是从「分析工具」到「主动关怀」产品跨越的根因。**负责人：AI。**
|
||
|
||
---
|
||
|
||
## 七、主题章节索引
|
||
|
||
本简报为决策层入口，各主题详细分析（愿景/举措/速赢/风险/工作量估算）见对应章节文件：
|
||
|
||
| 主题 | 文件 | 核心举措数 |
|
||
|------|------|-----------|
|
||
| T1 稳定性与上线护航 | `01-stability.md` | 5 举措 + 3 速赢 + 7 风险 |
|
||
| T2 技术债与架构演进 | `02-architecture.md` | 5 举措 + 4 速赢 + 6 风险 |
|
||
| T3 AI 智能化纵深 | `03-ai-depth.md` | 5 举措 + 4 速赢 + 8 风险 |
|
||
| T4 多端体验统一 | `04-multidevice-ux.md` | 5 举措 + 4 速赢 + 9 风险 |
|
||
| T5 医疗合规与数据治理 | `05-compliance.md` | 4 举措 + 3 速赢 + 8 风险 |
|
||
| T6 商业增长与 SaaS 规模化 | `06-saas-growth.md` | 5 举措 + 3 速赢 + 8 风险 |
|
||
|
||
---
|
||
|
||
## 附录 A：决策张力图谱
|
||
|
||
```
|
||
架构层（8.0）─────────────────────── 可靠性上层
|
||
│
|
||
├── 后端架构 8.0 ← 最扎实（无环依赖 + Outbox + 双层多租户）
|
||
├── 后端业务 7.5 （CAS 并发控制扎实，但 check-then-insert 竞态）
|
||
├── 数据层 7.3 （schema 优秀，但分区无自愈 + RLS 缺 FORCE）
|
||
└── 安全合规 7.3 （PII 加密企业级，但 Redis 凭据已泄露）
|
||
│
|
||
↓ 落差 3.8 分（上层可靠性无底层护栏兜底）
|
||
│
|
||
支撑层（4.2-5.5）─────────────────── 护栏底层
|
||
├── 测试 5.5 ← 回归防护薄弱（PP-01/PP-05 流入根因，24% fix 提交率）
|
||
└── DevOps 4.2 ← 可观测性盲飞（PP-04 是最大运营风险）
|
||
|
||
核心张力：上层的可靠性没有底层的护栏兜底。
|
||
决策方向：Phase 0 拆炸弹 + Phase 1 补护栏 = 让可靠性「可见、可防、可回滚」。
|
||
```
|
||
|
||
## 附录 B：跨维度主题（系统性模式）
|
||
|
||
本次分析识别出 10 个跨维度系统性主题，是「症状」背后的「模式」，需作为演进期间的持续治理对象：
|
||
|
||
1. **文档与代码漂移** — wiki 多处「已修复」与代码不符（PP-01/PP-07/长者模式/Testcontainers），真相源失真是 V1 上线后最隐蔽的系统性风险。
|
||
2. **「半成品自动化」模式** — retry_dead_letters 未接线（PP-01）+ AnalysisQueue 死存储（PP-05）+ ai.dialysis.kdigo_requested 空 no-op + 32 个 FIRE-AND-FORGET 事件无消费者，系统停留在「被动工具」而非「主动关怀引擎」。
|
||
3. **测试金字塔失衡 + 覆盖率工具缺失（PP-10）** — 历史根因，是所有潜伏故障流入仓库的共同成因。
|
||
4. **「有代码无数据」僵尸 UI（PP-09）** — value={0} 占位 + 死链 navigate，医疗后台展示假数据是信任度致命伤。
|
||
5. **多租户隔离多层防御可信度不足（PP-07/PP-08）** — RLS 缺 FORCE + 连接池 SET 串扰，医疗数据跨租户泄漏是合规红线。
|
||
6. **凭据与密钥管理散落** — Redis 密码泄露（PP-03）+ Redis/PG 无 TLS + token 黑名单非分布式 + HS256 对称密钥，阻塞水平扩展。
|
||
7. **可观测性近乎为零（PP-04）** — DevOps 4.2 分核心短板，决定上线后「是睡觉还是救火」。
|
||
8. **生产发布与回滚能力缺失（PP-11）** — 无 CD + 无灰度 + 单副本 + 迁移在启动路径，6-12 个月演进速度核心瓶颈。
|
||
9. **性能索引黑洞** — pg_trgm 装了没用 + JSONB GIN 覆盖率 ~5%，数据膨胀后成性能黑洞。
|
||
10. **硬编码与配置散落** — TabBar 索引（PP-06）+ 分区日期（PP-02）+ value={0}（PP-09），配置未集中治理。
|
||
|
||
---
|
||
|
||
> 本简报基于 9 维度并行分析汇编，所有论断均附证据（文件路径:行号或 grep 结果），已在各主题章节展开。决策层如需深挖单项，直接跳转对应主题章节文件。
|