路线图用于排序投资，不构成发布日期或兼容性承诺。判断一项能力是否可交付，要同时查看源码、自动化测试、运维手册和 Commercial GA 证据。

当前已形成闭环

模块化单体、Contracts 边界、Source Generator 与架构测试；
SqlSugar 主适配器、EF Core parity、Dapper 查询和统一持久化元数据；
认证、统一授权、多租户、审计、风控、幂等、限流和可观测性；
CAP/RabbitMQ、FusionCache/Redis、对象存储和后台任务；
平台工作流、通知、文件、Webhook、Catalog、PlatformBilling、Tickets、Chat、Search、Reporting 等能力；
模板、代码生成、Seed 导出、Workflow Migrator；
Consumer Contract 与商业 GA 门禁。

“已形成闭环”表示代码和主要门禁存在，不表示每个客户拓扑都完成容量与故障演练。

需要按部署补齐证据

领域	交付前证据
多副本	Redis Data Protection 密钥环、SignalR backplane、滚动发布交叉验证
数据恢复	数据库、对象存储、配置和密钥环恢复演练
消息	积压、重投、死信、Broker 故障和消费者幂等演练
工作流	定时器恢复、并发完成、版本回滚和在途实例迁移
安全	真实域名 CORS/CSP、Secret/KMS、MFA、代理会话与告警
商业交付	正式 Feed、签名、SBOM、provenance 和外部 Consumer 同源

后续投资方向

平台支撑模块深化：为 Gdpr、MasterData、AIManage、DocumentStructure、行业与法务扩展补充端到端用例和独立运行手册。
部署产品化：在实际采用后交付受支持的 Kubernetes/AWS Terraform 模块、升级矩阵和灾难恢复自动化。
实时通道扩展：通用 Notification Hub、SSE 或托管 SignalR 需要独立契约与多副本验证；当前只把 Chat SignalR 视为已交付事实。
业务域迁移：Cases、业务 Billing 等应进入 src/Modules，不能与 PlatformBilling 或 Licensing 混名。
兼容性治理：稳定公开包面、数据库迁移和模板 Profile，形成可执行的弃用窗口。

进入 GA 的判断

单元或集成测试全绿不是 GA。正式候选必须使用同一提交生成包、模板、SBOM 和 provenance，在隔离环境完成外部 Consumer，再由负责人签署风险与回滚结论。具体步骤见Commercial GA 门禁。

状态词典

状态	含义	退出条件
已实现	主路径代码存在	关键失败与边界测试通过
已验证	自动证据可复现	目标拓扑演练通过
可交付	文档、运维、安全证据齐全	Commercial GA 决策
规划中	问题与方向已记录	owner、验收和切片明确
暂不投入	当前收益不足	新证据触发重评

接口存在、Null 可注入或本机可运行，都不等于已验证。每个条目必须说明它要改变的可观察结果。

当前功能补全清单

Files：恶意内容扫描、上传会话过期、重复 finalize 幂等、对象元数据缺失时的服务端哈希信任；
Quota：缺省策略接线、硬配额并发、持久化 UsageId 唯一性和预留/结算；
Notifications：逐渠道 Attempt/Receipt、可恢复重试、稳定幂等键和运维重放；
Identity/Security：Delegation Provider parity、密钥轮换和多副本故障演练；
Outbound HTTP/Webhooks：超时、重试、熔断、签名、重放与死信证据；
Database Operations：备份恢复、迁移回滚、Provider parity 与长任务手册；
Realtime：Chat 之外的通知 Hub/SSE 需要独立契约和多副本证据。

详细 owner、验收标准和切片进入 Architecture Hub。本页只提供跨主题优先级，不复制执行 backlog。

优先级模型

优先处理数据泄漏、资损、不可恢复损坏、跨租户越权或虚假 GA 承诺。其次是阻塞采用的业务闭环，再其次是效率与体验。

priority = severity × exposure × probability
         + delivery-blocking value
         + evidence-gap penalty
         - implementation confidence

分数组织讨论，不替代架构判断。低概率但不可逆的租户泄漏仍可成为最高优先级。

路线图条目模板

### Files finalize hardening
Outcome: untrusted uploads cannot become available silently
Current gap: no malware scan or session-expiry enforcement
Acceptance: provider parity + replay/idempotency + ops runbook
Owner: Files / Security
Evidence: tests, threat model, recovery drill, consumer scenario

条目还要写明非目标、依赖、兼容性、数据迁移、指标、失败策略和回滚。没有 owner 或验收证据的愿望不进入近期计划。

交付切片

按端到端 tracer bullet 切分：公开契约、应用用例、真实适配器、失败语义、测试、观测和文档在同一切片闭环。不要先建完所有接口，把实现与运维留到后续。

每个切片回答：客户获得什么；失败如何表现；如何证明租户安全；怎样关闭或回滚；哪些 Provider 已验证。

版本规划核查

路线图不承诺日期。版本候选只吸收达到验收标准的切片；未完成项继续留在知识库，不能降低门禁后进入更新日志。

# 发布规划前检查缺口与门禁。
npm run verify:docs-depth
dotnet test tests/BitzOrcas.Framework.ConsumerContract.Tests --configuration Release
git status --short

# 核查规划是否已变成发布事实。
git diff --name-status vPREVIOUS..HEAD
rg -n "planned|待交付|not yet" src/content/docs
rg -n "SKIP|FAIL" artifacts/ga artifacts/consumer

移出与复盘

源码、测试、手册和运维证据同步完成后，能力才从规划移到更新日志。取消时记录原因与替代；风险由其他控制消除时保留决策依据。

每次 GA 后复查延期项、误判、手工证据和客户反馈，把重复出现的不确定性转为自动门禁。路线图质量体现在减少未知风险，不是条目数量。

审查清单

是否描述结果而非方案口号？
缺口是否可由源码或运行证据复现？
owner、依赖、非目标与验收是否明确？
是否覆盖安全、兼容性、迁移、观测和回滚？
是否与知识库、模块手册和更新日志保持边界？
是否避免日期承诺与“接口即完成”的推断？