功能包(租户功能授权)前端转向 B 端独立小程序

义父定调(2026-10-26):功能包前端全面转向小齐开发的 B 端独立小程序。
本文是这条定调的落地口径,写清「谁是真源、谁冻结、还欠什么」,避免两套前端继续平行生长。

一、先对齐概念:功能包 ≠ 商品套餐

名词英文存储面向
功能包Tenant Feature Entitlementtenant_feature_entitlements商户(租户)能用什么功能
商品套餐Packagepackages 表客人买什么(7081/7082…)

二者命名/存储/接口三隔离,历史上混过一次,不要再混。


二、现状盘点(2026-10-26 实测)

控制面(授权主体,唯一)

数据面(消费侧)——当前两套并存,这是要解决的问题

前端位置entitlement 实现生产状态
B 端独立小程序(小齐)miniprogram-staff/utils/packs.ts ✅ 完整(base/hotel/spa,菜单显隐 + 路由准入 + 本地恢复防闪)小程序端,2026-10-24 已全仓移交小齐
B 端网页版 H5b-workbench/utils/business-pack.ts ✅ 也有(拉 features 覆盖模块状态 + 持久化)在线:https://b.kailashi.cn(nginx bworkbench.conf)

三、定调后的口径

  1. 消费侧唯一真源 = miniprogram-staff(B 端独立小程序)。

新增/变更功能包的前端能力,一律在小程序侧做。

  1. b-workbench 冻结:不再新增功能包页面与能力;只允许修线上缺陷。

是否降级为「只读归档」或「下线 b.kailashi.cn」→ 待义父拍板(见第五节)。

  1. A 端控制面不变:开通/收回仍在 A 端,不迁到小程序。

(授权主体唯一是这套设计的地基,迁走会让"谁能给商户开功能"失去唯一答案。)

  1. 契约不变:消费侧只读 feature_keys,不做自助开通/申请 UI。

四、还欠的对齐(给小齐)

  1. feature_key 是高成本变更:启用前必须先与 A 端 entitlements 后台对齐加键

(miniprogram-staff/miniprogram/utils/packs.ts 头部 v1.5 红线已写)。

新增包键请提前打招呼,别先写代码再补键。

  1. hotel 包目前是双方并集临时态:小齐全功能批(任务/房态板/订单/开单/收银)

+ 波波第 3 批手机两页(今日房态 room-today、轻量 bookings)。

bookings 与 board/room-today 功能重叠 —— 收敛方案待小齐×波波对齐后由义父拍板。

  1. 后端 _staff(roles=) 是最终闸门;前端菜单显隐只是体验层,不做安全边界。

五、✅ 义父拍板(2026-10-26 20:22):B 端以小齐为准

一句话口径:B 端的一切,以小齐为准。
  1. 归属:B 端前端(b-workbench/ + miniprogram-staff/)及其配套后端(spa 域已交,

hotel/rooms 归属见下)全部由小齐定 —— 波波不再改动、不再评审、不再替他做决定。

  1. 第五节原两项待拍板,改为由小齐定:
  2. b-workbench(b.kailashi.cn)冻结 / 归档 / 下线 → 小齐定
  3. hotel 包重叠页(bookings vs board/room-today)留哪套 → 小齐定
  4. 波波的边界:A 端(admin-console/)+ C 端(miniprogram-v3/)+ 平台后端共用的部分。

B 端专属后端(spa.py 已交;hotel.py/rooms.py 若小齐要改则归他)以小齐为准。

⚠️ 边界未清时按「谁用谁定」:只有 B 端在用 → 小齐;C 端也在用 → 先对齐再动。

  1. 存量已做的保留:波波此前在 B 端做过的改动(设计系统令牌、emoji 清零等)不回滚,

也不再追加。此后 B 端文件波波只读不动。

  1. 设计系统真源及双端投影归小齐(2026-10-26 22:03 义父拍板,走 A 方案)。

跨端 UI v1.0 真源是一个整体工程,按 A 方案:真源 + 双端产物统一归小齐,波波不碰。

文件名带 C 端,但属真源在 C 端的投影/消费产物,归小齐——波波即便在 C 端域也不改这些文件。

不擅自新增/改令牌定义或适配层(那是小齐域,改了会和他的门禁打架)。

波波 C 端六道门禁现全绿,分工无冲突。


六、纪律

本文件即「功能包前端转向」的唯一口径文档,改口径先改这里。