mjava-ai/openspec/changes/define-customer-tiering/proposal.md

状态（2026-06-10 立项）：提案阶段，未实施 优先级：中。建立客户接入的分档判定，约束未来子模块/独立仓的取舍。

Why

当前 mjava-ai 处于基础建设期，仓内只有 mjava 基座 + mjava-mcli 模板 + mjava-pro（多客户单部署骨架） + mjava-com（BaaS 网关骨架），无实际客户落点。已有先例：

• mjava-pro 立项时的设想：轻客户入驻一行配置即可接入（add-mjava-pro proposal）
• mjava-com 立项时的设想：外部系统通过 REST 调 mjava 能力（add-mjava-com proposal）
• 历史已存在两个复杂客户独立仓：cur/mjava-guangming/（4 模块独立 git 仓）、akds（独立仓）

但「新客户来了，到底走哪条路径」没有显式约定。具体痛点：

1. 客户接入第一步要回答的问题（入 mjava-pro / 新建子模块 / 拉独立仓）没有判定标准 → 容易凭感觉选错，后续返工
2. 三档之间的升级路径（轻→中→复杂）没有约定 → 客户业务长大后没人推动迁移
3. mjava-pro 租户入驻清单不清晰、mjava-com 对外暴露白名单缺规则 → 两个公共项目能用但「怎么用」无据可依
4. 客户独立仓与 mjava-ai 的基座 jar 演进解耦关系无文档 → 上游 R4 跨仓 grep 范围反复被问

R3 已经写了「子项目优先调 mjava」的调用优先级，但没回答「子项目本身归属哪一档」。本 change 补这一层。

What Changes

新增 capability customer-tiering，约束客户接入决策：

1. 三档分档矩阵（A/B/C）：每档的硬指标（触发条件）+ 物理落点 + 部署边界 + 命名约定
   • A 档：入驻 mjava-pro，单部署多租户，宜搭应用表加一行配置
   • B 档：mjava-ai 仓内新建 mjava-{客户} 子模块（复制 mjava-mcli 模板），独立 jar 独立部署
   • C 档：客户独立 git 仓（不在 mjava-ai 仓内），自维护基座 jar 副本
2. 决策流程：新客户接入时按硬指标走判定树，输出选档
3. 升级路径：A→B→C 的触发条件、迁移步骤、回退禁忌
4. mjava-pro 入驻清单细化：宜搭应用表必填字段、隔离边界（DB/缓存/日志）、入驻 SOP（与 add-mjava-pro 的 tenant-registry capability 互补，不重复定义）
5. mjava-com 对外暴露规则细化：哪些 mjava Service 可暴露、白名单审批流程、限流默认值（与 add-mjava-com 的 baas-gateway capability 互补）
6. 客户独立仓与 mjava-ai 解耦边界：C 档客户仓如何 fork 基座、版本号约定、上游回流通道（仅约定，不强制）

Capabilities

New Capabilities

• customer-tiering：客户接入分档判定 + 升级路径 + 各档物理落点约定

Modified Capabilities

Impact

• 新增文档：openspec/changes/define-customer-tiering/specs/customer-tiering/spec.md
• README.md：「子项目速览」表追加一列「档位」（A/B/C），README 「新客户接入」段落改写为按档位分流
• CLAUDE.md：在「快速操作」追加「新客户接入决策树」短链接
• 共享后端规范：后端/CLAUDE.md 加客户分档段（与本仓 spec 互锚）
• 零代码改动：本 change 仅产出规范，不动 Java 源
• 依赖：与 add-mjava-pro / add-mjava-com 互补；本 change 不阻塞，可独立 archive

Non-Goals

• ❌ 不写 mjava-pro 的具体租户注册代码（属 add-mjava-pro 范围）
• ❌ 不写 mjava-com 的具体 action 注册代码（属 add-mjava-com 范围）
• ❌ 不约定客户业务建模（每个客户业务自行设计）
• ❌ 不约定客户前端架构（仅后端 Java 子模块/独立仓的判定）
• ❌ 不强制 C 档客户仓必须回流上游（仅约定通道，是否回流由各客户工程师决定）
• ❌ 不约定客户数据库选型（A 档共享 mjava-pro 的 DB，B/C 各自决定）