Keel roadmap

M0 → M5 多versionpublish节奏。每个version都是可独立publish的——而不是”等所有都好了再上”。

M = Milestone. Mortar/Keel 用 M 编号区分 launch 成熟度；区别于 Fabric 的 V 编号（V = 项目类型 / project type）。

2026.05 第三次修订：appunvs project-type 重排后 WeChat 移到 V4 (Fabric project type)，Keel 不再单独维护 WXML pipeline。Keel 自己的version边界保持在 M0-M5。

2026.05 第二次修订：与 Expo / EAS 5 层对齐——Keel = SDK / CLI / Build / Update / Submit。“Cloud Build” 改 “Build”，“OTA” 改 “Update”。删 “Hosting” 一层（Expo Hosting 是 web 部署，Keel 不做 web target——见 architecture 顶部说明）。Submit 从 M3 子项升格为正式第 5 层。

2026.05 第一次修订：基于跟 Expo 全产品对比 gap analysis 重排（详见本documentation第二部分”Expo gap”）。新增 Keel Go / Dev Client / fileroute（App Router 风格）/ Open Governance。Mortar 解耦为 optional plugin（不再默认 bundle）。

M0 historical 内容merge到 M1 § Historical context；产品对外编号从 M1 起.

M1（公开 launch — ~3 个月）—— Keel 第一次”对外可用”

Historical context — internal dogfood 阶段（pre-M1，2025-2026.05）

Keel 作为 appunvs internal技术栈跑通：

• ✅ Native SDK（Keel.xcframework + keel-sdk.aar）
• ✅ per-instance Hermes（per-KeelView）—— internal技术，不在 marketing 表面
• ✅ New Architecture（Fabric / TurboModules / Bridgeless）默认开启 —— 跟随 RN 0.85.2，不退回 Old Architecture
• ✅ internal Build pipeline（Docker + Metro + Hermes byte-compile）—— 给 appunvs 的 AI bundle 用

Pre-M1 不对外publish。Keel 还没正式品牌化，没 npm 包，没 CLI，没paiduser。

M1 — first public release

目标：让一个非 appunvs user能装 npm 包、CLI 跑起来、build / update 推一个 bundle 出去。

M1 code完成度：~95%。剩下的全是 operational（业务运营）项 —— Aliyun OSS / CDN 部署、App Store 上架、Discussions 频道创建、Project tracker configuration、Free + Pro 内测开放、repo public 化。

1. CLI + 工程基础

• CLI MVP（@keel-ai/cli）：12 命令落地（build / create / dev-client / doctor / install / login / logout / manifest / publish / rollback / start / submit），共 1494 行 TS 在 keel/cli/src/commands/
• keel doctor：检查 Node / Java / Xcode / iOS SDK / Android SDK version兼容性 —— cli/src/commands/doctor.ts (183 行)
• keel install：RN-aware npm install（version兼容性自动校验）—— cli/src/commands/install.ts (189 行)
• 5 个 templates —— keel/cli/templates/{blank,im,map,tabs,wechat-pay}/ 全部落地
• create-keel-project / create-keel-module —— 照 Expo 模式独立 scaffolding 包（packages/create-keel-project/ + packages/create-keel-module/）。user走 npm create keel-project <name> / npm create keel-module <name>；CLI @keel-ai/cli 不掺和 scaffolding，专做 daily development（start / build / publish / submit / …）。templates 复制自 cli/templates/ + modules-core/templates/，release时 npm publish 两个独立包
• @keel-ai/keel umbrella 主库 —— sdk/，对位 Expo 的 expo 包；KeelSDK.isAvailable() + version常量 + native module handshake。consumer 用 import { KeelSDK } from '@keel-ai/keel'

2. Build 对外

• 把internal Docker pipeline 包装成公开 HTTP API + 鉴权 + 计费 hook —— keel/cloud/cmd/build-server/main.go wires keelauth.Middleware + billing；handler.go (421 行) 实装
• CLI 支持 push tarball → 拉 ipa / apk —— keel/cli/src/commands/build.ts (165 行) + keel/cli/src/api/cloudbuild.ts

3. Update service（self-operated，跟 Mortar 解耦）

• manifest endpoint（PG / SQLite 自管）
• Client SDK：TS / iOS Swift / Android Kotlin 三端，状态机 + bsdiff4 patch + sha256 校验
• keel rollback CLI 命令（keel update 不单独存在——publish + rollout 覆盖）
• 灰度 (10%/50%/100%) via rollout.go
• 一键rollback via keel rollback CLI
• S3-compatible BlobStore 实装 —— keel/cloud/internal/update/s3_blob_store.go 兼容Aliyun OSS / Tencent Cloud COS / Cloudflare R2 / MinIO（同一份code切 endpoint）
• Production 部署：Aliyun OSS bucket + CDN 域名 + HTTPS cert + 监控 / 告警接 Sentry —— operational

4. fileroute（App Router 风格）

• @keel-ai/router：file-based routing，App Router 约定 —— keel/packages/router/ 落地
• 自动生成 TypeScript route类型 —— keel/packages/router-metro-plugin/ 配套，build-time 遍历 app/
• 底层基于 react-navigation（兼容现有 RN 生态），上层 wrap 成 file-based

选 App Router 而不是 Pages Router 的理由：Next.js 现在主推 App Router，社区心智已切；layouts / route groups / parallel routes 这些表达力对 mobile app 同样有价值（特别是 tab navigator + nested stack 的常见组合）。

5. documentation站

• documentation站 scaffold —— keel/site/ 基于 Astro 4，5 pages（index / features / docs / pricing / signup）
• 内容齐全：getting started (tutorial) / 5 层架构 (architecture) / 5 China module (modules) / Update (update) / Build (build) / Submit (submit) / CLI 参考 (../cli/README) / examples gallery (examples) / RFC 流程（CONTRIBUTING.md § RFC）—— docs.astro hub 全部链接
• 中文为主，关键 API 双语 —— 当前 18 篇 docs/* 均双语

6. Keel Go（tester app）

• iOS Keel Go app code —— keel/go/ios/（Podfile + project.yml + KeelGo target）
• Android Keel Go app code —— keel/go/android/（Gradle setup）
• 扫码 / 粘 URL 加载任意 Keel bundle —— go/src/{HomeScreen,ScannerOverlay,PreviewScreen}.tsx 共 412 行
• binary 链接 Keel Go 自己 package.json 里声明的 Keel module；超出范围的需要 Dev Client
• 上 Apple App Store + domestic / mainland China 5 大 Android market —— operational（developer账号 + review流程，每家market 2-6 周）

7. 5 个domestic / mainland China一等module的 spec doc

• modules — WeChat / Alipay / Amap / push（Jiguang + Getui抽象）/ 友盟（已写）

8. 定价 v0

• pricing：Free / Pro ¥48 / Team ¥298 / Enterprise（已写）
• Free + Pro 内测开放 —— operational（业务运营，需打通支付通道 + 内测白名单）

9. Open Governance

• Apache 2.0 LICENSE 落地（../LICENSE）
• GitHub repository公开（保留 monorepo liamxujia/appunvs，加 keel label / 子directorydocumentation）—— operational（GitHub UI 设置 repo visibility）
• 公开 RFC 流程 —— .github/DISCUSSION_TEMPLATE/keel-rfc.yml（Discussions 模板）+ .github/ISSUE_TEMPLATE/{keel-bug,keel-feature,config}.{md,yml} + .github/PULL_REQUEST_TEMPLATE；Discussions 频道创建本身 = operational
• 公开 roadmap —— roadmap 本file；GitHub Project tracker configuration = operational
• CONTRIBUTING.md + Code of Conduct —— ../CONTRIBUTING + ../CODE_OF_CONDUCT（Contributor Covenant 2.1，中文）
• governance（已写）

10. Mortar 解耦 — DONE

• 确认 Keel 不出 @keel-ai/mortar plugin——user接 Mortar 走标准 @mortar/client SDK
• documentation强调”Keel works with any backend; Mortar is recommended default but not required”

M2（~3 个月）—— Production hardening + 社区生态准备

M2 是 M1 上架后的”打磨期”——之前被 M1 范围排除的”够用但还能更好”的项，全部落这里。每项独立可publish。

M2 code完成度：~85%。剩余主要在 Dev Client V1.5（卡 macOS 工具链）和首次 release 的 macOS 操作。

1. @keel-ai/router metro 插件（build-time route生成）

• metro plugin 在 bundle 时遍历 app/ 树 —— packages/router-metro-plugin/src/index.ts (286 行)
• 输出虚拟module @keel-ai/router/__routes__.js + __routes__.d.ts
• 类型化 router.push('/posts/:id') —— 编译期捕获 path mismatch

2. @keel-ai/modules-core CLI 扩展

• keel-module install —— in-place 改 host app 的 Podfile / settings.gradle，fenced begin/end 注释包围注入块，重跑替换不重复 —— modules-core/src/cli.ts:188-289
• keel-module test —— npm test 或 jest fallback —— cli.ts:290-339
• keel-module publish —— 验证 module.yml + 可选 --bump=<patch|minor|major>（package.json + module.yml 同步推进version）+ npm whoami 检查 + npm publish —— cli.ts:344-

3. Keel Dev Client service端实装

• build-server kind=dev_client 配方interface —— cloud/internal/cloudbuild/devclient.go V1 scaffold（DevClientInput / DevClientBuilder / DescribeDevClient）
• 项目自定义 native modules 检测 + autolink 注入 —— modules-core/src/autolink.ts 落地，CLI keel-module link + keel-module install 输出 Podfile / Gradle 片段
• V1.5：DockerBuilder 实现 WrapDevClient，跑真 xcodebuild archive (iOS) + gradle assembleRelease (Android) + 签名 + TestFlight 上传辅助 —— 卡 macOS + Android SDK 工具链 access

4. OTA 监控 + Open API

• Open monitoring API —— cloud/internal/update/monitoring.go，3 个无 auth endpoint：
  • GET /v1/monitoring/health —— liveness + readiness JSON（subsystem 探测）
  • GET /v1/monitoring/metrics —— Prometheus exposition format（uptime / request counters / bundle counts）
  • GET /v1/monitoring/diagnostics —— 详细 JSON 快照（含 bundle staleness + TLS cert 到期）
• bundle 过期监控 —— StatsProvider.BundlesOlderThan 由 MemStore + SQLiteStore 实装；阈值 KEEL_UPDATE_MONITOR_STALE（默认 30d）；count 经 /metrics + /diagnostics 出口
• CDN 健康检查 —— /v1/monitoring/health 同时探测 manifest store + blob store；external cron 每分钟 poll 这个 endpoint 即可
• TLS cert 过期监控 —— KEEL_UPDATE_MONITOR_CERTS=host1,host2,... configuration后由 /v1/monitoring/diagnostics 报告每个 cert 的 not_after + days_remaining + status（ok / expiring_soon / expired）
• 可被任意监控系统接入（取代了之前的 “AI 监控员” 设计）—— Prometheus / Datadog / Grafana Agent / self-hosted cron / 第三方 AI monitor 都能 poll 这 3 个 endpoint；Keel 自身不dependency任何特定监控产品

5. 3 个 reference community modules

• keel-module-wechat（WeChat SDK 包装）—— 93 TS + 61 Swift + Android Kotlin + module.yml
• keel-module-alipay（Alipay SDK 包装）—— 67 TS + 57 Swift + Android Kotlin + module.yml
• keel-module-amap（Amap SDK 包装）—— 91 TS + 54 Swift + Android Kotlin + module.yml
• bonus：keel-module-umeng（友盟 SDK）—— 同样 4 件套完整结构

3 个 reference module同时验证了 @keel-ai/modules-core 的 autolink + install + publish 流程。

6. iOS Keel.xcframework 公开分发（SPM 默认 + CocoaPods 兼容）

• keel/Package.swift —— SPM manifest 落地，本地development模式 binaryTarget(path:) 直指 build 产物；release 模式的 binaryTarget(url:checksum:) 块在同file内注释，首次release时翻开
• keel/packaging/build-ios.sh —— 追加 step 6 输出 Keel.xcframework.zip + Keel.xcframework.zip.sha256，本地手工上传 GitHub Release
• keel/packaging/release.sh —— 一键收集 release 物料：跑 build-ios.sh + 打印 Package.swift / Keel.podspec / gh release / git tag / pod trunk push 全套 copy-pasteable 片段，全本地、零 CI、零file改写
• keel/Keel.podspec —— 兼容渠道 podspec 模板，binary :http 指向 GitHub Release zip，:sha256 占位待 release.sh 填入
• keel/docs/enterprise-distribution —— 3 种private渠道方案：private GitHub repo（推荐）/ 自托管 CDN / private Swift Package Registry；附 CocoaPods private spec repo 兼容做法
• Dogfood：repository内一个 downstream host shell 的 iOS 工程从直接 framework: 引用切到 package: Keel（path-based SPM），验证消费方真实走 Apache 2.0 公版 manifest path
• 首次 release：在 macOS 跑 bash keel/packaging/release.sh 0.1.0 → 按打印出来的 5 步走完（GitHub Release 上传 / 改 Package.swift / 改 Keel.podspec / git tag / pod trunk push）

M3（中期，~6 个月）—— 商业化 + 社区生态成熟

M3 code完成度：~85%。SDK / service端骨架全部落地；剩”V1 scaffold → 真实集成”的硬转化（push provider 实拨 / submit 上传 / 支付通道走签）需要customer驱动 + 真实凭据，以及若干运营动作（repo 拆分、商业付款打通、社区entry）。

1. Modules API（社区贡献module框架）

• @keel-ai/modules-core —— Expo Modules API 等价：autolink + 6 命令 CLI（create / validate / link / install / test / publish）+ swift-kotlin template（M2 同步落地，详见 M2 #2）
• documentation（modules-core/README）+ template 示例 + keel-module create 自动生成 iOS/Android stubs
• 4 个 reference module作为社区模板：keel-module-{wechat,alipay,amap,umeng} —— 详见 M2 #5

2. Keel Dev Client（项目自带 native module的 tester）

• keel dev-client CLI 命令（V1 scaffold）—— cli/src/commands/dev-client.ts
• service端 kind=dev_client 配方interface —— cloud/internal/cloudbuild/devclient.go 的 DevClientInput / DevClientBuilder / DescribeDevClient
• 项目自定义 native modules 检测 + autolink 注入 —— modules-core/src/autolink.ts + keel-module link/install
• V1.5：DockerBuilder 实拨 xcodebuild archive (iOS) + gradle assembleRelease (Android) + 签名 + TestFlight 上传辅助 —— 卡 macOS + Android SDK access

3. 5 China module全实装

按 modules 顺序：

• @keel-ai/push 抽象层（设备 SDK 183 行 TS @ packages/push/src/index.ts —— register / send / unregister，对应 push-server 的 /v1/{project}/push/{register,send}）
• WeChat（支付 + login + 分享 + navigate to小程序）—— keel-module-wechat（93 TS + 61 Swift + Android Kotlin）+ service端验签 cloud/internal/billing/payment/wechatpay.go (376 行)
• Alipay（支付 + login）—— keel-module-alipay（67 TS + 57 Swift + Android Kotlin）+ service端 cloud/internal/billing/payment/alipay.go (289 行)
• Amap —— keel-module-amap（91 TS + 54 Swift + Android Kotlin）
• 友盟（统计 + push）—— keel-module-umeng（README + module.yml + iOS + Android + src）
• push-server JPush + Getui dispatcher 双 backend —— cloud/cmd/push-server/main.go (298 行) provider interface 落地，V1 stub 接 stdout + return success，真实 HTTP 拨号待租户接入时实拨

4. Keel Push service端（self-operated，跟 Mortar 解耦）

• Keel 后端 push dispatcher —— cloud/cmd/push-server/，/v1/{project}/push/send HTTP entry完整
• 多 provider route：Jiguang + Getui provider interface 落地，按 device_id → provider 映射 dispatch
• push log + audit endpoint surface 已加，落地待 SQLite / OSS 接入决策
• 跟 Mortar 完全解耦：push-server 是独立 Go binary，不dependency任何 Mortar interface（同 M2 #4 monitoring 一致）

5. KAS Submit（层 5 实装）

• keel submit ios --to=appstore —— CLI cli/src/commands/submit.ts (162 行)
• keel submit android --to=<market> —— 同上
• 7 家market driver Go 实装：
  • appstore (378 行)、googleplay (413 行)、huawei (336 行)、xiaomi (233 行)、oppo (156 行)、vivo (162 行)、yyb (224 行)
• path全覆盖：CLI → build-server → submit driver；每家 driver 实拨该market API 的authentication / 上传 / submit for review流程（OPPO / vivo 是 stub，其余 5 家有真实 API 调用）

6. OAuth 流程辅助

• @keel-ai/auth-session（OAuth 2.0 PKCE flow helper）—— packages/auth-session/src/index.ts (308 行)
• @keel-ai/apple-signin（Apple Sign-In 包装）—— packages/apple-signin/ 117 TS + iOS native
• bonus：@keel-ai/google-signin（Google Sign-In 包装，roadmap 没列）—— 147 TS + iOS + Android native

7. Examples gallery

• 5 个示例项目 at keel/apps/examples/0[1-5]-*/：
  • 01-todo-list —— App Router _layout.tsx + index.tsx，104 行 RN code
  • 02-chat-im / 03-ecommerce / 04-wechat-pay-flow / 05-amap-nearby —— 同结构
• 用 @keel-ai/router App Router 约定演示 file-based routing
• 运营：拆 appunvs/keel-examples 独立 repo（roadmap 原始计划），目前合在 keel/apps/examples/ 下作为 npm workspace

8. 教程 / Tutorial

• tutorial 926 行完整课程：从零起项目 → App Store + Google Play + Huawei AppGallery 上架 + OTA 推update

9. 商业付款（code → 运营两段）

• WeChat Payservice端验签 —— cloud/internal/billing/payment/wechatpay.go (376 行)
• Alipayservice端验签 —— cloud/internal/billing/payment/alipay.go (289 行)
• subscription / 套餐模型 —— plan.go (139 行) + subscription.go (207 行) + payment.go (144 行) 抽象层
• 运营：WeChat开放平台 + Alipaymerchant ID实际申请 + 通道走签
• 运营：对公开票流程（财务侧）
• 运营：Free → Pro 转化触发埋点（产品决策 + 埋点落地）

10. 社区entry（全部 operational，无code）

• Feishu群 / 知乎专栏 / 公众号register + 运营
• GitHub Discussions 频道全开（dependency M1 #9 repo 公开）
• monthly RFC 议程节奏建立

M4（~12 个月）—— Tooling + 生态完整化

M4 的主线是工具链 + 生态完整化——M1-M3 把”能用 / 好用 / 商业化”打通后，M4 是把developer日常用得到的周边工具一次补齐。enterprise SLA 已挪到 M5（跟 appunvs / Mortar 共享的 enterprise pack 一起做，见下）。

M4 code完成度：100%（6 个主项全部落地）。

• VS Code 扩展 —— packages/vscode-keel/：extension.ts + cli-runner.ts + modules-provider.ts + routes-provider.ts + keel.json / module.yml JSON schema；语法高亮 / 智能补全 / build status
• Bundle Atlas —— packages/bundle-atlas/src/index.ts 301 行 + bin（bundle internal可视化，对位 Expo Atlas）
• Claude Code skill —— packages/skill/：keel-skill 175 行 + bin 安装脚本（教 Cursor / Claude Code 写 Keel-shaped code）
• GitHub Actions templates —— templates/github-actions/keel-{cert-healthcheck,ota-publish,pr-check,submit-stores}.yml 四份 CI 模板
• Keel Snack — 浏览器 playground（含 RN Web fallback） —— snack/ Next.js + Monaco + phone-mock iframe；public/playground.html 用 importmap 把 react-native 解析到 esm.sh 的 react-native-web，浏览器内 @babel/standalone 转 TS+JSX，base64 source 走 URL hash 传给 iframe，0 service端 round-trip。真机预览继续走 Keel Go；Full mobile simulator (云端 GPU emulator) 等 enterprise customer驱动
• 多语言documentation（i18n） —— keel/site/ 默认 zh，/en/ image所有 5 个页面：index / features / pricing / docs / signup。Astro 4 i18n config + Base.astro 加 locale prop + 语言切换链接 + hreflang SEO 标签。10 页 build 通过

enterprise SLA package 不在 M4——已挪到 M5 跟 appunvs / Mortar 共享 enterprise pack 一起做。

Keel Snack 的 RN Web fallback 已在 M1 直接实装（跳过了 fixture-stub 中间阶段）。Full mobile simulator (云端 GPU emulator + WebRTC stream) 等 enterprise customer驱动。

M5（enterprise版）—— 跨产品共享 enterprise pack

⚠️ M5 不是 cross-product。AppUnvs / Mortar / Keel 共享的是 enterprise 策略（统一的 SLA / 等保 / 合规口径），不是同一份code。Keel 自己的 enterprise feature 直接在 keel/ 内实装。

M5 code完成度（keel/ 范围）：~75%。SSO / RBAC / 审计 / Helm 全部 keel/cloud/ 内落地；剩 SLA / 培训 / ISO27001 / SOC2 是合同 / 流程 / 第三方审计（非code）。

1. 单一 SSO 网关（keel 自身）

• OIDC config + handler scaffold —— keel/cloud/internal/keelauth/oidc.go：OIDCConfig / OIDCHandler / /auth/oidc/{login,callback} route + state token HMAC + 会话 JWT 签发 + VerifySession
• StubOIDCProvider 让流程在无真实 IdP 时也能跑通；production时换 github.com/coreos/go-oidc/v3 实拨
• 支持 Okta / Azure AD / Auth0 / Keycloak 任意 OIDC provider —— configuration issuer URL 即可
• Feishu / DingTalk OIDC：protocol层完全兼容，configuration中文 SAAS issuer 即可

2. 统一 RBAC（keel 自身）

• Role 常量定义 —— keel/cloud/internal/keelauth/rbac.go：keel.module.publisher / keel.update.deployer / keel.build.viewer / keel.update.viewer / keel.admin / keel.org.admin
• Principal 抽象统一 API key + OIDC 两条 auth 通路
• PrincipalRoles interface + StaticRoleStore memory实装（含 Group → Role 映射，对接 OIDC group claim）
• RequireRole(store, roles...) gin middleware：401 / 403 区分；多 role OR 语义；RoleOrgAdmin 任意通过

3. private deployment（Helm chart）

• keel/cloud/deploy/helm/keel/ 完整 chart：
  • Chart.yaml + values.yaml（含 ingress / persistence / SSO toggles / 各 provider secrets）
  • 3 个 Deployment + Service template：update-server / build-server / push-server
  • PersistentVolumeClaim for update-server SQLite + bundle blob
  • Secret 模板（OIDC client / push provider creds / API keys 一站式注入）
  • Ingress 模板（统一frontend /v1/* → update / /build/* → build / /push/* → push / /auth/* → SSO）
  • NOTES.txt 部署后提示
  • liveness + readiness probe 指 /v1/monitoring/health
• 兼容多 k8s 后端：vanilla / k3s / Aliyun ACK / Tencent Cloud TKE / Huawei云 CCE（无 cloud-specific dependency）

4. 审计日志统一

• 结构化 audit event —— keel/cloud/internal/keelauth/audit.go：AuditEvent 固定 schema（timestamp / request_id / actor.{subject,source,project,groups} / action / resource / result.{status,error} / latency_ms）
• 3 种 sink 落地：StdoutAuditSink（默认）/ FileAuditSink（jsonl appended）/ SinkFunc（适配 Splunk HEC / Aliyun SLS / Elastic）
• AuditMiddleware 自动跟 OIDC + API key 两条 auth path联动；默认只审 mutating request（POST/PUT/DELETE/PATCH），加 AuditReads 选项为 GET 也审（等保 2.0 完整性需要）
• X-Request-ID 自动注入 + 回显，可对接external追踪

5. private Sentry + 监控

• 已在 M2 #4 完成 —— Open monitoring API（/v1/monitoring/{health,metrics,diagnostics}）任意 Sentry / private监控系统都能 poll
• Sentry private实例对接 = customer自己起 Sentry on-prem + 配 SENTRY_DSN env var，零额外code

6. SLA 合同 + 培训 + 国际化合规（合同 / 流程 / 第三方审计）

• 单一 SLA 合同（99.9% / 99.95% / 99.99% tier）—— 法务 + 商务
• customersucceeded经理 (CSM) + monthly技术 review —— 运营 + 招聘
• 等保 2.0 三级 —— 公安部ICP filing + 第三方测评，需 3-6 个月 + 全套合规材料
• ISO 27001 —— Bureau Veritas / SGS / DNV 任意一家审计，9-12 个月
• SOC2 Type 2 —— 6-12 个月观察窗口，AICPA-affiliated 审计师

跟托管版 hosted SaaS 的关系：hosted SaaS 是给中小customer的现成多租户；M5 enterprise pack 是给大customer的”自己部署 + 自己 SSO + 自己 SLA”version。同一份code，不同部署 + 不同合同形态。

等保 2.0 三级是中国 ToB 真刚需 —— 跨过它才能卖给金融 / 政务 / 大型国企customer。SOC2 / ISO 27001 是给国际customer准备的，先做等保再说。

不这样做的话：一个 Fortune 500 customer得登 3 套backend、装 3 个 Helm chart、签 3 份 SLA 合同——价格 + 部署摩擦都拉满，单子掉一半。

1. 单一 SSO 网关

• SAML 2.0 / OIDC IdP 集成（Okta / Azure AD / Feishu / DingTalk）
• 单一 session 跨 appunvs.editor / mortar.center / keel.update-server
• 跨产品 SCIM user provisioning（IdP 改一次，三产品同步）

2. 统一 RBAC

• Role schema 横跨三产品（appunvs.editor.member / mortar.project.owner / keel.module.publisher / …）
• Permission policy 在 IdP 设置一次，三产品都应用
• 审计 trail 包含所有跨产品操作

3. private deployment（一份 Helm chart）

• Helm chart 部署全套（update-server + build-server）
• 一份 docker-compose-enterprise.yml（小规模 ToB / PoC）
• image走customer自己的 registry，无外网dependency
• 等保 2.0 三级authentication（中国信息安全等级保护 —— 金融 / 医疗 / 政务 / 国企采购强制要求）

4. 审计日志统一

• 三产品 emit 到同一个 audit-log schema
• 单一 query 视图（“过去 30 天 user X 在所有产品里干了什么”）
• 接 SIEM（Splunk / Aliyun SLS / Elastic）

5. private Sentry + 监控

• private Sentry 实例 per customer（data不混跑）
• 接 AI 监控员（见 mortar/docs/monitoring-ai-employee）
• monthly incident 报告自动化生成

6. SLA 合同

• 单一 SLA 合同覆盖三产品（uptime / response time / RPO / RTO）
• 99.9% uptime 默认；99.95% / 99.99% 加价 tier
• monthly credit-back 机制（违约自动退款）
• 24h P1 response工单 / 4h P0（Pro 档 best-effort，enterprise档真合同）

7. 培训 + 专属支持

• customersucceeded经理 (CSM)
• monthly技术 review
• 24/7 关键 incident 支持

国际化合规（M5+，跟overseasmarket启动同步）：

• ISO 27001 国际信息安全management体系authentication
• SOC2 Type 2 美国enterprisemarket procurement 越来越多强制要求

跟托管版 hosted SaaS 的关系：hosted SaaS 是给中小customer的现成多租户；M5 enterprise pack 是给大customer的”自己部署 + 自己 SSO + 自己 SLA”version。同一份code，不同部署 + 不同合同形态。

等保 2.0 三级是中国 ToB 真刚需 —— 跨过它才能卖给金融 / 政务 / 大型国企customer。SOC2 / ISO 27001 是给国际customer准备的，先做等保再说。

远期（post-M5）

• Visual editor 探索（跟 Fabric形态共享一些 UI component）
• WebAssembly target / Skia 渲染 探索

Keel M6 原先规划的 WeChat Mini Program project type 已移出 Keel 范围 —— WeChat MP 的 WXML pipeline 跟 RN 完全不同，由消费方自行维护。

Expo gap 详细对照（2026.05 评估）

跟 Expo 全产品对比，硬性差距 / 战术差距 / 战略不竞争 / 长尾分布：

硬性差距（M1 / M3 必补）

战术差距（M3-M4 内补）

战略不竞争（intentional 差异）

长尾（M5+ 再说）

• 全球 multi-region 架构
• App Store Connect API 全套自动化
• enterprise级 audit log
• WebAssembly target

风险跟踪

跟 appunvs / Mortar roadmap 协同

• M1 期间：appunvs 把 Keel SDK 的versiondependency明确（不再藏在 keel/ internal用法）；CI 跨产品验证；appunvs 升级到使用标准 @mortar/client SDK（跟externaluser一样）
• M3 期间：Mortar 加 payment primitive，Keel @keel-ai/wechat 复用 Mortar 那一层做service端验签；同时 Keel 不强制user接 Mortar payment，自行接也支持
• M4 期间：appunvs publish的 project 通过 Keel CLI 进 OTA 流水线（不只是 Preview tab internal预览）