> 状态（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
<!-- 不修改已归档 capability；引用 add-mjava-pro/add-mjava-com 进行中的 tenant-registry/baas-gateway，由本 change 补判定层 -->

## 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 各自决定）